News:IMPORTANT MESSAGE! This forum has now been replaced by a new forum at http://forum.eastgate.com and no further posting or member registration is allowed. The forum is still accessible via read-only access for reference purposes. If you wish to discuss content here, please use the new forum. N.B. - posting in the new forum requires a fresh registration in the new forum (sorry - member data can't be ported).

I've been reading the manual, playing around with Tinderbox, reading every resource on the Web, and comparing Tinderbox to apps which seem "adjacent" in the information management space.

It occurs to me that Tinderbox is confusing to people because it consists of layers of increasingly advanced functionality, and that one is not required to know or use all the layers to make use of Tinderbox.

These are the layers I see, as they unfold:

# Capture

Initially Tinderbox is a place to _take_ notes, but not to do anything with those notes. And at first it's just titles and text. Lots of tools do this. It's a convenient place to dump tons of small snippets of text. (It could be better at capturing such information from other apps too, by providing a clipping service).

# Structure

Once you have lots of notes, you can organize them, either hierarchically or visually. Lots of tools do this also, but I like the way that Tinderbox links the outline and map views. OmniGraffle can do this also, but the Outline is definitely the second class citizen in that context.

# Refine

Later come attributes, stamps and prototypes, as ways of better managing the metadata associated with your notes. This is a very easy way to tag things, add checkboxes, etc. It doesn't necessarily have much value initially (it's hard to know what metadata to track, which prototypes need to be created, etc), but lends itself to real power down the road.

Not nearly as many tools do this, or do it well. I've never found rich metadata to be a strong suit of either DEVONthink or OmniOutliner, for example. There is some capacity, but it's never as convenient in the way it can be with stamps and prototypes.

# Relate

Here we find agents, aliases and inter-note linking (made visual in the map view). Other apps call these smart groups or folders, symbolic links (or replicants), hyperlinks, etc. They provide ways of perceiving and building relationships among all the data you've accumulated.

# Present

Tinderbox's ability to provide intelligent, metadata-enriched presentation using patterns, background plots, display expressions, hover expressions, columns in map view, smart adornments, etc., are things I've rarely experienced in any other tool -- at least not in such a well-integrated way. I also think many of those who peek at Tinderbox (from what I've seen) never fully perceive this level.

And by presentation I don't just mean "you can see your notes on a corkboard". I mean that Tinderbox can reveal your data in content-driven ways that make it possible to visualize inherent, complex relations.

For example, let's say I'm a volunteer coordinate, and I need to pair up volunteers with projects. This is a many-to-many relationship, with volunteers possibly working on multiple projects, and each project having multiple volunteers.

In the map view, I organize volunteers using a People prototype on the left side, and projects using another prototype on the right side. I then draw lines to connect volunteers with the projects they've chosen to work on.

Next I create a rule within the prototype to color people and projects based on the number of incoming or outgoing connections. I want people to be colored on a spectrum from blue to green to red, where blue means available, green means fully tasked, and red means overloaded. Conversely, projects are colored so that blue means unstaffed, green is fully staffed, and red is overstaffed.

Now I can glimpse at the board to see where attention is needed, who is likely to burn-out, which projects are being neglected, etc. I can also use agents to summarize the hot spots, and suggest possible volunteer/project pairings based on need and availability. Or I could add metadata to indicate strenths and interests (as lists), which would make the suggested pairings even more intelligent.

# Evolve

The final piece of the puzzle is that your data can transparently mutate and evolve, based on all the above. This is where rules really come into play, so that data can change in response to additions and changes elsewhere in your "note space".

This aspect of Tinderbox is the least visual, and the most programming-oriented, and is an area I think few venture into. Yet it is also the most enabling capability of the app, since it can free one from rote manipulations that become impossible beyond a few hundred notes.

Finally, all these areas of the application fit together fairly seamlessly, so that it can be hard to see that in fact there are multiple tools available within this tool.

I think it helps lay bare the cause of a typical starter's confusion by which they see some interesting, mature, TB example and thus start out with their mind at '# present' but their expertise at '# Capture'. That's not critique of new users, I certainly went through that phase when I started with TB, albeit 10 years back.

That is a very useful description! Thanks. I could imagine that the Eastgate high command might want to incorporate it in some of their "here is how to think about our tools" offerings.

And as you've probably seen, The Tinderbox Way builds toward the same kind of layered description, though (since it is a book, and is trying to cover some other things) not as concisely as you've done here.

Update: On your "refine" point, which you describe this way ...Quote:

Later come attributes, stamps and prototypes, as ways of better managing the metadata associated with your notes. This is a very easy way to tag things, add checkboxes, etc. It doesn't necessarily have much value initially (it's hard to know what metadata to track, which prototypes need to be created, etc), but lends itself to real power down the road.

I'm impressed by another aspect as well, consistent with what you say. I don't know any other tool that matches TB in making it convenient to adapt, evolve, prune, and refine your classification and metadata tools. The truth is that you don't know what you're looking for when you start out on a project.

As the information grows and changes, as your own interests evolve, ever-changing classification schemes make sense at particular times. In old-fashioned data bases you had to make all those choices at the beginning, and often it was easier to start from scratch if your initial bets proved to be wrong. (This kind of rigidity of course lay behind the old Y2K scare.) I've been impressed by how easy it is in TB to keep making these adjustments. The importance of allowing this growth is of course a big theme of Tinderbox Way.

You are so right, J Fallows. Anyone who has designed schema for a database before should know exactly what you're talking about. This I think is one of the weaknesses of the FileMaker approach, for example. It requires too much knowledge of what you *will* want, from the onset of the project. This works fine in business domains where the problem is well understood, but not so much in the more free-form domain of note taking.

I really appreciate the way you have summarized how tinderbox can be used. As a relative newbie to tinderbox, I'm happy to have confirmation of how powerful the program can be in the future.

Personally, I'm an academic and am trying to figure out how to use tinderbox in a meaningful way. For example, I understand the basic creating notes and adding attributes, as well as drawing links from one note to another. However, I haven't found the resources that will show how I can use tinderbox to organize the articles I read, constructs I study, research I've done, and plans for future studies.

As a concrete example, let's say I read an article about the neural mechanisms associated with sleep and chronic. I want to create a note that briefly describes study and results. That, or another, note would contain a list of brain regions studied and/or involved with sleep and/or chronic pain.

- Lather, rinse, repeat with several other articles -

I would then want some way of identifying and linking the articles/notes associated with just chronic pain, and some method of identifying the brain regions associated with chronic pain across all of the notes I created. I could then incorporate this information with notes I have created tracking my current research as well as use this information to generate new ideas for research.

So in summary, I really appreciate the way you have described a layered approach to using tinderbox, and if anyone can point me in the direction of some resources to help me accomplish my aforementioned goals I would be very appreciative. Thanks any and all for any comments, suggestions, and/or help.

This is a common question which boils down to the circular question of "how exactly do I use this open-ended system to look at my data?". The answer is that unless you're doing exactly the same as others, there isn't a 'template' to follow. The best initial approach is to just add some of the sort of data you're likely to collect - say 20-30 readings/papers/whatever - and which might mean creating more - or fewer than - one note per source. Then see what results. What can't you see that you expected to see? Are there strands of data in your notes that you can see would be useful as attributes, indeed as key attributes? Where might prototypes help? If you don't yet get the hang of prototypes, see my articles here and here.

If your (specimen) data's not too private to share, it can be useful to put a copy of the TBX on your webspace (or dropbox, etc) so other users can take a look. It's much easier to make sensible suggestions when there is an example to give context. Otherwise the advice can be a bit conceptual which is less use when starting out.

I also suggest making test documents and practice making attributes of various type so you can see how they work and get a feel for the Inspector, and Get Info panel and how Tb's inheritance works.

If you specifically want visual links you will need to work in Map view. To see links fully drawn source and target must be on the same map (i.e. siblings in outline view terms). You can drag/drop links (all most main view types) but as you get more data - and structure to it - you'll be able to leverage action code to capture links based on things like attribute values, allowing for serendipitous discovery.

Most of all, don't assume someone must have already done your exact process. However, it is likely different people will have done different parts of your overall (emerging) process. Thus getting a feel for what you want and asking how to do specifics is likely the fastest way to get up to speed.

I realise it seems counter-intuitive when compared with databases, but TB is very flexible in terms of applying emergent structure. Spot something you know know you want as an attribute - just add it. So bit of action code (for which someone here can help if needed) can help populate the new attribute in all the existing notes. This let's you let go of worries about getting everything right, structurally, at get go before you really understand the data.

Thanks for the response. The inherent flexibility is one of the things that drew me to tinderbox in the first place. You asked some great questions, and I will post a couple of my practice files with specific questions in the near future. In the meantime, I will take a look at your reference articles on prototypes. Thanks again.

Thanks for the response. The inherent flexibility is one of the things that drew me to tinderbox in the first place. You asked some great questions, and I will post a couple of my practice files with specific questions in the near future. In the meantime, I will take a look at your reference articles on prototypes. Thanks again.

Cheers,Jason

Hi Jason, I think it would be great if you could post your practice files and questions as it helps us all learn. Especially newbies like me.

This is a great discussion. For Jason Craggs's question in particular, I recently read Mark B's revised Tinderbox Way and would suggest this is probably one of the better places to get some ideas on the best ways to organize your notes. He has some nice discussions of when it might make more sense to, for instance, use a map view versus an outline view, depending on perhaps where you are in a project as it unfolds.

I agree that there is what one might call a sort of "developmental" approach to understanding Tinderbox, where one can be pulled into using it by some aspects of it that are easy, "elementary school" stuff like note creation. But you can then get pretty tangled up in the weeds as you try to do more advanced things. After a certain point, it can become a dauntingly difficult tool to use compared to the kinds of software challenges most people are accustomed to. At that point, either mastering more of Tinderbox has to become a sort of hobby, or else you don't ever learn the more complicated skills.

Addendum 3/19

An addendum, based on a challenge I had today (day after I wrote the above) illustrates some of what I am getting at.

So I'm working on a novel and have a growing TBX document for help developing it. There is one container note in the document that I use in outline view as a "journal" of ideas and process notes that occur to me as I work.

Each note I've been using in this section has a title that captures the main topic of the note, to which I've been adding the date of the note. The idea here is that my writing can take a long time and seeing that it's been three months of note-writing, say, can maybe keep me moving. So it might be a note with a title like "The Butler MAY have done it March 19, 2016."

Obviously, tacking the date on like that is not an ideal way to do a note title. So I remember that you can create columns in Outline View, and add any attribute you want as content of a given column. I think, gee, I could do that and make the date of the note appear in that column, right next to the note title. That will clean this up a bit.

So I tinker. I've never done this before but like with any other software, I start with the menu bar (or is it a "tool bar"? -- it's the bar at the top). I toggle View and indeed, there is a "Use Columns" option. I click it and a bar appears to add a column. I have to think a minute, what is the attribute name for "date note was created"?, and so look around in inspector and wherever and realize it is the term "Created" (or in Tinderspeak, $Created). Swell. I punch that into the little box that appears above that column. (With the dollar sign? Without? Not clear. I try and err.)

After a few minutes more of tinkering, I find that I still have no idea how to get the correct data to show in that column. At one point, I end up with every cell showing the number "8", for instance, which I used in the little "spaces wide" box, thinking that would be enough spaces to capture the date. So that's wrong... and on and on.

It becomes clear after a while that my trial and error approaches have failed me. So now I should look the answer up somewhere. But the problem is that I really don't know which reference resource to use to solve the problem of how to display date. I've been around TBX for years so know a lot of the good sources. (Most new users don't.) So I know I could ask here on the forum but I really hate bothering people with dumb-seeming questions, and like most people have a bit of normal resistance to displaying my ignorance. I know I could hunt in the manual. In Tinderbox Way. In Mark A's cookbook or other stuff he's published -- I have links or downloaded copies of all these things.

But in all cases I'm not even sure I know how to ask the question.. seems to me that once I specify that the attribute I want to display is the date created, it should have "just worked," as Steve Jobs might have said. Didn't seem to. Maybe that's my "mental block" - I get a bit peeved that it doesn't "just work." I growl.

Now I realize: This is taking more time than this slight improvement in the document is actually worth to me. Hence, I decide to cut my losses. I can do without.

Maybe later I'll come back to it and figure it out, or someone will mention it here since I bring this up.

I do think this is where Tinderbox can get hard, when you need a non-obvious, non-built-in, and so practically speaking, invisible solution.

So back to the topic of beginning to learn Tinderbox. Probably, it's best to consciously develop one's own mindful philosophy of using Tinderbox. When do you pursue solving a problem? When is it too time consuming, or disruptive to a workflow, to bother? What do you table for later and what do you plow through until it's solved that day? This is best done mindfully and deliberately. Sometimes, the smart move is to not bother. Sometimes, the smart move is to use a different tool entirely. But sometimes, it's really, really worth it to take the time to solve it, ask on the forum and so on.