Posts Tagged ‘montreal’

Kathy Sierra on creating passionate users

Thursday, October 25th, 2007

One of the keynote speakers at this years OOPSLA was the normal-from-afar-but-impressive-from-closeup-especially-when-speaking Kathy Sierra. She talked to us about how to create a host of passionate users. I’ll try and give an impression of the key points she touched upon.

First of all, it is important to recognize, people still want to meet in person, despite all the technological advances made during the last years that really means we can talk to one another without leaving our home, or the comfort of our couch. So to create a bunch of passionate users, you should build on this desire and get them together, where they can talk, discuss, learn and teach. A good example she gave was that of a barcamp. Basically, the roadmap to instilling passion in your users is discovering the characteristics these people have in common.

Essentially, where there is passion, there is a user kicking ass. So, you want people to get good at things, because if you suck at something, there is no way you will be passionate about it. Counterexample 1: I still suck at Haskell, but I’m quite passionate about it. Counterexample 2: the same goes for me and Drupal. But that may just be me. Most likely it is. On the other hand, there are people encouraging me to be passionate about this. With this observation, she encouraged the audience to give users a hi-res experience, such that they could understand that if they passed the suckiness threshold, they could really rock. This means showing things to people as you see them, and transferring your passion. For example, a mountain climber will certainly look differently at a rock wall than Joe average, e.g., me.

The main issue is that often people are encouraged to be passionate about a tool, rather than at what the tool can help them accomplish. Nice example is the camera. What you want to do is to make kick-ass pictures. So get people to be better at using the tool, helps them reach this goal. But don’t mention this, just show them the cool stuff they can do, without emphasising the tool itself.

Kathy claimed that the first roadblock to get things rolling is the brain of the users. People operate at a subconsious level, not at a logical level, despite the fact that – so she said – many men like to believe otherwise. Furthermore, brain have built-in crap filters, meaning it’s important to get the things you want users to retain pass those filters. The mind however operates at a higher level, but people are rarely actually guided by their mind. For example, when they really want something, they will seek arguments why they should be allowed to get what they want, rather than listening to their (correct) mind that tries to tell them not to for some good reason (e.g., no money). Her reasoning was that the brain cares about either life-sustaining of life-threatening things, about joy, sadness, anger, love, scary things, new things, intruiging things, etc. However, the brain cares not one whit about code. The brain also cares about faces, so it is more desirable to people to talk in person to somebody, instead of having them interact with a machine. The bottom line is that use have to use every trick at your disposal to capture the attention of the user. For example, conversational language captures people attention better than formal language. I guess that’s one to keep in mind for my PhD dissertation.

Well, everybody think he’s above average, even when it is not true. So the path to succes is constructed by dangling the carrot in front of the users: allow them to have the idea how cool they will be when they grow above the sucking threshold. So, users need a clear path to get to the good stuff, see a compelling picture down the end of the road, and a relatively easy first step onto the path. So, users must not be dumbed down. Additionally, the path must be open ended. Every time there must be a step users can take to keep increasing their competence.

Because all computer applications are somehow agnostic at some level to what users think, it is important that users can knock on the door when they get confused. Kathy called this adding a WTF? button to an application. One of the problem is that users guides and FAQs are written for happy people, not for somebody about to smack the hardware (after all, hardware is the part you kick). So FAQs are written for users on the other side of the canyon of pain.

I really like her metaphores.

Getting users on the path to world domination is but the first step, you also have to keep them going. The best way to do this is to get them in the flow state, which is the state where people just need to do this one extra thing, one more compile, and it will work, etc. They are not aware of time passing, and face it, you probably also accomplished most when you’re there. There seems to be a precarious balance between knowledge, skill and challenge. To avoid slamming users back to reality, you should make the good things easy, and the wrong things hard to do.

I think that she illustrated her point quite good by using the game example. In a good game, there is a payoff when a player attains certain experience, e.g., a faster car, better weaponry, etc., but there are also tougher challanges to be faced to get even further.

She made me grin when she asked how we feel about users. RTFM? That’s usually how I think most of the time, after having things explained time and again. But obviously it is the wrong approach, and deep down, we all know it. This is why some online communities are much more succesful than others. Those that don’t bark nor bite but care about newbies can get them up to speed easiest and create a following that will (hopefully) repond the same way later on when they passed the suck threshold. I think a good example of this is #haskell on irc.freenode.net, where people have always been helpful for as long as I’ve known. This is one of the key issues Kathy touched upon: get the community to help out. People should be encouraged to answer politely, and answer instead of just asking questions. Even when something is answered wrongl, the community can pitch in and correct things. And because newbies recall their pain best, it is important they actively contribute.

Moreover, when a community can be converted into a tribe, passion may be ignited sooner. A tribe has special little things only the members are in on, and they notice each other. Tribe members id themselves with a special thing, and they’re proud to be part of it. Provide people with the means to show they are part of the tribe, e.g., bumper stickers, t-shirts etc. I guess I should be taking my Drupal t-shirt out to the dry-cleaner so I dare wear it again. As Kathy nicely puts it: insider information is trading currency, so give your users something to talk about. Apple users should know what she means, given the huge number of rumour sites.

Finally, appreciate the intelligence of your users. A crowd can reach concensus, but that’s probably not what you’re interested in. Individuals can contribute better if they get the chance. So make them think they rule individually.

I really liked her talk, it was well paced, and had very well thought-out illustrations on the slides. She gave quite a lot of things to talk and think about. Which I what I intend to do.

Montreal Hyatt WiFi

Monday, October 22nd, 2007

To put it briefly: it sucks. We have little or no connection in our room, even when using a hotel provided WiFi connection device. We can get access in the hotel lobby, but uploading anything larger than a few KB does not work. Opening a secure shell to a machine outside the hotel, e.g., at work, is not possible. Thus, SVN access is simply fubar, as is pushing patches to a darcs repository. Uploading to flickr … no way. Not even through the HTTP interface.

And to think the hotel is hosting a few hundred geeks attending OOPSLA.

A tutorial on user-interface design

Monday, October 22nd, 2007

I attended the ‘From use to user interface’ tutorial at OOPSLA, which was presented by Jeff Patton. The approach outlined was the following. First, start by writing a scenario, with a specific user (and his associated persona) in mind. Go down to the nitty gritty details (fish and clam-level), as well as the broad scope (sea-level and above). In reality, you might have to create a few dozen scenario’s to cover the entire use-space for your particular problem.

From the scenario, identify user interface elements that help the user execute the tasks required to reach his goal. For this, Jeff advocated using post-it notes, as they can be reordered on a board, and teared up when wrong.

Given the post-it notes create paper UI building blocks, such as labels, input fields, buttons, tables, etc. these should be sticked onto paper sheets, which represent the screens a user sees as he proceeds through his stack of tasks.

Final phase is the testing. Get a person to play the computer, a person to explain the scenario, and a few people choosing to pick the UI-elements. Finally, somebody should observe and jot down everything the testers have trouble with.

The next step is to repeat the above phases as much as needed until you are confident the user interface you designed meets its requirements.

In all, I think this can be a good approach, especially when a complicated user interface needs to be designed. However, I’m still partial to the paper cutting and sticking the components onto paper. It seems to me that this might be a little time-consuming. This is especially true when you need a lot of screens, and the problem you’re dealing with is fairly complex. Basically, I think an electronical counterpart to the paper based cut-and-stick idea might work faster. Additionally, it seems as if the proposed approach is very hungry on people resources, so it might cost quite a lot to have a user interface designed in this way. And the testing phase seems to be quite awkward. But I’m no expert whatsoever. And a well-designed interface can of course rapidly earn its development price back because it can appeal to people, causing them to buy/use your application.

Belgian Food

Sunday, October 21st, 2007

Last night, Dries, Webchick and I went out to grab some food. Travelling with somebody (read: Dries), who knows people all over the place (thank you, drupal), has its obvious advantages.

We ended up at a place where they serve semi-Belgian food. I chose a croque-monsieur, which was adapted to North-American standars, as they dropped the tomatoes and the salad inside the bread leaves, bu otherwise it was excellent. Kind of weird, they served it with fries, and they were superb! And they sell Duvel – which I did not have, but now I know at least of one place here where good beer is to be had.

And, Angie … thanks for dinner :-)