Rhino implements policies that maintain a consistent look and feel across all Rhino-based applications and that govern the end user's interaction with Rhino-based applications. These policies form the Rhino users model.
This section explains where the Rhino users model came from.
The Rhino team identified possible end users for Rhino-based applications: Unix-illiterate bright professionals, such as animators and graphics artists, and systems administrators who seek tools to improve their efficiency. We interviewed these people using techniques described in Analyzing UI Requirements and thereby learned what makes system administration difficult:
Prerequisites and background knowledge. Users get stuck
when they must perform an administration task and don't know enough
about the system to get started or to complete the task. For example,
a user wants to share a file on the network, but doesn't know about
exportfs
and doesn't know that to share an individual
file they must share the file's directory.
Information overload. Users lose patience and feel overwhelmed when they must perform an administration task and are deluged with information from many sources: "Read this first!" documents packaged in the system box, man pages, release notes, books, the Web, and so on. Their frustration is compounded when the information is only partly relevant or consistent.
Risk of system damage. Users hesitate before performing
an administration task that they perceive may damage the computer,
whether or not there is real risk. Other users try ad hoc methods and
unknowingly do system damage when trying to perform an administration
task. For example, a user accustomed to a single-user system like a
Macintosh might always log into the root
account; to free
up disk space, the user might remove /unix
among other
large files.
Lack of confidence in result. Users who try to perform an administration task are not certain that what they tried had the intended effect. For example, most commands issued at the command line return an invisible return code, and few state in plain English what has happened and what ramifications to expect.
Entry points difficult to find. Users and systems
administrators use different terminology when thinking about their
systems, which makes it difficult for users to find and use the tools
they need. For example, a user who wants to get a modem working might
search for "modem" and not find that they must install
eoe.sw.uucp
.
Error recovery. When something goes wrong, users get
stuck and don't know what to do to fix the problem. For example, a
user who unwittingly removes /unix
might continue to use
the system for days or weeks until the system is rebooted, at which
point it can be difficult to track down what went wrong, why, and how
to fix it.
Deciding what to do next. Users don't know what to do next when they've run an unfamiliar command, whether the command seemed to have the desired effect or not. Users get confused when there is no feedback informing them how far they've come in an administration task or what their options are at any given point.
Based on the above findings, the Rhino team developed the following principles of interaction:
Make prerequisites explicit and complete. Telling the user up front what they will need to accomplish the task eliminates the need for them to seek this information elsewhere, thereby saving time, avoiding frustration, and building the user's trust in the application. This can eliminate the problem of having to know arcane prerequisites and mysterious background knowledge.
Hide unnecessary details by default. Getting secondary concerns out of the way helps the user focus their attention on the task at hand, saving time and avoiding frustration. This can alleviate the information overload problem.
Always tell the truth about system status (if possible). When the application gives accurate status, the user has confidence in the results and trusts the application to do the right thing.
Tell the user what will happen before they perform a task. Also tell the user what did happen after they've performed the task. Giving users feedback before and after a task helps them understand the ramifications of performing the task, avoiding frustration and building the user's trust in the application. This can reduce the problem of error recovery.
Identify problems as soon as possible. Users' time is
precious. For example, an animator working on a Jurassic Park
sequel may have a pressing deadline to finish designing a dinosaur
model for the next morning's dailies. It would waste the user's time
for the application to ask for additional input when the task has no
hope of succeeding. For example, when the user tries to add a modem,
the application should inform the user if eoe.sw.uucp
is
missing and tell the user to install it.
Let the user know what can be done next. Giving users alternative steps to take next helps them understand what they've done so far and how close they are to accomplishing their larger goal (they may be done), avoiding frustration, saving time, and building the user's trust in the application.
The Rhino principles of interaction have been embedded in the Rhino infrastructure:
Tasks can be implemented as a Form, a no-frills window containing a set of inputs (suitable for expert users), and/or as a Guide, a user-friendly interface that distributes inputs across pages and includes text that gives guidance to help the user choose each input (suitable for novice users).
At the top of the window, the Task introText explains prerequisites needed to perform the task.
The Guide summary page lists all input changes that the user has made, and informs the user what will happen when they click the OK button.
After the user clicks OK, the Task either fails and an error dialog appears to inform the user about the problem, or succeeds and a Rhino ResultView appears to inform the user what has happened and provide a list of Tasks that can be performed next.
The Rhino application developer can bind validations to be performed when the user changes any input. When any one of these validations fails, the user can thus be immediately informed in an error dialog and given instructions and opportunity to fix the problem.
Rhino ItemViews, ItemTables, and TreeView can display the system state. Rhino Items and Categories communicate dynamically to keep these views up to date, such that the Rhino-based application always tells the truth about system status.