<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:
-->