Wednesday, June 30, 2010

The Design of Fuzzy Things

Another book-related post. This time I'm going to approach the topic of playful usability via The Design of Everyday Things (Don Norman). I don't think I this book needs any more recommendations, so let's just go ahead with some thoughts of my own*.

I'd like to start with the three models. There's designer's model, which is how the interface is designed to work. On the other end, the user's model, is how the user thinks the interface works. And in the middle is the system image, responsible for communicating how the interface works. In other words, the user's model is dependent on the system model. In fuzzy usability, the system image is intentionally non-obvious. The idea is not to directly communicate the workings of the system but rather present an interface that raises curiosity and allows the user to discover the workings. By obscuring knowledge we make it more desirable to attain.

My hypothesis for the benefits is that interfaces constructed this way are easier to learn. In a typical desktop interface such as the Firefox web browser I'm currently looking at, the user is immediately presented with a lot of actions. Wizards are often used to guide beginners. The downside is that wizards are separate interfaces for doing specific tasks and do not teach the user to use the program's interface. In a purposefully obscured interface, it is easy to start by presenting the most basic of tasks and reveal advanced features when the user "levels up". The application can reveal the presence of features when they become relevant.

We can think of interfaces separated into zones. Anything the user is already familiar with is in the safe zone, and the message is clear "you know these things, it is safe to work with them". On the borders of the safe zone, there is the uncertain zone. The user has an idea of what is there, and it's kind of saying "you might feel uncomfortable here, but these things can make you more powerful". Finally, there is the great unknown, beyond the uncertain zone. When the application realizes that the user is doing something that could be done better with an advanced feature, it can assign quests, sending the user to explore a particular uncertain zone or even an unknown zone. If the user wishes to find a particular feature, the help system can provide directions of how to get to that feature.

Unsurprisingly, this bears high similarity with playing openworld or sandbox games like Grand Theft Auto. The player can explore quite freely, discovering new areas progressively while learning new skills. But when the player wishes to get on with the story, there are certain things that are required, and hence the game sends the player on quests to meet these requirements. Add rewards for mastering new skills. One further way to think of this comparison is that of task. In a game, the task is to complete the story. In an application, the task is to complete some external goal. Typically the difference between these two tasks is their definer: in a game, the task is defined by its designer while in an application the task is defined by the user. The point remains the same though: why shouldn't the user/player have fun while learning the skills required to complete the task?

In terms of affordances, safe zones afford safe using of features with predictable outcomes; uncertain zones afford experimentation with features; unknown zones afford exploration. Restrictions can also be used by requiring certain features to be in the safe zone before the user is allowed to use particular advanced features. This will ensure that the user has grasped some important basic concept before trying to use a feature that heavily builds upon that concept. The restriction also comes quite naturally - the user needs to traverse through the prerequired features on his way towards the advanced feature.

Implementing an interface that conforms to this model should be an interesting task. Some key considerations in functionality are to ensure that 1) the safe zone really is safe and 2) the uncertain zone clearly supports experimentation. Predictability is key in the first consideration, while proper undo support is key in the second. Another implementation question is analysing user actions in a way that the application can decide when it is appropriate to advertise a feature.

* Similar thoughts can be encountered in several HCI articles, and I'll return to them later. Difficulty regulation is a good key word if you're looking for one.

Monday, June 28, 2010

The Future of Computing

Lately I've been traveling quite a bit, so I've had time to read some books. This time around, I'll discuss three of them: The Design of Future Things (Don Norman), Leonardo's Laptop (Ben Schneiderman) and Everyware (Adam Greenfield). I've chosen these three for discussion because in many ways they are about the same thing: the future of computing. Norman's book of course touches a whole lot of other matters about future things, whereas Greenfield's book is about ubiquitous computing specifically, but all three books send the same message. It's time for users to step up.

The machines are about to take over. Not like in the movies of course, but subtly. We are about to become servants to our machines. Clearly, it should be the other way around but without enough thought given to human-centered design, we might end up with machines that think they know us and what's best for us, restricting our actions when they see fit. Machines, that demand our attention and maintenance. Networks that share everything about us without our consent. When computing will be everywhere, using it is no longer a matter of choice. And if the interfaces suck? We are screwed, and we have to learn them. These are some of the scenarios discussed in these books.

If, for some reason, this does not scare you, then think about what user-centered design for future computing could give us. A lot of possible scenarios for the future are presented in Leonardo's Laptop and they all share one central theme: computing should support, not replace or automate, human tasks. Technology should be making our lives easier, not harder. Computing should be available, not integrated. And, contrary to some beliefs, it should never be entirely seamless or invisible. Which computing do you want?

Jumping to another topic, the idea behind the concept of interactive spaces is in many ways similar to ideas described in these books - especially The Design of Future Things. Humans and machines do not talk to each other - not today, probably not in the future - they signal. When communication is limited to signaling, it is better for one participant be completely predictable. In this case of course, it should be the machine. The user knows what he wants to do - there's no need for the machine to try and guess, because no matter how much sensor information and whatnot it has, it cannot read our thoughts (hopefully).

Norman presents a good example from human-to-human communication where this also holds true. Here's another one: sometimes when walking, you find yourself walking on a collision course with another walker and when you avoid - yup, the other guy avoids to the same direction, and probably then the both of you avoid again to the same direction. This is a scenario where neither participant is predictable. Indeed, if you had just kept walking straight, the other guy would've avoided you. This scenario becomes a lot more dangerous when bicycles or cars are involved. It's happened to me with bicycles, and if I hadn't landed on my butt, I might not be writing this.

To wrap up, here are some of the principles of interactive spaces:
- Interfaces are available to the user - not seamless but gracefully seamful.
- Interaction is initiated by the human.
- Interfaces are precitable - they don't make decisions on their own.

Out of these books, I would highly recommend Everyware for anyone even remotely interested in the future of computing, and especially defending human rights in the coming* age. The other two books are good reading for designers, and especially Norman's book is once again really easy to read and even fun. All of these books made me more confident that what I and we are doing is relevant and important.

* In fact, we are partly there. The latest of these books (Everyware) was printed in 2006, and already it was said ubiquitous technology is in part already here.

Thursday, June 24, 2010

Foundations of Digital Games 2010

Another busy week behind. Exactly a week ago I was on my way to California, and more precisely the Foundations of Digital Games 2010 conference in Monterey. Here comes the aftermath.

Considering my own research, FDG2010 was mostly useful for the game design point of view but not that much actually. There were some interesting presentations and conversations with people about experimental game control methods, and finally some proper information about Kineckt. However, considering teaching game-related anything or game-aided education, the conference was much more useful for me. The details about the conference will be available later somewhere in the internet, so I'll just post some collected thoughts.

There was a plethora of sessions about inspiring more interest for computer science by using games and game design as part of CS education as well as to make potential students familiar with game development before college. I'm not exactly sure as to what the situation is here in Finland but I guess we can always use more interest. Probably the single most interesting session was about Microsoft Kodu, which is a visual game programming language, easy enough for children to learn. In the II City project, we are interested in using focus groups to create ideas for games, so you can probably see where this might be going. Yes, we can use Kodu to familiarize non-programmers with game dev.

Another thing I picked up were a lot of ideas for teaching a more serious game development course for post-grad students. This topic was presented in several sessions, and also discussed randomly throughout the conference. I'm mostly interested in doing this as a project-based course, and if possible, as a cooperation between our university and the department of industrial design in the University of Lapland. Bringing in artists from another university can get around the problem that CS students are not expected to have artistic abilities (and therefore we can't require them). This was how I had thought to do it to begin with, but discussions in the conference made me more confident. We can do this.

It was also nice to see a good glimpse of all the work being done in educational games, the Holy Grail of e-learning. There were quite a lot of projects presented that taught students computer science concepts in ways more interesting than plain programming practice. Using these kinds of games for teaching the basics of programming is an idea worth contemplation, especially if people are having a hard time grasping some of the concepts in our introductory course (I haven't asked yet, but in August I'll probably see for myself anyway). Of course, many a presented game taught other concepts than CS, such as how cats see the world.

Finally, game design was definitely not a forgotten topic. However, since there were always two sessions in parallel, I had to make choices, and because of my job, I ended up selecting all the education related sessions. So, like other people, I will have to check the interesting game design presentations when the presentation videos become available.

Jetlag and all that jazz aside, it was a good experience for a first conference trip. Although I definitely didn't expect that it would actually be cold in California. The wind was a real killer, especially on Saturday. In addition to huge amount of inspiration, I got to meet a lot of awesome people. Hopefully I'll be able to visit FDG2011 if it gets organized, wherever it might be. Oh, and the conference center had some serious Norman Doors - I took one pic, which I'll try to post later when I get it on my computer.

(During the trip I also had a lot of time to read books, so book reading report is up next)

Wednesday, June 16, 2010

Moving to Education - First Steps

Lately I've been working on course material, including sample code and lecture slides. I will be teaching my first course in august, and the topic is Introduction to Programming Through Game Development. It's a trial, an intensive course with the goal to teach students basics of programming and basics of game programming. We're hoping to inspire greater motivation for students to learn programming.

In my research, I'm taking part in rethinking usability. In education, I feel I should take part in rethinking teaching. I haven't fully thought out my teaching plan yet, but I will pursue active learning by having the students work on their own (simple) game projects throughout the course, instead of artificial exercise assignments. Of course, I'll have to do some lecturing since it's a basics course, and I'm specifically required to teach them the topics covered in our standard Introduction to Programming course. My initial inspiration for how I might do this comes from Ian Schreiber's blog Teaching Game Design, and for more inspiration, I think I'll revisit What Video Games Have to Teach Us About Learning and Literacy (by Paul James Gee).

I'm trying to avoid traditional lecture material. Instead of factual slides, I've made a relatively small amount, using mostly pictures that are fun and reflect the topic I'm talking about. More specifically, I'm using a lot of lolcats - we all have our personal quirks, so get over it. Slides aside, I have created an example project and taken snapshots from its source code throughout all phases of development so I can throw my students some practical examples to explore and play around with. I pretty much think that's all the material I'll need to pull this off (of course, we have a textbook as well, so students can look there if they prefer more reading).

My thoughts for this one are not exactly radical but it's a start. If the course goes well, we can probably try some more advanced courses in game programming, and then I can scrap the lecturing part altogether. Programming is fun. Game programming more so. Teaching game programming should also be fun. Looks like the course will be Introduction to Programming, Game Programming and Obscure Internet Humor. All in the name of science and creativity.

An interesting sidenote: Using pictures that are far from obvious is (sometimes) better than using ones that explain a thing really well. When I was leaning Japanese Kanji, the ones I found easiest to remember were the ones where I had to think for myself how to interpret the character. Humans are proud of achievements - if we make sense of something non-obvious, we want to remember our explanation and spread it to others. So maybe if students understand how this picture reflects doing operations to elements of arrays, the whole concept of arrays sticks better.

Thursday, June 10, 2010

Irrationality and What Should We Do with it

Time to discuss some stuff I've read from books recently. The first book is Dan Ariely's Predictably Irrational. It's actually a book for behavioral economics, but can tell a lot about how we humans are wired for anyone in any field. Because it's also quite fun, not too long and well-written, I can recommend it to anyone even remotely interested in human behavior.

In the book, Ariely discusses a lot of different types of circumstances where humans repeatedly fail in rational thinking. Hence the name. A lot of the stuff is actually really familiar for most of us, because we've been down those roads. The book does a good job of pointing out the circumstances where people make bad decisions. If people became more aware of these things, maybe they could make better decisions in the future. Who knows, right? For someone in the HCI field, and game design as well, every tidbit of knowledge about human behavior is valuable. Here are some thoughts I gathered while reading:

Actually my first thoughts were whether we could actually use this kind of irrational behavior to purposefully "deceive" the users. For game design, it's also helpful to know how people form their decisions in different circumstances. This way players could be guided implicitly instead of explicitly when the designer would really like the them to pick a certain option. Most players would likely end up picking the intended option, but they would still think they are firmly on the driver's seat. Actually I think it would be an interesting for game researches to analyze how decision making situations are staged in games (although they may have also done this kind of research already).

And what about interfaces? It's kind of a harder case. Here the designer doesn't want to guide the user into doing something. The idea is for users to get what they want, which is something we really cannot predict. I don't have any particular ideas yet, but I'd like to explore the concept of purposeful deception in usability to produce outcomes that make for a better user experience. Maybe it's a dead end but you never know before you try.

Then again, should we exploit irrationality? After all, it causes people to make bad decisions that can be really damaging to themselves in the long run. Perhaps it would actually be better to make games and applications that highlight our irrationality and make us aware of how it affects us even in situations we consider "too important to fail". Some games do require players to abandon certain types of irrational behavior. A lot of board games for example encourage players to make hard decisions instead of keeping all the options open. In order to win, players need to commit to a strategy sooner or later. It promotes simple folklore wisdom; "if you run after two hares you will catch neither".

This I think is another interesting topic where games could be used for teaching people, more effectively than most learning methods. After all, games are good for experimentation, because players don't lose anything permanently (in most games anyway). Of course therein lies a problem as well: we think differently when we know there is nothing to lose. So even if we learn to avoid our irrational behavior in a virtual world, does this wisdom transfer into real life, where losses are also real? It might be a tough challenge to come up with something that produces real benefit, but something that should be considered.

We are already coming up with games and applications that encourage people to exercise and look after their health etc. Should improving our thinking be the next step? After all, it is our thinking that's the root of everything else.

(I've also re-read Donald Norman's The Design of Everyday Things but it's something I'll get back to later.)

Monday, June 7, 2010

1st International UBI Summer School - The Aftermath

I haven't been writing anything for a while, and here comes the explanation. I was attending to the 1st Internation UBI Summer School, held here in Oulu by the UBI project (UrBan Interactions). Basically it took all of my time last week: seminar and workshops every day between 9:00 and 16:00, and social events in the evenings. Of course it was totally worth it - there were lots of interesting people from all around the globe, and the workshop I was in was cool and really relevant to my post-graduate studies.

I was in a workshop called Urban Social Networks Analysis, instructed by professor Vassilis Kostakos from the University of Madeira. Our task during three days was to gather bluetooth data from the city of Oulu, by scanning for bluetooth devices in various locations, and to use that data to analyze how people (carrying the devices) were moving around the city. My workgroup was trying to figure out groups from the data, and some flocking behavior. Sadly it turned out that two and half hours worth of scanning by five groups was not enough for finding any groups of devices that would appear together in more than one location, so we had to to just do some group analysis.

It also turned out that analyzing groups computationally was far from trivial, and turned out to be quite a challenging task to do in about two days of programming. More work needs to be done on the algorithm later on. But anyway, the really useful stuff I took home from the workshop was how can we utilize simple data that has just time stamp, location and identifier to derive quite impressive representations of how people move around. Figuring out this kind of information can be seen as essential when seeking to understand the flow of people in a physical space. It answers the question "where should we put interfaces?", which is a key question if thinking about the difference between typical HCI and HCI for interactive spaces.

On Friday we had the final presentations for all the workshops (six in total). I did have a lot of difficulty choosing the workshop to attend to beforehand, and after seeing the presentations I really wished I could've been in all of the workshops (except one, which was very technically oriented). The other topics included "Real World Context-Aware Applications", "Urban Informatics and Sustainable Cities", "Creating and Sharing Artistic Experiences with Ubiquitous Technology" and "Interactive Textures - Rethinking Materiality". Let's just say that the results for each workshop were pretty amazing, especially considering they were done in just three days.

If any of the guys I met are reading this, thanks again for being there - great times were had! For those who weren't there, I'll try to post some links later if they release any interesting aftermath material about the summer school.