Human interface guidelines
These are the interface principles followed by segusoLand. Of course
you are free to use them in another application, and to label it
This work is in progress and can change depending on your
Unfortunately these guidelines are not compatible with those of KDE
Do not hide complexity, but make it as apparent as possible (by default)
Things should me made as simple as possible, but no simpler.
If the actions you can do with your program are many, then
using the program is an intrinsically difficult task, and any attempt
to simplify it will be counterproductive. For example, it is bad
to treat the least used action differently (for example by hiding them
in submenus) by default, because
- you create different paradigm to do things; paradigms which
must be all remembered. Learnability decreases dramatically. Few
people will migrate to your program because they must relearn how to
do things, one by one;
- when the user needs to do something uncommon (e.g. play a music 8
hours from now, burn a CD from a cue sheet), he doesn't know where to
- The user may not understand that he can do something uncommon. It
is not apparent what you can do with the program.
- The user may not consider the action to be uncommon;
- therefore, the user may not understand why the action is so
In the case of segusoLand, the possible actions are hundreds (since
they are all the "common" actions you can do with a computer),
nevertheless it would be counterproductive to hide some of them or to
make some of them more difficult to be reached, for the reasons stated
Narrowing menus must be always open
(i.e. they cannot be pop-up)
Narrowing is a feature introduced by segusoLand. A narrowing menu is a
special context-sensitive menu. To say that a menu M does narrowing
means that 1) M is context-sensitive, and 2) when you select or
deselect one item of M, the contents of M and of other menus
Let me restate the difference from a traditional context-sensitive
menu: a context-sensitive menu A updates its content based on the
selection in some list B, but selecting from A does not affect the
content of B. On the other hand, narrowing menus not only are
affected, but also affect.
That said, the reasons why narrowing menus must be always open are:
- The users must frequently change their selection in order to
narrow the visible items in SOME OTHER menu.
Example: Usually, the visible files are many, and you only want to
look at the file panel when they are few. So you start selecting
devices, verbs or programs in order to narrow down the file list. If
the file panel were pop-up, this would be terribly impractical,
because at each new selection you'd have to open the file panel just
to see if the visible files are still too many.
Example: in segusoLand I often select the printer (in the
PRINTER menu) because it hides the nonprintable files (in the FILE
menu). If the printer menu were pop-up, I would need to open it each
time, which would discourage me from using it in order to narrow some
example: expert users will select xmms even if they don't want to
play music, just because they want to see only mp3 files! When you have
located the file you need, you deselect xmms. Imagine what this would
be if you had to open the program menu each time you want to
- Even if our menu is not a narrowing menu, but an ordinary
context-sensitive menu, there are still reasons to let it always open:
since a context-sensitive menu updates itself given the selection of
some other menu, it should be always open because it is good to see
its contents dynamically changing. If the user doesn't see the menu
contents updating dynamically, he may not understand that it is
dynamic. (This often happens when there is a pop-up menu callable with
the right button: the user assumes the pop-up menu is the only
context-sensitive menu, and does not notice that the main menu is too
Also, he wouldn't know when the menu has become sufficiently short
for him to scan it with his eyes.
Example: in segusoLand, the time panel does not do narrowing
(i.e. selecting a time does not hide anything), so it could be
implemented with a pop up menu (a dropdown list for example). But the
verb/file/program/device panels do narrowing, hence they can't be
Usability is not the same as intuitiveness
Many program are usable but not intuitive.
Example: the number of clicks does influence usability but not
always intuitiveness. A long list is just as intuitive as a short one,
but less usable.
Example: The traditional layout of a program, comprising a menu, a
toolbar and a main area, is usable but not intuitive. Arranging the
commands into menu and toolbar is equivalent to sorting them by access
frequency: the most used commands are accessible with a single click,
the least used ones with more than one click. This is usable but not
intuitive because: 1) it creates two ways to do one thing 2) the
newcomer is not interested in sorting the commands for frequency of
access. A cleaner and more uniform layout is better.
The best layout for using a program is usually different from the
best layout for learning it.
Unfortunately, nearly all programs have by default a layout suited for
using them effectively, not for learning it. For example, all programs
which use a toolbar and a menu by default have this fallacy. A user who wants to
learn a program does not want to see actions sorted by
frequency; he does not want to minimize the number of clicks but
maximize uniformity and "cleanliness"; and in general does not want
two ways to do something: he wants uniformity and minimality.
By default, privilege a layout and behavior which is easier to
understand, not easier to use. Privilege uniformity over
Layout: For example, if there are 5 panels in segusoLand, but
one of them is very short, and better left minimized as a dropdown
list, it would be wrong to minimize it by default, because this would
result in two sets of panels with the same semantics but different
aspect. The user might 1) be puzzled about why one of them has a
different aspect, 2) not understand it has the same semantics; and
therefore believe the behavior of the program is more complex than
it really is.
Behavior: One might think to add an AI by default which
selects some items automatically. This would make the program more
usable (fewer clicks) but more complicated to grasp: at each new
click, the newbie is already puzzled enough understanding why some
items have disappeared. We don't want him to be furtherly puzzled
asking himself why some items he did not click on are now highlighted.
The learner does not want to minimize the number of clicks, he
wants a program which is consistent, uniform, logically clean
This is a formalization of what stated above.
A list that is long but flat is more intuitive than a list which
is short but structured.
For example, one might propose to replace the flat verb list with a
tree hierarchy. This would make the program easier to use, but less
intuitive: the list becomes shorter but the selection mechanism becomes
more complex. This must not be done by default, because
intuitiveness is what matters by default, not speed or number of
clicks per action.
Finding a verb in a long list of verbs might not be
funny, but it is more intuitive than traversing a hierarchy where some
elements are categories and the leaf is a verb.
segusoLand does not require double-clicking
Single click mode will always be the default, officially supported way
of using segusoLand. Any interface decision will be taken with this
use in mind.
- Double clicks are unnerving for some persons, and undeniably
difficult to execute for newbies. Not everybody is a pianist.
- Furthermore, having a zone that can be both clicked and double
clicked is a bad habit, because this means assigning two semantics to
a single syntactic element, which is of course a bad thing because it
is not intuitive. For example, it is usual that a zone can be both
selected (single click) and executed (double click). This is bad
because you are assigning two distinct semantics (select/execute) to a
single syntactic element (the clickable area).
Solution: Fortunately, every application that requires
double clicks can be transformed into a single-click application by
duplicating the clickable area.
segusoLand does not require the use of more than one mouse
Single-button mode will always be the default, officially supported
way of using segusoLand. Any interface decision will be taken with
this use in mind.
- alternating the mouse button is unnerving for some persons, and
undeniably difficult to execute for newbies. Not everybody is a
- Furthermore, having a zone that can be both right-clicked and
left-clicked is a bad habit, because this means assigning two
semantics to a single syntactic element, which is of course a bad
thing because it is not intuitive. For example, it is usual that you
can both left-click a file, and ask for a context menu with the right
mouse button. This is bad because you are assigning two distinct
semantics (select/ask-for-menu) to a single syntactic element (the
file name area).
Solution: Fortunately, every application that requires
right-clicks can be transformed into a single-click application by
duplicating the clickable area.
segusoLand does not require holding the
The default, officially supported way of using segusoLand will not
contemplate holding the mouse button. Any interface decision will be
taken with this use in mind.
Rationale: this gives a sensation of anxiety to some persons.
Consequence: segusoLand does not require dragging either,
since it implies holding.
Zones that are often clicked must be very big
This holds for the default, officially supported layout of
segusoLand. Any interface decision will be taken with this in mind.
Rationale: Clicking inside small zones is stressing for the
user. Such stress can be perceived consciously or, more often,
inconsciously, as a sense of anxiety.
- GTK and QT's tree views cannot be used by default, because
they have very small widgets for expanding a branch. Also, their lines
are too narrow vertically.
- traditional pop-up menus a-la Windows cannot be used by default,
since its rows are usually too narrow vertically.
- The standard GTK/KDE/Windows scrollbar widgets cannot be used, as
it forces you to either drag or click on a small button in order to
If there is enough space, menus which are
always open are to be preferred over pop-up menus, even if they
require long mouse travels to be reached, whereas the popup appears
at the mouse position.
It is better to have a menu which is always open, like the verb panel,
in a statically allocated portion of the screen, far from the mouse
pointer, than a pop-up menu than must be opened by clicking, and opens
near the mouse pointer.
- The sequence "click->popup->click" is more expensive than
"Move-a-long-distance -> click", for a subtle cognitive reason. First
let me introduce the following phenomenon. Turn your head to the right
and then to the left, repeatedly and quickly. Even though the
movements are quick, you can understand perfectly what happens around
you. The brain itself has commanded the movement, so it can foresee it
and compensate for it. The brain has innate algorithms for
compensating movements he himself commanded. Now ask someone to move
your head the same way, quickly, with his hands. This time you can't
see anything, nor understand what's around you, because your brain
cannot predict where your head will be moved. It has to parse the
scene with no possibility to foresee the next scene, and there is no
time because the scene changes too quickly.
Now let us analyze what happens when you pop-up a menu. When the
menu pops up, your brain has a moment of trouble when it must realize
where the popup menu has appeared, get it into focus. The popup
position does not depend on the brain, but on the program. On the
other hand, moving the mouse depends only on the brain (since modern
infrared mice react to impulses in a perfectly predictable way).
Caveat: This is only true if you have an infrared mouse. With
an old wheel-based mouse, mouse movements are much more expensive,
hence popup menus are to be preferred.
- Having such a menu always visible opens new perspectives and
possibilities: you can make the menu items not only executable, but
also selectable; you can make it a narrowing menu (as defined above);
it is no more necessary for the menu item to be clicked after
The act of scrolling a list must be
Consequence: You cannot use dropdown lists or combo-boxes,
unless these widgets are implemented so intelligently as to span the
whole screen height if needed.
Solution: Use a maximized window containing a listbox
By default, avoid multiple ways to do the
Rationale: duplication of functionality can speed up your
work but it introduces complexity, hence confuses the newbie user, and
gives a general impression of bloating and redundancy.