We are defining an authoring tool for wiki as something distinct to a refactoring tool. An authoring tool either brings new information into wiki, creates new wiki-page content rendered by other plugins (refactoring tools).
In this way authoring tools are also different from configuration tools, as they do not change the appearance or function of wiki - they simply serve to provide means to import of export content into wiki. It should be "safe" to discard the tools, and refactoring within wiki will still continue to work.
Considering the act of authoring in wiki as it's own domain, leads to a better comprehension of use, and allows us to integrate developers more closely with the wider writing community on an equitable and no-hierarchical basis.
# Loose coupling
Authoring tools are naturally decoupled from wiki. Once information has been brought into wiki, it is self contained and ready to be refactored within wiki without reference to the external source material.
Marking the provenance of the import, is sufficient to give appropriate citation, and to provide a link back to the orginal material.
Software tools can take advantage of the information in these Citation Links to help augment or even automate keeping the imported content into wiki up-to-date. See Medaiwiki Transport and Citation Bar for an example.
Exporting content from wiki, to a static HTML5 site, or to HackMD markdown, is similarly decoupled. Tools may help augment the refactoring of exported content based on updated wiki content via continuous deployment, but nothing breaks should the link between the exported content and wiki be severed.
# Snapshots
Imported content is considered to be a static snapshot of external content. Exports are similarly an exported snapshot of the more dynamic wiki content.
Snapshots may be timestamped, and signed by authors or transporters marking their provenance.
Editing imported content should provide the option to re-access the tools that originally imported a snapshot when the external content has changed.
Double-clicking on items that originated via an import allows independent refactoring of content within the wiki.
It is not clear whether access to the import tools should be provided at the item level or the page level. Current Mediawiki Transport implementation stored json in the Create Action of the wiki page, enabling meaningful access to the import tool-chain at page access level. Forked paragraph items do not preserve this behaviour. This continues to seem appropriate.
# Microservices
Microservices are the defacto loosely coupled architecture for federation json. We seek to give them independent status within the federation with a particular role as authoring tools.
Transporters are microservices designed most commonly to support Drag-and-drop import of external content into wiki.
We seek to extend the range and domain of transporters to the general class of microservices that work with federated wiki json. As described here these export and import oriented microservices are authoring tools.
# Integrating the developer experience
Developers creating microservices outside of the wiki-client should not be considered as separate citizens. Wiki can serve as their basis for documentation, and presenting their work, and be firmly integrated into the Developer experience.
Similarly authors need to be able to find suitable authoring tools to support their work, understand their function, and add them to their writing environment should they find them useful.
The current Transporter mechanism allows them to take a first step doing this by specifying the REST url of the microservice in a plugin. This mistakes the domain of action of the plugin - indicating that the functionality is only available to the plugin on a particular page.
# Halo of integration
Authoring Tools should be marked and organised as such. There should be a place to find them, and a way of identifying them as a separate class of tools that add loosely coupled import and export functionality to an entire site.
We propose using a distinctive halo colour for pages containing authoring tools, and a means to navigate, access and install thee tools on a site using the conventional means available to wiki.
# Proposal
We propose being able to navigate from the welcome-visitors (home) page of any site to a Tool Dialogue Page from where the author can navigate within a distinct Wiki Dimension.
Installing an new import function would be as simple as forking a page to this new Tool Folder, Authoring Tool Folder, or Configuration Tool Folder. Simplicity would indicate having a single Tool Folder for all classes of tool described here.
The experience of writing this specification, and considering the implications makes me think that we are better served by creating separate folders representing distinct dimensions of functionality that already require different types of tooling, and may well need differing access permissions.
# A place to start
I propose a simple starting place that has implication for the wiki-client, and extends the architecture of the server. The former is good, the latter bad.
- Redefining Flag Clicks - Adding a Authoring Tools Folder to the server - Implementing a Universal Drag-and-Drop - Creating a Welcome Authors page