You’ve probably seen this suggestion, but worth mentioning again that Mark Bernstein’s book The Tinderbox Way is probably one of the best ways to get a good conceptual as well as practical grasp of the basics of Tinderbox. It’s especially good if you are someone who prefers to learn by getting a good conceptual overview in the beginning of learning a complicated thing.
Very true. And rumors are afoot of a possible update coming along soon…
Agree with Mark and Jim here. To take one simple use case as an example, you might have 32 notes that refer to people of interest before you realize that you would like each person to be connected to, say, a particular chapter. And that, on the other hand, you have never entered anyone’s Twitter handle. Add a $Chapter attribute to the prototype for that kind of note, then remove the $Twitter attrribute, and, ba-da-boom, you now have a way to capture data that fits today’s understanding of it. Not only in future entries, but in all the notes you have already entered. I know of no other software that lets your material evolve in this way.
This isn’t just a matter of avoiding the cognitive load of dealing with obsolete ideas (oh, right, I didn’t create a way to enter this info so I have to put it in this not quite right place). It also nudges you to think clearly about how your thoughts are evolving (do I need to add an attribute to all these notes? perhaps not, because now that I think of it, this morning’s notion is actually a version of this other idea, already embodied in the doc). This is why, for all the moments of widgety confusion (like, a + means two different things, say what now?), I rely on Tinderbox more and more these days.
For those feeling more hate than love (I’ve known such moments) I’d advise (a) keep it simple at first and (b) try to advance one very specific step at a time. I have learned much more, and improved my docs much more, when I had one specific thing I was trying to get Tinderbox to do. As opposed to setting out to understand everything about how an operator works, or trying to solve 3 problems at once.
I’m somewhat reminded of the process of learning a foreign language as an adult, though. As a fluent native speaker, I create fairly complicated structures (like this sentence) without even realizing that they are complicated. Drop me into a second language, and saying “just one thing” turns out to involve three or four different levels of complexity.
I think an aspect of Tinderbox that should be noted is that over its somewhat intense history of development there have been numerous features, attributes, actions, and so on, that Mark B. has added in response to user requests and suggestions, or (I assume) as result of his own research and emerging interests. So, Tinderbox has accreted a lot of add-ons, tweaks, and sometimes deprecated aspects. Mark A. does a great job trying to document the evolution of the software, in this and the other fora, and in aTbRef.
What I’m saying doesn’t change the love/hate issue – but it’s useful to remember for some, perhaps, that the price of admission also gets us an opportunity browse the odd bits and pieces of a development process that has always been attuned to the users who said “I have this project and it would be really useful if Tinderbox did this.” Et voilà! a week or so later this showed up as part of the Tinderbox feature set.
You’ll find those question / response threads all over this and the other fora. In that aspect, Tinderbox is like a really interesting attic crammed with the odd treasure.
Yep --the new Tinderbox Way should be out in 2-3 weeks
I’ve often mentioned how useful I find the Attribute Browser feature. I immodestly imagine that my whining and wheedling in predecessor forums over the years, about similar features offered by the MS-DOS program Lotus Agenda and the Windows program Zoot, might have played some role in the emergence of this great new-ish part of Tinderbox. (“Hmmm, how can we make this guy shut up? Well maybe if we did this…”) That’s a large-scale version of the continued program-evolution @PaulWalters describes here.
James Fallows is not wrong, though I’d classify it as gentle encouragement. Sarah Smith (King of Space, The Vanished Child) had requested the same thing earlier as well.
Very many thanks for all your replies and very sorry for the delay in answering. I’ll carry on with Tinderbox and I think the best way forward is to experiment with dummy data and see where it leads. Thank you for the very useful advice.
Such are the benefits of artisanal software. Constructive engagement with a responsive and thoughtful creator surely goes on the “love” side of the ledger. (I’m inordinately proud of the fact that there is a minor feature in Scrivener that resulted from my saying “it would be great if…”)
And btw the Attribute Browser was a great idea. Thanks to all who gently encouraged that one.
Tinderbox is a brilliant application of simple ideas. The idea that helps me most is having nested diagrams, coupled to an outline, with affiliated notes. My needs so far are modest; I don’t need the automation Tinderbox provides to help me maintain the model. If I don’t take things too far, Tinderbox is only a slight time sink.
Yet, even with those limited touch points, Tinderbox is a challenge. With respect to the “Principle of Least Astonishment” https://en.wikipedia.org/wiki/Principle_of_least_astonishment, Tinderbox doesn’t do well. That score assumes a particular user base – from the newcomer to the novice.
When I’ve been faced with or observed a simple challenge, the answer has been one of “here’s where the solution is hidden” or “that can’t be done for this subtle reason”. Tinderbox, the program, does not support investigation into itself. If a user’s requirement is valid and reasonable, it should be easy for that user to find a solution for himself. Doing a simple thing should be simple to do.
On the other hand, if Tinderbox’s target audience is the experienced, hard-core user, then its idiosyncrasies and niggling little bugs are excusable and its priorities are spot on. I might be one of those users someday. If that time comes, I’ll look back at this post and wonder what I found so astonishing.
The Principle Of Least Astonishment is primarily of interest for usability, which is to say, for the first encounter with the program. Tinderbox, unlike most programs available to end-users today, is designed not just to demo well or to have a pleasing first encounter, but for use in serious work over the period of months or years.
We could make a much simpler program that would seldom astonish anyone, simply by removing almost all the functionality from Tinderbox.
I wouldn’t say the target audience is “hard-core”, but rather people who are doing research and other challenging, intellectual work over an extended period.
That said, I honestly believe that, for the most part, doing a simple thing is simple to do. Want to make a note? Hit return, or – better still – double-click where it should go in the map. Want to select a note? Click on it. Want to delete a note? Select it and press Delete.
Want to do something fancier, like compose an action? The empty edit field gives you an example of an action. Start typing your own action; Tinderbox will autocomplete.
Need more information on what a Tinderbox attribute does? Sure – with more than 300 attributes, there’s a lot to know. Go to the system attribute inspector, select an attribute, and Tinderbox tells you what it does.
Usability is not just for the first encounter. Astonishment can rear its head at any point. If you don’t use a program day in and day out, you can forget things, especially when you’re constantly exposed to other programs which do things differently.
You seem a little defensive. I’m sorry, I didn’t mean any disrespect.
I would expect you, as an experienced, intelligent user, to find most all things in Tinderbox simple to do. It’s very hard to regain the perspective of an inexperienced user.
This is a very good example. I expected that information to also be available in the attribute browser. This is where I would be when I’m trying to manipulate a note. I just expected it there and was surprised that it wasn’t available as a simple tool tip. This surprise is the astonishment I’m talking about.
EDIT: I didn’t mean “attribute browser”. I meant the Note’s “Get Info…” popup. So sorry.
Go to the system attribute inspector, select an attribute, and Tinderbox tells you what it does.
Nomenclature can sometimes be a barrier. At first I thought “attribute inspector” must refer to the Attribute Browser. So I clicked around in there among the buttons and settings that I confess that I don’t entirely understand yet.
Then I realized the reference must be to the Document Inspector. There you click the document icon, pick an attribute and the description appears below.
One of the things that I find a little unexpected is that different “paths” in the menu seem to lead that same tabbed inspector: Stamps > Inspect stamps…, Window > Inspector, Stamps > Quickstamp, Window > Prototype Inspector, and perhaps other paths as well. And there is File > New Window instead of the expected Window > New Window. To me these menu paths are one aspect that makes the app seem more complicated than it is.
Having said that, Tinderbox is complicated, in a good sense. Just as a spreadsheet app like Numbers is complicated. Numbers looks simple on the surface, and offers deceptively simple built-in templates to get users started (built-in templates would be useful for Tinderbox as well). But it needs dedication and study to do complicated things. Tinderbox is similar in that respect.
Quite write Sumner. Nomenclature is a problem that caught me out. In my last post I said that I expected attribute descriptions in the “Attribute Browser”. I was wrong. I meant the popup that appears when you select “Get Info…” from the Note menu. That popup lists all the attributes in categories. It was there that I expected an easy way to get an explanation of any attribute (just a tool tip). Sorry about getting that wrong.
And, yes, Tinderbox does have a lot of good complication.
A program intended for serious work should facilitate discovery of the functions necessary for serious work. That is not my experience with Tinderbox. It is, by a wide margin, the most difficult software to understand that I have ever encountered. The fact that I continue to try is a tribute to its (perceived) usefulness, but the challenges are something for the designers to address, not to brag about.
20 days and 57 posts into this thread.
Interface design that meets all expectations and skill levels is quite difficult. Perhaps impossible. I don’t perceive that anyone is bragging – perhaps merely expressing a point of view? Perhaps a very well informed point of view?
Maybe it’s time for this thread to split into specific requests that the owner and the community can react to?
Opinions are fine, though observations about how software works that that read “I am frustrated and don’t like this thing” are difficult for designers / architects / developers (and the rest of us) to parse and understand what the call to action is.
It’s useful for all readers on any forum when individual suggestions or requests are specific (“I would like a command that does ‘this’”); explain why that might be a good thing; and are each in their own threads. (To avoid loss of focus.)
Designers can react to precise suggestions or requests: “the menu command ‘blah blah’ might be confusing and could be improved if the command were ‘yada yada’. I will explain why this is a good change …”.
I would second this suggestion. Over the years I’ve found that my progress with this program has been most advanced by saying: Here’s something I’d like to do. How can I do it? (See this related thread, which saved me a lot of time and taught me something for future use.)
<moderators hat on>.
This thread has run its course and I don’t think it is doing anyothing but encouraging moans about the app rather that what we can do using it.
Thread locked. Try to discuss issue fellow users [sic] can help with. This forum is not Eastgate’s formal tech support.