|
|
 |
 |  | | | | |  | |||
 | ||||||
          |  |  | ||||
|
Cross-Platform User Interface Development The Design of Everyday User Interface
Technical requirements vary from platform to platform, however the underlying principles behind them largely don't. Donald Norman's The Design of Everyday Things is an excellent source to learn about these principles. The book is a must read for anyone that develops user interfaces. It points out things in our everyday lives that are poorly designed and don't need to be, such as doors that you push that actually have to be pulled. Citing examples from The Design of Everyday Things, we hope to teach you a little design aikido that will satisfy technical requirements of all the major platforms. Get a Clue!
Here is a UI problem that just about every gamer has faced once or twice: a menu with only two items and no clear explanation of which item is currently selected. Let's break down the rationalizations a player might have when faced with a screen like this:
So the player is left with two options: scan the manual for more clues or press any button on the controller and hope for the best. The player presses the D-pad up, which makes "Yes" appear blue, and presses a button. The player ends up at the screen they were at previously. There was no feedback communicating that they moved back in the UI stack (for example a unique sound effect), but the player knows it's the previous screen because they remember what it looked like. With these clues they are able to deduce that white text is the selected item and blue is not. Now that the player understands the selection system, they get through the UI with greater ease and start playing the game. In reality, this only took a few seconds to figure out, but it's still irritating. It wouldn't have taken all that much effort on the part of the UI designer to correct this kind of confusion. Provide Instructions
For starters, it would help to give the player some instruction on how to make a choice. Insert a callout that consists of a brief text string that explains its mapped function, and an icon of the button to which the function is mapped. The icon should represent the button in color and shape. For some consoles, this is a requirement. Provide Feedback
A cursor is an effect or collection of effects that are applied to the selected item that provides visual feedback to the player's actions. In the original example of this UI screen, the cursor's only effect was a color swap of the text. This may work in menus of three or more items, but is ineffective in a menu with only two. A more refined cursor object, such as a glow effect and a shape that encompasses the text, is necessary. Sound effects are also excellent for providing additional feedback for the player's actions. In addition don't underestimate the power that good sound effects can have on the player's enjoyment. Seven Principles for Transforming Difficult Tasks into Simple Ones Any cross platform UI is going to stumble on some challenging screens. These seven principles can be used as guidelines that will contribute to a better design.
Now let's look at some examples of some tricky UI screens that utilize these seven principles. The Soft Keyboard Since no major console comes with a keyboard and some don't even support them, console games rely on a software solution for text input. Console developers have taken many different approaches toward soft keyboard design. Microsoft Same Studios usability labs have done extensive testing on the subject. Their results showed that players overwhelmingly preferred a horizontal, alphabetic layout over other virtual keyboard designs.
The figure above shows a soft keyboard design for an Xbox title that has a number of advantages:
Controller Settings It's important to keep the UI stack short, but it's just as important not to bombard the player with information. Trying to fit too much information on one screen can give a player mental indigestion. A common example of this problem is the controller
mapping screen. Numerous games have functions mapped to every available
button and try to fit it all on one screen.
The figures above show a controller setting screen for a first person shooter Xbox game that is broken down into two separate screens.
Design for Errors
All major console manufacturers require that any destructive action, such as overwriting a game save, have a confirmation dialog to allow the player to back out of a potential mistake. However, there are other kinds of irreversible actions that can still hinder a player's experience even if they are not as costly as losing a save game.
The previous figure shows an example of a training dialog that is meant to teach the player about a particular aspect of a game. The down arrow and page counter under the paragraph illustrate that there is a second page of information that the player can view by pressing down on the D-pad or thumbstick. Should the player press the "A" button, they will close the dialog box and miss the information on the second page. This design gives the player the ability to make this mistake. Below is an alternate approach to the same dialog that resolves this problem.
By binding the "A" button to move to the next page, in addition to the D-pad "down" button, it forces the player to see all the information, instead of closing the dialog and missing it.
Once the player has seen all the screens, the "A" button will now close the dialog and return to the game. Pushing up and pressing the "B" button allows the player to return to the previous page if necessary. Standardize Most games map the same buttons for moving forward
and back in the UI stack and some consoles require it. Therefore it's
conceivable that in the player's mind, these buttons are for "positive"
and "negative" actions.
UI designers can take advantage of these associations, as seen in the following:
Rather than making the player press the D-pad to move a cursor to select their choice and then press a button, they just press a single button. Tools of the Trade UI Flowchart. The following is a Microsoft Excel spreadsheet that we used to map out the flow for the UI in Crash Nitro Kart. CNK shipped on Game Cube, PS2 and Xbox so the flowchart was a tremendous asset in tracking any cross platform issues. This flowchart was created before any UI is put into the game so that we could adjust for scope and plan for any cross platform issues. Notice that some of the cells are actually hyperlinks. These are linked to MS Word documents that go into excessive detail about an individual UI screen. The flowchart is meant to provide answers to engineers, artists and designers. The documents outline any code support that may be needed, mockups for artists to refer to for visual design, and usability functionality for designers.
Text Dictionary
UI Menu System When development for Crash Nitro Kart began we decided to develop a scripting language specifically for UI development. Assets would be generated in other applications and layout and functionality would be done in script. This method would allow us to make a single user interface that would work on multiple platforms. We affectionately named our menu system G.U.I.D.O. which stood for Graphical User Interface Design Outline (yes it is a stretch). Rather than get into the specifics of using GUIDO, I recommend some goals based on what we learned: Goals for a UI Menu System
Final Thoughts Keep It Simple Stupid While it's true that a good looking user interface is important, it should hardly be the focus of your technology. A UI is not an effective tech demo. A minimalist approach toward UI design allows the player to focus on the function, without getting distracted by the form. Make It FUN!!! Think of the opening credits for a movie. They tell the audience who did what in the movie, but filmmakers learned that it's also an opportunity to entertain the audience and set the mood for the rest of the film. If the player has fun with the user interface, it will only enhance their overall enjoyment when playing the game. Source Material Crash Nitro Kart Jedi Knight: Jedi Academy (PC, Xbox) The Design of Everyday Things Xbox Development Kit Help documentation Xbox Guide Special Thanks Jonathan Herman, Jonathan Mintz, Brian Osman and Mike Scavezze. Opinions expressed here do not necessarily reflect those of Vicarious Visions ______________________________________________________
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
GDC
2004 Feature 
