Human interface guidelines

This work is in progress and can change depending on your opinions/suggestions/insults.

Unfortunately these guidelines are not compatible with those of KDE and Gnome.

Do not hide complexity, but make it as apparent as possible (by default)

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 look. Frustration.
• 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 hidden.

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 above.

Narrowing menus must be always open (i.e. they cannot be pop-up)

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 other menu.

  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 select/deselect xmms.

• 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 context-sensitive)

  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 popup.

Usability is not the same as intuitiveness

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.

By default, privilege a layout and behavior which is easier to understand, not easier to use. Privilege uniformity over usability.

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

A list that is long but flat is more intuitive than a list which is short but structured.

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

Rationale:

• 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 button.

Rationale:

• alternating the mouse button is unnerving for some persons, and undeniably difficult to execute for newbies. Not everybody is a pianist.
• 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 mouse button

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

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.

Consequences:

• 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 scroll.

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.

Rationales:

• 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 something else.

The act of scrolling a list must be minimized.

Solution: Use a maximized window containing a listbox instead.

By default, avoid multiple ways to do the same thing

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.

Examples:

• one might think to add a pop-up, context-sensitive menu that appears when you click a program. This is to be avoided by default because (not counting the reasons previously explained) there is already a context-sensitive menu showing the available actions: the verb panel.
• someone else might think to provide both a global "Go" button, and many "go" buttons near verbs. This is to be avoided because the user would be asking himself what is the difference (the answer being that there is no difference).

  Such redundant features can however be offered to advanced users, who are more interested in executing actions quickly.