[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: [PATCH] Animations enable/disable system wide
From:       "Richard Hartmann" <richih.mailinglist () gmail ! com>
Date:       2008-02-19 13:55:46
Message-ID: 2d460de70802190555l6d51adebt360ec038a8468d58 () mail ! gmail ! com
[Download RAW message or body]

On Feb 16, 2008 9:23 PM, Aaron J. Seigo <aseigo@kde.org> wrote:


> 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).

True, the only thing with system-wide impact in KDE3 used to be window
decoration, icons and backend stuff like proxy settings. I would say that
with clean application code, this should not mandate too much extra
manual testing, but you two are better suited to judge that.


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

More on that below :)


> 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.

Well, I personally prefer a way to get at advanced stuff via an extra click. I
simply don't know how many people would optimize those settings to the
maximum their local system can handle under the constraints they care
about. But having to revert to config files should, imho, be avoided. While
some pieces of software need text-based end-user configuration (zsh, vim,
screen, ten thousand others), others do not. One thing I like about KDE
is that you can do both basic and advanced tasks without having to leave
the GUI.

I see the risk of falling into the Gnome trap, i.e. giving users only basic
choices and requiring them to surmount a high learning step in order to
do anything else.


> 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?

Grouping would be highly specific to what the options turn out to be.
As to understanding, I am confident that a good explanation can be found for
all options. That is something KDE usually excels at, anyway :)


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

Yes, use cases are the best way to go.


> * 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?

I can see all three above appreciate a simple

  Advanced >>

button that they can click to get into a more detailed view. If you
plan to expose
the options in a fine-grained manner anyway and and agree that docs are needed,
the last step needed is an _additional_ interface for advanced users.


> 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)

I see space constraints for small displays and possibly display update
times (think
epaper) as additional points to keep in mind. If applicable, if
anyhing that does not
have focus wants to do something pretty but not essential, that should
not be done
on small devices, either.


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

What you see as jumbled mess, I see as one of the main strengths of KDE. As it
is hidden by default, it can not hurt _that_ much, imo ;)


Perhaps we shoud poke usability people about this, as well?

Richard
[prev in list] [next in list] [prev in thread] [next in thread]