|
There are many characteristic of the user interface, which can affect its usability.
Some of the most important are discussed below.
 
When a command line interaction is used, the user types in commands for the
application, usually one at a time, the application executes them, if possible, and gives
some feedback to the user. In this case, the interaction becomes just a dialogue, in which
the human is the active side.
The important advantages of the
command-line interface are:
First, the command-line interface is cheap. Not only because it is relative
easy to implement and requires less development time, but also because it could be used
with "dumb", not-graphical screens, and it does not need many system resources
(memory, CPU time, etc.). This makes it suitable when the performance of application is
crucial or leak of resources could be expected - for example if a slow communication line
is used.
Second, the command line is still the most flexible interface. Since the
number of the commands is not limited by the screen space, they can be much enough to
represent almost all needed operations by a single command. Experienced users can
reach very high performance, using command-line interface.
The flexibility makes command line also good for making compex queries to a program,
which returns relatively small amount of results [New95].
On the other hand, the most evident disadvantage
of the command-line interface is its low visibility. Since you cannot see the
commands before use, you have to remenber the command each time you need it.. This makes
the command line unacceptable for unexperienced or casual users, who probably will have
also difficulties with typing.
Another disadvantage is that error corrections are difficult, when once the data have
been entered. So, the command line interface is not suitable for applications, which
inludes a lot of data entry - the form filing generally better for this.
It is also not convenient for applications, which use and display many numeric data -
these data are much more readable as graphics - as well as for office
applications, where the look of printed documents is important, so the users would prefer
to preview them on the screen before printing.
The giudelines for good command line interface could be derived from three main
goals:
- Gain maximum flexibility
- Facilitate remembering of commands
- Facilitate error corrections
In order to be really flexible
- Provide meaningful commands, based on careful task analysis. For example,
renaming a file is a common operation in a file management system. It is possible to be
done by copying the file with new name and then deleting the original. Nevertheless, most
of the users will perceive renaming as a semantically different operation and it
is hihgly advisable to include such a command. It is normal, if the set of commands is
redundant. There is some research, showing that experienced users has their own
"active subset" of commands they use most of time. Even among users doing
similar tasks these subset vary significantly - the redundant system is customisable! In
general, the better the set of commands matches user's mental model of the
application, the easier to learn the system is.
- Provide way to remember and execute sets of commands. This will allow both the
user to tailor the application and the developer to tailor ot easy for different groups of
users. The sets in most cases will be simply sequences (print a file, than copy it to a
diskette), but they can include conditionals (check a diskette for viruses, if clean, copy
all the files to the hard disk) or even loops (for example, maintainig archive: check each
file in the directory, if it is newer, than on a diskette, copy it there). Command (batch)
files in MS-DOS gives this opportunity. UNIX has even a programming language to combine
commands in so-called shell scripts. In some systems such a
"recorded" set is called a macro
.
In order to facilitate recalling
- Use meaningful, descriptive names of commands. (connect is better than
cnn and start seems better than run). In this case users will
not have to memorise a new word, they will need to make a new (hopefuly natural)
assosiation with an existing word, which is easier. On the other hand, descriptive names
are usualy long, so they require more typing, thus reducing the speed and boring
experienced users. Some systems allow both long and short versions of the commnad names,
others rely on a compromise.
- Follow "de facto" standards. Exit and quit are most
widely used commands for stopping an application. Prefer them against bye or leave.
Reuse user's previous knowledge!
- If abbreviation are necessary, make them consistent when possible.
Some systems use just firts several letters, others prefer first-letter abbreviations,
like ftp for File Transfer Protocol or cd for Change Directory.
- Use options to change slightly command's behaviour, instead of introducing more
commands. If options are consistent, in many cases users will be able to combine a command
name and an options, instead of memorise many commands or all options for each command.
For example, -R in UNIX means that the command should be applied recursive to all
subdirectories, -l - that tha command should generate a long output, etc. These options
could be used with every command they make sence. If we suppose, that 10 commands may use
any of these two options, thn the benefit is evident - the user have to memorise 10 + 2 =
12 items. Otherwise, if different commands have be used for each combination, they will be
10 x 2 x 2 = 40.
- Use consistent format of the command line. In MS-DOS the command line consists
of the command name (what the operation is), operands, if any (on whom the operation will
be made) and options. Options are preceded by a slash "/", like dir /a.
Although, some DOS programs use UNIX style of options, preceded by a minus sign
"-". In the above example we may see that a special character "*" is
sometimes accepted, sometimes not - this is an example of inconsistency. In UNIX the
structure of the command line is fixed: command name, options, operadns. Special
characters, like "*" and "?" are accepted with any command and have
the same meaning.
- Provide on-line help. In the ideal case, the on-line help should answer three
questions: What a particular command is (short description)? What the command can do (full
description, with all options, etc.)? Which command could be used for a particular task?
 In MS-DOS the first question could be
answered by using /? and /?? options with any command, like in this example. For more
detailed description, help command is available. In UNIX, man command
gives full description of a command, while apropos gives a one-line summary. The
big advantage of apropos is, that it can be used "reversible", i.e. to
find a command, which description includes a specified word.
In order to improve the error correction.
- Provide a way to edit and replay last command.
- Give feedback on both successful and unsuccessful commands
|
World Wide Web version of a lesson from the course Human-Computer
Interactions. This text is provided as refererence only. All
exersizes, interactive examples and assignments are in the main page of the module.