Usability Notes - by Chris Baker

Thrashing numbers and the thirteenth task

Some tasks fit into an awkward sort of "squeezed middle". If something is quick and simple to do and doesn't disrupt the rest of life too much, you might as well get on and do it. Urgent tasks are usually not too hard to remember to do and to get on with, and long tasks are readily handled by putting the into your diary. In the middle are tasks that you need to do, but can't do easily find time to get around to. So they build up. That in itself starts to cause a problem - it's much more bother to have twelve 10-minute tasks than one 2-hour task. That's because there is an invisble 13th task ("keep track of all of the 12 tasks"). The mental pressure of feeling there is a lot to do can be very unpleasant - even  if it's "a large number of tasks to think about" as opposed to "many hours of work"  

Somebody once told me that old-time mainframe computers had a problem like this. They had to cope with prioritizing tasks for many different users. So the computer would run a program which would decide the best order in which to do the tasks. But of course that choosing program itself needed some of the computer's resources. As more and more tasks piled up in the queue, the computer could get stuck allocating more and more of its resources into deciding what to do. Endgame is that ALL the computer's resoures are going into trying to decide what to do next, and the computer has had a sort of digital nervous breakdown. The number of tasks that would cause this was known as the "thrashing number", I was told. To prevent this from actually happening, the computer would be programmed to change its behaviour as it felt the thrashing number approach - move from doing the tasks in the most efficient order to just doing them: get the length of the queue down any old how, until the situation improves enough to think about efficiency instead of survival again. 

Something similar can help for people too, I think. If you normally take some care over prioritizing but have ended up "thrashing", it can be helpful just to let that go sometimes and reduce the queue: do the thing that is bothering you first. Or, do the small things first; or just do things in any order to get life more simple again so you can think straight.

To avoid things getting that bad, it's helpful to set aside a fairly regular "thrashing hour" in which you work through as many of those inconvenient-sized tasks as you can. OK, it's something of a misnomer as the idea is to prevent the kind of behaviour which was "thrashing" for a computer. But "2pm Friday - thrashing hour" is such a satisfying thing to write in the diary.

van Gogh stops the Machine -- a paradox of virtual experience

The Machine Stops is a well-known science fiction story by E M Forster, written in 1909. Forster imagines a world where people live in solitary rooms; technology meets all their wants and needs well, and travelling or meeting anyone face to face is seen as inconvenient and tedious. Of course, then things start to go wrong... Its a really good story, as well as being of interest as classic dystopian story raising worries about over-dependence upon technology and the substitution of direct experience for virtual ones.

For some time now it has been possible to live as a cyber-hermit if you want - in 2000-2001 DotComGuy (born Mitch Maddox) lived for a year without venturing outside his backyard - ("The experiment was supported by corporate sponsors who wanted to persuade more customers to shop on the internet"). Such an existence would be massively easier and more convenient now, 11 years later.

But I also notice another trend. Bands from every decade of my life are reforming and touring (unless, like  the Rolling Stones, they never left the road) and tickets  can cost far more than buying the artists' entire discography. There seems to be no shortage of people who want to go to other bug events, or to travel to exotic holiday destinations. And when they get there, the emphasis seems to be as much (or more) than ever about the direct experience you can have.

So I wonder whether there is something going on a bit like "the paradox of automation". "The more efficient the automated system, the more crucial the human contribution of the operators. Humans are less involved, but their involvement becomes more critical." (Because if things start to go wrong, the machine which normally turns out 100 perfect components a minute will start turning out 100 pieces of junk per minute until the humans intervene). My thought is that, the more experiences can become virtual, the more important or valuable become those experiences we choose to have directly.

I was thinking about this because of a recent family trip to Amsterdam to see the van Gogh museum. That was something we all enjoyed, even though it is easy enough to see most of Vincent's work in books or online at a fraction of the cost and time of a trip to Holland. True, you can't yet get reproductions that show you all the details (such as the texture caused by brush-strokes or a palette knife), but even if, as I expect, complete VR facsimile is possible before too long, I think we'd still have wanted to have gone in person.

 

The Prioritizing Grid - as a project tool

When deciding requirements for a project, we're often trying to decide priorities between many items. This rapidly becomes difficult to do in your head ("or in your heads" in a meeting). Here's a useful tool, the prioritizing grid.

It originally comes, I think, from Richard N Bolles, author of "What Color is your Parachute" (a manual for job-hunters and career changers). Career counsellor and consultant Beverly Ryle has an interactive version on her website. The original purpose is to rank skills that a person has (e.g. "I am good at writing and also at cooking, particle physics and  kung-fu, but which of these do I like doing best?"). In its original context it is part of an exercise to help identify careers that a person is likely to find they'd enjoy. But the system could be used for prioritizing any kind of things - here is a screenshot of it in use to prioritize features of interest when choosing a car.

The way it works is that you write out the things you want to prioritize in any order, and number them 1-10 (if there should happen to be 10). In the screenshot, the un-prioritized items are listed on the left. Then you work through them in pairs like this:

• Which do I prefer, 1 or 2?
• Which do I prefer, 1 or 3?
• Which do I prefer, 1 or 4?

Once done with number 1, you do the same  with 2:

• Which do I prefer, 2 or 3?
• Which do I prefer , 2 or 4?

and then you move onto number 3:

• Which do I prefer, 3 or 4?
• Which do I prefer, 3 or 5?

...and then with each of the other factors until you reach the last pair.

It sounds cumbersome, but actually does not take at all long, unless you are over-thinking it, or need to define the factors better, or have a lot of items that you don't care about much.

Once you're done, you go through each  factor and you count up the number of times you preferred it to something else. This gives you the rank order.

In the screenshot example I've done that (the website has pairs of radio buttons to indicate your choice, but you could of course do this on a piece of paper....). On the right of the screenshot you see the priority order that this generates. It looks like I want a car that seats 4 passengers, has plenty of boot ("trunk" to US readers) space, is cheap on fuel and hard to steal (family life in Oxford...).  

As with anything else, I'd say "don't let the tool take over". Perhaps you don't really have a preference between a pair, or can't answer until  the items are better defined. Either of those discoveries could be useful - probably more useful than forcing everything artificially into neat priorities in order just to get the worksheet done.

Reviewing your unwritten plan

How often do you join a project and find that the documentation tells you all you want to know? Yep - never works completely for me, either. In "Your Crucial - and Unwritten - Plan"  (Linda Hill & Kent Lineback - Harvard Business Review) the authors give one important reason for this - our written plans are rapidly supplemented or superceded by a  constantly evolving unwritten plan. It' not just that most of us don't make the time to update our written plans at every twist and turn - the unwritten plan is a different beast altogether:

In sum, a written plan covers only those portions of your thinking that are clear, specific, focused, thought-through, and ready to go public as a formal (and often official) document bearing the title "Plan." Unwritten plans consist of your and your group's thoughts — ranging from vague hunches to roughly-written ideas — about the future and how all of you will create it. Formal, written plans are prepared at key points, while unwritten plans are living, dynamic possibilities that constantly change as you learn more from experience and carry on discussions with your people and network.

(From Your Crucial - and Unwritten - Plan  (Linda Hill & Kent Lineback - Harvard Business Review, 10 May 2011)

In that case, I was thinking, a key point is to take time to review and evaluate your own unwritten plan. Writing the darned thing down, while time-consuming, might help - it allows you and others to critique it, and allows one to step back from it. The unwritten plan can readily become one that is obsessed by the next milestone, or fatally discounts a certain risk or suffers from other forms of myopia. But a periodic write-up may not be the whole solution - vague feelings of unease about something can be too nebulous or personal to put into a formal plan (especially if it is to be shared), but can be a really useful indication of trouble ahead. Time out to think about things seems the only way to review the unwritten plan - hard to achieve in today's busy working lives (I used to find my cycle ride to work or a lunchtime walk very useful for this).

 

Facebook "friends" and what to call computing concepts

I've recently come across a few newspaper and radio items about Facebook "friends" not being friends in any older sense of the word. The usual observations are that you can have many more Facebook friends than you could have conventional friends; that Facebook friends may include people you don't know in any conventional sense; and that your Facebook friends may not behave in a way that friends traditionally ought. (The last point comes up, for example, in reports of tragedies of people posting suicidal messages on Facebook, but no-one responding seriously).

This is not another one of those articles. Let's take it as settled that Facebook has coined a new sense of the word "friend". Computing often does that  - "mouse", "menu", "password" are examples. When co-opting any word from the real for your interface, the existing resonances are a two-edged sword -  from the name, users may "get" what this function is for, or they may (like the journalists decrying "friends") "get" something else. But it's that or invent new terms ("dongle"), or use old words in a bizarre way ("tweet" in Twitter).

There are a number of usability issues too (and "friends" does well when you think about it in these ways):

• If the term is going to appear on interface buttons, breadcrumb trails etc. it is useful if it is short (so "friend" is better than "aquantaince" - whcih in any case sounds stuffy and posh, so should probably already be rejected on resonance grounds)
• Helpful if the word is easy to spell and to say, so that customers can re-use it easily (so, again, "friend" is better than "aquantaince")
• Use words that will be understood internationally, if you seek an interntaional audience ("Mate" instead of "Friend" might work in the UK or Australia, but perhaps not in the US. "Buddy" the converse, perhaps).
• Avoid words that already have any confusing senses ("Mate" instead of "Friend" might alarm non-native speakers looking it up in a dictionary)

I don't recall other adopted terms ("contacts" in Linked in, "followers" in Twitter) causing as many column inches as "friends" though. Perhaps "friends" is particularly redolent a term, or just particularly useful for "we-are-all-going -to-hell-in-a-bucket" journalism ("Young people today, their "friends" are not friends - In my day...."). Well, in the words of the Grateful Dead, "I may be going to hell in a bucket, babe / But at least I'm enjoying the ride"

Beware of Wantum Computing

I enjoyed the idea of "wantum physics" and think we could usefully have "wantum computing".

By "wantum computing" I don't mean quite the same as "wantum physics". Wantum physics is  fictitious science made up by a science fiction author, to do what is wanted to further the plot. "Lithium crystals", "flux capacitors" and "midichlorians" spring to mind. By wantum computing, I mean computer technologies that are in that tricky gap when the potential benefits have become clear enough for organizations to "want 'em", but there's still a substantial risk that the benefits can't actually be delivered. So a project is tried and overruns badly or has to be abandoned.  Or (perhaps more sadly) the project is completed and released to baffled or indifferent users who don't think they have a problem for that solution.

It's usually a matter of jumping too early ("making a wantum leap" I suppose). "All of this has happened before and it will all happen again." In the 1990s, many publishers invested in CD-ROM publishing, expecting a move to electronic formats from print. That shift is even now under way (it has gone a long way if you are a scholarly journals publisher, nowhere near as far if you are a fiction publisher now moving into eBooks). Then there was the dot.com boom just before the millenium- massive investment on the promise of a big shift to online eCommerce and marketing. Well that did happen, arguably is not complete yet, but took longer than the enthusiasts thought. 

CD-ROMS, dot.coms, "Web 2.0", Cloud computing... in each case there were (or are) early success stories, to enthuse and frustrate those who made the wantum leap a bit too early:  for whatever reason they didn't turn out have the right combination of factors to break new ground successfully.

Objections

"[Objections] are part of the nature of the very conservative society we live in. When new ideas come up they are scrutinised for perfection. If that perfection is not found, they are rejected for the status quo, which if scrutinised in the same way would fare much worse."

I saw this quote in a newspaper article about the pros and cons of changing UK time to match the Western European mainland, but applicable widely beyond that, I think. The quote is from Dr Mayer Hillman, author of a number of clock-change studies over nearly 30 years. 

Do we under-use routine?

When did you last forget to brush your teeth? My guess is that is is not something you forget unless something extraordinary is happening (or you have no teeth....). It's good to have a routine to handle teeth-brushing (and other aspects of getting up) so that you don't have to expend much mental energy on them.

At work, routine has a bad reputation. The lack of expenditure of mental energy can backfire. We think of the weekly meeting that is too often a waste of time - it happens out of habit rather than because it has any useful purpose this week. We think of routine as boring and repetitive and want our lives to be full of varied and exciting tasks every day ... at least until we have to manage the resulting workload.

I was thinking about this because I've found myself getting into the habit of putting a lot of repeating tasks on my to-do list. That works OK, but leaves me needing to expend a bit of mental energy deciding when to fit them around the rest of the day's tasks (or week's tasks). It also makes for a tediously long to-do list, which isn't so nice to look at when feeling busy :-).

Maybe I need to think about some of this stuff the other way around, and make more use of routine to clear the regular tasks. It seems odd, because typically they are less important than the rest of the weeks work. So one would think that the thing to do was put them in the to-do list at low priority so as to fit them around the variable stuff. But possibly the benefits of not needing to think about routine items outweigh the theoretical benefits of making more prioritization decisions.

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.