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

<?xml version="1.0" encoding="utf-8"?>
<chapter id="feedback" lang="sl">
  <title>Feedback</title>

  <sect1 id="feedback-responsiveness">
    <title>Characteristics of Responsive Applications</title>

    <para>Although highly responsive applications can differ widely from one
    another, they share the following characteristics:</para>

    <itemizedlist>
      <listitem>
        <para>They give immediate feedback to users, even when they cannot
        fulfill their requests immediately.</para>
      </listitem>

      <listitem>
        <para>They handle queued requests as users would expect, discarding
        requests that are no longer relevant and reordering requests according
        to users' probable priorities.</para>
      </listitem>

      <listitem>
        <para>They let users do other work while long operations proceed to
        completion— especially operations not requested by users— such as
        reclaiming unused memory or other "housekeeping" operations.</para>
      </listitem>

      <listitem>
        <para>They provide enough feedback for users to understand what they
        are doing, and organize feedback according to users' abilities to
        comprehend and react to it.</para>
      </listitem>

      <listitem>
        <para>They let users know when processing is in progress.</para>
      </listitem>

      <listitem>
        <para>They let users know or estimate how long lengthy operations will
        take.</para>
      </listitem>

      <listitem>
        <para>They let users set the pace of work, when possible, and they let
        users stop requested tasks that have started but not finished.</para>
      </listitem>
    </itemizedlist>

    <!-- CB-Ed: Collapse some of the items in the list above, they are similar or have lots of overlap.  -->

    <para>Highly responsive applications put users in control by quickly
    acknowledging each user request, by providing continuous feedback about
    progress toward fulfilling each request, and by letting users complete
    tasks without unacceptable delays.</para>

    <para>Even applications with attractive, intuitive user interfaces can
    lack responsiveness. Typically, unresponsive applications have at least
    one of the following problems:</para>

    <itemizedlist>
      <listitem>
        <para>They provide late feedback— or no feedback— for users'
        requests, leaving users wondering what the application has done or is
        doing.</para>
      </listitem>

      <listitem>
        <para>When performing extended operations, they prevent users from
        doing other work or cancelling the extended operation.</para>
      </listitem>

      <listitem>
        <para>They fail to display estimates of how long extended operations
        will last, forcing users to wait for unpredictable periods.</para>
      </listitem>

      <listitem>
        <para>They ignore users' requests while doing unrequested
        "housekeeping", forcing users to wait at unpredictable times—
        often without feedback.</para>
      </listitem>
    </itemizedlist>

    <para>You can sometimes possible to improve an application's
    responsiveness without speeding up the application's code. For tips on
    how to make such improvements, see <xref linkend="feedback-responding-to-user"/>.</para>
  </sect1>

  <sect1 id="feedback-response-times">
    <title>Acceptable Response Times</title>

    <para>Some user interface events require shorter response delays than
    others. For example, an application's response to a user's mouse
    click or key press needs to be much faster than its response to a request
    to save a file. The table below shows the maximum acceptable response
    delay for typical interface events.</para>

    <table frame="all">
      <title>Maximum acceptable response times for typical events</title>

      <tgroup align="left" cols="2">
        <thead>
          <row>
            <entry>UI Event</entry>

            <entry>Maximum Acceptable Response Time</entry>
          </row>
        </thead>

        <tbody>
          <row>
            <entry>Mouse click, pointer movement, window movement or resizing,
            keypress, button press, drawing gesture, other UI input event
            involving hand-eye co-ordination</entry>

            <entry>0.1 second</entry>
          </row>

          <row>
            <entry>Displaying progress indicators, completing ordinary user
            commands (e.g. closing a window), completing background tasks
            (e.g. reformatting a table)</entry>

            <entry>1.0 second</entry>
          </row>

          <row>
            <entry>Displaying a graph or anything else a typical user would
            expect to take time (e.g. displaying a new list of all a
            company's financial transactions for an accounting period)</entry>

            <entry>10.0 seconds</entry>
          </row>

          <row>
            <entry>Accepting and processing all user input to any task</entry>

            <entry>10.0 seconds</entry>
          </row>
        </tbody>
      </tgroup>
    </table>

    <para>Make each response delay in your application as short as possible,
    unless users need time to see the displayed information before it is
    erased. The acceptable response delay for each event is based on a typical
    user's sense that the event is a logical point at which to stop or
    pause. The greater that sense is, the more willingly the user will wait
    for a response. Verify that your application responds to users'
    requests within the limits listed in the table above. If your application
    cannot respond within those limits, it probably has one or more general
    problems caused by a particular algorithm or module.</para>

    <itemizedlist>
      <title>Guidelines</title>

      <listitem>
        <para>Verify that your application provides feedback within 100
        milliseconds (0.1 second) after each key press, movement of the mouse,
        or other physical input from the user.</para>
      </listitem>

      <listitem>
        <para>Verify that your application provides feedback within 100
        milliseconds (0.1 second) after each change in the state of controls
        that react to input from the user— for example, displaying menus or
        indicating drop targets.</para>
      </listitem>

      <listitem>
        <para>Verify that your application takes no longer than 1 second to
        display each progress indicator, complete each ordinary user command,
        or complete each background task.</para>
      </listitem>

      <listitem>
        <para>Verify that your application takes no longer than 10 seconds to
        accept and process all user input to any task—including user input to
        each step of a multistep task, such as a wizard.</para>
      </listitem>
    </itemizedlist>
  </sect1>

  <sect1 id="feedback-responding-to-user">
    <title>Responding to User Requests</title>

    <para>If your application takes too long to respond, users will become
    frustrated. Use these techniques to improve the responsiveness of your
    application.</para>

    <itemizedlist>
      <title>Guidelines</title>

      <listitem>
        <para>Display feedback as soon as possible.</para>
      </listitem>

      <listitem>
        <para>If you cannot display all the information that a user has
        requested, display the most important information first.</para>
      </listitem>

      <listitem>
        <para>Save time by displaying approximate results while calculating
        finished results.</para>
      </listitem>

      <listitem>
        <para>If users are likely to repeat a time-consuming command in rapid
        succession, save time by faking the command's effects instead of
        repeatedly processing the command. For example, if a user adds several
        rows to a table stored in a database, you might display each new row
        immediately but delay actually creating each new row in the database
        until the user finished adding all the rows.</para>
      </listitem>

      <listitem>
        <para>Work ahead. Prepare to perform the command that is most likely
        to follow the current command. That is, use idle time to anticipate
        users' probable next requests. For example, as the user of an
        email application reads the currently displayed new message, the
        application might prepare to display the next new message.</para>
      </listitem>

      <listitem>
        <para>Use background processing. Perform less important tasks —such as
        housekeeping— in the background, enabling users to continue working.</para>
      </listitem>

      <listitem>
        <para>Delay work that is not urgent. Perform it later, when more time
        is available.</para>
      </listitem>

      <listitem>
        <para>Discard unnecessary operations. For example, to move back
        several pages in a web browser, a user might click the browser's
        <guibutton>Back</guibutton> button several times in rapid succession.
        To display the final requested page more quickly, the browser might
        not display the pages visited between the current page and that final
        page.</para>
      </listitem>

      <listitem>
        <para>Use dynamic time management. At run time, change how your
        application prioritizes user input and other processing, based on the
        application's current state. For example, if a user is typing text
        in one word-processing document while printing another, the
        word-processing application might delay the printing task if the user
        shifts to an editing task (such as cutting and pasting text) that
        requires greater resources.</para>
      </listitem>

      <listitem>
        <para>In your application, display an estimate of how long each
        lengthy operation will take.</para>

        <itemizedlist>
          <listitem>
            <para>If a command might take longer than 5 seconds to complete
            its work on an object, allow users to interact with any parts of
            the object and parts of the application that are not directly
            affected by the command.</para>
          </listitem>

          <listitem>
            <para>If a command provides lengthy output, show partial results
            as they become available. Scroll the results (if necessary) until
            the user moves input focus to a component (e.g. a scrollbar or
            text area) involved in the scrolling.</para>
          </listitem>
        </itemizedlist>
      </listitem>
    </itemizedlist>
  </sect1>

  <sect1 id="feedback-types">
    <title>Types of Visual Feedback</title>

    <para>You can use two types of visual feedback for operations in your
    application— pointer feedback and progress animations.</para>

    <sect2 id="pointer-feedback">
      <title>Pointer Feedback</title>

      <para>Pointer feedback changes the shape of the pointer. For example, a
      busy pointer indicates that an operation is in progress and that the
      user cannot do other tasks. A busy-interactive pointer indicates that an
      operation is in progress but the window is still interactive.</para>

      <figure>
        <title>Busy pointer (left) and Busy-Interactive pointer (right)</title>

        <mediaobject>
          <imageobject>
            <imagedata depth="28" fileref="images/feedback-pointers-busy.png" format="PNG" width="58"/>
          </imageobject>

          <imageobject>
            <imagedata fileref="images/feedback-pointers-busy.eps" format="EPS"/>
          </imageobject>

          <textobject>
            <phrase>Busy pointer (left) and busy-interactive pointer (right)</phrase>
          </textobject>
        </mediaobject>
      </figure>

      <!-- CB-Fig: Replace above figure with one that is cleaned up.  -->
    </sect2>

    <sect2 id="progress-animations">
      <title>Progress Animations</title>

      <para>Progress animations show either how much of an operation is
      complete, or only that an operation is ongoing. Normally, these take the
      form of either a progress bar or a progress checklist.</para>

      <itemizedlist>
        <title>Guidelines</title>

        <listitem>
          <para>When displaying a progress animation, open it as soon as
          possible after you know it is required, and close it automatically
          as soon as the associated operation is complete.</para>
        </listitem>

        <listitem>
          <para>Use a measured-progress bar if your application can estimate
          either how long the operation will take, or what proportion of the
          operation is complete.</para>
        </listitem>

        <listitem>
          <para>If your application can make neither estimate, and the
          operation only has one step, use an <link linkend="indeterminate-progress">indeterminate-progress bar</link>.
          For operations with two or more steps, use a <link linkend="progress-checklists">progress checklist</link> that
          dynamically displays a check mark for each completed step.</para>
        </listitem>
      </itemizedlist>

      <sect3 id="progress-bars">
      <title>Progress Bars</title>
      <para>For information on different types of progress bars and when to use
            them see <xref linkend="controls-progress-bars"/>.</para>

        <sect4 id="progress-windows-vs-status-bar">
          <title>Progress Windows vs. the Statusbar</title>

          <para>In an application where the <link linkend="windows-primary">primary
          windows</link> contain a <link linkend="controls-status-bars">status
          bar</link> (which in turn contains a progress bar), it will often be
          the case that an operation's feedback could be presented in
          either the statusbar or a <link linkend="windows-progress">progress
          window</link>. A rule of thumb is to use the statusbar when an
          operation is expected to take fewer than ten seconds, otherwise use
          a progress window. However, do consider the following when choosing
          between the two:</para>

          <itemizedlist>
            <listitem>
              <para>Opening a new window, particularly when an operation is
              short, can needlessly disrupt the user's workflow.</para>
            </listitem>

            <listitem>
              <para>Progress windows can convey more information.</para>
            </listitem>

            <listitem>
              <para>Multiple progress windows can be open at once, whereas
              only a single operation can be presented in a statusbar.</para>
            </listitem>

            <listitem>
              <para>Progress windows provide a <guibutton>Cancel</guibutton>
              button.</para>
            </listitem>
          </itemizedlist>
        </sect4>
      </sect3>

      <sect3 id="progress-checklists">
        <title>Checklist Windows</title>

        <para>A checklist window shows the sequence of stages in an operation.
        See <xref linkend="progress-window-checklists"/>.
	
	<figure><title>A Checklist Window</title>
	
	<mediaobject>
		<imageobject><imagedata fileref="images/feedback-checklist-running.png" format="PNG" width="336" depth="220"/></imageobject>
	<textobject><phrase>A
        checklist window showing a sequence of steps</phrase></textobject>
	
	<imageobject>
            <imagedata fileref="images/feedback-checklist-running.eps" format="EPS"/>
          </imageobject>
        </mediaobject>
	  
	  </figure></para>
      </sect3>
    </sect2>
  </sect1>

  <sect1 id="feedback-choosing">
    <title>Choosing Appropriate Feedback</title>

    <para>To determine which type of visual feedback to provide for a
    particular operation, consider these factors:</para>

    <itemizedlist>
      <listitem>
        <para>Whether your application can provide an estimate of the
        operation's progress.</para>
      </listitem>

      <listitem>
        <para>Whether the operation blocks the user from issuing further
        commands in your application.</para>
      </listitem>

      <listitem>
        <para>Whether your application has a dedicated space, such as a status
        bar, for indicating the status of operations.</para>
      </listitem>
    </itemizedlist>

    <para>The table below shows which type of feedback to provide for
    operations that usually take at least 1 second to finish. In the
    "Appropriate Feedback" column, "Internal progress
    animations" means progress animations displayed in an
    application's dedicated status area, and "External progress
    animations" means progress animations displayed somewhere other than
    in a dedicated status area— typically, in an alert box.</para>

    <table frame="all">
      <title>Visual feedback types for operations that take at least 1 second</title>

      <tgroup align="left" cols="4">
        <thead>
          <row>
            <entry>Typical Duration &gt; 5 seconds?</entry>

            <entry>User blocked from issuing further commands?</entry>

            <entry>Application has dedicated status area?</entry>

            <entry>Appropriate feedback</entry>
          </row>
        </thead>

        <tbody>
          <row>
            <entry>Yes</entry>

            <entry>Yes</entry>

            <entry>Yes</entry>

            <entry>Internal animation plus pointer feedback</entry>
          </row>

          <row>
            <entry>Yes</entry>

            <entry>Yes</entry>

            <entry>No</entry>

            <entry>Pointer feedback</entry>
          </row>

          <row>
            <entry>Yes</entry>

            <entry>No</entry>

            <entry>Yes</entry>

            <entry>Internal animation</entry>
          </row>

          <row>
            <entry>No</entry>

            <entry>Yes</entry>

            <entry>Yes</entry>

            <entry>Internal animation plus pointer feedback</entry>
          </row>

          <row>
            <entry>No</entry>

            <entry>Yes</entry>

            <entry>No</entry>

            <entry>External animation plus pointer feedback</entry>
          </row>

          <row>
            <entry>No</entry>

            <entry>No</entry>

            <entry>Yes</entry>

            <entry>Internal animation</entry>
          </row>

          <row>
            <entry>No</entry>

            <entry>No</entry>

            <entry>No</entry>

            <entry>External animation</entry>
          </row>
        </tbody>
      </tgroup>
    </table>

    <itemizedlist>
      <title>Guidelines</title>

      <listitem>
        <para>Use a busy pointer whenever users are blocked from interaction
        with your application for 1 second or longer. Display the busy pointer
        less than 1 second after the operation begins.</para>
      </listitem>

      <listitem>
        <para>If a command will likely take 10 seconds or longer to finish,
        provide a <guibutton>Stop</guibutton> or <guibutton>Cancel</guibutton>
        button, which can also be activated by pressing <keycap>Esc</keycap>,
        that lets users terminate the command's processing even if your
        application cannot undo the command's effects. See <xref linkend="feedback-interrupting"/>.</para>
      </listitem>

      <listitem>
        <para>When using an external animation, leave the window containing
        the animation on-screen for at least 1 second after the operation has
        completed, with a successful completion message. Change the
        <guibutton>Stop</guibutton> or <guibutton>Cancel</guibutton> button to
        an <guibutton>OK</guibutton> button during this period— pressing this
        button should close the window immediately.</para>
      </listitem>
    </itemizedlist>
  </sect1>

  <sect1 id="feedback-interrupting">
    <title>Allowing Interruptions</title>

    <para>Users sometimes need to stop a command— for example, because it is
    taking too long. Your application should let users stop commands in
    progress, even if stopping a command cannot undo or "roll back"
    all the command's effects.</para>

    <itemizedlist>
      <title>Guidelines</title>

      <listitem>
        <para>Place a <guibutton>Stop</guibutton> or <guibutton>Cancel</guibutton>
        button, which can also be activated by pressing <keycap>Esc</keycap>,
        near the progress animation for the interruptable command.</para>
      </listitem>

      <listitem>
        <para>Label the button <guibutton>Cancel</guibutton> if the whole
        operation can be cleanly abandoned with no side effects, leaving the
        system in the state it was in prior to the operation beginning.
        Terminate the command immediately when the user presses this button.</para>
      </listitem>

      <listitem>
        <para>Label the button <guibutton>Stop</guibutton> if the command can
        be interrupted, but its effects up to that point cannot (or should
        not) be reversed. When the user presses this button, open an alert box
        that warns of the potential side effects of stopping the command. The
        alert box should have only two buttons: one for continuing the
        command's processing, and one for immediately terminating it.</para>
      </listitem>

      <!-- CB-Fig: Figure here showing example alertbox in context (overlaying the progress animation in a dialog, etc.) with sample alerbox text. JLFDG AT p. 107 shows this. (Fig 66) -->
    </itemizedlist>

    <para>Alternatively, you can place the <guibutton>Stop</guibutton> or
    <guibutton>Cancel</guibutton> button near the control with which the user
    issued the command that needs to be stopped. Place the button here only
    if:</para>

    <itemizedlist>
      <listitem>
        <para>There is no progress animation for the command, or</para>
      </listitem>

      <listitem>
        <para>The progress animation is in a window's status area or in
        another location that lacks space for a <guibutton>Stop</guibutton> or
        <guibutton>Cancel</guibutton> button.</para>
      </listitem>
    </itemizedlist>

    <para>In the alert box that appears after pressing a
    <guibutton>Stop</guibutton> button, ensure the message and button labels
    in the alert box are specific and precise. Ambiguous button labels can
    cause users to terminate or continue a command unintentionally. For
    example, use:</para>

    <para><screen>Continue deleting files? <guibutton>[Continue Deleting]</guibutton>
    <guibutton>[Stop Deleting]</guibutton></screen></para>

    <para>rather than</para>

    <para><screen>Operation interrupted, continue? <guibutton>[Yes]</guibutton>
    <guibutton>[No]</guibutton></screen></para>

    <para>since in the latter example, it is not clear whether pressing
    <guibutton>Yes</guibutton> would continue the operation or continue the
    interruption (i.e. cancel the operation).</para>
  </sect1>
</chapter>