HeuristicEvaluation-RaymondLee
From CS 160 User Interfaces Sp10
Contents |
Heuristic Evaluation
This document is a heuristic evaluation of Spencer Fang's Individual Programming Assignment 4 BART Application.
BART App Main Menu
Heuristic: Help and Documentation
Explanation
The interface offers four large buttons clearly showing all functionality offered by the application. However, there is no explanation for how the functionality of the features works beyond the title of the button, which makes the user depend solely on the interface being intuitive and self-explanatory.
Severity
2 = Minor usability problem: fixing this should be given low priority
This problem is not too frequent: upon a few uses of the application without a help menu, eventually the user will be accustomed to using it without instruction. The impact may be large depending on the complexity of the rest of the application because it could be daunting for users to use an app without initial help. Persistence is not much of a problem, once again depending on the user's intuitive grasp of the rest of the application.
Starting Station (Fare Calculator)
Heuristic: Visibility of System Status
Explanation
The interface offers a double sided picker view for selecting the origin and destination stations. The user rolls the picker until the desired origin and destination stations are selected, and then he hits a "Calculate" button to calculate the fare. The problem here is if the picker is rotated after a fare is calculated, the displayed fare is not automatically updated to reflect the new origin/destination fare. Thus, a user could potentially mistake the outdated fare calculation for the current origin/destination pair. The true status of the system is not shown to the user: that the fare is tied to a previously chosen origin/destination pair, or that the current fare might possibly not be associated with the current origin/destination pair.
Severity
3 = Major usability problem: important to fix, so should be given high priority
I rank this problem as major because it occurs frequently - every time the user wants to change stations for either origin or destination. This will also be a persistent problem: if a user forgets to hit the calculate button, the fare will always be out of sync with the picker view. The impact is not that severe: if a user knows about this problem, he will make sure to hit the calculate button each time, but consequently the responsibility is on the user to ensure the correctness of the fare calculation.
Train Map
Heuristic: Match between system and the real world
Explanation
In the real world, when viewing a map, a person typically has the whole map in view before moving closer to inspect regions of interest. This train map offers panning functionality, but the original view is focused on the top left corner of the map (where there is not much information to be gained), rather than having an overall view/centered view as in real life. Furthermore, there is no zooming functionality as a person would be capable of in real life. Thus, this interface is not the best representative of how one would view a map in real life.
Severity
1 = Cosmetic problem only: need not be fixed unless extra time is available on project
I rank this problem as very minor because adept users of the iPhone are well-accustomed to scrolling large images for a better view. This is only a minor nuisance to users who might want a more macro view of the map, or who wish for the map to be centered from first access. However, despite being a nuisance, this problem ranks high on frequency, impact, and persistence if a user is actually bothered by how this map is implemented. A newbie BART user would frequently access the map-- and he will persistently be hindered by the off centered image and lack of zooming. Since it is impossible for the user to overcome the limitation, it is a high impact problem.
Train Departures
Heuristic: Recognition rather than Recall
Explanation
The Train Departures subsection shows a picker and a button with a text view at the bottom. The picker is used to select an origin station, and after clicking Done, the text view is populated with the schedule of departing trains at the selected station. The amount of text is often larger than can be accommodated by the space provided, so a scroll bar briefly flashes to show that the bottom text view is scrollable. After this brief flash, the scrollbar disappears and the user is required to RECALL that a scrollbar was there and there might be more schedule information, rather than RECOGNIZE that he might be missing information.
Severity
2 = Minor usability problem: fixing this should be given low priority
I rank this problem as relatively minor, because as long as the user is paying attention as he is selecting the station he will notice the scrollbar briefly appearing and disappearing, and this will remind him that there is scrollable information in the text view. The only concern would be if the user is in a hurry, he might not notice a scroll bar present and thus would neglect further information that might be hiding underneath the displayed text. This problem is likely to occur very frequently as schedules contain several train departure times, but the impact and persistence will be mitigated once the user is knowledgeable about this interface quirk.
Ticket Machine Help
Heuristic: None
Explanation
The interface offers three segmented buttons which altogether describe all possibilities of currency/tickets being on hand. After selecting the options which apply, one pushes the Continue button to pop up a new screen that shows text instructions on how to purchase a BART ticket with the resources on hand.
Severity
0 = I don't agree that this is a usability problem at all This help interface is quite simplistic and as a result, there is not much fault to find with it. The user would be hard-pressed to get confused about the three questions posed, and the instructions about what to do are given immediately.
