projectdoc Toolbox

Document types have their default location within a documentation space. These default locations are called 'homepages'. If authors create new documents they can send them to these default locations within a given space. Delegate spaces expand this feature to find the default location in associated spaces.

If authors know what information they want to keep accessible for any stakeholder, found a template to support their task, they may still not know where to put it. Every wiki may have a different structure. On the one side this is a strength of wikis. They can evolve and are refactored to a new structure once the problem domain has been better understood. One the other side the individualism makes it hard for teams to create a comprehensible structure to live in - for readers and authors. If documents of similar content are stored at different locations, they are probably hard to find. If authors cannot derive the right location for their document, other stakeholder will probably have a hard time to find it.

Projects of similar objectives may be served by similar structures quite well. Software development teams know that the actual location for a file is arbitrary, but it should be the same folder for the same types of files. Furthermore it would be useful if different projects would define the same locations. This way developers who are new to a team will find out easily where to look if they need to find Java or JavaScript source files or the folder where all the sources are compiled to during the build process. This is called a standard directory layout.

Homepages to store Documents

Each template is defined by a doctype that defines the basic structure of every document instance of this type. The structure is a compilation of properties and sections.

In projects documents of the same type tend to be accessed together. Think of documents that describe roles or personas. Or design decisions, meeting minutes, the documentation of aspects of a software architecture. projectdoc defines a default location called homepage for each (with some exceptions that should not bother us here) document type. The homepages are similar to index pages you may already know. There is only a slight difference. While index pages collect every page that has a certain label on it, the documents on the homepage are the most important documents of that type. There may be more documents that are children of these root types. Think of roles! There may be a role document that describes the most generic user of a system. Subdocuments of the User document may be specialized users, like Power User or Admin User. The homepage only has a reference to the User document and allows the reader to drill deeper into the hierarchy step by step. If the user needs an alphanumeric listing of all roles, the index page is still around. But the documents are typically not stored on the index page, but as pages of the homepage or as a descendent of one of the root documents of their type.

If you create a space, all homepages are created by default. The space homepage lists references to the homepages (either directly or indirectly).

Here is an example from a space created by a projectdoc space blueprint.

The 'Topics' link on the space homepage refers to the homepage of the Topic doctype. There is one document instance on this homepage called 'Installation Howto'. On the homepage there are more links to homepages of doctypes (for instance Tours, FAQs, and Glossary). If a team defines a basic structure for their spaces of a given type, new group members, who have worked with other teams on other projects, will have an easier time to get familiar with the domain of a new project. They still have to learn the new domain, but they are already familiar with the structure of the documentation for this domain.

Default Target to store Documents

Each page wizard for a doctype that supports a homepage, there is a flag to store the document either as a child to the current page (default) or to send it to the homepage for this type.

The screenshot shows the creation of a document for a role named 'User'. The author decided to store the document to the homepage of the 'Role' doctype instead of saving it as a child to the current page. The current page is the page the author viewed when she decided to create a new page by starting the wizard.

Delegate Spaces and Homepages

Some documents are relevant to more than one space. If you have a large project with multiple large components you may want to have a space for each component you describe. Each component may share the same roles and topic types. So there is no need to have them copied around spaces. Instead have them stored in a collaboratively used delegate space.

There may be more than one delegate space. Delegates spaces are specified in an ordered list.

Whenever an author sends a document to its doctype homepage, the document is stored to the immediate homespace page found in the delegate space hierarchy. Assume for instance that the current space has a delegate space with a homepage for roles, but has itself no such homepage. If a document of type 'Role' is sent to its homepage, then it will be stored on the role's homepage on the delegate space.

Resources

More information on this feature.

Doctype Home
Controls the location of the homepage of a given document type. Use the identifier of the doctype.
projectdoc Spaces
projectdoc introduces structure on a Confluence space. It adds the concept of homepages for document types.

More Features

List of features of the projectdoc Toolbox for Confluence.

Deep Links
With deep links properties from referenced properties can be accessed for rendering.
Delegate Document
Delegating documents transclude sections and properties from a delegate document. Information may be overridden.
Document Types
Document types allow to guide authors producing information of a given type. They also help readers to find the information they are looking for quickly.
Dynamic Linking
A document template that uses query macros enables documents to dynamically render links to a set of related documents. If new documents are added to the system that meet the query criteria, links to these documents are automatically added to the querying document. This feature is also called dynamic lists or automatic linking.
Enhanced Transclusion
Transclude more than one self-contained snippet and mark transcluded information for authors. The projectdoc toolbox allows multi-transclusion from one document and even several documents.
Extensible by Spaces, Templates, and Macros
Never be limited to the vendor's ideas: Create your own spaces, templates/blueprints/doctypes and macros based on components provided by the projectdoc Toolbox!
Guided Writing & clutter-free Reading
Do not clutter the view with non-information sections. Instead help authors writing identical structured content by the use of templates.
Information Systems Integration
Via a free extension information from remote information systems may be rendered on a wiki page.
Live Templates / Impersonator
Use the structure from a page and render it in the current page's context.
Remote Control
The projectdoc Toolbox supports rendering a page controlled by request properties. This way a URL controls the contents of a page.
Rich Custom Document Metadata
Authors may add any metadata to a document and use these in their queries. The metadata may be displayed or hidden. This way authors can use metadata target at the reader and metadata used for authoring purpose.
Single Sourcing
The projectdoc Toolbox provides doctypes and macros to support teams to modularize their documentation.
Space Hierarchies
Organize spaces in hierachies with delegate and search spaces.
Space Properties
Properties may be set on space level and are inherited through space hierarchies.
Variables
Space and document properties may be used as variables with the projectdoc Toolbox.
Web API
To integrate projectdoc documents with remote systems the projectdoc Toolbox provides a REST API. This API is installed separately with a free extension add-on.