[mb-style] AR Types

[Brian Schweitzer]

Thanks for the detailed comments :)

There's obviously a lot to go through in there...  let me just touch on a
few before I sleep, and I'll take a look again when I wake up, as well as
any other comments anyone may have, and see what I can do...

>I think we should work very carefully on the wording of this page, to make
>its meaning very clear to dedicated but novice editors. The wording "AR",
>"Release AR", "Track AR", "the entire release", "some tracks on the
release"
>are open to misunderstanding. It may be that we will only be able to
express
>them concisely after we've written the page that expresses the concepts
>precisely in multiple paragraphs.  (Said the writer to the editor: "It's
too
>long, I didn't have time to make it any shorter.")

Very much agreed - that's even, to some degree, why I left the pink boxes
technical...  I'd rather we decide on a layout, then worry about the text,
though it does make some sense to debate the text now too.  My fear would
be, if we debate the text too much before the layout is "locked", we'll end
up liking some exact text, and having to make the UI fit it.  I think we end
up with a more useable UI if we first get the UI to some point where
everyone likes it and finds it simple enough, then craft the text to fit
what we've got - my gut just tells me we'll end up with something slightly
more user friendly that way.

>You mention that the first radio button is hidden for Type 1 ARs. Agreed.
>All three radio buttons should be hidden for Type 2 ARs (apply only to the
>Release as a whole, not to Tracks).  The only correct answer is "This AR
>applies to the entire release", so there's no need even to ask the user.
>Type 3 ARs would show all three radio buttons.

Good thoughts.  Just so we can all visualize and decide exactly which of the
three would show when, anyone feel like making up a chart of the various
type combos, and which of the three would show (or not show) for each type
combo?

>"Note, since we have no such list yet of which ARs would or wouldn't ever
be
>type 1....": I thought that's exactly what
>http://wiki.musicbrainz.org/BarryPlatt is -- albeit only a first draft.

Agreed.  I think also that's why, for now, it'll be better to keep the
discussion of which type combos show which of the three radios separate from
Barry's end of the discussion - they're related, but again I think we'll
keep things simplest by separately deciding "which ARs go to which of the
combo of the 3 types" from "which combo of the 3 ratios is shown for each
combo of the 3 types".

>I love the per-track Begin and End Dates. I suggest they be put to the
right
>of the track titles. Thus the track titles can be indented less relative to
>the radio buttons, which I think is an improvement.

Of all your suggestions, this is likely the only one I disagree with.  The
reason essentially is twofold:

1) Yes, I could make the column indents change drastically for the tracks vs
tracks+dates views, allowing for an indent in the former and no indent (to
fit the date boxes) in the latter.  But this would seem visually rather
distracting, as not only will the boxes appear, as now, but that entire
column will also flash for a half second, as the browser rerenders that code
and moves the text an inch to the left - ie, imagine the slight vertical
jumpiness you mention on the one version of the page, and magnify it about 5
times, but with a horizontal jumpiness instead.

2) More important.  (The above is a visual nuisance, but if it's what we
want, sure :) ).  The main reason I would suggest we keep the date columns
on the left side is purely practical.  The track titles column is
left-aligned as so:

YYYY-MM-DD  Track title text
YYYY-MM-DD  More track title text
YYYY-MM-DD  Even more track title text
YYYY-MM-DD  And yet lots more of the track title text
YYYY-MM-DD  ...track title text
YYYY-MM-DD  Track title text again
YYYY-MM-DD  Track title text and so on

It lines up perfectly, and there is essentially no horizontal jump across
white-space required for your eye.  Now, if we change it so the dates column
is on the right side, it's now bumping up against uneven text - it's
essentially positioned based on the longest track title's length, requiring
a large horizontal whitespace jump for the eye:
(This next example may or may not line up right, depending on what font
people are using - hopefully it still conveys the concept though):

Track title text                                      YYYY-MM-DD
More track title text                               YYYY-MM-DD
Even more track title text                       YYYY-MM-DD
And yet lots more of the track title text   YYYY-MM-DD
...track title text                                    YYYY-MM-DD
Track title text again                              YYYY-MM-DD
Track title text and so on                        YYYY-MM-DD

See the problem?  Because it's no longer quite as consistent a line, it's
suddenly much more difficult for your eye to identify at a glance which set
of date boxes goes with which set of track titles.  (Quick example:  Look at
the first example, and try to get a feel for how quickly your eye matches
"Even more track title text" with its proper date-pair.  Now try to do the
same for the second example.  Feel how it's a bit more uncomfortable to your
eye to try and identify the correct date-pair in the second?  If you did
this as quickly as you could, would you feel more sure that you'd identified
the correct date-pair in the 1st or the 2nd example?)  Now this could be
worked around, with a dotted line to lead your eye across the white
space...  but that adds more to an already busy area of the screen, and if
you're working on a longer tracklist - say long enough that at some point
your entire scrolled-down screen is simply a partial list of tracks, the
benefits of the dotted lines begins to go away simply due to the sheer
number of dotted lines.

>Filling in anything in a per-track date should check the Track's checkbox.
>Unchecking the checkbox should erase the per-Track dates (or perhaps
visibly
>disable them).

Personally I'd prefer to disable than clear the date boxes - you could
easily accidentally check the wrong checkbox - reenabling is easy, having to
re-fill in the boxes would be much more annoying.

>I'd love a small "copy to next" button between each adjacent pair of
Tracks.
>Click this button, and the checkbox and dates from the track above get
>copied down to the next track.  This means that, where there's multiple

Not a bad idea.  It's perhaps a little beyond my js abilities - if I was
dealing with static form boxes, no problem.  Dealing with dynamically
generated ones like this is a little more complex, but I'm sure there's
someone out there would can help out with tweaking this in.  More important
though, is how to represent such a function button in there without it
adding yet more "blob" of functionality (making the page seem too hard to
use) while also not making it so small as to be difficult to actually click
on.  Anyone have any ideas?

>Suggest "All tracks" and "No tracks" buttons at the top and bottom of the
>list of Tracks. They select or deselect all Track checkboxes.

My fault!  :)  I knew I'd forgotten something, I just couldn't place what it
was.  I'll definately add the "select all" back in.

>I think the per-Track date entry boxes look cramped.  I'm not sure if the
>text size in the box is too small, or the boxes are too tight around the
>text, or if it's just a matter of making them grey instead of black to
>reduce the visual clutter. But something looks cramped and busy there.

I do have them about as tight as absolutely possible, as every extra pixel
in the boxes adds 6 extra pixels to the width of the date-fields, and takes
that 6 pixels away from the text.  (6 pixels is just slightly wider than 1/3
of the width of the month and date boxes).  I like the idea of playing with
greys though - I'll play with it some more and see what I can come up with.
(Also, note your cramped/busy comment - this is just what I'm looking to
avoid with any "copy to next" button we might add in there.)

>Here's an idea: put dates to the right of each Track. Keep existing Begin
>Date and End Date at bottom visible in all modes.  In "same dates for all"
>mode, the per-Track dates are disabled, but those Tracks which are checked
>always have the same per-track dates showing as are in the Begin Date and
>End Date fields at the bottom.  As the Begin Date and End Date values
>change, values in all checked Track dates change. In "separate dates per
>track" mode, the Begin Date and End Date fields at the bottom become
>disabled, the per-track dates become enabled, and they retain their
previous
>values.

It's likely my brain getting tired, but this is a bit muddled to me.  If I
read it right, though, I think it'd work to make the UI very overly complex
to use...  you're now using 2 sets of fields (the checkboxes and the release
date boxes) to do one thing in one mode, and a completely different and
semi-unexpected thing in the other mode.  From a "page weight" point of
view, this would also add a good bit of extra javascript to the page, which
would slow down the transfer, loading, and rendering of the page - my guess
by around an extra 10%.  Personally, I'd prefer to keep it simple, each
field having a single function if its even visible.

>The "same dates for all" vs "separate dates per track" choice could perhaps
>be better expressed as a radio button pair, just above or below the Begin
>Date and End Date fields at the bottom.

This too would seem to make the UI more complex without a huge benefit -
people expect radio buttons to select options, while input buttons "make
things happen".  I'm not sure if tying a UI change to radio buttons would be
quite as intuitive to use.  (It also starts to get in to the "too many
little dots doing different things" problem - we already have one set of
radios, and one set of checkboxes - adding another set of radios starts to
make things just look complicated...)

>On my browser (FF 2.0.0.x on Mac OS 10.5), the track titles and bottom of
>that box jump up and down in addARdates.html when I switch between
>Release-wide dates and per-Track dates. They don't jump up and down in
>addARdates2.html. The difference may just be that the latter leaves space
in
>the design for the "Begin Date - End Date" heading.

Yes, that actually is as intended...  The css collapse function which IE
doesn't support essentially is eliminating that row entirely, whereas the
css hidden function that the IE version of the page uses simply hides the
row, but still allocates empty space for it.  To my eye, however it's coded
in a final version, I think you're right in that having a slight empty space
there without the jumpyness of all the track title text is better (so using
hidden, not collapse, there).

>The buttons for "Edit dates per track" and "Edit dates for release" are in
>different positions. I think they should be in exactly the same position.
>Nothing on the dialog box should change position or resize as the user
>switches date modes.

This is actually due to a hack I have in there at the moment - the if / else
I was trying to use simply wasn't working, so rather than put off publishing
it a day while I messed with the button's code, I simply have two buttons -
one of the pair is always hidden, depending on which view you're in.  This
would be the most obvious candidate for "de-hackifying" if people like this
concept.  :)

>If the track names are long, will they wrap to the next line?  That's
>particularly important if the date fields get moved to the right side, and
>when editing classical music Tracks, where titles have been known to
include
>all of "War and Peace".

Yes, I actually specifically tested this.  You can see it in the one Mozart
title a little, but even that one's rather short.  I tested with a 550
character (almost twice our length limit) title, and made sure it wrapped
properly - no matter how long we allow track titles to get, it ought to
handle wrapping them properly without any problems.

>I like the cover art in the upper-right corner.  Is that in the current UI?

>I haven't noticed it.  The cover art is in the right corner of the window,
>which on my computer puts it some distance to the right of the rest of the
>UI structure.  If it could be positioned above the right edge of the list
of
>tracks, that would be nice. Not worth spending much effort on, though.

No, it's not in the current UI - I wasn't sure about adding it, but it does
seem to give the page that little bit of "color" it needs, considering
people may be spending a lot of time on the page.  As for where to put it,
if people even think it ought to stay, I'm open for suggestions.  :)

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.musicbrainz.org/pipermail/musicbrainz-style/attachments/20080106/d19a0649/attachment-0001.htm