Click to Rate and Give Feedback
Also by this Author

Very soon, the development of Microsoft .NET applications will require interaction between those apps and existing COM components on both the client and the server. The .NET Framework has made provisions for this interaction by implementing various wrappers for COM objects to allow exposure of their properties and methods to .NET components. These wrappers will make it easy to make the connection between COM and .NET. After discussing wrappers, this article discusses other ways for .NET components to take part in COM+ transactions. To top off ...

Read more!

There are many tricks to getting the most out of COM+, and this article offers the author's top 10. The tips cover the importance of transaction processing, the use of the COM+ catalog, and the design of three-tier distributed systems. Writing components using the correct threading model, knowing when to use compensating transactions, and the importance of stress testing early in the process also make the list. Other indespensible suggestions emphasize the importance of recognizing where an object's state is located, choosing appropriate authentication ...

Read more!

In the beginning, writing controls meant dealing with Windows messages. Then came Visual Basic controls, which introduced methods, properties, and events. Later, ActiveX controls, which ran atop COM, became popular. While each innovation in control writing brought more flexibility, nothing has matched the versatility of the new .NET Windows Forms controls and Web Forms controls. This article, the first of a two-part series, introduces the reader to Windows Forms, beginning with their inheritance from one of the .NET CLR base classes, which makes ...

Read more!

When creating a distributed system you frequently need to provide for communication between two entities that are not in sync. Microsoft Message Queue Server (MSMQ) provides the kind of store-and-forward messaging in a pre-built infrastructure that can help you address these kinds of messaging needs. In the past, MSMQ was accessed using a COM wrapper. Now there's a .NET wrapper that lets you accomplish your messaging goals easily from your Framework-based code. To illustrate the use of the wrapper, the author builds a messaging application, sends ...

Read more!

XML and HTTP are cross-platform technologies especially suited for building applications that can communicate with each other over the Internet, regardless of the platform they are running on. Web Services in the Microsoft .NET Framework make it easy to write components that communicate using HTTP GET, HTTP POST, and SOAP. An understanding of these concepts, along with knowledge of synchronous and asynchronous operations, security, state management, and the management of proxies by the .NET Framework is essential in building these applications. ...

Read more!

Popular Articles

Writing a Web application with ASP.NET is unbelievably easy. So many developers don't take the time to structure their applications for great performance. In this article, the author presents 10 tips for writing high-performance Web apps. The discussion is not limited to ASP.NET applications because they are just one subset of Web applications.

Rob Howard

MSDN Magazine January 2005

...

Read more!

James Avery does it again with his popular list of developer tools. This time he covers the best Visual Studio add-ins available today that you can download for free.

James Avery

MSDN Magazine December 2005

...

Read more!

C# allows developers to embed XML comments into their source files-a useful facility, especially when more than one programmer is working on the same code. The C# parser can expand these XML tags to provide additional information and export them to an external document for further processing. This article shows how to use XML comments and explains the relevant tags. The author demonstrates how to set up your project to export your XML comments into convenient documentation for the benefit of other developers. He also shows how to use comments ...

Read more!

Jeff Prosise explains when it's better to use UpdatePanel and when it's better to use asynchronous calls to WebMethods or page methods instead.

Jeff Prosise

MSDN Magazine June 2007

...

Read more!

Ray Djajadinata

MSDN Magazine May 2007

...

Read more!

{ End Bracket }
To Confirm is Useless, to Undo Divine
David S. Platt


The common user interface technique of confirmation, popping a dialog box into the user's face and asking, "Are you really REALLY sure you want to do that?" is evil. It's unfriendly, it's distracting, and it's completely ineffective. It shouldn't exist. Anywhere. Not ever.
Have you ever, even once, said, "Whoa! I didn't want to do that. Thanks," and clicked No? Or have you seen anyone do that? I haven't. Confirmation is so vastly overused that it has, ironically, become completely useless. Because the box constantly cries "wolf!" like the shepherd boy in Aesop's fable, no one pays attention to it, even when it's warning you of something you really don't want to do. You cruise through it on auto-pilot, clicking Yes without thinking. It provides you with no safety whatsoever.
Other operations in life don't require confirmation. Your car does not ask, "Do you really want to start the engine?" when you turn the key. The supermarket clerk does not ask, "Do you really want to buy these?" when you place groceries on the register belt. Programmers constantly ask for confirmation because they think users don't understand the consequences of their commands. That may be true, given the poor quality of the user interface. But confirmation doesn't solve this problem. If the user was confused when he first gave whatever command triggered the confirmation box, he'll be even more confused when he sees it. On the contrary, it keeps programmers from having to clearly explain to the user what he's doing, and providing a way to recover when he does something that he later regrets, despite having originally confirmed it.
What if the user really is mistaken? If you put a flashlight on the register belt with a package of the wrong size batteries, wouldn't an attentive clerk ask, "Are you sure?" A good user interface should and can save us from mistakes like that by preventing the problem initially. Perhaps the Web page selling flashlights would contain a check box saying "include batteries," checked by default. Better still, the flashlight would come with batteries inside, so it'd work the instant you unwrapped it and no one would ever have to worry about buying the correct size.
Another reason that you aren't asked to confirm starting your car or buying groceries is that these operations are easy to undo. You just turn off the key or return the unwanted item. Programmers often put "undo" capability in their programs, where it's the greatest design advance since the mouse. It takes an enormous amount of effort to make this feature work so that users don't even have to think about it ("easy can be hard"), but the programmers who implement it are any user's best friends. I buy them beer whenever I meet them.
The worst confirmations are those of undoable actions, such as moving a file to the Recycle Bin. It's much more efficient to fix the relatively small number of errors that actually do occur (for example, a slip of the mouse that deleted the wrong file) than attempt to prevent them by annoying the user with a confirmation box every time (which are usually ignored out of habit). An ounce of cure is not worth five pounds of prevention.
The beauty of undo is that it allows users to explore a program. It's not always easy to understand a new program's operation from menu items and toolbar picture. With undo, a user can try different commands, knowing that he won't damage something that can't be repaired with a few keystrokes. Programmers often regard incorrect user input as the act of an idiot who should have read the %*$#% instruction manual. It isn't. It is the primary mechanism by which the human species learns. An application with undo capability recognizes and enhances the user's humanity.
If undo is implemented correctly, then there's only one destructive operation in the entire system: emptying the Recycle Bin. Some would say that this operation should have a confirmation box, as it currently does. But even here, the confirmation dialog exists only to guard against another bad design, placing the "Explore" context menu item next to "Empty Recycle Bin." One slip of the mouse, sliding down three spaces instead of two, and you get the latter instead of the former. That's bad. Emptying the Recycle Bin should have a special action used for no other purpose, perhaps clicking on it while holding down some key. Better still, the Recycle Bin should automatically delete files after some configurable period of time so you'd seldom have to empty it manually. Don't ask permission, ask forgiveness. Provide undo, not confirmation.

David S. Platt teaches programming for the .NET Framework at Harvard University and at companies all over the world. He was selected by Microsoft as one of their Software Legends, which you can read about at www.softwarelegends.com. He is the author of nine programming books, the most recent of which is The Microsoft Platform Ahead (Microsoft Press, 2004). Reach him at www.rollthunder.com.

Page view tracker