...is thus far a pleasant experience. Antoine and I have to hand in a chapter each in about twenty days' time. That's not much to fill those days with if you have nothing else to do, but we both have day jobs (well I do, Antoine's mostly busy without various degrees of holidays ;-p) and thus I don't think that it's too long, especially seeing that we need to get into the right pace and get a feel for how a technical book works.
So today I decided to spend my afternoon working on it, and it went better than I expected. Following our editor's (Simon St.Laurent) advice to pick a chapter that would be rather representative of the kind of content present in the rest of the book, but not too hard so as not to discourage us, I chose the chapter that introduces the DOM to the reader, then moves on to explain why it's useful, how it can be used, what are the traps, and what's special about the SVG DOM.
It was a good chapter for me to start with because I know the DOM in and out, but I was also a bit challenged by having to explain it to other people, not total beginners at programming or XML for sure, but maybe new to the DOM itself.
The reason I feared that part was because there are some things which I know people fail to understand in that area that I fail to understand why they don't understand (or something like that). Namespaces for instance have a few quirks but are really simple for anyone that knows about scoping. As a perlian, they feel totally natural. The DOM as a whole is something else. People keep complaining that it's huge and bloated... well it's only mirroring the complexity of the underlying XML, and that isn't all that complex. It might not be elegant, it does have its quirks, but I have yet to see a better solution. What's more, it's all very simple and is really a tiny API compared to anything "serious" (most W3C specs are tiny compared to specs produced by genuine standard bodies such as the ISO).
That's all fine and rosy when I'm the one that needs to use the DOM, but of course it's nowhere near as good if I need to explain it to someone else. "But hey! Come on, it's simple" doesn't get you very far, and certainly doesn't make the reader feel like he spent his bucks wisely :-)
Well it's too early to judge of the quality of the text (and in fact, given that I tend to braindump first then turn that into english it's likely that it isn't very good) but I surprised myself with the amount of things I managed to find to say on that topic. After an hour spent staring at a blank screen, I wrote for seven hours in a row to produce a little more than ten pages of content, complete with examples and all. I didn't have time to write all that came to mind and had to quickly sketch out the ideas of what is to follow so as to not forget them. At this rate, I'll produce fourty pages for that chapter which I'll cut down to twenty five when I rework it (I find that a lot easier than the other way around).
And it was all very enjoyable. I kept coming up with "A-HA, but I need to tell them about foo or they might not understand bar" ideas that I never thought I had. In a way, it's almost like writing fiction (feeling-wise). I sure hope that all of these ideas are actually useful (I'm sure my co-author as well as my editor will be helpful there), and that I'll be able to bang them into something readable as well as keep on writing like that for the rest of the book.
If this is a pace I can keep (ie circa ten hours a week with similar productivity) I should finish my part of the book just in time. Of course, this doesn't take into account hectic weeks or all-nighters, but I hope those two tend to cancel each other. It is also a fairly conservative estimate, so I do have hope.
And it being thus far enjoyable will surely help :)
