The most common view authors had of their data was a simple list of objects of the same class, as seen in Figure 6.3.
The objects are in alphabetical order. They can be filtered to find all of the objects that have the same piece of data in the same slot, such as the same substring in a string field, or else all objects referencing the same question.
As seen in this Figure 6.3, authors dealing with large amounts of data (usually at the point where they were building a prototype, as opposed to a walkthrough) found ways to circumvent the alphabetization by using preceding symbols to categorize the answers. Other groups of authors used numbers instead of symbols, but the effect is the same--authors wanted to categorize their data.
All objects in INDIE can be tagged. A tag is simply a word or phrase that can be easily added to an object, and finding all the objects that have that same tag can be an effective way to group objects. Authors almost completely failed to use the ``Tag'' mechanism to group their points, preferring to survey the data from the list format.
Also, many authors didn't try the tag mechanism as they didn't know what it was, while other authors who were trained on the use of tags stopped using them early on. One Rembrandt author in particular, when tags came up during the exit interview, said ``Tags, right, I guess we could have used those. We must have forgotten about them.''
The lesson we might learn is: Authors need to be reminded of features. Either we need to make tags more explicit (perhaps making them visible in the big lists of data instead of just sorting criteria), or at least we need to directly remind them. Perhaps we could take a leaf from Microsoft Office [Microsoft 1996] and pop up helpful reminders a few sentences long during startup or during long saves.