Skip to main content

Software as an Enabler

Over my long, somewhat protracted software development career, I have come across many situations of what I like to call "software as a disabler". Situations in which the software seems to work against the end user using arbitrary constraints or limitations that, to the developer, make perfect technical sense. This phenomenon is perfectly summerised by Little Britain's famous catchphrase "Computer says no".

How many times have you used software that just wouldn't quite let you do what you want to do? A lot, I would wager. Problems such as these often occur due to over-ambitious implementation of requirements, usually at a very technical level. Consider a simple calendar application for scheduling meetings. It makes logical sense that users would not want to be double booked, so a naive developer may put in a constraint that prevents such a situation from occurring.

The hapless end user comes to the software. They have a meeting scheduled with a client on Thursday between 2pm and 3pm. Another meeting opportunity then comes up with another client that can only be between 2:30pm and 3:30pm on the same Thursday. Clearly there is an overlap, and the user would be double booked during that time. The user attempts to enter that meeting, and the system refuses. No matter what the user does, they cannot enter two meetings that have conflicting time slots. The developer has "helped" the user by preventing the situation from occurring.

The end user now has a problem. He knows three facts:
  • He has a meeting between 2pm and 3pm that he cannot reschedule right now
  • He has a meeting between 2:30pm and 3:30pm that he cannot reschedule right now
  • The system won't let him do this, even though he is capable of fixing the problem if he were just allowed to
What often happens in situations like this is that the end user is forced to work around the software. Maybe he sets the meeting to run from 3pm to 3:30pm, and makes a note that it should really be 2:30pm. Maybe he arbitrarily deletes the old meeting and has to make a note elsewhere to contact the first client. Anything he does at this point would be purely for the sake of the system, and not help his real situation in any way. He cannot cancel either one of them at the time because it requires speaking to each of the clients, so he just wants to get the info there and have the time conflict visible. He just wants to put his data into the system the way he wants to. But the computer says no.

The right way for the developer to handle this would be to simply allow it, and have the user interface reflect the double booking. Maybe it would just show a message before adding the data. Maybe it could show the two events occurring side by side (Outlook does this), or it might show the overlap period in a highlighted colour to indicate that a conflict occurs. Anything, in fact, that lets the end user input the data he wants to and see it again later.

This is software as a disabler. Software that projects the developer's assumptions about the "right" way to use the software and forces the end user to conform. Sometimes this is necessary. For example, highly sensitive banking systems or insurance systems might need to put a stop to invalid situations before they occur. Even then there needs to be a system to handle the possibility that the real world might not represent the ideal held inside the computer. This is what software as an enabler is all about. Enabling the user to reconcile reality with what's stored inside the system.

So next time you're building an interface to a system, and you come across a constraint that you think would make sense to protect the end user from themselves, stop and think. Would your change actually provide any solid benefit, or would it just be there to make your life easier by ignoring the possibility that reality is not as perfect as your system requires?

It is a lot more work to allow invalid data to be entered and reconciled, but in the end, that's what the system is for. If the user has to perform all reconciliation work before entering the data in the first place, then your system will be viewed by your users as a waste of time. It would just be an extra step of manual labour to get the data into storage, with no added benefit. It has failed to provide the user with an efficient, possibly automated way to achieve a goal. And if your software is preventing users achieving their goals, it will be consigned to the Recycle Bin.

Comments

Popular posts from this blog

Another canal walk

The sun has started being a little more present lately, so some mornings are actually quite pleasant. On one such morning I decided to have a wander up the canal.


The clouds made everything look a bit Toy Story, and the low sun gave a lovely light and contrast to everything else.


Of course, it wasn't sunny everywhere. But even in the darker places, such as right underneath Leeds railway station, the sun had a go at peeking in.


Leeds Hyperbeastly

It's been five long months since I posted anything to this blog. Including this post here, I have posted no less than three times in 2014. As you can tell, I am nothing if not prolific.
A lot has changed since the last time I posted anything. I sold all my SLR gear, for a start, and switched to micro four-thirds. I got a lovely, lovely little Olympus OM-D E-M10 and a small selection of lenses including the must-have Panasonic 20mm f/1.7 pancake and the stunning Olympus 45mm f/1.8. Marvellous, and the camera, four lenses and spare batteries and SD cards in a bag that wouldn't fit the SLR and a single lens. Cracking stuff, because it's now small enough to carry all the time. In fact the body and pancake lens is barely bigger than my Fuji X10 compact!
Anyway, the point of this post; I've taken several walks through Leeds while I've worked there over the past few years and I've been finding it more and more difficult to find non-boring subjects. Everything is so dr…

Shooting the Enterprise

I was recently asked if I could help out providing an image for a magazine article about stress management. For reasons as yet undiscovered the requested image would be of the USS Enterprise flying through a storm in space. Unfortunately I didn't have a lot of time (just a couple of hours), but I did have a very nice model of the Enterprise D I could use to build the image around.

Thinking fast, I rigged up a rather slapdash rig consisting of a black reflector backdrop, an umbrella and stand from which dangled the model by a thread, and a couple of strobes. One light above, diffused, to provide the key light, and another, reflected and lower power, to fill some of the very dark shadows. It ended up all looking something like this:


Using a fast shutter, f/16 and cunning flash positioning I managed to keep the background black and give the model suitably textured lighting so it didn't have that flat, uniform, shadowless appearance of, well, a model. The narrow aperture obviously…