#musicbrainz

(btw, http://test.musicbrainz.org:8888/ - not much to see yet, but that will change over the next week)

straight python, or honeypy?

cherrypy, I mean - and from this error, I'm guessing cherrypy :D

looks good :)

renders much more quickly too

because it does much less work :)

well, the html itself is a lot cleaner

opinion question for you. With the rewrite, how much do you think we should be worrying about non-js compatability?

as much as with the current server

how much is that, though?

all functionality much be available without JS

JS-versions might be better and have more functions

yes there's 10% that doesn't use js at all, but I wonder how much bulkier we end up making pages by trying to handle that 10%

that's the user who can't use guess case, who has ASIN urls which are borked, etc...

you have very wrong viewpoint...

don't make pages bulkier

brianfreud: you mean certain js code needs to be duplicated on the server?

umm, that is my viewpoint. I was saying that adding the extra for non-js adds bulk.

basic example, and this is simply extra data sent to 90%+ who never even see it, let alone other non-js handling issues: <tr class="spaced" id="relationshipNoScript"><td>&nbsp;</td><td><div class="relationshipNoScript"><strong>NOTE:</strong> You do not have JavaScript enabled. Not all of theattributes shown above apply to all relationship types, and withoutJavaScript we cannot selectively display the appropriate attributes.We re

JS should add extra, not the non-JS version

js adds extra functionality. non-js handling adds extra bulk, if only to explain that without js you lose functionality

i don't expect a few lines of <noscript> will have any noticeable impact on performance.

brianfreud: js shouldn't add functionality, it should only make things more convenient

just that clump of text adds 392 bytes to the page's size

Shepard: Guess Case, etc, is added js-only functionality...

cool http://orera.g.hatena.ne.jp/keyword/おぺらたん

mo!

brianfreud: no, it's only making correction of tracklists more convenient. you can do the same manually, so it's not functionality to me

depends on your definition of functionality then...

http://operawatch.com/news/2007/09/opera-vs-fir... XD

but you can't, let's say edit a track title manully on the db because you don't have access to it

CatCat: haha

if all those things aren't added functionality, what is?

of course you could say: MB is just a convenience tool for tagging my files which I could do myself. then there would be no functionality, only added convenience. but that wouldn't really describe MB very well :)

lol, sure.

CatCat: did you see my note about Thao Nguyen?

brianfreud: but the whole site works without JS

My point is, yes, ok, without js, things can still be done - but really, for that 5-10%, doing it that way is so much more painful, because of the convolutions you have to go through (old style VA adds???), is it *really* something someone would do?

if you had added a VA release the old way, then added it the new way, given that having js on or off is your choice, which would you really choice 100% of the time?

brianfreud: some people just like to click..

brianfreud, *I* something edit things from my phone with opera mini, I'd go against myself if I start adding JS-only functionality to MB

(yet strangely don't like to scroll)

sometimes

js of course, because it makes things more convenient :) but what if I couldn't?

I guess what I'm trying to say is, ok, yes, things +can still be done without js... but given how much more effort some things take to do the non-js way, does anyone actually still really do it?

brianfreud, you should concentrate on making the non-JS version as good as possible

and when you can't do any better, then start thinking about compromises

sure. I'm just saying that if it comes down to "this just cannot be done without js", is it really better to not have that, for the 90-95% who would use it, just to support that 5-10% who wouldn't be able to use it?

I don't think designing a website to work without JS is that much extra work: you can add layers which are then hidden by JS, you can add links to perform actions server-side which are cancelled by JS which will perform the action instead etc. - there is some work to be done in coding though, yes, because you have to reproduce the functionality server-side

if something cannot be done without JS then how can you have a non-JS version?

yes - and it's those workarounds, Shepard, that I was referring to as added bulk - imagine just that 392 bytes of wasteful html/text on the add AR screen. Given the number of ARs that have been added, how many TB of wasted bandwidth is that to have sent down the pipe, for the 95% who never even saw it?

you are trying to save bandwidth on wrong places

I think the "bulk" is actually on the server-side code, not in the HTML

and I don't think there is something like "this just cannot be done without js" :)

luks: I guess. Though, thinking on it, I wonder how many GB we'd save a month if there was a user pref "I use Javascript", so the server only fed that junk if the user option was off?

Shepard: css/js/ajax transforms

brianfreud, not much

given the amount of tables in mb, not much

if you were optimizing a program, I'd tell you to use a profiler

but I'm not sure what the website equivalent would be

:)

where would you save something? on the AR screen? so that would mean load in bits of HTML and attributes to represent the options every time a user changes the AR type?

firebug

I'm just looking at the raw code and so much of the workarounds seems like it could be trimmed somehow to make it tighter

like all the &nbsp; in the AR instruments list... I wish I could find a better way to do that

or the AR descriptions - rather than feed the description of every AR every single time, ajax pull the description only as that option is selected, etc

brianfreud, I bet that by removing 20 characters from the homepage you can save more bandwith than with total JS-only AR page redesign

sorry, but that style of webdesign you're proposing seems like 5 years ago to me

we could just stop people from looking at bach's page :D

lol, easy, get rid of the "<link rel="shortcut icon" href="/favicon.ico" />" line on every single page :P

luks: does the webserver support compression?

it's apache, so yes, but it doesn't use it

Shepard: I'm not quite sure how cleaner css or ajaxified pages would be 5 years ago style, considering ajax (or similar functionality) didn't exist 5 years ago, and iirc, css was barely functional then...

brianfreud, people were creating IE-only pages 5 years ago

well, 2.5 years ago then :)

<some point in the past when everyone wanted to ajaxify everything and no-one cared about accessibility>

wait, that's still today.. damn!

sure, but I'm not talking about making IE/FF/Safari/Opera/Konquerer/etc specific pages. I'm talking about at what point do we claim to support non-js, but that support for non-js is so cumbersome that even those who don't normally use js turn it on, just to avoid the non-js workarounds?

brianfreud, you are talking about pages that require a specific software

you said non-JS users are 5%-10%

according to the W3 stats, opera has less than 2%

should we ignore opera?

well, yes, but I would consider js to be a given in any modern browser, we're not talking about even flash or quicktime... this is basic javascript support we're talking about.

You could make the same claim about css - and yes, you "could" use the site without css, but who actually would?

Do we actually have stats for how many MB users have JS disabled?

last I asked ru, he said it was around 10%, iirc - that's where I got the # I'm using from.

Well, Macromedia claims Flash is installed into about 99% of all browsers, so we could actually transform the UI into Flash!

brianfreud: I don't think blind people care much about CSS given the non-existing support for its speech-features

but there's a big difference between "who visits the site with js off" and "who edits the site with js off"

And of those, how many are editors compared to read-only visitors.

snap...ish

if I were blind I'd rather turn JS on than getting confused by things changing everywhere all over the site

err, off

as for opera, if it was as totally non standard as say IE 5, and required massive workarounds like IE 5, and only had 2% of the market? Yes, I doubt many would bother to support it.

Why did people bother to deal with the IE 5 workarounds? It had a huge % of the market.

and I don't think you can go by the current MB stats because they're biased. if the site was more usable without JS, you'd have more people with JS turned off using it

and it's not very accessible yet either

I doubt it

[22:47] Shepardwait, that's still today.. damn! <-- lol

That's like saying "if we made it text only we'd have more text only users"

we'd also have less non-text only users

it's not the same

it would only be comparable if he'd said if the site didn't use javascript at all

there is tiemsi tutn on javascript becasue the javascrpt is buggy

You would really edit the same amount of VA if VA still was the same as it used to be, pre-the js improvments to the ui?

well i did when Va was edit the traqacknames only

to be honnest it was less of a page load :p

brianfreud: people browsing the site have to either adjust to it or not use it at all. of course the stats are biased. of course people's behaviour nad generally the people using the site will change if you change the site...

and there was no "edit all" for VA albums :)

going thourgh each artist routine, atleast you focused on each artist at a time

I swore off doing anything with VA when I was new to the site, 2 years ago, after the first time I tried to add a VA release and it took an hour to go through all the page loads

and when you had goen trought it it was doen ,no accidental relaods losing data

actually, 3 years ago now :P

i liekd the ancient way of doing it to be honnest

ugh

rather hated when VA edit all was turned to the artists and not just the rtracknames

40 track VA comp? 42 pages, assuming every single artist already exists?

no thank you. :P

CatCat, well, you hate every change. that's nothing new

and when who was it, that created the first patcdh

it only did the tracknames thoguh

il oved that

didn't it used to select artists automatically if there was only one match?

yes

luks: that isnt true

i loved your easy ar serach in page

I liked that

me too

but now that is borked

adding ARs was more effective to me in the past

heh

also adding a va album was no biggie ,as it makde dupe artists bothe here adn there witotuh asking :)

nothing changed about adding ARs

sure it did

you made it twn times easier

luks: when you add an AR to releases it now goes to the artist page after that :)

Shepard, it does to the page where you was before

all I know is, when I added this release, it took 2 hours to go through all the various page loads. The same today would take 5-10 minutes. No way in hell would I willingly go back to that. http://musicbrainz.org/release/9f864dcf-21a4-42...

and if it doesn't, it's a bug and should be bugs.mb.org

ah, that explains why it sometimes did go back to the release..

brianfreud: yes but after each load of a page that edit was submitted

i am always paranoid abotu releases now

since the urls arent even spesific

well I generally start at a release, then go search for the artist, if it doesn't exist add it and then add the AR. and I want to go back to the release after that :)