gnome-devel-docs 3.8.1-1 / usr / share / help / sl / hig-book / hig-ch-checks.xml

<?xml version="1.0" encoding="utf-8"?>
<!-- we can change the title as soon as the content is written
     I want the document to be as usable and correct as possible
     this week -seth

  <chapter id="checklists">
    <title>Checklists</title>
-->
<chapter id="reality-checks" lang="sl">
    <title>Checklists</title>
    <sect1 id="checks-yourself">
      <title>Things You Can Do Yourself</title>
      <sect2>
	<title>Before You Start</title>

	<para>Write down the type of people you expect to use your application.  Then write some "scenarios" for each type of user— a little story that describes the typical tasks those users will use your application for.  These tasks should be along the lines of:</para>

	<blockquote><para>Fred needs to find an email about widgets that he received last week</para></blockquote>

<!-- CB: Flow chart diagram.  Boxes with arrows showing flow of user scenario 
example.  An transitional paragraph probably needs to be added after the "right" vs. "wrong" text examples shown, that basically says: You can use a flow chart, as shown below, to sketch out an expected user scenario. -->

	<para>rather than </para>

	<blockquote><para>Fred clicks on the <guibutton>Find</guibutton> button and types <userinput>widgets</userinput> into the dialog.</para></blockquote>

	<para>This way, you can use the same scenarios to test and compare different interface designs, and to spot any missing functionality.</para>

	<para>Include these user descriptions and scenarios with the documentation you commit to CVS.  This way, other contributors will get to understand your users too, can help to develop the application with that knowledge, and can provide more scenarios of their own.</para>
      </sect2>
      
      <sect2>
	<title> Keyboard Access and Focus</title>

	<para>When you have started implementing your interface, hide your mouse, and make sure you can still use it to do everything using only the keyboard. Implement keyboard functionality at the same time as mouse functionality— don't leave it until the end.</para>

<!-- CB: This is a non-figure comment, I couldn't help myself.  The first sentence in the paragraph directly above, is badly written.  The word "it" is ambiguous in the sentence because it likely refers to the mouse!  Please correct. -->

	<para>Using only keyboard commands, move the focus through all menu bars and toolbars in the application. Also confirm that:</para>
	
<!-- CB-Ed: OK I'll just make all non-figures comments tagged with CB-Ed.  The above paragraph should be part of the bulleted list below. -->

<!-- CB-Fig: All figures comments will be tagged with CB-Fig.  A single figure showing an example GUI with callouts highlighting bulleted points would be great. Perhaps visually box bulleted elements and then "zoom" them out with callout text.  -->
	<itemizedlist>
	  <listitem><para>Context sensitive menus display correctly (<keycombo><keycap>Shift</keycap><keycap>F10</keycap></keycombo>).</para></listitem>
	  <listitem><para>Tooltips can be popped up and down for all controls that have them (<keycombo><keycap>Ctrl</keycap><keycap>F1</keycap></keycombo>, <keycap>Esc</keycap>).</para></listitem>

	  <listitem><para>All functions listed on the toolbar can be performed using the keyboard.</para></listitem>

	  <listitem><para>You can fully operate every control in the client area of the application and dialogs.</para></listitem>

	  <listitem><para>Text and objects within the client area can be selected.</para></listitem>

	  <listitem><para>Any keyboard enhancements or shortcut keys are working as designed.</para></listitem>

	  <listitem><para>Verify that when moving among objects, the visual focus indicator is easy to identify at all times.</para></listitem>
	</itemizedlist>
	
      </sect2>
      
      <sect2>
	<title>Theming, Colors and Contrast</title>

	<para>Test various GNOME themes to ensure that your application respects all the available settings.</para>

	<para>Test your application with black and white, high contrast themes and confirm that all information is still conveyed correctly.  If you don't have a suitable high contrast GNOME theme available to test, print off some screenshots in black and white (not grayscale) and make sure all the important information is still visible— this will approximate what a high contrast theme user will see.</para>
      </sect2>

      <sect2>
	<title>Animation</title>

	<para>Ensure you have implemented an option to turn off any animation in your application (for accessibility reasons), and that it is working as designed.  Turn the animation off. Confirm that all information is still conveyed correctly.</para>
      </sect2>
    </sect1>
    
    <sect1 id="checks-other-people">
      <title>Things You Can Do With Other People</title>
      <sect2>
	<title>Get Early Feedback</title>
	
	<para>It's always tempting, but don't start coding your interface straight away.  Sketch out some ideas on paper first, or in Glade or HTML if you prefer.  (But don't be tempted add any functionality at this point if you do it this way!)</para>

	<para>Show these prototypes to other people— the GNOME mailing lists and IRC are ideal for finding likely candidates.  Ask them to use these prototype interfaces to run through some of the scenarios you came up with earlier.  You'll probably get questions like "how would I do X", "which menu is Y on"... these questions will help you think about the interface from the user's viewpoint.  You'll probably also get a few suggestions about how to do things differently— these ideas may or may not turn out to better than yours, but any idea from a potential user is worth considering!</para>

	<para>You should also consider seeking opinions from the <ulink url="http://developer.gnome.org/projects/gup/">GNOME Usability team</ulink>.  They have designed many user interfaces before and may be able to spot potential problems at this early stage, before you take your design too far to change easily.</para>

	<para>Once you've decided on the basic interface design and have started coding parts of it, find somebody to try it out again— it doesn't have to be the same person.  You'll probably find some more problems that were hard to see on your static paper prototype.  By finding these now, it's usually not too late to fix them without too much trouble.</para>
      </sect2>
      
      
      <sect2>
	<title>Internationalization and Localization</title>

	<para>If you intend your application to be translated into different languages, show draft designs of your application to the <ulink url="http://developer.gnome.org/projects/gtp/contact.html">GNOME Translation Team</ulink>.  They'll help you find potential translation problems, such as not leaving enough space for translated labels, shortcut keys that cause problems on a different keyboard layout, or using new terms in your app that are hard to translate.</para>

	<para>If possible, try out your application with users from the locales you are targeting.  This will help you determine whether users understand how to use the application, if they perceive the graphics and colors the way you intended, and if there are words or images in the application that may cause offence to users of that locale. </para>
      </sect2>

    </sect1>
  </chapter>