[UI] QML CV usability feedback

[Thomas Pfeiffer]

On 01.10.2012 08:34, Bart Cerneels wrote:
> On Fri, Sep 28, 2012 at 3:47 PM, Thomas Pfeiffer <colomar at autistici.org> wrote:
>> Hi everyone,
>> I've now compiled the QML branch of Amarok and will give some feedback to the
>> new Context View, as promised about a month ago. I'm addressing the whole list
>> since I'm not sure who will be working on the CV in the near future.
>>
>> First of all: I really like the look of the new CV! It's much cleaner and
>> fits better with the rest of Amarok's appearance compared to the old
>> one. I'd recommend changing the blue boxes at the bottom of the collection and
>> playlist areas to some shade of grey as well though, since now without the
>> CV's blue, they look rather out of place.
>
> I'm a bit worried about the sea-of-grey effect. The coloring of CV and
> toolbars might have been badly implemented in the past, but at least
> it prevented that uniform grey look.
> Perhaps we can do more background images and some color shades, but
> with the KDE color scheme it's always the question of what color role
> to use.

Sure, it doesn't have to be all grey. There just should be better transitions 
between the different colors, as currently the toolbars look rather alien.

>> Now for the usability feedback: It's a bit difficult to give much feedback on
>> the current state, because the more tricky things (like the integration of
>> additional CV "modules" or their configuration) are not implemented yet. Of
>> course the good thing about it is that we can work together on interaction
>> design for those things before they are implemented, which is less work than
>> having to change things afterwards.
>> My feedback to what's currently there:
>> - The icons look nice in monochrome, but currently they lack a bit in "click
>> affordance", meaning that it isn't obvious right away that they are actual
>> buttons vs. merely information icons, because they look very different to the
>> other button icons in Amarok. Maybe some very very slight plasticity effect
>> might help there. Perhaps you should ask the KDE artists team if they can
>> create icons for you which look clearly like clickable icons while still
>> fitting visually in the CV?
>
> I had to look up the definition of "affordance". Learned something new
> today, thanks.

Sorry for the jargon. But hey, I've learned tons of technical terms since I 
started working with KDE folks as well ;)

> Perhaps the solution is to make all the buttons in Amarok look similar/nicer?

Yes, there should be some recognizable visual element/theme among all button 
graphics. I'm not a visual designer, though, so others will have to make sure of 
that.

>> - Unless you plan to re-implement the drag-mouseover feature of the old CV,
>> the CV should definitely be placed on the right of the UI instead of the center
>> by default now. The mouseover options were the only argument
>> for keeping the CV in the center before, and with that removed, it would just
>> make no sense at all to keep it there and forcing users to drag items all the
>> way over the CV to the playlist.
>
> You are taking about the PopUpDropper (PUD) which we intent to keep.
> Even if we didn't the default layout should keep the context in the
> middle for consitancy with earlier Amarok 2 verions.

If the PUD returns, it makes sense to stay that way.
If it doesn't, keeping something with obviously negative consequences for 
usability for consistency's sake isn't a good idea. The burden of adapting to a 
changed layout is lower than the burden of needlessly dragging things form one 
end of the UI to the other every time you want to add them to the playlist.

>> - I think placing the different content types (lyrics, Wikipedia, etc.) in one
>> long column that can be scrolled continuously instead of switching between
>> them would be better. Of course users could still scroll directly to each type
>> with buttons above, but they could also scroll through them continually. The
>> advantage would be that a user interested in everything about the current song
>> could just read on from lyrics to Wikipedia to e.g. concert dates without
>> having to click any buttons, bzt can still use the buttons to jump to a
>> specific type of information.
>
> You mean without a scroll bar for the wikipedia content? It might be a
> bit long, but I personally loath double scrollbars, so certainly in
> favor.

Agreed, double scroll bars are a no-go. The length of e.g. the wikipedia article 
isn't a problem, though, because people who don't want to scroll through the 
whole wikipedia article to get to the next type of content can just use the 
buttons, so it won't be slower than it is now in the QML CV (where the buttons 
are the only means to switch between modules)

>> - I don't know what exactly the new CV currently pulls in from Wikipedia, but
>> it isn't the artist's main article. The main article would make more sense
>> here, since the things currently shown are not very informative.
>
> Ideally we'd show Artist, Album and track pages in that order. It's
> just a bit tricky to do since we are using heuristics to search and a
> bit of scraping to get the content. We should be using something like
> dbpedia.org

Currently the QML CV displays some kind of an overview page for the artist with 
a list of albums and a few lines of bio in some cases, but certainly not the 
main article. And it doesn't display any album/track info. The current (Plasma) 
CV does a better job here.
I know that the heuristics sometimes fail, but I don't think this is that much 
of a problem. However we certainly need clickable links (currently not the case 
in the QML CV) for example if we land on a disambiguation page. And a structured 
database could be put to good use here as well, sure.

>> And finally for the future interaction design:
>> First of all, I'd need to know which features of the old CV you are planning
>> to re-implement and which ones you are planning to cut. Depending on these
>> decisions, we can start working on interaction design for the planned
>> features.
>>
>> I'm looking forward to working with the Amarok team again (and now I've finally
>> got the hang of compiling Amarok master or branches from Git easily, so I can
>> try things out immediately)!
>
> Cool, I'll make sure you commit to that. I'll keep the long pointy
> stick ready ;)

That stick may indeed come in handy at some point, because I'm currently rather 
deeply involved in three KDE projects, plus a few more with lighter involvement, 
which makes it a bit difficult to keep track of where my help is needed at a 
given point. So if I happen to miss some UI discussion, feel free to prick me 
with it ;)

>> Thomas
>>
>> P.S.: I'd like to establish the [UI] tag for UI-related threads on this list
>> so that people like me who don't understand purely technical threads anyway
>> can concentrate on the threads relevant for them. If that's okay with you
>> guys, I'd appreciate if you could add that tag to the subjects of UI-related
>> mails in the future.
>
> Good idea. But reading the purely technical and social topics should
> not be avoided. They are the context in which the UI makes sense.
> UI threads certainly need screenshots. Do we have an easy place to
> upload them and keep persistent links? Various services around, but
> I'd like to know which work best and standardize a bit.

Of course I'd ideally be reading every thread. It's just a matter of 
prioritization to me. As said above, I'm involved in several projects and I 
simply don't have enough time to read through all of their mailing lists. That's 
why I'd like to focus on the topics which I actually understand (my programming 
knowledge is very limited).
Of course people can always point me to threads which specifically provide 
needed background to a UI discussion.
If we had enough "usability people" in KDE to have a "UX specialist in 
residence" for every major project, each one could afford to be a full member of 
the core team. Currently I'm afraid I just don't have enough spare time to read 
every thread in the mailing list of every project I'm involved in (my "main 
project" is still my PhD).

And, screenshots are needed, yes. I'd suggest putting them up on Techbase, since 
it's in our hands and we can add text to them. It may not have the most 
convenient upload mechanism, but I guess it's okay for our case.

Thomas