Design philosophy


The program must not change the employees' working habits.

# Example: If the employees are used to work on a simplified interface mask of an aging AS400 system, the CARE 2002 must emulate this mask, e.g. position and placements of entry fields, button, toggles, labels, etc. The advantage offered by the CARE system lies on its advance automation, data validation features, flexibilty in changing itself, introduction of dynamic help system like help ballons, embedded job wizards, interactive help systems, etc.
# CARE 2002 must be designed to adapt itself to the employees habits and preferences, not the other way around.
# CARE 2002 must be designed to compensate the employees' shortcomings, not the other way around.


Change must evolve in phases.

# If changing the working habits of employees is not totally avoidable in order to improve work efficiency, the CARE 2002 must evolve in several phases so that the employees can adapt slowly to the new working procedures.


The program must be able to detect user errors and try to correct them.

# The program must try first all it can to correct an error, not just prompting the user about it. If the error cannot be corrected by the program, it should present the user several alternatives to choose from. Two common source of errors are the entry fields for time and date.
# All data entries and changes must be validated. Example: It is only logical that no two surgeons can be primary operators at the same time. If the user makes this mistake, the program must present the user a simple way of selecting the primary operator with just one click, not forcing the user to go back to the entry fields to retype or reselect the information.


The program must provide more than one way of getting the job done.

# This enhances the intuitive way of navigating through the program and getting the job done. The user is not limited to a single strict procedure which might not correspond to his analytical capabilities.


Navigation must be simple

# Pull down or pop-up menus must be avoided. The disadvantage of pull down or pop-up menus is that their functions are initially not visible. Most employees or workers (who are interested in health care but not in computers) do not remember what's inside a menu entry. Not being able to find the desired function at once leads to some sort of panic reaction. The user gives up easily and blames other causes for not finishing the work on the computer.
# All menus and functions pertaining to a certain module must be visible at a glance without the need of opening, pulling down, or popping up menu entries. The most practical way to do this is using the left column menu index and the index card register style.
# Step-in / Step-out principle and use of "Back", "Cancel", "Close" buttons. Every selection of a menu item or function or subfunction must be like stepping in into a new functional realm. If the user notices or realizes that he just "stepped in" into the wrong realm, he must be able to "step out" by hitting either the "Back", "Cancel", or "Close" button.


Search function must be simple.

# The number of entry fields in search functions must be minimized. Search modules must have (if possible) only one entry field. This makes it simple for the user to make a successful search.
# The search modules must be smart enough to detect what the user wants to find by first analysing the entered search keyword(s) before starting the actual search routine.

The user must have the impression that he is in control.
# Easier said than done. This can be closely achieved by enabling the user to configure the program's look and feel according to his personal preferences. The user must have a way to disable job wizards or assistants when he already knows how to use the program.

If you want to join the development team, please register here.