An attempt at solving KControl's usability problems..
frans.englich at telia.com
Mon Jan 26 23:19:58 GMT 2004
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.
More information about the kde-core-devel