Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
The Player, the Web and the Interface
#1
'Tis easy to talk about "the player" when talking about creating user interfaces for games. I end up doing it myself, even though I know better. There ain't no such animal.

Grim pointed out, in another thread, that sometimes programmers design the game assuming that the players have the same degree and depth of understanding of every aspect of the game as they (the designers) do. And Grim is right. That is a big fail.

There is a tendency among some interface designers to go to the opposite extreme. To design the game to be "user friendly," by constantly pestering the player with requirement that he agrees that he understands the consequences of the order he has given. As one mentor of mine said: can you imagine having a human assistant who constantly said, "Are you sure you want to do this sir?" every time you told him-her to do something? That can get old, quite quickly, even for a noob, and is about as friendly as a straight-jacket.

What designers (and critics of designers) need to understand is that there are a whole bunch of different types of users and the interface has to work for all of them - which sometimes means having more than one interface, not designing for the lowest common denominator. When looking at an interface, it is important to have at least four or five personae and look at the interface from the point of view of each one of them. If Sally Mae Noob can't figure out what to do, it doesn't matter of Harry Curmudgeon likes it or Billy Whizkid finds it perfectly suited to the fact that he has memorized all 372 item codes. The standard questions that must be asked about the personae are:
  • What are the gamer's goals?
  • What are the gamer's skills and experience?
  • What are the gamer's needs?

Speaking of needs, research has shown that when someone approaches any new software, the most important thing to them is not looking stupid. Even if they are alone, that is the fear that a majority of new users experience.

The goal is to provide for the needs of all your potential users, adapting Web technology to their expectations and never requiring readers to conform to an interface that places unnecessary obstacles in their paths.

The user interface for a Web site should follow the general navigation and layout conventions of major Web sites because users will already be used to those conventions. Users spend most of their time on other sites not on the game's, so we should avoid highly unusual interfaces if the idea is to attract and keep a large audience instead of conducting a seminar for 12 interested people on alternative methods of navigating the Web.

A large part of good webdesign is making sure the player knows where he-she is on the website - and therefore knows how to get to everywhere else in the website. Important entry points (the home page, for instance) need to be reachable from everywhere. There should be no need to search for links to those points. Web design should offer constant visual and functional confirmation of the user's whereabouts and options, via graphic design, navigation buttons, or uniformly placed hypertext links.

One way of providing an interface for a skilled and frequent user is to provide keyboard shortcuts. Tapping <alt> <T> rather than having to switch back to the mouse, figuring out where on the page the cursor is and sliding it over to the proper button, menu, or link and then clicking it is a faster and more efficient method of getting to the "Transfer" page. Power users will appreciate it, while newcomers will never even think about it.

The best information designs are never noticed. Two excellent models of interface design are Adobe's and Amazon's websites. Graphic headers act as navigation aids and are consistently applied across every page in the site. Once you know where the standard links are on the page header graphics, the interface becomes almost invisible and navigation is easy.

Help documentation should be always available and specific, at least to the page, if not to the action about to be dealt with. Following a link to a help page should never mean losing any work in progress. There are 5 kinds of help that users want:
1. Goal-oriented: "What kinds of things can I do?"
2. Descriptive: "What is this? What does this do?"
3. Procedural: "How do I do this?"
4. Interpretive: "Why did this happen?"
5. Navigational: "Where am I?"

The fourth type of help is the one least provided. (Try figuring out a Microsoft error message) and one that is very important.

It's important for new users that they feel safe. They don't trust themselves or their skills to do the right thing. Many novice users think poorly not only of their technical skills, but of their intellectual capabilities in general (witness the popularity of the "...for Dummies" series of tutorial books.) In many cases these fears are groundless, but they need to be addressed. Novice users need to be assured that they will be protected from their own lack of skill. A program with no safety net will make this type of user feel uncomfortable or frustrated to the point that they may cease using the program. But this is not a reason for constant "Are you sure?" dialogs, but rather for giving the player a chance to back up and redo an order rather than committing to it. Even Amazon's one click interface allows a user to cancel part of all of an ordering session - as long as the books haven't left the warehouse.

At the same time, an expert user must be able to use the program as a virtuoso. She must not be hampered by guard rails or helmet laws. However, expert users are also smart enough to turn off the safety checks -- if the application allows it. This is why "safety level" is one of the more important application configuration options.

Anyone really interested in user interface design for gaming could do far worse than to read this document a couple of times. I don't always agree with either his analyses or his conclusions, but it definitely makes me think hard and come up with reasons why I think doing something another way is better.
Reply
#2
Its a little late here, so I'll expand my comments tomorrow.

This is a great little intro to the basics of UI design here JonO. The distinction between types of users is important, and often ignored. I find that using techniques from scenario based design helps the programmer get into the mindset of the different types of users, which helps prevent the tunnel vision and assumption holding Grim was describing.

Another important distinction is between information design and interaction design. They are easy to conflate because they are often implemented at the same time. Information design focuses on identifying tasks and actions, and how to represent them in a way to facilitate understanding, whereas interaction design aims to ensure users are able to do the right thing at the right time.

I've never heard of that breakdown in different types of help questions. Very enlightening JonO.

That PDF you linked is pretty informative, though personally I've always found a full GOMS analysis to be too cumbersome to do alone or in small teams. The concepts it attempts to model are important though, so its worth keeping them in mind when working on your design.
Reply
#3
(04-01-2011, 03:54 AM)Ramblurr Wrote: Its a little late here, so I'll expand my comments tomorrow.

Good. I'll be very interested and I certainly hope you don't let any real-world considerations like a job from interfering Wink

(04-01-2011, 03:54 AM)Ramblurr Wrote: I find that using techniques from scenario based design helps the programmer get into the mindset of the different types of users, which helps prevent the tunnel vision and assumption holding Grim was describing.

I first bumped into this approach reading Alan Cooper's books. His website is a great introduction to that concept. I think the man is brilliant. (And I got a couple of jobs by doing nothing but paraphrasing him for the entire interview.)

[quote='Ramblurr' pid='647' dateline='1301630081']
Another important distinction is between information design and interaction design. They are easy to conflate because they are often implemented at the same time. Information design focuses on identifying tasks and actions, and how to represent them in a way to facilitate understanding, whereas interaction design aims to ensure users are able to do the right thing at the right time.

Please talk more about this. The difference is something I have bumped into without having to deal with in a way that would help me learn it.

(04-01-2011, 03:54 AM)Ramblurr Wrote: That PDF you linked is pretty informative, though personally I've always found a full GOMS analysis to be too cumbersome to do alone or in small teams. The concepts it attempts to model are important though, so its worth keeping them in mind when working on your design.

I agree. It may be because he was working in a university setting that he didn't consider the fact that there are still lone wolves and tiny startups like ours that need to use a subset, but it is better to pick and choose from the quiver of arrows he offers than to have nothing for your bow. (Kewl metaphor, huh?)


Reply
#4
(03-31-2011, 05:39 PM)JonO Wrote: There is a tendency among some interface designers to go to the opposite extreme. To design the game to be "user friendly," by constantly pestering the player with requirement that he agrees that he understands the consequences of the order he has given. As one mentor of mine said: can you imagine having a human assistant who constantly said, "Are you sure you want to do this sir?" every time you told him-her to do something? That can get old, quite quickly, even for a noob, and is about as friendly as a straight-jacket.

You've got that right. When I play a game, I don't want the game, itself, to annoy the living Hell out of me. That's what my enemies in games are for.
Reply
#5
(04-01-2011, 01:54 PM)GrimFinger Wrote: You've got that right. When I play a game, I don't want the game, itself, to annoy the living Hell out of me. That's what my enemies in games are for.

There's a story about the creation of Amazon.com. Back when it was just an idea, Jeff Bezos hired a programmer and explained that central to the creation of his website was the idea of 1-click ordering. The programmer assured Bezos that he understood and designed a prototype. Bezos was very impressed - until, after he had selected a book and clicked on "Purchase," a confirmation box popped up and asked if he was sure he wanted to buy it. The concept of user-friendly meaning treating the user like he's five years old was so ingrained that the programmer implemented 1-click, with a requirement to click twice. Rolleyes
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)