* Save time: Actions can be read far faster from a script than they can be entered by a user;
* Decrease errors: Scripts are always read correctly, whereas users often err when entering repetitious commands; and
* Operate autonomously: Long-running scripts can be executed without a human operator, freeing the user to perform other tasks.
Moreover, macros are actually programs which have been created demonstrationally by end users. As such, macros represent the first large-scale commercial success for PBD technology.
This success, however, is largely confined to application-specific macro facilities -- that is, macro facilities distributed with and tightly linked to specific software packages. Despite this fact, a strong argument can be made in favor of a single set of system-wide (hence application-independent) macro facilities. Among other advantages, this approach allows for macros which include actions from multiple applications and also provides a single mechanism both for developers to support and for end users to learn. The allure of system-wide macro facilities is further demonstrated by the growing number of such products on the market. Unfortunately, even the most popular of these systems, such as Tempo II Plus [Affinity 91] and QuicKeys [CESoftware 90], suffer from serious shortcomings: foremost, they produce macros which are less robust and less intuitive when compared to their application-specific counterparts. These problems stem from the loss of semantic detail resulting from actions being recorded outside of the application which performed them. How is a macro system to infer, for instance, that the user just dragged a file icon into the trash, if the macro system only records a series of mouse moves?
This difficult problem has led to the development of high-level events (as opposed to low-level events such as mouse clicks and keystrokes). Using high-level events, for example, once a desktop application determines that a file was dragged into the trash, instead of actually deleting the file, the application would send itself a "Delete-File" high-level event. This event is passed to the system, where it can be recorded, and then sent back to the application, where it is finally executed. This is the basic approach used in Apple Events [Apple 91] and HP NewWave [Fuller 89], and to a lesser extent in Microsoft OLE [Petzold 91]. These architectures represent a major commitment to the high-level event paradigm, and they are meeting growing success as developers and end users begin to appreciate the power and elegance of this approach.
This chapter proposes, however, that existing high-level event architectures do not go far enough. The basic problem is that -- like the low-level macro facilities they subsume -- they record a flat history of events. While these events are at a higher level than mouse and keyboard actions, they are still grouped in one level. This is problematic because humans typically perform tasks with rich, multi-level structures. For instance, Figure 1 depicts a very high-level "Edit-File" event, which includes a "Save-File" event, which itself includes the sub-task of specifying the new file name, which then includes the sub-task of editing a string in a dialog box, which finally includes the low-level sub-tasks of entering actual keystrokes. If the system's history includes only one level of events, then all the history-based support -- including macro recording and playback, undo, event-based invocation (described in Chapter 21), and so on -- is confined to that level. Moreover, it is not sufficient to merely include all these events in the history (which present systems can do) -- the system must also maintain the basic structure of the events (which present systems can not do). Otherwise, the system will erroneously apply the same operation (such as undo or playback) to multiple levels of the same event.
Following this reasoning, this chapter proposes Aggregate Events, a new model of application event processing which extends the current high-level event paradigm to include arbitrary-level, structured histories. The Aggregate Event model serves as the basis for KATIE [Kosbie 93], a new architecture for improved system-wide, event-based macro facilities. Under this model, applications will group low-level input events (such as mouse clicks) into higher-level interface events (such as menu selections), which then are grouped into higher-level application events (such as "Delete-Paragraph"), which may be grouped into even higher-level events, such as "Edit-File." When an application groups events into a higher-level Aggregate Event, that event is sent to the system dispatcher by the same means that current high-level architectures utilize. However, the additional aggregation information will allow the system to maintain properly structured history. With Aggregate Events, system-wide macro facilities should match or even surpass the power of application-specific approaches, and serve as a viable platform for complex, demonstrational, end-user programming.
back to ... 
Table of Contents Watch What I Do