In-place activation is about document-centric computing—the notion that end users want to concentrate on the task at hand—the document—and to be free from having to remember which application to use at what time for what reason. As my mother would say, "I just want it to work! I just want to write a letter!" End users want to be sure that they use the best tools for the job without having to think too much about finding those tools.
Here's a case in point: while I was writing this chapter for the first edition of Inside OLE, Microsoft held a usability contest in which representatives from other companies were asked to create the most usable ATM—Automatic Taco Machine. No, seriously. The goal was to create an interface that would allow anyone to walk up to the ATM and, without ever having seen the device before, quickly and easily order a taco with any number of options. From what I heard, contestants exploited pull-down menus, pointing devices, three-dimensional beveled button controls, and all the other glitz we're used to seeing on a desktop computer. The entry that won was a simple design with a touch screen. You knew at a glance how to order a taco by pressing one spot on the screen; by pressing others you could specify exactly what kind of taco you wanted. No glitz. Just plain common sense.
Why did this win? Because it was, for lack of a better term, taco-centric. The purpose of the device was to allow an end user to order a taco. Period. The winning design did exactly that—no more, no less. It's not so much that it could do the right thing, but that it was designed in such a way that the only thing you could possibly do with it was the right thing. If this sort of idea interests you, Donald Norman's wonderful book The Design of Everyday Things (formerly The Psychology of Everyday Things) is a must-read. Norman would be the first to point out that the other designs failed because they paid so much attention to aesthetics that usability was flushed straight down the toilet. Sure, the menus and 3-D buttons were neat, but they didn't work. They would, however, probably win some prize for artistry.
In-place activation addresses the idea that we want the content in a document to look, feel, and act as if it were an integral part of that document. The basic activation concept that we've seen in Chapters 17 and 18 only partially achieves a document-centric model. It's a great start to have OLE automatically launch another application and to have the object automatically load its native data and show its user interface for editing. In this way, the user never has to leave the document to launch another application. However, having other applications show up on the screen in their own pop-up windows is still rather application-centric. These windows can obscure the compound document itself in such a way that the user might forget about the context in which he or she is working. In addition, users can be confused about where the real data exists. When an object is activated, its data or image is visible both in the server and in the container. Sure, the container draws a hatch pattern over the image in its own document, but confusion is still possible.
What in-place activation achieves is to bring all the necessary editing and other manipulation facilities from the object's own user interface to the container itself. That is, in-place activation is a means through which the object and the container merge their user interface elements: the container retains control of document-oriented elements, and the object gains control of content-oriented elements. Thus, the object can display its own menu items, toolbars, windows, and other devices in place in the container. When this happens, the user sees only one image of the object—the image in the document. And because no other pop-up windows appear, the user continues to work within the context of the document itself.
In-place activation architecture, although technically capable of activating both linked and embedded objects in place, should be used only to activate embedded objects. The reason is strictly one of user interface. When a user edits the source data for a linked object, he or she is working with shared data. Changing the source can potentially change many other linked objects in other documents. If a linked object is activated in place, the user might not realize that he or she is altering shared data and thus other documents. On the other hand, editing an embedded object changes only that object's data, which is entirely contained in the compound document itself. However, if you are building a closed system in which you control all the containers and objects, you can activate links in place if you want. The restriction must be followed on open systems to maintain consistency.