#musicbrainz

Damn, my Picard is broke :-(

aww

something stole my wxPython apparently.

bizarre.

Bleah, debian packaging weirdness I think.

you can't even imagine how happy i'm about this mods :)

yay! :)

djce: hey!

hi

I think debian stole my wxPython 2.5.x package.

So now I can't run Picard :-(

aww

after I finish my lunch do you have a few minutes to hash out some artist page redesign things with g0llum and I?

If I'm still around, sure.

5 minutes

I think I'll be for an hour or so.

perfect.

ehhh

2.6 in experimental?

really?

nice :)

eh.

and I went and compiled the damned thing

oh wait

I compiled it multiple times, failed to succeed, told it to fuck itself and aliened an rpm

i guess debian's version doesn't include the gizmos-extensions, let's take a look :)

right-o then.

g0llum, djce: you two around?

here

me too

good. have you seen the artist page redesign stuff on test.mb.org?

nope. /me looks

The details tab and overview tab are basically done.

now I have. In fact I saw something similar on g0llum's site.

(at least no major questions remain)

right.

so, now I am trying to design the back end for this.

questions that I have:

what is the proper granularity for sending albums to the user?

how to we cache this thing properly.

oh, it lists the albums alright :)

the latter question is heavily influenced by the former.

so, lets focus on the proper granularity.

g0llum: what is the URL to your mockup of the metallica page?

sec

i want to show dave the advanced stuff.

there's only the snoop stuff somewhat done

djce: one of the aims is to show AR stuff in these pages, rather than oen massive block as we have it now.

g0llum: fine

RobertLeCoquin is now known as Dominator

djce: that will make AR caching easier too.

my most immediate question is this:

what do we send when we show teh discography?

g0llum and I settled on just albums, not any of the other releases.

then, how does one select the other releae types -- that's one question.

I guess we need more info on the most common use case.

what do people want to look at when they come to an artist page?

how do we send the right amount of data? not too much, not too little?

from what i've heard, people use the compact view.

that's the amout of info i'd aim for

I love the compact view

djce: have you looked at the discography / customized view?

The obvious, but non-trivial answer is to be flexible.

yes, I did.

and direct links from the main page (or a dropdown menu on the discography) to pre-select filters (e.g. bootlegs, official releases, singles whatever imaginable)

from a UI note, we should make this the 'Advanced' view and have two simpler views.

Implement as many views as we can care to think of.

a default view which is the collapsed view equivalent...

then maybe have "discography" start on the user's preferred view options.

sure, that works too.

back to the question of granularity.

g0llum: YES!

djce: yes, or keep it in the session

do we always want to show a group of albums?

(EPs, live releases, etc)

or a combination of groups?

Whatever the user wants. But that's more work for us.

yep.

so, by default we show only album, in collapsed form.

hmm. the experimental debs seem to work

with an option to show all albums.

nikki_: thanks!

g0llum: what do you mean by "open albums" ?

expand/collapse

the current version features complicated server side code for that

but that would still be possible via a request/response, yes?

not useful imo

I really like g0llum's idea of not sending HTML formatted albums, but sending a JS script that can show/collapse/expand albums on demand.

you can open the album in another tab/window if you can't/won't support the advanced features

That works, as long as the non-JS UI isn't too dreadful.

sending a compact array of JS is less bandwidth intensive than fully formatted HTML albums.

you see the layout of the mockup, nothing more, nothing less

of course.

then the question becomes whether or not to send ALL albums by default.

no.

and we will still have the compact view of course

definitely not.

if I understand g0llum right, I have no objections to that (shock horror!)

three letters: J.S.B.

lets talk DB loading and caching for a moment then.

djce: its only the album titles, which amounts to the size of the compact view

JSB?

Bach?

ding!

oh yes. good example.

on the server, should we load all albums, even if the user asked just for the albums, and shove everythinginto memcached?

So, by all means default to showing up to, say, 50 albums.

then if the user expands something, we just pull it from the cache.

well, the client may not show them all right away.

but could do so without reloading the page.

why not send all albums unless there are more than a certain no.?

dseomn: thats another option

complicates matters, but its an option.

g0llum: and I originally thought about by default sending only albums.

if the user then pokes around more, we'll load and send them ALL.

thus not requiring more loads after that.

but that granularity seems too big...

yeah, i suppose that people would think there are albums missing

What's the purpose of the cacheing. Performance?

yes.

and longer disk life

am I optimizing too soon again?

Because the other issue which has been mentioned in the past is allowing spidering.

but spiders of course will always use the non-JS UI

another quite hairy issue, tbh.

best ignored for now?

afraid so.

otherwise we'll never get this done.

ok, fair enough

hehe, true

just checking what's "in scope"

:-)

ruaok: the list you're displaying for metallica is all releases now, right?

i like this view too, we should keep it