Defense against the dreaded Klingon Battlecruiser

Introduction

This article provides an intelligent solution to a phenomenon known as the Klingon battle cruiser. To illustrate, create an empty document in VC++, then type "something" in it. Good. The Battle cruiser is coming near. Ok, just type CTRL-F4 on the keyboard and - voila! There's one right there.

In essence, KBC (Klingon Battlecruiser) is an annoying message box. All kinds of users with all kinds of computer background have to face numerous message boxes dozens of time every day.

Most users "dismiss" the message box automatically, as a reflex. Why read it?

It turns out that a study (sorry - I have no formal references) has shown that a lot of good folks out there reject the KBC on site, w/o reading it.

Background

I am writing an application that is used in the context of a security system. Users can put in a lot of work and the application offers a BACKUP - RESTORE command that interfaces with the underlying SQL SERVER database engine.

My boss, who happens to be the industry Guru, is one of the greatest KBC fighters. He never, ever reads any phrase with more than two words. He dismisses dialog boxes so quickly, he could win Olympic medals.

What was bound to occur has occurred. He "accidentally" restored a database instead of backing it up. Result: 1 day of work lost. It could have been worse.

Earlier this week, he went to some clients, setting up their systems using his laptop and backed-up client 1 database on top of client 2 backup. This time, the loss was closer to 4 hours. Lucky.

Then he figures that if he makes that sort of mistakes, others are bound to do the same.

Hence this article, describing a simple way to replace "easy" MessageBox(), that too easily dismissed.

Using the pattern

Basically, the proposed design pattern replaces the "easy to dismiss" message box with a modal dialog box that not only provides messagebox like buttons, but that contains an extra confirmation edit control.

Once invoked, it will return "IDOK" if - and only if the operator has typed the confirmation in the edit control. The idea is that to know what to type, the user has to go through the text first. Only by carefully reading the text will the user learn what the "confirmation word" is.

Points of Interest

What this Graphic User Interface design pattern suggests, is that simple message boxes are often not enough to allow an application user to confirm dangerous operations.

Application users with all kinds of computer literacy skills have learned to dismiss most message boxes as trivial, unimportant. They automatically hit ENTER or click on the leftmost choice without reading.

The modal dialog box with edit control does not register with the brain as a message box. It draws attention. The user is more likely to read the text and, more importantly, think about the consequences before confirming their action.

Comments and Discussions

In addition to words (as few as possible, and directly relating to the event), use animation! Some Windows messages already use it. For example, when copying a file, you'd see a sheet of paper flying through the air to an opened folder, or when deleting a file, you'd see the sheet of paper disappear with a little bang at the other end of its journey.

For something that would cause severe damage and destruction, show something like a stick of dynamite that would explode (as part of the animation message), in addition to the words of warning or advice. For something more benign (like only requiring the "OK" button to be pressed), show a finger pressing the "Enter" button.

The point is, you don't need to have your messages become vanilla to your users after a while, because even if they don't take the time to read what the message contains, you will have caught their attention by the animation (or at least by the animation picture) that will immediately communicate to them the KIND of message they are seeing. In a way, the picture becomes the message!