An attempt at solving KControl's usability problems..

[Frans Englich]

On Sunday 25 January 2004 20:43, Scott Wheeler wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Just a note indicating that I'm going seek out and flog anyone that decides
> to reorganize KControl again in the 3.x series.  Figure out what you want
> to do; plan on that for KDE 4.  But if we end up with the yet another
> KControl reorganization in the 3.x series (it would be the 3rd), well, it's
> time for violence.  ;-)

Hehe :)) Working /remote/ has some bizarre advantages ;-)

> Remember that an important part of "usability" is not confusing the hell
> out of all of your users every time they update.

Yes, it is hard to find anyone who denies that. Fortunately, my proposal 
doesn't touch kcontrol's usability issues explicitly - it mostly means code 
reorganization, documenting things and in general "steering" things up, with 
the goal to ease maintenance, erase bugs and put a roof on the never ending 
discussions on kde-usability.. If the kcms were looked over, converted to 
KConfigXT and .ui, that would be a big thing.
But, except those organizational changes there's also changes to the ui 
proposed - the actual guidelines themselves and the ideas in the TODO. IMO, 
most of it, such as choosing terms consistenly and simplify them, is not of 
such a magnitude it puts the user's familiarity with KControl at risk.

Which is of course only is possible if it existed. KControl is so incredible 
big and fuzzy organized I simply don't think it is possible building a mental 
model of where things is located(among other things). Besides, it shouldn't 
be needed - when a categorization is correctly done you don't need to know 
how it worked before, to "learn", to remember - navigating is obvious and 
"streamlined" since the user's associations "hits", to name one thing. To put 
it roughly, we have nothing to loose and this consistency is OK to break 
since discussing consistency is in this case a wrong way of solving the 
problem. (Navigation in KControl should not be built on conventional 
decision's(which namely heavily relies consistency) but on "intuitiveness").

In either case, at least I haven't planned anything which I would classify as 
major reorganization. But for KDE's sake, and not my own health, I suggest 
you keep something big and physical at hand, in case things escalate.

Also, it is really hard to find one single developer or reviewer who does not 
puke over KControl, it has serious problems - if someone tried and even 
succeeded solving it, it would be applauded, I think. It is apparently not an 
easy task, it takes time and it must be ok to try, KControl is afterall under 
development and it must be possible to develop.
KDE's userbase will grow exponentially a lot of people would say, so I think 
it's better if big changes occur as early as possible(which also could be an 
argument for BC changes - pushing for KDE4).
But I would gladly see someone elaborate, and correct me on the art of making 
invasive changes in cases like KDE.

Those who write long letters usually foolish reward people who have read to 
the end, they should be slapped instead.


			Frans