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:
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.
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
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
Post a Comment