I think that’s more than a bit unfair. First, the “value proposition” (apart from being a tired old boomer term with no meaning) for Tinderbox is a highly sophisticated set of tools that are available for the user to explore working through projects from as simple as to-do lists to drafting mutli-volume works of philsophy. The slate is blank, build your own adventure. The challenge, apparently, is the user who shows up expecting a lovely automaton and gets what appears on first glance to an empty workbench. Unlike most of the highly opinionated junk sold today as “tools for thought”, this one is almost without opinion because it relies on what’s going on in the users head to guide the outcome.
Also, the designer has never promised or promoted Tinderbox as software built for “printing”. Instead, there is, as always, a very sophisticated set of export tools that can be molded to whatever purpose you want. But the user has to bring the purpose and work the tools. That’s the rationale of the product.
Sorry for the rant, but fretting about printing is missing the forest for the weeds. It’s a bit like being gifted an IBM Osprey and responding “that’s nice, but does it print”?
I’d firstly add an endorsement to all of @archurhh’s comments above, to avoid repetition.
FWIW, the fact that Tinderbox and Bookends have good interaction rests on two different developers agreeing to make mutually beneficial changes to their app. This isn’t a given when working cross-app. But, you’re using Zotero which doesn’t have a pseudo-protocol for local links (e.g. a zotero://... method) and has no developer as such, being a FOSS project (I think!). But people in the Zotero community may have developed plug-ins for that purpose (perhaps this?) so it’s worth asking in the Zotero community. Note: don’t use/know the app but there are users here( @satikusala?).
Stepping back, and following the point @archurhh rightly makes about not trying to do everything at once, do you need all the reference info in your TBX document. If—see above—you can link a Tinderbox note to a Zotero ref via a weblink (local or via the web), do you need to store it twice. Clicking a link to get to the info should be as fast as switching to another note. Plus, you might want to be viewing the reference alongside, not instead of the note using the reference.
Noting that you know you’ve “100s” of items (notes) in context, this suggests Map view may give you limited tractability , but only due to the volume of data. Once you can’t easily ‘read’ the map’s contents—i.e. you have to zoom out to much for legibility—do consider other views as well.
Choice and scope of prototypes is both personal and contextual to the task at hand. Experiment, and be comfortable to fail occasionally. That sounds counter-intuitive but the strong support for incremental formalisation, and to do-over, in Tinderbox is powerful, even if the promise only makes sense once you engage with it.
Tip: don’t rush to make a baroque structure of prototypes. They fulfil two (three?) different purposes whose salience varies by the work going on at the time. Simplistically they both visually style a note and set the Displayed Attributes, i.e the otherwise hidden attribute you want to see. Separately, $Prototype values is a really quick way to query for notes of a given type. BUT, don’t feel need to do all these things at once. For instance, it might be useful to have a number of different people-type attributes that need different (attribute) data captured/displayed. That can include a $PersonType user attribute that store the prototype’s name. Once input is done and you’re thinking of export, e.g. making a book, then the notes with different person-types prototypes can be assigned a common prototype, their derivation safely stored in $PersonType. This makes it easy to find/use all person type notes whilst not losing their more granular provenance.
And, that’s onlyone approach to that issue. The point of writing it out here is that unless you definitively know the end structure, don’t rush to guess: sort the later part out … later. Atypically for software, Tinderbox is very supporting of allowing later re-factoring. Compare that to an app using a relation database under=pinning—it would be much harder even if at al possible.
Or, keep one prototype $Person, create an attribute $Type and have action code work on off of the values of $Type. This would make search and other manipulations easier.
In my opinion, store an manage all your citations in Zotero. Only bring them over to Tindebox when you want to take notes on them. Again, maintain Zotero as your primary reference manager. Use a $CitationKey and action code to have TBX automatically tag the notes that relate to this caution. Absolutely install Better Bibex for Zotero. I have SEVERAL videos on Zotero and Tinderbox interaction. Happy to have one-on-one with you.
My background is not in academics but in financial analysis. I was therefore fascinated to see “value proposition,” something I’ve considered a serious business/marketing concept, dismissed upthread as a “tired old boomer term with no meaning.” Ouch!
As we all know, Tinderbox is complex. It’s also unique. Those two characteristics make weighing its value proposition–the benefits it brings to the table relative to its costs and to its competitors–a daunting task for a newcomer. Trying to do so is perfectly valid, I think, not to be interpreted as unfairly casting aspersions.
The specific suggestions that have emerged upthread in response to provocative and thoughtful questions have been helpful to me.
For me Tinderbox has been most useful in organizing and extracting themes from masses of textual data, such as emails. Also in extracting and summarizing numerical values from online posts, and displaying them graphically.
I haven’t produced fancy “printed” output (yet). But I dare to say, with the possible exceptions of sound and video, whatever output is indicated Tinderbox can produce, often more easily than anticipated.
I think of flexibility as a huge part of TB’s value proposition, both on the benefit side (other tools can’t match it) and on the cost side (learning curve).
Paul, I apologize if I hit your “Hot Button” with my “Value Proposition” statement. Really. It was meant as a clinic statement - not a pejorative one.
But let me assure you, contrary to you assertion, it simply isn’t true that the term “Value Proposition” is "a tired old boomer term with no meaning. To the contrary, it is a commonly used term in the field of engineering, economic engineering, and “value engineering” in particular. It is taught in engineering schools around the globe,and used as a means of optimizing engineering designs by engineers every day. Those that are 30 and those that are 70. Not tired. Not a boomer term, and not meaningless.
Thank you all for your positive and helpful comments! I am carefully reviewing each and every one.
One possible misunderstanding I need to erase before the dialog continues because I sense a high level of sensitivity here to any comments that could possibly be construed as critical of Tbx. I spent much of my career writing and running 300,000-500,000 line (source code) engineering software packages on supercomputers. While I am definitely a neophyte to Tbx, I have deep roots in the software and computing world and I can assure you I know what it’s like to immerse oneself in an overwhelming powerful and complex software package with faith that the investment in time and energy will be worth it.
My comments and questions about Tbx are intended to be clinical - not pejorative. They are not stimulated by some fanciful expectation that I will in short order become a power user of Tbx or even “use it well” for quite some time.
Rather, I’m like the guy who owns a 200 acre family farm and who is standing in the tractor showroom looking at that swanky new $400K tractor with all of its “bells and whistles”. Like him, I’m attempting to discern whether all of its capability and sophistication are (a) necessary for doing the work I need to do this season on my 200 acre farm, and (b) whether the bells and whistles are actually a help or a hindrance to me getting this season’s work done. He has ground to till, crops to plant, and harvests to gather. He can’t afford to spend a year learning how to get that done with his new tractor - regardless of its power and sophistication. He’s being told, trust us. It will do you jobs today and so much more you haven’t even imagined; and that it’s worth the investment in money and (especially) time. He’ll be eternally grateful he bought it. Does he take the plunge? What are his decision criteria? He has other options - less power, less sophisticated and less capable. His Value Proposition includes tradeoffs between sufficiency vs. ultimate capability, capability vs. purchase price, time invested in learning to harness the new tractor’s capabilities vs time spent actually tilling, planting, and harvesting… It’s an OJT proposition with high stakes. This is his world, his needs, his money, and his time. So, I’m that “farmer”, and Tbx is that new tractor. This may sound like a corn-pone analogy to some of you. But it’s a really good analogy that fits in my case…
So, please don’t interpret my questions and comments as anything other than reasonable questions from someone who needs a new tractor (SMILE).
Perhaps something that has been overlooked in all the talk of complexity is that it is possible to start very simple with Tinderbox. If I can express it this way, Tinderbox is like a suit of clothes that will expand and grow with you as you grow.
I have done a fair bit of qualitative data analysis (for a PhD in social psychology) and also spent around eight years researching and writing a history book (long before Tinderbox existed). Something that I learned from those experiences is that it is not necessary (indeed it can be deleterious) to put in much structure at the beginning. It is far better, in my experience, to just start collecting material and allow the material to suggest what one should do with it. I have droned on about this idea before, so I will suggest having a look at the graphic in an earlier post (What is the semantic tree of personal knowledge management? - #5 by MartinBoycott-Brown) which shows research as a “system” – an iterative process that constantly loops back to the beginning and steadily refines ideas.
It is far better to start simply with a tool that is capable of handling complexities as they are discovered than to start with a tool that is too rigid to adapt to emerging understandings and knowledge.
Jotting down some notes in Tinderbox requires almost no learning of the program at all. It’s the “back of the envelope” stage – all that is needed at the beginning, I believe. Complexity can come later when it is needed.
Your quandary is not new, I went through much the same crisis of commitment at some point (and, truth be told, a few smaller crises in the months that followed). The time/money commitment as an upfront question persists when investing in any capital equipment.
I concur with the simple suggestion proposed by @MartinBoycott-Brown. You can use the demo to employ the very basic concepts of Tinderbox - some outlining and map-view idea layout, play with links, Containers, a Stamp or Edict. See how it goes.
Also remember that Tinderbox doesn’t require a full commitment, unlike a typical database app where scaffolding is a prerequisite to entering concept. Rather, it works here in reverse. You can also create and export rather complex csv files from your spreadsheet app into Tbx at any time; and export your entire commitment out of the app at any time too (it’s xml).
Regards the ‘sensitivity to criticism’ aspect - I would suggest that rather than thin-skinnedness, it’s a from-the-hip reaction to a universal question (that’s been posed and answered many times here) of ‘will this Tinder match make a good life-partner?’ (apologies, I seem to be in metaphor-mode this week lol) - perhaps it’d be best to take it on a few dates and find out?
Not intending to step on toes with dissing “value proposition”, but after 30 years of Booz, McKinsey, PwC, BearingPoint, Deloitte, Leidos, etc. etc., traipsing into my office to eagerly tell me they have wonderful “value propositions”, better than anyone else, that just a few $million here or there will prove out, I’m skeptical. Anyway, it’s not a term I think is meaningful in discussing this sort of software. Just my own quirky viewpoint, I’m sure.
It’s perhaps worth noting that the ‘tractor’ analogy above, whilst understandable is perhaps not correct here. Why? Tinderbox is a ‘toolbox for notes’. So an Erector Set (or Meccano if you prefer) is a better analogy. A tractor is a finished product capable of many things, but all tractor-related. By comparison, with an Erector Set you can build pretty much anything, albeit constrained by the size and range of pieces available.
So, in the erector Set box there is no ‘plough’ piece, but pieces from the set can be used to make a plough, but you have to figure out which pieces to use. Moreover the plough you build and the one I build may both be ploughs—similar in function but possibly differing in style and use of pieces.
I think this is why the desire for assurances before starting a project confuses Tinderbox users. Can you write a book? Yes. How do you write the book? We can’t say as there isn’t one method and the type and content of the book haven’t been shared with us. Thus a Tinderbox user’s answers might seem cryptic or evasive if you think of the app as a tool for just making books, and books of only one or a few types. This is the wrong framing: Tinderbox is a toolset including tools/methods than can be used to make books.
New user’s “not having time” to learn implies the task is a known and bounded task, but the assertion is usually made in relation to an as-yet undefined task. In the same way, pre-emptively defining what we will refuse to learn/use, in advance of knowing what is needed is self-limiting.
Hopefully this goes some way to explaining why the ‘tractor’ analogy above, whilst understandable scenario, is unintentionally the wrong analogy by which to assess the problem. No user owns that exact tractor so can’t honestly give a blanket ‘Yes’ answer. But, in aggregate, users have done most/all of the things the tractor might do. The harder one pushes for an absolute guarantee for an undescribed task the less likely such an answer.
Someone can probably restate all this with great clarity (end of a long day here) but i think it does explain the disconnect that has occurred above.
As @mwra said! I might add also that an additional bonus of Tbx is that the components one builds for Project A can often/most-times be repurposed on Project B and thereon. Just as with an erector set, you are really building your toolkit, even while learning how to build toolkits for future use.
Isn’t Tinderbox both a tractor and a tool set? It can do a lot of things very nicely with little or no assembly required. But so can competitors. Its value proposition (its benefits vs its costs) becomes clearer with projects requiring a high degree of customization.
Come to think of it, it can output audio and video. Toss in embed code from YouTube or X or another site that provides that. It can pretty much do anything.
I sat down tonight and carefully read through each of your comments. There’s a wealth of information in them and I’m so very appreciative. Some of my takeaways so far:
Simple notes
Incremental formalization
Learn how to let Agents and Action Code do the work for you
Be prepared to learn some RegEx
aTbRefSiteMap, Michael’s videos, Duly Noted, Draft No. 4, and Martin’s Semantic Tree posts are good resources
Use Document Inspector to turn on/off global display of Attributes
Reference/Citation management approach is personal preference. Some do it all in Tbx. Some use Zotero. Some use Bookends.
I need to become familiar with use of $Prototype
Tbx’s Export feature is flexible way to interface with text processing software to achieve customized printouts of information
I like Mark’s Erector Set analogy. It definitely captures nuances my Tractor analogy misses.
Feel free to correct/expand any of my (highly distilled) highlights from the wisdom you’ve all offered.
I’m also creating a new post with a specfic question about whether and (at a high level) how Tbx could accomplish one bit of historical data analysis I know I will need to do. Please feel free to jump on that post with your answers.
Again, thanks to all for your patience and assistance.
Exactly how aTbRef started out! It definitely helped me understand the capabilities of export.
For most of us, I think the hard part is the step of seeing a view/feature demo-ed with someone else’s data and than trying to replicate that with our own data, which of course turns out to be slightly different from the demo.
Yes, but if we’re are to argue angles-on-pinheads on editions, and doing so would be to mis-read my previous intent. What I was getting at is that the ‘tractor’-type analogy is generally unhelpful in the early stage assessment such as starting this thread. Why? Because a key point is the app is far less fixed in the terms of what you may do. So asking “can it…?” of Tinderbox doesn’t generally have a meaningful Yes/no answer and is why users trying to help will genuinely ask “What are you trying to do?” or “How do you envisage doing it?”.
Also Tinderbox (and other open-ended tools!) do things that a defined-purpose tool, e.g the 'tractor, can’t. The latter can’t do so not because it is badly designed but simply because its design intent doesn’t include going up stairs or underwater, or whatever non-tractor thing. Thus another reason the ‘tractor’ metaphor is unintentionally unhelpful in early stage scoping of a project in Tinderbox and a cause of confusion to new users.
Let’s not for now, because you’ve pulled out a good set of observations that should get you off and running. Any precise quibbles on the list are fixable within Tinderbox and importantly will make more sense to resolve if/when they surface as issues. Otherwise well-intentioned corrections here would just load your plate.
I would add an item #11 and not because you missed it, but because its context didn’t get mentioned for far.
As you add automation and/or export, test new features in a small throw-away test TBX doc. Throw away hard work? Not exactly, the idea is to test a process we don’t yet understand and only once it is working in a manner to are happy with (and/or understand) do input it into our main project. Two benefits to this:
In a small doc there is less scope for edge case interactions. If the process works in test, we know the basics work. If, when put into the main doc, and if fails, it is easier to work out where to start looking for an edge case failure (e.g. your real data isn’t like your test data, etc.)
We don’t build up a load of cruft in terms of code from failed/part-complete experiments.
The advice in #11 will seem like extra work at outset—but stay the course and reap the benefit. Both the size of ‘small’ and exactly when (if!) you throw away the test is a matter of choice—you’ll get better at this with practice and find your sweet spot. Even if you throw nothing away, the tests are kept discrete from your main work so less scope for unintended results).