Difference between revisions of "IS480 Team wiki: 2011T2 Eureka Heuristic Evaluation"
Va.ng.2009 (talk | contribs) m |
Va.ng.2009 (talk | contribs) |
||
Line 45: | Line 45: | ||
| valign="top" align="left"| '''Visibility of system status'''<br> | | valign="top" align="left"| '''Visibility of system status'''<br> | ||
The system should always keep users informed about what is going on, through appropriate feedback within reasonable time. | The system should always keep users informed about what is going on, through appropriate feedback within reasonable time. | ||
− | | valign="top" align="left"| A timer should be included to give users and teams a sense of how long each round had been going on for. | + | | valign="top" align="left"| - A timer should be included to give users and teams a sense of how long each round had been going on for. |
| valign="top" align="center"| 3 | | valign="top" align="center"| 3 | ||
|- | |- | ||
| valign="top" align="left"| '''Match between system and the real world'''<br> | | valign="top" align="left"| '''Match between system and the real world'''<br> | ||
The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order. | The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order. | ||
− | | valign="top" align="left"| Buttons in the navigation bar for shortcuts and flexibility should be distinctively different from other function-specific buttons. This is so users can tell the difference.<br> | + | | valign="top" align="left"| - Buttons in the navigation bar for shortcuts and flexibility should be distinctively different from other function-specific buttons. This is so users can tell the difference.<br> |
− | After sending trade request, all values should be reset back to default instead of remaining as the last setting.<br> | + | - After sending trade request, all values should be reset back to default instead of remaining as the last setting.<br> |
− | The naming of certain functions/buttons need to be rephrased to be made obvious to the users<br> | + | - The naming of certain functions/buttons need to be rephrased to be made obvious to the users<br> |
− | | valign="top" align="center"| 3 | + | | valign="top" align="center"| 3 <br><br> |
2<br><br> | 2<br><br> | ||
3 | 3 | ||
Line 59: | Line 59: | ||
| valign="top" align="left"| '''User control and freedom'''<br> | | valign="top" align="left"| '''User control and freedom'''<br> | ||
Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo. | Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo. | ||
− | | valign="top" align="left"| A reset button on the ‘send request’ page could be added to allow users to undo and reset all their settings back to the default values. | + | | valign="top" align="left"| - A reset button on the ‘send request’ page could be added to allow users to undo and reset all their settings back to the default values. |
| valign="top" align="center"| 1 | | valign="top" align="center"| 1 | ||
|- | |- | ||
| valign="top" align="left"| '''Consistency and standards'''<br> | | valign="top" align="left"| '''Consistency and standards'''<br> | ||
Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions. | Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions. | ||
− | | valign="top" align="left"| Button sizes in the navigation bar are not consistent.<br> | + | | valign="top" align="left"| - Button sizes in the navigation bar are not consistent.<br> |
− | Use of conventional icons for certain buttons such as ‘back to main’ could be utilized.<br> | + | - Use of conventional icons for certain buttons such as ‘back to main’ could be utilized.<br> |
− | Login page should include password authentication to disallow other teams from accessing other teams’ accounts.<br> | + | - Login page should include password authentication to disallow other teams from accessing other teams’ accounts.<br> |
| valign="top" align="center"| 1<br> | | valign="top" align="center"| 1<br> | ||
− | 1 | + | 1<br> |
3 | 3 | ||
|- | |- | ||
| valign="top" align="left"| '''Error prevention'''<br> | | valign="top" align="left"| '''Error prevention'''<br> | ||
Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action. | Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action. | ||
− | | valign="top" align="left"| When sending a trade request, the default resources for ‘trade with’ and ‘trade for’ are the same which would not make any sense in a transaction/trade. Application should prevent users from selecting the same resources for both options. | + | | valign="top" align="left"| - When sending a trade request, the default resources for ‘trade with’ and ‘trade for’ are the same which would not make any sense in a transaction/trade. Application should prevent users from selecting the same resources for both options. |
| valign="top" align="center"| 4 | | valign="top" align="center"| 4 | ||
|- | |- | ||
| valign="top" align="left"| '''Recognition rather than recall'''<br> | | valign="top" align="left"| '''Recognition rather than recall'''<br> | ||
Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate. | Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate. | ||
− | | valign="top" align="left"| Team name should be displayed around the top of pages to avoid confusion if tablets got mixed up. <Br> | + | | valign="top" align="left"| - Team name should be displayed around the top of pages to avoid confusion if tablets got mixed up.<Br> |
− | Create the possibility of a scrollable area on all pages except main page to allow teams/users to view the amount of resources without having to click a separate button to open a popup. This will make it easier for tracking their resources.<br> | + | - Create the possibility of a scrollable area on all pages except main page to allow teams/users to view the amount of resources without having to click a separate button to open a popup. This will make it easier for tracking their resources.<br> |
− | Push notifications to teams whenever sent requests to other teams are accepted or declined. | + | - Push notifications to teams whenever sent requests to other teams are accepted or declined. |
| valign="top" align="center"| 3<br><br> | | valign="top" align="center"| 3<br><br> | ||
− | 2 | + | 2<br><br><br> |
3 | 3 | ||
|- | |- | ||
Line 92: | Line 92: | ||
| valign="top" align="left"| '''Aesthetic and minimalist design'''<br> | | valign="top" align="left"| '''Aesthetic and minimalist design'''<br> | ||
Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility. | Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility. | ||
− | | valign="top" align="left"| Some button names are very wordy. Should shorten the naming of particular functions.<br> | + | | valign="top" align="left"| - Some button names are very wordy. Should shorten the naming of particular functions.<br> |
− | More attractive design with some illustrations will be good. Perhaps a better background, include icons and different colour schemes etc. | + | - More attractive design with some illustrations will be good. Perhaps a better background, include icons and different colour schemes etc. |
− | | valign="top" align="center"| 2 | + | | valign="top" align="center"| 2<br> |
2 | 2 | ||
|- | |- | ||
Line 104: | Line 104: | ||
| valign="top" align="left"| '''Help and documentation'''<br> | | valign="top" align="left"| '''Help and documentation'''<br> | ||
Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large. | Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large. | ||
− | | valign="top" align="left"| A help button providing descriptions for each function in the main menu will be helpful. | + | | valign="top" align="left"| - A help button providing descriptions for each function in the main menu will be helpful. |
| valign="top" align="center"| 1 | | valign="top" align="center"| 1 | ||
|- | |- |
Revision as of 23:56, 25 July 2012
Home | Project Stakeholders | Project Overview | Usability & Storyboard | Project Management | Learning Outcomes | Sitemap |
Game Description | Storyboarding | User Acceptance Test | Heuristic Evaluation |
As our project focus is on developing an Android game, the importance of usability testing cannot be highlighted further especially when user experience is involved. Eureka has scheduled 4 Heuristic Evaluation tests throughout the project to highlight usability issues to help improve the user experience. The figure below shows the severity ratings for the evaluations.
Contents
Heuristic Evaluation 1
Heuristic Violated | Comments and Feedback | Severity (1 - 4) |
---|---|---|
Visibility of system status The system should always keep users informed about what is going on, through appropriate feedback within reasonable time. |
- A timer should be included to give users and teams a sense of how long each round had been going on for. | 3 |
Match between system and the real world The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order. |
- Buttons in the navigation bar for shortcuts and flexibility should be distinctively different from other function-specific buttons. This is so users can tell the difference. - After sending trade request, all values should be reset back to default instead of remaining as the last setting. |
3 2 |
User control and freedom Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo. |
- A reset button on the ‘send request’ page could be added to allow users to undo and reset all their settings back to the default values. | 1 |
Consistency and standards Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions. |
- Button sizes in the navigation bar are not consistent. - Use of conventional icons for certain buttons such as ‘back to main’ could be utilized. |
1 1 |
Error prevention Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action. |
- When sending a trade request, the default resources for ‘trade with’ and ‘trade for’ are the same which would not make any sense in a transaction/trade. Application should prevent users from selecting the same resources for both options. | 4 |
Recognition rather than recall Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate. |
- Team name should be displayed around the top of pages to avoid confusion if tablets got mixed up. - Create the possibility of a scrollable area on all pages except main page to allow teams/users to view the amount of resources without having to click a separate button to open a popup. This will make it easier for tracking their resources. |
3 2 |
Flexibility and efficiency of use Accelerators -- unseen by the novice user -- may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions. |
- | - |
Aesthetic and minimalist design Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility. |
- Some button names are very wordy. Should shorten the naming of particular functions. - More attractive design with some illustrations will be good. Perhaps a better background, include icons and different colour schemes etc. |
2 2 |
Help users recognize, diagnose, and recover from errors Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution. |
- | - |
Help and documentation Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large. |
- A help button providing descriptions for each function in the main menu will be helpful. | 1 |
Heuristic Evaluation 2
Heuristic Violated | Comments and Feedback | Severity (1 - 4) |
---|---|---|
Visibility of system status The system should always keep users informed about what is going on, through appropriate feedback within reasonable time. |
Values which reflect the current status of the team or game such as amount of money in the bank and interest to be earned should be a different colour. | 2 |
Match between system and the real world The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order. |
- | - |
User control and freedom Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo. |
- | - |
Consistency and standards Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions. |
Pop up window for depositing/withdrawing money from bank:
Image of the bank should be vertically centralized. |
2 2 |
Error prevention Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action. |
Building list should have horizontal divider lines to make it easier for players to match the descriptions with the image. This will prevent them from selecting the wrong buildings. | 2 |
Recognition rather than recall Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate. |
Building list pop up window does not reflect how much resources the team has. Because of this the teams will need to try to recall what resources they have when trying to build something. This pop up window should at least have a shortcut to view team resources. When building is insured, the building on the map should also indicate that it is insured instead of having to click on it then realised that it is already insured. |
3 3 |
Flexibility and efficiency of use Accelerators -- unseen by the novice user -- may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions. |
- | - |
Aesthetic and minimalist design Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility. |
Scrollable window that pops up revealing the team’s resources fills up almost the whole screen however, the about of space actually filled is only the left side. Pop up window shouldn’t have to be that big. The text in error or feedback pop up messages should be centralized to maintain the user’s focus on the centre of the screen. |
2 2 |
Help users recognize, diagnose, and recover from errors Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution. |
- | - |
Help and documentation Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large. |
Provide a detailed documentation of all buildings which includes how much resources required to build, how much you get back when you sell the building, its outputs, how much to insure and etc. | 2 |
Heuristic Evaluation 3
Not started...
Heuristic Evaluation 4
Not started...