I almost jumped in yesterday to say what Vermonter17032 as put forth. Support is actually very good in the grand scheme of things. When I fire off a question to Mr. Bernstein, I typically get a response very quickly that is accurate and helpful. On the forums, you get a lot of support from both the Marks as well as the community at large. It is not uncommon to see an issue get multiple, lengthy responses on the various techniques that can be used to solve it.
Where things have taken a step backward, in my opinion, is in the manual itself. It used to be they had a nice PDF that was released with every major upgrade. But I gather Eastgate was doing that entirely by hand in Acrobat or something and it took a lot of effort to keep it up to date. The switch to Apple’s Help system is, again in my opinion, not an appropriate venue for complicated software. Every since Apple made that window the superFloat monstrosity it has become, I’ve seen more and more software packages producing their documentation in PDF format, at least as an alternative. Even Apple produces documentation for their serious applications in PDF format. Tinderbox is one of those programs that really suffers under the Apple Help system. You can’t even search a document for a term! This makes long documents in it really hard to deal with. Anyway, that’s another rant.
Honestly I never use it. What I do
use is Mark Anderson’s excellent TBX-based reference file. It’s all the documentation you’ll ever need, neatly written up in a Tinderbox file that can be exported into a large website if you don’t want to read the raw nodes. It’s kept very up to date, and couple with TB’s own data management systems, is quite efficient for finding obscure things.
Beyond the mere description of features, tokens, and syntax though, I again agree with Vermonter. It’s really
difficult to document Tinderbox in a functional sense because it really is more akin to a programming language than ordinary software. When learning a new programming language, you focus on syntax and features, but the next step is very hard to address because due to the nature of a language, there are a zillion ways to do anything, and every solution is going to be different because every programmer has a different idea of what the implementation should look like. Tinderbox isn’t quite so bad as that, but it’s not far off. The interface is a set of tools, not a set of systems, and so building an implementation is learning to use those tools to accomplish what your vision is. That really isn’t something you can fully “document” outside of tutorial style abstracts which are hardly ever useful outside of the tutorial, except to help teach the concepts of implementation.
This is why you see things like “this is beyond the scope of the tutorial”, because once you get to a certain point, past the point of theory, every implementation is going to be different and the best you can do is just demonstrate a simple example that probably won’t work verbatim for anyone. Personally I like to take that extra step in the examples I produce for the Tb forum. I like to demonstrate how Attribute X will end up as Appearance Y in the final result, but this is just to show one possible way out of thousands.
That’s why a few simple, common export options in Twig make so much sense (they also make sense for TB). So, Hugh, like you I am hopeful that that will come along down the road.
I think TB 4 and 5 has made good strides toward that. There are number of prebuilt exporters that are always available, and now there are a number of prebuilt prototypes you can use to get your project going quicker. Tinderbox has always provided some default templates, but I think they integrated those in a much better fashion in more recent releases.
On price: I have no complaints about Tinderbox’s price. I usually skip every other year so I end up paying around $45 a year to stay up to date. That’s extremely reasonable for me, considering how much use I get from it.