Monday, September 17, 2007

Interface Design: World of Warcraft vs. Excel

Blizzard's World of Warcraft (WoW) game is extremely successful. For those who haven't been paying attention, it's a game where you coinhabit a fantasy world with thousands of other players. There are over 9 million people who play the game enough to pay Blizzard a subscription to play. The game is successful, and, in part, it's because of the interface. There are some lessons in Blizzard's interface that can be directly applied to conventional desktop or web applications.

WoW is a game that's designed to be appealing to both the casual user who doesn't play much and a smaller but more dedicated group of people who put a lot of effort into getting really good at the game. Microsoft Excel is another great example of a user interface that has to appeal to both casual and expert users, but it's a lot more fun to talk about video games than spreadsheets.

In terms of appealing to both casual and expert users, WoW is far better than any other application that I've ever used. In part this is because Blizzard is trying to convert as many players as possible from casual to expert. For many people, it's not possible to remain interested in a game for a long time without becoming an expert. Because of the subscription business model of WoW, it is critical for Blizzard to keep players interested for a long time.

In this blog, I'm going to look carefully at how Blizzard does this conversion. Microsoft Excel makes a similar attempt, but it is fundamentally different as well. Excel must be usable for both my mother who wants to make a shopping list and my wife who wants to model a wastewater treatment plant design. Microsoft does not need to convert my mother into someone who understands Excel as well as my wife. Microsoft will make the same amount of money from my mom and my wife, so there's no need to convert between the two types of users. WoW makes a lot more money off of someone like me who plays regularly than someone who plays for a bit, gets confused about how to do something, and then gives up out of boredom or frustration.

If you look carefully at WoW, a huge amount of effort has gone into slowly teaching a user about how the world works and how the avatar that the user is playing works. In fact, making the game easy to discover and learn has received an enormous amount of effort from Blizzard.

I'd like to think that authors of non-gaming applications can learn from this. Becoming an expert in an application is extremely satisfying. It's really fun to use Excel if you're comfortable using exactly the right features you need to accomplish a task. It's also really fun to play WoW after you've become enough of an expert to accomplish a difficult task in the game.

There are three things that an expert WoW user knows how to do. First, they know what their avatar can do in the world. Second, they have to understand the interface that Blizzard has provided for the game. Finally, they have to understand the "physics" of the world that their avatar is interacting with; they have to understand how the world reacts to what their avatar does.

Starting out in the world

When you start out playing the game, you don't have much to worry about. There are about 6 spells, abilities, or items that a starting avatar can use. All of the interface options are turned off, so the interface itself is almost empty. Furthermore, there's nothing that might attack you anywhere near you, so much of the complexities of the world are eliminated. Everything is extremely simple.

It's really easy to see what you're supposed to do next, too. There's a person standing nearby with a giant yellow exclamation point over their head. Later, you'll learn what this means. When you're starting out, it's something that draws your attention. You'll try to interact with that person, and this will give you your first quest. You have rapidly learned a bunch of new things about the interface at this point.

The first quest gives you something to do, and something to learn about. Frequently, it just involves walking a ways over to someone else. This is really easy, and it's impossible to be discouraged by this quest. Furthermore, you'll learn how to move around a bit.

Meanwhile, Blizzard is putting a bunch of little "tips" about your avatar and the world on your screen. If you want to, you can read these, but the design holds up without these. Only a few of these are really required to figure out what's going on.

Like Excel, WoW makes it easy to get by without knowing much. In Excel, you can type a list of grocery items without knowing anything about optimizers. In WoW, you can play with the 6 abilities that you're given at the beginning. It won't help to cast Healing Touch on yourself, but you can see what it does almost immediately. The casual user portion of both interfaces is easily discoverable.

Advancing through the world

As you progress through the game, Blizzard will try to teach you about different parts of the world, different abilities of your avatar, and different parts of the interface.

The interface can be played with right away. There are option screens that allow you to turn various features on or off. When starting out, they are all off. This is a lot like Excel hiding the less popular menu items. (But it's not annoying because the interface is changed directly by you. There are no surprises about moving menu items in WoW.) Furthermore, there are some buttons that are tied to actions that aren't needed for a while. Blizzard doesn't do a lot to make sure you know about some of these features, but you'll learn quickly about some of the more useful ones from other people you meet in game. Blizzard also has some information on them on their web site for those who are actively trying to learn about the interface. Some of the features that are only needed by experts are explained only on third party web sites.

This is a great model to use for some non-game applications. Focus on the necessary stuff. Make features that only experts need available, but don't try to get everyone to use them. Put your energy into making the casual features easy and the expert features possible.

The physics of the world becomes apparent only slowly. Blizzard has designed it so that only experts need to understand most of the physics. If you don't want to think and optimize what you're doing, it's perfectly fine to have the wrong impression of what's going on. You'll progress at a slower rate, and you might not be able to do some of the things in the game that are designed for experts, but you will be able to do a lot.

This is also a great model. If things are happening in the background in your application, make sure that the users don't have to know exactly what's going on. When I'm using Excel, I shouldn't have to know what its rules are for when it re-evaluates each cell. It should just work automatically 99% of the time. Experts might have to know, and they can look it up somewhere, but all of the programmer's energy should be devoted to making sure you don't have to know about it rather than explaining how it works.

The abilities of the avatar are slowly learned as you progress. This makes them almost trivial to teach. Every so often you'll kill enough monsters that you'll be able to learn a small number of new spells. Some might simply be more powerful versions of a spell you already knew. Sometimes, you'll learn a completely new spell. At these points, it's easy to convince a user that they should play with the new abilities they've been given.

I don't think Microsoft could hope to do this well with Excel. If Microsoft tried to force users to make a shopping list before they were allowed to use the SUM() function, you'd have a lot of bloggers like myself ridiculing them. The ability to teach a user in this way may be unique to video games.

Experts only

Blizzard has put a lot of time into creating content that experts can explore. I have to admit that I haven't explored any of the content that they've created that requires 25 people working as a team. However, I think I've got a reasonably good understanding of the behavior of monsters and the abilities of my avatar.

There are things in the game that are extremely complex, possibly even dangerous, and Blizzard doesn't do much to explain them. Users are expected to figure it out, look it up online, or not use it at all.

This is a good thing.

An expert user has to be able to think they are an expert. It's no fun being completely confused about a game after playing for days on end. There have to be things in there that are difficult to use or do correctly in order to convince people that they know what they're doing. They shouldn't be impossible to figure out, but a challenge that is overcome is a lot of fun.

Lots of people say that they are experts at Excel on their resumes. A very, very small number of people understand how to use all of the features of Excel. (Many of them are probably QA employees at Microsoft.) Users like to think that they're experts. To the developer, it really doesn't matter if they are experts or not. Both Blizzard and Microsoft make exactly the same amount of money when their so-called expert runs to the store to buy the next expansion pack or upgrade. They don't care if they really are experts.

Let's look at an example of how you can make someone feel like an expert in WoW. Last week, a small group of friends and I were playing WoW in an area that we hadn't been to before. A friend cast a spell that he almost never uses called Soulshatter. Disaster struck immediately, and we all died.

Soulshatter is a spell that makes you feel like an expert after you understand it enough to use it safely. The source of in-game info for the spell says this:

8% of base Health
5 min cooldown
Reagents: Soul Shard
Reduces threat by 50% for all enemies within 50 yards.

Most of this is nonsense for someone who isn't already at least familiar with the game, but some of it is actually nonsense to a lot of people who think that they're experts!

First of all, the spell costs some small amount of health to cast, and it also takes a "Soul Shard" to cast. A Soul Shard is an item that requires some time and energy to create, so this cost will discourage people from trying it when they aren't really interested in what the spell does. This is good, because the spell shouldn't be cast without careful thought.

What does it do? It doesn't behave at all like what the tooltip says, even if you understand what threat is, what a cooldown is, and what the "instant" might mean. It causes all monsters that are even remotely near you to be interested in attacking you! If they're already attacking someone, then they'll become less interested in attacking you (that's the point of the spell), but if they're pretty far away and haven't noticed your avatar yet, they're going to come running over and attack you (that's why we died).

I don't know about you, but that's not at all what I would have guessed after reading the description. Clearly, this is a spell that's designed only for experts. I read a description of the spell before we played, so I felt like an expert when I explained it to my friend. Is it really sufficiently complicated that I deserved to feel like an expert? Absolutely not. That's not the point. I felt good making my friend feel bad, but now we both understand it. Next time, he'll feel good about using it safely.

Notice that the link I used is not to a Blizzard owned web site. This is yet another great lesson for application developers. Online communities can and will help you out with expert-only features. If you're not writing for a game with 9 million people playing it, then you may have to create your own, but if you do, then people will have a place to go to find out the obscure parts of your program that you shouldn't be spending much time perfecting.

Experts can also be entertained in ways that don't impact casual players at all. For example, It is possible to get an item that makes you completely immune to any damage for 10 seconds. If used at exactly the right time, this will wow and amaze your friends and enemies. If used very carefully, an expert might even be able to do something useful with it, but it's mostly an item that's good for a laugh. Getting the item is mildly painful, but it's available even to fairly inexperienced players. This is a "feature" of the game that can benefit an expert and keep them entertained for an hour or so, but it also helps out casual players. Again, if someone uses this successfully, they will feel like an expert.

Many other examples exist in the game. I really enjoy discovering how Blizzard has made the game both easy and fun to discover. Not all of the work they've done is applicable to desktop and web applications, but it's frequently fun to try to imagine how it might be applicable.

This originally appeared on PC-Doctor's blog.

Monday, September 10, 2007

C++/CLI vs. C#

We're thinking about writing a new application in .NET. I tend to believe that there's not much difference between any of the languages that Microsoft has created for .NET. VB is essentially C# with different keywords and punctuation, for example. You're certainly not going to change the design of your code because you had to write end instead of }, so, for a long time, it seemed irrelevant to discuss anything but C#.

Then Microsoft fixed their C++ implementation with C++/CLI. This is actually a different language from C#. It tries pretty hard to be C++ with access to the .NET runtime and some extra pointer syntax. In particular, you can still have deterministic destructors, free functions, and generic programming. You'll write a different program with C++/CLI than you would with C#, so it's worth thinking about which language you'd choose.

Deterministic Destructors

Actually, you just have destructors. There is a way to create the whole IDispose mess in a C++/CLI class, but it's largely irrelevant since the destructor actually works. This blog explains how to do it, if you're curious.

With real destructors, you can use the resource acquisition is initialization (RAII) idiom to make your code exception safe and easy to read at the same time. C# supports exceptions, but it relies on some quirky syntax to make them safe to use. If the programmer forgets to use the quirky syntax in a few places, then the code can do some really weird things. (No, there aren't any memory leaks. People like to claim that that's a serious problem with C++. Releasing resources is a more general problem that garbage collection does not solve. RAII solves the whole problem rather than a corner case.)

Anyway, I've gotten lazy as a C++ programmer, and I'm not sure I'm willing to go back to a world where exception safety is something you have to work hard to achieve, and releasing resources correctly is not something that the compiler does automatically for you.

To me, this is enough to make me not want to touch a complex application in C#, but let's keep going.

Free functions

C# does not have free functions. Every function is a member of a class. This sort of restriction really irritates programmers like me. Why does the compiler writer get to decide what the right solution to a problem is? Why can't I use the tool that's right for my problem?

In C#'s defense, I think they're using theory that it's harder to kill yourself with a blunt knife. There are a lot of bad programmers out there in the world. Some of them don't know when to use a free function and when to use a static member function. The designers of C# decided that in a fully OO application, there shouldn't be much need for free functions. In the majority of the cases, free functions are, therefore, a bad idea. If you don't let programmers use them at all, then programmers who don't want to worry about getting things right have one less decision to make. C#'s solution is, therefore, ideal for them.

It's annoying for me.

For some reason, I picked on free functions. I'm a fan of them, but there are other things missing from C#: multiple inheritance, a preprocessor, etc. It's all the same story.

Generic Programming

Some people are violently against this stuff, so I won't try to argue that it's got its place. I'd certainly miss it, but I doubt I'd use much of it here at PC-Doctor.

Refactoring Tools

C++ is a frighteningly complex language. Creating a C++ complier is an enormous amount of work. Generally, by the time companies are done with the C++ compiler, they've run out of time and budget.

Refactoring tools never seems to get put in the budget. Of course, changing the name of a type and having to figure out where all the instances that need to be changed are can be both difficult and occasionally impossible in C++.

C#, on the other hand, has some great refactoring tools. This makes some things a heck of a lot easier.


C++ and, by extension, C++/CLI has a lot of features. There are a lot of things in there that are dangerous to use in the wrong circumstances. However, if you spend all your time doing something, you want to have all the tools available to you. You're willing to learn the extra parts that aren't useful every day. I want to have enough tools to hurt myself.

The refactoring tools will be missed, and I hope that someone will get around to making some good ones for C++ eventually.

This originally appeared on PC-Doctor's blog.

Tuesday, September 4, 2007

PC-Doctor's Robotics Lab

In August 2007's IEEE Spectrum they had an interesting article about Microsoft's robotics lab.

I do have some highly speculative and mildly interesting thoughts about PC-Doctor's role in such an industry. Before I get there, though, I want to comment on how, when Bill Gates wants to put together an "elite" team of programmers to do something that's new for Microsoft, they take people who have been Microsoft employees from birth. After all, if they've learned anything outside of Redmond, they might not want to do things the Microsoft way!

Okay, that's all the ranting I'm going to do. Other than that, they seem to be doing some cool stuff over there. Essentially, they've created a robotics lab who's goal is to create some software tools that will standardize the way sensors and actuators are hooked together, and they also want to make a centralized database to hold navigation information. The goal is to make home robotics happen on a large scale.

The article says that the current market for robotics is about $11B. That's not much from Microsoft's point of view. However, it's pretty easy to imagine that, if home robotics does get to the point where everyone has a few robots in their house, then it'll be a heck of a lot bigger than that.

Okay. We're finally past the ranting and background material. Why should a PC diagnostics company be interested in this?

A robot or two in everyone's home is a lot of hardware to manage. Camera lenses can get dusty, bearings can start to fail, DC motors can overheat, batteries can lose power, dogs can chew the video cables, and dust bunnies can be unreachable because of obstacles. There's a lot of diagnostic possibilities.

From our point of view, the best part of Microsoft's entry into the market with a bunch of Windows geeks is that they're almost certain to want to make robotics into something like Windows. Windows is incredibly good at getting a bunch of strange hardware to work together despite the different manufacturers not even knowing about each other. Anything that a bunch of Windows programmers will create is almost certain to have similar abilities. This is critical for PC-Doctor. We wouldn't be able to create a diagnostic for each IR camera out there. We'd have to make a single IR camera diagnostic that could work with a large fraction of IR cameras out there.

Would our diagnostics for robotics be substantially different from PC hardware diagnostics? To some extent, they wouldn't have to be. There's certainly a CPU and memory bank on the robot that has to work. For the purposes of a highly speculative blog post like this, let's ignore that.

Certainly, some diagnostics could be very, very different. A fancy robot contains a variety of sensors and actuators. A Roomba, for example, has a steering servo, a drive motor, a pressure plate on the front, and a sensor on the bottom to detect stairs. This is about the minimum number of sensors you can have on a useful robot. (That's why Roomba is successful. It's $120.) Testing these sensors and actuators in meaningful ways might not look a lot like PC hardware.

One difference here is that, if you want to test a sensor on the floor that detects stairs, you'll have to find some stairs. That means that the diagnostic would have to actually use the robot in order to test it. If you want to test the DVD drive on a computer, you don't really have to worry about the graphics card. To test a stair sensor, we'd have to figure out if it's even possible to test it. (It might be in a single floor house. It might be a Roomba and not have any useful navigation capability at all!)

Another difference is that a lot of robots have sensors that measure how well the actuators are working. For example, a motor that controls an arm joint might also have a angle sensor on that same joint. Feedback would be used to ensure that the arm is moving correctly. It's tempting to assume that this would reduce the need for diagnostics. However, the feedback loop actually creates more opportunity for diagnostics. For example, you could keep track of the amount power required to accelerate the arm under various circumstances. If that varies over time, then something bad might be happening. If you wanted to get really complex, you could test an angle sensor by pointing the camera from another robot at the arm and moving it. That would require multiple robots and be a lot of fun to write. (Hey, Ken! Can I write that one?)

Obviously, there's no market for this yet, and we don't have a robotics broom closet in the back of our R&D lab. (I suppose I wouldn't be talking about this on a blog if there was.) It is a fun topic to think about, though.

This originally appeared on PC-Doctor's blog.