Heuristic Evaluation-Group:Group Ate

From CS 160 Fall 2008

Jump to: navigation, search

Group Ate's Heuristic Evaluation assignment.

Group: 一三三七 (One Three Three Seven)'s Report and Prototype

Assignment Instructions (excerpts from the assignment page)

You will perform a heuristic evaluation (on your own) of their user interface using only the materials they turned in for the last project report. Using their tasks, scenarios, UI design, screen shots, and interactive prototype you will apply Nielsen's heuristics to the UIs. You should be able to get all of this information from their web page. Read their report first and then examine their prototype (i.e., run it). Your evaluation will use both the information in the written report and the prototype.

Please use the set of heuristics I gave in class (also described in Nielsen's chapter as the H2 series) and the numbering scheme from class (e.g., H2-1, H2-2, etc.). After finding all of the problems, go back and assign a severity (from the 0-4 scale defined in class) for each violation you found. You will produce a report showing the problems in the interface.

Your report will also summarize the number of violations found in each of the ten heuristic categories and give the total number of violations in the entire interface. You should also list the total number of violations in each severity category.

Finally, your report should close with some overall recommendations you have for improving the user interface given what you read of their description.


Contents

Problem

"Fit Wars" promotes fitness for gamer-type people by offering a traditional fighting simulation that requires exercise movements to perform actions in the battle. The game allows players all the usual fighting game affordances, like playing with other players around the world and gaining experience points and money. Because gamers traditionally enjoy these sorts of games, they will be more inclined to play this game for exercise.

Violations found

Example format:

1. [H2-4 Consistency & Standards] [severity = 2]

The interface used the string "Save" on the first screen for saving the user's file, but used the string "Write file" on the second screen. Users may be confused by this different terminology for the same function.

H2-1

  • (a) [H2-1 Visibility of system status] [severity = 3]
    • In the battle sequence, the user's "health bar" (I think it is a health bar) doesn't change. There should be some indicator of the user's status during the battle sequence. Also the enemy's health seems to "reset" if it is able to attack - not sure if this is a bug.
  • (b) [H2-1 Visibility of system status] [severity = 3]
    • Not an issue now, but in the future if this is actually implemented on the phone, something (vibration?) should indicate to the user that he/she has entered a battle sequence, since the program seems to enter the user into long running sequence and may unexpectedly port them into battle.
  • (c) [H2-1 Visibility of system status] [severity = 2]
    • On the "Select a Character" screen, it is unclear what ramifications this will have? What ramifications will choosing a particular character have? Is it purely cosmetic? Or does one character give different stats/performance compared to another?

H2-2

  • (a) [H2-2 Match System and real world] [severity = 3]
    • All inconsistencies on what can be done on an iPhone vs. what is in the prototype. Namely, hovering is not possible, and to type, there is no external keyboard. Also, the menu hover text is too small to read on a real iPhone.
  • (b) [H2-2 Match System and real world] [severity = 1]
    • Some of the text is confusing. Why would I "go back" after defeating the enemy? Or after completing the next level? I would like to "continue".
  • (c) [H2-2 Match System and real world] [severity = 1]
    • To navigate the register screens, the buttons are called "Go down" and "go up." Because there is no (clear) reference for up or down (i.e. a scroll bar), this is very confusing. Why not just "next page" and "previous page."

H2-3

  • (a) [H2-3 User control and Freedom] [severity = 4]
    • No way to exit the game to return to the phone. This is a pretty major show-stopper.
  • (b) [H2-3 User control and Freedom] [severity = 3]
    • Automatch only gives one option for who to battle. The user should have an option to "search again" or "find new match" if they do not like the automatch.
  • (c) [H2-3 User control and Freedom] [severity = 3]
    • No way to exit the fight
  • (d) [H2-3 User control and Freedom] [severity = 1]
    • No way to cancel during any of the "loading" screens

H2-4

  • (a) [H2-4 Consistency and standards] [severity = 3]
    • When the game starts, the character starts off in a running animation, even though it remains completely still. When the character runs, it is in the same running animation. It's confusing whether the character is actually supposed to be in motion or not. When I initially began and didn't know how to run, I was assuming that there was a bug that prevented the character from moving, because it looked like it was running.

H2-5

  • (a) [H2-5 Error prevention] [severity = 2]
  • No confirmation of data entered in the registration process.

H2-6

  • (a) [H2-6 Recognition rather than recall] [severity = 2]
    • If I want to search battle records, I would not logically click buttons to "Fight Player" or "Fight Computer". A better categorization would be Fight -> Player, Computer, and View Battle Records-> Player records, Computer records.
  • (b) [H2-6 Recognition rather than recall] [severity = 2]
    • The white tabs indicating that a monster/battle scene is about to appear relies on recall rather than recognition - no first-time user could expect the monster to appear. There is also no indication in the scene itself that a monster is coming. Similarly, I expected the last tab to be another enemy, not the "finish line" for the level.

H2-7

  • (c) [H2-7 Flexibility and efficiency of use] [severity = 2]
    • Reply should auto-fill the receiver's username, also RE: [original subject]. This seems logical and also works toward recognition (H2-6) since most email clients do this.

H2-8

  • (a) [H2-8 Consistancy and standards, Asthetic and minimalist design] [severity = 4]
    • For all buttons, there are not enough distinguishing features that make them look like buttons. (this is assuming hover doesn't exist, which it again doesn't for the iPhone). There should be some shape to these buttons, especially when the user has to know where he/she can touch.
  • (b) [H2-8 Consistancy and standards] [severity = 3]
    • On the second register screen, the name of characters on the graphics label is inconsistant with what is show above the register button after selecting. e.g. RedPanda vs. Red Panda, Hobo-Man vs. Hobo Man
  • (c) [H2-8 Consistancy and standards] [severity = 3]
    • When battling, the orientation of the hardware needs to change from portrait to landscape without warning.
  • (d) [H2-8 Aesthetic and minimalist design] [severity = 3]
    • The description text on the menu buttons is far too small to see.
  • (e) [H2-8 Aesthetic and minimalist design] [severity = 2]
    • The "messages" alert is very bright and eye-catching. This is good if the user has new messages - however, the same alert displays even when the user doesn't have new messages, which is distracting because the Messages button is so much brighter/different from the other buttons. Consider making it bright only when there are new messages.
  • (f) [H2-8 Aesthetic and minimalist design] [severity = 2]
    • It is not clear what are clickable buttons and what are just links. For example, when reading message, REPLY and GO BACK are the same font so it's not apparent they are buttons. This is related to violation H2-8(a) .

H2-9

  • (a) [H2-9 Help users recognize, diagnose, and recover from errors] [severity = 4]
    • After the user becomes lost in the battle sequence (or stands in place for a long time in the running sequence), , the user has no way of figuring out how to to get out of that mode.

H2-10

  • (a) [H2-10 Help and Documentation] [severity = 3]
    • While we were made to understand this would be implemented in some form, we believe it bears mentioning: there is no tutorial mode, and no help available to tell the user how to play the game. Specifically, there is no access to help from the fight, a problem because the interface doesn't give much to go off of.

Summary of violations

As summarized below, most of the violations we found were related to Consistency and standards and Aesthetic and minimalist design - fairly simple graphical or design issues that either made things confusing, or distracting.

We also found some issues with visibility of system status, matching the system and real world, user control, and some documentation issues (mostly that help/documentation doesn't yet exist). Essentially, there are many scenarios where no instruction or explanation is provided, the interface is not intuitive enough for the user to figure out on his own, and there is no help documentation for the user to refer to.


Violations
Heuristic Severity Count
H2-1 1 0
2 1
3 2
4 0
H2-1 Sub Total 3
H2-2 1 2
2 0
3 1
4 0
H2-2 Sub Total 3
H2-3 1 1
2 0
3 2
4 1
H2-3 Sub Total 4
H2-4 1 0
2 0
3 1
4 0
H2-4 Sub Total 1
H2-5 1 0
2 1
3 0
4 0
H2-5 Sub Total 1
H2-6 1 0
2 2
3 0
4 0
H2-6 Sub Total 2
H2-7 1 0
2 1
3 0
4 0
H2-7 Sub Total 1
H2-8 1 0
2 2
3 3
4 1
H2-8 Sub Total 6
H2-9 1 0
2 0
3 0
4 1
H2-9 Sub Total 1
H2-10 1 0
2 0
3 1
4 0
H2-10 Sub Total 1
Total 23

Recommendations

H2-1

  • (a) [H2-1 Visibility of system status] [severity = 3]
    • In the battle sequence, the user's "health bar" (I think it is a health bar) doesn't change. There should be some indicator of the user's status during the battle sequence. Also the enemy's health seems to "reset" if it is able to attack - not sure if this is a bug.
      • Make the health bar clear, and decrease as the user is hit. Also, either fix the enemy's health bug or explain it to the player in a better way (perhaps through a help or tutorial mode)
  • (b) [H2-1 Visibility of system status] [severity = 3]
    • Not an issue now, but in the future if this is actually implemented on the phone, something (vibration?) should indicate to the user that he/she has entered a battle sequence, since the program seems to enter the user into long running sequence and may unexpectedly port them into battle.
      • As mentioned, make the phone vibrate/ring when a battle scene is encountered.
  • (c) [H2-1 Visibility of system status] [severity = 2]
    • On the "Select a Character" screen, it is unclear what ramifications this will have? What ramifications will choosing a particular character have? Is it purely cosmetic? Or does one character give different stats/performance compared to another?
      • If the characters are purely cosmetic, perhaps change the wording to "Select an Avatar" or something. You could simply leave it as it is, and the user will learn from recall, which is OK since this is a fairly minor, one-time issue, however, less ambiguous wording is preferable.
      • If the characters have different abilities or stats, these should be listed. If it can all fit, a small table underneath the icons with the stat numbers would be useful. Otherwise some sort of "info" button that would take the user to a separate description page would help.

H2-2

  • (a) [H2-2 Match System and real world] [severity = 3]
    • All inconsistencies on what can be done on an iPhone vs. what is in the prototype. Namely, hovering is not possible, and to type, there is no external keyboard. Also, the menu hover text is too small to read on a real iPhone.
      • See our recommendation for H2-8(d) with regard to menu hover text. As we were told these issues would be fixed, we won't belabor the point, though for a realistic simulation they must be addressed.
  • (b) [H2-2 Match System and real world] [severity = 1]
    • Some of the text is confusing. Why would I "go back" after defeating the enemy? Or after completing the next level? I would like to "continue".
      • I would suggest changing the text to "Continue", or "Next level"
  • (c) [H2-2 Match System and real world] [severity = 1]
    • To navigate the register screens, the buttons are called "Go down" and "go up." Because there is no (clear) reference for up or down (i.e. a scroll bar), this is very confusing. Why not just "next page" and "previous page."
      • Change to "next page" and "previous page", or implement a clearer reference, as in a scroll bar.

H2-3

  • (a) [H2-3 User control and Freedom] [severity = 4]
    • No way to exit the game to return to the phone. This is a pretty major show-stopper.
      • Implement an "Exit Game" menu option
  • (b) [H2-3 User control and Freedom] [severity = 3]
    • Automatch only gives one option for who to battle. The user should have an option to "search again" or "find new match" if they do not like the automatch.
      • As stated above, the user should have an option to "search again" or "find new match" if they do not like the automatch.
  • (c) [H2-3 User control and Freedom] [severity = 3]
    • No way to exit the fight
      • There should be a pause menu available from anywhere, perhaps by touching a button in the corner of the screen. The pause menu can include an exit option.
  • (d) [H2-3 User control and Freedom] [severity = 1]
    • No way to cancel during any of the "loading" screens
      • A "cancel" button can be placed near the scroll bar, similar to the file transfer dialog in windows explorer.

H2-4

  • (a) [H2-4 Consistency and standards] [severity = 3]
    • When the game starts, the character starts off in a running animation, even though it remains completely still. When the character runs, it is in the same running animation. It's confusing whether the character is actually supposed to be in motion or not. When I initially began and didn't know how to run, I was assuming that there was a bug that prevented the character from moving, because it looked like it was running.
      • There should be a "standing" animation for when the character is not moving.

H2-5

  • (a) [H2-5 Error prevention] [severity = 2]
    • No confirmation of data entered in the registration process.
      • Create a simple confirmation screen much like the "message sent" confirmation screen.

H2-6

  • (a) [H2-6 Recognition rather than recall] [severity = 2]
    • If I want to search battle records, I would not logically click buttons to "Fight Player" or "Fight Computer". A better categorization would be Fight -> Player, Computer, and View Battle Records-> Player records, Computer records.
      • Change the main menu categorization to the one suggested above.
  • (b) [H2-6 Recognition rather than recall] [severity = 2]
    • The white tabs indicating that a monster/battle scene is about to appear relies on recall rather than recognition - no first-time user could expect the monster to appear. There is also no indication in the scene itself that a monster is coming. Similarly, I expected the last tab to be another enemy, not the "finish line" for the level.
      • I don't quite see a need to tell the user when an enemy will appear in a predictable manner. I would leave the tabs out completely, and if you wanted, place actual enemies in the scene of the game, so the characters will run into them directly and start a battle sequence. Alternately, if you're set on the tabs, making them little sword icons or even miniature depictions of the enemies themselves would make it much more clear what's going on.

H2-7

  • (c) [H2-7 Flexibility and efficiency of use] [severity = 2]
    • Reply should auto-fill the receiver's username, also RE: [original subject].
      • This should be implemented. It seems logical and also works toward recognition (H2-6) since most email clients do this.

H2-8

  • (a) [H2-8 Consistancy and standards, Asthetic and minimalist design] [severity = 4]
    • For all buttons, there are not enough distinguishing features that make them look like buttons. (this is assuming hover doesn't exist, which it again doesn't for the iPhone). There should be some shape to these buttons, especially when the user has to know where he/she can touch.
      • Draw a 3d-looking button texture behind the button that also has a press-down animation while it is being pushed.
  • (b) [H2-8 Consistancy and standards] [severity = 3]
    • On the second register screen, the name of characters on the graphics label is inconsistant with what is show above the register button after selecting. e.g. RedPanda vs. Red Panda, Hobo-Man vs. Hobo Man
      • Choose the names once and for all and stick with it.
  • (c) [H2-8 Consistancy and standards] [severity = 3]
    • When battling, the orientation of the hardware needs to change from portrait to landscape without warning.
      • As in our H2-1 (b) suggestion, a vibration perhaps accompanied by a flashing "ROTATE THE PHONE" text and/or diagram would alert users they must change their layout.
  • (d) [H2-8 Aesthetic and minimalist design] [severity = 3]
    • The description text on the menu buttons is far too small to see.
      • You could make the font bigger, but this would likely not fit. The buttons seem pretty intuitively named, so a better organizational scheme [H2-6 (a)] would go a long way. Also consider icons for the menu buttons - for example, a little sword icon for Fight, a little computer icon for Computer, etc.
  • (e) [H2-8 Aesthetic and minimalist design] [severity = 2]
    • The "messages" alert is very bright and eye-catching. This is good if the user has new messages - however, the same alert displays even when the user doesn't have new messages, which is distracting because the Messages button is so much brighter/different from the other buttons.
      • Have a less attention-grabbing messages button dedicated somewhere. It should display the number of unread messages, ex. "Messages (3)". When a new unread message is received, the current alert is fine, but it should not show up when there are no new unread messages.
  • (f) [H2-8 Aesthetic and minimalist design] [severity = 2]
    • It is not clear what are clickable buttons and what are just links. For example, when reading message, REPLY and GO BACK are the same font so it's not apparent they are buttons. This is related to violation H2-8(a) .
      • Differentiate the fonts of regular text, and "clickable text". Or make clickable things look like buttons.

H2-9

  • (a) [H2-9 Help users recognize, diagnose, and recover from errors] [severity = 4]
    • After the user becomes lost in the battle sequence (or stands in place for a long time in the running sequence), the user has no way of figuring out how to to get out of that mode.
      • After the user becomes lost in the battle sequence (or stands in place for a long time in the running sequence), you should have a dialog that tells the user what they should be doing, since the user is obviously stuck.

H2-10

  • (a) [H2-10 Help and Documentation] [severity = 3]
    • While we were made to understand this would be implemented in some form, we believe it bears mentioning: there is no tutorial mode, and no help available to tell the user how to play the game. Specifically, there is no access to help from the fight, a problem because the interface doesn't give much to go off of.
      • Tutorial mode and help need to be implemented.

Original Individual Notes

The original individual notes for the heuristic evaluation are available here, for those group members that wrote theirs out separately.

Personal tools