Why incremental UI changes are the way to go

[Nikolaj Hald Nielsen]

While I generally agree with these points (How can I not, I am always
the big proponent of agile methodology) I think this line of reasoning
misses 2 key points.

1. What is a "radical" change in terms of the look and feel? What we
define as a big change in this regards is not automatically the same
as what a user will see as a big change. For instance, I really like
leeo's recent mockups, and while these in terms of code are not that
big of a job (I think) the effect they have on the look of Amarok is
huge. So should we choose to go that route, the version where that is
brought into effect will seem like a huge change to the user.

Which leads me to

2. Markey argues that we should keep using a 6 week (or short in
general) and then use version numbers solely as a marketing tool. I
have no issues with the first part of this but I really think that
unless we actually have something that fells significant to show off
once we decided that it is tie for 2.3, the version number bump will
feel very hollow and dilute the effect of future bumps in the .x
version.

So, if what i was saying on irc was interpreted as meaning that we
should do 2.0.0 style loooooong release cycle all over again... then I
have not made myself very clear. What I proposed was simply to start a
branch for experimenting with improving the look of Amarok. Some
things form this branch might well be merged into minor versions, and
some might actually warrant a bump to version 2.3 if it looks
significantly different, even if the actual changes require to reach
that look are not that big.

So, I will repeat what started this entire discussion. I think I am
going to start a branch to see how much work is actually required to
implement leeo's mockups. My guess is really not that much on the code
side, even if it will require some svg work.

- Nikolaj


On Sat, Oct 31, 2009 at 1:07 PM, Mark Kretschmann <kretschmann at kde.org> wrote:
> Heya,
>
> so Nikolaj and I just had a little discussion on IRC. The gist was: Is
> it better to make a radical change of the UI (Look-And-Feel), or do it
> incrementally, in smaller steps? Let me explain to you again (I'd
> voiced it on IRC when not everyone was there) why I think that
> incremental changes are better:
>
>
> * We make mistakes. Lots of them. Everybody does so in fact - that's
> why you learn by trial and error. Especially with design things we are
> sometimes convinced that "this is it", only to realize a while later
> that it wasn't so great after all. It has happened many times
> (toolbar...), and often you can only judge something after having it
> out in the wild.
>
> * Given that we are prone to making mistakes, it would make us look
> pretty stupid indeed if we created a radical new GUI, only to change
> it completely again in the next release.
>
> * Our resources are limited. We can can only handle doing a certain
> amount of changes properly. The bigger the changes are, the more work
> and resources are required, which we simply don't have.
>
> * Incremental changes give the user a chance to get used to them more
> easily. Being confronted with something totally new turns many people
> off (see 1.4 -> 2.0).
>
>
> This is why I advocate an approach like we did it in 2.2.1, where we
> improved the Toolbar and also the Context View (in a minor way). In
> the upcoming releases we can do further improvements in this style.
> Polish a little here, introduce a new look there, etc. I think this
> works really well for everyone involved, and it's much less risky than
> doing it Rambo style (radically) :)
>
> --
> Mark Kretschmann
> Amarok Developer
> www.kde.org - amarok.kde.org
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel
>