Read the GNOME
Human Interface Guidelines. While there are
many details that differ between the two documents (and where there are
differences this document, of course, takes precedence) the GNOME HIG
contain a wealth of good advice on creating usable, attractive
Application Installation and Location
- Applications should not use absolute paths, either to parts of
itself or to other programs and parts for which search paths exist.
- An application's directory is atomic, i.e. it contains
everything the application needs to function, it can be placed anywhere
in the file system hierarchy and installed on any machine regardless of
what else is installed.
- An application's executable should reside in the root
directory of the application.
- If it is important that the application be accessible from
the CLI then a symlink to the executable may be placed in ^/bin.
- With certain unavoidable exceptions (e.g. development tools
dependent on GCC) an application must not have external dependencies to
anything beyond what is included in the Syllable base package. Any
required libraries or resources must be compiled statically or included
in the application's directory.
- Install scripts and programs should be avoided. If an
application needs to set up configuration files or directories then it
should be done when the program is run and those files and/or
directories are not found. This means that each user on a system does
not have to run the install script individually and that a user can
revert to defaults simply by deleting the application's settings
- An application's configuration files must be stored in
- An application should only create and/or modify files in the
current user's home directory.
- An application should, if appropriate, accept a file to open
when it is launched (e.g. "aedit ~/mydoc.txt" opens ~/mydoc.txt in a
new aedit window).
- Since file attributes require a query system to be most useful these
guidelines should be considered forward-looking and are not currently
- All files should preferably have an os::FileType attribute whose value is
the MIME media type of the file. See http://www.ietf.org/rfc/rfc2046.txt
for information on MIME media types.
- All files belonging to an application should have an
os::OwnerApplication attribute whose value is the application's
application signature. This includes configuration files created by the
application but not documents.
- The application's executable should have an
os::ApplicationSignature attribute whose value is the application's
- The application's executable should have an os::LargeIcon
attribute which value is a 32x32 image in any translator supported
format and an os::SmallIcon attribute which value is a 16x16 image in
any translator supported format.
- The application's executable should have an os::Category
attribute which value is one of: Development, Games, Media, Network,
Productivity, System or Utilities.
- A colour-blind user must be able to use the
application as effectively as a user who can see in full colour. Colour
cannot be used as the only source of information of importance to the
user. Using colour for strictly auxiliary information may be acceptable
under some circumstances. About 5% of people are colour-blind to some
extent, so a colour-blind user should not be unwarrantedly
disadvantaged in their ability to use the system.
- There are three main types of windows: document
windows, control windows and dialogue windows.
- Document windows contain a single document and the tools
necessary to manipulate it.
- Control windows contain additional tools that will not fit
elegantly in the document window.
- Dialogue windows present information or options to the user
and accept a response.
- Local window options, including window position, should be
saved when a window is closed.
- All windows must be ordered in a left-to-right,
top-to-bottom logical order. Rationale: while many cultures do not
organise information in this way, one consistent order is important.
- All windows must offer good contrast. Light text on a dark
background, or dark text on a light background.
- The document is displayed in the main content area
(note that the term document in this context is very broad).
- If the application deals with multiple forms of one document
or several closely related documents (e.g. a preview and code view of a
web page in an HTML editor, or multiple channels in an IRC client) then
these should be presented as multiple tabbed content areas in one
document window. These tabs should be at the top of the window, just
below the menu.
- Feedback on what is happening to the document may be
provided on a status bar.
- Document windows should have a title consisting of the name
of the document open in it followed by the name of the application,
separated by a hyphen (i.e. Document - Application).
- All text input fields should be lined up in a grid format.
- All controls should be surrounded with whitespace.
Rationale: this makes screens easier to read.
- Control windows are opened and closed using the "control
window window" item in the View menu.
- Control windows do not have menu bars.
- Control windows should have a title consisting of a one or
two word description of the controls the window presents followed by
the name of the application, separated by a hyphen (i.e. Controls
- Dialogue windows do not have menu bars, tool bars
or status bars.
- Dialogue window buttons must be located in the bottom-right
corner of the window.
- Standard dialogue windows should be used whenever possible.
- Modal dialogue windows should only be used when a non-modal
window could result in data loss or other serious problems.
- Notification dialogue windows have only an OK button and may
be modal or non-modal.
- Progress dialogue windows have a Cancel button and are
- Confirmation dialogue windows have a Cancel button, and
buttons related to the question they ask (Save/Discard, etc.), in that
order. The button lables should be verbs describing the function of the
button. Yes/No questions should be avoided. Confirmation dialogue
windows may be modal or non-modal.
- Settings dialogue windows have a Close button, a distinct
margin, an Apply (apply the changes made to the settings), Undo
(reverse the changes made by the last use of the apply button) and
Default (change the settings back to the application's defaults, and
apply them) button, in that order, and are non-modal. The Apply button
should be active when the window is opened.
- Dialogue windows should have a title that describes the
dialogue and states the application the dialogue belongs to, separated
by a hyphen (i.e. Dialogue - Application).
- The default button on all dialogue windows must be
non-destructive. Rationale: users sometimes
accidentally hit the Enter/Return/Space key. If they do that when an
Alert is open, we don't want the Alert to respond by deleting files.
- The menu bar is horizontally aligned and is
located at the very top of the window.
- The menu bar contains fixed menus that provide access to all
possible actions. Tool bars, context menus and keyboard shortcuts
should only duplicate functionality present in the menu bar, they
should not introduce new functionality.
- If a menu item is unavailable it should be greyed out, not
removed from the menu.
- A program does not have to include all of the standard menus
and may supplement them with additional application specific menus.
- Menu items that open dialogues must be labelled with a
trailing ellipse (...).
- The standard menus are: Application, File, Edit, View, Tools, Options and
- The Application menu contains the application's documentation. It
has the following standard items: About application..., a
- The File menu contains actions which deal with the basic
handling of files, opening them, closing them, saving them, etc. It has
the following standard items: New, Open..., Save, Save As..., a
separator, Close, Close All.
- The Edit menu contains actions that manipulate text or other
elements in the main content area. It has the following standard items:
Undo, Redo, a separator, Cut, Copy, Paste, a separator, Find..., Find
Next, Replace..., a separator, Select All
- The View menu contains actions that manipulate the
appearance of elements in the main content area. It has the following
standard items: Show/Hide control window.
- The Tools menu is a generic menu for application specific
actions. If the application has enough application specific actions to
fill more than one menu it is best to do away with Tools altogether and
give each menu a name that is more indicative of its contents. The
Tools menu has no standard items.
- The Options menu contains local (i.e. only affecting the
current window) options as well as an item that opens the Settings
dialogue, which controls the application's global settings. It has the
following standard item: a separator, Settings...
- The Help menu contains the application's documentation. It
has the following standard items: Contents...
- Application specific menus go between View and Tools (if they
- The tool bar is horizontally aligned and is
located just below the menu bar.
- The tool bar is a button bar. The buttons should have images
that are iconographic of the button's function and must have text
labels (the user should be able to turn the display of text lables on
and off as a system wide setting).
- The tool bar should only duplicate functionality present in
the menu bar. It should not add new functionality.
- The tool bar should provide access to all of the basic
functions of the application.
- The following actions should appear on the tool bar if the
application supports them: New, Open, Save, Undo, Redo, Cut, Copy,
Paste, Find, Previous Page/Back, Next Page/Forward.
- The status bar is horizontally aligned and is
located at the very bottom of the window.
- The status bar should be only one line high but may have
several fields on that line.
- Context menus are opened by clicking the
right mouse button on an element in the main content area.
- A context menu should provide a short list of the most
common actions that can be performed on the element clicked.
- The last entry in every context menu must be a separator and
then a "Help..." item which opens the application's help file to the
- All text messages must be complete
sentences, if possible. Rationale: abbreviations, sentence fragments,
and codes are harder to understand than full words and sentences.
- All error messages must be worded positively. E.g., "The
filename you chose is already in use" instead of "You cannot use that
- All error messages must imply that the user is in control.
E.g., "An account password should be at least 8 characters in length."
instead of "You have entered an invalid password of less than 8
- All error messages must provide insight into how to use the
application properly to recover from the error. See the above example.
- All text messages must be grammatically consistent. E.g., if
you're filling out a form, error messages should not be "You must enter
a first name" and "You must enter your last name" and "You must enter
the age." They should all be consistent (such as "your first name,"
"your last name," and "your age").
- The standard shortcut keys are as
- New - Ctrl + N
Open - Ctrl + O
- Save - Ctrl + S
Save As - Shift + Ctrl + S
- Close - Ctrl + W
- Close All - Ctrl + Q
- Undo - Ctrl + Z
- Redo - Shift + Ctrl + Z
- Cut - Ctrl + X
- Copy - Ctrl + C
- Paste - Ctrl + V
- Find - Ctrl + F
- Replace - Ctrl + R
- Select All - Ctrl + A
- Help Index -
Ctrl + H
- An application does not have to implement all
standard shortcuts. However, if implementing any of the above actions,
the standard key must be mapped to that action, and a standard shortcut
key must not be used for an action other than the action listed above
for that shortcut key.