Usability Notes - by Chris Baker

The awkwardfulness of doing things a new way- my search for an iphone timesheet app

I have recently been moving my timesheets and to-do lists to my iPhone. The iPhone apps I tried for this initially seemed to have poor usability, simply because they required me to do important things in an unfamiliar way. The awkwardfulness of doing something in a new way is both an issue and a red herring in usability studies, I argue.

For a Project Manager such as me, my to-do lists, calendar and timesheets are about the most basic of tools - equivalent to the carpenters hammer, saw and plane. I need an easy and reliable way of maintaining these kinds of information, and for a decade or so, I've kept it all on paper, using a loose-leaf planner from the Franklin Covey company. Over that time, of course I've got well into a routine. The paper planner has served me well, the only problem is my planner weighs nearly 2kg and is the size of a large textbook. It's also difficult to back up, always a worry for anything containing key information. Up until recently, it had to be paper - to-dos, calendar and timesheets need frequent quick updates and I could not always rely on being at a particular PC, or on being able to get online (to use files "in the cloud"). The iPhone changes that, being a truly pocket-sized computer.

The timesheet apps I have tried are iPunchclock and Easy TimeSheet (I have also been recommended iTimesheet but haven't tried that as yet). The first thing that I found disturbing was that both apps I tried are basically stopwatches - you touch a button to say you've clocked on, and then again when you stop or pause. There are then various features with which you can note what you were doing in the interim. Some editing is possible  (e.g. if you forget to click stop & find the timer has been running all night...).Then, there are features enabling you to create a spreadsheet or other report and to email or otherwise export it for further work.

 

When I say I found it disturbing I should emphasize that I DON'T mean that this workflow is inherently bad - the whole point of this article is that  it was just not what I was used to. I found it interesting that this made such a difference. For many years I have noted my start time, noted my stop time and then made any other notes. So this is how I would have designed my own timesheet app. (I did consider running my timesheets via a spreadsheet, and then I could have done exactly this. But so far I've found spreadsheets clumsy on the iPhone - not so much the spreadsheet apps, but the small screen and so the feeling of painting the hall through the letterbox.). When you think about it, clicking start and stop comes to the same thing as writing down start and stop times. But still, I found the iPhone apps clumsy and difficult to use, and would certainly have reported this if I had been taking part in a usability trial. I nearly rethought the whole idea.  A few days later, I'm settling down to using this stopwatch method and don't find it difficult any more.

When I turned to to-do lists, I tried FCTasks, (sticking with the Franklin Covey company). There is a helpful demo video of the product - embedded below.

Here I was on more familiar ground, but I did find one unfamiliarity problem. A feature of the product is that tasks are prioritized A, B and C (A are things that really must be done today, B are important but not so urgent, C is less important and so on. Ranking is competitive - your A1 task is the first you turn to, then you work through the A's and onto the B's. Here my problem is that I would typically assemble my to-do list, and then add priorities first thing in the morning as I plan my day. FCTasks requires you to state a priority immediately the task is created. Which is not a problem as soon as you get used to the idea of giving it a provisional priority and tweaking it later.

An interesting feature of both awkwardful problems I found (the unfamiliarity of the stopwatch; the need to assign a priority to tasks immediately) is that for all that the problems turned out to be very simple-sounding, it took me considerable thought to unpick what exactly I was finding difficult.

So, in both cases, I experienced problems of "awkwardfulness" (and awkwardful word that I like because it is so...awkward, and which I think I got from Douglas Hofstadter. If I recall, it turns up in Hofstadter's book Gödel, Escher, Bach: An Eternal Golden Braid ). Awkwardful problems are ones that provide a user with a temporary, personal usability problem based on the application not working in the way to which the user is accustomed (the application has to work in a way that does make sense to many users, or it is merely poor design). For a non-software example of awkwardfulness, consider the difficult initial days of attending a new job (or a new school) - suddenly all kinds of things that were easy to do in familiar surroundings are hard. You are forever having to ask "where is the photocopier?" "How do I book a meeting room?" or the equivalent.

Awkwardful usability problems seem significant for a while but would  rapidly be overcome with persistence and familiarity with the application. The problem is that a lot of users just aren't going to persist, blaming the application for not being very usable.

Technical Debt, a useful metphor for software projects

"Technical debt" is a nice metaphor for discussing the long-term costs of some project decisions.
For example, imagine that you are building a complex website that has a tight commercially driven deadline (e.g. it must be ready to do business by Thanksgiving/Christmas). The way you would ideally like to do the project is not compatible with that schedule, so you decide to develop faster, deliberately choosing a solution that is less easy to support in future, is less extensible, less robust, requires more maintenance, or suffers some other trade-off. Just as if you had taken out a loan to finance the project rather than take it out of revenue, you are committing yourself to future expenses (cash, staff time, more imminent replacement of the system) in order to buy short-term progress. This might, of course, be entirely satisfactory if the profits from being live by Thanksgiving are attractive enough. 

Of course not all debt is deliberate - just as you can work up a big overdraft by spending carelessly, a poorly run project could get deep into technical debt by inadvertently doing work that it will be difficult to support or extend.

Browsers, search engines, it's all the same to most folks

Ask some people what car they drive and they'll answer "A Ford Focus Zetec 1.6" (for example). Ask others and they will say "er...a blue one?". Which is of course an OK answer - you need to know how to drive it, how to recognize it in car park and whether to refuel it with petrol or diesel. And that's probably all you really need to know for daily purposes, even if you use the car a lot.

In an interesting post on the Google blog, Jason Toff did a straw poll of his friends, asking them "what is a browser?" Some interesting results (90% of his poll knew which car they drove c.f. 50% knowing which browser they use, even though most of the sample spent more time online than driving):

Linked from Jason's post is an interesting (and entertaining) video in which someone from Google does a vox pop in Times Square New York asking people what a browser is, which one they use and whether they know the difference between a browser and a search engine. OK, if the interviewees had just been told they were speaking to Google this might have muddled them up a bit, but <8% of interviewees (not even Santa Claus) knew what a browser was. You get a strong impression that for a lot of folks Windows/Internet Explorer/Google is all part of "the blue one". Something which I (with 4 browsers on my system for work purposes) need to remember!

<

Content is Consul?

Mr George Handel (1685 – 1759) ever the businessman, had a good publishing scheme for his Concerti Grossi - ahead of all that expensive engraving and printing, he sold subscriptions via a newspaper advertisement. When copies were printed, most subscribers collected theirs in person from Handel's house in London, but a few had to be dispatched to other towns.

It's fun to speculate how Handel wouldbe operating as a composer, entrepreneur, impresario and publisher if he was around today. He was certainly well up with the fashions and business opportunities of his own time - making a fortune out of the fad forItalian opera (imported castrati superstars and all), and then spotting the new trend for works in English and producing a further smash hits, such as Messiah. Were he in business today, I like to think he'd be happily exploring the publishing and marketing opportunities of the internet.

One unchanged thing is the need for a publisher to have both content to publish and an audience to publish it to. There's plenty of room on the Internet for stuff that hardly anyone reads ("Wikipedia is not paper" ) but for a business you need to create content folks care about, and get it to them (or get them to it). Same game, new challenges.

Thinking about the favourite digital myth that "Content is King" perhaps it would be more accurate to say that "Content is Consul" - one of two rulers of  your Internet business, the other being your ability to attract and retain an audience.

Simple, but not easy

"Although this stuff is simple it's not easy (there's a difference)."

This great quote comes from "What Got You Here Won't Get You There" by Marshall Goldsmith. Mr Goldsmith makes a living by coaching executives whose further progress is being hampered by one or more unfortunate habits. But by doesn't it apply to a lot of areas of life! If only we could all be MBOs (Masters of the Basic and Obvious)

Software "Ecosystems"

PC Pitstop have a review of a talk by Steve Sinofsky (A Senior VP of Microsoft) at the October 2008 Microsoft Professional Developer Conference. The article reports Mr. Sinofsky's comments about Windows Vista and the forthcoming Windows 7. I found the following quote interesting:

"Even Microsoft can’t hide or ignore the cold reception that Vista has received. Sinofsky identified a few key things that caused problems. First, the Windows “ecosystem”, the third-party software, hardware, and user training, wasn’t ready for the extensive changes that came in Vista. The driver model changed, which caused lots of hardware headaches at launch. The User Account Control (UAC) feature broke applications and frustrated users who hadn’t seen the behavior in Windows XP."

The idea of an "ecosystem" seems a good one to me. While Windows probably has a bigger ecosystem than just about anything else, its a feature of any software or website these days that it will need to interact with other systems. For example in a website, you want it to:

• be searchable by engines
• provide permanent links for bloggers or other websites,
• provide RSS feeds or email alerts,
• work on a variety of browsers (including those favoured by customers with disabilities),
• Be bookmarkable by de.icio.us, Digg.it etc.

The days are long gone when you can consider your website as your own little island, accessed through the home page.

First impressions and half-done work

I have been reading about first impressions recently, and thinking some more about wireframes.

First impressions and snap judgments can be powerful and profound, and seem to be able to reach conclusions inaccessible to logical thinking. In Mind Over Matter (an article in Intelligent Life magazine), Helen Joyce has a lovely introduction to the subject:

"Set down all the Reasons, pro and con, in opposite Columns," wrote Benjamin Franklin in 1779 to his nephew, who was attempting to choose which of two women to propose to. "When you have considered them two or three days ...observe what Reasons or Motives in each Column are equal in weight, one to one, one to two, two to three, or the like, and when you have struck out from both sides all the Equalities, you will see in which column remains the balance."

If you have been faced with a difficult decision--which house to buy; whether to accept a posting abroad--you may have done something similar yourself. And you may have had the following strange experience. You listed, you weighed, you calculated the answer--and, in a flash of insight, you realised it was the wrong one.

Did you omit some small but vital factor from one of your Columns? And how on earth did your subconscious get it right so fast?"

I did once try the 2-columns method to balance two job offers (for which it was a miserable failure). My own experience is that I don't always even get to a calculated conclusion that I then decide is wrong - if there are a lot of "how do I feel about this.." elements I sometimes simply get bogged down in the analysis. Interestingly that is a complete contrast to, say, supplier selection exercises, perhaps because those tend to have large portions of quantifiable factors to stack up one way or the other. Using the 2-columns method for romances would almost certainly be a disaster - for example; Who to invite to the ball, Daphne or Velma? So let's see: Daphne is more glamorous and popular, but Velma is a lot more interesting and fun to talk to, and to be honest you like her better... soon you're floundering with how big a plus or minus anything is. Or even, which is it - a plus or minus? For example, Daphne, being the most popular girl in college may be swamped with offers and might turn you down unkindly; Velma is a good friend, does it risk that relationship if are you now asking her out as a date.. is that what you are doing? ..is that what you want? ... is that what she will want?--- but maybe she really wants to go to the ball and no-one has asked her...Arrg I'm panicking already and this is only a thought experiment! Sometimes the only way out is when the subconscious comes to the rescue with a flash of insight - perhaps a really unexpected one such as the realization that actually you're gay and it is really Fred you want to be with, or that the ball is a boring cattle market for the college dating game and you'd rather go bowling with Shaggy and Scooby.

Also on my reading list recently has been Blink (by Malcolm Gladwell) a popular book on the same subject ("those moments when we 'know' something without knowing why" in the words of the blurb on the book). It gives examples of the power and perils of relying on this ability. For example, art experts were able to tell at a glance that a statue was a fake, even though they could not explain what led them to this conclusion. The ability can lead to bad decisions however - for example Warren Harding, whose appearance was extremely presidential was duly elected president of the USA but became president but proved to be ineffective as a leader. Various psychological experiments show that the "blink" ability can be subconsciously influenced. But people can learn to use their "blink" abilities more effectively, or create situations where their snap judgments are more likely to be helpful than distracting.

Blink has a chapter "Kenna's Dilemma" concerns cases where market research (usability testing, in effect) produced misleading results, or ones at variance to other studies. It begins with the predicament of a musician, Kenna, whose music appealed strongly to music industry professionals and dedicated concert-goers, but scored poorly in market research exercises that involved trials on a wider cross-section of the public. The predicted lack of a wide appeal made it difficult for Kenna to secure a record deal, despite the enthusiasm of music industry professionals for his work. Another case is that of the Aeron chair, which at the time of its introduction was a radical new chair design. During trialling, customers said it was ugly, but the manufacturer persisted in making it and it was soon regarded as a design classic. In these two examples, Gladwell suggests, test subjects were unable to give helpful feedback, because they were being presented with something very novel, and were unable to order their first impressions. People who were more expert (music aficionados, chair designers) gave different reactions because they could see beyond this novelty. This also reminds me of an editorial I saw at the point when the publication was introducing a new design. The editor was opining that readers would initially complain, but would in time come to regard the design as a classic and would complain about its replacement (previous designs had gone through exactly that cycle, apparently). I remember thinking that this was probably true, but that the Editor came across as arrogant and pompous in pointing it out.

Recently I came across the proverb "Fools and bairns should never see half-done work" ("Bairn" is Scots dialect for child). This is a similar idea - that people without enough experience can't necessarily extrapolate the finished product from seeing just a stage in the process. It seems rather harshly put to me - I certainly don't think you have to be a fool or a bairn to find it difficult as often it takes experience and training not to be a "fool and bairn". For example, I remember hearing in a radio documentary a snatch of the demo version of Space Oddity by David Bowie. If I remember correctly, Mr Bowie sings to an acoustic guitar which simply strums out the chords. I recall being mainly struck by how different is sounded from the finished work, and how difficult it was to imagine how the eventual song would sound. Probably it would have been one of my many failures to spot potential if a record company had been insane enough to hire me as an A&R man. Nowadays DVDs often have "deleted scenes" and documentaries about "the making of.." - and these provide lots more examples. It is interesting both to see how things are tried out cheaply at first (for example with storyboards if it is an animated feature) and how things can be fully worked up, at great expense probably before it is realized that they need to end up on the cutting-room floor.

Like Mr Bowie setting out his ideas just with the guitar, or Pixar Studios working with storyboards, we use wireframes to give a basic impression of early ideas, and so have to try and deal with the "half-done work" problem. This can led to the issue that I reviewed a while back - Test users sometimes have a hard job of focusing on what you want them to think about: I quote Chris Heillman:

"If you use Lorem Ipsum the testers asked what language that is and why it was allowed there. If you use copy nicked from other sites or made-up by a copywriter user names or headlines make testers judge the site by this and don't see it as just a demo of what can be done. "

Along with testers who don't mentally supply any extra work to imagine the finished article from the "half-done work" there is the risk that people extrapolate wrongly - there is some error or misunderstanding in what you are showing them but they don't point this out, because they imagine that it is a problem that will automatically be fixed as the work gets completed.

Wireframes are often quite deliberately "half-done" in another sense. If you consider that every website (or printed work) has:

• Structure (e.g. how many pages and what is on each page?)
• Navigation (how are the pages ordered or connected?)
• Aesthetics (how to make it look nice, fit with the brand values, be legible etc.)
• Prominence (how to make things stand out where appropriate)

...we are often trying to put aesthetics and prominence completely to one side, so as to try and get the structure and navigation right. I have ordered it S-N-A-P not only to get the acronym "SNAP" but because structure and navigation seem to go tightly together (logic, order; left-brain in pop psychology; the province of the Information Architect), with aesthetics and prominence as another pair (creative, artistic, right-brain; the province of the Web Developer). However, this is artificial as humans normally interact with both the logic and the art of a finished page, without thinking much about these distinctions. In explaining aspects of electronic publishing to conventional publishers, I have come up with some ways of helping people to unpick this. In a presentation called "What the Hell is XML?" (available here as a pdf file) I use the approach of showing people a web page in a language I don't expect them to be able to read (Welsh in this case). This puts them in the same position as a computer, which can just read an interpret the tags, not the "#PCDATA" (typing that is not tags) that humans seem to like so much. Another good demonstration is to show people a newspaper in a language (and preferably a script) that they can't read at all - this forces people to rely on the design conventions of newspapers (e.g. the lead story goes on the front page with a big headline; key lines bind illustrations to their captions, and images appear near the story they illustrate). Discussing things like these can help people prepare to control their first impressions when looking at your "half-done" wireframe, and be better able to tell if their "blink" response is helpful or a distraction.

And with that, I am off on holiday and will try not to think about wireframes at all for a while. But I might take some Kenna on the iPod and see what I think..

A "requirements" rope trick

Requirements analysis is the bit of a project when we figure out what has to be done to complete the project successfully. It is not easy to do well - often some of the requirements stand out very clearly, but others are not uncovered without a lot of thought and effort. I have written a couple of serious posts about this: "Requirements analysis" and "How to choose a solution" . In this post though, I will write about a puzzle that would do as a good warm-up exercise for a training session on requirements analysis.

Here's the puzzle - you put a piece of string or cord (about 40 cm long) in front of someone and tell them that they must:

1. Pick up the string at each end
2. Tie a knot in the string and then put it down
3. They must not let go of the ends of the string at any point
4. They must be able to put the string down completely when finished - it can't be looped around their hand or arm, for example.

If you want to try this for yourself don't read any further until you have had a go - next I am going to reveal secrets.

What most people do is to take the left-hand end of the string between their left finger and thumb, and the right-hand end of the string between their right finger and thumb. But now they have three problems.

1. Firstly, many knots require you to pass the end of the string through some other part of the knot and now you can't because you are holding the ends and mustn't let go (rule  1). 
2. Secondly, it is now hard to introduce twists or loops into the string without getting tangled.
3. Thirdly, unless you are unusually dexterous with your fingers or other parts of your body, you will probably need your fingers and thumbs to tie any kind of knot. So you shouldn't have used them for holding-the-string duties...

The requirements analysis point is of course that we could, in principle, have thought this through before tying ourselves in knots (literally in this case!). But it is much easier to see where you are going wrong than to anticipate the problems arising from a particular course of action.

The model solution is to fold your arms before picking up the string and keep them folded while picking it up. This causes you to pick up the left end of the string with the right finger and thumb, and the right end with the left finger and thumb. As you unfold your arms, you introduce a neat knot into the string, which you can then put down.

There are other solutions - some knots (such as the Overhand Loop knot) don't require you to let go of the ends  - maybe you can pick up the string with your little fingers. and have enough fingers (teeth? toes?) left to tie the knot.  Another interesting solution (is it cheating?) is for me to pick up my string, and ask you to tie a knot in it with the agreement that I will then reciprocate.
   

"Doing a Scotty"

A colleague on one of my projects has an excellent phrase "Doing a Scotty" to describe a certain kind of human behaviour sometimes seen on projects.

Many of us remember Mr Scott, the Chief Engineer of the Star Ship Enterprise in the original series of the Science fiction TV show Star Trek. Mr Scott was noted for reacting angrily to the Captain's unreasonable demands to fix things, generate more power or speed etc., typically saying things such as "I cannae break the laws of physics, Captain!" Then of course, he would find a way to do so, and the characters of the show would escape in the nick of time. In the show of course this was just his lion-hearted obsessive genius. However  "Doing a Scotty", "Pulling a Scottie" or the "Scottie principle" means deliberately over-estimating the time or difficulty or personal sacrifice to do some work, in the hope that the boss will be delighted to get it in the reasonable amount of time.

Just to head off a certain kind of comment - no sensible person would think that "Doing a Scottie" is a behaviour or attitude that is associated with Scots people more than any other bunch. (And Scottie terrier dogs won't do  what you tell 'em anyway. )

Poka-yoke II

A while back I wrote a post about poka-yoke, the design concept of "mistake proofing": making things so that mistakes by the user are impossible, or are at least detected  before any harm is done. I have occasionally been looking for software examples. I wanted to find ones that were clearly mistake proofing rather than good usability in any more general sense.

A nice example, I think, is afforded by the "confirm" dialogs that many applications offer. For example if you delete a file, a lot of applications first ask you to confirm that this is really what you want to do, even though there is no reason other than poka-yoke to ask you to confirm. You have after all already issued a valid and complete instruction with which the application can comply without seeking further instructions.

The figure "pokayokeconfirm.jpg" shows an example of a confirm dialog from Microsoft Word 2003.
Download pokayokeconfirm.jpg
The scenario here is that I have asked Word to alert me to the fact that my document contains tracked changes. When I save the document, therefore, Word checks that I want to proceed. (Out of interest, I have it set this way to avoid me muddle-headedly sending out tracked changes information beyond the circle of people who should be allowed to see it; for example where this would accidentally allow someone outside the group to see how an internal negotiating position was reached). Inspect the image of the dialog box pokayokeconfirm.jpg closely, and you will see that there is a further level of poka-yoke. By default the button that is active is the one that will cancel my save. Similarly, dialogs that ask you to confirm a file deletion often (but not always) have the "No" option highlighted, thereby hoping to save the inattentive user from disaster. If I simply hit Enter without reading the dialog I make the lesser mistake of the possible ones.

Conversely, my second example Download pokayokesave.jpg is what Word does if you try to close a new word file that you have never saved. Note that the dialog Word offers me has "do you want to save - Yes" highlighted by default (again, highlighting by default the poka-yoke option).

There is a balance here of course - it would be annoying and poor usability to ask users to confirm every darn thing they want to do; asking the user to confirm needs to be kept for situations where the wrong choice is regrettable. Which means that the challenge is to correctly anticipate what users will regret doing....