The Usability Project report

The Usability Project (UP) is a student project that aims to improve usability of Dungeon Crawl Stone Soup. The team consists of five students from the faculty of Information Processing Science in Oulu University.

The project runs from late winter 2009 until April 2010. It consists of three phases: in-team evaluation using game usability evaluation heuristics, user-testing, and implementation and/or prototyping of suggestions. The project produces a usability problem report (this document) and code patches for the implementation and prototypes. The focus of the project is in learnability of the graphical version (tiles) of Stone Soup. The in-team evaluators and the testers in user testing were all first-time players of the game.

Method

In-team evaluation

Each evaluator separately played the game for 20-30 hours, first making free-form notes. Additional 2-3 hours per evaluator was spent looking at the game from the point of view of the heuristics (see appendix A). Then the evaluators combined their findings and produced an initial list of usability problems.

User testing

Six testers tested the game. We sought testers who were gamers and had not played Dungeon Crawl before. Four of the testers had previous roguelike experience. All the testers were male, and around 25-35 years of age. The testers tested the game with a moderator, who first explained the test to the testers, and during testing, asked questions from the testers and assisted as necessary.

How the test was prefaced

The testers were first told a few things about the test:

  • Which cameras and other equipment were in use
  • That the recordings were to be only used for producing the problem report and were only to be seen by the UP team members
  • Tester could end the session any time they wanted - if they were comfortable and entertained, it would last maximum 45 minutes
  • The test evaluated the usability of the game, not the abilities of the tester
  • There was no hurry to play as much and as quickly as possible in the short time; the test was about the very first steps and initial learnability of the game
  • The tester was encouraged to speak as much aloud as possible

Then the testers were given a form with a few basic questions.

Tasks given to the testers

At the start of the actual test, the folder which Crawl was unzipped to was open in the Windows XP desktop. During the first two tests, the testers were tasked to “begin the game”. However, both of the testers first looked at the text files they saw. The first task was changed to simply “begin testing” for the subsequent tests.

During the test, about halfway in, the testers were tasked to save and load the game.

Also about halfway in, at the moderator's discretion, and if the tester didn't find out about it by themselves, testers were told about the tutorial and tasked to begin a tutorial game. Otherwise, the moderator did not assist the testers unless they seemed hopelessly stuck or very frustrated.

The testing environment

The usability testing laboratory that was used has two rooms, the testing room and the observation room. The testing room had the PC (ordinary Windows XP tabletop computer - normal mouse and keyboard were used) and microphones and cameras with which the tests were recorded.

On the observation side, observers had microphone and camera feeds, plus a feed directly from the video output of the testing PC. All were captured on video/audio file(s), with varying degree of technical difficulties. All the tests were deemed at least partially successful, and could be used in finding and confirming problems.

Overview of DCSS Stone Soup

Most problems were identified in heuristics category 9 (Instructions). No problems were identified in categories 3 (AI), 4 (Clear views) and 5 (Skip non-playable content). On 3 (AI), ally-based play wasn't done much during evaluation and testing.

Main problem areas

  • Starting menus:
    • The tutorial being unfindable
    • The overwhelming amount of character choices is not accompanied with information about what they actually mean
  • Tutorial and manual:
    • There were difficulties in finding the relevant information in the manual / help
    • Unfortunately, the same goes for tutorial (too much information at once)
  • Controls:
    • There's a lot of genre baggage that makes the controls different (and hard to learn) compared to modern games (caused by 80×24 terminal graphics, keyboard controls, config files)
      • A lot more should be mouse-operated (see Mouse Playability)
      • The keyboard commands are numerous and sometimes hard to input and remember
      • Inability to remap the commands in-game
  • Game:
    • Players miss important events due to not knowing where to pay attention. The interface could attract player's attention to unusual happenings with colours and sounds
    • Some basic mechanisms are difficult to grasp (resting, stairs)

Good stuff

  • Much of the game is fairly intuitive to play
  • While work can be done to make it more accessible, the game and character status needed to make meaningful decisions is available
    • Also true about species and background choices
  • While you still cannot play the game completely with it, mouse control works fairly well
    • Handling the inventory and items with the mouse works well, left-click on items usually does the expected thing.
    • Comparing things in the inventory (such as weapon stats) is also efficiently and intuitively done with mouse.
  • A lot of work has obviously been spent in making the interface efficient for playing, and it shows
    • Autotravel, autoexplore, autopickup work well and save keystrokes from the player
    • While it's not accessible in-game, the game is very customizable
    • Minimap in tiles is also a good feature
  • It is also evident that there's been effort to make the game learnable and easier to get into (even if there still is work to do)
    • The presence of tutorial. Even with its problems, it is still a good tool to teach the game to the player (at least, as long as the player likes reading!)
    • The player gets positive feedback from success
      • Messages about killing monsters successfully (coloured red and added with exclamation mark)
      • Level and skill gain messages stand out similarly
    • Game gives hints to the player, for example monster descriptions give an overall feel how dangerous the monster might be
    • There is some backstory in the game in the descriptions e.g, if player wants to find these out
  • Icons are generally good and informative and support the playing experience, for instance:
    • The smileys in meat chunks work
    • The way wielded and worn items show on the character tile is neat
    • Tiles generally look nice (the look is oldschool, granted, but it works)
  • As each game is procedurally generated, it doesn't feel repetitive and boring. (“Xom is, like, totally awesome.”)
    • The player can change their strategy and tactics, and even try to develop their own
    • The same tactics don't get you out of every situation (helps against boredom)
    • The characters actions and capabilities can be shaped with the player's choices
    • The game is challenging and meaningful from the beginning, which is good as you need to always start from beginning after each death
  • Player and development community is active and accessible
    • Game keeps developing and new versions get released, and the players can take part in the development
    • The IRC channel and server play are good ways of getting help and improving in the game

Identified usability problems

Template for a problem

Problem summary Name/summary of the problem
Problem description Long description of the problem
Screenshot(s) Screenshot(s) that describe the situation
Scenario(s) Gameplay scenario(s) (or steps to reproduce) of the situations where the problem is encountered
Breaks heuristic(s) Heuristics that the behaviour violates
Severity UP-team's assessment of how severe the problem is (based on how often it comes up and how much trouble it causes)
Occurred in Where the problem was noted: in evaluation, and/or in (how many) user tests? (Quantification of the user tests where it was noted or caused problems is not precise.)
Suggestion(s) Suggestions to fix the problem
Related page(s) Links to other wiki pages or feature requests.
Comments Various comments. Please sign your posts and keep them short and to the point. If several comments start turning into a discussion, we may want to move said issue onto another page or a FR of its own.

Severity

The following 0 to 4 rating scale is used to rate the severity of usability problems: [http://www.useit.com/papers/heuristic/severityrating.html|(Nielsen)]

  • 0 = I don't agree that this is a usability problem at all
  • 1 = Cosmetic problem only: need not be fixed unless extra time is available on project
  • 2 = Minor usability problem: fixing this should be given low priority
  • 3 = Major usability problem: important to fix, so should be given high priority
  • 4 = Usability catastrophe: imperative to fix this before product can be released

Heuristics

The following heuristics were used:

  1. Provide consistent responses to the user's actions.
  2. Allow users to customize video and audio settings, difficulty and game speed.
  3. Provide predictable and reasonable behavior for computer controlled units.
  4. Provide unobstructed views that are appropriate for the user's current actions.
  5. Allow users to skip non-playable and frequently repeated content.
  6. Provide intuitive and customizable input mappings.
  7. Provide controls that are easy to manage, and that have an appropriate level of sensitivity and responsiveness.
  8. Provide users with information on game status.
  9. Provide instructions, training, and help.
  10. Provide visual representations that are easy to interpret and that minimize the need for micromanagement.

Source: Pinelle, Wong, Stach: “Heuristic Evaluation for Games: Usability Principles for Video Game Design” CHI 2008, April 5–10, 2008, Florence, Italy.

In Appendix A, they are listed with more detail.

We interpreted heuristic 6 to apply to missing controls (mostly mouse clickability).

Heuristic 7 was interpreted to apply to menus (as well as direct player character control), and also to apply to lack of feedback.

Heuristic 10 was interpreted to apply to alignment etc. of help texts and menus (although not to the content of the texts themselves).

1. Starting menus

1.1.

Problem summary [FIXED] Tutorial easily goes unnoticed
Problem description Tutorial is not visible enough in the start menu, or the character choice screen. (See also 1.7)
Screenshot(s)
Scenario 1 The player gets excited about the many character choices in the menus so he doesn't notice the small tutorial text in the top of the screen.
Scenario 2 The player starts looking at the welcome screen, sees “enter your name here”, enters name and presses enter proceeding to the next screen, without reading the note about tutorial below.
Breaks heuristic(s) 10 (Easy-to-interpret)
Severity 3 (high priority)
Occurred in Evaluation, Testing (5/6) (one tester, who first read readme.txt and noticed tutorial from there, correctly entered name and pressed Ctrl+T in the next screen.)
Suggestion(s) Overhaul the starting menu to display tutorial (and other choices) more prominently.
Related page(s) Hints Mode Feedback
Comments No longer an issue with the starting menu overhaul in 0.7. — jpeg 2010-12-26 21:46

1.2.

Problem summary Too many race/class options for first timers
Problem description For a first time user there are too many options for a race or character class and not enough information easily available to base their selection on.
Screenshot(s)
Scenario(s) A first time player starts the game and gives his name for the game. He moves to following screens and gets overwhelmed by the number of possible race and class options. The player finds the race and class description texts, but he has to go through the entire list to find information about the specific race/class.
Breaks heuristic(s) 9 (Instructions)
Severity 2 (low priority)
Occurred in Evaluation, Testing (5/6)
Suggestion(s) Provide short (one-sentence) descriptions of each choice when mouseovering over the choice. Getting the players to go to the tutorial probably also mitigates this problem.
Related page(s) Character Selection
Comments With the descriptions introduced by the 0.7 starting menu overhaul, this is less of a problem. — jpeg 2010-12-26 21:46

1.3.

Problem summary [Improved] New players cannot tell which character choices would be the good to start with
Problem description -
Screenshot(s) -
Scenario(s) A new player opens the game and comes to the screen, where is the menu, where to choose the race. He does not pay attention to to the text above, where there is mentioned a command to get more information about the race. The user tries to find information by clicking the right mouse button on the top of the ”'Deep Elf”, but nothing happens. He assumes that he should already have some basic information about the race, gets nervous and makes a random selection.
Breaks heuristic(s) 9 (Instructions)
Severity 2 (low priority)
Occurred in Evaluation, Testing (at least 1/6)
Suggestion(s) Getting the players to go to the tutorial probably mitigates this problem. Providing short (one-sentence) descriptions about each choice when mouseovering them should also help players find something they'd like to play.
Related page(s) Character Selection
Comments Again, less of a problem since the 0.7 starting menu overhaul. — jpeg 2010-12-26 21:46

1.4.

Problem summary [FIXED] Entering tutorial “on next screen”
Problem description On the welcome screen of the Crawl, the tutorial is mentioned, but not selectable.
Screenshot(s)
Scenario 1 A new player is starting the game. He is reading the welcome page intensively through and notices the possibility to play the tutorial. He tries to press the “ctrl+T”, but nothing happens. He does not assimilate, that tutorial is selectable on the next screen. He gives his name and forgets the whole mention of the tutorial.
Scenario 2 Two testers, when told that a tutorial existed and were asked to find and play it, noticed the text “Press Ctrl-T in the next screen” and tried to press Ctrl-T immediately
Breaks heuristic(s) -
Severity 2 (low priority)
Occurred in Testing (2/6)
Suggestion(s) With the starting menu overhaul, the tutorial is made selectable (also) in the welcome page.
Related page(s) Start / Welcome Menu
Comments Fixed with the 0.7 starting menu overhaul. — jpeg 2010-12-26 21:46

1.5.

Problem summary [Improved] The keyboard shortcut/help section in character selection screen is messy
Problem description It's hard to pick up the keyboard shortcuts at a glance in the character selection screens. No testers seemed to pay attention to them; the fact that they are hard to interpret at a glance may contribute.
Screenshot(s)
Scenario(s) -
Breaks heuristic(s) 10 (Easy-to-interpret)
Severity 2 (low priority)
Occurred in Evaluation
Suggestion(s) Align the keyboard shortcuts with the choice columns.
Related page(s) Character Selection
Comments As a result of the 0.7 starting screen overhaul, they now are at least nicely sorted, which might alleviate this a bit. — jpeg 2011-01-18 23:12

1.6.

Problem summary [FIXED] “Good” in “good random” is assumed to mean good/evil alignment
Problem description It is not immediately clear to players, that the “good random” option means getting a random recommended choice. “Good” is assumed to refer to good/evil alignment.
Screenshot(s) -
Scenario(s) A tester suspected, during creating the first character, that the “good random” choice would produce a random character that was good-aligned.
Breaks heuristic(s) 9 (Instructions)
Severity 1 (no priority)
Occurred in Evaluation, Testing (1/6)
Suggestion(s) Use dpeg's idea to rename “good” to “viable”.
Related page(s) Character Selection
Comments Renamed to “viable” in 0.7. — jpeg 2010-12-26 21:46

1.7.

Problem summary [Improved] It's difficult to find out that unrecommended character combinations can be picked
Problem description In species/background selection greyed out selections are assumed to be disabled. While this resumes the cognitive load for the beginner in these screens (as dpeg pointed out), it is hard to realize in-game that the selections can be chosen.
Screenshot(s)
Scenario(s) Two of the testers, when looking at the background selection screen for the first time, assumed out loud that the greyed out selections couldn't be picked.
Breaks heuristic(s) 10 (Easy-to-interpret)
Severity 1 (no priority)
Occurred in Evaluation, Testing (2/6)
Suggestion(s) Note that the greyed out choices are selectable somewhere where the player can be assumed to look during the course of several games. For example, add ”(unviable)” to the appropriate short descriptions that are planned for each choice.
Related page(s) Character Selection
Comments Now that they are mouse-selectable, this should be much more obvious. — jpeg 2011-01-18 23:12

1.8.

Problem summary [FIXED] Saved game is not selectable by mouse
Problem description Loading the saved game is only doable on keyboard
Screenshot(s) -
Scenario(s) Many of the testers, when asked to save game and the load, tried first to click the saved game appearing in the starting menu.
Breaks heuristic(s) 6 (Intuitive and customizable controls)
Severity 1 (no priority)
Occurred in Testing (all or nearly all six)
Suggestion(s) Make the saved games clickable in the starting menu.
Related page(s) Start / Welcome Menu
Comments Fixed with the 0.7 starting menu overhaul. — jpeg 2010-12-26 21:46

1.9.

Problem summary [FIXED] Race and class are not selectable by mouse
Problem description When the user is selecting the race and class and other inputs, there is no possibility to do it with the mouse, only keyboard commands are available.
Screenshot(s) -
Scenario(s) A new user is starting to play the Crawl. He has been giving his name and now the game is asking him to choose the race. The user tries to click “Human” with mouse, but nothing happens.
Breaks heuristic(s) 6 (Intuitive and customizable controls)
Severity 1 (no priority)
Occurred in Testing (most or all)
Suggestion(s) Make species and background selectable with mouse.
Related page(s) Character Selection
Comments Again, fixed with the 0.7 starting menu overhaul. — jpeg 2010-12-26 21:46

1.10.

Problem summary [Improved] Player doesn't read texts of the starting screen after typing their name
Problem description When coming to the starting screen, there is text above and below the field, where the name is asked. The user does not pay attention to read the whole text through.
Screenshot(s)
Scenario(s) A new player downloads the Crawl to his laptop and is eager to start the game after hearing good recommendations about it from his friends. He starts the game and he is asked to give his name. After giving his name, he does not read the text below, because he assumes, that it is not essential. He misses the information about the tutorial.
Breaks heuristic(s) -
Severity 1 (no priority)
Occurred in Testing (3/6)
Suggestion(s) Overhaul the starting screen into a starting menu, which displays the choices, such as the tutorial in an easily readable manner. The tutorial should be mentioned before asking any inputs from the user.
Related page(s) Start / Welcome Menu
Comments Much less of a problem since the 0.7 starting menu overhaul. — jpeg 2010-12-26 21:46

1.11.

Problem summary Player doesn't recognize the meaning of subsequent choices in the character selection
Problem description Available choices in starting menus are spread out between the screens. Early on, it's hard for the player to make the connection between these choices.
Screenshot(s) -
Scenario(s) A new player is starting the game. First he comes in to the screen, where to give his name. After giving his name, he has to select the race. Randomly he decides to choose the “Mountain Dwarf” and continues to the next screen. In this screen he chooses just the first option, which is the “Fighter”. After this there is again another screen coming, where to select the weapon. After making all the earlier choices randomly, the user does not realize the connection between the choices. He does not understand, how to choose the weapon and he has not noticed commands for getting help to the selections.
Breaks heuristic(s) 9 (Instructions)
Severity 1 (no priority)
Occurred in Evaluation
Suggestion(s) a. Make the steps more visible in the interface with “Next/Previous”-buttons that you can move between screens with.
b. Flatten the number of needed selections (tweak the backgrounds so they don't include two (or even one) additional choices).
c. Giving the short one-sentence descriptions about each choice helps here too. Extend these to the weapon and god choices.
Related page(s) Character Selection
Comments I'm in favour of reducing the number of secondary selections to one, at most two extra screens. — jpeg 2010-03-13 00:14
At most one, I say. Also, we need to be more radical and just remove some selections. — dpeg 2010-03-13 22:06
Related to background reform 2782067evktalo 2010-03-16 11:31

2. Tutorial

2.1.

Problem summary [Improved] Tutorial Hints mode texts have too much information
Problem description The game tries to teach several things simultaneously.
Screenshot(s) -
Scenario(s) The tutorial shows player a message that shows multiple key commands at once. Long text and amount of information given at once makes it hard for the player to learn and remember all the information given at once.
Breaks heuristic(s) -
Severity 2 (low priority)
Occurred in Evaluation, Testing (2/6 at least)
Suggestion(s) Having a separate minigame tutorial mode to teach the basics will lessen the need for a lot of text in the hint mode (current tutorial).
Related page(s) Hints Mode Feedback
Comments The new tutorial is better, though hints mode still suffers from an extreme case of verbosity. — jpeg 2011-01-18 23:12

2.2.

Problem summary [FIXED] Tutorial gives some information about gameplay too soon
Problem description -
Screenshot(s)
Scenario(s) When facing first monster in deep elf conjurer tutorial the player is guided to look at the spellbook in his inventory rather than just simply telling him how to cast spells. The player is distracted away from the monster first into his inventory and secondly to the spellbook. Additionally before the player is told how to cast spells he is told how to memorize them (before it is even possible for the player to do so).
Breaks heuristic(s) -
Severity 2 (low priority)
Occurred in Evaluation
Suggestion(s) Review the current tutorial texts to reduce information overload.
Related page(s) Hints Mode Feedback
Comments The tutorial redesign helps with this, but it's still a problem for Hints mode. — jpeg 2011-01-18 23:12
However, hints mode assumes you've already played the tutorial and already know about all the basics. Thus, fixed. — jpeg 2011-02-03 22:15

2.3.

Problem summary Too long tutorial hints mode texts
Problem description Players may consider long tutorial texts boring or tedious to read. Secondly long descriptions hide information that is relevant in a tutorial message.
Screenshot(s)
Scenario(s) “To do magic, you can left mouse click on the monster you with to target (or on your player character to cast a spall on yourself) while pressing the Control key, and then select a spell from the menu. Or you can switch to the spellcasting display by clicking on the corresponding tab.” In case explaining a simple key combination takes whole two lines of text.
Breaks heuristic(s) -
Severity 2 (low priority)
Occurred in Evaluation
Suggestion(s) Go through each tutorial text and rewrite them. Remove notes about advanced and unnecessary actions, such as self targeting in example above. Having a separate minigame tutorial mode to teach the basics will also lessen the need for a lot of text in the hint mode (current tutorial).
Related page(s) Hints Mode Feedback
Comments As above, still a problem for Hints mode. — jpeg 2011-01-18 23:12

2.4.

Problem summary [FIXED] The word “tutorial” raises different expectations than what the mode actually is in the game
Problem description Tutorial was assumed to be a separate minigame.
Screenshot(s) -
Scenario(s) When new player starts playing the tutorial he expects to start some sort of minigame which teaches him how to play the game in safe environment. This assumption is proved false when his Deep Elf Conjurer is killed by first kobold appearing from behind a corner.
Breaks heuristic(s) -
Severity 1 (no priority)
Occurred in Evaluation, Testing (1/6)
Suggestion(s) Tutorial as a separate minigame where you can't die and it teaches the basic things about crawl. Another possibility would be to change the name of tutorial to something that better describes how it actually works, such as “paperclip mode” or “hint mode”.
Related page(s) Start / Welcome Menu
Comments I'm not sure what “paperclip mode” is supposed to mean, but hint mode would work, especially if “tutorial” refers to a separate minigame. — jpeg 2010-03-13 00:26
As a non-native english speaker, I have no clue what paperclip mode could mean. I suggest Guided Mode or Training Wheels instead. — b0rsuk 2010-03-14 09:33
Renamed to “Hints Mode” during the 0.7 starting overhaul. — jpeg 2010-12-26 21:46

3. Manual and help screens

3.1.

Problem summary Specific help text sections can be scrolled past the end of the section
Problem description It is unexpected that, when looking at a specific part of the manual, you can scroll past the end of the section. It is then difficult to find your way back to the section you wanted to read.
Screenshot(s) -
Scenario(s) Player opens the manual at section “H. Spellcasting”. Because the section is quite long he starts browsing the section by scrolling down. Accidentally the player scrolls past the entire spellcasting section of the manual. After realizing this he tries to scroll back up to the spellcasting section but again by accident scrolls past the section. Now player has completely lost the section of the manual he was trying to read.
Breaks heuristic(s) 6 (Intuitive and customizable controls)
7 (Easy-to-manage/sensitivity/responsivity)
10 (Easy-to-interpret)
Severity 2 (low priority)
Occurred in Testing (3/6)
Suggestion(s) Only scroll manual section within the specified section. Change between sections with left and right arrow keys.
Related page(s) http://crawl.develz.org/mantis/view.php?id=512
Comments

3.2.

Problem summary Some help texts are hard to reach
Problem description Some help texts are behind difficult symbols in the help screen
Screenshot(s) -
Scenario(s) The user is looking for a quick start guide in the ? help screen. It is really hard for him to understand and assimilate, that the command for that action is "^" (a character that is difficult to input in Scandinavian keyboards).
Breaks heuristic(s) 9 (Instructions)
Severity 2 (low priority)
Occurred in Evaluation, Testing (2/6)
Suggestion(s) ? screen selections should be clickable.
Related page(s)
Comments

3.3.

Problem summary Help files show information only relevant to console version of the game
Problem description In the help screen some things are described with the symbol from the console version
Screenshot(s)
Scenario(s) Player doesn't know what ”{” for example means, because the symbols are from the console version
Breaks heuristic(s) 10 (Easy-to-interpret)
Severity 2 (low priority)
Occurred in Testing (1/6)
Suggestion(s) Use the tile images in the help screen for the tiles version.
Related page(s)
Comments The glyphs are not totally nonsensical in this example, seeing how they're also displayed in the drop/pickup menu as item type shortcuts. I do agree, however, that showing tiles would be nicer. — jpeg 2010-03-13 00:26

3.4.

Problem summary Quickstart is not quick to read
Problem description While quickstart.txt is much shorter than the manual, it's still not short enough to browse through in a minute, understand the basic concepts of the game and get playing.
Screenshot(s) -
Scenario(s) -
Breaks heuristic(s) 9 (Instructions)
Severity 2 (low priority)
Occurred in Evaluation
Suggestion(s) Rewrite the quickstart so it explains the objective of the game, getting through starting menus “pick a minotaur fighter” and basic commands in a single screenful.
Related page(s)
Comments

3.5.

Problem summary [FIXED] AC, EV, SH are in different order on the manual that in the stat region
Problem description -
Screenshot(s) -
Scenario(s) Player tries to find from the help screen for what SH for example means. He thinks that the information is not there because they are in different order that in the stat region
Breaks heuristic(s) 10 (Easy-to-interpret)
Severity 1 (no priority)
Occurred in Testing (1/6)
Suggestion(s) Put AC, EV, SH to same order in the manual and the stat region.
Related page(s)
Comments Sounds like a documentation bug. — jpeg 2010-03-13 00:26
Fixed, at least in the wiki. — jpeg 2011-01-19 00:00

3.6.

Problem summary Finding the relevant information in manual can be difficult
Problem description When the player has a certain topic in mind, that s/he would like to know the basics of, the manual entries feel too long to read up on.
Screenshot(s) -
Scenario(s) The player is playing a Spriggan Venom Mage. He finds a scroll, but does not know what to do with it. He figures out that the command for the help is ”?” and gets to the starting screen of the help. He notices that with the “H” he gets information about spellcasting. When he arrives to the section about spellcasting and discovers how broad the amount of information is, he gets frustrated and returns to playing the game.
Breaks heuristic(s) 9 (Instructions)
10 (Easy-to-interpret)
Severity 1 (no priority)
Occurred in Testing (1/6 at least)
Suggestion(s) The most important issues are highlighted when reading the manual, so the user comprehends that it is not necessary to read the whole text through.
Related page(s)
Comments

4. Controls

4.1.

Problem summary Replying to y/n prompts is inconsistent
Problem description Replying to prompts works different ways in different situations.

yes: Quitting, walking in to a Zot traps
Y: Going up D:1 stairs, accepting a god, renouncing a god.
y: Saving a game, walking into a teleport trap.

There's a usability aim to making unthinking “yes” answers to dangerous prompts. At the same time, the difference between “Y” and “y” isn't obvious to new players (see 4.7.), and using shift-Y and “yes” is annoying. That the game always accepts lower-case “n” even when it asks “N” is confusing.
vi keys Requiring enterying a large-case “Y” protects accidental prompt answers with vi-keys. It's not consistent, however - (teleport) traps can be entered accidentally with small-case y. Also, allowing lower-case “n” where “Y” is required makes it possible to accidentally accidentally answer “no” accidentally. (Not sure if there are cases in the current game design where this is a problem).
Screenshot(s)
Scenario 1 The player tries to climb upward stairs on D:1. game asks “Are you sure you want to leave the Dungeon?”.
The player answers “y”. The game asks ”[Y]es or [N]o only, please.”
The player answers “y”. The game asks ”[Y]es or [N]o only, please.”
The player answers “y”. The game asks ”[Y]es or [N]o only, please.”
The player answers “y”. The game asks ”[Y]es or [N]o only, please.”
The player answers “n”. The game says “Alright, then stay!”
Scenario 2 One of the evaluators refuses to ever quit, but instead “ragesaves” with ctrl+s. That way there's no need to input the infuriating “yes”.
Breaks heuristic(s) 6 (Intuitive and customizable controls)
7 (Easy-to-manage/sensitivity/responsivity)
Severity 3 (high priority)
Occurred in Evaluation, Testing (3/6)
Suggestion(s) a Prompts can be answered with upper case or lower case letters. Make prompts configurable, so that vi-key users can remap them to capital letters.
b Make the prompts clickable.
Related page(s) Tiles Interface Ideas (Bulk)
Comments As you noticed, the three-level prompt separation does have its uses, and I'm a bit leery of the idea to give that up. Forcing upper-case prompts for vi users would be annoying, as well. And of course, clickable prompts are the answer to everything. :) — jpeg 2010-03-13 00:26
The prompts are far from ideal, but having several levels is probably okay. We need two levels (compare “target yourself?” vs “really quit?”; I am not sure about three. — dpeg 2010-03-13 22:08
In hints mode and the tutorial, these prompts now explicitly stress the need for these keys to be uppercase. — jpeg 2011-01-19 09:50

4.2.

Problem summary Keymaps cannot be changed in-game
Problem description Changing keymaps is very common option in modern games and is usually done via menu dedicated for this feature. Lack of traditional start menu structure along with dedicated options page makes even finding out about possibility of keymap customization very difficult.
Screenshot(s) -
Scenario In actual evaluation none of our evaluating team members were able to find a way to customize the keymaps. Possibility of changing the controls was only later pointed out for us by Eino.
Funny story First Eino opened up the manual and selected a page where keymap customization was mentioned. Next Eino went back in game and hit the button to remap a key. (… Not remembering exactly how the scenario went on I checked out manual for the page where the button to remap a key is mentioned… I couldn't find it.) Anyways… Eino said “Err… what the …?” and gave up trying to demonstrate how to remap keys. (He was trying to use the macros to do this, which is wrong anyway.)
Breaks heuristic(s) 6 (Intuitive and customizable controls)
Severity 3 (high priority)
Occurred in Evaluation
Suggestion(s) This would be a part of the in-game options setting feature.
Related page(s)
Comments Actually, they can be changed but apparently it's both complicated and undocumented how to do so. — jpeg 2010-03-13 00:26
I've recently read that ADOM would print a key list upon starting the game for the first time and tell the player how to change keymaps. This may be a good idea for us, too. — dpeg 2010-03-13 22:08

4.3.

Problem summary [Improved] Many actions in the game are mapped to special keys, which is very unintuitive, complex and unexpected for non-roguelike players
Problem description The game uses a lot of complex keymaps combining use of both lower and upper case buttons, special keys requiring either shift or alt to be pressed down, and mouse clicks combined with shift, alt or ctrl. In addition while upper case keys can be used without too much trouble using special keys forces even players with above average typing skills to look down at keyboard. Also the location of these special keys are often different depending on keyboard layout in use. For example ”@” which is quite easy on UK layout is quite awkward using Scandinavian layout. Using special keys also makes the controls very unintuitive.
Screenshot(s)
Scenario(s) -
Breaks heuristic(s) 6 (Intuitive and customizable controls)
Severity 3 (high priority)
Occurred in Evaluation
Suggestion(s) a Make everything clickable.
b Try reducing keymapping to special keys.
c Could use a multifunction key, or a simpler key that opens up a menu of some less-used informational commands. (Can keep the special keys as shortcuts, but the help should advertise the easy-to-access commands.)
d Remove actions that are available via mouse from keyboard (such as eat, quaff, read)
Related page(s)
Comments A special command tile tab is being planned (that would be option a), but b and c sound intriguing as well. However, I completely disagree with option d. There are players who switch from console to Tiles because of the monster icons and minimap, who already know the keyboard commands. Some of them even play the Tiles version without ever using the mouse. I see no reason to disallow this playing style. — jpeg 2010-03-13 00:26
What jpeg said. — dpeg 2010-03-13 22:08
And for example, I'm spanish and to type a "^", I need to Sift-^ and then a Space (as "^" is an accent) what is very annoying. — PhoneixS 2010-05-03 11:26
The command tile tab for large enough screens should help with this. — jpeg 2011-01-18 23:12

4.4.

Problem summary [Improved] Key combinations are shown in a complex and confusing way.
Problem description “Shift-L-Click” (stairs tooltip) or ”/ Dir., Shift-Dir.: long walk” (?? help).
Screenshot(s)
Scenario(s) Player mouse overs the tile where player character is standing. There are stairs in this tile so the tooltip says “Shift-L-Click” to use the stairs. Player presses down Shift and hits “L” on keyboard. When nothing happens he realizes that he should click the left mouse button instead.
Breaks heuristic(s) 10 (Easy-to-interpret)
Severity 2 (low priority)
Occurred in Evaluation, Testing (1/6)
Suggestion(s) 1. Use + rather than - between different keys (Ctrl + A)
2. Spaces might improve readibility (Ctrl+A vs Ctrl + A)
3. Commands with more than one dash are difficult to read (Shift-numpad-5 or Ctrl-L-Click), remove extra dashes by typing each key without dashes in middle (numpad5 or LClick)
4. Most complex shortcuts after these changes could look like this: Shift + numpad5 or Ctrl + LClick
Related page(s)
Comments And here we thought “L-Click” was self-explanatory… *sighs* To me, numpad5 looks really ugly and LClick much more technical than L-Click. Using “Shift + L-Click” might help, though. — jpeg 2010-03-13 00:26
Changed to “Shift + L-Click” in trunk. — jpeg 2011-01-19 09:50

4.5.

Problem summary Home key doesn't work in all help screens
Problem description Home key doesn't work from ”?:” help page “Browse character notes”. When in ”?Q” or “FAQ” hitting “Home” closes down the entire help page. When in ”?V” or “Version information” hitting “Home” does nothing at all.
Screenshot(s) -
Scenario(s) While trying to check out how exactly customizing keymaps works out in crawl for the problem scenario of the problem above, I started up Crawl and opened help. After checking out multiple different help pages and being unable to find the key to remap controls I started going through the help pages one by one, each time returning to the original help page by using “Home”. It came turn for ”:: Browse character notes”, so I hit ”:”, from this screen I was unable to return back to the original help/manual menu with “Home” Also when trying “Home” from ”?Q” or “FAQ” the entire help screen closes.
Breaks heuristic(s) 1 (Consistency)
Severity 2 (low priority)
Occurred in Evaluation
Suggestion(s) Review all the different help etc screens and make their behavior more consistent.
Related page(s)
Comments This is one of the ideas that should be used as-is. Also, all lists should work uniformly, as much as possible. (There have to be slight deviations; for example, the ? key cannot give help in the pickup/drop menus, as it is the scrolls shortcut there. But such exceptions are rare and can be worked around.) — dpeg 2010-03-13 22:08

4.6.

Problem summary Scrolling controls
Problem description The meaning of ”+/L-click: Page down -: Page up. Esc/R-click exits.” is unclear.
Screenshot(s)
Scenario(s) When scrolling the help text with mouse, the player can not scroll back to the earlier stage, because the scroll button does not work and the right mouse button exits the help.
Breaks heuristic(s) 1 (Consistency)
6 (Intuitive and customizable controls)
9 (Instructions)
Severity 2 (low priority)
Occurred in Evaluation
Suggestion(s) Scroll up: arrow up, page up. Scroll down: arrow down, page down.
Related page(s) http://crawl.develz.org/mantis/view.php?id=512
Comments As above. — dpeg 2010-03-13 22:08

4.7.

Problem summary [Improved] The difference between lower and upper case letters as commands is hard to pick up
Problem description The player doesn't realize s/he should enter a command letter in upper case.
Screenshot(s) -
Scenario 1 The player is standing next to the door, wanting to close it to keep the jackal from reaching him. He points at the door with the mouse, and reads the “C” command from the description that is on top of the message window. Player tries to press “c” (lower case) multiple times. The game responds “There isn't anything there!” Player gets frustrated and says “Ok, not then.”
Scenario 2 The player tries to climb upward stairs on D:1. game asks “Are you sure you want to leave the Dungeon?”. The player answers “y”. The game asks ”[Y]es or [N]o only, please.” The player answers “y”. The game asks ”[Y]es or [N]o only, please.” The player answers “y”. The game asks ”[Y]es or [N]o only, please.” The player answers “y”. The game asks ”[Y]es or [N]o only, please.” The player answers “n”. The game says “Alright, then stay!”
Breaks heuristic(s) 6 (Intuitive and customizable controls)
Severity 2 (low priority)
Occurred in Evaluation, Testing (3/6 at least)
Suggestion(s) For yes/no questions, use clickable buttons. In tooltips and other such help, offer “Shift-T” instead of “T” for capital T. (Doesn't unfortunately work for other buttons than letters, thanks to different keyboard layouts.)
Related page(s)
Comments I am not sure this is a problem for console players (who generally will be aware that commands are case sensitive). — dpeg 2010-03-13 22:08
I don't think this will be necessary. We are better served with initially making it clear (in the documentation and tutorial) that commands and menu choices are case sensitive. However, I do agree that the door description (mentioning the C “key”, rather than “command”) can be somewhat misleading. — jpeg 2010-03-17 17:07
The tutorial explicitly describes all uppercase letters as e.g. “uppercase Y”. — jpeg 2011-01-22 20:30

4.8.

Problem summary Mouse wheel cannot be used to scroll manuals, message logs etc.
Problem description (see summary)
Screenshot(s) -
Scenario(s) When reading the manual, a tester attempted to use the mouse wheel to scroll the long text.
Breaks heuristic(s) 6 (Intuitive and customizable controls)
Severity 1 (no priority)
Occurred in Testing (1/6)
Suggestion(s) Mouse wheel is not used at all currently. Scrolling the scrollable texts would be a natural function. However, this is not as much a problem as a feature suggestion; one tester intuitively tried to use the mouse wheel for browsing the manual - other testers that read the manual in-game did not do so.
Related page(s)
Comments

4.9.

Problem summary vi-keys are obscure and unintuitive
Problem description vi-keys are not an intuitive way to move the character, in the tutorial, they are given a lot of attention via highlighting
Screenshot(s) -
Scenario(s) A new player starts playing the tutorial and gets confused when the game says “you can move around with hjklyubn”. Then he starts to play with the arrow keys which is not a good option because you can't move diagonally with them.
Breaks heuristic(s) 6 (Intuitive and customizable controls)
Severity 1 (no priority)
Occurred in Evaluation, Testing (at least two people)
Suggestion(s) a Numpad should be also highlighted in the tutorial texts and the use of plain arrow keys should be discouraged. hjklyubn should only be mentioned as “back-up” option for people with no numpad (or for those already familiar with them), so that the player doesn't think they're expected to use them as the main method of movement.
b Provide another keymap for numpad-less keylayouts, with movement keys based on the WASD scheme more familiar to gamers.
Related page(s) Wikipedia WASD entry
Comments How would WASD help with diagonal movement? — jpeg 2010-03-13 00:26
The main problem here is that for a modern gamer vi-keys are completely unknown and WASD is considered a standard. We have actually started planning an alternative WASD, or rather WAXD keyboard layout that uses QEZC as diagonal movement keys. This places the movement keys to the familiar WASD region and allows use of a familiar numpad shaped area of movement keys. — aslakkar 2010-03-13 01:59
That sounds like a good idea. Unfortunately, it suffers from the same problem the vi keys do: y and z being switched on, at least, German keyboards. :( — jpeg 2010-03-13 09:20
No, it's not a good idea. I see where the UP team is coming from, of course, so let me explain a bit: Yes, in generally it is a good idea to use an established control system (and WASD is well-established among several genres). However, vi-keys are the best standard among roguelikes, so that is definitely a reason to keep using them. (We want to make it easy for roguelikers to try Crawl.) What's worse, the WASD keys are already in use (wield, ability, drop are crucial, search is not). So going to WASD would require to dispense with the vi standard of the mother genre (roguelikes) as well as redefining three standard keys. This is a bad idea, in my opinion, because for most players (without roguelike background and with keyboard are input device), the numpad will be the simplest choice. (And then also what jpeg said.) — dpeg 2010-03-13 22:08
Ah, but I don't think aslakkar was talking about replacing the vi keys. Rather, you could define an alternate key set like they already did for the Dvorak keys. The difficult part is keeping the documentation in sync. (It's why I added the possibility to access the appropriate command strings depending on the used keymaps.) Ideally, players could then pick between different keysets (basic-vi, basic-WAXD, dvorak-vi, …) and the game would dynamically use the correct keys on the help screen. We can keep the current one default, but it _would_ be nice to have a normal, numpad-like order of movement keys. I still keep mixing up h and l, and j and k. It's why I only use the vi keys for diagonal movement and the arrow keys, otherwise. — jpeg 2010-03-14 20:30

4.10.

Problem summary Executing multi-drop can only be done with keyboard
Problem description (see summary)
Screenshot(s)
Scenario(s) Player wants to drop all clubs from the inventory so he hits “d” to open multi-drop menu. Then the player selects all clubs from the list with mouse as it is quicker and easier than selecting them with letters p, q, r, s, t, u and v. After selecting the items player stops to wonder how to finalize the drop, expecting some sort of “OK” or “Drop” button to click. Not finding any buttons to click with the mouse to finalize the drop the player's hand rooted firmly on wasd keys first hits “space” being closest all-round button to his hand. Nothing happens so the player tries out hitting “enter”, this finally executes the multi-drop action.
Breaks heuristic(s) 6 (Intuitive and customizable controls)
Severity 1 (no priority)
Occurred in Evaluation
Suggestion(s) Add a “Drop” button to the multidrop screen.
Related page(s)
Comments

4.11.

Problem summary [FIXED] Resting with mouse is unintuitive
Problem description Clicking stat region causes 100 turn rest. The stat region does not look clickable. The player is more likely to accidentally click it than realize to use it for the purpose.
Screenshot(s)
Scenario(s) Even after playing the game for a few months and being aware of importance of resting, the evaluator had no idea that resting could be done by clicking the stat region with mouse.
Breaks heuristic(s) 6 (Intuitive and customizable controls)
Severity 1 (no priority)
Occurred in Evaluation
Suggestion(s) Add a “Rest” button.
Related page(s)
Comments The new command tile tab does include a rest button. — jpeg 2011-01-18 23:12

5. Stairs

5.1.

Problem summary Controls for using stairs are unintuitive
Problem description The player moves over the stairs for the first time in the game and does not know how to use them.
Screenshot(s) -
Scenario(s) A new player is playing Crawl. He is moving around in the first Dungeon. He sees a stairs leading down and decides to climb. The player moves on the top of the icon. He thinks he gets down by clicking the icon with left mouse button. He misses the tooltip and tries to use enter button then. Nothing happens, the user thinks that he can not go down there and continues the game in the first dungeon.
Breaks heuristic(s) 1 (Consistency)
6 (Intuitive and customizable controls)
Severity 3 (high priority)
Occurred in Evaluation, Testing (5/6)
Suggestion(s) Change default keybind for using stairs to enter and/or left mouse button. (Rebind picking up items from player's tile to Shift + LClick). Use the same behaviour for altars and fountains. Additionally, having two different keybinds for going up and down the stairs is unnecessary - all the stairs and gateways can only be taken to one direction.
Related page(s)
Comments Picking something up is a much more common action than taking stairs and I really like how you can enter the pickup menu with a simple double-click. I thus refuse to budge on this issue. :p However, in the next section you suggest to always include actions specific to certain features in the tooltip, even if not on the same square or even adjacent to it. This should solve this and related issues nicely. Also, there is one difference between < and >: downstairs can only be entered if not levitating. — jpeg 2010-03-13 00:26
That's a difference between upstairs and downstairs, not ”<” and ”>” commands. — evktalo 2010-03-16 11:38
Mouseover descriptions now include staircases even if not standing on them. Making ”<” and ”>” synonymous is still an option. — jpeg 2011-01-19 09:50

5.2.

Problem summary [Improved] Accessing the tooltip for stairs and altars
Problem description The player tries intuitively to reach the tooltip (with the tips for entering/praying) by standing next to altar or stairs, but he gets it only by standing on it.
Screenshot(s)
Scenario(s) The player is moving around and notices stairs leading down. He thinks it is now time to move to the next Dungeon. The player is standing next to the stairs and moves the mouse on the top of the icon. A tooltip appears, which saying, [L-click Move, R-click Describe]. The player thinks that he can move down by clicking the icon with left button of the mouse. He clicks once, moving the character on top of the stairs. Clicking the button again, nothing happens. The player gets frustrated, thinks that he can not go down there and continues the game in the same Dungeon.
Breaks heuristic(s) 9 (Instructions)
Severity 2 (low priority)
Occurred in Evaluation, Testing (at least 1/6)
Suggestion(s) Always show all possible actions related to the tile in the tooltip. Gray out possibilities that are not available from the player's position.
Related page(s)
Comments I like this. The tooltip can't handle formatted text, but that would be a nice addition. — jpeg 2010-03-13 00:26
Mouseover descriptions now include staircases even if not standing on them. — jpeg 2011-01-19 09:50

5.3.

Problem summary [Improved] Player doesn't realize that the game will end by going up the stairs at first level of the dungeon
Problem description (see summary)
Screenshot(s) -
Scenario(s) A new player starts the game. The starting screen is a difficult kind of, there is only stairs leading up away from the Dungeon and walls around the character. The player uses the arrow keys to moving around and he does not realize that he can move diagonally. He thinks that the only way to get ahead is to climb up the stairs, so he escapes from the Dungeon and the game is over.
Breaks heuristic(s) 9 (Instructions)
Severity 1 (no priority)
Occurred in Testing (2/6 at least)
Suggestion(s) When the user is trying to climb up the stairs in the first level of the game, the game should give exact information, for example in the message log, that this action will end the game.
Related page(s)
Comments The tutorial does have such a prompt. Extending it to the main game only makes sense. — jpeg 2010-03-13 00:49
The exit stair tiles now look completely different, and the stair description (when stepping on it) refers to leaving the dungeon, as well. We still don't have a secondary prompt. Do we need one? — jpeg 2011-01-18 23:12

6. Display

6.1.

Problem summary [Improved] Tile description texts prevent message log from showing
Problem description If your cursor is on top of visible squares, the message window is obscured by the description. It is tiresome to move the cursor away from the LOS (or from top of the dungeon region), and it's very hard to realize what you should do to get rid of the annoyance. For starting players, the possibility of understanding the message window's significance is denied.
Screenshot(s) -
Scenario 1 How to reproduce:
0) Use only mouse for moving.
1) Click on a square to travel to it.
1.1) Your character moves to it.
1.2) Message window is displayed.
1.3) Cursor is now on top of a different square.
1.4) The description of this different square is shown on top of the message window.
Scenario 2 A tester is using Ctrl+Click to cast spells at a goblin. After casting a couple of Flame Tongues, the tester wonders where the goblin disappeared (it got killed). The mouseover descriptions covered the message window throughout the combat. (There was no corpse or blood left behind in this particular battle.)
Breaks heuristic(s) 7 (Easy-to-manage/sensitivity/responsivity)
10 (Easy-to-interpret)
Severity 3 (high priority)
Occurred in Evaluation, Testing (3/6 - all who used mouse for movement)
Suggestion(s) A. Only use mouseover description when looking at inventory or spell tab. The player can right-click the dungeon region for descriptions.
B. Don't show the description for common features, such as floor and walls. (Already implemented in master.)
Related page(s)
Comments As mentioned above, floor and wall descriptions don't get displayed this way. Could be extended to other non-special features, e.g. shallow water. — jpeg 2011-01-18 23:47
Simple mouseclicks won't trigger descriptions anymore, however tiny mouse moves by a pixel or two still will. — jpeg 2011-01-22 20:30

6.2.

Problem summary [FIXED] Tooltip erases mouseover short description
Problem description When the tooltip appears, the mouseover short description is erased from view. Tooltip usually appears so fast, that there's not enough time to read the short description. To view the short description again, you need to move the cursor over another tile and then move it back again.
Screenshot(s) -
Scenario(s) Player mouses over a tile he hasn't seen before to see what it is. He first gets short mouseover description that tells the name or type of the tile. However very soon afterwards the name or description text disappears as the blue tooltip pops up.
Breaks heuristic(s) 7 (Easy-to-manage/sensitivity/responsivity)
10 (Easy-to-interpret)
Severity 2 (low priority)
Occurred in Evaluation
Suggestion(s) Do not erase the short description when the tooltip appears.
Related page(s)
Comments Part of this was a bug that was since fixed. The other part also has been improved. — jpeg 2011-01-18 23:12

6.3.

Problem summary [Improved] Excessive and hard to understand prompt choices when picking up multiple items from one square
Problem description y/n/a/*?g,/q/o is very confusing. “o” starts autoexplore, and we couldn't figure out why it's included. Listing all of *?g, which do the same action crowds the prompt. None of the *?g, really speak their function.
Screenshot(s)
Scenario(s) The player moves to square, which has many items on it and hits ”,” to pick up items. Prompt saying “Pick up a +2, +2 mace? (Left click to enter menu, or press y/n/a/*?g,/q/o)” It is difficult for the player to understand how to pick up them.
Breaks heuristic(s) 1 (Consistency)
Severity 2 (low priority)
Occurred in Evaluation
Suggestion(s) Change the prompt into: yes / no / all / open menu (g)
Related page(s)
Comments Sounds good, but as 'g' is synonymous with ',' both should be mentioned. Also, this is assuming that q/Esc is self-explaining. — jpeg 2010-03-13 00:49
According to my understanding 'g' is also synonymous with '*' and '?' in this case, so this makes total 4 keys that do exactly the same thing. Our recommendation is to only show one key option per action in prompt texts to avoid confusion and cluttering. This was one of our hot topics during the evaluation, we were able to easily figure out meaning of y/n/a, but further than that we had absolutely no idea what the other options meant. — aslakkar 2010-03-13 02:15
Ah, sorry. I meant that these two commands are synonymous for pickup. The point of listing 'g' is that you can comfortably use 'gg' to enter the pickup menu, same as you can ',,' if you are using that one. Listing '*' and '?' is pointless for this purpose, though it is consistent with other prompts. – jpeg 2010-03-13 09:20
On second thought, we already keep track of the last command issued (for the “redo” command), so it shouldn't be too difficult to respond dynamically to that, filling the “open menu” command with whatever the player used to start pickup ('g', ',' or mouseclick), which brings across the easy-access information for whichever command the player is comfortable using. — jpeg 2010-03-13 19:18
That sounds good. — evktalo 2010-03-16 11:40
Made more explicit for at least some prompts. (I don't think I got them all.) — jpeg 2011-01-19 09:50

6.4.

Problem summary “You die” is easy to miss
Problem description When the user is playing the game in a way that involves repeatedly pressing buttons or clicks with mouse, the information about dying is easily missed in the message window and he does not notice that he gets killed.
Screenshot(s) -
Scenario(s) The player is playing the game with the “Spriggan Venom Mage”. He is fighting with the enemies with a spamming kind of tactic and does not notice the information about decreasing amount of “Health” in the information bar. He does not also notice the “You die” in the message window and suddenly he is in the inventory screen. He does not realize, that he gets killed.
Breaks heuristic(s) 1 (Consistency)
Severity 2 (low priority)
Occurred in Evaluation, Testing (at least 2/6)
Suggestion(s) Add a clickable “OK” pop-up, or even a splash screen when dying.
Related page(s)
Comments I think there's a forced -More- prompt now, but that doesn't help a lot. — jpeg 2011-01-18 23:12

6.5.

Problem summary Window size cannot be changed
Problem description If the default game window size happens to be undesirable to the player for some reason there is no in-game way to change it.
Screenshot(s) crawldualscreen.jpg
Scenario(s) When using computer with two monitors (with settings that treat the space as a single monitor), the game window will cover both of the monitors and wastes a lot of space with blank black screen.
Breaks heuristic(s) 2 (Customizable settings)
Severity 2 (low priority)
Occurred in Evaluation
Suggestion(s) (a) Make the window resizable with mouse by dragging the window border.
(b) This should also be part of the in-game adjustable options.
Related page(s) http://crawl.develz.org/mantis/view.php?id=1004
Comments

6.6.

Problem summary Some status indicators are hard to understand
Problem description Status indicator terms such as “BWpn” and “tele” and “pois” are difficult for the new player to understand. If the player fails to pay attention and/or make a connection between game actions, message window and/or status indicators, it is a struggle to figure out the meaning of these abbreviations without looking at the manual.
Screenshot(s) status.jpg
Scenario(s) -
Breaks heuristic(s) 8 (Game status)
10 (Easy-to-interpret)
Severity 2 (low priority)
Occurred in Evaluation
Suggestion(s) Implement tooltips for each status effect that explains what they mean.
Related page(s)
Comments I like the idea to extend tooltips to other areas. Might be hard to implement, though. — jpeg 2010-03-13 00:49
“Bwpn” has recently been changed to “Breath”, which is more understandable. I do think that “Pois” is pretty self-explanatory, and that “Tele” is easy to map to the behaviour once you've experienced teleportation. Some of the randart autoinscriptions might be pretty confusing, though. — jpeg 2010-12-26 21:57

6.7.

Problem summary Fog of war monster ghosting
Problem description Sometimes, it's possible to multiply the amount of “known” monsters via ghosting in the fog of war. The game by nature places a monster “ghost” in the fog of war if said monster gets out of player line of sight. However, if you drag a monster just on the edge of the fog, every turn taken will add a new “ghost” to the trail, producing a hilarious effect
Screenshot(s)
Scenario 1 Any occurence where you're kiting or running away from a monster that is just at the edge of the fog of war, following you.
Scenario 2 A tester commented out loud: “There's too many monsters in there, I'm not going back there.” Those were all “ghosts” of one orc.
Breaks heuristic(s) 8 (Game status)
Severity 2 (low priority)
Occurred in Evaluation, Testing (about two)
Suggestion(s) Provide a solution for this case (edging just at the fog of war) that does not add the ghost if the monster is still visible the next turn.
Related page(s)
Comments With the unique monster ids, it might now be possible to improve this. — jpeg 2011-01-18 23:12

6.8.

Problem summary [URGENT!] User might not realize being in “targeting mode”
Problem description When trying to cast a spell or fire a ranged weapon user might not realize having entered targeting mode, especially when the player is not yet comfortable with the commands. Accidentally pressing 'f' or 'x' can also make this problem surface.
Screenshot(s)
Scenario(s) The tester wants to cast spells. No monsters are around, and he has figured out that 'Z' is the right command, but doesn't yet know how it works. The tester presses 'Z', reads that pressing '*' will get him the list of available spells, and uses it. He selects sting from the menu that appears. Then he is returned to the main view. No monsters are around, so nothing is autotargeted. He doesn't realize what to do next.
Breaks heuristic(s) 1 (Consistency)
10 (Easy-to-interpret)
Severity 2 (low priority)
Occurred in Evaluation, Testing (at least 1/6)
Suggestion(s) In tiles, it's possible hilghlight the dungeon view with a transparent overlay. This overlay would change the outlook of the view subtly, but noticeably. Also, there would be a text that says “firing mode”, “casting mode”, examining mode”, “targeting mode”, … The change would get the player to look for explanation, and the text would tell what was going on.
Related page(s)
Comments

6.9.

Problem summary Item description texts prevent item stats from showing
Problem description When mouse overing over an item, long description texts prevent actual item stats from showing in message log window.
Screenshot(s) -
Scenario(s) -
Breaks heuristic(s) 10 (Easy-to-interpret)
Severity 1 (no priority)
Occurred in Evaluation
Suggestion(s) Prioritize item stats to show if there is little space.
Related page(s)
Comments

6.10.

Problem summary [Improved] Message log history is difficult to find
Problem description -
Screenshot(s) -
Scenario(s) While playing the tutorial player keeps constantly moving with arrow keys. This causes some tutorial text just quickly flash by. Player notices the flashing text and tries to find out what it was. He opens the manual to try and look for the answer but doesn't try clicking on the message log area.
Breaks heuristic(s) 6 (Intuitive and customizable controls)
10 (Easy-to-interpret)
Severity 1 (no priority)
Occurred in Testing (1/6)
Suggestion(s) Add a clickable button to access the message history.
Related page(s) Mouse Playability
Comments Included in the tile command tab. — jpeg 2011-01-18 23:12

6.11.

Problem summary Meaning of values in stat region unclear
Problem description The abbreviations are difficult to interpret.
Screenshot(s) -
Scenario(s) Player wonders aloud what AC, EV and SH mean. He opens the manual, and finds the right section. (But see problem 3.4)
Breaks heuristic(s) 9 (Instructions)
Severity 1 (no priority)
Occurred in Evaluation, Testing (2/6 at least)
Suggestion(s) a Write entire name of a value (Armor Class etc.) (Eino's comment: won't fit)
b Add a tooltip for each element of the stat region.
Related page(s)
Comments

6.12.

Problem summary Important messages in message log are easily missed
Problem description When there is lot of action going on in the game, the message log is running fast and the user may miss important information in it. (Of course, the game is turn-based and the player can take all the time they need between turns, but when the game gets exciting, this is can be hard to remember.)
Screenshot(s) -
Scenario 1 The user is surrounded by enemies. He tries to destroy them fast and gets excited. He pays all of his attention to the enemies and does not realize that he got poisoned while fighting. Trying to continue after battle, traveling gets interrupted by poison messages. By now, it is too late to react to poisoning (no healing potions, but could have escaped earlier from battle.)
Screnario 2 The player is playing without paying much attention to the message window. The game is halted with –more– in the message window. The player is confused, bashes random keys for a while until hitting enter and the game proceeds.
Screnario 3 The player gets mutated by Xom during an intense battle. This goes unnoticed by the player even though it has drastic effects on the character.
Breaks heuristic(s) 10 (Easy-to-interpret)
Severity 1 (no priority)
Occurred in Testing (4/6)
Suggestion(s) a Use the monster status icons (such as poison) for players as well.
b Flash the screen briefly when getting poisoned etc.
Related page(s)
Comments I've added a poison icon to the player doll. — jpeg 2011-01-18 23:12

6.13.

Problem summary [FIXED] Tooltip for doors is missing closing and opening commands
Problem description Standing next to the open door and pointing at the door only lists “Move” command, not “Close”. Closed door only lists “Describe”, not “Open”. The commands are listed in the feature description, but this is inconsistent.
Screenshot(s)
Scenario(s) A new player is standing next to the door, wanting to close it to keep the jackal from reaching him. He points at the door with the mouse, expecting to see the command in the tooltip. The player does read the command from the description that is on top of the message window.
Breaks heuristic(s) 1 (Consistency)
9 (Instructions)
Severity 1 (no priority)
Occurred in Testing (1/6)
Suggestion(s) Add the missing commands to the tooltip.
Related page(s)
Comments Oh, good one. Disarming traps was only recently added, as well. — jpeg 2010-03-13 00:49
Added in trunk. — jpeg 2010-03-17 17:04

7. Game mechanics

7.1.

Problem summary [FIXED] It is not obvious that resting is the main way of regaining health
Problem description The resting mechanic is not communicated by the interface, so it's not an obvious action for the player to do.
Screenshot(s) -
Scenario(s) When player is low on health he first tries to eat the bread rations or other food he may have in the inventory. Alternatively he tries to use a potion, but resting never seems to be obvious way of healing.
Breaks heuristic(s) 9 (Instructions)
Severity 3 (high priority)
Occurred in Testing (3/6 at least)
Suggestion(s) Same as 4.11 - make a visible button for resting in the interface.
Related page(s) Mouse Playability
Comments The tutorial mentions this, a lot. Also, the command tile tab helps. — jpeg 2011-01-18 23:12

7.2.

Problem summary [FIXED] Player doesn't realize that corpses need to be chopped before eating
Problem description Chopping corpses for food is somewhat complicated game mechanism.
Screenshot(s) -
Scenario(s) A player with previous Nethack experience tried to eat corpses, but didn't know that they need to be chopped first. He assumed that the corpses couldn't be eaten.
Breaks heuristic(s) 9 (Instructions)
Severity 2 (low priority)
Occurred in Evaluation, Testing (number unsure)
Suggestion(s) Add text “This corpse can be chopped for food.”
Related page(s)
Comments Explained in the tutorial. — jpeg 2011-01-18 23:12
Also, corpse descriptions mention butchering. — jpeg 2011-02-03 22:15

7.3.

Problem summary [Improved] Meaning of inscribe is unclear
Problem description When examining any item the inscribe text really jumps out at the player. Because of lack of further information about the inscribe feature the entire meaning of inscribe is left unclear to the player, only causing confusion.
Screenshot(s) -
Scenario(s) Player examines a potion and notices help text telling how to inscribe items. Player presses “i” to inscribe and becomes confused when the game asks “Inscribe with what?”. Player becomes frustrated and hits esc to get away from the evil and confusing inscribe feature.
Breaks heuristic(s) 9 (Instructions)
Severity 2 (low priority)
Occurred in Evaluation, Testing (2/6 at least)
Suggestion(s) a Remove or hide the help text for inscribing (at least in tutorial, or mention that is meant for power-users).
b Also display “press Esc to exit” so that the player doesn't think inscribing is the only (or an important) option.
Related page(s)
Comments Yeah, hiding the inscription prompt in the tutorial might make sense, esp. as you can still do so from '{'. Still undecided, though. — jpeg 2010-03-13 00:49
With the new item-based command prompts, inscriptions don't stand out anymore. I don't think it's a problem for hints mode anymore, and I've deactivated them in the Tutorial. — jpeg 2011-01-18 23:55

7.4.

Problem summary [Improved] Accessing spell list is behind unintuitive shortcut
Problem description -
Screenshot(s) -
Scenario(s) Our tester started a game using s conjurer. The tester realized that he would have to cast spells to kill the monsters he ran into. When trying to open up a spellbook he first said he'll try “magic” and hit “m”. Obviously this did not cause the expected action. Next he said he'll try out “spells” and hit “s”, again this did not cause the expected action to happen. Finally the tester found out how to cast spells by mouse overing a monster for long enough to notice Ctrl-L-Click tooltip. After this he was able to cast spells, but never noticed that he could have also hit “z” on keyboard to cast spells.
Breaks heuristic(s) 6 (Intuitive and customizable controls)
Severity 2 (low priority)
Occurred in Testing (2/6)
Suggestion(s) Spell tab probably makes it easier to cast spells. “z” is a nethackism, and difficult to guess for non-roguelikers. Could it be remapped?
Related page(s)
Comments Due to letter shortage, many commands will have arbitrary key designations. That said, remapping 'z' to the redundant 's' is fine by me. — jpeg 2010-03-13 00:49
The first remark is that casting should be (easily!) possibly for mouse users without even having to press a key. For keyboard users, I don't think that “z” is any worse than “s”. The ”??” list of items sums it up very nicely, in my opinion (again, for keyboard users). — dpeg 2010-03-13 22:37
With the recently added detached spell tab, this is less of a problem. — jpeg 2010-12-26 21:57

7.5.

Problem summary [FIXED] Casting spells is not feasible with mouse (in the testing version)
Problem description Technically, the spells can be cast with mouse by ctrl-clicking the player or monster, but this is rather difficult to find out. In addition casting spells this way requires clicking the monster two times, first when ctrl-clicking, second time when targeting.
Screenshot(s) -
Scenario(s) -
Breaks heuristic(s) 6 (Intuitive and customizable controls), 7 (Easy-to-manage/sensitivity/responsivity)
Severity 2 (low priority)
Occurred in Testing (1/6)
Suggestion(s) Casting with mouse is in genral easier in later versions with the introduction of spell tab. Clicking the same target twice should be fixed though by remembering the target of the first click.
Related page(s)
Comments Actually, the last monster will already be autotargeted. Clicking on the monster again is one way to confirm this choice. I really don't want this to happen automatically. (There was a bug recently where it worked like that, and I hated it.) — jpeg 2010-03-13 00:49
On second thought, pre-confirmed autotargeting was usually exactly what I wanted, except when the beam path revealed that I was going to hit another monster in the way, so if we manage to check for that and treat this differently (without allowing the player to pick a different beam path than is possible by using the keyboard commands) this would work nicely. Maybe require confirmation (as now) if the targeted monster is not the first visible monster in the path, otherwise shoot right away. Note that the latter might be confusing if you miscast a spell. — jpeg 2010-03-13 01:19

7.6.

Problem summary [FIXED] When or why items are or are not auto-picked up is unclear
Problem description -
Screenshot(s) -
Scenario(s) a) Player gets confused because some items get picked up automatically and some things not.
b) Some things were auto-picked earlier but not again, and why this is is not evident for the new player.
Breaks heuristic(s) 9 (Instructions)
Severity 2 (low priority)
Occurred in Testing (2/6)
Suggestion(s) Make a tutorial mission about picking up items and autopickup.
Related page(s)
Comments Covered in the new tutorial. — jpeg 2011-01-22 20:30

7.7.

Problem summary [FIXED] It is not obvious that the player can (and should) move diagonally
Problem description Movement is diagonally impossible with arrow keys, but it is intuitive to use them for movement.
Screenshot(s) -
Scenario 1 The player starts the game. The starting screen is a difficult kind of, there is only stairs leading up away from the Dungeon and walls around the character. The player uses the arrow keys to moving around and he does not realize that he can move diagonally. He thinks that the only way to get ahead is to climb up the stairs and so he escapes from the Dungeon and the game is over.
Scenario 2 A tester with Nethack experience was surprised that he could move through a diagonal corridor of single width.
Breaks heuristic(s) 9 (Instructions)
Severity 1 (no priority)
Occurred in Evaluation, Testing (at least 2/6)
Suggestion(s) a. Discourage use of arrow keys and encourage using numpad or mouse instead.
b. In the future level-based tutorials, make one mission about diagonal movement.
Related page(s)
Comments For me, using the arrow keys/vi keys is much more comfortable than movement by mouseclick. I don't have a numpad, though. — jpeg 2010-03-13 00:49
I would like to mention that ideally console vs tiles and keyboard vs mouse should be independent choices. It is a very worthwhile goal to achieve a mouse-only interface, of course. — dpeg 2010-03-13 22:31
The tutorial makes a big point of diagonal movement being possible, though it leaves the strategic value for the player to work out (which is exactly as it should be). I'm not sure whether this resolves this issue. — jpeg 2010-12-26 21:57
The main problem seemed to be that it was unclear to the testers that diagonal movement was possible at all. — evktalo 2010-12-30 10:38
In that case, it gets explained in the tutorial. — jpeg 2011-01-18 23:12

8. Other

8.1.

Problem summary No in-game settings
Problem description While the game does have some settings that can be changed, these settings are not accessible in-game. First of all to even find out about game settings player would have to read the readme, which quite honestly is unlikely. Also if player actually does find the settings they will have to be manually edited in a complex text file. Amount and overwhelming size of the setting files add to the difficulty of changing the settings.
Screenshot(s) -
Scenario(s) -
Breaks heuristic(s) 2 (Customizable settings)
Severity 3 (high priority)
Occurred in Evaluation
Suggestion(s) Make in-game settings for the most important and most likely to be changed game settings. Especially choosing keymaps/control schemes.
Related page(s)
Comments

8.2.

Problem summary [FIXED] It is confusing that the game shuts down when player dies
Problem description When the game is over, the game shuts down.
Screenshot(s) -
Scenario(s) a) Player is confused when the game shuts down after dying. Player thinks that the game has crashed
b) A new player gets frustrated starting the game multiple times when dying quickly after the start of the game.
Breaks heuristic(s) 1 (Consistency)
Severity 3 (high priority)
Occurred in Evaluation, Testing (number unsure)
Suggestion(s) Return the player to the starting menu after dying.
Related page(s) http://crawl.develz.org/mantis/view.php?id=889
Comments The restart_after_game option (added in 0.7) defaults to true for Tiles games. — jpeg 2010-12-26 21:57

8.3.

Problem summary Player gets stuck on long “more”
Problem description On the message window the player gets stuck on “more”, he does not know how to pass it.
Screenshot(s) -
Scenario 1 The player notices the “more” in the message window, but he does not understand, that he has to pass it with enter or space -button. The player thinks that the game is crashed.
Scenario 2 The player plays without paying much attention to the message window. The game seemingly freezes to a –more– prompt. Random bashing of keys gets them through the pause.
Breaks heuristic(s) 1 (Consistency)
6 (Intuitive and customizable controls)
9 (Instructions)
Severity 2 (low priority) - 3 (high priority) depending on case
Occurred in Evaluation, Testing (2/6)
Suggestion(s) Display – press enter for more – for the long more. Use error sounds and flash the message area red briefly when pressing wrong key for prompts.
Related page(s)
Comments The tutorial has a more informative -More- prompt and I'm in favour of using something longer in the normal game as well. Others are violently opposed to the idea. — jpeg 2010-03-13 00:49

8.4.

Problem summary [FIXED] Player gets stuck on small more
Problem description Unless you know what to expect, the meaning of ”+” in the message log is very hard to understand.
Screenshot(s) -
Scenario(s) Player levels up, but doesn't notice or understand the plus sign. Player thinks that the game has crashed because he can't move or do any other actions.
Breaks heuristic(s) 1 (Consistency)
6 (Intuitive and customizable controls)
9 (Instructions)
Severity 3 (high priority)
Occurred in Evaluation, Testing (4/6 at least)
Suggestion(s) small_more was defaulted to true in the testing version. It has already been set to false as default, which should solve this problem for new players. Those who change the option most likely know what they're doing, so the problem is fixed.
Related page(s)
Comments

8.5.

Problem summary Player doesn't always notice giving wrong input
Problem description When pressing wrong key the player doesn't notice the “unknown command” message.
Screenshot(s) -
Scenario(s) Player who is new to crawl tries to figure out the keys on his own without looking at manual. When trying out different keys nothing seems to happen if the player doesn't keep an eye on the message log.
Breaks heuristic(s) 7 (Easy-to-manage/sensitivity/responsivity)
Severity 1 (no priority)
Occurred in Evaluation
Suggestion(s) a Use error sounds.
b Briefly flash message window red when giving wrong kind of input.
Related page(s)
Comments

8.6.

Problem summary Notifications for some failed actions give unclear response of what should have happened
Problem description Pressing “g” or ”,” when there are no items on the ground gives error message “There are no items here.” This indicates that the action that should have happened has something to do with items, but doesn't specify what. Pressing “c” when there are no corpses on the ground gives error message “There isn't anything here!” which gives no indication of what should have happened.
Screenshot(s) -
Scenario(s) A player is standing next to the door, wanting to close it to keep the jackal from reaching him. He points at the door with the mouse, and reads the “C” command from the description that is on top of the message window. Player tries to press “c” (lower case) multiple times. The game responds “There isn't anything there!” Player gets frustrated and says “Ok, not then.” (This illustrates that the player didn't notice he was accidentally trying the wrong command.)
Breaks heuristic(s) 1 (Consistency)
9 (Instructions)
Severity 1 (no priority)
Occurred in Evaluation, Testing (1/6 at least)
Suggestion(s) Tweak the messages to always include information about what the command was.
Related page(s)
Comments Good point. — jpeg 2010-03-13 01:04

8.7.

Problem summary [Improved] Game is not saveable with mouse
Problem description Saving the game is possible only with the “S” or “Ctrl+S”. There is no possibility for the user to do it with the mouse.
Screenshot(s) -
Scenario(s) The player has been playing the Crawl for two hours and now he needs a coffee break. He plays the game with the mouse. He has an exiting situation going on in the game and he would like to continue the game later on. He is searching the possibility for that, but there is no any icons for doing that. The player is getting frustrated and just clicks the button to close the whole window.
Breaks heuristic(s) 6 (Intuitive and customizable controls)
Severity 1 (no priority)
Occurred in Evaluation
Suggestion(s) Add a clickable button or a menu for game saving. Alternately, always save game when the game is exited.
Related page(s) Mouse Playability
Comments This is included in the command tab. — jpeg 2011-01-18 23:12

8.8.

Problem summary [FIXED] Objective of the game is unclear
Problem description To learn the objective of the game player must either read the manual or play the tutorial.
Screenshot(s) -
Scenario(s) A new player starts to play the game. He does not notice, that it would be useful for him to start with the tutorial. He does not find the manual, so he does not understand what he should do and how to proceed.
Breaks heuristic(s) 9 (Instructions)
Severity 0 (not a problem)
Occurred in Testing (1/6 at least)
Suggestion(s) Add text “Fetch Orb of Zot from the bottom of the dungeon and escape alive!” at the beginning of the game.
Related page(s)
Comments Personally, I'm in favour of adding an introductory screen similar to the tutorial's one. — jpeg 2010-03-13 01:04
0.7 introduced a brief game goal message as suggested here-in. — jpeg 2010-12-26 21:57

Appendix A: The used heuristics in more detail

Heuristics are from the following source: Pinelle, Wong, Stach: “Heuristic Evaluation for Games: Usability Principles for Video Game Design” CHI 2008, April 5–10, 2008, Florence, Italy.

1. Provide consistent responses to the user's actions.

Games should respond to users' actions in a predictable manner. Basic mechanics, such as hit detection, game physics, character movement, and enemy behavior, should all be appropriate for the situation that the user is facing. Games should also provide consistent input mappings so that users' actions always lead to the expected outcome.

2. Allow users to customize video and audio settings, difficulty and game speed.

The video and audio settings, and the difficulty and game speed levels seen in games are not appropriate for all users. The system should allow people to customize a range of settings so that the game accommodates their individual needs.

3. Provide predictable and reasonable behavior for computer controlled units.

In many games, the computer helps the user control the movement of their character, of a small group of teammates, or of a large number of units. Computer controlled units should behave in a predictable fashion, and users should not be forced to issue extra commands to correct faulty artificial intelligence. The game should control units so that pathfinding and other behaviors are reasonable for in-game situations.

4. Provide unobstructed views that are appropriate for the user's current actions.

Most games provide users with a visual representation (i.e. a “view”) of the virtual location that the user is currently occupying. The game should provide views that allow the user to have a clear, unobstructed view of the area, and of all visual information that is tied to the location. Views should also be designed so that they are appropriate for the activity that the user is carrying out in the game. For example, in a 3D game different camera angles may be needed for jumping sequences, for fighting sequences, and for small and large rooms.

5. Allow users to skip non-playable and frequently repeated content.

Many games include lengthy audio and video sequences, or other types of non-interactive content. Games should allow users to skip non-playable content so that it does not interfere with gameplay.

6. Provide intuitive and customizable input mappings.

Most games require rapid responses from the user, so input mapping must be designed so that users can issue commands quickly and accurately. Mappings should be easy to learn and should be intuitive to use, leveraging spatial relationships (the up button is above the down button, etc.) and other natural pairings. They should also adopt input conventions that are common in other similar games (e.g. many first-person shooters and real-time strategy games use similar input schemes). Games should allow users to remap the input settings, should support standard input devices (e.g. mouse, keyboard, gamepad), and should provide shortcuts for expert players.

7. Provide controls that are easy to manage, and that have an appropriate level of sensitivity and responsiveness.

Many games allow users to control avatars such as characters or vehicles. Controls for avatars should be designed so that they are easy for the user to manage, i.e. they are not too sensitive or unresponsive. When controls are based on real world interactions, such as steering a car or using a control stick in an airplane, the game should respond to input in a way that mirrors the real world. Further, games should respond to controls in a timeframe that is suitable for gameplay requirements.

8. Provide users with information on game status.

Users make decisions based on their knowledge of the current status of the game. Examples of common types of information that users need to track include the current status of their character (such as their health, armor status, and location in the game world), objectives, teammates, and enemies. Users should be provided with enough information to allow them to make proper decisions while playing the game.

9. Provide instructions, training, and help.

Many games are complex and have steep learning curves, making it challenging for users to gain mastery of game fundamentals. Users should have access to complete documentation on the game, including how to interpret visual representations and how to interact with game elements. When appropriate, users should be provided with interactive training to coach them through the basics. Further, default or recommended choices should be provided when users have to make decisions in complex games, and additional help should be accessible within the application.

10. Provide visual representations that are easy to interpret and that minimize the need for micromanagement.

Visual representations, such as radar views, maps, icons, and avatars, are frequently used to convey information about the current status of the game. Visual representations should be designed so that they are easy to interpret, so that they minimize clutter and occlusion, and so that users can differentiate important elements from irrelevant elements. Further, representatiodens should be designed to minimize the need for micromanagement, where users are forced to interactively search through the representation to find needed elements.

Logged in as: Anonymous (VIEWER)
dcss/usability_project/report.txt · Last modified: 2011-11-24 17:07 by evktalo
 
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki