Revision [1825]
This is an old revision of CategorySystemOverhaul made by NilsLindenberg on 2004-10-12 17:17:04.
Category System Overhaul
The category system used in Wikka needs improvement, and I'm looking for ideas and comments. -- JsnX
Current system:
User adds a wikiword category tag to each page, such as CategoryDevelopment.For more information, see WikiCategory.
Issues with current system:
- Not newbie friendly.
- Non-obvious, making it easy to forget to add a category tag.
- Resource wasteful: Category changes are stored as page updates, thus added database entries.
- Time wasteful: Category changes cause pages to show in RecentChanges, forcing people to review them for what changed.
Proposed system:
User selects a category from a dropdown box during page editing.- Create a new table named Categories.
- Create an action for adding items to, and removing items from, the category table.
- Add a field to the pages table named 'category'.
- Show a dropdown box during page editing that lets the user select a category. The value in the dropdown box is then saved in the 'category' field for that page.
- Create a new category action that will list the available categories.
Issues with this proposal:
- As proposed, this will only allow one category per page.
Ideas?
Multiple categories per page
You say: this will only allow one category per page
This is not necessary. If we want to allow more categories per page, we might think of storing sets of values (I recently had the very same problem with a user management system in which users can belong to different categories):
- On page editing/creation, instead of a dropbox, display a list of check boxes
- a system-generated unique-key (TINYINT), invisible to the user and handled by the system for cross-referencing the wikka_pages table (whose category field will then contain a simple comma separated list of numerical keys, like: "1, 5, 7")
- a human-readable category label (VARCHAR), like "Documentation", or "Development".
-- DarTar
Yet another approach:
- categories table:
- id
- category
- parent (may be NULL for top-level category)
- maybe extra "administrative fields such as timestamp
This would take care of a categories hierarchy
- pagecats table:
- page_id
- cat_id
Now we can store many-to-many relationships between pages and categories; and everything is neatly normalized, too.
When a page is created/edited a dropdown (rendering the hierarchy!) could allow choosing one or more categories; there should be an extra option to (instead) create a new category and assign it to an existing one. Edits should of course also allow to remove a category for a page (while still allowing assigning or creating a new one). Note I'm using page_id, not page_name, in pagecats - on purpose, so the categorization belongs to the page version; a new page version should (initially) inherit all categories, of course.
That might become a tad complicated for an edit dialog; so maybe "categorization" sould be a separate dialog (handler). I'm sure there are nice examples around for dialogs for maintaining a hierarchy of categories. (Many CMS systems have something like that, I know there are demos around.)
Extra wrinkle: what to do with pages when a category is deleted? (Probably assign to the parent category.)
--JavaWomanJavaWoman, that sounds good. And a page showing the none categoriesed wikipages could be helpfull :)
--NilsLindenberg
JW, I confess I was thinking of a set of horizontal categories, not of a hierarchy of categories. The two approaches have different kinds of use and different pros/cons. The horizontal approach is certainly much easier to implement/maintain, the vertical approach requires some extra work, but I think it is worth the effort. I welcome the idea of a dedicated handler, instead of cluttering the edit page. -- DarTar
Kevin Yank from Sitepoint.com has an example in his book which uses checkboxes rather than a dropdown menu to allow multiple categories to be chosen.
--JamesMcl
Why a hierarchy?
The current system (admittedly not very user-friendly or at least not newbie-friendly) does allow a hierarchy of categories. I wouldn't like to lose that capability. The categories table as I proposed allows such a hierarchy without enforcing it: if the community "decides" they don't need a hierarchy they'd just not assign a new category to a parent - and that's that; it will be as flat as the users make it. (A maintenance handler could enforce a hierarchy, given such a data model, but I don't think that's necessary or even sensible.)
Another issue: conversion for an existing Wikka Wiki. A conversion utility (something definitely needed) should migrate all existing categories; and if that Wiki already has a hierarchy of categories, and the new system doesn't support that - what are you going to do? It's not easy to "flatten" and existing hierarchy into something still meaningful.
Definitely extra work, but are we in a hurry? We do have a system that actually works, even if it is hard to use. And I think categorization (and a user interface to support it) is important enough to give it careful thought.
-- JavaWoman
Perhaps we should at first define/think about, what a category-system could (should?) have for features:
- Pages should be able to belong to zero or more categories
- Cat. should be able to belong to zero or more cat.
- it should be easy to add/delete a category to/from a page
- a admin should be able to rename/delete cat.
- there could a page which lists all pages belonging to no cat.
- a admin should merge to cat./ divide a cat. into two or more
- a action like "nocategory" which prevents adding a cat. to pages
-...
--NilsLindenberg