Re: [Tads3] Eric Eve's Getting Started guide

["Mike Roberts" <mjr_@xxxxxxxxxxx>]

Doeadeer3@aol.com wrote:
> I've reuploaded it to another site, and downloaded it to check it's whole.
Thanks - it looks like this one worked for me, too.

> I'd almost volunteer to turn the finalized T3 manual into a Windows Help 
> File
> (as I said there are programs helping one to do so, one puts in hot spots 
> for
> cross-referencing, indexing, etc.), except I have a faint idea how much 
> work
> it could be and I have no foreseeable free time for some time.
Hopefully that won't be necessary.  I'm not a big fan of manual conversions 
like this, since (1) the conversions are so much work to create in the first 
place that they never, ever get updated when the original is revised, and 
(2) because I'm well aware of (1), there's a big psychological and practical 
disincentive for me to update the original once conversions exist.  That's 
been a big factor in why I never update the tads 2 manual - I know there are 
all these conversions floating around, and if I update the original, all of 
the conversions become branched versions and no one is quite sure which one 
is right.  So I try to make do with "delta" documentation on the updates 
instead, which is a big obstacle for new users after a few versions, since 
you have to manually roll forward the deltas in your brain.

So I feel a pressing need to create the documentation in such a way that I 
can automatically generate all target formats off of a single source base.  
As long as the process is automated, there will be minimal cost to 
incremental updates to the base version, since I can just crank it through 
the generator on each update.  At first blush, the various after-the-fact 
conversions are just like this, in that they use some automated tool to 
convert from TeX to WinHelp or whatever; but in actual practice, the 
after-the-fact conversions always involve an enormous amount of manual 
tweaking, and that manual tweaking is never automatable because the tweaking 
information isn't ever merged back into the source material.  I think the 
only way to make such processes work truly automatically is to use a tight 
feedback loop, so that I'm effectively designing simultaneously for all of 
the target formats; rather than tweaking what comes out of the conversion 
generator, I instead go back and tweak what goes *into* the conversion 
generator, ensuring that the same tweaks will be reproduced in future 
updates.  It's not practical to do this for ten target formats, but I think 
I can do it pretty well and pretty efficiently for two; and in this day and 
age, I think targeting HTML and PDF would cover the bases pretty well.

Doe, since you're a fan of WinHelp, do you think I should consider that as 
an additional target format?  I'm not sure that I'll have enough bandwidth 
to do that - but maybe there's a bigger constituency for WinHelp than for 
HTML or PDF and I just don't know about it, and if so, I should consider it. 
 My personal feeling about WinHelp is that it doesn't really bring anything 
to the table that HTML doesn't, but maybe I'm missing something.

--Mike

_________________________________________________________________
Need more e-mail storage? Get 10MB with Hotmail Extra Storage.   
http://join.msn.com/?PAGE=features/es