HeaderSIS.jpg

IS480 Team wiki: 2011T2 Eureka Heuristic Evaluation

From IS480
Jump to navigation Jump to search
Team Eureka logo.jpg







Heuristic Evaluation

Good design begins with honesty, tough questions, and trusting your intuition...


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.

Eureka Heuristic Evaluation Severity Ratings.png

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.
- The naming of certain functions/buttons need to be rephrased to be made obvious to the users

3


2

3

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.
- Login page should include password authentication to disallow other teams from accessing other teams’ accounts.

1

1

3

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.
- Push notifications to teams whenever sent requests to other teams are accepted or declined.

3

2



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.

- 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

Back to Top

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.

- Naming of the building ‘Bank’ should be bolded and be located on top of the bank image, not below.
- The close button of the building list is located and the top right of the pop up window. This is very unconventional. The button should be located at the bottom right instead.
- It is a little unexpected to see another pop up window after selecting a building at the building list. Some may think that selecting a building will immediately build the building. If possible the additional information “required to build” should be put on the same window as the ‘Building List’ instead of being in an addition pop up. If this is not possible, the naming of the button ‘Select’ could perhaps be renamed so players will know that there is additional information to view instead of thinking that pressing this will immediately build the selected.
- Names of buildings in the buildings list should be bolded. The pictures and the names of the respective buildings should be the first thing the players see on the pop up.
-‘Select’ buttons should be vertically centralized beside the images.

2

2

2


3







2


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.

- 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.
- When the building has already produced its output per round, it should also be reflected on the building image on the map so that players won’t need to recall their actions.

3



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.
- The text on the pop up window when depositing or withdrawing money from the bank needs to be aligned properly.
- Neater if withdraw and deposit buttons were the same size.
- Building list is too wordy. This can be simplified by converting it into a table.
- The name of the building should be centralized at the top and bolded as a title in the “Required to build” window when selecting a building in the building list.
- The building list should be organised with primary buildings listed at the top and secondary buildings listed below.

2


2

2

1
3
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

Back to Top

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.

- The confirmation popup that appears at the bottom of the screen for a few seconds after sending a trade is a bit small and may be unnoticeable to users.

- When a user accepts a team’s trade request, the team who sent the trade request is not notified. Perhaps send a notification to the team for notification with the updated resource values.

- No feedback given to team when user declines their offers.

-When the ‘market’ window opens, it blocks the panel above where you can see how much ‘Gold’ you have.

-When admin changes game phase a notification should be shown to show that phase changed.

-Teams don’t know when a new round has started.

-Teams don’t know when phase has changed. Teams can remain in the previous phase even when game phase has changed already.

1


3


3

2


2


4

4


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.

- Naming of ‘View Pending Offers’ and ‘View Offers from Other Teams’ is confusing.

- Confusion over term ‘Money on Hand’ as this actually refers to ‘Gold’ not ‘Money’.

2

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.

- -
Consistency and standards

Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.

- Need to click on ‘More Info’ to build in building list -> not intuitive
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.

- When accepting a trade request where the team does not have sufficient resources to trade, notification pops up notifying insufficient resources but the trade request still remains in ‘Trade Offers from Other Teams’ to accept again.

- ‘Reset Game’ button is very close to the ‘Start Simulation’ button. Perhaps move the bottom further away to prevent accidentally resetting the game.

- A game save should be done frequently in case game crashes. Perhaps an auto-save each time the user presses back or a particular frequently pressed button.

2


1


3

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.

- A page for teams to view and track the trade history/summary would be good to keep track of what has been traded.

- Good to have navigation map at the top corner/bottom corner of screen so users know the boundaries of the entire map.

2

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.

- User cannot accept multiple trade offers at the same time.

- Good to have navigation map at the top corner/bottom corner of screen so users know the boundaries of the entire map.

- Cannot buy multiple items at the same time in the ‘Market Place’

2

2

2

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.

-Status bar and navigation bar shouldn’t be all black and dull. Perhaps add more colours to make it more eye-catching.
1
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.

- Documentation and rule book for all teams to refer to if new to game.
3

Back to Top

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.

- When a user accepts a team’s trade request, the team who sent the trade request is not notified. Perhaps send a notification to the team for notification with the updated resource values.

- No feedback given to team when user declines their offers.

- When admin changes game phase a notification should be ‘pushed’ to tablets to show that phase changed.

- Teams don’t know when the phase has changed to building phase. Teams can remain in the trading phase even when game phase has changed already.

- When scenarios are released, teams will not know until they touch on a button or location on the map.

3


3


2


3


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.

- “Trade Resources” in trading menu is confusing sounds like an action to trade. Perhaps change naming to “Team Resources”. 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.

- -
Consistency and standards

Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.

- Need to click on ‘More Info’ to build in building list -> not intuitive.

- When clicking on “Market Price of Resources” in the “Send Trade Request” page, the pop-up showing the market price of each resource is out of alignment and should be consistent with the “Trade Resources” page.

- After successfully buying/selling items in the “Buy”/”Sell” menu in the building phase, the quantity inputted remains in the text box. This should be emptied after every successful buy.

2

3



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.

- When sending a trade request, ‘Trade With’ and ‘Trade For’ resources are both default as ‘Wood’. Not practical and does not make sense for teams to trade give and receive the same resource in a trade. 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.

- Good to have navigation map at the top corner/bottom corner of screen so users know the boundaries of the entire map.

- When first going into “Building Phase” the ‘Bank’ building almost cannot be seen hidden at the far bottom. View of map should be set to default location where the ‘Bank’ is centralized on the screen.

2

1

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.

- User cannot accept multiple trade offers at the same time.

- Good to have navigation map at the top corner/bottom corner of screen so users know the boundaries of the entire map.

- Cannot buy/sell multiple items at the same time in the “Buy”/”Sell” menu in building phase.

2

2

2

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.

- Alignment issues of buttons in trading phase menu.

- Alignment issues with the resource drop down options on “Send Trade Request” page.

- Darker labels on “Send Trade Request” page would be easier to read. Perhaps darken the grey coloured labels.

- “Market Prices of Resources” and “Submit” button on “Send Trade Request” page are not consistent are of different size and colour.

- Alignment issues when listing quantity of resources required to build a certain building.

1

1

1


1


1

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.

- Documentation and rule book for all teams to refer to if new to game.
3

Back to Top