Updated now that Dakar is released.

My vision of TWiki is a TIM - Team Information Manager (c.f. PIM). In my vocabulary a TIM is an integration platform; a portal or gateway that provides a consistent, configurable portal onto data held in many applications, and provides a simple means to perform common processing tasks on that data to integration different applications together. I believe I share this vision, to a greater or lesser extent, with all of my TWiki-using clients. These are all small to medium sized businesses, or business groups within large corporations. Their expectations of what they can get from TWiki fall into three broad categories, with many overlaps of course:

1. Featureful traditional wiki user (text only, discussion, collaborative authoring, but with lotsa smart plugins),
2. Document store,
3. Highly user-configurable mini-database applications, mainly for issue tracking and lightweight project planning (TWikiApplications),
4. Industrial strength database interfaces and application integrations .........
5. .........that can be rolled out as customer solutions.

This is a continuum; I see "trad wiki" usage as entry-level, and industrial strength DB as expert level. Most have reached (3) and are knocking on the door of (4).

At the moment TWiki caters pretty well for (1), fairly well for (2), moderately well for (3), badly for (4) and not at all for (5). So my roadmap is all about filling in the gaps. Here are the things I think are missing. These are not in order.

Trad wiki

• We are so focused on the original wiki model that we have to some extent lost sight of the fact that wiki meta-language was created to address the fact that no WYSIWYG editors were available. Trad Wiki usage will mainly be improved by WYSIWYG editing.
  • Post WysiwygPlugin, I believe we need a PluggableEditingComponent.
  • Also want an architecture for plugging TWiki Variable - specific editors into TinyMCE.
• A second uncomfortable fiction is the WikiWord. Word and phrase linking needs to be sorted out. RationaliseAutomaticLinking.
• Further out is the idea of providing better indexing - whether that is google-like searching, or keyword linking, at this stage I don't know. ImproveTextSearchingAndIndexing?
• More flexible notification
• CacheingForPerformance Micha has done this

Doc Store

Pretty much there, but could do with

• RobustContentTransformation to/from popular tools (M$ and OO)
• BetterAccessControls for attachments

Mini-DB

Possibly the most common use of TWiki, and where IMHO it is hurting most, is in the building of TWiki applications. I think we need:

• A much better model of content processing than difficult SEARCH and clunky uncontrollable plugins. For example, a PipelineModelForContentProcessing. Focus most plugins authors on writing TWiki applications - they should be able to do most of what they need from the browser.
• PerformancePerformancePerformance
• Brainless 3rd party application integration e.g. using HTML ripping without having to write perl code
• ContentAccessSyntax

Industrial strength

• Ability to map a database as a data store. Any database (DBIStoreInterface).
• High speed SQL search & results presentation, supported consitently for all store implementations (again via DBI).
• High quality, high reliability (more test suites!)

Rollable-out

To be able to roll out TWiki applications as customer solutions requires

• Automatic packaging of a pre-wrapped TWiki application, for rollout on customer site (BuildContrib) (RequirementsForATWikiApplicationPackager)
• Simple management for very inexpert customer IT people (configure interface)

Restful access to data

• TopicObjectModel and ContentAccessSyntax, access to TWiki data via HTTP requests is the single biggest stumbling block for opening the gates to AJAX components.

-- CrawfordCurrie - 17 Nov 2004, 31 jan 2008

---

I just reviewed and updated these for 2008; 4 years since I first wrote them, and the list is still pretty much the same

-- CrawfordCurrie - 31 Jan 2008