This document outlines my views on how Amigaguide could have been improved after V40. Please note that this document was written at a time when it seemed more likely that there would be future versions of Amigaguide. I have published it as it may interest some people to see how things could have been.
Amigaguide And HTML
It is important to realise that Amigaguide was not designed for the same purposes as HTML, so continuing introducing HTML features into Amigaguide is not necessarily a good idea.
HTML documents form a web of independent pages (although these are frequently organised into websites) — in contrast, Amigaguide documents contain a number of dependent nodes, and cannot assume any other Amigaguide document is available on the user's system (unless the guides are distributed together, in which case it would usually be a better idea to merge them into one guide).
HTML is intended to represent the logical structure of documents — although many presentational elements exist, W3C aims to remove these eventually, leading to the draft Cascading Style Sheets specification now available. Amigaguide is presentational, and is not intended to be a cross-platform language — there is only one viewer. Note also that in Amigaguide documents, whitespace is significant.
System Documentation
In future releases of Workbench, documentation for the entire operating system should be available in Amigaguide format to encourage its use. In particular, developer’s guides for writing Amigaguide documents should be written, as developers currently learn Amigaguide through looking at the source code for existing Amigaguide documents.
System documentation should be put in a standard drawer (for example, DOCS:) so other guides can link to them easily - for example, @{"SetEnv" link DOS:AmigaDOS.guide/SetEnv}.
Amigaguide Language
The Amiga datatypes system should be used fully by allowing Amigaguide documents to include arbitrary objects — for example, @{object ART:illustration.iff}.
Tables should be introduced. To avoid bulky code, it should be possible to use tabs rather than tags to separate table cells in tables with small cells — for example:
@table
@headers "Amiga" "Type" "Processor"
A500 Desktop 68000
A1200 Desktop 68020
A4000 Tower 64030
@endtable
Better navigation should be introduced — for example, @up to specify the ‘higher’ node in the document, and @see to specify other nodes to refer to.
Amigaguide Viewers
There needs to be a way to tell which links point to nodes that the user has already visited - perhaps making the button’s borders fainter, or dotted rather than solid. Also, links that execute AmigaDOS commands ot ARexx scripts should be indicated, otherwise they seem broken (as they don’t lead to other nodes).
Amigaguide suffers from a total lack of security — not only can links execute arbitrary AmigaDOS commands or ARexx scripts, but with the new @onopen and @onclose, scripts can be executed without user action.
A security manager must be introduced that alerts users before performing a potentially dangerous operation (such as formatting a disk).
The existing @keywords should be used, with a document search function being introduced to the viewer.