Starter/Learner Tinderbox document: suggestions?


(Kirby Krieger) #1

Hi,

Following much good advice, I am going to start learning how to use Tinderbox (having worked my way through the Getting Started Tutorial) by attempting a focused document. I have kept lists of Questions & Answers in other programs. I would like to do so in Tinderbox (this is truly one of the biggest note-taking tasks I have).

In short, I want to create a database of questions and answers using Tinderbox.

Any suggestions?

I’d like the following:
. Notes have a similar format
. Notes be grouped by specific topic (real examples: Zwift, Tinderbox, Lightroom).
. Topics be grouped by type (software, hardware, painting, woodworking).
. Answers be readily seen.
. Answered questions be visually identified (and/or grouped).
. Ability to indicate whether a question has been posted/asked elsewhere/of someone.
. Link or note of location/person posted/asked. Date of same.
. Link or note of where answer found.
. All quickly searchable.

Of course, this is just a start, but it seems a good place to start for learning as well. I have some sense of how to use some of the tools introduced in the Tutorial for the features I’ve listed, but (also of course) I don’t have the experience to lay out an un-brambled path towards my goal. Use a Badge to mark Notes that are Questions and change the Badge when answered? Via a Stamp? Create Notes with a Prototype? Automatically, via a parent Note? With Key Attributes? And how to as seamlessly as possible record a question when I have one while I’m working?

Just for starters :blush: .


(Paul Walters) #2

I would start with a basic approach. Make containers for each “domain” (Tinderbox, Zwift, Lightroom, woodworking, and so on). Put the questions into the containers as children. And then put the answers into the question containers. So, here’s a possible hierarchy:

Lightroom
-- What's the best practice for selecting images to Develop
-- -- answer 1
-- -- answer 2, etc.
-- What's the best practice for publishing images to Tumblr
-- -- answer 1, etc.
Zwift

You could have a prototype with key attributes for domains, one for questions, and one for answers. I would make rules so that things like domain topic, or question, populate downward into the children.

Now, that’s a way to do it using an Outline. If you want to flatten this and use a map instead, you could use adornments to represent the domains, colors to represent question notes versus answer notes, and links to visually tie it all together.

Agents, attribute browser, the roadmap view, and other features can help to explore the knowledge base as it grows.

I’m sure this suggestion will generate questions and other folks’ comments about how they have done this. So I’ll stop there.

Word of caution: it’s best to start these sort of projects with just a basic structure and then over time let the document evolve as the best structure for your knowledge base emerges while you populate it with notes. In other words, don’t get deep into thinking of design (what badges to I use, what stamps would I need). When I get lost into design I forget the whole point of why I was doing the project. Perfection is the enemy of progress.


(Pat Maddox) #3

Well, I hope this doesn’t get too meta, but I would turn your list into a set of questions:

  • How do I create notes with a similar format?
  • How do I group notes by specific topic?
  • How do I group topics by type?
  • etc…

and then go to work answering the questions, and applying what you learn to the document itself.


(Mark Anderson) #4

I commend both the last answers. Trying to bend the as-yet-not-learned toolbox bend to a conceptual model if far harder then thinking about the toolbox’s features you project might involve and learning each of these before adding it to your burgeoning proctor file.

For instance, is a badge more useful a state indicator? First it help to know how so set each of these, first via the UI and then, for effective use at scale, via action code. Do these test in a new file so you’re throwing away test detritus. Otherwise you hit the problem of a seeming bug but which is actually a forgotten/broken earlier test in the same file. Once you know how to set various features, look at them in several different views - certainly thus you might use. Don’t overlook Attribute Browser as it can save a whole farm of reporting agents you felt were needed but which you view infrequently - AB view may deliver that far more quickly when needed and with less background overhead. It may be your style makes it sensible to use a badge (for one view 's purpose) and colour (for a different view). Taking this incremental path also teaches you general automation techniques helping bootstrap your knowledge enabling you to try more complex things.

You will find some limitations along the way, but this will enable you to build your project within the capabilities of Tinderbox’s toolbox. It avoids the scenario of over-investing in an imagined outcome before understanding if it’s a possible (or indeed optimal) approach within Tinderbox.

For early steps, don’t overlook the tutorial PDFs in the Help menu. Once you get going remember there’s aTbRef as a functional reference on what things do (as opposed to how/why to use them). If you get stuck, ask us fellow users here. Good luck.


(James Fallows) #5

All of the advice here is excellent. I might underscore the perhaps non-intuitive step, referenced by @mwra, of applying one of Tinderbox’s “advanced” seeming capacities relatively early, in addition to becoming familiar with the basics of note construction etc.

That capacity is in fact the Attribute Browser, which is something I use all day long with different Tinderbox files. Its power is allowing you – without constructing agents or queries or anything similar – to group and display your data by any criterion you have in mind. For example, if you’re adding a Topic or Theme or any other tag to your info as you enter it, the AttrB can then display all your data grouped by topic. You can limit the display to items that meet certain criteria. (Simple examples: tasks grouped by Due Date, excluding those with no set due date – or a date more than a month in the future.) For numeric or financial data, you can see it grouped by category – or date, or payee, or amount.

You’ll find extensive descriptions and screen shots:
Here , which is the most detailed thread; also
Here ; also
Here; also
Here

And each of those will link you to more. Once the concept of the Attribute Browser clicks for you, I think you’ll find it a natural way to do a lot of what you have in mind. Here’s a sample screen shot from one of the previous discussions, showing research notes grouped by theme.