'Re: Single vs Multi Window KControl'

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

List:       kde-usability
Subject:    Re: Single vs Multi Window KControl
From:       Charles de Miramon <cmiramon () kde-france ! org>
Date:       2004-08-26 16:27:04
Message-ID: 200408261827.05414.cmiramon () kde-france ! org
[Download RAW message or body]

Le mercredi 25 Août 2004 14:27, Aaron Seigo a écrit :

To sum up a little bit the discussion about KControl and KDE 4. That is what I 
understand of Aaron's ideas, my own thoughts and the general consensus on the 
list as I understand it.

What we have already agreed on :
--------------------------------------

- Move the different options to KConfig XT for multiple technical reasons
- Access the options or group of options through a specialized shell (KControl 
revamped) that will provide a search and browsing interface, displaying of 
help, etc. That rules out the different project to create WindowsXP like 
control centers. 
- The main interface for finding options should be a search window. Browsing 
through modules is an alternative (today it is the opposite)

My propositions :
-------------------

My own little ideas put a lot of emphasis on keywords ...

Putting help nearer to the configuration options :
------------------------------------------------------

What I meant by that is Benoît Walter did in Kcontrol3 :
http://www.avenheim.online.fr/kcontrol3/kcm_font.png
	- The title of the configuration modules is better emphasized
	- The short help for a configuration module is always visible, not a tab away
	- The whatsthis method is reimplemented so that it appears not as a tooltip 
but in a small always on panel

Improving the keyword system :
------------------------------------

The limitations of the actual keyword system can be seen on this screen
http://www.avenheim.online.fr/kcontrol3/search.png
Keywords are attached to modules. When a user searches for a keyword, Kcontrol 
sends back a list of modules with this keyword sorted alphabetically. 
	Problems
		- The most relevant modules are not necessarily at the top of the result
		- The keyword does not necessarily applies for the entire module but for a 
subset of it. Mouse cursor is a a good example

	Proposed solutions :
		- Keywords are not attached to modules but to options, group of options, or 
modules. For example, the keyword Mouse is attached to the module Mouse but 
Mouse Cursor to the group of options related to Cursor style. When the user 
click to the result, KControl is intelligent enough not only to open the 
correct module but to jump to the correct group of options. This idea goes in 
the same direction that Aaron's breaking of KCM in individual unities.
		- We add to each couple keyword / option(s) a relevance number. The more 
relevant the link between the option and the keyword the bigger the number 
and we use the number to sort search results. For example, if you search for 
the keyword mouse, the Mouse module will appear at the top and subsidiary 
options (launchback and accesibility) below

Adding simple wizards for common newbie tasks :
--------------------------------------------------------

My idea of wizards is that they will be accessible through the keyword search 
system and will be added for tasks we believe are the most usual one for 
non-geek user. For example attached to the keyword mouse we could imagine 3 
common tasks :
- Switching to simple click / double click
- Interverting buttons for left handed people
- Making the cursor bigger and the mouse movement slower for old people

The wizards will have high relevance number and will appear at the top of the 
search result.

Why keywords are better that full text indexing of the documentation :
--------------------------------------------------------------------------------

Full text indexing is great and complementary to this solution but a more 
manual system (keyword, relevance number) gives us much more control to how 
we present the results to the user and limit the noise ratio. I think 
keywords work well for a circumscribed body of knowledge. Full text is much 
better when the body grows in unexpected directions (like the web).
Another problem of full text indexing is that we don't have to my knowledge a 
working indexer integrated in KDE and fully Unicode. It is not trivial to 
make one.

To sum up :
-------------
With this improved keyword system, if the user search or browse to the keyword 
"Mouse cursor" , he willl get the result :

- Make the cursor bigger and the mouse movement slower [Wizard, relevance 95]
- Mouse settings > Mouse cursor style [Subset of module, relevance 85]
- Application Launch feedback > Mouse cursor [Subset of module, relevance 70]

If he searches for Mouse, he will get the result

-  Switching to simple click / double click [Wizard, relevance 98]
- Interverting buttons for left handed people [Wizard, relevance 97]
- Making the cursor bigger and the mouse movement slower for old people 
[Wizard, relevance 95]
- Mouse settings [Module, relevance 90]
- Windows behavior>Action tab [Subset of module, relevance 80]
- Style>Toolbar [Subset of module, relevance 70]
- Application Launch Feedback>Mouse cursor [Subset of module, relevance 40]
- Accessability>Mouse accessability options [Subset of module, relevance 30]

etc.

Cheers,
Charles 
-- 
cmiramon@kde-france.org
http://www.kde-france.org
_______________________________________________
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] 