Task (Document) Templates

Now, a dialog box such as Insert Object represents only one level of user intention—the insertion of a content type into a document that itself already has a type. How did the user create the document in the first place? In general, this process is still application-centric: the user has to think, "I want to work on this task. What sort of applications do I have that let me work on a task like this?" The user then has to go looking for the right application, start that application, and create a new document of the appropriate type, possibly basing that new document on a template of some sort.

This process is less than optimal because the user must once again break the flow from intention to the fulfillment of that intention by searching for a program to run. This is the same problem that would occur in the absence of the Insert Object dialog box. Somehow we need to create a computing environment in which the user can quickly and easily map the task he or she intends to perform to some sort of task (or document) template that structures that task.

We want to give the user a way to say, "I want to start a new task, and this is the sort of task I want to perform." This is the essence of the File New command in most of today's applications. Some current major desktop applications already do something similar to this within the confines of their own document or file types. Consider, for example, Microsoft Word for Windows version 6. When you run Word without opening any documents, you'll be presented with an empty window frame in which only a few tools on the toolbars and only a few menu items are functional. In this mode, Word offers, besides access to Help, the File New, File Open, File Find File, File Templates, and File Exit commands, as shown in Figure 25-3.

Think for a moment about what you can accomplish at this point:

• Start a new task (File New)
• Continue work on an existing task (File Open)
• Find existing tasks (File Find File)
• Manage objects of some sort that each represent a specific task (File Templates)

Figure 25-3.

The available commands in Microsoft Word for Windows 6 when no documents are open.

When you select File New in Word, you are presented with a dialog box that lists the current document templates installed on the machine, as shown in Figure 25-4. Take a close look at the contents of this list. Each item describes a task: the creation of an agenda, an award, a brochure, a calendar, a directory, a fax, a fax cover sheet, an invoice, a letter, and so on. This dialog box looks suspiciously like the Insert Object dialog box, does it not? It gives the user a way to map an intention, such as "I want to write an agenda for a meeting," to specific actions in a piece of software. Microsoft Word even provides template wizards to walk the user through much of the task, applying artificial intelligence

Figure 25-4.

The list of document templates as presented by Microsoft Word when the user selects File New.

heuristics to perform a great deal of the work involved in the task on the basis of a user's answers to a few questions. This is incredibly task-centric.1

I think, with new standards and extensions to OLE, we could accomplish this same level of task focus in a generic way for all task types, regardless of whether they involve text documents, spreadsheets, e-mail messages, database forms, or other content types. This idea applies equally well to the File Open, File Find File, and File Templates commands, which all give the user the means to map slightly different intentions to the actions to fulfill those intentions. Furthermore, these functions would not be part of any one application's frame but part of the operating system shell itself.

I say this because we are already seeing many of these features work their way into the system shell. Take, for instance, Windows Explorer in the Windows 95 shell. Explorer is a systemwide Find File user interface that allows the user to search for files based on many different criteria. The idea of the Explorer is that when you need to locate an existing task, you ask the computer to find it for you. You don't need to spend time navigating the directory structure of your network or hard drive looking for some obscure filename. (Long filenames help out here as well.) In short, a shell-level document search facility increases one's productivity by eliminating the time wasted in searching for files.

The result of any search will typically be a file list of some sort. Given long filenames, this list presents existing tasks that are described by the filename itself. A simple double click on one of the items in the list tells the shell to find the code associated with that file type, run that code, and have it load a file. We already know how to do all of these things using the file's extension, a CLSID, a file pattern, and so forth. In fact, the system shell could reduce the whole process to the creation and binding of a file moniker.

So through a user interface such as that in Explorer, and with a few future evolutionary enhancements such as full content searching, each application will no longer need to provide its own Find File capabilities, nor even its own File Open capabilities. With a shell-level user interface for selecting a new task, applications need no File New command themselves. At this point, there is no longer any reason to have applications as we know them today! This is because most of today's applications, especially the multiple-document applications such as Microsoft Word, are really nothing more than frames around a collection of documents. The functionality now provided by the frame is something that will eventually be provided by the system shell itself. Instead of having one application frame that manages text documents, another that manages spreadsheets, and another that manages e-mail messages, the system desktop itself becomes the frame that manages documents of all types in their own windows.2

I'm saying that what we now know as applications will become the servers for what I call task template objects, special flavors of OLE objects that implement interfaces specifically tuned to the management of a task. This means that an application such as Microsoft Word could simply become the server for a whole host of different template objects, as could all other applications. Each template type, appropriately classified, would be registered with the system along with its server. These registry entries would be the source of a system shell–level File New dialog that would list all the available task types on the system. When the user selected a task from such a list, the shell would basically create an instance of that type's CLSID, which would launch the server code for that type. Now, instead of the server displaying a document window inside some frame, it would simply display a document window, negotiating menu items and toolbar space with the system shell in order to provide the user with the appropriate commands for that task. When the user selected a piece of content to create using the Insert Object dialog box, the new content object would perform in-place negotiation with the document and the system shell (acting as the frame) to once again make commands and other tools available to the user.

The purpose of a shell-level File Templates command would be to help the user manage the tasks that are on a system, removing old ones, installing new ones, and so on. Given OLE controls and powerful end-user tools that work with them, users could even create their own templates—that is, define a custom task. This would also be the role of many corporate developers—creating business-specific task templates for use across their enterprise.

The big question, of course, is when and how this sort of task-centric computing environment will become fully implemented. What sort of interfaces will be involved with a task template object? How will it be integrated into a generic system shell? What services will the shell provide to templates? What other sorts of objects will be integrated with the shell? There are many such questions, most of which are very complex. Still, the process of creating the answers promises to be an exciting one.