UI Suggestions for discussion on the dev sprint

[Thomas P.]

Here are my 2ct on UI/Usability for discussion on the dev sprint:

1. Tree view node behavior
I would heartily recommend making the collection tree behave like other
tree views in KDE and other platforms, i.e.: Single click selects a
node, double click expands the branch under it. These are the
disadvantages and advantages in my opinion:
Disadvantage: 
- One rather efficient way of adding an artist or album to the playlist
(by double-clicking) is lost. Some users that have been regularly using
that method would need to adjust to the change.
Advantages:
- Higher external consistency. That means two things:
        - Users which are new to Amarok but hav been using KDE or other
        platforms which expand branches on double click don't have to
        re-learn the behavior of the concept "tree view" for Amarok.
        - Users who use Amarok in parallel with other applications that
        have a tree view in them don't have to keep in mind that the two
        tree views look similar but behave differently.
- The artist name / album title (or whatever tags are used for grouping)
are a much bigger click target than the + to the left of them, thus
making it much easier to expand a branch.

Conclusion: In my opinion external consistency and bigger click targets
outweighs decreased efficiency in this case, so I recommend using double
clicking for expand instead of add to playlist.
If the team concludes that you want to keep the "double click to add to
playlist" functionality, I highly recommend doing the same with the root
node. If that is impossible for some reason, it should do nothing on
double click rather than expanding since the latter would raise
expectations that other nodes behave the same.

2. Context view scrolling
The current way context view widgets are presented (i.e. in a continuous
but un-scrollable way) is quite problematic. Seeing the upper end of a
widget on the bottom of the CV makes users want to scroll down to see
the rest of it. Instead they can only click the widget in the widget bar
below. This causes an inconsistency between the way of presentation
(continuous) and the way of interaction (discontinuous) which is bound
to cause confusion. 
The most natural way to solve this would be to add a scroll bar to the
CV. The problem here is that many widgets already have their own scroll
bar and having two scroll bars directly side-by-side clearly isn't a
good thing. 
- A few weeks ago Gary Steinert proposed using a widget similar to the
thumbnail view in Okular to scroll through the widgets. This would have
two advantages:
1. It introduces a way to scroll down the CV continuously without
interfering with the widget-internal scrollbars too much
2. It may replace the widget-bar at the bottom (by allowing placing and
(re-)moving widgets within) and present the widgets in the same
orientation (vertical) as they are placed in the CV, thus creating
consistency of presentation and interaction. 
- Another option would be to never show parts of widgets which don't fit
into the current view. That way though it would behave much like the
multiple panes introduced in 2.0 which obviously created usability
problems as well.


3. Configurability
I know this is a difficult topic. KDE 3 and many of it's applications -
including - Amarok made the mistake of giving the user an overwhelming
amount of configuration options. I fully understand that you don't want
to repeat that mistake. On the other hand, KDE 4 doesn't go the way of
taking most of those options away (as many GNOME applications do) to
keep the configuration UI as clean as possible. What KDE 4 is aiming to
achieve is to keep reasonable amounts of configuration options and
present them to the user in a well designed interface.
The - really hard - question is: What options are reasonable? One way to
find that out would be to ask yourself: How many users might want to
turn it on and how many would want to turn it off and do they have good
reasons to want / not want it? If > 90% of users would be better off
with or without something, you don't need to create a configuration
option for the remaining < 10%. But if a feature is useful for 60% of
the users but annoying for the remaining 40%, making it configurable
would make sense.
One of Amarok's features this might apply to is the context view. It is
an awesome feature for people for whom rediscovering their music often
means getting additional information about it like lyrics or wikipedia
entries. But for some of those people who use Amarok mainly to just play
their music, it may seem like a waste of screen estate. It is possible
to reduce it to zero width, but that is not an intuitive or discoverable
way to hide an element. And since Amarok would suit the needs of a
considerable group of users better with a hidden CV, this would
definitely make sense to be configurable in the options.
Another feature that could make good use of configurability is the
playlist toolbar. Since it is the only toolbar in Amarok, it could be
configured via the "configure toolbar" dialog as in many other KDE 4
applications. For example, not all users actually save or export
playlists, so not everyone actually uses those buttons. Random and
repeat, on the other hand, are options that some users might want to use
quite often. So it would be helpful for users who use random and repeat
far more often than save or export (or even undo and redo) to be able
replace the latter by the former. Of course, since this is not a general
toolbar but a playlist toolbar, only playlist controls can be put there.

Hope this will fuel some constructive (but not too heated ;) )
discussion. It's too bad I can't personally be on the sprint, hopefully
I can make it to the next one. I don't even have internet connection
from tomorrow till friday, so I apologize in advance for not being able
to answer any questions until then. 

Have fun,
Thomas