15 golden rules for parsing application UI design

Editor's note: This article is originally contained in game state, author Jake Simpson

Friends have shown me the latest iphone and ipad version of "Need for speed." The game's rendering effect is impressive, is a good game ready to be sent. However, the front end of the game is a typical case of UI design bias. But there is a lot of attribute data in the interface, which provides too much content when the player has no time to make a decision. These content can dramatically change their gaming experience, but are presented when the player is not always feeling the change.

Need for Speed (from itunes.apple.com)

This prompted me to start thinking about the golden rule of UI design. Here are the UI design methods that I think should be used to create the best experience. Frankly, these rules are just a common practice and do not fully apply to all of your UI design.

1, the start of the game required button click No more than 3 times. IDs can be achieved in online games (such as "Thor Hammer 3"), so you can do it. Players do not want the game to constantly show them that they need to understand or even affect the game's data. Playing games is their first thought. You can't add up to 20 minutes of content before the 15-minute first game experience, which can make the player crazy.

2. Hide complexity. This is what the Advanced tab does. When introducing players to the gameplay experience, all content that is currently irrelevant (game bang: for example, any default and unlikely to change) needs to be hidden in other dialog boxes. The idea is not to remove the complexity of the game (which is the right thing to do), but not to present the complex content immediately. Of course, you can allow players to change the parameters, but you don't have to ask or even force them to see which parameters can be changed. Those who want to do this will naturally find the option to help them achieve their goals, but keep in mind that less than 50% of the players are trying to change the parameters. For more than 50% players, you just have to show the options and features that don't require them to change, because too much choice will only make them feel confused.

3. Present all the information to the player in the same place. Maintain consistency of information rendering positions. You need to guide the player to see a place and get all the game information just by looking at it. Of course, there is a technique in information presentation that filters information content so that the player does not have to pay attention to too much information from the game or other players, which can cause the player to lose critical information. But this is the filtering level of information, left for further discussion. It is important to note that if you only highlight errors or missing entries, you are not complying with this rule. When you fill out a form on a page, they often use this method, which is certainly permissible. However, if you want to do this, do not use only text color to imply errors, which can cause color blindness users inconvenience. What you need to do is invert the highlighted text, so don't just display the inappropriate text in red, but also display the background as red. In this way, even color-blind users can grasp the input error.

4, filtering information, rendering meaning. It's good to be able to present information, but the more information you share, the better? In a way, this is true. However, if the information is flooded to the user, they will feel disgusted. "Are you sure you want to do this?" "Such repetitive information can become spam, ignored by users or clicked directly, and too much spam can cause users to ignore important information." It is a good practice to set the presentation cooling time of a repeating dialog box, such as when a dialog box is rendered 3 times and the dialog box is no longer rendered within the preset time, you can set the preset time to the 5 minute time that the last dialog box renders. In this way, users do not have to constantly click on the same dialog box, and will not be bothered by this information.

It is also a good idea to allow users to filter certain types of information. For example, allow users to ignore warnings or messages from the scripting system. This requires proper categorization of information so that the system can identify which category it belongs to. Although it is troublesome, it is a practice that can be adopted.

Also, keep a list of the information you have received (all information that has not been filtered) and make sure that the user knows the location. This way, if they need this information, they can view it at any time.

The presentation of information is also worth mentioning: it is important to inform users of the implications of their changes, especially tools. If the user clicks the "All content uses dynamic Illumination" button in the Unreal Editor, then you need to tell them the effect that these practices will have on the frame rate. It is often not enough to use the traditional method of interpreting each keystroke by displaying text on the screen, because the differences in content or other settings often lead to changes in the impact of a control. If you are only a single object in the Poly scenario, setting "All content using dynamic lighting" will not have a negative impact, and only when you render 400 objects in the 10000 poly world will the negative effects be obvious. So fundamentally, my point of view is to make an internal analysis of the other changes that might be caused by controlling changes, comparing them to other effects that might have a dramatic effect on the user. Again, it is necessary to note that the number of dialog boxes and information is rendered, as there are always special cases where the application believes that the user is asking for an unwanted action, and is therefore constantly issuing a warning.

5, maintain all UI rendering content consistency is the key. Some practices are obvious, such as the use of radio buttons or checkboxes in applications, but they are not fused, and in all dialog boxes, keep the text type, font, and size consistent. But there are some finer things. For example, if you need to provide a path in the tool and keep using the browser button, do not expect the user to enter the path directly. Xcode is an excellent counter case. It is also a good practice to use the scroll bar instead of requiring the user to enter a value, but you can still support the user using the numeric input method.

One of the most important parts of data entry is to avoid user input of bad or conflicting data from the outset. There are a lot of code in the application that can handle bad data, but it's a better way to eliminate bad data input from the beginning. That's why you use the preset pull-down menu because you can make sure that the program doesn't get misspelled words and bad data.

6, if you can achieve without user input content, this method, this is the 5th expansion. Preset drop-down menu labels or provide default text where user input is required, so that if the user does not want to do so, they do not have to enter any text themselves. All things should have a default option.

7, you can set up a multi-channel view of the same dialog box, Windows XP at this point to do a good job, allowing users to open the same control dialog box in a variety of ways. It is acceptable to do so. It should be noted that when using this method, the dialog box itself should be guaranteed to be consistent. Regardless of the channel you open the dialog box, they are identical, including appearance, performance, and functionality.

8, control set in the same and only place, this is the 6th extension. The same kind of control should only exist in a single dialog box, and it is not possible to set the appearance of a similar but functionally different control, which will allow users to encounter difficulties in understanding. Similarly, Xcode is doing poorly in this area.

9, dialog box depth can not exceed 3 layers. If you're making RPG games, you might be able to set up 4 floors. The bottom line of the dialog box depth setting is that users cannot be confused about where they are, what they are doing, and why. You'll also need to show them where they are in the dialog tree, but it's nice to add the back button, but a small dialog tree indicator will look better, and you can refer to the Windows System Resource Manager practice.

10, dialog box switch. dialog box switching time is best done in 150 milliseconds, up to 200 milliseconds. How to switch and how beautifully the switch is is irrelevant, and the user wants a short response time, especially if they navigate through the UI dialog tree. A gorgeous but lengthy switch is like joking with the user. The user may initially feel that the design is cool, but after a while will be bored, all you have to do is to make the whole process faster.

11. Any thing that can visually affect other content should be changed immediately. If you don't know the effects of lighting or costume changes on roles and other content, then you should render them instantly so that users can see the effect they have on changing settings. Sometimes this may not be possible, because changes in individual settings affect other content (game state Note: For example, in the modification of the script value, only modify the other one before it takes effect). But you'd better do it if you can achieve this instant rendering.

12, so that all content can be configured and saved. Allows the user to modify the size and location of each window and save it. Setting the default options is easy, but making sure your application can save changes made by all users. Remember that dialog box layouts can save users a lot of time.

13, the difference renders the information and can change the data. Information that cannot be changed by the user should be presented in a specific way so that the user can understand that these are static information. The information that can be changed should be rendered in a slightly different font, color, or size, or in a way that a user can easily perceive as something that is subject to change. This is closely related to the 2nd, and if users are aware that some data can be changed, they will look for changes and start exploring your dialog UI structure.

14. For PC developers, you need to see if the content is actually displayed on the screen when you open the dialog box. In many cases, the user changes their display settings and suddenly discovers that their saved dialog box disappears from the screen. You need to see if this happens. I have encountered this problem more than once.

15. The final point may also be the most controversial rule: Are you designed to meet data change flows or to meet data aggregation? A brief introduction to the background, the design of the flow of data changes means that you will gather many dissimilar data into a single screen, dialog boxes and UI sections, sorted by the process that the user needs to expand, so that the user can select the steps they need to take, such as entering a name, selecting a type of text, choosing a game type, Select the server and enter the game. These elements are different "types" of data. Most games separate them into multiple screens, adding a lot of extra keystrokes and information for the user to modify the experience, but in fact most users don't use them. The other is the "similar data" grouping method, where each screen is designed around a particular function, and the user can make a choice from it. The Data Flow screen places all the specific features that the user must select or change into a single screen so that they can see the request at the same time, make a choice and move on. One kind of emphasis on rendering options, the other is to simplify the process so that users can quickly reach the place of thought.

My personal opinion on this issue is that both methods are reasonable. I prefer to present the data flow method as the default, because most people will use this method, especially for the first time using the application. Once the user is familiar with the application, you can let them use another method, because they need to find what they want faster. This is closely linked to the 2nd, and complexity can exist, but is not a necessary factor.

These are the 15 golden rules of UI design that can help you communicate a more user-friendly user experience.

Source: http://leiphone.com/15gold-priciple.html