[PATCH] Animations enable/disable system wide
Aaron J. Seigo
aseigo at kde.org
Sat Feb 16 20:23:50 GMT 2008
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
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
* 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
* 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...
Size: 194 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel