We describe the origin of wiki technology, which has become widely influential, and its relationship to the development of pattern languages in software. We show here how the relationship is deeper than previously understood, opening up the possibility of expanded capability for wikis, including a new generation of “federated” wiki.
~
Wiki's roots go back to Pattern Languages where pages represent Information that can be applied in the Context created by its antecedents. We extend application to computations performed by plugins using Data found before it in the lineup.
We promised our initial supporter we would create a data wiki, something that would do for numbers what the first wiki did for words.
We translated an awk script from the '80s to a plugin to show we could capture useful Computation within the wiki's text format. See About Calculator Plugin
We completed our first year of exploration with specific attention on the complex and many dimensioned sustainability properties of materials. We paused to look back before heading forward without further financial support. See Federated Wiki at One
# Numbers
Michael Mehaffy understood why Ward Cunningham had spread calculations across the pages that explain them. His own interests were in quantifying the properties of neighborhood scale pattern languages so that social and environmental impacts could be made more real to planners, designers and the ultimate inhabitants of a space.
We improved the Method plugin as needed for modeling in the pattern language WikiPLACE where each pattern chosen amends a basic calculation with adjustments even when chosen from different sites.
We developed methods for recalculation of pattern sequences listed only by name and subsequent interactive adjustment by multiple parameter sliders. See About Reduce Plugin
Mehaffy's greenhouse gas modeling
We extended Method calculations to include formulas, conversion factors and validated or inferred units in support of Mehaffy's greenhouse gas modeling. See Hacking Wiki's Methods and Prospects for scenario-modelling urban design methodologies.
# Graphs
We became interested in the graph structure of the growing federation. We built several scrapers and visualizations using d3.js and neo4j. But our users reminded us that they were more interested in graphs, such as knowledge graphs, in wiki rather than of wiki.
We integrated the elaborate Cytoscape graph rendering engine in pilot form in a video conference during the Mozilla Festival Science Fair. See About CytoDemo Plugin
We were unsure how to exploit the versatility of the Cytoscape package with input from a federation. We revisited the federating strategy that had worked with numbers by making a small plugin that would capture a fragment of a larger graph and later combined across a lineup chosen from the federation. See About Graph Plugin
The CytoDemo could then render whatever graph was assembled from parts. We added the GRAPH configuration to the Transport plugin that would trigger the same assembly. With this we could export to the venerable Graphviz package (or any other server-side application) and bring back its rendering as an SVG image.
We developed drag and drop editing of graphs and used it to reconstruct two different sub languages extracted from Alexander's A Pattern Language. Each resides in a different site but can cross and merge when assembling with both in the neighborhood. See Patterns Together
# Places
Through a similar collaboration we put new energy into the Map plugin which had languished for several years. With ambition to do much with GeoJSON we started small with place markers that could be entered as markup text copied from elsewhere.
We extended the plugin so that it could source markers to other plugins and read those markers itself too. This lead to an organization where place pages would contain a map with a single marker. With a series of these open one was offered to show places together on a map configured to do so. See About Map Plugin
We developed various workflows involving other online map services. We felt the need for interactive planting of places on an existing Map, much like our drag and drop Graph editing. We adopted a mixed approach where shift-double-click would plant a marker and double-click would open the markup for labeling the coordinates just added.
We integrated our Map plugin with the newly inaugurated Portland Biketown system with a plugin, Bikeshare, which reads the GBFS station information format used by any number of cities. This plugin could source hundreds of markers for a whole system but became more interesting when it read places of interest from upstream pages and then added only bikeshare stations near these. See About Bikeshare Plugin
In use we found sometimes we liked maps with lots of places and sometimes only one. We revised the Map marker sourcing logic to do both, one when one has been selected with a popup identification and all markers otherwise. See Hip Portland