Here are some thoughts on how to implement the qooxdoo manual requirements.

(”model-view” arch)

To fullfill all those requirements, I envision a “model-view” architecture, where the whole application is logically divided into the “model”, which are the individual pieces of information aka wiki pages, and the “views” that present different views onto this model. Views could be link pages, pre-fabricated searches or other presentational means.

The indivdual information pages will be written and stored in some directory or namespace structure, which should be simple and is not of paramount importance.

The central view will be the manual site map.

• Editing: assigning tags to documents
• pre-fabricated searches: using the tags

The manual site map follows a basic table-of-contents approach, as you would usually find in any decent manual. Guiding principles are a systematical and comprehensive presentation of the available information bits.

In the next step the site map could provide toggles to switch between something like “standard” and “advanced” view, where the standard view would show less and the advanced view additional nodes that are more useful for an advanced audience. More fine-grained (”beginner” - “intermediate” - “advanced”) and topic-oriented (”hints&tips”, “practice&exercises”, “how it works”, ...) toggles are imaginable, to add or remove information nodes from the view. It looks like the our standard API Viewer and Test Runner frame could be re-applied here, although not necessarily as a qooxdoo application.

Every information node (page) has at least to be represented in the site map. No existing information node is only represented outside the site map. Among other things this means that every new information node is linked from the site map.

Alternatively to the site map views onto the information nodes could be organised in various topical “tours”, where the user is taken through a special selection of nodes that pertain to a specific topic or task (Reminder: It is essential that those tours only provide different views (selections) onto the existing information nodes, and do not add new nodes that are only accessible through them). Possible tours could include a quick start guide, working with widgets and Ajax, defining themes, etc.

An automatically maintained standard keyword index of the manual would be desirable. Page authors could tag keywords in their texts, and an automated process could collect those keywords into an index page. The hyperlink for each keyword would trigger a pre-fabricated search that returns a list of all pages where this keyword is containted. This way, the references for each keyword are automatically maintained even with added pages that do not specifically tag this keyword.