Trials, Triumphs & Trivialities #141:

User Interfaces

by Shannon Appelcline
2004-02-06

Last week I spent a solid day and a half working on a credit card interface for RPGnet. RPGnet, for those not in the know, is the top independent tabletop RPG site on the Internet. It's owned by Skotos, and I think it's a very nice sister site. On the one hand we have our online RPGs, and on the other hand tabletop discussions. It's a nice little continuum.

Originally we'd hoped that RPGnet would have sufficient value in ad space to Skotos that we could run it without problem. However, as just about the whole world knows, ads just aren't worth what they used to be. We've gotten Skotos members from RPGnet, no doubt about that, but not enough to pay RPGnet's bills.

Hence: the credit card interface. It's part of a membership system where we're given people the opportunity to actually support the site. They sign up for a year, pay us a fee, and so become one of the contributing members who help RPGnet run. I just announced the system two days ago, at the time of this editing, and over 60 people have already stepped up to support their community. I'm hoping that'll grow to a couple of hundred by the end of the month, and ratchet up in smaller numbers month by month afterward.

The programming for the membership program wasn't terrible. I had a lot of PHP parts and modules already in place that I was able to put together in some useful new ways for members. The work I had to do connecting up the ad system, the forum system, and the member system was a tiny bit tedious, but not terrible. Things went overall pretty well: until I got to the credit card interface, which was where my productivity crashed to a screeching halt.

And that's what I want to talk about today: how user interfaces can be one of the most annoying and time consuming elements of any computer project.

Useful Input & Fact Checking

Interfaces tend to come in two types: tightly constrained and somewhat freeform. In the former you're typically collecting decisions: yes/no, up/down, on/off. You specifically state what input a player is allowed to offer you, and you don't allow anything else. No problem. You have to worry about how intuitive your interface is, which I'll talk about later, but it's all actually not that big of a deal.

My credit card interface was, however, the much more dreaded type: the freeform interface. Giving users the opportunity to enter whatever information they might want to can be trying (and even terrifying). To make this work at all, there are three strict rules you need to abide by:

First of all, you must carefully describe what information you're asking a user to provide you with. For example, in my credit card form, to ask for a credit card number I could have initiated my request with any of the following: "#", "CC", "CC#", "Card Number", or "Credit Card Number". It looks like I choose "Card Number" as a compromise between wordiness and clarity. Too much terseness could have made the form much harder to use.

Second, you have to carefully check the input to make sure it's right. So, for a credit card, I had to make sure the input was composed of numbers, hyphens, or spaces. I had to make sure that it had approximately the right number of digits. I had to make sure that it was one of the credit card types that we accepted.

And, I had to do some sort of rational checking like that for every input I requested.

Third, you have to report any errors clearly, and make it easy for users to correct them. In this particularly case I flagged missing information in red and made sure that after an error all the forms got refilled with the already entered information (except the credit card information which I required to be reentered for privacy reasons).

I've built a number of User Interfaces for Galactic Emperor: Hegemony and they were equally painful. The interface generally required 25-50% of the time that it took to implement an entire system. Even for a fairly constrained system like my space station movement panel, I had to:

• Make sure they'd selected a station.
• Make sure they'd selected a direction.
• Make sure they'd selected a range.
• Make sure what they'd selected was actually a station, not a regular planet.
• Make sure that they actually owned the station.
• Make sure the movement would end before the end of the game.
• Make sure the movement wouldn't take them off the map.
• See if there were any planets in the way.

Getting good input into your User Interface requires a weird combination of error checking, because you need to: validate information; maintain the integrity of the rest of your data in relation to this new entry; and make sure that the user isn't cheating and entering data that should have been "impossible".

Pretty Output & Intuitive Interface

The general output portion of a User Interface is a little more obvious: you want it to look nice. In web forms this means using tables, bold headings, and other obvious separators to keep everything on track. Via any other method, you generally just need to make sure that your interface doesn't run together in an ugly mash. You need to paragraph, just like in writing, to keep separate ideas separate and intuitively group together similar concepts.

Everything that's required to create an intuitive interface is well beyond the scope of this article. People have written books on the topic. Still, I'm going to try and hit a few points:

Likes Attract. As I touched upon above, you want to keep similar ideas together in your user interface. I was recently looking over a quick reference chart for Age of Mythology: The Boardgame and sort of shook my head over how they'd listed out various buildings you could buy. They were just an unorganized listing rather than, for example, grouping the two buildings which provided your lands protection into an area; and the four buildings that provided additional resources into an area. Organization helps everything fall together.

The Rule of Seven. I touched upon this previously when talking about decision trees in strategy games. It applies at least equally well to User Interfaces. The mind can innately grasp somewhere between 5-7 items. When you have an Interface that offers more than that, particularly if they're ungrouped, users can no longer intuitively grasp what their options are. A year ago I did a major revision to RPGnet's front page, and my first step was to replace a listing of 15 or 20 "main pages" with a new graphic showing just 5. I'm probably going to up it to 6 next week, and maybe 7 in a couple of months, but I'll still be staying within the boundaries that many people should be able to intuit.

Location, Location, Location. Finally, you really need to think about the location of all your elements in a UI. For example, in my credit card interface I made sure that the "Submit" button was at least near the fold on a standard 800x600 screen. I figured this would make it more likely that people would fill out the form, because they'd see it was just that one screen. In order to accomplish this, I had to push the Terms of Service down below that fold, but it seemed a good compromise to make things optimally easy to use.

I've heard some people talk about a "mom" or "grandma" test: the question being, could your mother or grandmother easily use the interface you've designed? Or, is it something that's only obvious to insiders? (There's a corrolary to this: if you've developed an interface that 99% of the world can use fine, even if your mom can't, it's probably a fine design. Another general rule of business, that happens to be true, is that you'll spend 80% of the time pleasing the last 20% of the people. You need to know when it's rational to cut that off.)

Text & Graphics

We've talked about interface now, and I've worked through my annoyance over the latest UI I built. The question is, however, how does this relate to computer games?

For web-based games, like Galactic Emperor: Hegemony, the correlation is pretty direct. You're going to hit those exact same trials and tribulations that I ran into when writing my credit card form. You're going to need to verify lots of input and offer really good output.

For text-based games, you need to address the same issues, but in a slightly different format. You need to be really good at offering players alternatives when they've input a command that's illegal for whatever reason. The biggest barrier of entry for a text game is probably figuring out how to work the Command Line Interface. Your UI needs to heavily support players in this.

Contrariwise, for graphic-based games your biggest issue is output, not input. Since you're usually asking players to hit arbitrary keys or buttons, you need to make sure that it's really obvious what those buttons do. I think one of the biggest failures I've seen here was the "upgrade" from Age of Empires to Age of Mythology (we're talking about the computer game now). I've never entirely liked the old Age of Empires interface because the buttons were arrange in a somewhat arbitrary, haphazard order. But Age of Mythology made this even worse by dropping the size of all the buttons by 50% or so. Suddenly the icons were often indistinguishable and I had to start slowly mousing over all the buttons to figure out what they did. Continued usage would eventually have resolved the problem ... but that's generally a pretty bad answer for users.

Conclusion

The bottom line through all of this is that if you're designing a game, you should be spending a notable amount of time on making a user interface that really works. It's just as important as your game's mechanics, and can make or break your game.

What portion of UI design you have to concentrate on will vary depending on the medium you're building for: input will be more an issue for a prose game, output for a graphical game, and both for a web game. Make sure you know where your emphasis will need to be, and pay real attention to it.

[ <— #140: Guns & Flaws | #142: The Disconnect Dilemma —> ]