[PATCH] Animations enable/disable system wide

[Aaron J. Seigo]

On Saturday 16 February 2008, Richard Hartmann wrote:
> On Feb 16, 2008 4:27 PM, Robert Knight <robertknight at gmail.com> wrote:
> > It is feasible to test all of the main KDE applications against 3 or 4
> > different settings.  If you have checkboxes for each capability then
> > this becomes 2^N different states where N is the number of options.
>
> Well, the same concept worked for KDE3. 

no, it didn't. firstly, we didn't do many things of this nature (complex 
global configurations that needed per-app testing; we had simpler global 
settings and few of them required per app testing ... if you do want an 
example, go around and find all the apps that don't reload all their icons 
properly on icon change in various releases of KDE3).

secondly, KDE3's configuration interfaces were functional but ghastly. let's 
try and avoid recreating that =)

> Don't get me wrong, I am 
> not saying you need a bazillion options. But I would give them
> meaningful names, not assign abstract concepts to them.
>
> > Right.  One thing I learned over the past couple of years is that it
> > is much easier to add options rather than take them out.  This can
> > quickly lead to over-complex user interfaces which make it hard for
> > users to comprehend them and achieve their basic goals.
>
> True. See above for the first part. As to complex interfaces, unless we
> are talking 20+ options, there should be a nice and clean way to group
> and display them.

there's nothing that says they need to be in the UI, especially since this is 
the kind of thing that very, very few people would ever feel the need to 
tweak.

moroever, it's not just about finding a good way to group and display them. 
the question we need to ask is will the users that will most often be in 
front of this interface truly understand what any of them mean or how they 
impact their user experience?

honestly, this is going about it somewhat backwards and we should be asking 
ourselves:

* what are the use cases
* what do these use cases need

we design our APIs like this, why not our UIs as well? so.. i can see three 
major use cases:

* system integrator (perhaps a sys admin or an IT consultant) defining a thin 
client environment

* a user trying to get performance on their low end system

* a developer working on a device configuration

the first group would probably like something in a kiosktool like app; the 
second is probably served just fine by a high level abstraction such as the 
combobox i suggested; the third is probably fine with some documentation and 
a configuration file, bonus points for a kiosktool like app.

so no, i really do not see the need to put N options in the main user 
interface. i do see the need for documentation, though.

do you see further use cases, or needs of the above 3 i've already enumerated?

also, as you seem to have some interest in mobile device, do you have an input 
as to what might be useful there? (honestly, gradients, animations and colour 
depth are the three issues i can see of concern)

> As the options would be hidden behind an advanced 
> option, it should not confuse 'normal' users, either.

this just leads to the same jumbled messes that most of our control panels are 
currently in. no thanks =(

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080216/46fd1004/attachment.sig>