To put together the identified main windows, we relied on the Model-View-Controller (MVC) framework, which is known from the Smalltalk programming environment, as a starting-point. Among others, it is described by Dodani, et. al. [1989] and Lee [1994]. As I will show you, the MVC architecture can be applied to general graphical environments like Microsoft Windows which has substantial impact on the prototype of The COOPerator.
The notion of dialogue independence has been applied in human-computer interfaces in various forms of implementation. It was first introduced in Smalltalk-80. In this environment, models are the application function layer. They perform the requested action. Views are the human-computer interface presentation layer and are mainly concerned with displaying the application's status. Finally, controllers manage interaction. That is, they handle user input-device interactions. The MVC framework is shown in the following figure which was adapted from Dodani, et. al. [1989]:
We did not use the Smalltalk programming language to implement COOPerator's functional core subsystem nor its human-computer interface subsystem. Instead, we used Whitewater's object-oriented programming language for the Microsoft Windows environment, Actor Professional version 4.1. However, as Lee [1994] explains, the MVC model has been the basis for most of todays widely used graphical environments, including Microsoft Windows. The MVC architecture can be applied to human- computer interaction and application development in other graphical environments. As all the de facto standard graphical environments support event-handling mechanisms for user input-device interactions, the definition of the architectural elements of controllers subsystem and subsystem-interfacing mechanisms should be adjusted accordingly. In an event-driven MVC architecture, the controllers component becomes the event handler that dispatches user input-device events, windowing-environment events, and any other system events to the corresponding response functions in the models component.
Microsoft Windows is such an event-driven graphical environment: it responds to user input-device interactions. Windows acts as the controller in the Model-View-Controller framework. When an event occurs, the Windows module USER.EXE generates a message that, among other things, identifies the affected window (that is: the window in which the action took place) by its handle, that you can think of as a unique address for the window element. The message is placed in the corresponding application's message queue.
While there is only one instance of USER.EXE for a Windows session, each running application within the Windows environment has its own queue which it polls for the messages it needs to respond to. This is, in fact, how Windows multi-tasking works. Inside each running application is a message loop that runs during the course of the program's operation. The message loop polls the application's message queue and dispatches messages throughout the program to the appropriate window object: the window object associated with the handle the message identifies.
If a response method is defined for the window object receiving the message, that method is invoked; otherwise, the default response defined by Windows (called the default window procedure) is invoked, which guarantees that all messages are responded to in some way. These methods give an application its event-driven character. Application-specific behaviour is achieved through selectively responding to the Windows messages received. Thus, a human-computer interface engineer can focus on writing methods that respond to the Windows messages and, in turn, send messages that invoke the application's functional core which is the model of the application. The model performs the requested action and the view displays the resulting application's status. It receives the handle for the Window from the controller.
The view component is concerned with display. It is equivalent to windows in most systems. What we call a main or parent window, is a top-level view which can hold multiple subviews or child windows. Typically, the top-level view provides common facilities for opening, closing, (re)sizing and moving its child windows or subviews.
A top-level view may be seen as the root of a view hierarchy in which a superview is responsible for graphical transformations, windowing, and clipping between levels of the superview/subview hierarchy. The following example shows the view hierarchy of COOPerator's document facility:
This anatomy can be translated into a tree (in which A is the root of the hierarchy) as follows:
We already made clear that Microsoft Windows plays an important role. For one, this graphical environment provides sufficient standardised graphical widgets which ensure the creation of a consistent interface. According to Marcus [1992] the standard controls for Windows are relatively easy to understand and should provide even inexperienced operators with an immediately usable system. At the same time, the extensive keyboard-control capabilities will satisfy hard-core users. Thus, Windows stipulates the level of communication. Moreover, The COOPerator system uses Windows specific keymappings (e.g. ALT+F4 to close the application, CTRL+V to paste something from the clipboard) and links up with Windows functionality like the clipboard. Marcus [1992] sees the following benefits and limitations regarding Windows:
This summary may seem somewhat brief. It is, however, necessary to view this list in relation to other graphical environments like Motif, OPEN LOOK, and the Macintosh. Though Windows does not feature the directness of interactive control provided by the Macintosh, it comes close (when used on a sufficiently equiped computer). And the beautiful three-dimensional look and feel presented by the NextStep graphical environment is also gradually appearing in the Windows environment.
For providing the students with status information and feedback, we highly relied on Windows' standardised, built-in features. For example, the hourglass shaped cursor always appears to inform the user that his system is carrying out the actions he initiated while we frequently use the window caption or the help bar to present status information. Another mechanism is applying context-sensitivity whenever a user must choose from a number of alternatives. This is especially powerful in combination with Windows' object-action model of interaction.
Besides the functionality of Windows' clipboard, The COOPerator will eventually embrace the standard on-line help facility which I consider to be the most beautiful part of the Windows environment. Microsoft's User Interface Guide (itself available as help-file!) defines the behaviour of a standard help menu and browser window and a means of presenting them within the standard window structure. Within The COOPerator, a help button is already included in most dialogue boxes to provide context-sensitive access of the help facility.
Thus Microsoft Windows accounts for a large part of the functionality of The COOPerator. For one, it provides a means for constructing a consistent interface. Nevertheless, a lot more is to be told regarding the specific design of COOPerator's main windows: the document facility, the agenda, the graphical browser and the mail facility. Also, do not get the wrong impression: I am far from thrilled about Windows. Though I like the standardisation it offers, I dislike it for being so instable and because it lacks preemptive multi-tasking.
Sjoerd Michels, Tilburg, The Netherlands