Amarok UI analysis, proposal - link inside

[Thomas Lübking]

Am Wednesday 07 October 2009 schrieb Téo Mrnjavac:
> that's more text than many of us are used to actually reading here :)
Hehe, i actually cut things off - there would be more, but in a way related 
stuff =D

> I think we should focus on making the interface netbook, laptop, and
> big screen -friendly, and leave vertical thumb-based UIs for another
> discussion.
Ok, will drop handheld aspects for now.

> First of all, I agree that we need to use vertical space sparingly,
> and that the main toolbar should have some kind of symmetry. That has
> already been discussed pre-2.2 for a post-2.2 implementation.
Great, so starting from these screenshot (quick ggi:)
http://amarok.kde.org/blog/uploads/amarok_xtina5.png
http://blog.chip.de/chip-linux-blog/files/2007/11/amarokampacheservice32.png
http://blog.chip.de/chip-linux-blog/files/2007/08/amarok2_preview2.jpg
http://farm4.static.flickr.com/3040/2443323556_e1f473994d_o.png

The obvious problem is the toolbar height, which derives from
a) the vertical stacking of buttons and slider
b) the button style itself

To handle this problem one could either
1) use an autohiding toolbar (sliding over the lower area)
2) try to reduce the vertical space requirements.

Now, for a centered layout one cannot do much about a) but one can improve 
things a lot by adjusting b)

these shots:
http://blog.chip.de/chip-linux-blog/files/2007/08/amarok2_preview2.jpg
http://amarok.kde.org/blog/uploads/amarok_xtina5.png

do not suffer from "superflous" deco elements that cover vertical space, but
a) there's a frame around the buttons on the 2nd and 
b) a frame around the actual icon around each button (the circle)

Ths is one of the "cut off" items:
Icons tend to look this way to cover various window colors (i.e. the black 
circle constrats on bright bgs while the white area inside on dark bgs, so the 
dark icons (|<|| > >|) are visible for sure)
However, the way amarok is currently implemented (svg icons) this isn't 
necesary at all - amarok has perfect control on fore- and background colors of 
the icons.
Therefore i'd simply suggest to drop all these frames to save some (esp. 
vertical) space (the button can be smaller while the unique icon part remains 
at its size) and as a bonus unclutter the UI.
(If anyone is interested, i'll try to refind the Apple HIG page that also  
indicates that such outlines are bad regarding icon detection, "unique shape 
over color")

Other  than this and as proposed on the MID concept sketch,
http://cloudcity.sourceforge.net/amarok/amarok.16_10.png
(sorry i didn't notice that the initial upload failed :-(
 it's possible to preserve vertical space by limiting the horizontal dimension 
of the toolbar.

So if one concludes that the vertical space is esp. crucial to the context 
view and the playlist, but not the media sources (filesystem, database),
having the toolbar work better on low horizontal resolutions implicitly 
provides a solution for the vertical space issue as well.

> Moreover, my personal opinion is that currently amarok has too many
> thick borders and other unused gray space, and I'm afraid that this
> won't be easy to change in a clean way as long as Oxygen is the
> default KDE widget style. 
As long as you control the painting (i.e. don't use std. UI elements), it's 
not really necessary to respect KDE spacing hints - nor the oxygen ones.
(I.e. the app might always say "I know better - there's no reason for large 
extends, so please use these values")

But yes: 
Oxygen isn't really MID compatible and most other styles could do better as 
well ;-)
(Actually I once ever agsain played with the idea to write a style focussing 
on such devices ;-)

Skål,
Thomas