The page WikiObjectUseCases describes some Wiki use cases which are strong candidates for implementing using WikiObjects. They all (as of 5-Aug-02) involve combining information across multiple wikis.

When it comes to extensions of a single wiki, the argument for using WikiObjects is less compelling. You could simply extend the basic support provided by the underlying wiki.

The use cases on this page are ones which could be achieved simply by more PHP code in the base wiki. My expectation is that as this list grows it will become apparent that some of these use cases can be generalised and move to the WikiObjectUseCases page.

==== Simple Wiki Discussion page

==

A simple discussion page would have a comment text box at the bottom where users can submit a comment that either appends or prepends the page with a timestamp. ==== Page rename function.

==

Renaming a page in PhpWiki is labor intensive. All the links to the page must be modifies and the new page created by copy and pasting from the old page and then the administrator must delete the orphaned original page. A simple rename function could handle everything with one click.

==Corporate Wiki Features ==

These features have actually been added to a base wiki at a company where I worked and have proven useful:

 'Example:' Meetings Record.  Whenever a new page is created with the title 'M'eetingXyz' the default empty page instead of saying 'describe M'eetingXyz is now created instead as a copy of page 'M'eetingTemplate'.  This template has standard sections in it for date and time, attendees, agenda, minutes and actions.  Another page M'eetingSummary lists all meetings in date order and shows oustanding actions from the meetings.

 'Example:' Bug List.  Whenever a new page is created with the title 'B'ugNnn' the default empty page instead of saying 'describe B'ugNnn' is now created instead as a copy of 'B'ugTemplate'.  This template has standard sections in it for date and time, person reporting the bug, description of bug, component where bug is believed to be, status (fixed/not fixed/feature request), priority, repeatability of bug.  Various pages B'ugsByDate, B'ugsBySeverity, B'ugsByCategory list extracts from these pages in glorious technicolour (red for priority one etc...).  If you edit a page such as B'ugsByDate you find that it contains a couple of function calls in square bracket syntax, one which gives a summary count at the top and a second which specifies the pages to combine and the sort order.

Suggestions for Corporate Use:

I've looked at, appraised, designed, extended, and in general supported several 'similar' systems to Wiki on a corporate level. One finds that most businesses and government agencies are always looking for similar things.

Your Meeting Planner would meet one of these features, in a broad way.

The Bug List is more of a specialization of the more general 'Issue' Tracker (Also known as Trouble Ticket and Problem Resolution systems, depending on current corporate cultural and regional spin).

Entirely missing: Work Flow Specializing of Work Flow missing: Order Entry/tracking. (End Customer, Shipping, Manu, etc etc etc. Everyone wants the same thing, only tailored for their specific department/section needs.) Specializing of Work Flow missing: Action Tracking. (No, I'm not trying to put our hosts out of work. Just listing what my experience with Corporations and Agencies are always looking for.)

A major element missing from Corporate/Agency use: Grainularity to 'pigeon hole' information so that only approved users/roles/groups may browse/edit/delete information. This is especially big must have in government Agencies, where it is illegal to share information with the world.