By the end of 1986, AutoCAD's user interface was looking pretty antiquated. In October 1986 we'd shipped AutoSketch which had, for the time, a rather nice interface including pull-down menus and dialogue boxes. Many people felt that outfitting AutoCAD with such ease-of-use features would be a massive job requiring major modifications all over the program, further complicated by the need to maintain compatibility with existing menus, scripts, and other application components.
I wasn't sure it was all that tough. The moment the company shut down for the Annual Week of Rest between Christmas and New Year, I launched into a fury of round-the-clock programming, integrating the user interface manager from AutoSketch into AutoCAD, then extending AutoCAD's menu system to permit user-customisable pull-down menus and adding dialogue boxes to control many aspects of the program. By the time the company re-opened on January 4, 1987 it was all working as described in the following document which I stuffed into all the programmers' boxes so they'd find it when they got into the office that Monday. This was the first high-profile ``Holiday Hack'' and, along with the Portable Data Base project (see page ), which I did the next month, formed the centrepiece of AutoCAD Release 9.
A new user interface can be added to AutoCAD in incremental steps without sacrificing open architecture. Installation of this capability may spark the next large growth in sales.
The evolution of AutoCAD's user interface has, to a large extent, recapitulated the evolution of user interfaces within the computer industry since the advent of timesharing.
The first programs designed for timeshared computers were command driven. These programs required the user to learn and become facile with a fairly large set of commands expressed as words or abbreviations and entered on a keyboard. As time passed, programs came to provide assistance to the user in the form of on-line help, command completion, and user-definable macros.
As on-line systems were adopted for commercial applications in the 1970's, menu driven user interfaces became increasingly popular. In a menu driven system, the user's major act of volition is choosing from a set of alternatives presented by the computer. Such systems can lead the user through a maze of functions with minimal confusion. In such systems, however, it is clear that the computer is in charge and the user is at best a guide and at worst a peripheral.
Research on how untrained users, particularly children, perceive computers led to the development in the early 1970's of the first event driven user interface: the Smalltalk system developed by Alan Kay at Xerox PARC. Event driven systems superficially resemble menu based systems, but differ in that the user is in control, generating requests of the system which are performed regardless of its state. Event driven systems tend to use a flat command space model and are largely devoid of modes.
AutoCAD began as a completely command driven program, and was consequently an exemplar of the first class of timesharing applications. Immediately prior to COMDEX 1982, a screen menu was added to AutoCAD, complementing the preexisting rudimentary tablet menu facility. Commands generated by menu selections were allowed to pause for user input, allowing the development of simple menu macros. In 1983 and 1984 the AutoCAD menu facility underwent further development, culminating in the release of AutoCAD 2.0 in October of 1984. This package incorporated a true menu programming language, allowing replacement of menus and submenus, and supported four separate tablet menu areas, a button menu, and the screen menu simultaneously. This package, along with a hierarchically structured menu released in conjunction with it, advanced AutoCAD into the second generation of user interface.
Unlike many other programs which made this jump, AutoCAD added menu-driven capability on top of the existing command-driven architecture, preserving the preexisting interface for users who preferred it. Since AutoCAD is an open architecture program and has always encouraged its users to extend it, this was particularly important. An open architecture program such as AutoCAD is founded on the concept of its command language being a programming language. Only a command-driven language is well suited to interpretation as a programming language and the retention of AutoCAD's original command language, and its extension, first through menu macros and later with AutoLISP, contributed to the acceptance of AutoCAD as the standard for desktop computer aided design.
Many observers of the development of software believe that programs cannot evolve from one generation of user interface to another without being rewritten. Indeed, many programs have been rewritten concurrently with being fitted with a contemporary interface. In addition, the goal of open architecture as exemplified by an extensible command set, programmability, and mutability of the interaction with the user, is often viewed as detrimental to the goal of a consistent event driven user interface. Most event driven programs (the majority of which haven been developed for the Smalltalk system and its derivatives such as the Xerox Star and the Apple Lisa and Macintosh) have been closed architecture systems, providing little or no ability for the user to tailor the system.
Those who have extensively used command-, menu-, and event-driven systems commonly remark that these systems form a continuum. The command based system is the hardest for the new user to learn, but the most productive in the hands of the experienced ``power user''. The event driven system, though easily mastered by the beginner, delivers little more productivity to the user who uses it constantly. An open architecture package must also consider the consequences of the adoption of a new user interface on its extensibility and the base of applications which have been built upon it. Since the history of computing has demonstrated that open architecture, extensible systems predictably supplant closed architecture, proprietary systems, any modification of the user interface of a successful, established package must be carried out in an upward compatible, responsible fashion.
This article describes a set of modifications to AutoCAD which, taken as a whole, permit AutoCAD to present the user with a third generation event driven user interface. These modifications, while numerous, are individually minor. They build on AutoCAD's open architecture, making it the first true open architecture event driven program. The individual features described below work together in a tightly coupled fashion to deliver a far more responsive, intuitive, and transparent model of interaction with the user. They cannot be adequately evaluated by reading feature descriptions or by trying them in isolation. I recommend you see a demonstration of these new capabilities before attempting to understand the details of their implementation.
Some of these new capabilities require functionality not previously provided by AutoCAD display drivers, in particular the ability to save, restore, and clear rectangles on the screen, and to write text on the screen in any character cell position with normal, reverse, or disabled attributes. The display driver interface was extended to provide these additional functions in such a way that if an existing driver is not or cannot be upgraded, the new features will automatically be disabled, leaving existing AutoCAD functions unchanged. Several of the new features do not depend on the display driver extensions, and are present in all AutoCAD configurations.
Editor: John Walker