“The Kindle will be to traditional books as the Segway is to walking.” (via slashdot)
“The Kindle’s so ugly, Speak-and-Spells run away crying when it comes in the room” (overheard)
“Amazon is touting this as the iPod of e-book readers … it’s actually the Zune of e-book readers.” (via slashdot)
“Is it just me, or is there something a bit weird about naming a product for reading books with a word which means “to set on fire”? Now, maybe as a name for Dell laptop…” (via slashdot)
Robert Scoble does an on-the-street usability-test / review of Amazon Kindle. It’s a rambly interview and the video is poor quality but it’s a refreshing antidote to the nauseatingly saccharin Amazon promo video.
The nice folks at Techsmith are giving away free copies of Snagit 7.5.2 and Camtasia 3. Both apps are really useful for UX professionals, and they’d normally set you back a few quid. They aren’t the newest versions but they are still very good.
Get Snagit 7.5.2 here, and get Camtasia 3 here.
There’s been a fair amount of discussion over the past week about eye tracking. As someone who used to do a bit of qualitative eye tracking research at Amberlight, (a great London-based UCD consultancy that I used to work at), I have a few factoids and opinions that I’d like to share.
1. Quant vs Qual eye tracking research - the key differences
Qualitative eye tracking research (“Qual”) involves observation and interpretation. First, the user is given a task while their eyes are tracked. During this time they are not allowed to speak (to discourage them from looking away from the screen). Then, after the task, the user is interviewed about their experience, and depending on your method, you can play the gaze trail video back to them and ask them to describe what was going through their mind. Analysis of Qual research involves touchy-feely “human” skills rather than statistical analysis. With Qual studies, you normally test between 8-20 users (roughly speaking).
Qualitative research is like a form of detective work. You look at the pieces of evidence you have available, and you try to fill in the gaps based on your past experience and expertise. It’s is a bit like looking around a crime scene and saying “Well the window is broken, the room has been upturned, it looks like a robbery.” But – the big but – you never actually get concrete conclusive proof that this is the case. This is the nature of Qual research, but don’t let it put you off - Qual is the cornerstone of most design research.
Quantitative, on the other hand, involves recruiting a large number of volunteers (e.g. 75-200), so you can collect enough data for statistical testing. This costs substantially more, and it takes a lot more time. Also, your research objectives are screwed down much more tightly – you control variables, you have hypotheses, and everything feels a lot more like “laboratory science”. The big differentiator is that although you get statistical evidence, you only get a sense of “what people did” but not “why they did it”. Qual, on the other hand, gives you a lot of “why” findings but no statistical evidence. With Qual, you have to put your trust in the expertise, experience and past portfolio of your researchers. When doing a Quant study, it’s fairly common to have a Qual element bolted onto it (e.g. interviewing the participants as well as tracking their eyes).
In summary: the point I am making here is simply that there are two types of eye-tracking, qualitative and quantitative. It’s important to understand the difference between the two, which leads onto my next point.
2. The “Qual-Quant confusion” problem
One problem with eye tracking is that the people who buy the service often get confused about what type they are getting. The high tech kit, the gaze trails and heatmaps look impressively scientific. It feels like the most rock solid evidence you’re ever going to get. In a qualitative eye tracking study, this just isn’t true. I’m not saying it’s fictional - I’m saying it’s just a picture of what a dozen or so people fixated on. In other words, it can useful but it’s just another piece of supporting evidence, like the verbal statements of your users, or your observations of their behaviour (e.g. task failure rate).
Going back to our “qualitative research ≡ detective work” metaphor, both eye tracking heatmaps and hand-written notes are like ‘clues’. They require human interpretation. The researcher has to sit there, scratch their head and think about what it all might mean.
In summary: in a qualitative study, eye-tracking data is no more valid or conclusive than your handwritten interview notes. Just because heatmaps and gaze trails are shiny, impressive and expensive doesn’t mean they hold any special “weight”.
3. Eye tracking tells you what users looked at, but not why.
Imagine you have run an eye tracking study on your site, and you now have a heatmap showing what 12 users looked at. You notice that there is a lot of heat on your proposition statement. Great, you think to yourself, they read the proposition! This means they understand what we are offering!
Actually, you’ve just made an assumption - that the more someone looks at something, the more they understand it. Actually, the opposite might be true. The heat may be a symptom of confusion - users might be re-reading your statement repeatedly because they found it hard to understand.
Just because someone looks at something doesn’t mean they understand it or like it. This is why eye tracking is almost always paired with interviewing where you try to find out what users were thinking. In short, beware of heatmaps - they can be easy to misinterpret.
4. Eye tracking often doesn’t tell you anything new
Another problem with Qual eye tracking is that often, it doesn’t tell you anything that you wouldn’t have found out through other means. Take a look at the eye tracking evidence provided by Luke Wroblewski in this study here. It’s a great article for educational purposes, but to an experienced eye, it’s quite obvious which would be the winning and loosing design patterns. Theory and principles like “affordances”, “visual hierarchy”, “call to action” and even Nielsen’s heuristics would all point you towards the right approach. And if you use “standard” user testing methods (no eye tracker, just a 1-on-1 interview where the user is given tasks and thinks aloud), you can test your designs without the cost of eye tracking - simply record task time, failure rate, and gather user feedback.
I’m not saying “don’t do qual eye tracking”, since it can be a great educational tool, it can uncover things you may not have otherwise noticed, and it can be a great weapon when trying to fight the user experience corner with a difficult stakeholder. But you’re unlikely to suffer if you don’t do it, and instead you opt for cheaper “standard 1-on-1 user testing” (by this I mean giving users tasks, asking them to think aloud and interviewing them).
In summary: if you don’t have a huge budget, and your research objectives don’t explicitly require eye-tracking, then you should seriously consider other options. Eye tracking can be expensive beyond its usefulness. Instead of doing a single, costly eye tracking study, it can be more rewarding to do multiple rounds of “standard” user testing (iterative design & research), and employ a collaborative process using a war room and design workshops. Involve your design team: research should be an intimate part of the design process, rather than something carried out by strangers and delivered via PowerPoint bullets.
The current discussion about the Amazon Kindle suggests that its feature list and capabilities far outstrip anything that traditional paper could ever manage:
Amazon Kindle:
Book:
A fairly random selection of things I’ve been looking at over the past week or so.
You may have noticed that a few people are blogging about Blendie right now - the blender that you growl at to make it go.
If you like the idea then try downloading Racing Pitch - a prototype PC game from Skinflake that works on the same principle. You make an engine noise into your microphone to make your car go. Your pitch determines your speed, and if you ‘accelerate’ too fast, you make your car skid.
It’s only a proof-of-concept but it’s quite fun, and when the novelty of playing it wears off, you can watch your friends making a fool out of themselves. All in the name of interaction design research!
I read a nice factoid on this topic this morning in Eric Schaffer’s Institutionalization of Usability book. It’s a quote from Jared Spool:
In April of 2002, Princeton Survey Research Associates surveyed 1,000 adult Internet users about their concerns with privacy on the Internet. In the survey, only 18% said they never read privacy policies most of the time, or every time they shop.
Yet, in our study of more than 1,000 shopping sessions, where we actually observed what users did while shopping, we noticed that only two users ever checked the privacy policy. And for these two users, it had no effect on their shopping behaviour. This is yet one more case of users doing something different from what they say they do.
To reiterate this point -
What users said they do:
82% of users said they read privacy policies (from survey data)
What they actually did:
0.2% looked at privacy policies (in user tests)
This ‘observational data vs self-report’ argument is a road well trodden (read Jakob’s 2001 alertbox on this topic here, or a great signal vs. Noise post here), but I like this factoid because it sums up the argument so well.
[Note - typos have been removed from the original post. Thanks Jared!]
I was looking at the packaging of my Arm & Hammer toothpaste this morning. It has metallic inks, embossed card, and plastic lamination. The box probably cost more than the contents. It’s kind of pointless given that everyone chucks the box away as soon as they open it.
When I got into work, I stared at the UI on my Mac and noticed some similarities. Nowadays we’ve got translucent windows, genie effects, and all kinds of hardware accelerated eye candy. It got me thinking - what’s the environmental impact?
Take your average drop-down menu in Os X or Vista. You click on it, and you’re treated to a drop-shadow and maybe a blur and a translucence effect. To achieve this, you’re computer is hammering the graphics card, and as a result it’s using more electricity and chucking out more heat. OK, it’s probably a tiny amount even if you multiply this up by global usage over time, but the point is, it’s needless and avoidable.
So, every time you click on a dropdown, you are increasing your carbon footprint. Gradually bringing about the next ice-age, one click at a time.
The OLPC (aka the ‘hundred dollar laptop’) has a ‘View Source’ button on the keyboard. See if you can guess which one it is in this image here.
The motivation for this is to let kids ‘under the bonnet’ and learn to program (Python, specifically). Is it really a good idea?
Blogger Mike Hearn made some interesting comments on this a few days ago:
When I was a kid, my school had a computer lab containing on BBC Micros. They were used for teaching maths, using LOGO and that sort of thing. They didn’t even start teaching us programming until we had a good grasp of maths and ‘procedural thinking’. Then when they did, they introduced it very slowly, so not to leave anyone behind. On BBC micros, you could get to the source code (BBC BASIC) at any time by hitting the Escape key. And you know what? Teachers would shout at us for doing this. When you teach kids, lessons are highly structured, and you drip feed them concepts one-at-a-time. You don’t throw them in the deep end.
To give an analogy, if you were teaching 10 year old kids literature, you wouldn’t do it by reading them random chunks of Macbeth. That would just turn them off. It would be overwhelming and, more to the point, boring.
But isn’t this exactly what the View Source button does? Take a quick look below at the source code of BlockParty (A Tetris-style game), and put yourself in the shoes of a 10 year old kid.
I’m sure it’s a neat feature if you’re already up-to-speed on Python, but there’s a fairly tough learning curve you’d have to get past first. So, like the OLPC itself, the View-Source button is just an adjunct to traditional teaching, rather than a learning solution in itself.
I’d find it so much more reassuring if there was some well planned open source teaching and teacher-training materials coming out of this project in addition to the OLPC hardware/software bundle.
That'll be me, Harry Brignull. I'm User Experience Consultant at Madgex in Brighton (UK). My work involves making experiences by blending User Research, Interaction Design and UCD process consultancy. In the past few years I've consulted for Nokia, British Airways, Vodafone, O2, AOL and many others.
Read more...
