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

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 directory.
• An application's configuration files must be stored in ~/Settings/application
  
• 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).

File Attributes

• Since file attributes require a query system to be most useful these guidelines should be considered forward-looking and are not currently binding.
• 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 application signature.
• 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.

General

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

Windows

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

Document Windows

• 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

• 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 - Application).

Dialogue Windows

• 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 non-modal.
• 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.

Menu Bar

• 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 Help.
• The Application menu contains the application's documentation. It has the following standard items: About application..., a separator, Quit.
• 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 exist).

Tool Bar

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

Status Bar

• 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

• 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 appropriate section.

Text Messages

• 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 filename."
• 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 characters."
• 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").

Shortcut Keys

• The standard shortcut keys are as follows:
  • 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.