UNIFIED DOCUMENT MANAGEMENT, CREATING A MILESTONE COPY OF THE DOCUMENT

<< BEHAVIOR & FORM: UNDERSTANDING UNDO, TYPES AND VARIANTS, INCREMENTAL AND PROCEDURAL ACTIONS

DESIGNING LOOK AND FEEL, PRINCIPLES OF VISUAL INTERFACE DESIGN >>

Human Computer Interaction (CS408)

Lecture37

Lecture 37. Behavior & Form - Part V

Learning Goals

As the aim of this lecture is to introduce you the study of Human Computer

Interaction, so that after studying this you will be able to:

· Discuss Unified Document Management

· Understand considerate and smart software

Unified Document Management

37.1

The established standard suite of file management for most applications consists of the

Save As dialog, the Save Changes dialog, and the Open File dialog. Collectively, these

dialogs are, as we've shown, confusing for some tasks and completely incapable of

performing others. The following is a different approach that manages documents according

to the user's mental model.

Besides rendering the document as a single entity, there are several goal-directed

functions that the user may have need for and each one should have its own

corresponding function.

· Automatically saving the document

· Creating a copy of the document

· Creating a milestone/milestoned copy of the document

· Naming and renaming the document

· Placing and repositioning the document

· Specifying the stored format of the document

· Reversing some changes

· Abandoning all changes

Automatically saving the document

One of the most important functions every computer user must learn is how to save a

document. Invoking this function means taking whatever changes the user has made to the

copy in computer memory and writing them onto the disk copy of the document. In the

unified model, we abolish all user interface recognition of the two copies, so the Save

function disappears completely from t h e mainstream interface. That doesn't mean that it

disappears from the program; it is still a very necessary operation.

The program should automatically save the document. At the very least, when the

user is done with the document and requests the Close function, the program will merely

go ahead and write the changes out to disk without stopping to ask for confirmation

with the Save Changes dialog box.

In a perfect world, that would be enough, but computers and software can crash,

power can fail, and other unpredictable, catastrophic events can conspire to erase your

work. If the power fails before you have clicked Close, all your changes are lost as the

memory containing them scrambles. The original copy on disk will be all right, but hours

of work can still be lost. To keep this from happening, the program must also save the

document at intervals during the user's session. Ideally, the program will save every single

343

Human Computer Interaction (CS408)

little change as soon as the user makes it, in other words, after each keystroke. For most

programs, this is quite feasible. Most documents can be saved to hard disk in just a

fraction of a second. Only for certain programs--word processors leap to mind -- would

this level of saving be difficult (but not impossible).

Word will automatically save according to a countdown clock, and you can set the

delay to any number of minutes. If you ask for a save every two minutes, for example,

after precisely two minutes the program will stop to write your changes out to disk

regardless of what you are doing at the time. If you are typing when the save begins, it

just clamps shut in a very realistic and disconcerting imitation of a broken program. It

is a very unpleasant experience. If the algorithm would pay attention to the user instead of

the clock, the problem would disappear. Nobody types continuously. Everybody stops to

gather his thoughts, or flip a page, or take a sip of coffee. All the program needs to do is

wait until the user stops typing for a couple of seconds and then save.

This automatic saving every few minutes and at close time will be adequate for

almost even body. Some people though, like the authors, are so paranoid about

crashing and losing data that they habitually press Ctrl+S after every paragraph, and

sometimes after every sentence (Ctrl+S is the keyboard accelerator for the manual save

function). AM programs should have manual save controls, but users should not be

required to invoke manual saves.

Right now, the save function is prominently placed on the primary program menu.

The save dialog is forced on all users whose documents contain unsaved changes when

users ask to close the document or to quit or exit the program. These artifacts must go

away, but the manual save functionality can and should remain in place exactly as it is now.

Creating a copy of the document

This should be an explicit function called Snapshot Copy. The word snapshot makes it

clear that the copy is identical to the original, while also making it clear that the copy is not

tied to the original in any way. That is, subsequent changes to the original will have no

effect on the copy. The new copy should automatically be given a name with a standard

form like Copy of Alpha, where Alpha is the name of the original document. If there is

already a document with that name, the new copy should be named Second Copy of Alpha.

The copy should be placed in the same directory as the original.

It is very tempting to envision the dialog box that accompanies this command, but

there should be no such interruption. The program should take its action quietly,

efficiently, and sensibly, without badgering the user with silly questions like Make a

Copy? In the user's mind it is a simple command. If there are any anomalies, the program

should make a constructive decision on its own authority.

Naming and renaming the document

The name of the document should be shown on the application's title bar. If the user

decides to rename the document, he can just click on it and edit it in place. What could be

simpler and more direct than that?

Placing and moving the document

Most desktop productivity documents that are edited already exist. They are opened

rather than created from scratch. This means that their position in the file system is

already established. Although we think of establishing the home directory for a document

at either the moment of creation or the moment of first saving, neither of these events is

344

Human Computer Interaction (CS408)

particularly meaningful outside of the implementation model. The new file should be put

somewhere reasonable where the user can find it again. .

If the user wants to explicitly place the document somewhere in the file system

hierarchy, he can request this function from the menu. A relative of the Save As

dialog appears with the current document highlighted. The user can then move the

file to any desired location. The program thus places all files automatically, and this

dialog is used only to move them elsewhere.

Specifying the stored format of the document

There is an additional function implemented on the Save As dialog.

The combo box at the bottom of the dialog allows the user to specify the physical format of

the file. This function should not be located here. By tying the physical format to the

act of saving, the user is confronted with additional, unnecessary complexity added to

saving. In Word, if the user innocently changes the format, both the save function and any

subsequent close action is accompanied by a frightening and unexpected confirmation box.

Overriding the physical format of a file is a relatively rare occurrence. Saving a file is a very

common occurrence. These two functions should not be combined.

From the user's point-of-view, the physical format of the document--whether it is rich text,

ASCII, or Word format, for example -- is a characteristic of the document rather than of the

disk file. Specifying the format shouldn't be associated with the act of saving the file to disk.

It belongs more properly in a Document Properties dialog

The physical format of the document should be specified by way of a small dialog box

callable from the main menu. This dialog box should have significant cautions built into its

interface to make it clear to the user that the function could involve significant data loss.

345

Human Computer Interaction (CS408)

In the case of some drawing programs, where saving image files to multiple formats is

desirable, an Export dialog (which some drawing programs already support) is appropriate

for this function.

Reversing changes

If the user inadvertently makes changes to the document that must be reversed, the

tool already exists for correcting these actions: undo. The file system should not be

called in as a surrogate for undo. The file system may be the mechanism for supporting

the function, but that doesn't mean it should be rendered to the user in those terms. The

concept of going directly to the file system to undo changes merely undermines the

undo function.

The milestoning function described later in this chapter shows how a file-centric

vision of undo can be implemented so that it works well with the unified file model.

Abandoning all changes

It is not uncommon for the user to decide that she wants to discard all the changes she

has made after opening or creating a document, so this action should be explicitly

supported. Rather than forcing the user to understand the file system to achieve her

goal, a simple Abandon Changes function on the main menu would suffice. Because

this function involves significant data loss, the user should be protected with clear

warning signs. Making this function undoable would also be relatively easy to implement

and highly desirable.

Creating a milestone copy of the document

37.2

Milestoning is very similar to the Copy command. The difference is that this copy is

managed by the application after it is made. The user can call up a Milestone dialog

box that lists each milestone along with various statistics about it, like the time it was

recorded and its length. With a click, the user can select a milestone and, by doing so,

he also immediately selects it as the active document. The document that was current at

the time of the new milestone selection wi l l be milestoned itself, for example, under

the name Milestone of Alpha 12/17/03, 1:53 PM. Milestoning is, in essence, a lightweight

form of versioning.

A new File menu

Our new File menu now looks like the one shown in Figure

New and Open function as before, but Close closes the document without a dialog

box or any other fuss, after an automatic save of changes. Rename/Move brings up a dialog that

lets the user rename the current file or move it to another directory. Make Snapshot

Copy creates a new file that is a copy of the current document. Print collects all printer-related

controls in a single dialog. Make Milestone is similar to Copy, except that the program manages

these copies by way of a dialog box summoned by the Revert to Milestone menu item. Abandon

Changes discards all changes made to the document since it was opened or created. Document

Properties opens a dialog box that lets the user change the physical format of the document. Exit

behaves as it does now, closing the document and application.

346

Human Computer Interaction (CS408)

A new name for the File menu

Now that we are presenting a unified model of storage instead of the bifurcated

implementation model of disk and RAM, we no longer need to call the left-most application

menu the File menu -- a reflection on the implementation model, not the user's model.

There are two reasonable alternatives.

We could label the menu after the type of documents the application processes. For

example, a spreadsheet application might label its left-most menu Sheet. An invoicing program

might label it Invoice,.

Alternatively, we can give the left-most menu a more generic label such as Document. This is a

reasonable choice for applications like word processors, spreadsheets, and drawing programs, but

may be less appropriate for more specialized niche applications.

Conversely, those few programs that do represent the contents of disks as files -- generally

operating system shells and utilities --should have a File menu because they are addressing files

asfiles.

Are Disks and Files Systems a Feature?

37.3

From the user's point of view, there is no reason for disks to exist. From the hardware

engineer's point of view, there are three:

· Disks are cheaper than solid-state memory.

· Once written to, disks don't forget when the power is off.

· Disks provide a physical means of moving information from one computer to

another.

Reasons two and three are certainly useful, but they are also not the exclusive

domains of disks. Other technologies work as well or better. There are varieties of RAM

that don't forget their data when the power is turned off. Some types of solid-state memory

can retain data with little or no power. Networks and phone lines can be used to

physically transport data to other sites, often more easily than with removable disks.

Reason number one -- cost -- is the real reason why disks exist. Non-volatile solid-state mem-

ory is a lot more expensive than disk drives. Reliable, high-bandwidth networks haven't

been around as long as removable disks, and they are more expensive.

Disk drives have many drawbacks compared to RAM. Disk drives are much slower

than solid-state memory. They are much less reliable, too, because they depend on

moving parts. They generally consume more power and take up more space, too. But the

biggest problem with disks is that the computer, the actual CPU, can't directly read or write to

them! Its helpers must first bring data into solid-state memory before the CPU can work with

it. When the CPU is done, its helpers must once again move the data back out to the disk.

This means that processing that involves disks is necessarily orders of magnitude slower and

more complex than working in plain RAM.

The time and complexity penalty for using disks is so severe that nothing short of enormous

cost-differential could compel us to rely on them. Disks do not make computers

better, more powerful, faster, or easier to use. Instead, they make computers weaker,

slower, and more complex. They are a compromise, a dilution of the solid-state

architecture of digital computers. If computer designers could have economically used

RAM instead of disks they would have done so without hesitation - and in fact they do, in

347

Human Computer Interaction (CS408)

the newest breeds of handheld communicators and PDAs that make use of Compact Plash

and similar solid-state memory technologies.

Wherever disk technology has left its mark on the design of our software, it has done so

for implementation purposes only, and not in the service of users or any goal-directed design

rationale.

Time for Change

37.4

There are only two arguments that can be mounted in favor of application software implemented

in the file system model: Our software is already designed and built that way, and users are used

to it

Neither of these arguments is valid. The first one is irrelevant because new programs written with

a unified file model can freely coexist with the older implementation model applications. The

underlying file system doesn't change at all. In much the same way that toolbars quickly invaded

the interfaces of most applications in the last few years, the unified file model could also be

implemented with similar success and user acclaim.

The second argument is more insidious, because its proponents place the user community in

front of them like a shield. What's more, if you ask users themselves, they will reject the new

solution because they abhor change, particularly when that change affects something they have

already worked hard to master -- like the file system. However, users are not always the best

predictors of design successes, especially when the designs are different from anything they've

already experienced,

In the eighties, Chrysler showed consumers early sketches of a dramatic new

automobile design: the minivan. The public gave a uniform thumbs-down to the new

design. Chrysler went ahead and produced the Caravan anyway, convinced that the

design was superior. They were right, and the same people who initially rejected the

design have not only made the Caravan the one of the best-selling minivans, but also

made the minivan the most popular new automotive archetype since the convertible.

Users aren't interaction designers, and they cannot be expected to visualize the larger

effects of interaction paradigm shifts. But the market has shown that people will

gladly give up painful, poorly designed software for easier, better software even if

they don't understand the explanations behind the design rationale

Making Software Considerate

37.5

Two Stanford sociologists, Clifford Nass and Byron Reeves, discovered that humans

seem to have instincts that tell them how to behave around other sentient beings. As

soon as any artifact exhibits sufficient levels of interactivity -- such as that found in

your average software application -- these instincts are activated. Our reaction to

software as sentient is both unconscious and unavoidable.

The implication of this research is profound: If we want users to like our software, we

should design it to behave in the same manner as a likeable person. If we want users

to be productive with our software, we should design it to behave like a supportive

human colleague.

Designing Considerate Software

Nass and Reeves suggest that software should be polite, but the term considerate is

preferred. Although politeness could be construed as a matter of protocol --saying

348

Human Computer Interaction (CS408)

please and thank you, but doing little else helpful -- being truly considerate means

putting the needs of others first. Considerate software has the goals and needs of its

users as its primary concern beyond its basic functions.

If software is stingy with information, obscures its process, forces the user to hunt around

for common functions, and is quick to blame the user for its own failings, the user will dislike

the software and have an unpleasant experience. This will happen regardless of how cute, how

representational, how visually metaphoric, how content-filled, or how anthropomorphic the

software is.

On the other hand, if the interaction is respectful, generous, and helpful, the user will like

the software and will have a pleasant experience. Again, this will happen regardless of the

composition of the interface; a green-screen command-line interface will be well liked if it can

deliver on these other points.

What Makes Software Considerate?

Humans have many wonderful characteristics that make them considerate but whose

definitions are fuzzy and imprecise. The following list enumerates some of the

characteristics of considerate interactions that software-based products (and humans)

should possess:

· Considerate software takes an interest.

· Considerate software is deferential.

· Considerate software is forthcoming.

· Considerate software uses common sense.

· Considerate software anticipates needs.

· Considerate software is conscientious.

· Considerate software doesn't burden you with its personal problems.

· Considerate software keeps you informed.

· Considerate software is perceptive.

· Considerate software is self-confident.

· Considerate software doesn't ask a lot of questions.

· Considerate software takes responsibility.

· Considerate software knows when to bend the rules.

Well now discuss the characteristics in detail.

Considerate software takes an interest

A considerate friend wants to know more about you. He remembers likes and

dislikes so he can please you in the future. Everyone appreciates being treated

according to his or her own personal tastes

Most software, on the other hand, doesn't know or care who is using it. Little, if any, of the

personal software on our personal computers seems to remember anything about us, in

spite of the fact that we use it constantly, repetitively, and exclusively.

Software should work hard to remember our work habits and, particularly, everything that

we say to it. To the programmer writing the program, it's a just-in-time information world,

so when t h e program needs some tidbit of information, it simply demands that the user

provide it. The-program then discards that tidbit, assuming that it can merely ask for it

again if necessary. Not only is the program better suited to remembering than the

human, the program is also inconsiderate when, acting as a supposedly helpful tool, it

forgets.

349

Human Computer Interaction (CS408)

Considerate software is deferential

A good service provider defers to her client. She understands the person she is

serving is the boss. When a restaurant host shows us to a table in a restaurant, we consider

his choice of table to be a suggestion, not an order. If we politely request another table

in an otherwise empty restaurant, we expect to be accommodated. If the host refuses,

we are likely to choose a different restaurant where our desires take precedence over the

host's.

Inconsiderate software supervises and passes judgment on human actions. Software is

within its rights to express its opinion that we are making a mistake, but it is being

presumptuous when it judges our actions. Software can suggest that we not Submit our

entry until we've typed in our telephone number. It should also explain the consequences,

but if we wish to Submit without the number, we expect the software to do as it is told.

(The very word Submit and the concept it stands for are a reversal of the deferential role.

The software should submit to the user, and any program that proffers a Submit button is

being rude. Take notice, almost every transactional site on the World Wide Web!)

Considerate software is forthcoming

If we ask a store employee where to locate an item, we expect him to not only answer

the question, but to volunteer the extremely useful collateral information that a more

expensive, higher quality item like it is currently on sale for a similar price.

Most software doesn't attempt to provide related information. Instead, it only

narrowly answers the precise questions we ask it, and it is typically not forthcoming

about other information even if it is clearly related to our goals. When we tell our word

processor to print a document, it doesn't tell us when the paper supply is low, or when

forty other documents are queued up before us, or when another nearby printer is free. A

helpful human would.

Considerate software uses common sense

Offering inappropriate functions in inappropriate places is a hallmark of software-based

products. Most software-based products put controls for constantly used functions adjacent

to never-used controls. You can easily find menus offering simple, harmless functions

adjacent to irreversible ejector-seat-lever expert functions. It's like seating you at a dining

table right next to an open grill.

Considerate software anticipates needs

A human assistant knows that you will require a hotel room when you travel to another

city, even when you don't ask explicitly. She knows the kind of room you like and reserves

one without any request on your part. She anticipates needs.

A Web browser spends most of its time idling while we peruse Web pages. It could easily

anticipate needs and prepare for them while we are reading. It could use that idle time to

preload all the links that are visible. Chances are good that we will soon ask the browser to

examine one or more of those links. It is easy to abort an unwanted request, but it is always

time-consuming to wait for a request to be filled.

350

Human Computer Interaction (CS408)

Considerate software is conscientious

A conscientious person has a larger perspective on what it means to perform a task.

Instead of just washing the dishes, for example, a conscientious person also wipes down the

counters and empties the trash because those tasks are also related to the larger goal: cleaning

up the kitchen. A conscientious person, when drafting a report, also puts a handsome cover

page on it and makes enough photocopies for the entire department.

Considerate software doesn't burden you with its personal problems

At a service desk, the agent is expected to keep mum about her problems and to show a reasonable

interest in yours. It might not be fair to be so one-sided, but that's the nature of the

service business. Software, too, should keep quiet about its problems and show interest in ours.

Because computers don't have egos or tender sensibilities, they should be perfect in this role; but

they typically behave the opposite way.

Software whines at us with error messages, interrupts us with confirmation dialog

boxes, and brags to us with unnecessary notifiers (Document Successfully Saved!

How nice for you, Mr. Software: Do you ever unsuccessfully save?). We aren't interested

in the program's crisis of confidence about whether or not to purge its Recycle bin. We

don't want to hear its whining about not being sure where to put a file on disk. We don't

need to see information about the computer's data transfer rates and its loading

sequence, any more than we need information about the customer service agent's

unhappy love affair. Not only should software keep quiet about its problems, but it should

also have the intelligence, confidence, and authority to fix its problems on its own.

Considerate software keeps us informed

Although we don't want our software pestering us incessantly with its little fears and

triumphs, we do want to be kept informed about the things that matter to us. Software can

provide us with modeless feedback about what is going on.

Considerate software is perceptive

Most of our existing software is not very perceptive. It has a very narrow

understanding of the scope of most problems. It may willingly perform difficult work,

but only when given the precise command at precisely the correct time. If, for example, you

ask the inventory query system to tell you how many widgets are in stock, it will

dutifully ask the database and report the number as of the time you ask. But what if,

twenty minutes later, someone in your office cleans out the entire stock of widgets. You

are now operating under a potentially embarrassing misconception, while your computer

sits there, idling away billions of wasted instructions. It is not being perceptive. If you

want to know about widgets once, Isn't that a good clue that you probably will want to

know about widgets again? You may not want to hear widget status reports every day for

the rest of your life, but maybe you'll want to get them for the rest of the week.

Perceptive software observes what the user is doing and uses those patterns to offer

relevant information.

Software should also watch our preferences and remember them without being asked

explicitly to do so. If we always maximize an application to use the entire available

screen, the application should get the idea after a few sessions and always launch in that

351

Human Computer Interaction (CS408)

configuration. The same goes for placement of palettes, default tools, frequently used

templates, and other useful settings.

Considerate software is self-confident

Software should stand by its convictions. If we tell the computer to discard a file, It

shouldn't ask, "Are you sure?" Of course we're sure, otherwise we wouldn't have asked. It

shouldn't second-guess itself or us.

On the other hand, if the computer has any suspicion that we might be wrong (which

Is always), it should anticipate our changing our minds by being prepared to undelete the

file upon our request.

How often have you clicked the Print button and then gone to get a cup of coffee, only to

return to find a fearful dialog box quivering in the middle of the screen asking, "Are you sure

you want to print?" This insecurity is infuriating and the antithesis of considerate human

behavior.

Considerate software doesn't ask a lot of questions

Inconsiderate software asks lots of annoying questions- Excessive choices quickly

stop being a benefit and become an ordeal.

Choices can be offered in different ways. They can be offered in the way that we window shop.

We peer in the window at our leisure, considering, choosing, or ignoring the goods offered

to us -- no questions asked. Alternatively, choices can be forced on us like an interrogation

by a customs officer at a border crossing: "Do you have anything to declare?" We don't

know the consequences of the question. Will we be searched or not? Software should

never put users through this kind of intimidation.

Considerate software fails gracefully

When a friend of yours makes a serious faux pas, he tries to make amends later and

undo what damage can be undone. When a program discovers a fatal problem, it has the

choice of taking the time and effort to prepare for its failure without hurting the user, or it

can simply crash and burn. In other words, it can either go out like a psychotic postal

employee, taking the work of a dozen coworkers and supervisors with it, or it can tidy up

its affairs, ensuring that as much data as possible is preserved in a recoverable format.

Most programs are filled with data and settings. When they crash, that information

is normally just discarded. The user is left holding the bag. For example, say a program is

computing merrily along, downloading your e-mail from a server when it runs out of

memory at some procedure buried deep in the internals of the program. The program,

like most desktop software, issues a message that says, in effect, "You are completely

hosed," and terminates immediately after you click OK. You restart the program, or

sometimes the whole computer, only to find that the program lost your e-mail and, when

you interrogate the server, you find that it has also erased your mail because the mail was

already handed over to your program. This is not what we should expect of good

software.

In our e-mail example, the program accepted e-mail from the server -- which then

erased its copy -- but didn't ensure that the e-mail was properly recorded locally. If the e-

mail program had made sure that those messages were promptly written to the local disk,

352

Human Computer Interaction (CS408)

even before it informed the server that the messages were successfully downloaded, the

problem would never have arisen.

Even when programs don't crash, inconsiderate behavior is rife, particularly on the

Web. Users often need to enter detailed information into a set of forms on a page. After

filling in ten or eleven fields, a user might press the Submit button, and, due to

some mistake or omission on his part, the site rejects his input and tells him to correct

it. The user then clicks the back arrow to return to the page, and lo, the ten valid entries

were inconsiderately discarded along with the single invalid one.

Considerate software knows when to bend the rules

When manual information processing systems are translated into computerized

systems, something is lost in the process. Although an automated order entry system

can handle millions more orders than a human clerk can, the human clerk has the ability

to work the system in a way most automated systems ignore. There is almost never a way to

jigger the functioning to give or take slight advantages in an automated system.

In a manual system, when the clerk's friend from the sales force calls on the phone

and explains that getting the order processed speedily means additional business, the

clerk can expedite that one order. When another order comes in with some critical

information missing, the clerk can go ahead and process it, remembering to acquire and

record the information later. This flexibility is usually absent from automated systems.

In most computerized systems, there are only two states: non existence or full-

compliance. No intermediate states are recognized or accepted. In any manual system,

there is an important but paradoxical state -- unspoken, undocumented, but widely relied

upon -- of suspense, wherein a transaction can be accepted although still not being f u l l y

processed. The human operator creates that state in his head or on his desk or in his back

pocket.

For example, a digital system needs both customer and order information before it can

post an invoice. Whereas the human clerk can go ahead and post an order in advance of

detailed customer information, the computerized system will reject the transaction,

unwilling to allow the invoice to be entered without it.

The characteristic of manual systems that let humans perform actions out of sequence

or before prerequisites are satisfied is called fudgeability. It is one of the first

casualties when systems are computerized, and its absence is a key contributor to the

inhumanity of digital systems. It is a natural result of the implementation model. The

programmers don't see any reason to create intermediate states because the computer

has no need for them. Yet there are strong human needs to be able to bend the system

slightly.

One of the benefits of fudgeable systems is the reduction of mistakes. By allowing many

small temporary mistakes into the system and entrusting humans to correct them before

they cause problems downstream, we can avoid much bigger, more permanent

mistakes. Paradoxically, most of the hard-edged rules enforced by computer systems are

imposed to prevent just such mistakes. These inflexible rules cast the human and the

software as adversaries, and because the human is prevented from fudging to prevent big

mistakes, he soon stops caring about protecting the software from really colossal problems.

When inflexible rules are imposed on flexible humans, both sides lose. It is invariably bad

for business to prevent humans from doing what they want, and the computer system usually

ends up having to digest invalid data anyway.

353

Human Computer Interaction (CS408)

In the real world, both missing information and extra information that doesn't fit into a

standard field are important tools for success. Information processing systems rarely handle

this real-world data. They only model the rigid, repeatable data portion of

transactions, a sort of skeleton of the actual transaction, which may involve dozens of

meetings, travel and entertainment, names of spouses and kids, golf games and favorite sports

figures. Maybe a transaction can only be completed if the termination date is extended two

weeks beyond the official limit. Most companies would rather fudge on the termination

date than see a million-dollar deal go up in smoke. In the real world, limits are fudged

all the time. Considerate software needs to realize and embrace this fact.

Considerate software 'takes' responsibility

Too much software takes the attitude: "It isn't my responsibility." When it passes a

job along some hardware device, it washes its hands of the action, leaving the stupid hardware

to finish up. Any user can see that the software isn't being considerate or conscientious, that the

software isn't shouldering its part of the burden for helping the user become more effective.

In a typical print operation, for example, a program begins sending the 20 pages of a report to

the printer and simultaneously puts up a print process dialog box with a Cancel button. If the user

quickly realizes that he forgot to make an important change, he clicks the Cancel button just

as the first page emerges from the printer. The program immediately cancels the print

operation. But unbeknownst to the user, while the printer was beginning to work on

page 1, the compute has already sent 15 pages into the printer's buffer. The program cancels

the last five pages, but the printer doesn't know anything about the cancellation; it just knows

that it was sent 15 pages, so it goes ahead and prints them. Meanwhile, the program smugly tells

the user that the function was canceled. The program lies, as the user can plainly see.

The user isn't very sympathetic to the communication problems between the

application am the printer. He doesn't care that the communications are one-way. All he knows

is that he decide not to print the document before the first page appeared in the printer's

output basket, he clicked the Cancel button, and then the stupid program continued

printing for 15 pages even though hi acted in plenty of time to stop it. It even acknowledged

his Cancel command. As he throws the 15 wasted sheets of paper in the trash, he growls at the

stupid program.

Imagine what his experience would be if the application could communicate with the print driver

and the print driver could communicate with the printer. If the software were smart

enough the print job could easily have been abandoned before the second sheet of paper was

wasted. The printer certainly has a Cancel function -- it's just that the software is too

indolent to use it, because its programmers were too indolent to make the connection.

Considerate Software Is possible

37.6

Our software-based products irritate us because they aren't considerate, not because

they lack features. As this list of characteristics shows, considerate software is usually no

harder to build than rude or inconsiderate software. It simply means that someone has to

envision interaction that emulates the qualities of a sensitive and caring friend. None of

these characteristics is at odds with the other, more obviously pragmatic goals of business

computing. Behaving more humanely can be the most pragmatic goal of all.

354

Human Computer Interaction (CS408)

Making Software Smarts:

37.7

Because every instruction in every program must pass single-file through the CPU,

we tend to optimize our code for this needle's eye. Programmers work hard to keep the

number of instructions to a minimum, assuring snappy performance for the user. What we often

forget, however, is that as soon as the CPU has hurriedly finished all its work, it waits idle,

doing nothing, until the user issues another command. We invest enormous efforts in

reducing the computer's reaction time, but we invest little or no effort in putting it to work

proactively when it is not busy reacting to the user. Our software commands the CPU as

though it were in the army, alternately telling it to hurry up and wait. The hurry up part is

great, but the waiting needs to stop.

The division of labor in the computer age is very clear: The computer does the work, and

the user does the thinking. Computer scientists tantalize us with visions of artificial

intelligence: computers that think for themselves. However, users don't really need much

help in the thinking department. They do need a lot of help with the work of information

management--activities like finding and organizing information -- but the actual

decisions made from that information are best made by the wetware -- us.

There is some confusion about smart software. Some naive observers think that smart

software is actually capable of behaving intelligently, but what the term really means is

that these programs are capable of working hard even when conditions are difficult and even

when the user isn't busy. Regardless of our dreams of thinking computers, there is a much

greater and more immediate opportunity in simply getting our computers to work harder.

This lecture discusses some of the most important ways that software can work a bit harder to

serve humans better.

Putting the Idle Cycles to Work

37.8

In our current computing systems, users need to remember too many things, such as the

names they give to files and the precise location of those files in the file system. If a

user wants to find that spreadsheet with the quarterly projections on it again, he must

either remember its name or go browsing. Meanwhile, the processor just sits there, wasting

billions of cycles.

Most current software also takes no notice of context. When a user is struggling with a

particularly difficult spreadsheet on a tight deadline, for example, the program offers precisely

as much help as it offers when he is noodling with numbers in his spare time. Software can

no longer, in good conscience, waste so much idle time while the user works. It is time for

our computers to begin to shoulder more of the burden of work in our day-to-day activities.

Wasted cycles

Most users in normal situations can't do anything in less than a few seconds. That is

enough time for a typical desktop computer to execute at least a billion instructions. Almost

without fail, those interim cycles are dedicated to idling. The processor does nothing

except wait. The argument against putting those cycles to work has always been: "We can't

make assumptions; those assumptions might be wrong." Our computers today are so powerful

that, although the argument is stilt true, it is frequently irrelevant. Simply put, it doesn't

matter if the program's assumptions are wrong; it has enough spare power to make

several assumptions and discard the results of the had ones when the user finally makes

his choice.

355

Human Computer Interaction (CS408)

With Windows and Mac OS X's pre-emptive, threaded multitasking, you can perform

extra work in the background without affecting the performance the user sees. The

program can launch a search for a file, and if the user begins typing, merely abandon

it until the next hiatus. Eventually, the user stops to think, and the program will have time

to scan the whole disk. The user won't even notice.

Every time the program puts up a modal dialog box, it goes into an idle waiting state, doing no

work while the user struggles with the dialog. This should never happen. It would not

be hard for the dialog box to hunt around and find ways to help. What did the user do

last time? The program could, for example, offer the previous choice as a suggestion for

this time.

We need a new, more proactive way of thinking about how software can help people with their

goals and tasks.

Putting the cycles to better use

If your program, Web site, or device could predict what the user is going to do next,

couldn't it provide a better interaction? If your program could know which selections the user

will make in a particular dialog box or form, couldn't that part of the interface be

skipped? Wouldn't you consider advance knowledge of what actions your users take to be an

awesome secret weapon of interface design?

Well, you can predict what your users will do. You can build a sixth sense into your

program that will tell it with uncanny accuracy exactly what the user will do next! All those

billions of wasted processor cycles can be put to great use: All you need to do is give your

interface a memory.

Giving Software a Memory

37.9

When we use the term memory in this context, we don't mean RAM, but rather a

program facility for tracking and responding to user actions over multiple sessions. If

your program simply remembers what the user did the last time (and how), it can use that

remembered behavior as a guide to how it should behave the next time. As we'll see later in

this chapter, your program should remember more than one previous action, but this

simple principle is one of the most effective tools available for designing software

behavior.

You might think that bothering with a memory isn't necessary; it's easier to just ask

the user each time. Programmers are quick to pop up a dialog box to request any

information that isn't lying conveniently around. But as we discussed, people don't like to be

asked questions. Continually interrogating users is not only a form of excise, but from a

psychological perspective, it is a subtle way of expressing doubt about their authority.

Most software is forgetful, remembering little or nothing from execution to execution. If our

programs are smart enough to retain any information during and between uses, it is usually

information that makes the job easier for the programmer and not for the user. The program

willingly discards information about the way it was used, how it was changed, where it was

used, what data g it processed, who used it, and whether and how frequently the various

facilities of the program were used. Meanwhile, the program fills initialization files with

driver-names, port assignments, and other details that ease the programmer's burden. It is possible

to use the exact same facilities to dramatically increase the smarts of your software from the

perspective of the user.

356

Human Computer Interaction (CS408)

Task Coherence

37.10

Does this kind of memory really work? Predicting what a user will do by

remembering what he did -last is based on the principle of task coherence: the idea that our

goals and the way we achieve them (via tasks) is generally the same from day to day. This is not

only true for tasks like brushing our teeth and eating our breakfasts, but it also describes how we

use our word processors, e-mail programs, cell phones, and e-commerce sites.

When a consumer uses your product, there is a high-percentage chance that the functions he

uses and the way he uses them will be very similar to what he did last time he used your

program. He may even be working on the same documents, oral least the same types of

documents, located similar places. Sure, he won't be doing the exact same thing each

time, but it will likely be variant of a small number of repeated patterns. With significant

reliability, you can predict the behavior of your users by the simple expedient of remembering

what they did the last several times they used the program. This allows you to greatly reduce

the number of questions your program must M

Remembering choices and defaults

The way to determine what information the program should remember is with a

simple rule: If it's worth the user entering, it's worth the program remembering.

Any time your program finds itself with a choice, and especially when that choice is

being offered to the user, the program should remember the information from run to run.

Instead of choosing a hard-wired default, the program can use the previous setting as the

default, and it will have a much better chance of giving the user what he wanted. Instead of

asking the user to make a determination, the program should go ahead and make the

same determination the user made last time, and let the user change it if it was wrong.

Whatever options the user set should be remembered, so that the options remain in effect

until manually changed. If the user ignored facilities of the program or turned them off,

they should not be offered to the user again. The user will seek them out when and if he is

ready for them.

One of the most annoying characteristics of programs without memories is that they are so

parsimonious with their assistance regarding files and disks. If there is one place where the

user needs help, it's with files and disks. A program like Word remembers the last place the user

looked for a file. Unfortunately, if the user always puts his files in a directory called Letters,

then edits a document template stored in the Template directory just one time, all his

subsequent letters will be stored in the Template directory rather than in the Letters

directory. So the program must remember more than just the last place the files were

accessed. It must remember the last place files of each type were accessed.

The position of windows should also be remembered, so if you maximized the document last

time it should be maximized next time. If the user positioned it next to another window, it is

positioned the same way the next time without any instruction from the user. Microsoft Office

applications now do a good job of this.

Remembering patterns

The user can benefit in several ways from a program with a good memory. Memory reduces excise,

the useless effort that must be devoted to managing the tool and not doing the work. A

significant portion of the total excise of an interface is in having to explain things to the

program that it should already know. For example, in your word processor, you might often

reverse-out text, making it white on black. To do this, you select some text and change the font

color to white. Without altering the selection, you then set the background color to black. If

357

Human Computer Interaction (CS408)

the program paid enough attention, it would notice the fact that you requested two formatting

steps without an intervening selection option. As far as you're concerned, this is effectively a

single operation. Wouldn't it be nice if the program, upon seeing this unique pattern repeated

several times, automatically created a new format style of this type -- or better yet, created a

new Reverse-Out toolbar control?

Most mainstream programs allow their users to set defaults, but this doesn't fit the

hill as a memory would. Configuration of this kind is an onerous process for all but

power users, and many users will never understand how to customize defaults to their

liking

Actions to Remember

37.11

Everything that users do should be remembered. There is plenty of storage on our hard

drives/ and a memory for your program is a good investment of storage space. We

tend to think that programs are wasteful of disk space because a big horizontal application

might consume 30 or 40 MB of space. That is typical usage for a program, but not for user

data. If your word processor saved 1 KB of execution notes every time you ran it, it still

wouldn't amount to much. Let's say that you use your word processor ten times every business

day. There are approximately 200 workdays per year, so you run the program 2,000 times a

year. The net consumption is still only 2 MB, and that gives an exhaustive recounting

of the entire year! This is probably not much more than the background image you put on

your desktop.

File locations

All file-open facilities should remember where the user gets his files. Most users

only access files from a few directories for each given program. The program

should remember these source directories and offer them on a combo box on the

File-Open dialog. The user should never have to step through the tree to a given

directory more than once.

Deduced information

Software should not simply remember these kinds of explicit facts, but should also

remember useful information that can be deduced from these facts. For example, if the

program remembers the number of bytes changed in the file each time it is opened, it can help

the user with some reasonableness checks. Imagine that the changed-byte-count for a file was

126, 94, 43, 74, 81, 70, 110, and 92. If the user calls up the file and changes 100 bytes,

nothing would be out of the ordinary." But if the number of changed bytes suddenly shoots

up to 5000, the program might suspect that something is amiss. Although there is a chance

that the user has inadvertently done something about which he will be sorry, the probability

of that is low, so it isn't right to bother him with a confirmation dialog. It is, however, very

reasonable for the program to make sure to keep a milestone copy of the file before the 5000

bytes were changed, just in case. The program probably won't need to keep it beyond the

next time the user accesses that file, because the user will likely spot any mistake that

glaring immediately, and he would then demand an undo.

Multi-session undo

Most programs discard their stack of undo actions when the user closes the document or the

program. This is very shortsighted on the program's part. Instead, the program could

358

Human Computer Interaction (CS408)

write the undo stack to a file. When the user reopens the file, the program could

reload its undo stack with the actions the user performed the last time the program was run

-- even if that was a week ago!

Past data entries

A program with a better memory can reduce the number of errors the user makes.

This is simply because the user has to enter less information. More of it will be

entered automatically from the program's memory- In an invoicing program, for

example, if the software enters the date, department number, and other standard fields

from memory, the user has fewer opportunities to make typing errors in these fields.

If the program remembers what the user enters and uses that information for future

reasonableness checks, the program can work to keep erroneous data from being entered.

Imagine a data entry program where zip codes and city names are remembered from run

to run. When the user enters a familiar city name along with an unfamiliar zip code, the

field can turn yellow, indicating uncertainty about the match. And when the user enters

a familiar city name with a zi p code already associated with another city, the field can

turn pink, indicating a more serious ambiguity. He wouldn't necessarily have to take any

action because of these colors, but the warning is there if he wants it.

Some Windows 2000 and XP applications, notably Internet Explorer, have a facility of

similar nature: Named data entry fields remember what has been entered into them

before, and allow the user to pick those values from a combobox. For security-minded

individuals, this feature can be turned off, but for the rest of us, it saves time and

prevents errors.

Foreign application activities on program files

Applications might also leave a small thread running between invocations. This little

program can keep an eye on the files it worked on. It can track where they go and who reads

and writes to them. This information might be helpful to the user when he next runs the

application. When he tries to open a particular file, the program can help him find it,

even if it has been moved. The program can keep the user informed about what other

functions were performed on his file, such as whether or not it was printed or faxed to

someone. Sure, this information might not be needed, but the computer can easily spare

the time, and it's only bits that have to be thrown away, after all.

Applying Memory to Your Applications

37.12

A remarkable thing happens to the software design process when developers accept the

power of task coherence. Designers find that their thinking takes on a whole new

quality. The normally unquestioned recourse of popping up a dialog box gets replaced

with a more studied process, where the designer asks questions of much greater subtlety.

Questions like: How much should the program remember? Which aspects should be

remembered? Should the program remember more than just the last setting? What

constitutes a change in pattern? Designers start to imagine situations like this: The user

accepts the same date format 50 times in a row, and then manually enters a different format

once. The next time the user enters a date, which format should the program use? The

format used 50 times or the more recent one-time format? How many times must the new

format be specified before it becomes the default? Just because there is ambiguity

359

Human Computer Interaction (CS408)

here, the program still shouldn't ask the user. It must use its initiative to make a

reasonable decision. The user is free to override the program's decision if it is the wrong one.

The following sections explain some characteristic patterns in the ways people make

choices that can help us resolve these more complex questions about task coherence.

Decision-set reduction

People tend to reduce an infinite set of choices down to a small, finite set of

choices. Even when you don't do the exact same thing each time, you will tend to

choose your actions from a small, repetitive set of options. People unconsciously

perform this decision-set reduction, but software can take notice and act upon it.

For example, just because you went shopping at Safeway yesterday doesn't necessarily

mean that you will be shopping at Safeway exclusively. However, the next time you

need groceries, you will probably shop at Safeway again. Similarly, even though your

favorite Chinese restaurant has 250 items on the menu, chances are that you will usually

choose from your own personal subset of five or six favorites. When people drive to and

from work, they usually choose from a small number of favorite routes, depending on

traffic conditions. Computers, of course, can remember four or five things without breaking a

sweat.

Although simply remembering the last action is better than not remembering anything, it

can lead to a peculiar pathology if the decision-set consists of precisely two elements. If, for

example, you alternately read files from one directory and store them in another, each

time the program offers you the last directory, it will be guaranteed to be wrong. The

solution is to remember more than just one previous choice.

Decision-set reduction guides us to the idea that pieces of information the program

must remember about the user's choices tend to come in groups. Instead of there being one

right way, there will be several options that are all correct. The program should look for

more subtle clues to differentiate which one of the small set is correct. For example, if you

use a check-writing program to pay your bills, the program may very quickly learn that

only two or three accounts are used regularly. Rut how can it determine from a given

check which of the three accounts is the most likely to be appropriate? If the program

remembers the payees and amounts on an account-by-account basis, that decision would be

easy. Every time you pay the rent, it is the exact same amount! It's the same with a car

payment. The amount paid to the electric company might vary from check to check, but

it probably stays within 10 or 20 percent of the last check written to them. All this

information can be used to help the program recognize what is going on, and use that

information to help the user.

Preference thresholds

The decisions people make tend to fall into two primary categories: important and

unimportant. Any given activity may involve potentially hundreds of decisions, but

only a very few of them are important. All the rest are insignificant. Software

interfaces can use this idea of preference thresholds to simplify tasks for users.

After you decide to buy that car, you don't really care who finances it as long as the terms

are competitive. After you decide to buy groceries, the particular checkout aisle you

select is not important. After you decide to ride the Matterhorn, you don't really care

which toboggan they seat you in.

Preference thresholds guide us in our user interface design by demonstrating that

asking the user for successively detailed decisions about a procedure is unnecessary.

360

Human Computer Interaction (CS408)

After the user asks to print, we don't have to ask him how many copies he wants or

whether the image is landscape or portrait. We can make an assumption about these

things the first time out, and then remember them for all subsequent invocations. If

the user wants to change them, he can always request the Printer Options dialog box.

Using preference thresholds, we can easily track which facilities of the program the

user likes to adjust and which are set once and ignored. With this knowledge, the

program can offer choices where it has an expectation that the user will want to take

control, not bothering the user with decisions he won't care about.

Mostly right, most of the time

Task coherence predicts what the user will do in the future with reasonable, but not

absolute, certainty. If our program relies on this principle, i t s natural to wonder

about the uncertainty of our predictions. If we can reliably predict what the user will do

80% of the time, it means that 20% of the time we will be wrong. It might seem that the

proper step to take here is to offer the user a choice, but this means that the user will be

bothered by an unnecessary dialog 80% of the time, Rather than offering a choice, the

program should go ahead and do what it thinks is most appropriate and allow the user to

override or undo it. If the undo facility is sufficiently easy to use and understand, the user won't

be bothered by it. After all, he will have to use undo only two times out of ten instead of

having to deal with a redundant dialog box eight times out of ten. This is a much better deal for

humans.

Memory Makes a Difference

37.13

One of the main reasons our software is often so difficult to use is because its

designers have made rational, logical assumptions that, unfortunately, are very wrong.

They assume that the behavior of users is random and unpredictable, and that users must

be interrogated to determine the proper course of action. Although human behavior

certainly isn't deterministic like that of a digital computer, it is rarely random, and

asking silly questions is predictably frustrating for users.

However, when we apply memory via task coherence to our software, we can realize

great advantages in user efficiency and satisfaction. We would all like to have an assistant who is

intelligent and self-motivated, one who shows initiative and drive, and who demonstrates

good judgment and a keen memory. A program that makes effective use of its memory would

be more like that self-motivated assistant, remembering helpful information and personal

preferences from execution to execution without needing to ask. Simple things can make a

big difference: the difference between a product your users tolerate, and one that they love.

The next time you find your program asking your users a question, make it ask itself one

instead.

361

Table of Contents: