Concurrency is necessary in the implementation of multi-threaded dialogues. These arise in user interfaces where the user is free to manipulate multiple input devices to address several (possibly related) tasks at the same time. For example, in a CAD application, the user may be allowed to drag a part into position (say, with a mouse manipulated with one hand), while selecting the size, rotation, colour or some other parameter(s) of the part with some other device manipulated with the other hand. Similarly, in a paint program, a user may paint with one hand, while controlling paint attributes with the other. Buxton and Myers [1986] have demonstrated that allowing users to performs two tasks simultaneously may speed up their performance and thus this feature should be supported in UIMSs.

Concurrency can also be a useful tool for structuring the implementation of the UI. In many direct manipulation interfaces the user can perform a wide variety of actions, depending on which item the user has selected to manipulate. If these interfaces are implemented as a single dialogue, a complex structure can result. By implementing them as several dialogues that are able to run in parallel, where the item selected determines which dialogues (if any) are running, a more modular, easily understood implementation results.

Concurrency can be used to improve the structure of user interfaces in another way. If a UIMS that supports concurrent dialogues is used, the UI can be implemented as a translator that carries on one dialogue with the user while carrying on another with the application routines. This can result in a more easily understood implementation, and can improve the responsiveness of the interface by overlapping interactions with the user and the application routines. The control panel interface was implemented in this way, and it gains responsiveness and has a clearer structure as a result of this approach.

For all of the above reasons, concurrency is an important feature that should be supported in UIMSs. Sassafras demonstrates that it is practical to do this.

Most existing UIMSs have a run-time structure where the UI is allowed to call the application routines, or the application routines call the UI. Neither approach allows a good balance between the two components. The problem is that if the only form of communication is procedure call, the communication will tend to be one-sided as the callee can only send information by returning, and must return to the calling routine. A balanced approach is needed as the UI will often have to communicate commands and arguments to the application routines, and the application routines will have to communicate information to the UI such as range limits and defaults that change as the state of the application routines change. If communication in either direction is sacrificed, then interface quality is compromised.

This two-way communication between the UI and the application is used in both the control panel and layout interfaces. In the control panel interface, commands are sent to the application routines in response to user input, and the application routines supply information that is used in the pop-up menus that the UI presents to the user. Tanner and Buxton [1985] describe picking as a potentially difficult problem in UIMSs. In the room layout interfaces, two-way communication is used to support picking (selection of objects that have already been placed by pointing and then clicking the mouse button). In the case of the layout programs the user interface tells the application routines where the user has attempted to pick, and the application replies with the object that the user picked (or error information). Thus the solution is simple if appropriate communication facilities are provided.

Two-way communication is also needed between the user interface and the routines or modules that are used to collect input from the user (the Interaction Modules or IMs). These are the standard packages that support keyboard input, pop-up menus, and other standard forms of input. These packages are effectively subroutine libraries. There must be some way to send parameters to them (to customize their behaviour), and to receive input from them.

In the paint program described above, the IMs report mouse activity and interaction with the touch tablet. The UI tells the interaction modules that deal with the touch tablet and the mouse what information they should report. If the UI could not tell the IMs how to behave, the UIs would have been much more difficult to construct.

Suspended time editing is the ability to suspend the execution of a user interface, alter its specification, and then resume execution from the point of suspension, running the new specification. This feature allows a user interface designer to rapidly install changes in a user interface and then immediately test the changes in the context that inspired them. Assuming a UIMS is to be used to support a style of interface development where a prototype is constructed and then iteratively tested and improved, this feature is very useful. It makes the loop very fast, and eliminates the tendency to procrastinate on the installation of some changes because the effort is not believed to be worth the improvement in interface quality.

During the development of the interfaces described above, Sassafras was modified to support suspended time editing. This feature was found to be extremely useful in the refinement of user interfaces.

It is often suggested that UIMSs can be used to retrofit user interfaces to existing applications with little or no change to the applications routines. This is likely true, if the new UI can be tailored to the existing application. However, if the goal is to add a new UI of a specific style, then the application routines may have to be extensively modified. For example, the original application routines for the first version of the room layout program had a model of behaviour that was incompatible with the specification of the Foley and van Dam interface. The application routines had to be extensively modified before the UI could be completed.

The style of interaction supported by the user interface is not independent of the functionality of the application routines. The UI cannot support functionality at the user interface that is not supported in some way at the interface between the UI and the application routines. There are two potential problems:

The only solution to the first problem is a major rewrite of the application routines, or a change to the UI specification. Both of these are undesirable. In the case of new applications, there must be communication between the UI and application designers during development, to ensure that their respective designs are not incompatible.

The second problem is not as serious. If the UI can be easily modified, then it is natural to expect that useful commands will be discovered and quickly implemented at the UI level. If a powerful programming environment is used to implement the application routines, it should not be difficult for the application implementor to keep up with extensions to the user interface.

Much UIMS research, and many systems, are predicated on the assumption that the user interface can be separated from the application and the two developed separately [Olsen & Dempsey 1983, Tanner & Buxton 1985]. The meaning of ``separation'' is not clear. It could be logical separation, in the sense that the user interface and the application routines do not share data, and have only a limited ability to communicate with each other. Alternatively, the separation could be physical, with the specification of the user interface being in a different file (or files) than that of the application routines. The two forms of separation are independent, hence there are four possible combinations. The best combination is physical separation without logical separation. This allows the most appropriate language to be used for each component, and allows the various components of the interactive system to communicate as needed. For example, the room layout interface relies heavily on physical separation to help modularize the specification and to control complexity. It also uses a tight logical coupling to improve feedback when the user is moving pieces of furniture. Traditional run-time structures have prohibited the use of a combination of physical separation and tight logical coupling.

Many UIMSs are built around some form of parser and are predicated on the assumption that a key function of the UIMSs is the parsing of user input. Thus, the language used to specify the user interface is a language for formally specifying languages and does not have most of the features of traditional programming languages. For many simple interfaces (e.g., the control panel interface) this is sufficient.

For more complex interfaces, such as the paint and advance room layout interfaces, the parser based approach becomes clumsy and awkward. The problem is that simple computations must be frequently performed on user input or system state. This is particularly true of direct manipulation style interfaces. For example, the two-handed paint program must modify the size of the brush, performing additions to it and keeping it in the range of legal sizes. If the user interface specification language does not support this type of operation application routines must be used. This greatly increases the size and complexity of the specification and reduces its legibility. A solution is to extend the user interface specification language so it becomes a simple programming language with special control constructs to assist in dialogue specification.

Throughout the UIMS literature (e.g. [Buxton, et al. 1983] and [Feldman & Rogers 1982] and the advertising for most commercial UIMSs), it is commonly claimed that UIMSs should allow non-programming user interface experts to design and implement user interfaces. When dealing with visual aspects of the UI, such as icons and screen layout, programming skills are not needed. But for some parts of the UI development a limited-programming user interface expert would be better than a non-programmer. The above issues are arguments in favour of requiring the user of a UIMS to have some programming skills. Also, when testing and debugging it is often hard to know if the problem is in the application routines or the user interface, hence, some programming knowledge would be of use in locating errors or when consulting with the application programmer(s).

Thus, the goal should not be to eliminate programming, but to provide the UI-designer with an appropriate set of tools. These tools could require the use of some programming skills. In the development of the example interfaces, it was found that simple arithmetic operators, conditional branch and function call were the only constructs needed. It is likely that non-programmers could quickly learn to deal with these constructs (the more complex and error prone concepts of iteration and recursion are not needed). Thus it reasonable to ask that the user interface expert have some basic knowledge of programming.

There are, however, some UIMSs that require no programming (e.g., Trillium [Henderson 1986], the University of Toronto UIMS [Buxton, et al. 1983], and Peridot [Myers & Buxton 1986]). The cost of being free of programming is a loss of generality. This cost may be acceptable in many cases.

Three desirable features that should be supported by UIMSs have been described. These are: concurrency, communication and suspended time editing. These can improve the quality of user interfaces developed with a UIMS and can speed this development. The Sassafras UIMS demonstrates that these features can be efficiently supported.

Four key issues in the design and use of UIMS have also be presented. These concern: matching of the UI to the application, separation of the UI from the application, whether the dialogue specification language is a parser or a programming language and whether the UI implementor should be a non-programmer. These issues are derived from assumptions or beliefs about the way in which UIMSs can be used. Experience with Sassafras suggests that these assumptions and beliefs are not always true. This suggests that the design and implementation of future UIMSs should not rely on these assumptions and beliefs.