This topic is for working out some ideas that have been fermenting within me for some time about the nature and future potential of wikis and, in particular, TWiki. --
LynnwoodBrown - 30 Jan 2005
Introduction - Extrapolating a future of wikis
This inquiry started out for me as a kind of my-ideal-wiki or
TWiki:Codev.VisionsOfTWiki TWiki:Codev.TWikiWhatWillYouBeWhenYouGrowup.
What are wikis? Thoughts on "wiki-nature"
There's another story about a master who, on handing a beautifully lacquered bowl to a monk, asked, "What's the most important part of this bowl." The monk carefully examined the detailed and delicate gold work, the polish and sheen of the bowl's urushi surface and finally admitted he didn't know. "This part.", the master said and with a sweep of his hand indicated the inner volume of the bowl.
Common definitions of wikis, such as "simpliest possible database," "editable web," or "group whiteboard" have never been entirely satisfactory to me. Within the design of the original wiki, as well as in the on-going development of wiki-clones such as TWiki, I discern an underlying intention or
design sensibility which is much richer than these definitions convey.
I propose that a clearer articulation of this design sensibility, or what we might call "wiki-nature," could provide some guidance on future development. In other words, it would help us discern what features or design approaches best reflect this wiki-nature and thereby reinforce its distinctive character, or to put it more crassly, it's unique market position.
While I don't feel the common definitions of wikis do justice to their real nature, I have no problem with the essential metaphor implied in the term "wiki" or "quick." After reflecting on this for a while, I have concluded that all we need to do is expand on other nuances of meaning within the metaphor of "quick" to include the qualities of
directness, or
immediacy, or
shortest-route. Other examples or facets of this quality include:
- in the flow of task-at-hand
- least action or Wu-Wei
- "Reluctance to do unnecessary work is a great virtue in programmers. If the Chinese sage Lao-Tze were alive today and still teaching the way of the Tao, he would probably be mistranslated as: when the superior programmer refrains from coding, his force is felt for a thousand miles. In fact, recent translators have suggested that the Chinese term wu-wei that has traditionally been rendered as 'inaction' or 'refraining from action' should probably be read as “least action” or 'most efficient action' or “action in accordance with natural law”, which is an even better description of good engineering practice!" (Source)
- simple - few methods, many uses
- e.g. bullet list defines menus.
- non-model - changing underlying structure doesn't require constant shifting between application interfaces (modes). Lacks multi-level complexity. Contrary example is Mambo: going from Public, to member, to admin, to component interfaces (modes). Wikis are more like just "lifting the hood." Leads to a certain transparency.
- unimpeded
- program doesn't get in the way of task-at-hand by constantly diverting user into other modes.
- graduated complexity
- smooth transition from simple to complex
So close... On the verge of new kind of "application space"
I believe that wikis are on verge of a new kind of "application space." Beyond "application platform" - a different paradigm of "application."
Implicit utility versus explicit application
- Prevailing concept of "applications" is what I would describe as explicit application—i.e. separate, distinct functionality designed around internal logic. Form follows function.
- Wikis suggest rethinking application as "implicit utility" which means:
- Primarily used within context of topic, conversation
- primary focus not on internal logic/structure of the functional application (e.g. contact list, calendar, task manager) but rather on ease of use within context of regular activities, document-at-hand.
- application dispersed throughout wiki-space.
- Another name might be "Implicate utility". Association with David Bohm's concept of "implicate Order" (refs: 1, 2) is intentional.
- Yet another...ambient application? - context-centric application
- ambient - completely enveloping; "the ambient air"; "ambient sound"; "the ambient temperature" (WordNet)
- am·bi·ent adj. Surrounding; encircling.
- Explore where JotSpot achieves this or not.
EpiData = application data in context
What do you call data like actions, events, people, attachments within the context of a topic/conversation?- Not really "metadata" in that it is not really about the topic.
- It's incidence in the topic is significant, but its primary meaning and utility comes from how it relates to other topics/applications.
- Possible name: "epidata".
- epi- or ep- pref.:
- On; upon: epiphyte.
- Over; above: epicenter.
- Around: epicarp.
- Close to; near: epicalyx.
- Besides: epiphenomenon.
- After: epilogue.
- EpiData is application-related data within a topics that almost "rest on top of" the other information in the topic.
See
EpiData for further development of this idea.
TWikiRoadMap?
Priority developments:
- WYSIWYG
- Dynamic Data Sets
- Extension of topic includes idea. or formatted searches.
- Applications growing out of context of topic data. Foundation of implicit applications mentioned above.
- EmailToWiki?
- WikiDataSets?
- "Quick" creation of auto-updating data sets.
- Use case 1: DynamicFormFieldOptions?
- Use Case 2: Applibits, datacles, applicals or whatever...
- Fluid use of external data sets - easy import or linking (TWiki:Plugins.DataBasePlugin?)
- Forms simply a feature added to a topic. JotSpot?
- Physical storage reflects topic space. Reveiw discussions between TWiki:Main.MattWilkie and TWiki:Main.MichaelSparks regarding "what if topics were directories."
Break these out as:
- Wiki-architecture
- Wiki-interface (including Wiki-WYSIWYG}
- Wiki-data sets
- Wiki-file storage
Misc ideas
- Do use case of creating menu from topic comparing Mambo & TWiki.
Misc Twiki topics for reference