The basic wiki concept is very simple: Everyone can edit a page, either using an editbox which is always at the bottom or following an "edit this page" link. New pages can be created by linking to them and then following the link to a non-existent target. HTML is not necessary, and pages are interlinked using specially formatted links for easier editing.
Usability is essential for wikis: One click, one key, one cookie too much and people will not participate. Because of such considerations, many wikis have no security measures whatsoever -- really anyone can edit a page, and the social collective makes sure that rules or netiquette are not violated (by fixing improper changes). To aid such self-regulation, previous versions of a document are often stored. Many wikis also have a "RecentChanges" log, which shows previously changed pages (and sometimes highlights them in the text).
Integrating wiki-technology into Scoop would have a major advantage: Scoop already has an account system which can be used as a basis for assigning access rights to prevent abuse. It would also be easy to maintain several separate wikis, just as it is already possible to maintain several diaries. Here is a basic concept for integrating wikis in Scoop.
Creating a Wiki
Any user can create wikis through a "Your Wikis" interface. When a new wiki is created, the user will have to enter the following information:
- Wiki identifier (alphanumeric, 11 chars, no spaces)
- Wiki title
- Wiki description (multiline)
- Access type:
- Blacklist - Every user can edit, users can be banned
- Whitelist - Users must be invited before they can edit
- Content license
- GNU FDL
- Public Domain
- All content copyrighted by respective authors, permission to modify as granted in context, no permission to copy
After a name-check, the wiki is created. The wiki data can be changed later. The Your Wikis interface now allows the creator to access his wiki, to maintain blacklist or whitelist, and possibly to add other maintainers who can manage these access lists.
When the wiki maintainer first accesses his wiki, he will simply get a page with the wiki title and description, plus the edit controls (I suggest putting the textarea form element itself on a separate page in order to save bandwidth).
Editing Rules
In the interest of readability and usability, wikis will require simple editing syntax. Most important are internal links to other pages in the wiki. These could be added by typing [linkname], for example [wikis are cool] (instead of a typical wiki-style: linking to pages by shiftingTextCase, which makes text very hard to read). Square brackets could be typed by [[doubling them]].
In conventional wikis, a link to a non-existent target is not underlined but has a questionmark with a link to an edit page to it. I suggest using a different visual style, perhaps underlined links for existing targets and non-underlined ones (CSS style text-decoration:none) for non-existent targets.
Other text should be HTML, perhaps without <P> and <BR> (automatically interpreted), so that plain text can be used. When you edit a page, you can optionally enter a description of your transaction for the logs.
Propagating Wikis
How do other people learn about new wikis? First, of course, through the conventional channels: Relevant wikis can be announced in diaries, stories, comments and on external pages. Additionally, however, there should be a public wiki directory, where wikis are browsable, 50 wikis per page, sortable and searchable by different criteria (creation, date of last change, number of changes, description, creator etc.). At first, just listing them recent first will be enough.
Recent Changes and Rollback
The changelog and rollback features are perhaps one of the most complex aspects of the system. There are several stages possible here, starting with a totally changelog-free system that is kept in order through the access control lists. In the second stage, changes would simply be listed, but it would not be possible to display previous versions. The third stage would, after saving a page, create a diff entry for a table where the changes to the previous version would be stored, so it would be possible to roll back step by step to get to a previous entry (e.g. << and >> controls, where it would be clear that you are in "rollback mode" - no saving possible for security reasons, if you want to save, you have to copy the text from the textarea field, go back to the current page and save it).
Administrative Limits
A Scoop admin will at least want to limit the following aspects of wikis:
- wiki: yes or no - use the wiki functionality at all?
- wiki_per_user: how many wikis can a user create? 0=no limit
- wiki_allow_images: should <img src> be an allowed HTML tag in wikis?
- wiki_pagesize: how many bytes may an individual page have?
- wiki_pagenum: how many pages may a single wiki have?
- wiki_rollbacknum: how many previous versions of the document to store per wiki?
- wiki_historylines: how many lines of wiki history to store per wiki?
Advanced Features
It would be nice to be able to link to wiki pages from within elsewhere in Scoop by using syntax such as [wiki-identifier::wiki-page]. Wiki-access rights should be selectable in the "Groups" interface: participating in wikis (wiki_edit), creating wikis (wiki_create), deleting your own wikis (wiki_own_delete), deleting any wiki through the directory or from the wiki start page (wiki_foreign_delete), editing wikis you have no access to (wiki_foreign_edit).
Storage and Editing Operations
Wiki pages are stored in wiki-syntax in the database and dynamically translated to HTML. This makes it possible to easily change the wiki syntax (e.g. add features like footnotes) without regard for reverse translation. Caching should significantly speed up page retrieval most of the time. Re-generating a page will be necessary whenever the whole wiki is changed, because some links may have become valid or invalid, and their appearance needs to be changed (the alternative is modifying relevant pages, which would require an additional table of all links to be efficient). Dynamic link apperance is an essential feature for wikis because it allows a high level of interconnectedness, even when the target pages don't exist yet, motivating users to create new content.
All wiki pages could be stored in a single table with a wiki identifier field, a page number field, a page title field, and a page content field (optional: page summary, page keywords, ...). Wiki maintainer information, blacklists, whitelists, link lists, changelogs and other relational data should be stored in separate tables.
The changelog would be a fairly simple table that stores the wiki identifier, page number, date/time of the change, (optional) description of the change, user who made the change, (optional) difference between the changed page and the old page. Blacklists and whitelists would be simple Wiki-ID & user-ID tables.
Implementation Summary
The stages of implementation can be summarized as follows:
- Stage 1
- Basic wiki creation and editing functionality
- Administrative limits
- Stage 2
- Blacklists and whitelists
- Simple changelog
- Wiki directory
- Wiki group rights
- Stage 3
- Rollback features, improved changelog
- Links from elsewhere within Scoop
- Advanced directory filters and sortings
- Advanced wiki syntax
- Stage 4
- Ratings and trust/mojo
- Multi-language editing
- Highlighting changes
- ...
Conclusion
I believe wikis would be a very powerful addition to Scoop. Possible uses include collaborative book and story writing, link directories, glossaries, encyclopaedias, FAQs and other document archives for reference within stories and comments, personal pages ("homenodes"), project pages, notes, user group communities and much more. The integration into Scoop would allow some interesting new possibilities traditional wikis don't have, e.g. reference, announcements etc. It would also have the vast advantage of making use of the existing user database. While it may place an additional load on already stressed sites, the feature can easily be opted out by the administrator. The implementation can take place in several separate stages. Maximum usability should be strived for through simple syntax and style.
