Concep 0.5, mockup #1

[Thomas Lübking]

Am Monday 26 October 2009 schrieb Jakob Kummerow:
> Well, me, I'm *very* skeptical about a more dynamic UI. Reasons:
> 
> #1. As Myriam said, too much animation/dynamics kills an app. I
> couldn't agree more. Usability suffers badly if just about every
> feature you might want to use is hidden behind some slide effect or
> fading transition or menu popup.
> 
> #2. I don't agree with what you, Thomas, wrote in your other email
> about the time required for displaying an animation not bothering
> users: It does bother *me* if something I want my computer to do
> doesn't get done right away because some stupid animation has to be
> shown first (logout sounds are a prime example for such a completely
> useless holdup).
I was specifically NOT talking about "Look what we can doooooo" glimpse, but 
transitional animations, i.e. a timeframe of 80 - 120 ms.
(The logout sound lasts 7.76 seconds, that's a factor of 64 - 97!)

You need /very/ good reactions to outperform this, especially when you're 
required to react (ie. eg. handle or even just recognize the mouse pointer) 
anyway.

For a little self experiment, Bespin uses a /150ms/ animation on button 
hovering (in, out takes 300ms) - in case you happen to have installed it, just 
try yourself.

> #3. I really don't like music players (or other apps, for that matter)
> that show different information at the same spot in turns, making use
> of the oh-so-cool-sounding "4th dimension".
> Usually either I don't care at all (-> see #4), or I want to see all of it 
(say, artist,> title, album, ...) at once. In the second case

No need to insult poor time, i cannot defend itself ;-)
Seriously: the use of layes and timedynamics is not done for fun but the 
limits of screenspace and the human brain.
If there's more information than you can make visible on screen or the user 
can handle w/o feeling cluttered, you'll have to look out for ways to organice 
it.
I agree in that I often don't care too much about the current song info -as I 
know it anyway- but one of amarok's approaches is (was?) to bring music into 
context and a context requires a link, so you will happen to display something 
and if the available space doesn't allow you to display (in this case) title, 
artist and album together you bring in a tooltip, popup or a timered stack.
If you've better solutions, I'm sure a lot of ppl. would like to hear =D

> , it's just annoying if I can see only one thing at a time, and surely the 
animation speed will either be too fast, so that I can't read all of it, or 
too slow, so that I have to wait for ages until whatever I'm interested in 
comes up. And even on the off chance that it just perfectly matches my reading 
speed, it'll be completely wrong for you.
That's not entirely true as the acceptable speed is usually not determined by 
your reading skills (unless you're incredibly slow) but rather your taste for 
calmness.
Anything below 3 or 4 seconds can be assumed to be annoying.
Now if one picked a 5 second stillness you'd have to wait 10 seconds in this 
and worst case (two iterations, third is what you want to see) or 11 to read 
everything.
I can however not decide whether this is too much.

> #4. Performance. 
This is the most valid argument.

First off: your amarok CPU abuse is likely triggered by the gstreamer phonon 
backend.
I don't want to start a flame and this is explicitly MHO, but gstreamer is the 
worst stuff (besides pulseaudio...) i've ever kicked from my box so far.
Xine and MPlayer are /much/ more performant (i've tried songbird, suffers from 
similar cpu drain, even if minimized) and the xine phonon backend (haven't 
tried the mplayer one for a longer time and then it was alpha) sounds *by far* 
better than the gstreamer one. Period.
So if you use gstreamer, my suggestion was to get rid of it. Amarok plus Xine 
don't ever use more than 3% cpu even on my old XP1800 (1522 MHz) (similar to 
plain xine, mplayer beats them all =D)

Second: frankly, that's a matter of implementation.
If the window is unmapped the painting should in best case consume excatly 
/NO/ cpu cycles 
(Permanent animations can be stopped, you get an event on the unmap. This 
should be done if the repaint does much more than just using some simple 
QPainter calls)

As you mention that amarok apparently already has flaws in this regard (though 
i blame gstreamer), the 4-6 frames (on limited space) in 5 seconds an auto 
animation adds (given you don't run an analyzer) won't kill you at all.

Instead one should profile and walk through the code and check for the 
performance lacks (e.g. a transparent itemview causes more cpu usage on 
repaints than a solid one, any alphachannel containing element is bad if you 
don't have usable xrender support, because the default X11 SW fallbabck is... 
improvable.

Btw: there's a video widgetoid - i've never used it but it seems amarok plays 
videos ;-P

Kind Regards,
Thomas