'Re: kcontrol'

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

List:       kde-usability
Subject:    Re: kcontrol
From:       Frans Englich <frans.englich () telia ! com>
Date:       2004-07-26 2:51:50
Message-ID: 200407260251.50738.frans.englich () telia ! com
[Download RAW message or body]

On Monday 26 July 2004 01:54, Benjamin Meyer wrote:
> Rather than being just another complainer person who says "KControl sucks
> and needs to be better" with nothing constructive to add, I have put
> together some things first.
>
> Based somewhat on the already constructed changes by this mailinglist
> contained in kdebase/kcontrol/TODO I have written up first a doc specifying
> the basic grouping along with explanations of what/why.  This type of doc
> never seemed to have existed before which is part of the problem for the
> constant kcontrol changes in the past 7 years (as far back as I know)
>
> http://www.csh.rit.edu/~benjamin/kcontrol4/kcontrol4.html
>
> At the same time I played using QtDesigner and a little code and made a
> mockup application:
> http://www.csh.rit.edu/~benjamin/kcontrol4/screenshots/mockup.png
>
> Then I actually sat down and fleshed it out quite a bit more to the point
> where it does actually load the kcontrol modules on your system.
>
> http://www.csh.rit.edu/~benjamin/kcontrol4/screenshots/
> http://www.csh.rit.edu/~benjamin/kcontrol4/kcontrol4.tar.bz2

Hey, that name is already taken! kdenonbeta/kcontrol4

My KControl is visually/usability wise close to your version. You'll need the 
branch new_kcm_code of kdelibs/kutils to make it compile(it uses the 
conditional module loading among other things).

Attached kcontrol4_discussion discusses the benefits of my kcontrol. It was 
ment as a blog entry, some parts of it(even if I've cutted) concerns future 
stuff. Care about the parts which makes sense to you :)

Why don't you commit your version in kdenonbeta/kcontrol5? (this is crazy..)

FYI, there exist 4(four) different KControls:
kdebase/kcontrol
kdenonbeta/kcontrol3 -- by Benoit Walter, derived from kdebase/kcontrol
kdenonbeta/kcontrol4 -- by me, (written from scratch)
kdenonbeta/kcontrol5 -- if your version ends up there

>
> You can compile it yourself and check it out.  It works just enough to play
> with the system, but probably wouldn't take much more to finish it off.
>
> I guess the work I have done present two things:
>
> 1) A (sort of) formal doc that can be used explaining where modules go.  As
> far as I know know one has bothered to write up something like this.  Feel
> free to point me out as wrong. (no, mailing list archives don't count)

There is:
http://developer.kde.org/documentation/standards/kde/kcontrol_style/index.html

Which among having much generic stuff, also tries to do what your 1) do. I 
think its "validness" was postponed for KDE 4. 

Those KCM guidelines I plan to to replace with the "KDE Usability Articles" 
project[1] combined with a KUA discussing KControl. In short, the KUA project 
is a platform for documenting applications designs(like kcontrol) among other 
things. The web site framework will be committed in a couple of days(perhaps 
tonight).

I also wrote a doc similar to yours(see attached kua11) which is just one or 
two thoughts, and the attached "email_discussion" is a draft email for the 
same subject -- the purpose/goal is exactly of your 1) and tries to address 
the same things(as the KCM Guidelines also do)

1.
http://lists.kde.org/?l=kde-usability&m=108939865814380&w=2

>
> 2) A different way of looking at kcontrol.  Someone said it looks like
> something from winXP, but if so that was not intensional and entirely
> accidental.

Oh, mine looks the same -- I thought I accidently designed the way Mac OSX had 
it :)

>
> -Benjamin Meyer
>
> P.S.  When seeing the modules icon's at 64x64 some of the icons really
> don't make much sense in relation with the module.

In the formal document we will produce, the selection of icons for categories 
will of course be taken care of.

I think:

* Merging your document, kdebase/kcontrol/TODO, the KCM Guidelines, the ones I 
have attached, the suggestions from this list, and then some corrections -- 
and the resulting will be great. (to be part of the KUA project, if that's 
suitable)

* From my POV, conceptually merging your kcontrol and mine will make a killer 
KControl.

I will have to read your code/texts before making actual comments on this. I 
just wanted to get my work out so we don't clash even further.

			Frans

PS. The attached stuff is very alpha and just drifting rambling thoughts. 

["kua11" (text/plain)]

Name: KUA11 KControl's Categories

Description: Explains the rationalis behind KControl's categories.

Observe, the content, does not reflect the current state, but the plans for KDE 4.

KControl uses a traditional way of organising functionality; instead of showing a \
long list of all available functionality, it is grouped into categories. Instead of \
having the user iterate through a single list for finding the requested \
functionality, the navigation is performed by first selecting a category. As a \
result, the selection and phrasing of categories, and the organisation of the \
modules, affects the navigation substantially and must thus be done with great care. \
Since all users, regardless of what they are looking for, must intercept and \
interpret the categories, it is of interest keeping the categories fast to read, as \
well as having as low amount as possible. Obviously, not to the extent their content \
becomes crowded. To the contrary of older versions of KControl, only one level of \
categories is allowed. The existence, and need of multiple levels, is a sign of how \
absurd the amount of configuration options was, and its usability inefficiency. \
Eventually, at some point in the future, no categories will exist at all.

KControl is not a dumping place for configuration options in general, it provides \
configuration functionality which affects the computer on a global, central level. \
Thus, a module can not represent an individual programs's settings. Of course, from \
an implementation perspective the module may well affect an individual component's or \
program's settings, but the implementation details are irrelevant since it is not the \
user's, but the developer's, view.

KControl have, except for regular configuration modules, administrator modules, which \
allows more intrusive changes when the user have entered the administrator password. \
Under what categories administration modules are placed have absolutely nothing to do \
with their technical nature. If a module need administrator privileges is a \
technical, system dependent, aspect the user does not know about, and does not want \
to know about. Organising KControl on whether modules need system administration or \
not, will make the user's navigation fail, since it does not correspond to the user's \
knowledge and expectations. Thus, it is not obvious an administration module should \
be placed under "System".

Do not add any KControl modules without consulting the KDE developer community first. \
Remember, new modules affect the whole of KControl, not only the module itself, and \
must thus be coordinated with the rest of KControl's development. Having a module \
peer reviewed will also ensure a good selection of name and category - aspects not \
always obvious.

Entries in the former "Peripherals" and "Power Control" have either been removed or \
                transfered to the new "Hardware". Because:
* The word "Hardware" is broader and cover more devices than peripherals. Thus, \
multiple hardware categories is not necessary. Furthermore, "Hardware" is more \
                common, and not as technical and clinical as "Peripherals".
* With the new conditional-module-loading code in KDE 3.3, and later restructurings, \
the amount of modules for the mentioned categories was reduced, and thus two \
categories unnecessary.

"Web Browsing" in "Internet & Security" and "Spell Checker" in "KDE Components" was \
                removed since:
* Their content is not percepted as being global but program specific. For example, \
the user is unaware of KHtml is a generic component and associates its behavior with \
Konqueror or whatever program it is used in. When, as a developer, being aware of \
                KDE's high integration, it is easy believed the user shares the \
                insight.
* They were duplicated by being available where they were used. For example, all \
programs which have spell checking have the configuration available in one of their \
                menus.
* The need for accessing their content(to configure) araises in the respective \
programs the components are used. When it is possible to place functionality close to \
the user, it should of course be done. Applications using the components, which \
configuration modules not any longer available in KControl, should load the needed \
modules in their configuration dialog.

Former "KDE Components" was removed because it assumes the user distinguishes between \
KDE and other system components, an idea far from the actual circumstances. Its \
content was either removed or moved to "System".

"System Administration" was renamed to "System". No need to state the obvious, as \
well as increased interpretation speed.

* Hardware
Contains elements the user percepts as engaging directly with the hardware. For \
example, "Monitor" could be placed under "System" since it actually means configuring \
the X Windows system, but the user associates a monitor with hardware, and percept \
the configuration of the monitor as affecting the actual monitor, not the underlying \
system component(which the user does not know anything about).

* System
Contains elements the user associates to directly concern the actual computer - the \
system. 

["kcontrol4_discussion" (text/plain)]

While not being in any way a representant, I thought it could be suitable ventilating \
the current development on KControl.

Widespread, opinions something needs to be done with KControl, can be found, be it \
from distributors, developers or users. Roughly the feedback can be divided in two \
parts; The actual content, the categories and modules, and the program, KControl, \
which presents it. Lets see what is happening in these two fields, starting with the \
former.

As requested, an attempt at an improved KControl is done by systematically discussing \
its categories - what wording, icons and their content. What have been agreed upon, \
and will be committed in KDE 4, is documented in KUA11 TODO. Of course, as the draft \
state implies, nothing is set in stone, and will most likely be further changed(read \
on for how to give feedback).

A nifty feature called conditional module loading(CML), allowing if a module should \
be shown be determined by code, will help reduce the amount of modules and keep the \
content relevant. The support for this is in the core libraries(kutils), and the \
laptop and xinerama modules is ported to the new interface. However, KControl is not \
supporting CML due to its implementation(and never will, AFAIK). Related to \
organizing modules, a new class called KCModuleContainer(kutils, HEAD), which groups \
several modules into one, support CML and is used for the monitor module, meaning \
xinerama is dynamically loaded. The API documentation explains the class further.

As I see it, a couple of categories will be removed, the amount of modules will \
significantly drop and, as many distributors already have done, KInfoCenter will be \
removed. All changes will be done in accordance with the relevant KDE Usability \
Articles.

On the KControl programs(notice the s :) front, it is suitable described as, \
configurable. First of all, there is the ordinary KControl which most likely will be \
replaced, then there's Benoit Walter's KControl residing in kdenonbeta/kcontrol3, and \
my version, residing in kdenonbeta/kcontrol4. I, obviously, prefer another approach \
than Benoit, so I will leave the explanation of his version up to him, and take this \
opportunity to rant about my version.

My version(KControl4) is written from scratch, resulting in various technical \
                benefits:
* It uses a UI files instead of hand crafted GUI
* KConfigXT
* It takes advantage of the latest refactoring in the kutils library, meaning clean \
                code and supporting conditional module loading.
* It's lines-of-code count is 650, compared to the current KControl's 5000. KControl \
is large and complex with tons of dead code paths, and have experienced several large \
changes. It needed a rewrite.

In other words, it is easily changed(such as the GUI), and is small and efficient. \
Startup time should also be faster, although it is not noticable on my machine, I \
think.

However, the most interesting is its GUI and how it compares to the current KControl. \
Afterall, this is the sole reason we will change KControl.

As the screenshot LINK TODO shows, the layout reminds much of Mac OSX(if I remember \
correctly). The navigation is simple - a category is selected above and its content \
is shown below, as the first startup tells. Modules are shown as standard \
configuration dialogs. The search is instant, as Benoit's version.

In my eyes, this is its usability advantages:
* Its navigation is not hidden and stays as static as possible. This has the usual \
advantages of being not confusing, consistent, giving a feeling of assurance, and is \
                easily learned. Dynamic interfaces are evil. TODO
* Several configuration modules can be opened simultaneously(as Lycoris' CEO \
                requested).
* The main window can be closed while individual modules are open.
* It allows only one level of categories. Yes, this is a feature. KUA TODO discusses \
                this in detail.
* With its simple main window, it is small. It easily obeys the KDE UI Guidelines \
                paragraph on 800x600 resolution conformance, and does thus benefit \
                the general case.
* It uses large icons  - Fitts's law.
* It uses basic widgets - consistency.

Furthermore, some small features:
* It remembers the previously selected category(as the LindowsOS' kcontrol fork does)
* It have session support(restores modules) TODO
* Obvious failsafe check: brings focus on the module if it's already shown.
* It contains few texts meaning it is fast to use and easily learned. However, it can \
well be the opposite(of course) for the same reason, but I think its usage is self \
explaining and obvious. However, it wouldn't surprise me if it turned out they are \
needed. They are easily added anyway. Perhaps Relevantive, or a similar group, can \
give KDE 4 Alpha a test run, and focus on the various KControls, and their \
                weaknesses.
* It authorizes modules
* Installed/altered modules is detected.

Is there any feature regressions compared to other KControls?

I find the design good. It is just as complex it needs to be, and its simpleness \
makes it beautiful. CrystalSVG icons looks great in large resolution. Since no custom \
widgets and the like are used, its "fancyness" evolves with icon themes, widget \
themes, and X server development(which are the places where eye candy belongs).

Choosing what KControl to use can be a though matter, but on the other hand, it is \
easily solved by shipping them all. Or the other usual solution: make it \
configurable.

All of these major changes will first be done in KDE 4. Major versions is the \
opportunity to make intrusive usability changes, so if one wants to affect, this is \
the right time to "catch the train". Send a mail to kde-usability with your ideas(in \
a short and concise manner..). TODO <-- good idea? Distributors know how difficult it \
is to affect KDE development, especially on the usability front. I think we(the KDE \
developers) gets somewhere in our discussions in a robust way, and I would gladly \
speak for distributors' wishes, small as big, in this matter, staying with it the \
whole "washing program".

No matter what, in all its respects, I think the result will turn out fine. We are \
advancing in a stable manner with steady documentation, we have plenty of time, \
plenty of alternatives and a big interest.

Frans Englich
frans.englich@telia.com

***

Visst �r det frustrerande n�r folk inte g�r som de s�ger?

Om du inte vill r�ka ut f�r �nnu en s�n h�r upplevelse s� finns det mycket du kan \
g�ra. Om n�gon installerar ett n�tverk hemma hos dig s� kan du ge en symbolisk g�va \
som tack, du kan fixa TV:n, dammsugaren, tv�ttst�llet eller n�got annat underh�ll som \
dina hyresg�ster ber dig som hyresv�rd att g�ra. Att skippa skrattretande \
motiveringar f�r ockerhyror �r ocks� ett utm�rkt s�tt. Du f�rst�r Svein, som man \
b�ddar f�r man ligga. Jag kan naturligtvis s�tta dina handlingar i ett moraliskt och \
humanistiskt perspektiv men det �r v�l �nd� nog meningsl�st med tanke p� att du har \
inga problem att med en �l i din hand titta p� medan n�gon annan tv�ttar din bil \
eller l�ta ditt hus st�das f�r 25 kronor timmen. Du beh�ver inte bry dig ett dugg om \
dina medm�nniskor och g�ra handlingar som gynnar dem �nd� - d� ser inte folk ner p� \
dig s� mycket.

Kom igen, Svein. F�rs�k g�ra livet surt f�r mig. Sk�nk mig gl�dje genom l�ta mig se \
dig springa efter mig.

Med tanke p� hur mycket det kostar att f� en n�tverksinstallation gjord av ett \
f�retag och hur m�nga sommarm�nader jag bott h�r s� kan du alltid sitta och knepa p� \
om du i det stora hela g�r med ekonomisk f�rlust. T�nk om du hade letat efter en ny \
hyresg�st n�r jag sa att jag flyttade ut - d� hade det varit storvinst! Attan. Som du \
sj�lv sa, "d� kommer jag efter dig". G�r det. Fundera �ver hur mycket jag igentligen \
vet om vad som �r fr�n ett lag m�ssigt perspektiv tvivelaktigt hos dig. Det vore ju \
dumt om du ocks� fick problem. Du fattar ju inte detta sj�lv utan m�ste prata med din \
advokat, det konstaterade du riktigt nog sj�lv. � andra sidan, du �r den typen som \
inte har n�gra st�rre problem med att s�tta dit den lilla studentarj�vel bara f�r sak \
skull - det beh�vs inga rationella anledningar. V�ga inte ens fundera, min �r st�rre \
�n din.

S� vad h�nder nu?
Till en b�rjan tycker jag du ska ta en tur i din feta Chrysler, jag hoppas den �r \
h�rlig och du k�nner hur m�ktig du �r, det �r trotsallt jag som har betalat den. \
Sedan kan du ju alltid g� och kl�mma p� din halv neurotiska fru och fr�ga om hon inte \
ska ha �nnu en till M� Bra tidning f�r att uppskattas av dig.

Om ni beh�ver en jultomte s� vet ni vem ni ska ringa!

Med V�nliga H�lsningar,
Frans Englich
epost: frans.englich@telia.com

*****

["kcontrol" (text/plain)]

* Select icons for the categories, perhaps having as axiom to pick icon for the most \
common module(for example, if users usually looks for the printer module in the \
Hardware category, the printer icon should be used). We will have to wait discussing \
this until the categories and their content have settled down.

* A though problem is the two ambivalence residing between:

  -) "Security & Privacy" and TODO. This is some mixture between computer security, \
privacy, personalisation and the user's "profile". In either way, we most likely need \
two categories.

  -) "Look & Feel" and "Desktop". What is behavior and what is look & feel? Isn't \
Sound Notifications behavior? Yes, it is also sound, but why is it not better placed \
under a "Behavior" category?(I'm not saying it is) This is a big mess. A user test \
could perhaps help telling how the user associates.

* "Sound & Multimedia". Much of this begs for selecting sane defaults and move out to \
KConfigXT. "System Bell" removed since it is duplicate settings(see Accessibility). \
Sound Notifications moved to a "Behavior" category, "Sound System" renamed to "Sound" \
and moved to "System". Fix the others, and remove the category. Something in that \
direction?

* "Internet & Security". The Web Browser category will be removed(or rather, not \
available in KControl). "Preferences" moved out to KConfigXT.

* Read the rationalis in KUA11 about what the category "System"(and for example \
Hardware) should contain. Should the Login Manager really be in System, not an \
"Appearance" or "Look" category?

_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability

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