[mb-users] A Call For Feedback - "StructuredXHTML" branch

[Oliver Charles]

Ooo, more feedback. Goody :D Quick note, this post is a bit long as  
I've combined feedback from both Aaron, Frederic and some other  
people at the bottom. It should be quite light reading though. Also,  
there is an important note at the bottom regarding the search field -  
please take a read of that!

Firstly, Aaron:

> Love it, looks much tidier, I agree!  By the way, I am using Firefox
> 2.0.0.4 on Mac OS-X 10.4.10

Ah thanks, that makes it easier - as I have the same browser and OS :)


> I see the icons now - very cool idea.  They didn't show up before, so
> perhaps you fixed something?  I'm still wondering about some strange
> behaviour inside the boxes though:
>
> When you click in the top 4, the word is erased and then if you don't
> type anything they stay empty.  Is this desired?  I think if they're
> empty and it's possible it would be good to refill them with the
> search type word (artist, album, etc).
>
> Also, the 5th search a) has no icon and b) the text doesn't behave
> when you click inside the box.  I'm sure we could rig up a simple "MSN
> guy"-type icon to represent editors (if we don't have one already).

These search boxes are very work-in-progress at the moment, but I'm  
glad you like the initial concept. I've had mixed opinions about  
this, mo for example does *not* want to see a javascript system.

The strange text deletion is because I only really mocked it up to  
quickly demonstrate the concept in IRC, but I forgot I left it on the  
live server. If I stick with the javascript system, I'll use some  
proper programming to replace blank text, handle the correct events -  
but I need to know if I should stick with this system, or try another  
system (maybe sans javascript). I have improved the mock up anyway  
now, so it should work for keyboard navigation, and resets it self  
correctly.

The editor search doesn't have an icon because one didn't exist  
(well, that I could find in a quick scan of the images directory  
anyway…) and I'm no artist! I guess I forgot to add the javascript  
onto that box, heh.

An option to make mo and other people who don't want to see  
javascript happy might be to have a preference to use the "old style"  
search - that is, with a label and empty fields - or use the "new  
style" search with javascript. But I'm hesitant to do that because  
it's yet another option...


>>> On the browse pages, my first tab takes me to the search text  
>>> boxes in
>>> the sidebar.  I think it would make more sense if tabbing took you
>>> first to the text field to enter the browse character.
>> I've added a form focus field, so it's focused on there by default.
>> Not sure about changing the tab order yet, but I've made a note :)
>
> It doesn't focus there by default for me.  I've tried refreshing a few
> times but no luck.  Again, I'm running Firefox 2.0.0.4 on Mac.

Hmm, it's not working for me either… I'll look into this!

> And one more thing: I wondered what other people thought of the
> justified text.  I don't think I'm really a fan of it because I think
> it can look goofy in the ride blog panel when three words are spread
> across an entire line.  I compared it to the current MB page and I
> think that, in the right panel at least, left justified text looks
> better.

Hmm, I understand what you mean, I've never found it too much of a  
problem, I much prefer the odd rendering quirk on a line, rather than  
some more compact formatting that interupts the flow of the  
paragraph, if that makes sense. Maybe a compromise would be to turn  
justification off for narrow boxes (such as the right hand side bar)?  
I've enabled this now, so let me know what you think :)


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Frederic:

> I prefer justified text, but only if the justification is done between
> the letters of a word too: I feel the difference in spacing between
> lines helps me to keep track. But I don't have a visual impairment, so
> my opinion here is not very important.

Hurrah, a conflict! :) Well, how would you feel about the compromise  
above?

> First of all, all my remarks will be blind-users oriented because this
> is the only impairment I know.

Yea, and it's probably the most significant aspect for the new  
website. I'm trying to put a lot of effort into making it suitable  
for screen readers - try turning off CSS and you'll see the  
navigation folds out, and there are some hidden helpers for screen  
readers.


> The color is much better. We'd need someone with an actual visual
> problem to say, but at least to my eyes it is much clearer.

Glad we've found a suitable colour :)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Some other points that people have raised:

"A bug with the sidebar, the >> after Direct Search, as it touches  
the sidebar edge, as does the ellipsis after More."
Should be fixed now, thanks Brian!


"Toggle doesn't work"
Yea, not going to be able to get that done yet, but I have made a  
note. It'll take some javascript hacking, so I don't want to do it  
just yet.


"Far too much padding on the blog headers"
Don't know how that slipped in, but it should be more compact now.

"What's up with the News heading, on the right hand side, it seems  
redundant"
I suppose yes, it is a bit redundant. But if we get rid of it we'll  
break the grid, and that won't be pretty. I can always leave it  
blank, as has been suggested, but I'm not sure it's doing much harm  
as it is. It may be a bit confusing for people using screen readers  
to hear News followed by information about the MetaBrainz Foundation.

"The icons look misplaced in the search fields"
True, maybe these would look better if I made them gray scaled?

Me and Brian also talked a lot about the ordering of the horizontal  
menu bar. Alpbetical is in one way accessible, but I don't think it  
really does justice here. Here's an example. A new user comes along  
and wants to search for an artist. Ignoring the quick search fields  
they go to the search menu. They know the need to find "artists" so  
they hunt the menu. If we write "artists" it's at the top, if we  
write "search artists" it's at the bottom, so alphabetical ordering  
really hasn't helped. Maybe rethinking the  current priorities would  
be a good idea.


Now then, the important note about the search fields. Currently,  
these fields are confusing, as each field is exclusive. That is,  
entering data in both the artist and release fields is meaningless,  
it will only take data from the last field (the one you submitted).  
Rather than coding something to allow a union of these fields, Brian  
suggested we change it to just one field, and instead use a combo box  
to choose what to search. This loses the javascript, makes search  
more compact, and it makes more sense. I'm all for it, and have added  
a sidebar module (that's not functional) to see how it looks. Any  
objections?

As you can see, no concrete decisions in some places, so any input is  
as always highly appreciated :)

Thank you everyone as well for all the feedback, it's very detailed,  
and really helping me get this page as perfect as I can. Thank you!


~ Ollie