The list of commands in READ and the whole idea of the command menu is distasteful. I think maybe a simple command language or some form of directed prompting would be more in order. The current set of commands evolved largely out of a desire to test the various sections of the program in an orthogonal manner. I'm sure a more elegant set of ideas should underlie the commands.
You should be able to do a lot more with marks in the text. They should be saved when you sign off or view another document, and you should be able to clear them, easily display them, automatically set marks for all referenced sections, etc., etc.
There should be a +ALIAS command in SCAN. Sometimes you want a section to be selected when a word not used in it is referenced. For example, the ``necessary and proper'' clause in the U.S. Constitution might have a +ALIAS ELASTIC before it, as it is often known as the ``elastic clause''. It could be found by its common name, even if the user didn't know what it said.
There's another aspect to aliases. You might want to have an alternate word or words indexed every time a given word is used. This would let relevant sections be retrieved regardless of which synonym were used. For example: +ALIAS BONNEY=BILLY THE KID . would index ``Billy the Kid'' every time the desperado's real name were used in the text.
Inter-document references: A complete system should let you file all your documents and move freely between them. SCAN could implement this with a +KEYWORDS statement listing keywords in the document for the global dictionary. One could start at the global level and get a list of all documents with selected keywords, then move on to read them. References between documents would be handled by a +SEE statement. One might, for example, in a manual about the text editor, insert the statement:
+SEE SYSTEM REBOOT,LOAD,CREATE,FILE,DELETE,...where the user would be given a reference to the manual ``SYSTEM'' when one of the listed words were asked for.
SCAN should also have a command called +EXPLAINS. Before a section, one should be able to insert a statement like:
+EXPLAINS CHANGE,ALTER
and have it flagged as the section which explains those terms. Then the user reading the document could ask for the explanation of a term (rather than just the references) and get the section providing the most basic definition of the term.
When you're reading a real document, you can make marginal notes. READ should allow this too. The master copy of the document remains unchanged, but a user can ``annotate'' any section by typing in text which gets saved in a special notes file belonging to that user. When the section of the document is viewed, the user can see that he's made notes, review the notes, and edit them as desired.
The format SCAN stores the text in is wasteful of space, and results in each document being stored as two files (.RAT and .REF). This is because I was lazy. Fixing it wouldn't contribute anything to evaluation of the product idea. In a production system, one file should contain all information for a document, and the document text should be compressed using the ``polygram compression'' algorithm used in SPELL. Also, a simple encryption should be done to protect documents from being ripped off by the honest and naive. Whether the user is allowed to make a hard copy or store decoded text in a file would be controlled by a flag on the copyright statement in the document. Compression is very important because the value of this system depends on how many documents you can keep on-line.
There should be a way in READ to locate text by section title as well as by word references. I'd suggest a command which lets you specify words from the section title. It scans the section titles and looks for a section title containing all the words you used in your specification (regardless of order). If more than 1 were selected, you could look at them and choose the right one.
More general facilities should be available for moving around in the text when looking at text with READ. You should be able to:
These facilities are why I think that a ``command line'' at the end might be better then the menu/view mode presently installed.
Also, should we encode the hierarchical structure of the document? We know the levels based on the encoding given to SCAN. We might want to say, ``Go to the next chapter'', or such.
One of the most complicated design tasks is the ``rooter''. I think
the guts of the
hyphenation algorithm are a good start. We
want to index the original word, then add the derivative forms,
flagged as such. Then we can retrieve based on the exact form, or
any derivative form.
I don't expect most people to make as much effort encoding a document as we might make in indexing manuals for distribution with this thing. Thus, SCAN should be far more intelligent in breaking up documents into sections based on heuristic rules. We'll need to learn what information there may be in a WordStar file, for example, which would help in this task. The utopian idea is that once any document is written (letters, etc.), in an office, the original text is archived, and the formatted text is run through SCAN and saved on-line. Anybody who refers to it does so with READ. This makes references more productive, saves disc space, aids in building a master document library, and allows readers to make annotations without either changing the original or copying it.
Don't be upset by how slowly SCAN runs. I used a stupid merge algorithm in sorting word references. It should be able to be speeded up to run faster than WORD. For evaluation, it serves.
Yes, READ is awfully fast, isn't it? The sneaky way it looks up indexed words remains fast even with very large documents.
You can also use READ to aid in access to paper documents. To do this, just make WORD crank out a:
+1 Page number
item in the HEADING macro. Then all sections will be flagged with the page number.
This drawing was, to my knowledge, the first actual drawing ever done with AutoCAD (other than scribbles made while testing the program). I initially drew it on AutoCAD-80 before text was even working, then added detail as parts of the package were implemented. The drawing was made by taping the cover of a Time magazine issue from late 1981 featuring the shuttle to a HI-Pad digitiser and tracing the drawing. The picture in the magazine wasn't precisely a face-on view; that's why the drawing is slightly asymmetrical. This drawing was also the first BLOCK ever used with the INSERT command, and the first drawing ever to be plotted with AutoCAD (on a Houston Instrument DMP-8 plotter). The CHANGE command was initially implemented to help clean up the raw digitised coordinates in this drawing.
Editor: John Walker