Concep 0.5, mockup #1
Jakob Kummerow
jakob.kummerow at googlemail.com
Mon Oct 26 22:06:02 CET 2009
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).
This is especially important if you use some function very often:
while you might find the animation cool the first three times you see
it, and accept having to watch it the next couple of days, you'll
surely get sick of it when it slows down your workflow for the 100th
time. If you know exactly what'll happen because you've done it
umpteen times before, you don't need any time to adjust to the new
dialog popping up or whatever.
(It's a slightly different situation if, say, a context menu smoothly
fades out *after* you've clicked whatever you wanted to click.)
#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, 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.
#4. Performance. Sure, people's computers are fast these days. Mostly.
But some of us have laptops, which maybe aren't quite as fast because
they're not exactly brand new. And some of us use our laptops while on
the road, where there are no power outlets, and one battery charge has
to last as long as possible. And, most importantly: Amarok is just a
music player! It's not a 3D game, it's not a processor benchmark, it
doesn't even show videos. Which means, most of the time it just sits
there and plays its music, be it with a (partly) visible window or
minimized, while the user concentrates on something else. So, despite
there being Core i7's with four cores, hyper threading, turbo boost
and three-channel RAM on sale, Amarok should still consume the lowest
possible amount of system resources (without sacrificing core
functionality, of course).
To support this with some numbers: for playing mp3s, mplayer only
needs 2% of a Pentium M running at 800MHz while on batteries. When
Amarok has a bad day, even if it's minimized to the tray it still uses
20% of one of the cores of a Core 2 Duo running at 3GHz.
To sum it up: I quite like the cleanness of your design concepts, and
I sure love some eye candy, but (a) hiding things may look good, but
impedes usability, and (b) watch out for that resource usage! So,
please don't overdo it, but look for a compromise.
Jakob
More information about the Amarok-devel
mailing list