This is a response to the original poster, Damien, but I’m referring to points in the Eastgate / Mark B post just above.
I wanted to say to Damien that all of the advice you’re getting here is sound. But my own experience with the program (over now nearly a decade, after previous immersion in the sublime DOS program Lotus Agenda, and then the Windows program Zoot), makes me especially want to emphasize the points I am quoting above:
-
My natural instinct was to build hierarchies, based on a long reliance on outlines for thinking and planning. In Tinderbox, associations of various sorts generally pay off better than hierarchies, for me. These associations have several forms: links on a map (which I rely on relatively little); physical arrangement of items on a map, especially relative to adornments (which I use more); and categorizations of items via attributes (which I use all day every day, for everything I do). You can tag, classify, identify, and otherwise meta-tag your info practically any way you want through attributes, and you can flexibly add or change anything as needs adjust. Main point: I find TB most powerful as an associative rather than a hierarchical tool. (This is related to Mark B’s first two points.)
-
I can’t say enough about the Attribute Browser, which is an awkward-sounding name for a very powerful tool. Simplest example: suppose one of your attributes is $City (attributes begin with $, by convention.) And you’re entering info about places you want to go or places you’ve been, with a $City tag – Paris, Sacramento, Dubuque, whatever. When you switch to the Att Br view, it shows everything neatly classified by city. This is something that the old forebears like Agenda and Zoot had done all along, and its addition to TB a couple of years ago was transformative for me.
I agree with the other advice too: start with the simplest structure that will work, add to and adjust it as you like, learn by going and doing.
Also be aware that, compared with products from big companies, Tinderbox will sometimes crash. I think that’s because it’s evolving and being refined continually–literally hundreds of incremental releases in the time I’ve been using it. But I can’t remember any case in which I suffered any data loss from a crash – 99% of the time you restart the program and all is well. And if you send the crash log to Eastgate, 99% of the time the problem will be addressed very quickly in an update or release.
Have fun.
Update to add that all the suggestions above, from the two Marks and Paul W, ring true to my experience. Also the invaluable aTbRef is the first place to go if you’re wondering, “What does this command do?” or “How do I try to get the program to do this particular thing?” And all of the tutorial videos, from a range of perspectives, are cumulatively very helpful. Questions asked here tend to get answered fairly quickly.
But start simple and learn by growing and expanding.