Now that TiddlyWeb has reached version 1.0 (and beyond) it can be claimed that the general purpose of TiddlyWeb has been filled: create a server-side store for Tiddly* content where tiddlers are first-class entities with their own URIs.

Versions of TiddlyWeb up to and including version 1.0.x have intentionally not paid attention to performance, conscision and of ease of use in favor of:

• readability
  
• testability
  
• transparency
  
• extensibility
  
• duplicability
  
  

This has allowed users and developers to prove out the HTTP API and the architecture in a fairly "close" to the implementation fashion.

TiddlyWeb 1.2 has improved upon 1.0 by addressing some of the performance concerns. The changes are described in UPGRADE1.0to1.2.

In the next phase of development ease of use concerns should be addressed.

Ease of Use

Ease of use is entirely context dependent. Much of the standard UI for TiddlyWeb is managed through tiddlywebwiki therefore ease of use work should focus there. Ease of use can be divided into two realms: Getting TiddlyWebWiki installed and running, and actually using it.

Many of the complaints with installation are general to installing any Python software, so solutions to those general problems should help with TiddlyWeb as well. These include things like py2exe, py2app, packing debs and RPMS and the old standby of more and more clear documentation.

When using TiddlyWebWiki, the features and benefits of using TiddlyWeb are insufficiently clear. The bag and recipe concepts are not native to TiddlyWiki, so additional plugin support is required to take full advantage of them. Some features that should be explored include:

• In TiddlyWiki ways to move content between bags and recipes and to create new ones.
  
• More visual cues in the UI of how bag policy settings are impacting the actions that can be performed on the tiddler currenty in focus.
  
• More effective lazy loading of tiddlers from the server.
  
• Notification from or polling of the server when there is new content available.
  
• Conflict resolution when the server responds with a 412.
  
• Support existing patterns of TiddlyWiki behavior, notably import through the backstage.
  
  

Each of these, though, must be considered in the context of people actual doing them. The features need to more than just available, they need to be useful and essentially self-documenting.

See also TWW task dredge.