Ultimate Wiki CMS

Created by: mlpvolt, Last modification: 13 Aug 2011 (13:50 UTC) by Richard Be-Involved
This page is intended as a feedback tool for wiki progammers from wiki admins and end users. Please add/edit/remove as you please. The actual features and upgrades currently planned for the next major release are viewable at New for R2. New feature discussions are happing at ReleaseThree

Different wikis have different uses. This version of the Ultimate wiki CMS is based on a wiki as groupware perspective.


see also: WhyUsebitweaver


Software Architecture:


  • modular
  • kernel can be upgraded separately from extentions
  • runs on multiple databases.
  • minimizes round trips to the server
  • compatible with W3C web standards
  • auto crash/bug reporting
  • icon table/index
  • system message text/index

Themes/Skins

  • place as many design choices as possible in the top level CSS.
  • top level CSS includes the "design map" to all other theme files.
  • theme creation wizard / checklist for all kernel design components.
  • kernel controls all design

Content Management System

This CMS is completely database driven, provides wiki pages, blogs, articles, comments, discussion boards and system messages as differing templates on the same basic architecture.
  • all content shares the following wiki features:
    • complete version history with compare any two versions.
    • robust object permission management (can set perms for individual objects)
    • watch feature (notify by email)

Group, and Category Permissions system.

The permissions structure inherited from tikiwiki was fairly robust, and by tikiwiki 1.9.2 a fully customizable group and category permissions regime emerged. This beats mediawiki and most other wikis because it allows for multiple private areas assigned to any number of groups (who may or may not have the same general permissions).

Basic logical structure

  • Category is a set of any objects (including modules)
    • objects can have many categories assigned/nonexclusive
    • categories are organized in heirarchies.
  • Group is a set of any users.
    • users can be assigned to many groups/nonexclusive
    • groups are organized in heirarchies (permission sets can include other groups)

Group Permission Sets

  • General Permissions_ have a default 4 or 5 level group heirarchy, which is editable. (so all new installs have a ready to go basic heirarchy)
    • anonymous - can alter little or none.
    • registered - standard user perms
    • editor - power user perms
    • admin - system wide perms
    • god - create and define admins
  • Batch Import and Export by group.
  • Allow delegation and promotion users may give permissions they have to other users. Delegate means permission is granted conditionally by a senior user and can be removed by same person (who may be implicitly/explicity responsible for their delegates). Promote is a "permanent" upping of perms (which can of course be removed by admins).

Category Permission Structure.


Category Permission Structure
The trinity of permissions checks
1. Can user of group Y do X for this module ?
2. Can user of group Y do X for this category ?
3. Are there any object specific exceptions for Y on X? (i.e. password required each time)

The more local the permission, the more dominant category overrides module and object overrides category and module. This is good because it enables the fastest application of all permissions by administrators.

Three kinds of categories
Categories can be used in two ways:
  • tags for sorting and structure
  • perms for access control

Sometimes you want only one of these functions, sometimes both. If the category is a tag, you probably want it displayed (ok maybe there are some display-categories-to-group possiblities)
don't want to display a category, just have it turned on to provide access control. In this way, there are three ways categories can be used.

  • a "tag" - which is a label only
  • a "tag + perm category (user viewable category with defined permission set)
    • perms only category (non user viewable category with defined permission set)

Objects should inherit permissions from object they were created from. (is their any reason why this should not be default behavior)

Categories from namespaces:

pagename begins with or includes string x is automatically assigned to category y.

Administering permissions.

Only two kinds of permission admin screens

Assign Users and actions to Groups.

Assign Groups and action exclusions to objects (same for modules catgegories and all end objects, except that end objects and modules don't have assign objects to category below.

users to groups and objects to category should have very similar interface.

Forms, features and formats.


This is a simplification of wiki CMS, in concept and practice. Rather than have a bunch of features, (blog, article, userpage etc. have these features available as forms (edit templates) that can be pasted into a blank wiki page.
Think of it as editing two levels deep:
  • end users edit the content in form fields.
  • power users edit at the second level to define fields and add html markup, including tables, columns, etc.

Forms-as-content templates can be created by a forms editor.

Forms combine template and tracker in tikiwiki. They include markup and data management.
  • forms replace/incorporate plugins in many instances
  • forms can be assigned to created objects individually or by category.
  • forms can be "locked" to a category wide template (change one to change all in category)
  • forms are embedded in version (not the other way around - forms can change over the life of the object.
  • using forms you can create and manipulate variables, and input strings.

With forms you can:

  • create structured page templates with predefined sections and content.
  • create pages with both editable and non editable content.
  • Collect data for a survey.
  • Display two pages side by side and edit either or both.
  • Create a report with user input of a database query.
  • Create a site wide tempate for user pages.
  • add plugins like datestamp, userstamp, in a specific place.

Pages, Bookmarks and Sections

  • bookmarks,toc entries and sections are all the same thing.
  • edit by section is possible
  • perms by section is possible
  • lock section is possible.

voting mechanism.

Voting mechanisms are like counters placed on a page (dumb to what the subject of the vote is, they just tally reponses.)
Simple voting plugin that
  • appears as small css controlled text box with x buttons.
  • acts as a tag that wraps around a section/subsection
  • defaults to locking that section for the duration of a vote.
  • icon based voting buttons (easy to change)
  • voting box can be "opened" (java) to explain:
    • details of vote
    • admin vote
    • results
  • must vote before results by default.
  • closed vote displays results by default.
  • basic voting configurations:
    • choose one (multiple choice)
    • chose many (approval)
    • rank preference
    • add text beside or mouseover text to for each voting icon.
  • displayed either as left or right or centered on page (text wraps or in a table with text)
  • admin cannot rig vote.

Impliment a "karma" and "mojo" system

The Karma system should collect data without server round trip, but displaying results can be loaded. Mojo is the "what have you done for me lately" of karma.

Karma system tracks the following:

  • User
  • group
  • Page views
  • edits by user
  • objects created by user
  • days between logins
  • pages watched by user
  • object approval scores (given by viewers)
  • edit approval scores (given by editors rating previous edit)
  • user to user "kudos"
  • "friendship" status
Each tracking item generates a variable, and then variables are weighted (weights can be customized) to achieve total karma score. Keep it easy to add/remove parameters later.

Karma reports should track both the function (absolute karma) and the derivative (mojo)

Wiki exchange

wiki to wiki communication module.
  • import wiki page on creation. (tikiwiki or media wiki)
  • import html page (from bookmark to bookmarK)
  • import page on view (master/client)
  • allow remote edit
  • mailin feature
  • heirarchy of external sites to import from
  • check for licence.
  • html to wiki markup conversion wizard.
  • rtf to wiki wizard
  • mediawiki to tikiwiki auto conversion.

  • search new page name for similar names before creating a new page.
  • exact match goes directly, rather than to list.
  • page names only, with option to search body.
  • a real search engine that ranks by relevance.
  • limit search by date of last modification - After and Before parameters
  • limit search by date of creation - After and Before parameters
  • limit search by Category - allow multiple categories
  • limit search by Tag - allow multiple tags
Support four types of wiki navigation
  • knowledgebase, organized by tagging, wiki hubs, or naming conventions (consistent NC = easy intra wiki navigation)
  • wikibook - organized with navigation UI (forward and back, up and down)
  • free form - breadcrumbs and what links here
  • structured - wiki as cms
    • right or left side collabsible menus
    • drop down menus

Admin Features

  • Mass revert (for spambots)
  • Editable error messages (all messages generated from a wiki page, essentially.)

Documentation

the hardcore "wiki people, eat your own dogfood" method.

  • project site contains knowledge base including:
    • a page for every page - for each and every admin/config screen there should be a page in the documentation, named after the url, which explains all the options.
    • pages which define and explain all commonly used terms and concepts, like what is a "category" in bitweaver.
  • no help by forums, nor by chat, nor by email. Those seeking help need to be trained to help everyone, and save everyone's time by only asking questions in the documentation wiki itself.
    • developers get the recent changes / changelog of the documentation as an rss. and answer only by editing pages
  • shut down all forums and listserves
  • don't answer questions by email or irc.
End result a somewhat messy but highly comprehensive and up to date documentation.

category: travelling documentation

all stable parts of the knowledge base should be categorized as such, included in a structure which publishes to PDF, and included in the startup wiki DB.

Comments

by dspt, 17 Apr 2006 (19:41 UTC)
I like the "hardcore eat own dogfood" approach to documentation