Wednesday, April 25, 2012

A Deeper Look at GUI Design

One of the most important parts of a game, often the most overlooked part, is its Graphical User Interface, or GUI.  It’s easy to tell when a game has an awful interface.  Yet when a game’s interface is good, it’s easy to overlook because it fits in seamlessly with the rest of the overall experience.  There are a lot of guidelines on how to make a good GUI, but the best one I’ve come across is CRAP from Usability Friction.  Obviously we don’t really want our interfaces to look like crap.  This is just a mnemonic device to be able to remember these guidelines: Contrast, Repetition, Alignment and Proximity.  Now this article wasn’t directly talking about game user interfaces, but a lot of this can still be translated to work as such.

First we have contrast.  Specifically, if two things have nothing in common, don’t make them look like they do.  A really good example from the article was that of an ‘ok’ and ‘cancel’ button.  The ‘ok’ button stands out versus the ‘cancel’ button because it is almost always the choice the user will make, so it should stand out more.  For our game, we could incorporate this when taking pictures of artifacts.  Specifically, we could try to draw the user’s eye to the “Keep” button and make the “Discard” button less desirable.  Or since all of the information is available to us, if the picture doesn’t contain anything useful, we could instead make the “Discard” button the more desirable of the two.  In our game we also have “Create Exhibit” and “Clear” buttons, referring to the photos played to the tableau.  Here is an example of where we would not want to make one button more desirable than the other because this would reveal our mechanics and information we wanted to keep hidden.  For instance, there’s no reason to make the “Create” button desirable when the proper pictures are played because we don’t want the user to know if its correct or not until after the “Create” button has been hit.

Next they listed repetition as a basic principle.  Basically, this is reusing patterns throughout your entire program.  A good example from the article is how all of Google’s search tools use the same text input field and a styled ‘search’ button that reflects what you’re searching.  In our game, our dialog boxes are the same, so it’s not jarring every time a new one pops up.  Another good example from our game is how the map button is consistent--it would obviously be a bad idea if we moved the map button from place to place depending on what part of the game the user is currently in.  It seems like a simple thing, but it can be easy to overlook when the core mechanics are still being worked on.

The third item listed is alignment.  For this, the article is specifically mentions vertical alignment of things in a list.  While aligning elements vertically isn’t necessarily the kind of alignment wanted in game’s GUI, alignment is still an important factor.  It’s important for visual elements to be aligned in an aesthetically pleasing way that makes sense.  Placing buttons near the corner of the screen for ease of use and being out of the way of the focus of the game is important.  Having those buttons spaced appropriately to each other is also important.  So for designing a UI, it’s good to have a nice flow from one visual aspect to the next.  This property is reflected in our game in a few places.  There are two places where we have buttons that are functionally similar aligned horizontally next to each other.  A third place where we have things aligned is our photo collection.  The player’s collection of photos is aligned across the bottom of the screen in a clear and organized manner.

The last principle mentioned is proximity.  This is just having like-items near each other.  Think of any role playing game on a console or PC--things like health, magic power, fatigue, or hunger are almost always displayed near each other.  This is because these elements are related so they are proven so by being shown near each other.  Likewise, buttons to bring up menus such as the player’s statistics, inventory, or spellbooks are usually near each other for the same reason.  A relationship is created when things are placed near each other, so it’s important for the developer to strengthen existing relationships by doing this instead of implying a relation between elements that aren’t actually related.  In the introduction of our game, we have two arrows that represent a forward and back button.  It might seem obvious to place these next to each other--it simply wouldn’t make sense to place one in the bottom left of the screen and the other in the opposite corner.  However, they must be placed near each other to create visual cohesiveness.  Likewise, in the challenge state of our game, the placement of the cards for the challenge are next to each as opposed to randomly placed about the screen.

We went through many iterations of our game.  We weren’t following these guidelines throughout our design process.  But from testing and failing to eventually succeeding, we found a GUI that worked.  While we didn’t know about the CRAP guidelines while we were designing the interface, it’s apparent that the design does follow the four principles described.  In the future, we could reach a more optimal design sooner by starting with these principles rather than using the trial and error method we employed.

No comments:

Post a Comment