<chapter id="ui-guide-fundamentals"> <title>Fundamentals of the GNOME user interface</title> <para> [This is to be modeled after Part 1 "Fundamentals" of the Macintosh User Interface Guidelines.] </para> <sect1 id="cl"> <title>Compliancy levels</title> <para> This document will often speak of "GNOME compliancy levels". Programs can be assigned ratings of conformance to the GNOME User Interface Guidelines based on these compliancy levels. </para> <para> The purpose of having compliancy levels is to let developers progressively implement features of the GNOME user interface into their programs, by being able to know which of those features are more important than others. </para> <para> When this document describes a particular user interface feature, it will be labeled with a specific compliancy level so that developers can implement those features in an orderly fashion. </para> <para> There are five compliancy levels for the GNOME user interface: <itemizedlist> <listitem> <para> GNOME compliancy level 1 (G1) - Mandatory </para> <para> All applications are expected to have G1 features. These are meant to be the bare minimum user interface features that applications should have. </para> </listitem> <listitem> <para> GNOME compliancy level 2 (G2) - Highly recommended </para> <para> Features in the G2 level are to be expected in the final version of an application (i.e. one that is past the beta stage). All GNOME applications of release-quality are expected to have G2 features. </para> </listitem> <listitem> <para> GNOME compliancy level 3 (G3) - Suggested </para> <para> Features in the G3 level are not to be expected in applications. These are features that may not be applicable in all situations, are hard to implement, or are beyond the call of duty. It is suggested that very polished applications try to implement G3 features. </para> </listitem> <listitem> <para> GNOME compliancy level 4 (G4) - Nice to have </para> <para> Features in the C4 level are minor conveniences that developers may not decide to implement. Users will experience C4 level features as ocassionaly useful, but definitely not needed for a functional user interface. </para> </listitem> <listitem> <para> GNOME compliancy level 5 (G5) - Experimental features </para> <para> Features in the G5 level are experimental user interface conventions that are in development. As such, they may have not been formalized enough for developers to use consistently. It is recommended that no release-quality application have G5 level features -- only development and proof-of-concept programs should use these when appropriate. </para> <para> When features in the G5 level are formalized enough to be included in the G1-G4 levels, they will be moved there and cease to be experimental features. It is recommended that the original developers of G5 features help application developers integrate these new features in their applications. </para> </listitem> </itemizedlist> </para> </sect1> <sect1> <title>User interface principles</title> <para> foo </para> </sect1> <sect1> <title>Design considerations</title> <para> bar </para> <sect2 id="levels-of-usage"> <!-- FIXME: this subsection likely needs to be moved somewhere else. A detailed explanation of each concept presented will likely be in the other sections. --> <title>Levels of usage</title> <para> The needs of the user shall be the primary consideration when designing the interface for a GNOME application. Because of the broad range of needs each user will present to a given application, that application shall be designed to accomodate two separate styles of usage. The first of these styles is casual usage: the needs of a user who is unfamiliar with a piece of software dictate that functions within the application are to be clearly mapped to their respective controls, that the controls for those functions are easily discoverable, that the presentation of the controls is easy to read and understand, and that the controls present clear feedback when they are used. The primary goal of these design fundamentals is to ensure that a casual user can make full use of the application through intuition alone. </para> <para> The goal for the second style of usage each GNOME application's interface shall accomodate is ergonomics. For one who uses a GNOME application frequently or whose productivity is limited solely by the capability of that application, the relationship between each function and its control shall be determined by the efficiency and consideration of human interaction with the control. Although intuitiveness and discoverability are not primary concerns for this style of usage, feedback to the user shall still be provided by each control. </para> <para> If possible, the intuitive, discoverable controls for the casual user should be efficient and designed well ergonomically, but if a single control does not meet the requirements for both styles of usage, separate controls shall be provided to fulfill the needs individually. An example of a function whose controls are both intuitive and efficient is the manual typewriter keyboard: although a new or casual user can find each key relatively easily and produce desired output by typing each letter in sequence with an index finger, a touch-typist who must produce output in as little time possible can use the same controls with all ten fingers and without having to search for each key in turn. </para> <para> An example of an application which might need two sets of controls to accomodate both styles of usage is a text editor: functions such as opening files, maneuvering the cursor within a document, or formatting text would be easily discoverable through menus in the application window or arrow keys on the keyboard. A user who makes regular usage of the same text editor may seek to reduce time wasted maneuvering through the document or formatting it by using keyboard shortcuts for which the experienced user's fingers do not need to leave the keyboard. </para> </sect2> </sect1> <sect1> <title>Developing the user interface</title> <para> baz </para> </sect1> </chapter> <!-- Keep this comment at the end of the file Local variables: mode: sgml sgml-omittag:t sgml-shorttag:t sgml-minimize-attributes:nil sgml-always-quote-attributes:t sgml-indent-step:2 sgml-indent-data:t sgml-parent-document:("ui-guide.sgml" "book" "sect1" "") sgml-exposed-tags:nil sgml-local-catalogs:nil sgml-local-ecat-files:nil End: -->