I’m a newbie to Tinderbox. I’m wondering if it makes most sense to store notes in folders by topic/project, as I would do with any software product, or is there any reason to create a single generic folder for all notes?
Just wonderin?
TY
doclrb
I would contend it all depends on:
- What the outcome of the use of your notes is.
- Your personal work style
- To a lesser degree, other tools you’ll use alongside Tinderbox
Containers don’t ‘do’ anything per se, other than store child items. Links within Tinderbox are not hierarchy dependent. Hierarchy can be queried in action code (agent queries are still just action code).
For research /workflow reasons I work with large container (i.e. many child items) a lot but generally avoid them when I have choice. This is simply because, regardless of view, large containers can make navigating around a bit more of a chore. If a container of notes pertaining to authors gets too big, then a pragmatic split to, say, to two A-M and N-Z sub-containers is one form of compromise.
From years of observation, containers are often used as a primary taxonomy and (worse IME) as a tag hierarchy. One of the best Tinderbox use skills to acquire early is using (user) attributes to hold metadata for your notes. Notes pertaining to ‘project X’ could be stored in a container of that name. But what to do if the note pertains to projects X and Y. You could put an alias in a ‘project Y’ container. But, more efficient is to store the data in attributes as then you can begin to work Tinderbox’s analytical magic more easily.
If your Tinderbox is heavily linked to data in other apps, that may give you good reason to mimic data structures elsewhere.
In summary, it all tracks back to those first two points. What are you trying to achieve? What is you normal work style in doing such a task?
I read the question two ways:
- Where should I store my Tinderbox documents, or
- What’s a good practice for organizing the notes inside a given Tinderbox document
@mwra has addressed the second question.
My own practice on the first question is
- if the Tinderbox document does not relate to a group of other documents in a project, then I store the Tinderbox document with other Tinderbox documents in thematic folders in a parent “Tinderbox” folder inside Documents
- otherwise, the Tinderbox document is kept along side the other documents in the “Project XYZ” folder hierarchy, which is usually not inside Documents.
Of course, as @mwra suggests, do what makes sense to you. There is no best practice.
1 Like
As @mwra said, you can use Attributes to organize some of your documents. For example, in the screenshot below, you can see three parts of a new document I’m working on (introduction, part 1, part 2). In that case, I can easily see what I already wrote in each section of my document. I only need an outline to do that or a map full of notes. No need of container nor separator even if I can use it too.
On the second screenshot, there is a convenient way to take an overview of all your documents if you prefer to store your notes in different “folders”: just stay clicking on the Tinderbox icon and your recent documents appear.
… and two very interesting and useful discussions about how to store and organize notes in Tinderbox:
On the subject of metadata/attributes, this is essentially the same a ‘tags’ (or keywords, etc. - all the same concept). If you are used to just working with with tags, i.e. just one place to store a note’s metadata - often because that is all the app offers, Tinderbox has a $Tags built-in attribute. Indeed, import from/synching with some apps with which Tinderbox offers some specific integration may populate $Tags for you.
However, ‘tags’ are an everything-bucket for all your custom metadata. Once you feel comfortable with the notion of teasing apart the stands within your tags, that is where Tinderbox’s strength in easily adding attributes (you can think of them like database fields or extra spreadsheet columns) will become useful. IOW, if your experience is only of tags, you can use that method to start and have a fairly familiar experience to tags in some other apps.
3 Likes
One practical consideration, which hasn’t been addressed yet, is that notes need to live somewhere. By default they go at the top level. I find this gets unwieldy very quickly.
My first basic level of organization is to create a top-level container called Notes, and I put all of my “content” notes inside it. That lets me keep the top level for organizing purposes, with containers like Prototypes, Templates, etc. I typically usually end up with top-level agents or containers that give me quick access to groups of notes I’m most interested in. I frequently alias content notes into one of the top level containers, or sometimes move the original into the top level containers and keep an alias under Notes.
I admit I haven’t figured out attribute browser yet. I know how it works, I just don’t know how to make it work for me. It does seem like it can be useful for grouping stuff into “buckets,” so I don’t have to alias notes all over the place. But at some point, I want to give notes an explicit structure, and that’s why I spend most of my time in outline view.
One practical consideration, which hasn’t been addressed yet, is that notes need to live somewhere. By default they go at the top level.
This is where my notes-on-the-fly live and I love this icon:
1 Like
Just one man’s opinion (explained at greater length here, as others have noted) but the Attribute Browser is the secret power of Tinderbox. Details in that linked thread.