Don’t Do Evil to Users

vs “Your work will self-destruct in five seconds…”

With Delphi (or C#) it’s so easy to put a Timer to implement some Auto-DoStuff feature that you’ll find one in almost any application. No doubt it can be very handy; it might even be very kind for the user.

Now, please read again the previous sentence… I shouldn’t have to use “might even”; it should always be beneficial to the user, 100%, no exception, period! It is unfortunately not true. I even have an example of the opposite; it happened to me and I got pissed off upset real bad.

When a feature is too easy to implement, developers tend to not think through it: use cases, specifications, design are often shrunken or short-circuited because “hey, we can just do it”.

Consider an Auto-Save feature…

It must save the modified files, only those, and without writing over the real files because you might not want to keep these modifications after all, but you’d just hate to lose them. And it can be good to save multiple iterations. I would think of it as a combination of snapshot and Undo that can survive an abnormal termination. I had one old AutoSave expert that I ported to BDS2006, and it saved my work lots of times.

Now, what about an Auto-Close feature…

Web applications

If you are like me, you hate those half-baked web applications where you have a Form to fill out, but there is also a time limit and if you are not quick enough you’ll have to start all over again.

Bad. Especially if there is some open ended question or some free-form text to enter, and not even a warning when the timeout is about to kick you out, so that you’d have a chance to save your text in a Notepad on the side.

I can understand some security limitations as a reason for not being able to save the user’s labor, but still, everything possible should be done.

Rich GUI applications

In a previous life, I had to use an issue tracker application (bugs and change requests) that had been developed in-house. One teamwork problem quickly arose: when a developer had a CR form open, that CR was locked and could not be used by another developer.

The solution went swiftly: let’s put a timer to close any open CR. After 60mn, the CR would close automatically. This guarantees that it could not be stuck open if someone forgot to close it before leaving on vacations for instance (ok, extreme use case).
S(n)ide note: another example of a simple, quick and wrong solution to a real problem. It would have been better to manage concurrency properly.

What was to happen happened: when working on a bug, you go back and forth between the CR and the code and if you don’t force yourself to save after each modification, the CR will close losing your last unsaved edits. Some complained (yours truly included) and …

The fix went swiftly: let’s restart the timer whenever there is some modifications, giving the user 60mn to think about saving these modifications. This was an order of magnitude better in practice, due to this back and forth workflow.

But still, there are cases when you are interrupted and have to leave your workstation for 5mn that last in fact hours, like going to help someone tracking a bug or dealing with urgent support case. That’s also very likely to happen if you have to do some heavy multi-tasking.

Auto-Save vs Auto-Close, Good vs Evil?

I did put those 2 in perspective on purpose. In one case, you have a feature to alleviate pain to the users in the (hopefully unlikely) event something bad happens. On the other hand, you have a feature that is very likely to cause frustration and anger, not to speak about the loss itself.

How hard is it to understand that you should never ever let your users’ labor be destroyed even when accidentally and even more so intentionally? And, no, telling your users to “save often” is not good enough (I’ve heard it).

So, if you really need to implement an Auto-Close feature, think thoroughly about it, and at least implement some sort of Auto-Save as well before closing.

Your software is to make your users’ life better

That should be written in fire letters on the walls wherever developers are crunching their code.

As Joel Spolsky puts it, they use your software so that

“their selfish DNA will get to replicate itself”.

This entry was posted in Quality, User Interface and tagged , , , , . Bookmark the permalink.

4 Responses to Don’t Do Evil to Users

  1. Steven Kamradt says:

    Lets not forget the “auto-reboot in x minutes” that Microsoft has used in the past with some windows updates… never mind the fact that I might be connected to the machine remotely, actually to the VM that is running on that machine so I can’t see the message.

    I’m sure the intentions are always good, its the implementation that is flawed… and mostly for the case not thought about at the time. Sometimes those cases are so edge its not worth thinking about. Other times they can be very costly.

    For the update issue, I am thankful that VMWare responded to the WM_SHUTDOWN message and saved the state of the VM as the machine was going down. I’m also thankful that at the time I was not doing something mission critical that could not be interrupted.

  2. Uwe Raabe says:

    A collegue once used his notebook until the battery was nearly empty and Vista decided to shut down with no chance of a veto. Problem was that a bunch of updates waited to be installed during shutdown – bang! The notebook didn’t start any more.

    • François Gaillard says:

      Oooh, I hated this one when Vista decided to take 15 mn to shutdown my laptop when I wanted to get back home and missed my commute.
      But someone paid attention: you now have an < !> on the shutdown button in Win7 and you can even shutdown without installing the downloaded updates.

Leave a Reply to Uwe Raabe Cancel reply

Your email address will not be published. Required fields are marked *