Mobile game navigation and user experience
Some developers may have questions about the importance of navigation as part of the game experience. After all, users don’t spend that much time in the game menu — they spend most of their time playing the game. And that is exactly what we are trying to accomplish with these guidelines.
If the navigational structure of the game is usable, users can concentrate on playing the game. In actual practice, our user tests revealed that users spend a considerable amount of game time trying to navigate. In these tests, navigation emerged as one of the greatest sources of frustration and a major cause of bad user experiences. To ensure a good user experience, developers should commit to making navigation so intuitive that users don’t even notice it.
When playing a game, users should not feel that they are simply using the device; rather, they should experience the game world. The game navigation structure should support this experience, which is why the use of high-level UI components should be avoided. Game menus should look and feel like the game, not like the rest of the device. If high-level UI components are used, they should support the game user experience. In practice, this means that the user experience should be seamless; high-level UI dialogs should be used only in the game menu, not in the mobile game itself.
The figure below represents three different implementations of the same game. In the first example, the game menu and game are implemented with custom graphics in full-screen mode. Here, the game experience is not disturbed by device graphics. This kind of seamless experience should be the goal when designing a game's navigation structure.
In the second example, the game's main menu is implemented with standard device UI components, but the game itself offers an undisturbed experience. This implementation can be used if necessary.
In the final example, some events in the game itself are represented to the user with standard UI dialogs, which easily disturbs the game experience. This implementation should be avoided.
Even if game menus are implemented with custom graphics, this does not mean that the interaction style should be custom. On the contrary, the style of interaction should be consistent, even if custom graphics are used. The user should encounter familiar controls in navigation, and custom graphics should have some familiar characteristics. This way, users can transfer their existing knowledge about UI style to the game. In the optimum situation, users would know intuitively how to use game menus, although they look different from the rest of the device. To achieve this goal, developers should consider preserving the following characteristics in the game UI:
If the navigational structure of the game is usable, users can concentrate on playing the game. In actual practice, our user tests revealed that users spend a considerable amount of game time trying to navigate. In these tests, navigation emerged as one of the greatest sources of frustration and a major cause of bad user experiences. To ensure a good user experience, developers should commit to making navigation so intuitive that users don’t even notice it.
When playing a game, users should not feel that they are simply using the device; rather, they should experience the game world. The game navigation structure should support this experience, which is why the use of high-level UI components should be avoided. Game menus should look and feel like the game, not like the rest of the device. If high-level UI components are used, they should support the game user experience. In practice, this means that the user experience should be seamless; high-level UI dialogs should be used only in the game menu, not in the mobile game itself.
The figure below represents three different implementations of the same game. In the first example, the game menu and game are implemented with custom graphics in full-screen mode. Here, the game experience is not disturbed by device graphics. This kind of seamless experience should be the goal when designing a game's navigation structure.
In the second example, the game's main menu is implemented with standard device UI components, but the game itself offers an undisturbed experience. This implementation can be used if necessary.
In the final example, some events in the game itself are represented to the user with standard UI dialogs, which easily disturbs the game experience. This implementation should be avoided.
Even if game menus are implemented with custom graphics, this does not mean that the interaction style should be custom. On the contrary, the style of interaction should be consistent, even if custom graphics are used. The user should encounter familiar controls in navigation, and custom graphics should have some familiar characteristics. This way, users can transfer their existing knowledge about UI style to the game. In the optimum situation, users would know intuitively how to use game menus, although they look different from the rest of the device. To achieve this goal, developers should consider preserving the following characteristics in the game UI:
- Use the navigation key as a primary control. Users are likely to be very familiar with a five-way navigation key. Users should be allowed to move focus with the navigation key and select items with it. Also many users are used to conducting default actions with the navigation key.
- Display softkey labels on the screen. Users are likely to be very familiar with the concept of softkeys, and this familiarity should not be wasted. Softkey labels should always be used, even in full-screen mode. A minimalist solution for a softkey label is a simple symbol that tells the user which softkey opens the game menu.
- Use the left softkey as an Options menu and also as a secondary selection key. The pop-up Options menu is familiar to users. However, it might be a good idea to avoid using pop-up menus with Series 60 graphics to maintain a coherent user experience, especially in J2ME games. Similar functionality can be used in more complex games if the pop-up menu is implemented with custom graphics.
- Use the right softkey for Exit / Cancel / Back. Note that in the UI styles for the Series 60 Platform, settings are saved when the settings screen is exited with the right softkey. As a general rule, users should be able to exit an application by repeatedly pressing the right softkey from any game menu, except from the game itself. The only exceptions are situations where the user may risk losing information.
- Provide automatic saving and loading of application states. Normally in Series 60 applications, saving and loading are handled automatically when opening and closing an application. Also, multitasking replaces the functionality of save and load in its own way: If an application is interrupted or the user exits the application with the End key or the Application key, the application is not terminated but is switched to the background instead. This allows the user to return to the application later, after dealing with the interruption. This functionality works even if users are not aware of the multitasking capability of their device.
posted by Mikael Vandegraff at 1:42 AM
0 comments
