‘Roughly’ and ‘better’ can help usability

In this article I’ll go into some fuzziness that we often encounter in the everyday world, that’s often missing in the world of computers. Unfortunately we’re used to this fuzziness, and so its lack can make computers hard to use.

Star Trek shields 

I remember watching episodes of Star Trek where the Enterprise was in danger.  Fortunately, the shields had kept the crew safe, but they were gradually failing. A crew member would call out to the rest of the bridge: “Shields at 78%!” and then later “Shields at 54%!” and so on.  Other than increased stress, the crew were perfectly fine while the shields were holding, but there were unspecified dire consequences that would happen if the shields went down to 0%.  I found this odd – things would be completely fine for much of the time, but then would switch from completely fine to absolute disaster as soon as 1% became 0%.  

As a diagram, it would look like this: 

Computers 

Despite the title of the blog, Star Trek is normally a little beyond the scope of what I talk about here, so why do I mention it?  I mention it because it’s unfortunately a contrast to what often happens when using a computer.  This is surprisingly widespread in my experience – both as a user of someone else’s code e.g. a website, or when I’m trying to write my own. 

I’m trying to do something, and fail.  It could be I’m trying to find where on a website I need to be to do something, or I need the particular sequence of punctuation etc. necessary to persuade my code to compile and do what I want it to. I try something else, and that fails too.  I repeat this a frustrating number of times, and eventually it all works.  

As a diagram it would look like this: 

The world away from computers and Star Trek shields 

Both of these contrast with what I think is a much more common experience in the world away from computers and Star Trek.  In this case, you can reach a solution that is roughly or partly right.  That is, outcomes that are e.g. 40% rather than only 0% or 100%.  You might not even know that it’s 40% rather than 30% or 50%, but you do often know that one partial outcome is better than another one.  It’s like the children’s game hotter / colder – someone is hunting for something that’s hidden, and if they walk towards it they’re told that they’re getter hotter, and if they walk away from it they’re getting colder.  They don’t know that they’re at 152.925K, but they do know if they’re hotter or colder than before. 

It’s similar to how people often navigate in a strange town or city.  They think to themselves: I don’t know exactly where I am, but I have spotted that cathedral that I recognise, so if I walk towards it (judged by it getting bigger) then I’m fairly confident that I will get to the bus station that’s by the cathedral.  The computer-y behaviour would be “Am I at the cathedral? No.” repeated many times as you bounce around almost randomly, until it’s finally “Am I at the cathedral? Yes.” 

This is a heuristic – according to Wikipedia an “approach to problem solving … that is not guaranteed to be optimal or perfect … but is sufficient for reaching an … approximation”. It might be that a river flows through the city, and to get to a bridge to cross it you’d have to go the wrong way (away from the cathedral). But this approach gives good enough results enough of the time, and is relatively easy to do (you don’t need to speak the local language, for instance, as you would if you asked for directions) so it’s worth trying. 

As a diagram the approach would look like this: 

 In abstract terms, this is using hill climbing to solve problems. 

 The key components are: 

• Solutions that are roughly right 
• A way to tell that one solution is better than another, even if they’re both only roughly right rather than fully right. 

UX (user experience) of production code 

Unless your system is very small, or all users will be adequately trained, or you have a search or help function that works perfectly for all users, it’s unreasonable to expect that your users will always know exactly where to go in the code and what to do when they get there.  So, users will have to navigate your code as they would in an unfamiliar city in real life.  How can you help the user be roughly right, even if they’re not fully right?  Do you have navigation menus, breadcrumbs etc. that help them get to a broad subsection or heading, and drill down from there?  Can they bookmark so they can create their own landmarks that will help them in future heuristics?  Does back / up etc. always do what they’d expect? 

UX for programmers 

One of the things that computers unfortunately drum into programmers through painful experience is pedantry.  Another is breaking a problem down into smaller and smaller chunks, solving the chunks when they’re small enough, and then repeatedly assembling several partial solutions into one bigger solution.  This is one way that the programmer can implement their own roughly / better.  The solution to a smaller part of the problem doesn’t solve all of the big problem, but you know you’re making progress towards it. However, sometimes there are chunks that are indivisible and give no clue as to how to solve them. 

If you’re designing a library, API, toolkit, framework or even language, I encourage you to think about roughly / better.  How many things are there that are the way they are “just because”? That is, they don’t follow patterns – either building up from simpler parts of the library or moving sideways from things that someone would feel are next-door things to the one you want. Similarly, think about the error messages and debugging tools. Can a programmer work out for themselves that the error message they’re getting now is better than the previous one? Or is the error message just a variation on “An error has occurred”? 

Summary 

Users are used to a world where there are partial solutions as well as complete ones, and also ways of telling which of two partial solutions is better than the other.  They have developed problem solving strategies that make use of these, and expect to be able to use these strategies when facing a computer-related problem.  Unfortunately, computers don’t always support these problem-solving strategies by default. So, it falls to the humans in charge of a computer to put in the effort to make the computer fit better into a human way of thinking.