© 2005 icarnegie, inc. 1 unit 2 interfaces : evaluating with usability heuristics

© 2005 iCarnegie, Inc. 1

Unit 2Interfaces : Evaluating with Usability Heuristics


2.1 Creating with Labels — Evaluating with Two Heuristics

• 2.1.1 Lablels • 2.1.2 HE: Match System to Real World • 2.1.3 HE: Visibility of System Status


2.1.1 Labels


2.1.2 HE Match system to Real world

1. Real-World Concepts

"desktop metaphor "

2. Real-World Language

"Speak the user's language."



• Real-World Conventions( 惯例 )– Printed matter is read in a specific order (for English,

this is left-to-right, top-to-bottom). – Things that are the biggest are probably the most

important. – Things that are visually grouped together probably

have something to do with each other semantically. Things that are separated by white space are less likely to be related.

– Something that happens right after you do something is probably caused by what you just did.



4. Cultural Issues Describe Date in different format

• Date/Time Control Panel Applications of this Heuristic

match between system and real world



• Example UAR: Aspect 1 — Presentation of the date speaks the users' language. Follow Real-World Conventions

UAR IdentifierHE1—Good Feature

This name indicates that this is our first UAR using Heuristic Evaluation.

Succinct description:Presentation of the date speaks the users'

language.This phrase sums up our assessment of the aspect.



Evidence for the aspect:

Heuristic: Match between system and the real world.

First, we again identify the heuristic used to assess the aspect.

Then, we provide the interface aspect to which we applied the heuristic. As you see above, we use an actual screen-shot to make the report more concrete.



Interface aspect:

The label for the presentation of the date is U.S. residents typically present dates as name of the month, number of the day of the month, and year.

Above we supply the actual real-world language the aspect uses. This is direct evidence for the match: you can see (as a reader of the report) the interface and the real-world language here and judge whether they match.



Explanation of the aspect:The format of the date in the interface and the

format that U.S. residents expect match exactly.• Sometimes the explanation is so obvious that it is

redundant(多余的 ) next to the evidence. This is OK and happens often with heuristic evaluation. But we'll see in the material examples as we go along where the explanation is not as obvious, especially in the think-aloud usability studies.

Also, since the interface we are analyzing right now is so small, we don't have to provide any additional context.



Benefit of the good feature:

The users will be able to recognize the date immediately, without having to translate it from another format.

Again, this benefit seems pretty obvious. This is OK. It should still be reported (although briefly) because those making future design decisions may need to be reminded of obvious things.



Solution:

Although this format is right for U.S. residents, it may not be correct for other cultures. For example, Europeans typically put the day of the month first, then the month, and then the year. If this product is going to be sold globally, we'll have to discover the other formats that are typically used among our user group and tailor the interface for those other users.

• There is no actual “solution” because this is not a problem: it‘s a good feature to be preserved in future versions. However, this is also the slot where you record any possible trade-offs(替换 ) you can think of with respect to other design possibilities. Therefore, we should record here that presentation of the date is culturally dependent.



Relationship to other UARs:

No relationships apparent at this time.

Because this is the first UAR we are recording, there are no relationships to other UARs. So, this slot remains empty at this time. With each new UAR, we will examine all the previous UARs up to that point and make connections back to them as needed.

Typically,1) you make connections by looking at UARs that concern other aspects on the same screen, 　 2) other aspects that violate (or follow) the same heuristic, 　　 3) other aspects that would be used in the same task a user might have to perform.



• Example UAR: Aspect 2 — Map Very Good But Not Interactive, Does Not Follow Real-World Conventions

UAR Identifier

HE2—Problem

This name indicates that this is our second UAR using heuristic evaluation.



Succinct description:

Map is sufficiently prominent to invite interaction, but it doesn't interact.

　　　 http://www.chinamap.com

This phrase sums up our assessment of the aspect.



Evidence for the aspect:Heuristic: Match between system and the real world.

First, we again identify the heuristic used to assess the aspect. You can copy-and-paste this from UAR HE1. Since you are likely to be looking at these UARs out of order and by themselves sometime in the future, it is important for each UAR to "stand on its own"—that is, have all the information it needs to be understood alone. Therefore, you will need to include the heuristic in each HE UAR. This may seem redundant, but it is important for the future use of the reports. So, do it—but use copy-and-paste to save yourself work.Again, we use an actual screen-shot below to make the report concrete.



Interface aspect:

Given the screen, the map image takes up more than half the control panel's screen real estate, making it the largest thing on the control panel.

The real-world convention is that the biggest things are the most important for giving information or interacting.



Explanation of the aspect:

The image of the map is so large that it invites interaction, but it doesn't interact. The user gets no reaction if they click it or drag across it. It doesn't even show any information about the time zone, which makes us wonder why it is even present in this simple prototype.

Here the explanation is more than just repeating the evidence.

You may often find yourself wondering at times about aspects of an interface, later, when you understand more about it, you find a convincing rationale. If that is the case, you can always revisit the previous UARs and answer the questions you wondered about when you originally wrote them.

But, It is a good idea to record questions such as these as they come up—because if they are never answered to your satisfaction, you should consider redesigning the interface to eliminate the irrelevant aspects.



Severity of the problem:• The user will probably quickly learn that

this map doesn't give them any information or any opportunity for interaction, so this will probably be a problem only for the first-time user. However, this image takes up so much screen space that it might (妨碍 ) with other information we may want to present in the interface.

This statement of severity considers how often the user may encounter the problem as well as what other problems this image might cause.



Solution:Consider delete the map altogether.

Or consider increasing its importance, at least in providing

information, by (for example) putting in the lines that (指示 ) the different time zones (a possible difficulty with this: some time zone lines are very complicated when they go around certain countries or areas—such as some Native American Indian reservations). Will have to look up where all the irregularities with time zones occur. And Do some places not have daylight savings time.

Make sure to record any possible difficulties you can think of with the solutions you propose. Even if you don't know for sure, but think there might be a problem, make a note that you'll have to determine the details (as we did here with the instruction to find out more and the question about daylight savings time).




No relationships apparent at this time.

Glancing back at UAR #HE1, it seems to have no relationship to this UAR. That's fine, but always check anyway, even though you don't expect to see too many relationships until you have a larger number of UARs.


2.1.3 HE: Visibility of System Status

Provide Feedback — Keep the User Informed About the Stages of a Process

Most users become uncomfortable when they have initiated a command but there is no immediate activity to indicate that the command has been received and is being executed.

1. selects the File/Open command

2. copy bar

3. The hourglass when the computer is doing something.



(continue)

　The following series of messages appears on the screen as the modem dials

1) dialing 02988312255 2) checking username and password 3) registering user on network Feedback can take many forms—an icon changing shape, a menu item

blinking briefly as it is selected, a message, a dialog box, an alarm, an audio clip, or an animation, to name just a few.

Warn of irreversible actions. Guide users along a multi-step path. Messages should be in the user’s term, not computerese.



Don’t Make the User Guess· Showing the filename on the title bar of a

document keeps users informed about what files are in each window.

· Dimming or shading a menu option is another example of applying the visibility heuristic. The dimming tells users the status of the option—that the option is not currently available.

· Icons show the presence of applications or documents.



Example UAR: Aspect 3 — Button Labels Are Good –It shows the Date the Computer Is Set To

UAR Identifier

HE3—Good Feature


Presentation of the date shows what date the computer is set to.


Heuristic: Visibility of system status.



Interface aspect:

The label for the presentation of the date, is generated by

code that takes the date from the system clock. Therefore, it is actually displaying what date the system clock is set to.


Since the date presented to the user is programmatically generated from the system clock, it will always show the actual status of the system clock.


The users will always know the date the computer is set to. This will benefit all users—novice, occasional, and expert.



Solution:

I can't imagine a downside to this implementation.　Relationship to other UARs:

UAR# HE1—Good Feature: Presentation of the date in the users' language.

This UAR is the second UAR that praises the presentation of the date. It is an accurate reflection of the computer's state, and it is presented to the user in a way that will be understood. Preserve these features of the date.


2.2 Creating with Buttons — Evaluating with Three Heuristics

• 2.2.1 Buttons.• 2.2.2 HE: Consistency and Standards. • 2.2.3 HE: User Control and Freedom. • 2.2.4 HE: Flexibility and Efficiency of Use.


2.2.1 Buttons

In Unit 1


2.2.2 HE: Consistency and Standards

• Don’t Frustrate the User

When one screen requires a specific series of actions, users will expect the same series of actions to be required under similar conditions.



• Maintain Platform Consistency 1. User frustration(受挫 ) is minimized when products adhere to

platform conventions. An example of a platform convention is the location and contents of the File menu—the File menu option is always the leftmost item on a Windows-style menu bar—and users can expect to find File menu commands for opening, closing, saving, printing, and quitting.

2. Users are able to learn new products quickly. That is, users don’t have to learn new locations or sequences for common commands (such as Open, Close, Save, Print, and Exit/Quit). Hence, they can concentrate on(集中 , 全神贯注于 ) learning the commands that are unique to the product.


2.2.2 HE: Consistency and Standards• Other areas where consistency is important

are:1. Key bindings(捆绑 )—keyboard shortcuts should comply with platform

and application standards. 2. Messages, warnings, and alarms—messages, warnings, and alarms

should be consistent in their wording and in where they appear. 3. Color semantics(语义学 )—colors, when they are used as codes,

should keep the same meaning throughout. 4. Formatting—formatting styles for date and time, monetary units, and

numbers should be kept consistent. 5. Dialog boxes—dialog boxes should be consistent in their

presentations. 6. Data presentation—aspects of data presentation (such as labeling,

capitalization, font face, use of bold and italic, and the placement of fields) should be kept consistent.

7. Terminology(术语学 )—words used to describe actions, behaviors, and commands should be kept consistent.



• Example UAR: Aspect 5 — Button Labels Are Good


2.2.2 HE: Consistency and StandardsExample UAR: Aspect 5 — Button Labels Are

Good

UAR Identifier

HE5—Good Feature


"OK", "Cancel", and "Apply" button labels follow Windows standards.


Heuristic: Consistency and standards (in particular, the "standards" part of this heuristic)


2.2.2 HE: Consistency and StandardsInterface aspect:

The buttons at the bottom of the screen are labeled "OK", "Cancel", and "Apply"—as shown in the table right.

In the online MSDN　Library　Visual　Studio　6.0　,it lists the following standard ways to close the property sheet:

Command

Action

OKApplies all pending changes and closes the property sheet window.

Apply Applies all pending changes but leaves the property sheet window open.

Cancel Discards any pending changes and closes the property sheet window. Does not cancel or undo changes that have already been applied.


2.2.2 HE: Consistency and StandardsExplanation of the aspect:

All the standard ways to close the property sheet are present and work as described.


Users will be able to use their prior knowledge of Microsoft products with this control panel.

Solution:

I cannot think of any drawbacks to using the standard button labels and actions at this time.


None when this UAR was originally written.


2.2.2 HE: Consistency and StandardsExample UAR: Aspect 6 — Button Names Are

Very Similar

UAR Identifier

HE6—Problem


The difference between "OK" and "Apply" is not obvious.


Heuristic: Consistency and standards (in particular, the "consistency" part of this heuristic)



Interface aspect:

The button labels "OK" and "Apply" have very similar definitions in lay English.

Definition of "OK" in Webster's New Collegiate Dictionary: approve, authorize.

In the context of just making changes to something, the changes are the things that are approved or authorized.

Definition of "apply" in Webster's New Collegiate Dictionary: To put into effect.

In the context of just making changes to something, these changes are the things that will be put into effect.




The difference between "OK" and "Apply" is not obvious to the user. From common definitions of the words, it would seem that they do the same thing: make the changes that the user just indicated in the control panel. Since the words are different, the actions should also be different according to the consistency and standards heuristic, but the difference between the actions should be reflected in the words used to label them.

According to the Design Guide passage quoted above, both buttons apply the changes the user made to the property sheet. The only difference is that the Apply button leaves the property sheet open and the OK button closes the property sheet. Unfortunately, this difference is not inherent(固有的 , 与生俱来的 ) in the meanings of the labels.


2.2.2 HE: Consistency and StandardsSeverity of the problem:

The users will probably learn the difference between these buttons pretty quickly, especially if they use other Windows products.

Solution:

Change the labels to reflect the real difference in the actions. Perhaps use "Apply" and "Apply & Close".

However, following this solution will violate the Windows Design Guide conventions and, therefore, will violate the standards part of the same heuristic. The buttons “OK” and “Cancel” were standardized long before dialog boxes that needed “Apply” were in use. Therefore, the terms have been “inherited(继承 )" with a lot of users knowing what they mean. It will not be easy to change away from the "OK" label.


2.2.2 HE: Consistency and StandardsRelationship to other UARs:

UAR# HE5 – Good Feature: "OK", "Cancel," and "Apply" button labels follow Windows

standards.

This heuristic seems to give conflicting advice. Perhaps we'll have to do user testing—or at least conduct a survey or some interviews—to see if our users will really have problems with "Apply" and "OK".

Having identified a relationship to UAR# HE5 we would go back to that UAR and write the relationship to this UAR in its Relationship to other UARs slot. In addition, since HE6 is a direct contradiction of HE5, this needs to be recorded in the Solution slot of HE5 as well as the Relationship to other UARs slot.


2.2.2 HE: Consistency and Standards• Important — When Heuristics Conflict(冲突 )

If they point in different directions, you have to do something in addition to HE to figure out how to design your interface. First, you should think hard about whether the conflicting advice makes any real difference to the user. For instance, you can do an error analysis as follows.

Let's assume that the user does not understand the difference between the labels Apply and OK, but does understand the difference between the functions they perform. If the user wanted to apply the changes and close the property sheet, she or he should hit the OK button, but what if she or he hits the Apply button instead? This is not a big problem, because the Apply button applies the change and leaves the window open. The user did not get the desired result (changes applied and the window closed), but she did get part of it (changes applied). Also, the window is obviously still open, so the mistake is easy to detect. She can now simply try the OK button (or even click the little "x" button on the window itself) and will then be exactly in the state she wants to be in. Thus, the error will be detected, and the "cost" of recovering from this error caused by this possibly poor interface is only a single keystroke or mouse click..



Let's now assume that the user wanted to apply the changes and leave the window open, but hit the OK button to do that. Then the changes are applied (the result she wanted) and the window closes (an undesired result). Now the user immediately sees that the window is no longer open (the error is again easy to detect). She must re-open the control panel, but again, this is a relatively inexpensive operation, involving at most one or two clicks of the mouse.

Thus, this error analysis suggests that the cost of confusing the two buttons because their labels do not reflect the actual differences in their functions is relatively small. Therefore, it is better to go with the standard labels because there really are great benefits to be had from adhering to platform standards.


2.2.3 User Control and Freedom

• Let the User Be in Control

The sense of "who's in charge" strongly affects how a user feels about an application.

Their tone should suggest that the computer is ready and compliant(顺从的 ), not commanding or threatening, and that the user, not the computer, is in charge.



• Provide an Undo Mechanism

1. An undo command that reverses the most recent command is common in many applications. The simplest form only allows the user to reverse the most recent command. Some applications allow the user to reverse several steps.

2. A “Reset” or “Factory(机构 ) Settings" button is another form of undo mechanism.



• Require Confirmation （确认 , 批准）

The user should be warned when an irreversible（不能撤回的） action is about to be initiated. An application should require an explicit confirmation before allowing an irreversible step to be set in motion.



• Provide an Escape Route

Users should be able to halt processes. A typical way to provide for this is to offer a Cancel button at all times. —the user should be warned that canceling could have negative consequences and should be advised of an alternative way to halt or reverse the process.



• Example UAR: Aspect 7 — Cancel Button Is Good —Provides an “emergency exit”

• Example UAR: Aspect 8 — UARs Sometimes Lead to More UARs.



Example UAR: Aspect 8 — UARs Sometimes Lead to More UARs.

UAR Identifier HE8—Problem

Succinct description: Cancel doesn't give feedback when it doesn't

cancel anything Evidence for the aspect:

Heuristic: Visibility of system status



Interface aspect: There is a Cancel button at the bottom of the screen, as shown

in the picture below:

In the online MSDN Library Visual Studio 6.0, it lists the following specification of the Cancel button's action:

CancelDiscards any pending(悬而未决 ) changes and closes the property sheet window. Does not cancel or undo changes that have already been applied.

As specified in the Design Guide, if changes are made in the property box and then the Apply button is pressed, those changes are made permanent and cannot be discarded by clicking the Cancel button. However, there is no visual indication that these changes are not available to be canceled; the Cancel button still looks active. In effect, if the Cancel button is clicked right after the Apply button is clicked, the Cancel button will behave exactly like the OK button: it will simply close the window.




The Windows Design Guide does not seem to give advice about whether the standard buttons should be available (black) or unavailable (gray) at any particular time. However, this Date/Time control panel tab (labeled "Date & Time") makes the Apply button unavailable (gray) when there are no changes to be applied, and it will have no effect. The Cancel button is not grayed out when there are no changes to cancel, presumably because it will still have an effect (i.e., closing the window), but it will NOT have the effect it was labeled for (i.e., canceling something) if the changes have been applied.



Severity of the problem:

This can be a rather severe problem if there is no way the user can check the status of the property box once it is closed—or even if the information is on the screen but difficult to see. In this case, many users will have the clock in very small font down in the bottom right corner where they may never have occasion to look. This is severe because users may think they've canceled changes when they haven't: in reality, the changes have been applied to the system clock. This change will affect the dating of files and e-mail messages and, therefore, can have wide-reaching consequences.


2.2.3 User Control and FreedomSolution:

Make the Cancel button unavailable (gray) when there are no changes to cancel. Thus, the Apply and Cancel buttons will either be available (black) or unavailable (gray) at the same time—depending on whether or not there are changes to apply or cancel.

When there are no unapplied changes, only the OK button will be available (black), and it will close the window.

Note that this train of thought could continue to the point of reconsidering if the OK button should also be gray when there are no unapplied changes made. The window could always be closed with the Close button (labeled with an "x") in the top right corner of the window. A complete analysis of this issue would generate at least one more UAR to discuss the OK button, links between all these UARs, and a group UAR to discuss them all as a group.



The Windows Design Guide seems to be silent on the issue of active/inactive Property Sheet command buttons, so graying the Cancel button would not violate an explicit platform standard.

However, we might want to look at several other applications with property boxes to see if there is a de facto standard, or see if people in user tests are confused by the Cancel button becoming unavailable (gray).


UAR# HE7—Good Feature: "Cancel" button provides an "emergency exit."



It is quite possible that as you write up one UAR about a good feature or problem, you will discover other usability aspects that warrant their own UARs. When this happens, just record in the first UAR that another UAR is connected; then write the second UAR. For example, while writing UAR# HE7 above, we discovered that the Cancel button doesn't always cancel something, and when it does not, it doesn't indicate that fact. We discovered this when we were thinking about trade-offs and writing in the Solution slot. Therefore, we put a note in that slot referring readers to the next UAR, UAR# HE8. Likewise, we listed UAR# HE8 in UAR# HE7's Relationship to other UARs slot.


2.2.4 HE: Flexibility and Efficiency of Use

• Provide Keyboard Shortcuts

Examples of keyboard shortcuts:

1. On the Macintosh, when a choice of buttons is presented, the button outlined in bold can be "pressed" by hitting the RETURN key.

2. Common commands like opening and closing documents in an application, printing, saving, and quitting can be issued using keyboard shortcuts such as CTRL-O (under Windows) or Command-O (under MacOS).

3. Windows 95/NT/98 provides an additional keyboard shortcut mechanism. The underlined letter of a menu item indicates that menu option can be invoked by hitting the ALT key and the underlined letter together. For example, opening a file can be accomplished by hitting the F key and then the O key while holding down the ALT key—or simply by pressing CTRL-O.



• Allow for Customization 1. Speed: Power users want to maximize speed, typically by adding

keyboard shortcuts in order to reduce the amount of time they use the mouse.

2. Appearance: Some people are strongly affected by the amount of clutter on their screen. Giving users control over secondary menus and toolbars within an application as well as icon placement on the background gives users control over how their computer looks.

3. Readability: Other users (such as elderly users) may require a large font for readability reasons or reverse-video (white text on a black background) to reduce eyestrain. Giving users control over the computer’s background, font face and size, and other display settings allows users to adapt these according to their needs and preferences



• Date/Time Control Panel Applications of this Heuristic • Example UAR: Aspect 9 —Button Accelerators Exist



• Not Every Facet of Every Heuristic Applies to Every Interface

For example, there is no way for users to tailor their frequent actions in this control panel. However, this facet of the flexibility and efficiency of use heuristic doesn't really apply to this control panel.

Because:

First, this is a control panel that won't be used very often, so users will not really have "frequent actions."

Second, the actions on this control panel are so simple that they are already quite efficient.

Thus, you need to question whether every facet of a heuristic applies—and the answer might often be "no."

© 2005 icarnegie, inc. 1 unit 2 interfaces : evaluating with usability heuristics

Documents

match system

heuristic match

real world interface

real world evidence

real world explanation

real world benefit

real world example uar

real world cultural