Johnnie, could you give an example sort of question you're looking to answer and the sort of article you're expecting to find? The question's not idle. People regularly articulate what they don't like with the Help but there's nary an indication as to what they envisage in their minds eye.
Over some years of use & helping out I've noted, re Help, that people:
- don't want long form. Yawn, too much to read in one go.
- do want long form. Can print out everything in one place.
- don't want short form articles. Too much clicking around, can't print out in long form.
- do want short form articles. Allows rich hyper-linking and concise articles on topics.
- don't want PDF. Inflexible format based on dead-tree technology. Tends to have poor hyperlinking. Doesn't work so well on small screen with limited window space.
- do want PDF. Rapid word search of whole corpus.
- do want Help online, outside app. Mac in-app Help slow to load. No word search.
- want in-app Help. Web access is pervasive than thought. Not all all users live in first-world city areas with fast/always-on access. Some orgs bar on-demand access of their network.
- want it totally up to date. Conundrum: with a small outfit, delay releases whilst all new features are exhaustively added/reviewed/cross-reference to Help pre-release.
- want regular releases - qv last item.
- want to understand how there is no one correct way to do things in TB
- want to know the one correct way to do things [sic]
- want to understand incremental formalisation
- want exact step-by-step of how to implement incremental formalisation
- want Help to cover everything the app can do
- dont want Help to cover everything, only 'useful' (?) things
- want generic examples
- want very context specific examples
- want syntax examples
- don't want syntax examples that don't apply to their particular style of use
- want exhaustive change logs
- don't want to have to look at change logs
- don't want Help cluttered with references to techniques for older versions
- don't want Help to assume everyone uses the latest version
- want it comprehensive. Ensure constant review and re-linking.
- want small team's limited time that could be spent on app dev being frittered away on writing docs.
- want an online resource to link to. So updates mustn't break existing doc structure. So, how to add new stuff?**
...and so on, but you get the drift. No model suits all.
** FWIW, this is aTbRef's ongoing dilemma and why there are three editions still served online. Any significant re-factoring of the source breaks all inbound (web) links and so the doc grows old and ugly via incremental accretion of new stuff.As someone who's contributed to TB documentation/support in various forms over the years (PDF Help, wiki, forum, Help in HTML form, aTbRef, cookbook...) it's never been clear what people, in an addressable number, want - apart from it not being the status quo.
Much as I want to like wikis, experience shows few users understand them and without disproportionate effort by attentive wiki gardeners the wikis rapidly become a maze of litter-stewn paths leading nowhere useful. Far from being self-indexing, they rather seem to add to the task of making usable online resources.
The TB Cookbook is a very useful tool but it seems no one uses it, more's the shame.
Leaving aside my involvement, aTbRef encapsulates the inherent conflicts in above listing - it probably gets as many ticks as crosses.
Short-to-long form translation (i.e. such as HTML->PDF) maintaining rich hyperlinking is far less well supported than I'd imagined, having spent a while looking. That app space seems a mix of unsupported semi-documented semi-complete open source projects and Enterprise stuff that you have to be able to afford before you can assess whether their top-$ price ticket is worth it.
I'd certainly be up for getting involved in/doing some new deliberate stand-alone documentation (even better if not for free - groceries cost money!). I'll also be interested to see the publisher's/editor's brief, as I don't think that's yet known, for the reasons above.
Sorry if all this reads as a rant, it's not meant that way. It's just really had to see what what (an addressable number of) users really want.