There were two key tools I developed for it:
-
Reordering tools – quickly drag and drop sections and chapters around. I moved things quite a bit before I decided on the final order, so being able to quickly bump things was important.
-
TODO list – working exactly like the one I now have in my Zettelkasten, writing a link to TODO anywhere in a tiddler would automatically add an entry in my meta tiddler pointing directly to the section that needed something done to it.
Other than that, my writing process was mostly a big long list of things to write, change, or improve which I added to when I had ideas and removed from as I worked on the book. Not very exciting, but functional.
A related challenge with any creation this long, whether it’s a book, a software program, or something else entirely, is silent dependencies and cross-references between sections. For instance, the exercises in GTW involve a sort of “implied wiki” – it’s not actually in the book anywhere, but the user is creating a wiki based on the exercises as they go through the book, and for many of the exercises the implied wiki needs to be in a particular state. Making changes to one of the exercises can change that state, and it’s extremely tricky to recognize this as an author unless you just happen to remember that your change will influence something further through the book; obviously it’s not practical to read through every exercise to see if it might have an effect, even if you could be confident you would notice there would be an effect when you saw the exercise.
For something which is published once and is done, this isn’t all that big a deal, as you can just do all of the exercises a couple times, or have a first round of readers do them, and fix any problems that you spot. For GTW, which has to be continually updated to follow the changes in TiddlyWiki, this gets harder. I’m more or less stuck relying on users to send me feedback indicating that something’s wrong right now. (I get feedback of some sort almost every day, so this seems to be proving a fairly effective approach, but it’s too early to know for sure, and obviously it’s frustrating for someone to have to run into a problem before the book can be fixed.)
Takeaways in GTW have a similar problem, though this one is not as bad because changes to a section usually only affect takeaways within that section, so it’s practical to look at all of them and see if any need to be updated.
If the topics / sections / paragraphs were split into small enough units, I could imagine keeping track of some of these dependencies directly with a list field or something. I’m suspicious this might have a negative ROI though…if you’re working on a big project like a book, you tend to do a pretty decent job holding this kind of thing in your head, and tracking the dependencies within the text would be quite a lot of work. If you could come up with some creative way to use the dependencies to let the user navigate through the text, that might redeem the project since you’d be getting several things out of it.
This is getting a little off-topic into GTW’s problems specifically, but it would be interesting to see if some kind of “automated testing” could be developed to verify whether the exercises behave correctly when put together. That sounds fanciful, but while complicated I think it could actually be pretty doable. As an example, Python has doctest, which can programmatically verify that all the examples in your API documentation work. The “output” to be tested in our case would be the HTML generated by the rendering of a particular tiddler (this would cover most, but not all, things that could be wrong with the exercises – for instance, wrong instructions about what buttons to click to accomplish some task wouldn’t be caught this way). The structure of exercises and their answers would change a little bit so that the test framework could apply the answers to a fresh wiki, each exercise in turn. This could also make it possible for readers to grab a copy of the wiki at any stage and inspect it or continue working from there…in effect turning it from an “implied wiki” into an explicit one.
