SIDEBAR: a while back, a couple of patent lawyers approached me to see about building a tool that would help them generate their client patent application documents quicker. They had developed an approach that was highly structured and looked like a great candidate for something that could make things easier and quicker for their workers. In fact, they wanted me to build them something that would reduce the amount of time it took by 1/3 to 1/2.
As they were explaining things to me, I'm thinking of something like a big template generator that had a bunch of combo boxes and edit boxes (both one-line and multi-line) on it. I thought of this as the "obvious approach".
When they were done explaining it, one mentioned, "Oh, we should tell you we just finished working with another coder who built something for us, but it didn't work out well." They fired it up and showed it to me. It was the exact thing I had conjured up in my mind as they were talking to me. It takes a very similar approach to how DB Data Modeler and most DB tools work.
The problem in this case was they said it took their people 2.5 times longer to create the documents, and after building several, it didn't look like they'd be able to speed up what they were doing by very much simply due to the way the tool was organized and what-not. This approach would not improve their time at all versus what they were already doing.
In other words, they found it was faster for their workers to use a simple copy-and-paste approach to taking boilerplate text from a document and then doing block text replacements and insertions where needed than to use a "more automated" tool that most programmers would lean towards building initially. Furthermore, using boilerplate was found to be decidedly faster than NOT using boilerplate. The so-called "automation" that tried to finesse the boilerplace approach only slowed things down.
Part of the trade-off is clearly a question of "how much of the necessary (or likely) text or program code do you include in the automated tool?"
I've got this other browser window open next to this one that shows something Bruno pointed me to in another question. It lists all of the parameters you can use in Build Events (for the Delphi Project Mgr pane). It's really handy because there's absolutely nothing in that Build Events panel to suggest what you might want to use. It's really not much more useful than a blank sheet of paper, implying it's designed for "experts" who already know what's needed.
Having drop-downs there that list possible parameters for Build Events would be helpful mainly if you're NOT a total expert and already know all of the stuff off the top of your head. If you ARE an expert, it probably won't speed things up much, if at all.
Similarly, it might be helpful to have a tab in the DB Data Modeler that lists a bunch of possible methods that would be useful, along with a way to select some (a check-list) that you wanted to have generated for you automatically. Not because everybody would use it, but because it's a useful help guide in itself. Simply not showing anything means you have to open a help page or the document and hope they both get updated when the information changes.
There are ways to be helpful in different ways that don't require the user to employ them every time. Sometimes just having the options listed there is helpful in lieu of having to maintain separate documentation in one, two, or even more separate locations.