User Interfaces

      In a speech at the InfoCorp Silverado conference in March 1986, I said that ``user interface is a distribution issue''. In other words, the economic viability of a low-cost product sold through retail channels without extensive support depends on that product being accessible to its potential customers without extensive training or handholding. One reason that AutoCAD was able to fend off assaults from PC versions of mainframe CAD software is that users were able to draw with AutoCAD without spending the time a mainframe CAD operator would invest to learn his system.

AutoCAD's user interface wasn't all that great in 1986, but it was better than most of the competition. Since that time, we have gotten much worse while our competition has been improving rapidly. Today I believe that no commercial software product with comparable installed base and revenues has a user interface remotely as bad as AutoCAD's, that the situation is degrading rapidly and spreading to our other products, and that the wages of our inattention to what should be at the heart of the design of any interactive tool are now coming due in the form of lengthy test time, unreliable applications, expensive training requirements, and rising product support costs.

Lack of vision, the absence of clear design, inattention to developments in competitive products, failure to apply reasonable engineering judgement to counter the demands of a QA department run amok in fields of casuistry, and general abandonment of the user interface to whatever seems expedient to developers as code is written, has resulted in an almost inconceivably wordy, obscure, error-prone, and virtually impossible-to-document input language which makes the CADDS 4 commands we used to ridicule elegant by comparison. It is ironic that a company whose staff ridicules products like and EMACS as ``suitable only for programmers'' is engaged in selling an application whose command language makes either seem a paragon of clarity and generality.

While AutoCAD's command language was an object of neglect, computer vendors were rapidly raising the stakes by attempting to make the user interface part of their operating systems. It appears increasingly probable that, in order to compete in the future on multiple hardware platforms, an application like AutoCAD must become able to conform to multiple different user interface mechanisms while somehow maintaining application and database compatibility across platforms. There has been general acknowledgement for over a year of the seriousness of this problem and how important finding a solution is to Autodesk's future. During that time, no resources have been allocated to solving it within the software development department--the problem has been left to me to solve in whatever time I make available to work on it, with whatever energy I can spare from other tasks.

Our development and QA staff seems increasingly consumed in debates over arcana about which nobody outside Autodesk seems to care as shipment deadlines slide past, while our competitors are creating and delivering products which are making intuitive concepts that Autodesk seems to lose grasp of in a lake of wordy commands, and a sea of error messages whose aggregate size exceeds the total size of some Macintosh applications. If you don't know what I'm talking about, or think this is some of the hyperbole often attributed to me, I suggest you schedule, back to back, a two hour demo in which a robot arm is constructed with AutoCAD, and a 15 minute demo in which the same task is done with Swivel 3D, a new modeling product for the Macintosh. Swivel 3D was originally developed to explore solid model interaction with the VPL glove, a user interface modality which seems to elicit laughter from the majority of Autodesk personnel, notwithstanding its being considered one of the most promising approaches to 3D manipulation by the user interface group at NASA Ames and having been the subject of the cover of Scientific American in October 1987..