IS 485: User Interface Design, Prototyping, and Evaluation
Professor Thatcher
Heuristic Evaluation of a Paper Mock-Up
Aggregated List of Heuristic Violations for the TRAVELweather Interface
1. [H2-8: Aesthetic and Minimalist Design]
The name of the system is displayed too prominently. It dominates the interface, makes the
interface look cluttered, and attracts the user’s attention away from the most important
aspects of the interface – the map itself. Making the name smaller would allow more room
for some other design elements or make the screen look less busy.
2. [H2-2: Match Between System and Real World] or [H2-6: Recognition vs. Recall]
It is difficult for the user to recognize the location on the map (which is the point of a map!!).
The map should list the names of at least a few major cities or locations so users can recognize
the map. To avoid clutter, maybe have pop-up names when the mouse goes over a certain
location.
3.
[H2-2: Match Between System and Real World]
The map shows the northeastern US from New England over New York and New Jersey to
Delaware (as well as part of Canada). However, this may not be clear to users that are not
familiar with this part of the country (or this part of the world). Make the borders and
boundaries of these locations clear to the user.
4. [H2-2: Match Between System and Real World]
The pattern used to denote water (i.e., oceans and lakes) does not make it sufficiently clear what
parts of the map represents land and which parts represent water. This distinction could be made
more clear by using a wavy pattern or the color blue to represent the water or by including
distinguishing characteristics on the land (e.g., mountain ranges, canyons, etc).
5. [H2-2: Match Between System and Real World]
The map does not represent Long Island as an island, which may cause some confusion for
users. The map should be changed to account for this discrepancy.
6.
[H2-1: Visibility of System Status]
There is no way that the user can know that the box with a date and time can be edited since
there is no label, prompt, help text or any other visual clue. Many users will press enter and they
will be left wondering as nothing happens. The interface should provide a visual clue for the
user. One way to reduce the likelihood of this problem is to have an explicit “update” or “find it”
button.
7. [H2-5: Prevent Errors]
The day / month / year date format may be misinterpreted by foreign tourists who may not be
familiar with this edit mask convention. It may be possible to avoid this problem by representing
months by their names instead of their number.
8. [H2-2: Match Between System and Real World]
The zeros in the dates have slashes (the way the computer represents a zero – this is a
technology-centered representation). Use a typeface with regular 0s.
9. [H2-9: Help User Recognize, Diagnose, and Recover From Errors]
The error message “Weather Data is Not Available” is neither precise nor constructive. Instead,
the system should show the date and time entered by user and explain why either or both of these
inputs were invalid. Use different error messages for: 1) time and date formatted incorrectly
(picture checks), 2) times and dates that are not within the valid interval (limit / range checks) –
weather info is only available for specific times and dates, and 3) times that are not one of the
four hours where information is available interval (limit / range checks). As an example, if the
user entered a valid date but an invalid time, the system should provide an error message that
says “Weather information is only available for 3AM, 9AM, 3PM, and 9PM – Please enter one
of these times”.
10. [H2-9: Help User Recognize, Diagnose, and Recover From Errors]
When the user enters an invalid time or date, the system provides an error message, forces the
user to press “OK”, and then deletes the users inputs. Users should not be punished for making
errors by having the system delete their inputs (and resetting to a previous value). The invalid
input should be retained to allow the user to edit it; alternatively, the system could put the
incorrect input in the error box and allow the users to correct their mistakes in the error message
box.
11. [H2-5: Prevent Errors]
Having users enter a complete date and time is error prone, especially since there are only 12
valid combinations (3 valid days, 4 valid times). The system could provide a drop-down list
box with the twelve times that weather information is available.
12. [H2-2: Match Between System and Real World]
The word precipitation may be confusing to some users, especially foreign users (foreign users
are apparently envisioned as users since there is a Fahrenheit/Celsius option on the interface).
One option may be to use simpler words like Rain/Snow/Humidity. Using icons (e.g., raindrops
or snow flakes for precipitation and a thermometer for temperature) may also make the interface
easier for foreign users to use (i.e., enhance international usability).
13. [H2-2: Match Between System and Real World]
The word visibility is also unclear and may be confusing to users.
14. [H2-2: Match Between System and Real World]
The label “F” and “C” may be confusing for some users. Maybe spell out the words Fahrenheit
and Celsius to make it more clear. Alternatively, it may be more clear for the user if the letters
“F” and “C” were preceded (or followed) by a degrees mark (e.g., ºF and ºC).
15. [H2-4: Consistency and Standards]
The display of temperature on the map in Fahrenheit and Celsius are mutually exclusive, with
exactly one of the two things being active at any one time. Therefore, the choice of temperature
2
scales should be represented by option (or radio) buttons and not check boxes (which are used
for options that are not mutually exclusive). This problem violates consistency with GUI
standards.
16. [H2-8: Aesthetic and Minimalist Design]
F/C is not an additional feature that is the same as Temperature / Precipitation / Visibility /
Wind selection. The F/C option should be grouped with the Temperature option and should
be grayed out until the Temperature is selected. For another related problem see Problem #
17.
17. [H2-4: Consistency and Standards]
While the interface specifies the unit of measure for the temperature with the F/C option, it
does not specify the unit of measures for the other three options: Precipitation (inches,
centimeters??), Visibility (feet, meters, miles, kilometers??), and Wind (miles per hour,
kilometers per hour??). This may be resolved by allowing the F/C option to be active only
when the Temperature is selected by the user and by having this F/C option change to
another unit of measure based on the users’ selection of precipitation, visibility, or wind.
Alternatively, these measures can be made available within the map itself based on which
option is selected.
18. [H2-6: Recognition vs. Recall]
Some advanced users may want to see lots of weather information together to get a better,
more meaningful sense of the weather patterns. This way they do not have to try and
remember the temperatures as they look at the precipitation and wind characteristics. It
might be better to not make the four weather options mutually exclusive (as indicated by the
radio buttons) – check boxes may be a better choice of design element. But the default
should still have only one option selected so the system looks approachable to the novice.
This problem could also violate the heuristic of [H2-2: Match Between System and Real
World] since most users will be familiar with weather maps from TV news which typically
show many weather dimensions on a single map.
19. [H2-5: Prevent Errors]
It is possible to enter a magnification level of zero in this interface, even though that value
will likely lead to an undefined result. Also, the user may enter extremely large
magnification values, resulting in an unreadable map. The interface should provide the user
with valid ranges she may enter for this input. This may help prevent users from entering
unreasonable magnification levels.
20. [H2-9: Help User Recognize, Diagnose, and Recover From Errors]
Beeping is a poor error message for the magnification box. The system needs a more precise and
constructive error message saying that only numbers can be entered.
21. [H2-9: Help User Recognize, Diagnose, and Recover From Errors]
Some users may be deaf, have a hearing impairment, or use the system in a noisy environment.
Such users may not even hear the beep after they enter an error into the magnification box.
Therefore, they may be unable to recognize an error has been made at all.
3
22. [H2-2: Match Between System and Real World]
It may not be clear to users what a magnification level of 6 means. Is a magnification of 8 bigger
or smaller? It may be more intuitive for users to use a slider or a zoom-in and zoom-out button
to adjust the magnification level. This may be easier for users since many of them will be
familiar with these design elements from Microsoft products.
23. [H2-2: Match Between System and Real World]
Some users may not understand that the numbers listed in the map center box represent measures
of longitude and latitude and will therefore be unable to navigate through the map. To make this
more clear the system should display degree marks as part of its default entry in the map center
box. The system should accept user input without the degree marks – but a default with degrees
will make it easier for the user to interpret.
24. [H2-2: Match Between System and Real World]
The navigation method on the UI will be awkward for many users. Many people will not be
comfortable entering map locations as degrees of longitude and latitude; therefore, navigating
the map will be awkward. The system should let the user choose a location by clicking on
the map with the mouse (or point with finger if it is a walk-up machine) or using scroll bars.
25. [H2-7: Flexibility and Efficiency of Use]
The system does not provide a search option where the user can enter the city or state or
whatever they want to view. Most users like search options; however, if the system provides
the user with a search option make sure that the search engine works well! (e.g., it should be
very tolerant of spelling mistakes)
26. [H2-3: User Control and Freedom]
Several users may want to use the system to find weather information for a date/time combo
other than the 12 provided. This may frustrate users who need to know the weather forecast for
one of these other times.
27. [H2-7: Flexibility and Efficiency of Use]
Several users may want to use the system to view weather information over a period of time.
However, they cannot do so with the system as it is. It may be useful to add a feature to get full
weather information over a period of time for a single city in a single display rather than
requiring the user to select multiple times and multiple data types. This should be a separate
window with some extra summary information.
28. [H2-7: Flexibility and Efficiency of Use]
If the system will be used by the same users repeatedly, it may be useful to provide a shortcut
that is presently not available. The same person may want to get information about the same
areas each time they use the system. It might be helpful if the system remember the last 5 or
10 map locations that the user entered and allow fast and easy access to that information
through a pop-up menu, a drop-down list box, a most frequently used list, or something like
that. This can also be helped by carefully setting default values.
4
29. [H2-7: Flexibility and Efficiency of Use]
There is no way for a user to quickly and easily go back to a previous screen. The system
should provide the user with a “Back” option so the user can get easy and quick access to
previously viewed map information.
30. [H2-9: Help User Recognize, Diagnose, and Recover From Errors]
The error message “Unknown map coordinates” is neither precise nor constructive. Error
message should repeat the user’s input and give different error messages depending on whether
the user has entered incorrectly formatted coordinates (picture check) or coordinates that are out
of bounds (limit / range checks).
31. [H2-5: Prevent Errors]
The system is not forgiving in its acceptance of longitudes. For example, if the user enters 190E
in the map center box, the system should interpret this input as 170W.
32. [H2-5: Prevent Errors]
The system is not forgiving in its acceptance of latitudes. For example, 0 degrees (the Equator)
should not require a letter (N or S) to specify a hemisphere. Similarly, latitudes 90N (the North
Pole) and 90S (the South Pole) should not require specifications for a longitude.
33. [H2-3: User Control and Freedom]
It is not clear how a user would exit the TRAVELweather system. Provide a clearly marked exit
for the user so she can leave the program when she is done. Add a close box or a quit button.
34. [H2-7: Flexibility and Efficiency of Use]
The user will usually try to center the map around a location and zoom. Maybe it would be
faster to let the user combine these actions by pointing and clicking. For example, the user may
put a square around the area that she wants centered and magnified.
35. [H2-10: Help and Documentation]
The system has no help feature. Hopefully a redesign will eliminate the need for one, but a help
screen is probably necessary given the complexity of the system.
36. [H2-8: Aesthetic and Minimalist Design]
The term “Zoom Specifications” is redundant. “Magnification” and “Map Center” should not be
enclosed in the box labeled “Zoom Specification”. Just get rid of it.
37. [H2-2: Match Between System and Real World]
The term “Map Center” may not be clear to the user. It may be better to use different term.
38. [H2-1: Visibility of System Status] or [H2-5: Error Prevention]
If a person is trying to find out about the weather in a location in a different time zone, it may not
be clear which location the time input refers to. Does it refer to the time in the city that you are
using the system or does it refer to the local time of the city about which you are request weather
information. For example, assume a user is in Los Angeles and wants to find the weather
conditions in London (it’s about a 9 hour time difference). However, the user wants to know the
5
weather conditions as of 9 PM London time. What should the user put in the time text box – 9
PM or 9 AM?
39. [H2-4: Consistency and Standards]
The title of the software program “TRAVELweather” is written in an unusual combination of
uppercase and lowercase letters. In general, it is better to only capitalize the first letter of a word
(or maybe in this case make the letters “T” and “W” uppercase). In addition, if anything is in all
uppercase letters maybe it should be the word “weather” since the functionality of the system is
to provide weather information.
6