IWETHEY v. 0.3.0 | TODO
1,095 registered users | 0 active users | 0 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New Second try, edited passive voice:
4.2.2 Acceptable user-interaction times
It is highly important that users find the speed of the system acceptable. However, user perception is highly subjective, and system responsiveness depends on many things outside of developer control. Therefore, this and other design documents will not specify exact clock limits. Instead, each time requirement will specify a category of timeliness, one of the following:

4.2.2.1 Immediate Time.
Users perceive Immediate Time processes as instantaneous. Humans cannot measure them unaided. They do not indicate processing or progress. Examples of Immediate Time activities include:
  • Displaying a character on-screen following a keystroke.

  • Highlighting selected text (of moderate length).

  • Repainting discovered windows.


4.2.2.2 Page Time.
Users notice Page Time processes; however, any delay does not measurably affect their work speed. In most cases, the user offsets any delays with instinctive workflow improvements. Page Time processes must indicate that processing is underway. Examples of Page Time activities include:
  • Opening a new window in a web browser and populating its view.

  • Updating a data objects' primitive properties.

  • Password verification.


4.2.2.3 Analysis Time.
Users notice Analysis Time processes and categorize them as delays; however, they accept the delay, considering it reasonable and necessary to complete a complex task. Analysis Time processes must indicate that processing is underway, and indicate relative progress where possible. Examples of Analysis Time activities include:
  • Retrieval of large or complex tables for display.

  • Updates to multiple similar or interrelated objects.

  • Spell-checking or find-and-replace applied to a large document.


4.2.2.4 Background Time.
Background Time processes are not always noticed by the user, since they do not interrupt their work. They allow other user actions to be performed simultaneously. They must unobtrusively indicate that processing is underway, and indicate relative progress where possible. Examples of Background Time activities include:
  • The actual time between a user clicking 'Send' on an email, and the time that email is delivered.

  • Background printing; that is, the actual time between a user clicking a 'Print' button associated with a document, and the time that document begins or completes printing.

  • The processing of a request which is relegated in a web interface to a "popunder", or background window.


4.2.2.5 Warehouse Time.
Users understand Warehouse Time processes but are not normally affected by them. For example, the user may have knowledge that a process occurs once every twenty-four hours, but is usually able to work without regard to the exact time that process occurs. Such processes have published time specifications, but do not indicate their progress to end users while underway. Server-side processes indicate relative progress where possible to system administrators. Examples of Warehouse Time activities include:
  • Data warehousing activites, in which low-level details are summarized for management-level analysis, usually in another datastore designed specifically for that purpose.

  • Hourly "batch" processes, such as garbage collection, integrity checks, or child property summation for a parent's consumption.

  • Daily "batch" processes, such as automatic payments via credit card, or automated email reminders based on dated triggers.


4.2.2.6 Moderated Time.
Moderated Time processes require the action of a human to complete. They indicate to the user who is responsible for the next step. They either notify the next party or inform the user how they may be notified. Examples of Moderated Time include:
  • Temporary access to subsystems to which the user does not normally have permission.

  • The "posting" of a forum message on a forum which requires all posts be approved by a moderator.

  • "Two-actor" systems which require that users act in concert to perform an activity. Such systems are commonly used to combat fraud.


Many fears are born of stupidity and ignorance -
Which you should be feeding with rumour and generalisation.
BOfH, 2002 "Episode" 10
New *Much* easier to read
===

Implicitly condoning stupidity since 2001.
     Maybe we need a new forum to fit my new job. :( - (tseliot) - (5)
         Use active voice, not passive. - (ben_tilly) - (4)
             OK, thanks! - (tseliot)
             About the only complaint I have is passive voice. - (folkert)
             Second try, edited passive voice: - (tseliot) - (1)
                 *Much* easier to read -NT - (drewk)

Why is that so damned familiar?
49 ms