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

List:       kfm-devel
Subject:    PLEASE READ: KControl-Guidelines
From:       Torsten Rahn <torsten () kde ! org>
Date:       2001-03-30 12:21:40
[Download RAW message or body]

As KDE2.x becomes more and more complex it becomes more difficult to avoid 
that KControl turns into a Graphical Registry.

To improve this situation I put together some guidelines and tips which make 
it easier to create good dialogs.

Everyone who changes something in the KControl-Modules: 
It's important that you take the five minutes to read this stuff!
It's only five minutes of your time and it will help a lot to get a 
KControl which is easier to use!

Thanks for your attention.

Tackat

PS: I will post this every two weeks as a reminder in an updated version. If 
you feel that there's something missing then send me an e-mail and I will add 
your suggestion.

===========================================================

Guidelines for Creating KControl Modules.
===============================

As KDE2.x becomes more and more complex it becomes more difficult to avoid 
that KControl turns into a Graphical Registry.

Our biggest enemy is what I call the "cockpit-dilemma" which keeps especially 
newbies from using our software:

- If people think of the cockpit of a plane then they imagine dozens of 
controls spread all over the control-panel. Of course only advanced users 
(i.e. the pilot)  can "easily" control such a crowded-looking system because 
they know where each control is and what it does. 

- machines which are designed for the common user (washing machines, tv-sets 
etc.) are usually kept more simple: there is a low number of buttons for the 
most common tasks exposed on the front of the machine ("start, stop, 
channel/program #1, #2, etc. ..").
To still allow advanced actions (like changing frequencies per channel e.g.) 
these settings can be controlled in a more hidden place (on the back of the 
machine or behind a tiny semitransparent/labeled door on the front of the 
machine).

While the cockpit-solution can be used very fast by the advanced user it 
guarantees a horrible experience for the newbie: Most people who are not very 
used to computers will react in one way when seeing such a cockpit-dialog:
"It looks complicated. I don't understand it. I'm too stupid. I can't work 
with this.".

To avoid that people react this way we have to follow the second approach:
The user has to be _GUIDED_ by the dialog and it must be possible to _EXPLORE_
the possibilities of configuration step by step:

Tips:
====

*** Group your items in groupboxes. Arrange your items / groupboxes in a way 
that looks *simple*.

Remember: In many cultures people read from left to rigth and from top to the 
bottom. (For cultures where the situation is different the toolkit has to 
make sure that things are arranged in a proper way ....).
This means that settings on the bottom shouldn't affect settings on the top
of the page.
Also keep in mind that groupboxes inside groupboxes are bad style.


*** the number of items/groupboxes should be kept low.

How many I's can be seen here:
IIIIIIIIIIIIIIIIIIIII
As you can see it's not easy to "get" the situation unless these items are 
being arranged in a different way:
IIII IIII IIII IIII IIII I
It's very easy for the human brain to deal with up to 4 items so try not to 
use more than four groupboxes on one dialog-page. Inside this groupbox the 
number of items should also be kept as low as possible (ideally 3-4). Larger 
numbers of items can't be counted easily and don't look very simple.

*** More advanced options should be hidden!

The most important settings should be very easy to find.
Less important or more special items can be "hidden" on different pages. That 
way the user can "explore" the situation step by step.
Usually newbies have much more basic needs. Therefore it is necessary to
put more important settings in more prominent places. Once the user gets more
advanced he will have more specific needs. Such users are able to find the 
settings even if they are being "hidden". This way the user can "explore" the 
interface.

- Tabs: The tab with the most general stuff should be put on the first (left) 
tab.
Other stuff should be grouped by topic from the left to the right in 
decreasing importancy. Don't use Tabs inside Tabs (bad style)!

- "Customize"-button: A small number of settings which are probably
changed only very seldomly ("finetuning") should go into a dialog which pops 
up when pressing a button ("Customize", "Tuning", "Advanced").
Such buttons should only contain one word.

*** The whole kcontrol dialog should fit on a 800x600 screen using 
default-settings _without_ using scrollbars.

Therefore:
- Don't use scrollbars
- Make sure that textstrings are as short as possible and still easy to 
understand.

Making the textstrings short is important to make sure that the dialogs look 
good in every language.

If you use a word over and over again in a groupbox (like "Add" or "Setup") 
then there's probably something wrong: Mentioning them once on the whole 
dialog should be enough: Often you can do this by changing the Subject of the 
Groupbox in a way that already implies these terms instead. In most cases 
terms like "setup" or "configure" are redundant as "configuring" or "setting 
up" is what kcontrol is about anyways.







 

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