Versions Compared

Old Version 3

changes.mady.by.user christopher cannaday

Saved on

compared with

New Version 4

changes.mady.by.user Scott Peterson

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Excerpt

This guideline describes how the module is expected to function in specific situations.

General Points

  1.  There must be consistency, for example, in regards to, the manner in which icons, symbols, abbreviations, button text and shortcut keys are placed and used. There should be compliance with Windows standards and the ‘Noah 4 Standalone Features and User Interface Requirement Specification’ document (on the HIMSA website – www.himsa.com), wherever possible.

2.  Running a module should not have an adverse effect on other programs.

3.  To make modules Noah 4 compliant, they should be able to save data while still remaining open. HIMSA recommends the implementation of a Save toolbar button in addition to a Save command in the File control menu.

4.  The module should be able to handle internal program errors and user errors in such a way that these are detected and communicated to the user in an informative and understandable way. When at all possible, the user should also be informed of the necessary course of action to take to solve the error.

User Interface

  1.  User configurable options should be user consistent.

2.  There should be access to context-sensitive help by pressing F1 whenever the module is running. If no context-sensitive help is available for a particular item, the Help file’s “contents/index/find” front page should be displayed. The module should also support the ‘What’s This?’ Help facility.

3.  Operation of the module via the keyboard is recommended wherever possible. Consistency should be maintained both with the Noah keyboard commands and within the module. Two or more module functions must not use the same keyboard shortcuts.

4.  Buttons, and other controls that should not be available to the user under certain circumstances, must be disabled but still visible at such times. Typically, buttons and options are colored light gray to denote that they are no longer accessible.

Windows, Controls, etc.

  1.  All module-controlled dialog with the user – i.e., window titles, dialog boxes, text and error messages – must be conducted in the correct language, and in user-friendly terms. For example, if the user is running the Swedish version of a module, all text must appear in Swedish.

2.  All list boxes must be implemented with invisible horizontal and vertical scrollbars. These should only become visible, and take effect, when the content of the list box exceeds its specified width and height. Columns should be resizable and consistent.

3.  For all buttons without text (e.g., toolbar icons) ToolTips should be used – i.e., a brief help text should appear beside the button when the mouse pointer is placed over it.

4.  When Noah begins a process that will take a short time (to be determined, under approximately 10 seconds), the cursor should change to an hour glass until the process is completed. When Noah begins a process that will take a long time (to be determined, over approximately 10 seconds), the program must make it clear that it is busy by displaying a gauge control. This box should make the following clear to the user:

  • a time-consuming process is taking place
  • events are running normally 
  • how much more time the process will take – whenever possible
  • how to cancel the operation – whenever possible

...