Now for project tiddlers. Let's create ourselves a project for completing the company onboarding process. Create a new tiddler (that's the button in the upper-right corner, if you forgot, or Alt+N if you have your hands on the keyboard already), name it OnboardingProcess, and tag it Project.
What kind of information do we want to keep track of for projects? We might imagine including deadlines, stakeholders, approvals, and so on, but it's probably going to depend a bit on the project, and at this point we're too new to understand how the company operates and what processes our projects will move through, so let's refrain from adding fields until we know we need them. However, we do already know that every project we're assigned will have an entry in the company's ticket-tracking system with an associated ID number, so let's create a field called ticketnum. Our protagonist's onboarding is ticket number 245188, so put that in as the field value. Let's throw something in the body describing the project for good measure: how about A project where we waste a bunch of perfectly good time learning all about this nice company..
Project contents
There's our project tiddler, but it's missing something: the EmployeeProfileSetupMeeting we had with Jane was definitely part of the company onboarding process. We need to relate these two tiddlers somehow. How should we do that? We have several sensible and straightforward options, along with many more silly ones. Here are the most obvious choices:
- We could link to the meeting from the project tiddler.
- We could link to the project from the meeting tiddler.
- We could create a field called
projecton the meeting tiddler with a value ofOnboardingProcess. - We could tag the meeting with the project's title,
OnboardingProcess.
Option (1) works, but if you have a large project, your project tiddler might be primarily composed of links to tiddlers relating to the project. In general, it's usually better for tiddlers to indicate that they're a part of some whole, rather than the whole listing out all of its parts; it's easy in TiddlyWiki to identify all of the parts of a whole in any number of ways, but the reverse tends to be fussier. Further, it's irritating to have to open and edit the “whole” tiddler every time you add a “part” tiddler, and it's easier to forget to do that than to forget to add a “whole” reference to the “part” tiddler. (If you happen to know anything about relational database design, you'll see a clear parallel here. TiddlyWiki is in fact arguably a weird kind of relational database, though without rigid schemas.)
Option (2) is a solid choice and particularly easy to implement, but links carry less information about what exactly the relationship between the two tiddlers is than tags or fields do. With a link, we just know they're related in some way. With a field or tag, we can know specifically that the meeting is part of the project – rather than the project being part of the meeting, or the project being mentioned in the meeting as a horrific disaster that needs to be avoided in the next project.
Option (3) provides the most information about the precise relationship between the two tiddlers. However, since you'll be creating your own custom field, you'll have to create your own customizations in TiddlyWiki to make the field do anything useful aside from showing up in the “fields” section of the Info tab, so this requires extra work. (We'll learn how to do this kind of thing starting in chapter 4.)
Option (4) is easy, fast, and effective, and tags are understood as the primary means of creating hierarchies and memberships in various plugins and parts of TiddlyWiki's core. Additionally, you get the autocomplete functionality of tags when searching for a “whole” tiddler to attach your “part” tiddler to. This sounds like an obvious coup, but the disadvantage is that if you have a large wiki, you may end up cluttering up your tag space by using this mechanism for many different things – that is, dozens or hundreds of tags will show up in your tag picker, making it harder to find the ones you want. There are a number of ways to mitigate this, such as color-coding them or adding prefixes to their names to describe their functions, but it's still a disadvantage, and some experienced users of TiddlyWiki prefer to use fields in many cases for this reason.
Let's go with option (4) for this wiki: it's an important part of TiddlyWiki to understand, whether or not it turns out to be your preferred method, and it's a quick and easy way to get started.
To make the EmployeeProfileSetupMeeting a part of the OnboardingProcess project, then, simply edit the EmployeeProfileSetupMeeting tiddler and add a tag OnboardingProcess. To check your work, go back up to the OnboardingProcess tiddler, click the info button, and choose the Tagging tab; you'll see that OnboardingProcess is now tagging EmployeeProfileSetupMeeting. You can also see the relationship by clicking on the OnboardingProcess tag pill on the EmployeeProfileSetupMeeting tiddler; above the line you'll see the OnboardingProcess tiddler itself (the “whole” tiddler, or the “tag” tiddler), and below the line you'll see a list of everything tagged with that tag (currently, only EmployeeProfileSetupMeeting).
Exercises
Suppose you have a tiddler MyCar, along with a series of tiddlers describing the items you keep in your car. Why should each item state that it belongs in your car, rather than the car listing out all of the items it contains?
Create the car tiddler in your example wiki and relate several items to it, using each of the four methods discussed in this section. What methods do you like best?
go to answer