Click here to Skip to main content
Click here to Skip to main content

Defense against the dreaded Klingon Battlecruiser

By , 15 Apr 2004
 

Sample Image

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

Sample Image

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.

History

First release of this article in April 2004.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

About the Author

Bamaco2
Technical Lead
Canada Canada
Member
No Biography provided

Sign Up to vote   Poor Excellent
Add a reason or comment to your vote: x
Votes of 3 or less require a comment

Comments and Discussions

 
You must Sign In to use this message board.
Search this forum  
    Spacing  Noise  Layout  Per page   
GeneralFacing a Klingon Battlecruiser ...memberMaximilien16 Apr '04 - 0:54 
I wish I will not need to type in text confirmation ...
 
"C'ptain How do you spell "LOAD THE TORPEDO" " ?
 
I think it all depends on the level of "danger" that the operation will be.
 
Having clear, descriptive labels ( for the buttons and the message ) is enough for 90% of the time; as well as having the different warning logos.
 
Having a text confirmation is overkill for everyday confirmation, but for a really destructive operation that happens once every year, it can be acceptable. but on a daily frequency, I'm not sure.
 

Maximilien Lincourt
Your Head A Splode - Strong Bad
GeneralRe: Facing a Klingon Battlecruiser ...memberBamaco217 Apr '04 - 20:28 
I agree that it is overkill for a simple "daily backup" operation.
 
I have used this pattern as-is, however, for a special function that allows one to "reinstall" the database from scratch.
 
This application option allows one to experiment with my application and get a good feel, trying all kinds of silly things, then dismiss it by restoring the application to a freshly installed state. It is faster and more friendly than actually uninstalling - deinstalling, but could be very dangerous if used by mistake. This is why I have used this design pattern.
 
For backups, I forsee that before the end of the week, I will come up with something from the suggestions from many of the messages I got in response form this article.
 
- Having small text with boldface emphasis
- Having "unstandard" button labels. (for MessageBox(), that is), with clear text, instead of "OK" "CANCEL".
- Having an icon with a pictogram or animation showing the user what's going on. (Still, It must be absolutely georgious. I don't think I can draw that, or even explain our resident c/g. expert on what should be drawn.)
- Changing the innerworking of my program to make it absolutely difficult to do something silly, like overwriting client A backup with client B data.
- Maybe I can "cheat" a little and keep a "hidden" backup that will be used to preserve what I had before. (So If my operator restores an obsolete backup on top of a good one, thinking he is backing up, a special "hidden" recovery procedure could be invoked. I don't know if I should eat hard disk space like that. A backup can easyly take 5 megabytes or 50, from what I have seen. Hmmm. I only have 40 gig right here, at home...?

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Permalink | Advertise | Privacy | Mobile
Web02 | 2.6.130523.1 | Last Updated 16 Apr 2004
Article Copyright 2004 by Bamaco2
Everything else Copyright © CodeProject, 1999-2013
Terms of Use
Layout: fixed | fluid