Text editors and electric kettles
A few weeks ago I was asked to meet with a company that is selling a software product for doing hospital management. On first glance the product seemed nice, truckloads of features and modules in a fairly clean layout. But there was something wrong with it, something I couldn't quite put my finger on. A few weeks and this blog article later, I figured it out - the application is too close to the text editor side of the user interface spectrum.
The text editor is the most powerful computer application that exists. With it you can write a novel that starts a revolution, create a system to organize recipes, write code that can create a different text editor or a new operating system - the possibilities are truly limitless. On the other end of the user interface spectrum would be something like an electric kettle. You pour water in it, you press a button and it brings water to a boil before turning itself off. If you were really creative you might manage to cook soup in it, but you wouldn't do this because it would probably ruin all subsequent attempts to boil water. The electric kettle does one thing only, it requires very little training and it performs it's task to perfection.
I think all user interfaces land somewhere on the spectrum between text editors and kettles, and the goals of an application should dictate where on the that spectrum the application should land. Problems occur when an application lands on the wrong part of the spectrum.
I think this is the problem with the application I saw yesterday. Lets call it "boxware", because it had a lot of boxes. In fact boxware had boxes everywhere, and each box more or less represented a new feature, even if it was just a box. Let me explain. After clicking on the patient registration icon a screen pops up with a lot of little boxes, one for last name, first name, address, city, phone number, and so on. There is also a box with three tabs in it, patient history, family history, other history. Almost any kind of data you would want to capture has a box for it, and if you don't see it, then the required box is probably behind a tab or another icon.
Interfaces like this are common, and for good reason. This kind of user interface is the path of least resistance for software developers. Any new feature simply requires a new box, which is created by drawing a new box into the software development tool. The new box gets labeled "surgery management", which is usually enough for the decision maker to tick off "surgery module" from their required feature list. When this happens, the software developer wins and the decision maker is pleased at having found a system that matches their requirements. Unfortunately the users and in this case, the patients are the losers. Just because a bunch of labels on boxes happen to correspond to some important activities, there is absolutely no guarantee the boxes will be used for the intended purpose. I can count a dozen different repurposed boxes and containers on my desk alone. If only I knew what was in them!
I have seen many boxwares, and they often have a common origin: a single person uses MS Access (or Foxpro, or whatever) to computerize a process. Often the end user and the developer are one and the same. Adding features is easy (just add a box, or a database column or a tab) and before long the system is fully featured and easy for the user/developer to use.
If the system is useful, then other people want to use the system. This is a nice problem that gets solved with...training! But soon, the developer notices that users keep using the system in a way that was totally unexpected. Time for another training session...
But there is another approach that doesn't rely on training. They are called constraints.
Let's think about the constraints of kettles and text editors. An electric kettle is constrained to heat liquids and is either off or on - not much training required. A text editor requires dozens of keys and key combinations just to do it's primary function of editing text. It doesn't constrain the user at all, and if you have ever taught an absolute novice how to use Microsoft Word (think grandma, or a nurse in a rural health clinic in Africa) then you know that training is not easy. Lack of constraints are even more apparent when people use text editors to model the more complex human processes of organization or collaboration.
The amount of training required is usually inversely proportional to the number of constraints in the system.
Constraints do two things, they filter garbage and they guide processes.
For example, an application may allow you to enter a weight value for a patient. A simple box will do just fine. But a user could type in No ("Why would I want to wait?"). Or they could type in 2 (is that pounds or kilograms?). Or they could simply not click on the box at all (whether a user knows how to use mice or keyboards is beyond the scope of this article).
Constraints can put ranges on what is allowed in the box - anything outside of that range will get rejected. So we could say that all patients must weigh between 2 and 300 (and make it explicit that we are talking about kilograms). But constraints can be even more clever. If we know what the patient's age is, we can narrow that band or even better, if we know what they weighed a month ago, then we can assume that their weight is plus or minus 10% of their last weight. If the user entered something that is outside of that range they will immediately be warned or perhaps even stopped. Maybe they typed in an extra 2, or they were entering data for the wrong patient, or they were reading pounds instead of kgs. Range constraints can catch that, they filter garbage.
Besides data validation (garbage filtration), constraints can also guide processes. Process guidance is a powerful way to move your application towards the appliance end of the spectrum. Instead of having a bunch of boxes that can be clicked on in any random order, an application can hold the hand (or mouse) of a user and guide them step by step through the process. One question gets asked at a time, in a specific order that matches how the user thinks or acts. This is the wizard approach that Microsoft has successfully used to help people navigate complex processes like setting up networks. And like data validation constraints, with a little bit of logic, the step by step wizard approach can add extra cleverness as well. For example, if you have a question that asks if the patient is pregnant, you could first make sure that their sex and age are asked. If the patient is a 60 year old man, you can then automatically skip the pregnancy question - this makes filling in the form easier and faster. But wait! We can do even better! Since sex is a critical piece of data to know, you can make sure that the user can enter no other data until the patient's sex is known.
If you are creating an application that will be used by a lot of different people to do very specific things, then range contraints and process constraints are important tools to make users happy. They empower them without needing training and usually speed processes up. If we are talking about first time computer users capturing life or death information in Africa, then constraints are critical.
So next time you are evaluating software pay attention to the user interface - not just how pretty it is - but what it actually does. How does it guide the user? How does it ensure quality data? Who will it make happy? Is it a text editor or an electric kettle?
The text editor is the most powerful computer application that exists. With it you can write a novel that starts a revolution, create a system to organize recipes, write code that can create a different text editor or a new operating system - the possibilities are truly limitless. On the other end of the user interface spectrum would be something like an electric kettle. You pour water in it, you press a button and it brings water to a boil before turning itself off. If you were really creative you might manage to cook soup in it, but you wouldn't do this because it would probably ruin all subsequent attempts to boil water. The electric kettle does one thing only, it requires very little training and it performs it's task to perfection.
I think all user interfaces land somewhere on the spectrum between text editors and kettles, and the goals of an application should dictate where on the that spectrum the application should land. Problems occur when an application lands on the wrong part of the spectrum.
I think this is the problem with the application I saw yesterday. Lets call it "boxware", because it had a lot of boxes. In fact boxware had boxes everywhere, and each box more or less represented a new feature, even if it was just a box. Let me explain. After clicking on the patient registration icon a screen pops up with a lot of little boxes, one for last name, first name, address, city, phone number, and so on. There is also a box with three tabs in it, patient history, family history, other history. Almost any kind of data you would want to capture has a box for it, and if you don't see it, then the required box is probably behind a tab or another icon.
Interfaces like this are common, and for good reason. This kind of user interface is the path of least resistance for software developers. Any new feature simply requires a new box, which is created by drawing a new box into the software development tool. The new box gets labeled "surgery management", which is usually enough for the decision maker to tick off "surgery module" from their required feature list. When this happens, the software developer wins and the decision maker is pleased at having found a system that matches their requirements. Unfortunately the users and in this case, the patients are the losers. Just because a bunch of labels on boxes happen to correspond to some important activities, there is absolutely no guarantee the boxes will be used for the intended purpose. I can count a dozen different repurposed boxes and containers on my desk alone. If only I knew what was in them!
I have seen many boxwares, and they often have a common origin: a single person uses MS Access (or Foxpro, or whatever) to computerize a process. Often the end user and the developer are one and the same. Adding features is easy (just add a box, or a database column or a tab) and before long the system is fully featured and easy for the user/developer to use.
If the system is useful, then other people want to use the system. This is a nice problem that gets solved with...training! But soon, the developer notices that users keep using the system in a way that was totally unexpected. Time for another training session...
But there is another approach that doesn't rely on training. They are called constraints.
Let's think about the constraints of kettles and text editors. An electric kettle is constrained to heat liquids and is either off or on - not much training required. A text editor requires dozens of keys and key combinations just to do it's primary function of editing text. It doesn't constrain the user at all, and if you have ever taught an absolute novice how to use Microsoft Word (think grandma, or a nurse in a rural health clinic in Africa) then you know that training is not easy. Lack of constraints are even more apparent when people use text editors to model the more complex human processes of organization or collaboration.
The amount of training required is usually inversely proportional to the number of constraints in the system.
Constraints do two things, they filter garbage and they guide processes.
For example, an application may allow you to enter a weight value for a patient. A simple box will do just fine. But a user could type in No ("Why would I want to wait?"). Or they could type in 2 (is that pounds or kilograms?). Or they could simply not click on the box at all (whether a user knows how to use mice or keyboards is beyond the scope of this article).
Constraints can put ranges on what is allowed in the box - anything outside of that range will get rejected. So we could say that all patients must weigh between 2 and 300 (and make it explicit that we are talking about kilograms). But constraints can be even more clever. If we know what the patient's age is, we can narrow that band or even better, if we know what they weighed a month ago, then we can assume that their weight is plus or minus 10% of their last weight. If the user entered something that is outside of that range they will immediately be warned or perhaps even stopped. Maybe they typed in an extra 2, or they were entering data for the wrong patient, or they were reading pounds instead of kgs. Range constraints can catch that, they filter garbage.
Besides data validation (garbage filtration), constraints can also guide processes. Process guidance is a powerful way to move your application towards the appliance end of the spectrum. Instead of having a bunch of boxes that can be clicked on in any random order, an application can hold the hand (or mouse) of a user and guide them step by step through the process. One question gets asked at a time, in a specific order that matches how the user thinks or acts. This is the wizard approach that Microsoft has successfully used to help people navigate complex processes like setting up networks. And like data validation constraints, with a little bit of logic, the step by step wizard approach can add extra cleverness as well. For example, if you have a question that asks if the patient is pregnant, you could first make sure that their sex and age are asked. If the patient is a 60 year old man, you can then automatically skip the pregnancy question - this makes filling in the form easier and faster. But wait! We can do even better! Since sex is a critical piece of data to know, you can make sure that the user can enter no other data until the patient's sex is known.
If you are creating an application that will be used by a lot of different people to do very specific things, then range contraints and process constraints are important tools to make users happy. They empower them without needing training and usually speed processes up. If we are talking about first time computer users capturing life or death information in Africa, then constraints are critical.
So next time you are evaluating software pay attention to the user interface - not just how pretty it is - but what it actually does. How does it guide the user? How does it ensure quality data? Who will it make happy? Is it a text editor or an electric kettle?