Now that we've identified the requirements for our sample wiki, and we understand the basic data model of TiddlyWiki, with tiddlers, fields, wikitext, links, and tags, let's develop a broad outline of how we'll implement the requirements in TiddlyWiki. While it's easy enough to restructure a wiki if we need to, it still makes sense to get a clear idea of what we're trying to accomplish before we start, or we'll spend all our time restructuring instead of adding useful content.
It's helpful to be consistent when structuring a TiddlyWiki: if we want to be able to find all our meetings, for instance, it's probably a good idea to mark all of them as meetings in a consistent way (whether by linking to them from a central list of meetings, tagging them all with the same tag, putting Meeting in a tiddler-type field on all of them, or whatever). Prebuilt software for handling work notes would likely provide some built-in way to identify something as a meeting – perhaps a “New Meeting” button that created a different type of note – but in TiddlyWiki we have to make those decisions ourselves. (The upside, of course, is that we get to make these decisions based on what makes the most sense for us.)
So let's take another look at our requirements and figure out how, broadly, we want to structure the notes in our wiki. Specifically, let's identify some types of tiddlers. This is not a technical distinction that TiddlyWiki makes – a tiddler is a tiddler is a tiddler – but it's useful for a broad range of wiki use cases to classify tiddlers in some way based on what kind of content we store in them and how we use them.
- Daily journal tiddlers
- Every day we'll create a new tiddler that summarizes what we did each day.
- Contact tiddlers
- One for each person we meet and want to keep track of.
- Meeting tiddlers
- These will be the central location that we work in during a meeting. If there's any information that needs to go into our permanent knowledge banks, though, we'll move that out into project or knowledge tiddlers (discussed momentarily) after the meeting, as it's usually tough to remember which meeting something was part of when you need to find it later.
- Project tiddlers
- While we certainly won't have only one tiddler per project (tiddlers are supposed to be small, after all), these will serve as the central gathering point for all the information about a project.
- Knowledge tiddlers
- Any information not described above that needs a home in the wiki will be a knowledge tiddler. Because almost anything can be a knowledge tiddler, knowledge tiddlers will likely be the hardest to keep organized. That said, because they are so unstructured, it will be easy to move the information they contain between tiddlers and split and join tiddlers as our understanding of the information and the structure we want to use evolves.
Now we have to decide how to implement these classifications within TiddlyWiki. Tags are an easy and popular method, so let's use them here. We'll tag journal tiddlers Journal, contact tiddlers Contact, project tiddlers Project, and meeting tiddlers Meeting. We won't bother giving knowledge tiddlers a classification tag, since there are usually few situations in which we want to treat only those tiddlers separately, but you could create a Knowledge tag too if you preferred.
We'll also have to decide how to associate the different types of tiddlers with each other. Since tiddlers are small and focus on only one idea, it's critical to associate them with each other in a coherent and understandable way, or they'll get lost. We'll discuss how this will work for each type of tiddler as we get to it.
If you're not sure how I came up with these divisions or why I made them, that's OK – you can just play along for now. Once you have a bit more experience with TiddlyWiki, we'll be returning to the reasons for and methods of dividing content into different tiddlers and different types of tiddlers, in Slicing Up Content.