rc3.org Strong opinions weakly held

Posts Tagged ‘design’

The economics of raid lockouts in World of Warcraft

Interesting post from Greg Street, the lead game systems designer for World of Warcraft, explaining why they are changing the game so that you can’t do the same raid more than once a week.

Some of you guys are coming from the angle that players should take responsibility for not playing more than they want to. I agree with that of course, but I also think the game design should not be something that puts that kind of pressure on you. We don’t want to make a game full of traps or temptations that you should have to resist. It’s more fun, I think, if what the game asks of you is reasonable. Killing the same boss twice or four times (as in ToC) or an unlimited number of times (as in the “no loot” model) doesn’t seem reasonable. Neither does having to play Alterac Valley hundreds of times in a weekend to get a prestigious PvP rank. Neither does having to grind for consumables for hours every week before raid night. All of those things are theoretically “features” that players could have shown some common sense and opted out of, but realistically they were just boneheaded design decisions that we needed to fix.

It’s this sort of real systemic thinking about how games work that make Blizzard’s games the best.

Turning novices into experts through game mechanics

Danc has posted the notes to a presentation he gave, Why we turned Microsoft Office into a Game. It’s a great piece on the complexity of applications and how to manage it for users. In it, he gets down to the core problem that faces companies trying to build growing businesses around software — dealing with the fact that different users take advantage of different features, and that applications tend to grow more complex as their user bases grow. It seems to me that the fashionable answer to this problem is to claim to be an auteur of application development, and to only build the features that are appealing to you. But that’s not the way big software companies work, and it’s really not the way they should work. If you’re in the software business, this presentation is a must-read.

Universal design

In yesterday’s post about URL literacy a little debate broke out in the comments about whether it’s worth it to add usability features for novices if they make life more difficult for experts. On that note, last month’s Dwell had an article on universal design, a school which argues that designers should be trying to create designs that work for everyone, regardless of their level of experience or capabilities. This is the position I was arguing in the comments, and is an approach I’m fond of. I generally reject the notion that experts and novices require wildly different interfaces or devices, although obviously there are outliers in any group whose tastes may differ.

Assessing Apple’s revamped checkout process

Form expert Luke Wroblewski compares Apple’s revamped checkout process to their old checkout process. If you do any work designing HTML forms at all, you’ll want to check this case study out. I’m particularly interested in the pros and cons of requiring users to enter their city, state, and zip versus entering just the zip and looking up the city and state. Luke has looked at this issue before.

Ryan Tomayko on Unicorn

Everybody’s linking to Ryan Tomayko’s post, I like Unicorn because it’s Unix, but I’m not going to let it keep me from linking to it as well. It’s a paean to the Unix design philosophy, and really illustrates how few applications these days are built on that philosophy. Go read it. It’s good.

Links for August 28

What do you guys think of the new link format? Good? Bad? Should each link be a separate post?

Explaining the iPhone’s success

Every time a new iPhone is released, there’s a spate of articles that analyze the its success as a product. My friend Stephen O’Grady puts the success of the iPhone down to the apps. He’s got a point — the applications available for the iPhone are great. But the truth is that when the iPhone launched, the only opportunity for developers was to create Web sites that were optimized for the iPhone’s Web browser, and Apple was still selling a ton of phones.

Why? Because of usability. The iPhone offered a better experience than any other phone for making phone calls. Checking voice mail, conducting three way calls, and managing contacts are all light years better than they are anywhere else. The iPhone offered better Web browsing than any other mobile phone. Blackberry email is better than iPhone email, but the iPhone’s email experience is better than every other phone on the market.

That was the real secret to the iPhone’s early success, in my opinion. Apple spent a lot of time not only adding capabilities not available in other phones, but also perfecting the things that people were already using their phones to do. It made the wait for real applications tolerable.

Links from May 26th

I have a number of Sonya Sotomayor links today.

Links from May 22nd

Today’s batch of links:

Becoming a designer

I don’t actually want to be a designer or a usability expert, but I’d like to know more about design and usability. I’m always working on various kinds of Web pages — content pages, listing pages, reports, forms, and so forth. My specialty is server-side programming, but I spend enough time on the output side that I’d like to be better at it.

So where to start? Is Tufte’s The Visual Display of Quantitative Information the best place to start? What are the other good options? I’m not trying to put anyone out of a job, but I’d like the things I build myself to look less terrible.

← Before