90 percent of everything : Usability Blog

Written by Harry Brignull

I’ve spoken to a few people recently who want a free / cheap PC app for recording usability tests, i.e. a screen recorder that does picture in picture. On a Mac, the solution is easy to find – it’s Silverback ($50). But on a PC, what have you got?

The most obvious contender is Morae – but it’s pretty damn expensive at $2000, and has has a whole raft of powerful research features that you might never need. It’s a bit extreme if all you want is to record footage of a user test for archiving and making highlight clips. Another downside is that Morae records to a proprietary format (.RDG) which you have to import into a sister app (Morae manager) and then batch export to get shareable video. This can take hours for big studies, and is best set up as a night-time batch job. In other words, a bit of a hassle.

One of the big questions you have to ask yourself when looking for a cheap alternative is whether you can live without picture in picture (i.e. the webcam footage of the user pulling faces as they do the tasks). It might be the industry standard nowadays, but a few years ago things were very different. Back in the 1990s it was normal to scale screen footage down to VHS resolution and record it onto tape, making the footage impossibly blurry (1024×768 down to 330×480 is never going to be legible). Later on, it became fashionable to record onto DVD-Video, which is higher resolution (720×480), but still fairly unreadable. If you wanted, you could add a hardware video mixer and a second camera to allow picture-in-picture of the user’s face. This was fairly common but not particularly useful since it didn’t escape from the fact that you could barely make out what was happening on screen.

The big breakthrough came when screen recording software appeared, allowing pixel perfect full-resolution recording along with audio via an attached microphone. Apps like Lotus Screencam and Camstudio were among the first entrants. Since then, masses of cheap screen recording apps have appeared, though not all are appropriate for user testing – some output strange video formats, others slow the test machine down or crash after 20 minutes. To save you the trouble of finding out the hard way, I’ve put together a list of personal recommendations:

No Budget whatsoever: Windows Media Encoder 9
- no picture in picture
Out of all the free screen recorders, Windows Media Encoder is the only one that includes editing facilities that allows you to create highlight clips from your sessions. The UI is pretty horrible, but it’s fit for purpose – just. (for example, the editing tool only gives you a thumbnail view of your footage, which is annoying). On the upside, footage is saved directly as WMV, so no need for time-consuming exports. Plus, the editor can trim the WMVs into highlight clips almost instantaneously.

Tiny Budget: Jing Pro with Quicktime Pro ($15+$30)
- no picture in picture
The new Jing Pro allows you to save your sessions as MPEG-4/H.264 video. This means you can then edit the video (unlike Jing basic, which though free, only outputs .SWF which isn’t editable). In addition to Jing Pro, you will need a stand alone video editing app. The cheapest option that’s capable of editing screen resolution video is Quicktime Pro ($30), which allows you to create highlight clips, and also chapter markers. The UI is limited, but unlike Windows Media Encoder, it’s easy to use. It’s also quick – it doesn’t require lengthy encoding or re-encoding of the video.

Small budget: Camtasia ($300)
- with picture in picture
We are now getting into the realms of non-cheap, but Camtasia is worth considering since it does picture in picture, unlike any of the other contenders. This is a big benefit – and it’s also still a lot cheaper than Morae ($2000). Camtasia is a mature product and it comes with a decent editing tool, along with various funky screencasting features that you probably wont need for user testing.

If you go for one of these options, you will notice that you have no functionality that allows you to add markers or flags to the timeline as it records. Don’t worry, there’s no need to get Morae or Silverback envy. In your session notes, simply record the current time when something interesting happens (You can bind a macro to a keypress if you’re feeling clever). Then, when looking at the session video afterwards, all you need to do is fast forward to the place where the system clock on the video matches the time in your notes. It aint rocket science.

Finally, I should mention I’ve omitted to talk about any of the really important aspects of user research: recruitment, study design, interview techniques, analysis methods, and so on. Your software package is only really an enabler for this “big stuff”. Luckily, these bigger issues have been written about extensively elsewhere. Mike Kuniavsky’s Observing the User Experience is good; so is Jeff Rubin and Dana Chisnell’s Handbook of Usability Testing (2nd ed). Remember, you can skimp on everything apart from hard graft and critical thinking.

Do you know of any other decent screen recording apps that do picture-in-picture with audio? I’d love to know!

If you don’t know the story of how the role and structure of DNA was discovered, you really should read the full article that I quote below, or even better, read The Double Helix by James D Watson (a charmingly personal account, highly recommended). Anyway, what you probably don’t know is the role that prototyping, particularly paper prototyping, played in the discovery:

When Dr. Watson heard details of Dr. Franklin’s work at a seminar she gave in November 1951, he and Mr. Crick felt they possessed enough data to start building a model.

Their model had three helical chains, with the phosphate groups inside and the bases sticking out. Dr. Wilkins and Dr. Franklin were invited to Cambridge to inspect it but ridiculed the result. Dr. Watson had misunderstood one of Dr. Franklin’s measurements. After a conversation between the two laboratory chiefs, Dr. Lawrence Bragg at Cambridge and Dr. John Randall at King’s, the two young scientists were told to return to their official, non-DNA work and desist from model building. They handed over their equipment to King’s, urging it be used before Dr. Pauling solved the problem.

But both Dr. Wilkins and Dr. Franklin ignored the advice. ”Both Jim and I became impatient with their slow progress and pedestrian methods,” Mr. Crick wrote later. And in January 1952, Dr. Pauling indeed announced that he had determined the structure of DNA.

But his structure, which had three chains, was wrong. Dr. Watson seized the chance to persuade Dr. Bragg to let the model building resume at Cambridge before Dr. Pauling saw his error and corrected it.

Mr. Crick had now deduced from Dr. Franklin’s X-ray data a fact she did not, that DNA must consist of two spiral chains, running parallel to each other but in opposite directions. He and Dr. Watson at last realized the bases might be on the inside of the spiral, even though it was hard to see how an irregular composition of bases could form a regular structure. They ordered exact metal cut-outs from their machine shop to make a new model.

But Dr. Watson was so impatient that he made cardboard cut-outs of the four DNA bases, known as adenine, thymine, guanine and cytosine, or A, T, G and C. Playing with them on his cramped desk, he tried to fit like with like, but nothing worked. After an interruption by a colleague, he suddenly noticed that an A-T pair lined up on his desk was identical in shape to a G-C pair. Immediately he saw how these could be the equal steps of DNA’s spiral staircase. Each of the four letters on one chain is matched by its opposite on the other; when the chains separate, each is the template for a new chain of exactly matching sequence.

”That morning,” Mr. Judson wrote in his account, ”Watson and Crick knew, although still in mind only, the entire structure: it had emerged from the shadow of billions of years, absolute and simple, and was seen and understood for the first time.”

Quoted from “A Revolution at 50” (New York Times article) by Nicholas Wade, Feb 2003

While I had this on my screen yesterday, the reactions of people walking past ranged from chuckling (“Is that for real?”) to asking enthusiastically if I had a copy to lend out. I’m not going to write my opinion here, since I haven’t read the book, but I’ll say one thing: there’s clearly a trade off between choosing a tool because it suits your team’s skill set – and choosing a tool because it enhances your design process or quality in other ways. The balance of this trade off is going to vary depending on your organisation. In other words, different strokes for different folks.

Parag Deshpande asked me to explain about Wicked Problems, so here’s a quick rundown. I’m not going to write a long post since this has been written about extensively elsewhere (including wikipedia).

So, what is a Wicked Problem? It means a lot more than just “hard”. Specifically:

• A Wicked Problem cannot be solved. It can only be “dealt with” in different ways, each of which have their own trade-offs and knock-on effects.
• A Wicked Problem means you must always think of your approach as “work in progress”, i.e. “the best we can do for now, given our constraints”. There is always scope to improve on your approach. Over time, externalities may change and open up new possibilities.
• Your understanding of the problem develops as you engage in your design process. The problem is a gradually emerging picture that is revealed by delving into design, tinkering and testing. Iterative research and design is ideal in this respect.
• To complicate things, Wicked Problems are affected by your activities in the world. In other words, when you release something into the wild, people start to use it, this changes their behaviour, their understanding and expectations. Your very own butterfly effect!

Everything you deal with as a User Experience designer is a wicked problem, at least at some level. If you think a problem isn’t wicked, you need to take a step back and think again. You are in the business of designing things to help or entice people to engage in certain behaviours. There is never a right way of doing this, only better or worse, and even this depends on your perspective.

“In answer to your question, there is no understanding, there’s only different viewpoints – from wherever you stand.” – Tim Booth, 1990.

Here’s a lovely series of pictorial slides from Iain Barker on the perils of rushing into a design solution too quickly.

Taken from Iain’s OzChi ‘08 presentation “Context is everything”

Check out these initial sketches for the Scribd user interface. This is what they should look like: messy and conceptual. For some reason, a lot of people still don’t get this. Being able to draw is a bonus, not a requirement.

Can’t see the embedded item in your feed reader? View it here.