![[Home]](http://meatballwiki.org/meatball.gif)
WikiMutants
MeatballWiki | RecentChanges | Random Page | Indices | CategoriesWikiMutants are web-based collaboration tools that started out as WikiClones but developed into a special-purpose production or presentation system. The requirements and constraints of the special purpose shape the mutations.
Varieties
Some observed varieties of WikiMutants are --
- WikiLog -- a normal wiki whose members primarily use their home pages for web logs
- WikiAsPim -- a normal wiki primarily used for activity scheduling, contact logging, and other personal information management tasks
- WikiLexicon? -- wiki-based encylopedias, fact, FAQ, and other information collections like WikiPedia
- NakedWiki -- one view for editing, one view for display
- GraphicWiki? -- macro-language modifications use graphic objects for display of gameboards, designs, etc.
- WikiFarm -- subsectioned or partitioned wikis-within-wiki
- WikiAsCMS? -- content management system wiki with enhancements for file uploading, cataloguing, access control, etc.
- DocWiki? -- document production using wiki for input, with modifications to handle output formatting
- WikiAsWBT? -- wiki used for developing and/or presenting web-based training and instruction
- ProjectWiki? -- wiki as a project development, communication and management tool
- ModellingWiki? -- wiki as a tool to analyze, model and simulate complex systems (e. g. large organizations)
- Other -- as-yet unimagined applications
Mutating Forces
The primary driver for WikiMutants seems to be the HammerSyndrome. A wiki is such an engaging and compelling concept that its adopters become adapters who seek out applications that can be shaped with their favorite tool. Wikis have been used to replace other tools or tool collections used for collaboration.
WikiFetishism aside, a pure wiki is like a Swiss Army knife, a tool that serves many purposes, none of them very well. As soon as one contemplates using a wiki for a specific purpose, all sorts of design deficiencies become apparent. WikiMutants are better screwdrivers, better corkscrews, better bottle openers, not better wikis. Paradoxically, the wiki's minimalist design is both its greatest strength and its greatest weakness.
So far, there has not arisen a wiki-specific function or process, something that can be done only as wiki, something not already being accomplished in some form with other tools. The wiki concept is a springboard improvement on a diving platform for performing aerial acrobatics, not a trampoline that produces routines impossible to do with any other apparatus.
Minor Mutations
Once beyond the initial concept of free-for-all web-based collaboration, the creative programming energy expended on wikis goes into tweaks and modifications such as --
- WikiClones -- the original Perl version spawned Python, PHP, ColdFusion, ASP, Common Lisp, Scheme and other (Curl?) variants.
- Input syntax -- wiki authoring syntax now covers the gamut from the original blank-line plus lists and bold/italic notations to full-blown raw HTML formats
- Input interface -- the HTML textarea input box has evolved into in-browser WYSIWYG
- File formats -- there are flatfile, DBM, mySQL, PostGRES?, and a variety of custom formats for handling the wiki files
- Display Interface -- the basic, brutal wiki interface has been tweaked for layout, structure, user options, graphic adornments, and CSS-controlled presentation
- Output -- absolute minimal HTML has given birth to more up-date XHTML-compliant page-generation versions
- Information access -- subpages, InterMap notations, and indexing schemes have developed to enhance the retrievability and categorization of wiki-produced information
Desired Future Mutations
Based on trends in other aspects of web-based computing, some future wiki mutations that could extend the HammerSyndrome to new areas could be --
- Portal tools -- user personalization to include layout, format, color, web channel selections would open the way to subscription-generated income
- XML -- adoption of XML file-formatting beyond the current state of small experiments could lead the way to wide-spread use of RSS and ecommerce applications.
- Package or widget design -- special-purpose tool enhancements and attachments could support the adoption of wikis for courseware designing, distance learning, system and software documentation, even governmental feedback from voters and legislative development projects.
Perhaps when people are looking for more than a wiki, they haven't looked hard enough at a wiki. -- SunirShah
Exactly so, Sunir. That's why I named this page WikiMutants instead of CriticalWikiEnhancements. For a wiki-style community, current wiki tools (especialy UseMod) are perfect. There are applications, however, that could lend themselves to realtime collaboration with semiautomatic display formatting without becoming wiki communities. Such applications may benefit from specific mutations into non-wiki syntax, or display modes, or interaction processes, while still acknowledging their wiki roots. This is not to denigrate, challenge, or compete with pure-state wikis. It is only to say, "You know, I wonder how it would work if...." -- JerryMuelver
From WikiFetishism: Without limitations, there are no definitions.
I'm trying to think of a word (or WikiWord) for this: explicitly defined structure supported by the system versus structure defined by convention supported by culture. In the first place, you have a limited purpose and specialized app: an address book program with defined fields. In the second place, you have a very free-form and multi-purpose app: a wiki with content containing commonly used and agreed upon keywords and format. It's a bit like structs versus hashtables. It takes more of the intelligence out of the system and requires more of it to be picked up by the users.
In some cases, there's a point where too much freedom is too much work in a piece of software. Then again, it could be a matter of understanding, but that too is work. Seems to me that some WikiMutants trade freedom for letting the system take care of some details. --LesOrchard
What freedom? You have either a TechnologySolution or a CommunitySolution, but restrictions nonetheless.
The community solution requires continuing effort by human beings, eternal vigilance and all that. Which is OK if you're a busybody, but it means that wiki communities will be small. If you handle more of the functionality with technology, you open up the system to lazier and stupider people. The community expands. Good or bad? Depends on who you are.
Aren't all true communities small?? Literal BarnRaising doesn't scale to thousands of people, so maybe metaphorical BarnRaising doesn't either. Cf. TheTippingPoint on the rule of 150.
CategoryWikiTechnology