|
|
We'd always hoped that once we got a product into the market, our customers would direct our development efforts through their requests for enhancements to the product. We couldn't have wished for a more energetic, imaginative, or vocal community of users. After six months of shipping AutoCAD, the lists of requests for new features were growing so long that we decided to get together, merge all of our private lists, and try to sort them by size of the job and importance of the feature. Duff Kurland prepared this first-ever AutoCAD Wish List from his notes of this meeting. Duff continued to be the keeper of the wish list for several years thereafter.
Any doubts about the veracity of our claim “our development agenda is taken directly from the list of user-requested features” can easily be dispelled by comparing with wish list with the features in AutoCAD releases up to the present day. I've added annotations in italics listing the release in which each item was eventually implemented.
An AutoCAD enhancement technical session was held on Monday, June 6, 1983, at John Walker's home. Present were Dan Drake, Richard Handyside, Rudolf Künzli, Duff Kurland, Greg Lutz, Lars Moureau, Mike Riddle, and John Walker.
A list of desirable features was compiled and discussed with varying degrees of detail. An attempt was made to prioritize these items, and some were assigned to individuals for implementation. This document has been prepared so that those who were not at the meeting (and those who were) will have a basic understanding of what's going on, and what the project names mean.
A few general notes are in order before presenting the list of features. First of all, AutoCAD-80 is not expected to be enhanced at all. Secondly, the priorities were set based on a combination of factors:
Lastly, strict priorities have not been set. Some of the low priority items may actually be among the first done, if they're in areas where we're already poking around.
I have included notes on the discussion of most items, but they are by no means complete. I would welcome comments, clarifications, and additions; this list will be continually updated, and published at reasonable intervals.
The ability to draw an arc by specifying its center, radius, and start/end angles has been requested by users. This is somewhat embarrassing; that's the way we encode arcs internally, but the user cannot specify them that way. Other combinations, such as endpoints and included angle have been requested, also. 1.4.
This is the ability to select the text size based on the length of the field in which it is to fit. 1.4.
AutoCAD-80 now has a “CHANGE LAYER” command to allow selected entities' assigned layers to be changed. A similar capability is needed in AutoCAD-86. 1.3.
This item was discussed briefly, and I'm not sure what it encompasses. Discussion included the ability to select the size and resolution of a new drawing without prompting the user for the details each time. Two methods were proposed; selecting defaults via the new “Configure AutoCAD” main menu item, or allowing the user to specify the size using ANSI or DIN sizes with a default resolution. A more elaborate “drawing type” scheme was also proposed (see “Questionable items” below). Prototype drawings in 2.1.
Drawing interchange files do not currently contain certain information about the drawing (insertion base point, etc.). This information is in the drawing file header, and should be added to the DXF file. 1.3.
This would be a change to the display drivers (“dsdot”) to invert the pixel at each grid point, rather than simply set it. The idea is to ensure that the grid is visible even on a filled solid area. (Note: “GRID ON” will currently write a grid even if the grid is already on. This will have to be fixed first.) 1.3.
This will avoid two areas of confusion, since “FILL” is a better description of the command's effect, and “REDRAW” won't perform different tasks depending on which key (space/return) is used to terminate it. 1.3.
This should also eliminate some user confusion. 1.3.
The “SOLID” command should prompt with “1st point:”, “2nd point:”, etc. as documented. 1.3.
User friendliness (eschew obfuscation). 1.3.
I forgot to bring this up at the meeting, but feel it belongs in this category. First, “HELP” should be a synonym for “?”. Second, we should support requests such as “HELP CIRCLE”, which would display information about the CIRCLE command. I've already written an extended HELP file to support this capability. 1.3.
If ORTHO mode is on when an object is INSERTed, the insertion angle should be constrained to 0, 90, 180, or 270 degrees. 1.4.
Several AutoCAD prompts display the current value within square brackets. Unfortunately, these character codes are used for foreign language letters. We will change to angle brackets. 1.3.
A polyline is a group of lines, gaps, and arcs (?) which are associated with one another. They can be edited to add, delete, or move a vertex, move a line segment, etc. A width should be associated with the polyline; perhaps double walls could be special polylines. Assigned to Duff Kurland. Done by Dan Drake in 2.1.
John Walker has been experimenting with a cross-hatching technique which seems to work. We should implement the standard hatching patterns for various structural materials (concrete, steel, mud, etc.), and should consider a general user-defined pattern fill capability. Would be an extra-cost option. The project has been assigned to Mike Riddle. Done by John Walker in 1.4.
John Walker has also been researching various spline drawing methods. We had hoped that IGES would point us in the right direction here, but it doesn't point anywhere. Release 9.
Architects require this feature. A center line capability is also needed. Polylines might do the job here. Provided in AEC.
Several topics are covered by this item. First, we need to standardize on our color representations. For instance, the first eight colors should be:
0 black (erase)
1 red
2 green
3 blue
4 cyan
5 yellow
6 magenta
7 white (black on plotter?)
On monochrome devices, 0 means black (off), and any nonzero value means white (on).
Up until now, some AutoCAD implementations have used various bits of the “color” number to select the dotted/dashed line features of hardware devices (Scion Microangelo, NEC APC, plotters). While this has the desirable effect of allowing monochrome displays to differentiate between colors, it has two undesirable effects and must be avoided. First, it tends to make the color numbers difficult to work with (red + dashed line = 1 + 32 = 33). Second, it conflicts with the need for standardized line types.
One area which was not discussed at the meeting was the choice of colors for things AutoCAD (not the user) draws, like crosshairs and grids. My feeling is that the crosshairs should always be white, while the grid might be best in green. 1.3.
This is the ability to draw a line which intersects another entity in some specified manner (tangent to arc, perpendicular to line, etc.). 2.0.
It should be possible to select two points on a line, and split the line into two segments with a gap spanning the two selected points. This should not be limited to simple lines, however. Polylines, walls, traces, circles, and arcs should be breakable. 2.0. Polylines: 2.5.
Fillets are arcs which smoothly connect two lines. We should have a method of applying fillets after the lines have been drawn, and a method (FLINE command, or POLY command) of drawing them on the fly. 1.4.
Creation and reading of IGES-format interchange files should be
implemented. Could be an extra-cost option. Seen as large design
project with quick implementation involving adaptation of DIFIN
and DIFOUT functions.![[Footnote]](i/footnote.png){kind=small}
Assigned to Peter Goldmann. Done by Ben Halpern and
John Walker in 2.5.
Currently, our BLOCK command allows dynamic creation of a new block, but the new block is INSERTable only in the current drawing. We need a way to write the block to a new drawing file, so that it may be INSERTed in other drawings as well. 1.4.
Once a block has been INSERTed in a drawing or created via a BLOCK command, its definition rides around in the drawing file. In one respect, this is nice; the drawing file for the INSERTed part need not be present after the initial INSERT is done. However, it makes it difficult to update the part definition in all the drawings which include it. Even if all references to the block are erased from the drawing, the definition remains; the only way to delete it is to write a DXF file, edit it to remove the block definition, and load the DXF file back in. This is awkward. We need a way to delete or redefine an existing block definition. 1.4.
Our dimensioning facility can only draw horizontal and vertical dimensions. Several additional capabilities have been requested:
Our internal coordinate system uses 16-bit integers, giving a range of 0–32767 points in the X and Y directions. We are now seeing large (48-inch) plotters with 0.001 inch resolution. We need to support them, but they exceed our limits. A workaround might be to use only half of the plotter's resolution for the time being. 1.3.
So far, we've been producing a custom user manual for each machine implementation. This probably cannot continue. The basic reasons for separate manuals up to this point have been:
It might be best for us to produce a generic AutoCAD-86 manual, documenting all the commands, and control keys which will work on every machine. I would suggest the following keys:
Cursor left CTRL-H
Cursor right CTRL-L
Cursor up CTRL-K
Cursor down CTRL-J
Flip screens ESC 1
Select graphic cursor ESC 2
Select menu cursor ESC 3
Return to keyboard ESC 4
Slow cursor ESC 5
Fast cursor ESC 6
A note such as “on some machines, the CTRL key is marked ALT; see the AutoCAD installation/user guide for your machine” could be added. Operating system differences would be noted, as well. A separate installation/user guide and reference card would be associated with each machine, and would include exceptions from the main user manual and a list of alternate function keys if applicable. 1.4.
The AutoCAD reference card for each machine should include a list of the function keys available on that machine.
Rudolf Künzli has been working on various foreign language versions of AutoCAD, translating not only the user manual, but also the messages generated by the program. As things stand, he must re-apply his changes each time we send him new source disks.
We decided to use compile-time tests for each language, so that the text of each message could be provided once and maintained in the master source files. 1.3, later redone using the automatic translation utility.
This is the ability to attach a name to a designated point, and to use that name in subsequent relative coordinate specifications, geometric snaps, etc. 2.1, via Variables and Expressions, later AutoLisp.
This is the ability to more finely describe the entities to be selected. Possible additional criteria would be layer, color, entity tag (see below), and entity type. Mike Riddle has already done some work in this area. Done by Kern Sibbald in Release 9.
These are text items which would be carried around with each entity drawn. They could be used to construct a bill of materials. 2.0 Attributes.
A sample program was suggested to demonstrate the capabilities of DXF files (or was it for entity tags?). 2.0.
This would be an extended CHANGE command, to allow modification of any of the properties of an existing entity. Extension of the CHANGE command from 1.3 to Release 9.
The OOPS command restores the last thing(s) which were erased. We need a more general ability to “undo” the previous command (e.g., MOVE). 2.5.
In some systems, the user can try drawing an entity; if it doesn't turn out as desired, he can reject it and try again. For continue commands like LINE, this seems like a nice approach. 2.0 for lines, 2.5 UNDO for everything else.
Currently, the “L” modifier allows the user to select the last entity in the redraw file. A more general ability to select the same set of entities as most recently selected would be useful. 2.5.
The current LAYER command, with its embedded COLOR option, is confusing to users and should be reworked. Ongoing process. Dialogue box introduced in Release 9.
Our current GRID command produces a square grid with specified spacing (within certain limits), with the grid origin at (0,0). We have been asked to provide grids with differing X and Y spacing, isometric grids, offset and rotation capabilities, and something better than the “5 to 50” dot limits. 2.0.
Similar to the above GRID enhancements. Differing X and Y spacing, isometric snaps (or is that isometric ORTHO?), offset, rotation. Also, the ability to snap to the nearest of a list of arbitrary points. 2.0.
Some systems can display not only a list of the available drawing parts, but a sample of each one. This is desirable. Release 9.
To list a disk directory or delete a file, it is first necessary to exit AutoCAD. These facilities should be provided while in the Drawing Editor. 1.4.
This would allow the user to rotate the display to work on a section of his drawing which is not easily visualized horizontally. Release 10.
Currently, the only way to draw an ellipse is to create a CIRCLE block and INSERT it with adjusted X and Y scales. 2.5.
Anything which can be done via INSERT should be possible via ordinary commands (see ELLIPSE, above).
Allow scale factors and rotation to be applied to the individual entities in an “INSERT *”. 2.5.
We can now left-justify and center text fields. Right-justification would complete the set. 1.3.
Architects like to work with feet and inches. We should be able to handle them in input, and display them in STATUS, LIMITS, DIST, and DIM command outputs. 1.4.
Names should be assigned to many of AutoCAD's internal variables, and commands implemented to display and change their values. Some of the names could be documented for users, while others would remain secret for development and debugging. 2.1.
Discussion here included “smart parts” and “parametric entities”, which would prompt the user for any needed parameters and use those parameters in expressions. It was also felt that a good macro feature would enable us to create all sorts of new entities easily. Perhaps more importantly, the users could create them also, taking some of the burden off us. AutoLisp in 2.1.
Now that we've done a few conversions and have the package running on a variety of machines, we should take a careful look at the device driver routines, with an eye toward restructuring them. Some new common service routines might reduce the work needed for future conversions. Ongoing process.
Users sometimes forget what layer they're on, and whether or not SNAP or ORTHO is in effect. Use of the bottom right-hand corner of the display to indicate mode settings was proposed. 1.3, improved in 1.4.
When drawing something like a continued sequence of lines, it is sometimes necessary to SNAP or ORTHO only some of the segments. Currently, the user must end the LINE command, issue the appropriate mode command, and begin a new LINE command. We could provide control keys to allow mode switching during a command. 1.4.
Again, this might fall under the general polyline-with-width implementation. 2.1. Doughnut command in 2.5.
Some hardware displays can draw “rubber band” lines and rectangles very quickly. A rubber band could be used along with the cross-hair when entering the “to” point of a line or trace, and when pointing to indicate a rotation angle. A rectangle could be used when selecting the objects in a window. The core program could indicate the preferred cross-hair type, and the base point, to the “DSMARK” routine, which would draw a normal cross-hair if it couldn't do the preferred type. “DSMARK” would save the necessary information so that “DSCMRK” could clear the previous cross-hair when needed. 1.3.
An ability to add a slant of a specified angle to an existing text font would be useful, but we should avoid prompting the user for too many things; the TEXT command already asks for insertion point, height, and angle as well as for the text string. 2.0.
Some design work has been done on a new capability for text font definitions (to support more than just 16 vector directions), and some fancier text fonts, including italic, have been constructed and are waiting for this feature. 1.4.
The LOAD command permits the user to load a new text font at any time. What we don't tell him in the manual is that the next time he REGENs the drawing, all his old text will now appear in the new font. Only one font at a time is actually supported. We should look into adding a multi-font capability. Again, we should be careful not to overload the user with prompts from the TEXT command. 2.0.
Our numeric ZOOM factors are confusing to users. “ZOOM 2” does not necessarily mean “double the size”; it is relative to the original drawing size, not the current display.
Also, “ZOOM 0.1” might result in a small drawing in the lower left corner of the screen, and a subsequent “ZOOM 1” might leave you with a blank screen. 1.4.
It was proposed that the user could assign “view” numbers to various portions of his drawing (with associated zoom, etc.). This would allow switching from one area to another rapidly, without the need for several PAN or ZOOM commands. This might fit in nicely with the “point variable” feature (e.g., “VIEW KITCHEN”). 2.0.
Performance optimization. Freeze and thaw in 2.1.
The REPEAT/ENDREP facility is limited, and can cause confusing results. A capability to form a radial array would be useful. Array command in 1.4 REPEAT/ENDREP removed in 2.5.
Currently, our redraw file contains only vectors. Circles, for example, are composed of many small vectors, and cannot utilize the circle-drawing capabilities of various displays and plotters. Even if we could use these hardware features, we'd still need a way to identify such an object when it is pointed to; this currently depends on the vector approach.
This is the ability to simply select a polygon (polyline) and compute its area or perimeter. Our present AREA command requires the user to specify the polygon vertex by vertex. 2.6.
Currently, QPLOT operates only on Epson printers. Other dot matrix printers are popular as well, and could conceivably be used. This might require additional code in the new Configurator. General printer plotter support added in 2.1.
A three-dimensional capability is desirable. It appears that an “extrusion” feature might be relatively simple to implement and sufficient for some users. Could be an extra-cost option. 2.1.
These are items whose value to the program is questionable, or for which additional research is needed before we decide to implement them.
Should color be associated with an entity rather than with a layer? 2.5.
Although the ANSI standard specifies that unidirectional dimension text is preferable, we have been asked for the ability to have the dimension text aligned with the dimension lines. 1.4.
This would allow the user to “sketch” his drawing just as he would on paper, without regard to precision. Once the sketch is done, it could be SNAPped (or even ORTHOed) into a precise drawing.
When SNAP mode is on, some systems only move the crosshairs from one snap point to the next. This makes it very evident that SNAP mode is on. 1.4.
???
??? We might not have known what it was, but that didn't stop us from putting it in 1.4.
A general “drawing type” facility was proposed. A drawing type could have an associated default drawing size, resolution, menu file, and even a skeleton drawing (such as ANSI title boxes). 2.1.
Some systems allow you to draw several boxes, for example, and then adjust them so that their top lines align horizontally.
This is the ability to move an object across the screen with the cross-hairs in real time, as opposed to erasing it and redrawing it in its new location, as we do now. “If it can be done on an Apple, we should be able to do it on our machines.” 2.0.
This wasn't discussed at the meeting, but I've had a couple of user requests for it. These guys have large mainframe systems with large CalComp plotters, and don't want to buy another plotter to hook up to their AutoCAD system. We tell them about DXF files, and they ask if we have a program (or know of one) to do the job. The CalComp subroutine package is used widely enough that it might make sense for us to provide a “sample” FORTRAN program, but we'd have to supply the source, and support could become a problem.
|
|