As one can see in those links, there is a large amount of sub-standards (work place displays to TV panel displays, etc) for building good UI’s. I’m not going to talk about what is already published because anyone can read that. Instead, I am going to talk about my experiences in building UI’s and some of the points that I find important. All of this is my own opinion and what I have discovered during my times. I hope it proves to be useful!<\/p>\n
Since the UI is essentially the way the End User uses the program, I feel a good UI must have several important key concepts done well: Usability, Accessibility and Consistency.<\/p>\n
Usability<\/h3>\n
Usability is how easy it is to use the User Interface to do a task. Can you do your task easily and efficiently? How difficult is it to perform an action? Note: It is easy to confuse Usability with Accessibility.<\/p>\n
Before I go into more detail. I want to define two terms:<\/p>\n
Average Task<\/em>: Is a task that a user performs on a regular basis. For example, saving\/load files (or games), using common windows (research\/planet\/ship design\/etc)s, and the like.<\/p>\n Complex Task<\/em>: Is a task that the user doesn’t perform on a regular basis and usually gives\/does a bit more than the average task. This type of tasks usually requires more clicking\/window movement\/etc than an average task. An example consists of the Planet Window and using filters to display a list planets based on parameters. Or, the Statistic Window where overviews of the Empires in the game can be seen through various filters.<\/p>\n I will now go over a few ways to determine how good Usability is in a UI.<\/p>\n One of the easiest ways to gauge difficulty in the usability realm is the number of clicks it takes to do a given task. This idea can be expanded to include moving the mouse on the screen, or clicking through various drop down lists\/menus\/etc. And finally, it can be further expanded to traveling through multiple windows in order to accomplish a task.<\/p>\n Another way to gauge difficulty is the usage and placement of components. How are the components arranged on the window? What types are used (Lists, Drop Down boxes, Tabs, Scroll Panels, etc) and are they the right ones? Is the screen cluttered? What is your initial reaction (how do your eyes feel?) to opening a window? And so on.<\/p>\n A pitfall of Usability is a lack of Consistency(which I will explain further below).<\/p>\n One other big issue I have with UI’s is the lack of feedback. There can be tasks that can take some time to process. Having absolutely no feedback creates a sense of mystery that the user should never have. At every moment during the User’s time with a UI they should always know what the UI is doing. There are times when it may be impossible to gauge how long a particular task will take but feedback should still be given in some way. Some examples are: use a progress bar that continually moves back and forth, a mouse cursor spinning or some other sense of animation. A User should never be thinking: \u201cIs this locked up?\u201d or \u201cWhat is this thing doing!?\u201d or \u201cWill it end soon?\u201d. This can be taken a step further and a label can be used to display the current step. This would be great feedback.<\/p>\n Another pitfall of Usability is not ensuring the UI scales with large amounts of data. Yes, the window with a list of 5 items behaves fine. How does it behave with 1,000, 10,000 or even 100,000? Time to check!<\/p>\n One last note is to ensure the UI has proper flexibility. There should be more than one way to do an average task. As a developer, that is a task that is left up to you. Shortcuts are the most common way to implement flexibility.<\/p>\n Some ways to ensure good Usability is to:<\/p>\n Accessibility is how easy it is for a user to sit down and learn the User Interface by themselves, without the developer\/manual nearby to help them.<\/p>\n If a user can sit down and start to use the program and be productive in a short amount of time with little problems \u2013 then the program is accessible.<\/p>\n Another way to describe Accessibility is the \u201cLearning Curve\u201d. What is the learning curve of the program? How much time does the user have to spend before they are able to be productive?<\/p>\n Describing the difficulties and pitfalls in accessibility is hard because there is no silver bullet that will cover every single aspect for every single program.<\/p>\n However, I do have a few tips as a fellow developer. I have noticed over the years, that much of the accessibility problems are due to the omniscient view a developer(s) has of their system. They designed the system and implemented it (not always but for example’s sake). As such, they know the inner workings and how to do every task. Thusly, they usually have very little issues using their own program. Of course they don’t have issues! They built it!<\/p>\n As one can see how this could be a huge pitfall. To overcome this problem what I like to do is to:<\/p>\n In both cases, the omniscient feel can be dulled and almost put to rest. This should give some decent feedback and ensure that the accessibility of the UI can be made better.<\/p>\n As mentioned above, Consistency is a very important part for UIs. Consistency goes a long ways and brings structure and order to a UI. It is very easy to have a UI spiral out of control and be absolutely a pain to use (MoO3 and from Adam’s review the original DW).<\/p>\n If a good level of consistency is instituted within the program, it will have a very overall positive impact. Good consistency raises the usability and accessibility.<\/p>\n Let me provide some examples of good consistency:<\/p>\n Consistency is very very\u00a0important. But it can be implemented badly.<\/p>\n Let’s use MoO3 for example. Even though they used a Tabbing mechanism in the Planet window for consistency, it went completely over board. They simply had too much going on (item 1) and the number of clicks to perform the average task (item 2, editing the build queue), was unacceptable. Most times, the tabs where hidden or put in odd places (item 5). I could probably write (I’m not the only one!!) several articles, one for each window, for MoO3 on how the UI was bad and flawed.<\/p>\n In all, the developer has to keep in mind that the End User is someone ELSE and envision how they will be using the UI. They need to sit down and think on how the UI can be made clear and concise in ALL of its windows. The End User needs to feel the same in every window in terms of how to use it. It makes no sense whatsoever to institute the idea of using Tabs in all of the windows but having one straggler window using buttons to open up sub windows instead. It will just confuse the user and lower the Usability and Accessibility.<\/p>\n I will now talk about some code tips. This particular section may not apply to all readers, so I shall keep it short.<\/p>\n Functional Decomposition<\/em> \u2013 Functional Decomposition is vitally important for UIs. Functional Decomposition is taking a large system and breaking it down into smaller pieces. The reason why Functional Decomposition is so important is because the windows and parts in a UI’s generally have a lot in common with each other. It does no one any service by having repetitious code in many different locations. This makes the maintainability of the program extremely difficult, and it leads to buggy programs. Bugs lead to money, time wasted and the most important: unhappy customers. Of course, modular code can be reused so the UI can be extended for new function that much faster.<\/p>\n A good way to implement modular code is to have a Utility class\/file that provides generation of generic components.<\/p>\n For example, in my SitRep Window, I have a Utility class that allows for the generation of various parts of the SitRep Entries. By doing it this way, I can simply write a new SitRep Class and call these methods to build my SitRep Entry. The benefits are: Here is a picture of my (Alpha) SitRep screen.<\/p>\n It is easily seen that each entry looks generally the same (+Consistency) and they all function very similar (+Usability, +Accessibility). This is because each SitRep Entry calls the identical underlying Utility methods. Each entry has their own line that can be fully expanded (+Usability) by clicking on the + or the line itself(+Usability). Under each entry very detailed information is provided and gives links to various important windows.<\/p>\n Above, the expanded Entry is about a Fleet arriving at a system. Detailed information is provided, and in this case, 4 planets are present with no owners. Buttons can be used to view the Star System immediately.<\/p>\n Layouts\/Scaling<\/em> \u2013 Having some underlying code mechanisms to automatically perform layouts and scaling (the Java Swing layouts for example) of UI Components is beneficial because it removes the fact that people run on different resolutions. You have to make sure your UI will look good on all supported resolutions.<\/p>\n I, personally, prefer using absolute positioning with built in scaling than layouts because I get more control that way. To me, control is power.<\/p>\n In this case, I’ll talk about my 4X Game I’m developing. We all know that 4X Games need to display a large amount of information. Screen real estate is low and at a premium. So I have instituted a policy that windows will contain tabs to manage various portions of windows. For example, there is a Fleet Window that has tabs for Deployed Fleets and Fleet Creation. There is a Planet Window that has tabs on the right for Information, Construction and Resources \u2013 all the while the planet view is still viewed on the left side. In both cases, the tabs are top tabs. This is a good usage of consistency between windows.<\/p>\n This sums up my thoughts on making User Interfaces. As mentioned before, there is a lot of literature out there so most of this article is my own opinion. I am looking forward to reading what others have done and what parts of a UI they think are important.<\/p>\n In order to generate some good discussion on this topic, I pose the following questions to the readers:<\/p>\n dayrinni has been a Space Sector contributor since October 2011. This is his first foray into writing articles for any review site. He is an avid gamer in the genres of 4X, Strategy, MMO’s and RPGs. Finally, he has been the implementor of several MUDs and is currently working on a 4X space game that offers large scope and complexity. See all dayrinni’s posts here<\/a>.<\/span><\/em><\/p>\n","protected":false},"excerpt":{"rendered":" It goes without saying that User Interfaces(UI) are extremely important to any program. This article will talk about some basic concepts and thoughts about building good User Interfaces.<\/p>\n","protected":false},"author":41,"featured_media":0,"comment_status":"registered_only","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0,"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","enabled":false},"version":2}},"categories":[177,1],"tags":[711,712,562,1502,709,710,708,713,714,589],"class_list":["post-6034","post","type-post","status-publish","format-standard","hentry","category-game-design","category-space-strategy-games","tag-accessibility","tag-consistency","tag-dayrinni","tag-game-design","tag-ui","tag-usability","tag-user-interface","tag-user-interface-in-games","tag-user-interfaces","tag-what-makes-a-good-game"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/www.spacesector.com\/blog\/wp-json\/wp\/v2\/posts\/6034","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.spacesector.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.spacesector.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.spacesector.com\/blog\/wp-json\/wp\/v2\/users\/41"}],"replies":[{"embeddable":true,"href":"https:\/\/www.spacesector.com\/blog\/wp-json\/wp\/v2\/comments?post=6034"}],"version-history":[{"count":0,"href":"https:\/\/www.spacesector.com\/blog\/wp-json\/wp\/v2\/posts\/6034\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.spacesector.com\/blog\/wp-json\/wp\/v2\/media?parent=6034"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.spacesector.com\/blog\/wp-json\/wp\/v2\/categories?post=6034"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.spacesector.com\/blog\/wp-json\/wp\/v2\/tags?post=6034"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\n
Accessibility<\/h3>\n
\n
Consistency<\/h3>\n
\n
Usability, Accessibility, and Consistency Summary<\/h3>\n
Code Talk<\/h3>\n
\nI can easily develop new SitRep Entries by simply passing in the information (generally Strings). I don’t have to re-write the code to generate the entries and I ensure the code is not ridden with bugs since I am already using something that is known to work.<\/p>\n![\"\"](\"https:\/\/www.spacesector.com\/blog\/wp-content\/uploads\/sit_rep_small.png\" "\\"sit_rep_small\\"")
<\/a><\/p>\nTime for Examples<\/h3>\n
Conclusion<\/h3>\n
\n