^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)).

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:

*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

*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 Category and Object Permissions system.
*Category is a set of any objects (including modules)
*Group is a set of any users.
!!!Group Permission Sets
*Default 4 or 5 level Group Heirarchy, editable
**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.
*users may give permissions they have to other users

!!!Category Permission Structure.

Permission Structure
1. Can Y do X for this module (based on group)?
2. Can Y do X for this object (based on category)?
3. Are there any object specific exceptions for Y on X? (i.e. password required each time)

iow category overrides module and object overrides category and module.

*There are three kinds of categories
**tag category - a label only
**tag + perm category (user viewable category with defined permission set)
**perms only category (non user viewable category with defined permission set)
*objects may inherit permissions from object they were created from.

!!!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
*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:
*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.

!!Navigation, Organization, and Search
*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.
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)

!!!the hardcore "wiki people, Eat your own dogfood" method.
*project site contains knowledgebase including all relevant terms.
*visitors as a question only on the relevant page and in edit comment window.
*developers get changelog as 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 included in the startup wiki DB.
Page History
13 Aug 2011 (13:50 UTC)
Added to Search gunction - limit by dates, category, tag
Richard Be-Involved211.30.210.69
Current • Source
View • Compare • Difference • Source
View • Compare • Difference • Source
View • Compare • Difference • Source
View • Compare • Difference • Source
View • Compare • Difference • Source
View • Compare • Difference • Source
View • Compare • Difference • Source
View • Compare • Difference • Source