Tinderbox Forum

Formatting Export Layout

I am trying to use Tinderbox to capture ideas I then want to export in a tabular format, ideally as pdf.

The tabular format is
Top line - Context: a model and a metaphor
Middle line - Concepts: a series of A/B statements (like a title and subtitle) that relate to the model
Bottom line - Content: stats and stories

I imagine that I could paste an image into a note for the Model, have another note for the Metaphor.
The same would apply for the bottom line: a note with a bunch of references and another with a story or two.

It is the middle line that is causing me design issues. Do I have one note with all the A/B statements in the text field or have multiple notes? Do I nest the notes under a model, or link to both model and metaphor? A map view could look like this.


Or, do I put everything into a table in a single note?


How, then, do I export into a tabular form that I can then upload as a pdf?

Or, always possible, am I trying to do something with Tinderbox it was not designed to do?

Thanks in advance.

designed to do? Likely so. Bear in mind Tinderbox’s strength is in emergent structure and you’re describing a totally rigid process. It might help us (here, like you, we are Tinderbox users) if you could explain the context of this pattern and what you’re really trying to do.

If it is a totally right process why not use a UML tool or working in something like Omnigraffle.

As to export, whilst a Tinderbox note’s text ($Text) uses RTF text it’s meant primarily for text rather than complex layout tasks like tables.

If I had to make tables like that, I’d use HTML export and style the nots’ output to give me the table.

A worked example, even if illustrated with screen grabs using a different tool might help here.

I concur - HTM/CSS styling isn’t obvious if starting from no knowledge.

The OP illustrated a Map of their data structure. If some notes are children on others it makes Map-based use more difficult (or sub-optimal). However, while the actual OP’s task is so loosely defined it’s hard to know if Map-based use (as in all notes on one map) is a need, a convenience, or a casual assumption.

Thanks Mark, yes, you’re right, I am using a rigid process. At least, the final display is rigid.

I think I’d be better to use Tinderbox to collect the ideas and let the structure emerge, then copy/paste into a Word table for the final display.

Thanks Paul, in trying to force a structure at the wrong point of the process I’ve mixed everything up. There is no parent / child relationship as such, except that there can be many Pink Sheets to a Model.

This describes the process: https://www.pinksheetprocess.com

If you can think of a way Tinderbox can be used, that would help me a lot. Though it’s possible I just need to use Tinderbox for what it’s good at…

It gets used lots of different ways, but I think where it has a USP is in exploring knowledge - which is arguably the polar opposite of the process to which you just linked (from a brief read). Don’t read that as judgmental. Rather the point is one is placing facts into a framework and the other is doing quite the opposite. Some find process aids through, some find quite the reverse (I’m definitely in the latter camp - I like a very loose/broad so I don’t miss emergent links). I see Tinderbox as an unforced way to surface structure. this is powerful as most knowledge environments are heavy on process and/structure - i.e. forcing your reality into someone else idealised grid, which can be painful - or bliss of you align with that grid process type.

The closed to systematised use I’ve seen is that some people do GTD time management in Tinderbox. I don’t really get GTD, so I’ll have to let a GDT-er explain if it works.

I often explain freeform use of Tinderbox as a bit like starting to do a jig saw. You tip out the bits (i.e. add notes to the map). Some things are obvious; edges, corners. As you turn the pieces over other tentative structures emerge. These pieces are the same shape but clearly go in different places. These blue bits definitely differ from those red ones, so we put them in different places, at which point it’s clear there are actually several different shades of blue, so we can sort those too. Even if we don’t have a box-top picture, relationships start to emerge and we can start to capture structure.

Sticking in map mode, we could use different colours/shapes/borders for different notes to capture loose associations. If you’ve got the hang of Tinderbox prototypes (a very light and powerful feature) you can make prototypes and work on changing multiple notes at once.

As the jigsaw starts to take on some form - i.e. you begin to see patterns and structures in your notes you can formalise these further. Some like to stick with a single map and formalise the structure, giving the layout a more structured fell. Others might begin to explore other views (it’s still the same data), perhaps pulling similar things into containers (Tinderbox maps only ever show the contents of a single container). Container help if you’re trying to put some form of narrative track, e.g. if you’re trying to write a document based on your notes.

If that all seems a bit loose - it should. There is rarely one ‘right’ way to do things. You can make large/complex resources (the c.1.8k pages in this resource all derive from a single Tinderbox doc - though from not a single map!) but if you need a heavyweight writing environment you might want to migrate data to a writing environment Scrivener or Ulysses, etc. Or if you’re working virtually, you might want top move to OmniGraffle or Illustrator, etc.

About the only method that tends to end in failure is trying to use Tinderbox for a single feature that [some other app] doesn’t have but which is a main workspace. IOW, trying to make Tinderbox simply work like [some other app+plus one feature]; that doesn’t always end so happily. But hopefully the above should give you some ideas as to why.

I hope this gives some ideas, and I hope others will join in with different takes - possibly the polar opposite of mine, but we are a broad church here.

1 Like

And this is what I did…

Made prototypes for each of the five sections of the “Pink Sheet”, then created notes for each section of a single pink sheet and linked them. This in anticipation of models, metaphors, statistics and stories being used multiple times to support a single point.

I’ll worry about exporting it later. For the moment, I have a means to see emergent structure, and that’s what counts…

Thank you!


Great. Glad to see you’ve dived into prototypes. I find them a real force multiplier, especially as a document grows.

1 Like

Very nice approach @Stephen. I’ve put the pink sheet info you provided the link to, on my reading list – I’m curious about the approach and its benefits.

Is the export something that is needed to make the process work for you, or is it more of a nice-to-have feature?

Looking at your map, I’m tending more toward the HTML export model. With the links, etc., I think I can see how that can work with building a “pink sheet” table structure in HTML – although it would be a bit of challenge getting it right.

1 Like

Thanks Paul. Yes, it was just a matter (just a matter…) of breaking a rigid one-pager into its component parts and seeing if that could work for Tinderbox.

Re export, strictly speaking, yes. It would be useful to have these on one-pagers but a large table would also be acceptable. As I write, I think that having the identifier as a separate field, rather than part of the name, would help this.

I would agree. If an object has a name and separate identifying characteristics, it’s good practice in my opinion to separate these characteristics (such as object ID) into their own attributes.

So, if you had $Name as the standard attribute and $pinkID as a user attribute (a string perhaps), then you could use a DisplayExpression and see the same result in the displayed name of a note as if the two elements were combined in $Name

$Name == “This is a pink item”
$pinkID == “PS13”
$DisplayExpession == $PinkID + ": " + $Name

will display in name “PS13: This is a pink item”

Tinderbox is usually flexible enough to model a rigid process pretty well, and even to loosen up a rigid process if that’s what you want.

1 Like

Thanks Paul, I think I have that working. But I’m seeing " : $Name" on all my notes now - I think that is because the $DisplayExpression is system-wide?

Does this mean I need to create a User Attribute “$DisplayExpressionPS == $PSID + “:” + $Name” in my Pink Prototype?

@Stephen can you please share a simple input & output example? We can probably help you.

input: a super simple TBX file
output: the tabular data you want

I see the “tabular format” description in your first post, but it’s hard for me to put together what that would actually look like based on your images.

$DisplayExpession can be document-wide if you set a default for $DisplayExpression in the System attribute inspector for that attribute. Generally not a good idea.

The most common approach is to set $DisplayExpression for a prototype.


Okay, I have that working for the PS Prototype with the exception of one PS which does not want to pick up the Prototype attributes. It was the PS that I used to first test $DisplayExpression manually.

Yes, Paul, the table would look something like that; there would be no need for the other IDs to be displayed but they could be used to select the notes, perhaps? I don’t know enough about links to “type” them but, for example, a metaphor-pink link would be a unique type.

Remember: notes only inherit a value from their prototypes if they don’t have their own explicit value. Your note has an explicit value for $DisplayExpression, do it’s not inheriting — you’ve told Tinderbox that this note has a special DisplayExpression and it’s taking you at your word.

To address this, you can:

  • remove the value in QuickStamp or Get Info: Attributes.
  • or, just set the $DisplayExpression to what it ought to be.

Thanks, Mark. Solved it by recreating the note.

A bit more on ‘resetting’ attributes to restore inheritance.

1 Like