History of Ultimate Wiki CMS
Version 6 | Current version | |
---|---|---|
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:
Themes/Skins
Content Management SystemThis CMS is completely database driven, provides wiki pages, blogs, articles, comments, discussion boards and system messages as differing templates on the same basic architecture.
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
Group Permission Sets
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:
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.
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 screensAssign 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:
Forms-as-content templates can be created by a forms editor. Forms combine template and tracker in tikiwiki. They include markup and data management.
With forms you can:
Pages, Bookmarks and Sections
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
Impliment a "karma" and "mojo" systemThe 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:
Karma reports should track both the function (absolute karma) and the derivative (mojo) Wiki exchangewiki to wiki communication module.
Navigation, Organization, and SearchSearch
NavigationSupport four types of wiki navigation
Admin Features
Documentationthe hardcore "wiki people, Eat your own dogfood" method.
category: travelling documentationall stable parts of the knowledge base should be included in the startup wiki DB. | 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:
Themes/Skins
Content Management SystemThis CMS is completely database driven, provides wiki pages, blogs, articles, comments, discussion boards and system messages as differing templates on the same basic architecture.
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
Group Permission Sets
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:
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.
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 screensAssign 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:
Forms-as-content templates can be created by a forms editor. Forms combine template and tracker in tikiwiki. They include markup and data management.
With forms you can:
Pages, Bookmarks and Sections
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
Impliment a "karma" and "mojo" systemThe 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:
Karma reports should track both the function (absolute karma) and the derivative (mojo) Wiki exchangewiki to wiki communication module.
Navigation, Organization, and SearchSearch
NavigationSupport four types of wiki navigation
Admin Features
Documentationthe hardcore "wiki people, eat your own dogfood" method.
category: travelling documentationall 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. |