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).