Wednesday, May 13, 2009

Hazard: Usability Studies, proceed with caution.

So this study, by Saul Greenberg and Bill Buxton, is really a complaint against method more than anything. Usability Evaluation Considered Harmful (Some of the Time) is a paper that mostly complains against strict adherence to a method. It seems to me that if you have an experimental phase done in the front it would help this process a lot. It seems to me that Usability Evaluations is more of a refinement process than anything. You have to have a raw process in place before hand. So the complaint could largely be levied against just aribitrarily copying ideas.

Eh, it wasn't that bad.

Human Centered Design considered harmful

Once again we hear from Don Norman, and once again he changes everything. We shouldn't focus on tasks anymore, now we focus on activites. He points out that many successful things today were designed through Human-Centered design, like the automobile, which was designed to be able to perform an activity, not do a specific task. It seems to me to be the approach of "What would people use this for?", rather than "What can we make this thing do?".

One interesting thing I liked that he talked about was the adaption of people to technology, rather than vice versa. I have encountered this in video games, especially first person shooters, if people deviate to much from the standard controls, I don't like it, and try and switch it back, or at least get it as close as possible, even if it's supposedly better. It seems to me that eventually you feel as if you have "mastered" technology, and if it changes, that mastery, and the comfort it provides, is gone, and range from disconcerting, to violating.

Anyway cool beans.

Ehtnographies considered harmful, but only when you do them, because you do them wrong

That's what the paper seems to be saying. So the title is pretty misleading, by which of course I mean "Ethnography considered harmful" by Andy Crabtree, Tom Rodden, Peter Tolmie and Graham Button. They argue that ethnographies are becoming to focused on "situated actions" rather than dealing with people as a whole. I can see this being an issue, like when the designers think of notifying you with different beeps, but every designer does this, and eventually you have a nonstop cackaphony of blips and bleeps that you end up answering the toaster and finding breadcrumbs in the dvd player.

Anyway, these sacred guardians of "ethnographies" seem to just be pushing for a name change, but that doesn't seem to be worth the subject of a whole paper. Geez guys.

Fitt's Law

First time I heard this I thought it was Fitz Law, which meant googling didn't turn up the right stuff. but I got it right eventually eh.

So Fitt's Law is T = a + b log2(1 + D/W), so basically, the closer and bigger it is, the easier it is to point at something. It was proposed by Paul Fitts back in 1954

Anyway, Fitt's law is very interesting in that it provides a rigid quantification of Human Computer Interaction. In a field permeated with ethnographies and questionnaires, and fuzzy measurements, it was good to know that something exact could be deduced.

It has held up remarkably well over time and is very important to CHI, which is full of pointing of various kinds. Unless your using a keyboard or voice, pretty much all other interfaces involve pointing (mostly because of buttons). It things like this that contribute to CHI becoming a harder science.

The Inmates are running the asylum

This book was fairly interesting, and I did enjoy reading it. I have joked around that it's a "novelized resume", but I guess his experience would be with what he himself had accomplished. The dancing bear concept was also pretty cool, but I kept thinking how awesome it would be if combined the power of a bear and the grace of a dancer, what if you could make it good? But enough about that. Some things I'm also glad he talked about is not having software engineers design the interface. I found setting them in an entirely different species semi-offending, but eh. Let them focus their energy on making a product work well with the specifications they are given. Another thing I liked was how deadlines worked for software. In other projects, if something is delayed, you don't just call it done. How would you feel using a bridge that crossed half of a canyon, because they didn't finish the other half because of the deadline. Just taking more time can make a product better. Most of the book that I liked applied to time issues, allowing enough time for design, and not demanding insane work-hours to meet a deadline that was set to early. Parkinson's Law was an interesting concept too. Another good distinction is that of features and tasks. Certainly you need features, otherwise your product doesn't do anything, but that is coming from the wrong perspective. You need to look at it from the point of what I can do with it. Ask not what your software can do for you, but what you can do with it, I guess... we'll think that one over a bit more.

Monday, May 4, 2009

Playing the game. EyeSpy: supporting navigation through play

EyeSpy: supporting navigation through play.

This paper was written by Marek Bell1, Stuart Reeves1, Barry Brown2, Scott Sherwood1,
Donny MacMillan1, John Ferguson1 and Matthew Chalmers1 (1. University of Glasgow, 2. University of California)

One of the central ideas behind this paper is getting useful information from a game, while keeping the game fun. I am a big supporter of these kind of things. One of the cool things about EyeSpy, is that it takes place in a real world environment. Alternate Reality Games, and augmented reality I think will soon offer more and more interesting things to do simply while you are doing your everyday activities.
But now on to what they actually did.

EyeSpy is a game designed to extract easier navigational aides and landmark recognition from photos as well as text tags. Though the text tags really did not work, the pictures where able to help quite a bit.

Here is how the game is played, and it's played over a weeks time integrated into your daily life. Players take pictures that they think people will recognize, and then other people have to confirm it by visiting the location and confirming the photo. (The software that the game works with tracks location by looking at wireless networks.). Over time the players got better at finding spots that people would easily recognize. After the game was finished, people were asked to navigate using the photos, versus random ones of the same area from Fliker. The photos from EyeSpy were significantly better at this task.

I am looking forward to seeing more articles on extracting useful interaction from games.

Playing tag with blue people. Socially augmenting employee profiles with people-tagging

Socially augmenting employee profiles with people-tagging, is an article put out by the people at IBM concerning an experiment they ran on there own Blue Pages (Think IBM's personal Facebook), where you could tag people. In an effort to keep things friendly and useful, there are only public tags, and tags you put out can be easily traced back to you. The effort is to try and improve blue pages with relevant information. If a person has a lot of people tagging him with "good java experience" or something like that, you can easily find people like that within the orginization, even if there job doesn't necessarily imply that. Not all the tags were work-related of course, humourous ones such as "needs to shave" still popped up, but still interesting. In the future they were thinking of making private tags, so that you could sort through your own contacts fairly easily. I personally like the idea of being able to tag people with features, and being able to electronically store things they can do. I don't think I would want it in a purely social medium, such as Facebook, but in a workplace setting this could be a valuable asset for finding the right people, especially in larger companies.