Why Microsoft turned Office into a Game.(slideshare.net)
slideshare.net
Why Microsoft turned Office into a Game.
http://www.slideshare.net/danctheduck/wordcamp-2010-public
8 comments
I seem to remember having user experiences where the first couple of times I did something wrong, I got a short warning sound or flashing menu bar, and after a couple of more of them, a dialog box popped up with a more elaborate description. I didn't think about it at the time, but I do believe that encourages clicking around more than getting the dialog box every time.
Nice point. I guess learning means experimenting, in which failure is information. I have not failed 1000 times. I have succeeded in proving that those 1000 ways do not work. The buzz comes from the transition from not knowing to knowing. A sensation of progress.
Maybe it's similar to users having more satisfaction from bugs fixed in a later version than there never being bugs in the first place.
The very clear error messages in Java made it more game-like, and were unusual at the time (compared with eg. C memory management problems). The Java development team apparently played nintendo games to study what made them fun to use. Though out of fashion these days, it wasn't always the case. The popular scripting languages of today often have a REPL, which is more game-like. Do they have other game-like qualities?
Maybe it's similar to users having more satisfaction from bugs fixed in a later version than there never being bugs in the first place.
The very clear error messages in Java made it more game-like, and were unusual at the time (compared with eg. C memory management problems). The Java development team apparently played nintendo games to study what made them fun to use. Though out of fashion these days, it wasn't always the case. The popular scripting languages of today often have a REPL, which is more game-like. Do they have other game-like qualities?
Yeah, but if you do it wrong, then it just feels as though the program talks down to you.
I agree that designing the architecture to be easy to explore and learn is a great idea, to me it seems that the best application to a help interact was if one added the option to play with things before the instructions for how to do them. Not if one removed the instructions entirely.
You don't want to be doing something, and then be distracted by the help screen and come back to the initial thing an hour later forgetting what it was you wanted to do.
Sometimes less engaging functionality has a greater capacity to engage.
I agree that designing the architecture to be easy to explore and learn is a great idea, to me it seems that the best application to a help interact was if one added the option to play with things before the instructions for how to do them. Not if one removed the instructions entirely.
You don't want to be doing something, and then be distracted by the help screen and come back to the initial thing an hour later forgetting what it was you wanted to do.
Sometimes less engaging functionality has a greater capacity to engage.
I want Vim Hero!
This is a great presentation - thanks for posting.
This is a great presentation - thanks for posting.
snake is vi hero
Apparently, it was designed to teach the hjkl keys. It's likely a few other vim games already exist (vim has every feature you can imagine, and then some). After I've played some video games, Vim actually feels like a video game to me.
Except for its learning cliff. However, when I put together regular expressions, I use new features by trial and error at first, and this is quite like a game. Try it, press u, edit and try again, press u. That's a feedback loop, as in the game; just turn-based instead of real-time. lisp/python/ruby/bash etc REPLs are similar.
Apparently, it was designed to teach the hjkl keys. It's likely a few other vim games already exist (vim has every feature you can imagine, and then some). After I've played some video games, Vim actually feels like a video game to me.
Except for its learning cliff. However, when I put together regular expressions, I use new features by trial and error at first, and this is quite like a game. Try it, press u, edit and try again, press u. That's a feedback loop, as in the game; just turn-based instead of real-time. lisp/python/ruby/bash etc REPLs are similar.
Stack Overflow is another application patterned on a gaming badge/reward system. On the Stack Overflow podcasts, Jeff talked about how he was deliberately copying the XBox idea of badges for rewarding specific achievements and unlocking additional functionality.
It's a very interesting perspective. They are dead-on about video games. You startup the game with basically no instructions and quickly have to figure out how to play.
I'm curious how well this type of thing would do in a corporate environment, especially those switching from Office 2003 or earlier to 2010. I can see how this would be much more helpful than the standard training classes I've seen.
I'm curious how well this type of thing would do in a corporate environment, especially those switching from Office 2003 or earlier to 2010. I can see how this would be much more helpful than the standard training classes I've seen.
Video games are the most tradition-bound interface in all of computerdom. There is basically NO exploration going on. Every button on the controller has to do what the user expects from every other game or the they get frustrated and don't buy the game. Even when ported to a PC the games stink of "console".
[deleted]
Unnecessary rock thrown at the iPhone (almost literally). Still a very good presentation.
Since Office on the Mac sucks and has subtle compatibility issues whenever I share files with PC users, I am considering giving the web app a try as my new "have to use MS Office" escape hatch.
Since Office on the Mac sucks and has subtle compatibility issues whenever I share files with PC users, I am considering giving the web app a try as my new "have to use MS Office" escape hatch.
Ya, because maybe the iPhone is the best example of exactly what he's talking about. The iPhone has always been something of an enigma to me. In all of the short-term usability testing I've seen (and done), it's performed really poorly. Yet the overall engagement is through the roof.
I would argue it's primarily because the iPhone feels like a game when you play it. It rewards you for doing the right thing. It provides a lot of feedback. It's smooth and quick... It's exactly what the author is talking about.
I would argue it's primarily because the iPhone feels like a game when you play it. It rewards you for doing the right thing. It provides a lot of feedback. It's smooth and quick... It's exactly what the author is talking about.
He also talks about the success of a plugin system, like iApps, in shrinking the skill pyramid.
It did seem very MS vs Apple, but it's true that Apple's walled garden prevents those later explosions on one of the 10% peaks.
The iPhone has been around for several years, but it seems there have been no such growth in it. Each app is self-contained, and is explicitly forbidden from becoming a new center.
The iPhone has been around for several years, but it seems there have been no such growth in it. Each app is self-contained, and is explicitly forbidden from becoming a new center.
I think his comment about the iPhone is highly appropriate in this case; while it's generally got good user experience design, there are definitely cases where the UI is built in a way that will frustrate users. Two examples come to mind from back when I still used my iPhone:
1. Undo. Who is ever going to discover this on their own? Every action you can perform on your iPhone (With the exceptions of volume adjustment, going to the home screen, and locking the screen) is done by interacting with the screen. The undo gesture is not only hard to discover by accident, but it's very context-sensitive, which means if you do it by accident, it may not do anything at all. This is basically the complete opposite of discoverability. His 'skill atoms' example should demonstrate why this is problematic - if you want the user to develop a skill on their own, it should be easy for them to discover the verb to trigger the action (press a button, tap an interesting thing) and easy to understand the results.
2. The home button. While it's convenient and useful, in many cases I would find that an application would discard my changes if I hit home to dismiss it, instead of saving them. The most common case where I ran into this was the alarm application: I'd create a new alarm, go into the subview to set up the alarm, and then hit home to dismiss it instead of hitting the little back button they shoved in the corner... and it would throw out my new alarm. While the home button is a good affordance, it is destructive - by using it incorrectly, the end-user may or may not lose work, which makes them wary of experimenting. (It's my understanding that Android has a similar issue, but I've yet to use an Android phone).
I could also harp on how the lack of multitasking increases the penalty for end-user mistakes, but people have already beaten that dead horse.
Just to be fair, here's a similar example from the Palm Pre:
In most Pre applications, to delete an object, you simply pop up the dialog to edit it, and hit a trashcan icon. Simple. However... in a few specific cases, somebody on their UX team decided it would be brilliant to require the use of a gesture to delete. There are zero on-screen cues to suggest that it's possible to perform this gesture, or that the gesture will do anything - so the uninitiated user will simply think 'how do I delete this?' and get frustrated (or, hopefully, look it up on Google). In these specific cases, you have to drag to the left or the right on top of the object you wish to delete, which magically reveals a hidden pair of buttons under the object: Delete and Cancel. Only then can you delete. Even worse, it's possible to botch the gesture - if you don't drag far enough, the phone ignores your gesture. Compared to the majority of the Pre's UI (which is light on punishment and encourages exploration), this is a huge design failure.
1. Undo. Who is ever going to discover this on their own? Every action you can perform on your iPhone (With the exceptions of volume adjustment, going to the home screen, and locking the screen) is done by interacting with the screen. The undo gesture is not only hard to discover by accident, but it's very context-sensitive, which means if you do it by accident, it may not do anything at all. This is basically the complete opposite of discoverability. His 'skill atoms' example should demonstrate why this is problematic - if you want the user to develop a skill on their own, it should be easy for them to discover the verb to trigger the action (press a button, tap an interesting thing) and easy to understand the results.
2. The home button. While it's convenient and useful, in many cases I would find that an application would discard my changes if I hit home to dismiss it, instead of saving them. The most common case where I ran into this was the alarm application: I'd create a new alarm, go into the subview to set up the alarm, and then hit home to dismiss it instead of hitting the little back button they shoved in the corner... and it would throw out my new alarm. While the home button is a good affordance, it is destructive - by using it incorrectly, the end-user may or may not lose work, which makes them wary of experimenting. (It's my understanding that Android has a similar issue, but I've yet to use an Android phone).
I could also harp on how the lack of multitasking increases the penalty for end-user mistakes, but people have already beaten that dead horse.
Just to be fair, here's a similar example from the Palm Pre:
In most Pre applications, to delete an object, you simply pop up the dialog to edit it, and hit a trashcan icon. Simple. However... in a few specific cases, somebody on their UX team decided it would be brilliant to require the use of a gesture to delete. There are zero on-screen cues to suggest that it's possible to perform this gesture, or that the gesture will do anything - so the uninitiated user will simply think 'how do I delete this?' and get frustrated (or, hopefully, look it up on Google). In these specific cases, you have to drag to the left or the right on top of the object you wish to delete, which magically reveals a hidden pair of buttons under the object: Delete and Cancel. Only then can you delete. Even worse, it's possible to botch the gesture - if you don't drag far enough, the phone ignores your gesture. Compared to the majority of the Pre's UI (which is light on punishment and encourages exploration), this is a huge design failure.
Can you elaborate a little on the subtle compatibility issues you've found?
Sure, here's one. ppt files with elements that don't work the same on mac and PC. Fonts changing size, elements moving around. These problems make the Mac and PC Office users avoid collaborating. Also, because the releases are are out of sync you also have to use the least common denominator file format and mac owners are the lusers. Not much fun in a startup where everyone is bringing their own tools to work.
Call me paranoid, but it feels like Microsoft doesn't really like Mac users. Kind of odd since Office is a important franchise unto itself, but now maybe they have caught on. Another example of one business silo hurting another.
Call me paranoid, but it feels like Microsoft doesn't really like Mac users. Kind of odd since Office is a important franchise unto itself, but now maybe they have caught on. Another example of one business silo hurting another.
Thanks. I try to use Power Point as little as possible, but I've noticed some font issues between Win and Mac versions of Word too. Not surprising I guess, but none the less annoying.
For those interested in reading more:
The presenter is Daniel Cook (Danc) who worked for Epic Megagames long ago doing game art and design.
Some of his essays have made it to HN before, those and some of his art can be found at his site: http://www.lostgarden.com/
The presenter is Daniel Cook (Danc) who worked for Epic Megagames long ago doing game art and design.
Some of his essays have made it to HN before, those and some of his art can be found at his site: http://www.lostgarden.com/
This is so full of corporate bullcrap that it makes me shudder...
Game mechanics in crappy apps -> ???? -> PROFIT!
I detest whimsical crap like this - especially when its shoved into your face like that insufferable paperclip guy.
The ribbon may be a happy happy joy joy thing for fluffy folks, but I just see a crappy toolbar with half a dozen fonts and no clear way to search for the randomly-distributed features. I detest it.
The ribbon may be a happy happy joy joy thing for fluffy folks, but I just see a crappy toolbar with half a dozen fonts and no clear way to search for the randomly-distributed features. I detest it.
Give me Excel 2003. That was the most usable version for me. (Actually I was the most productive by far in Lotus 1-2-3. The reason I believe was the lack of a mouse.)
this is one of the most inspiring talks about ui design I have read in quite a while, and from microsoft of all people.
This would seem to extend beyond turning your interface into a 'game'... maybe it means that we should be much more focused on providing meaningful feedback. When a user does something wrong, translate that into an action, comment, or something that clearly provides an opportunity for learning. Makes sense...
Interestingly, I've experimented with something like that in one of our products. Instead of trying to provide the shortest path to complete an action, I designed the interface to take the user through the same steps they'll use when actually managing the stuff they create (with lots of helpful prompting). This isn't necessarily new, but it was new for me. The early returns have been pretty good with this approach.
One thing I might take a stab at changing: Instead of providing immediate prompts for the user, let them click around and only display the prompts after enough (failure) time has elapsed....