Curse and swear? (certainly)
Restore the backup? (definitely try)
Look for a backup of the backup? (absolutely while cursing and swearing)
Redo the work you lost? (arrrgggghhh)
Well, you blog about it of course.... :-)
Being new to this blog thing, I am compelled to write about my latest frustration. I was up last night till about 11:00 pm working on Chapter 7 of Mastering Revit Architecture. Now Word has been acting a little strange lately by asking me if I want to save the Normal.dot template all the time. I don't know if this is the cause, but it seems that the last time my DOC was saved was at 7:52PM not after 11:00 when I closed all the files and stopped working.
I use Windows Offline files to keep synchronized copies of everything on my server copied to my Laptop. This allows me to unplug and go mobile and still maintain access to all my files. Mostly it works as advertised with a few caveats. I will refer to this as redundancy number 1. I also have a Seagate Mirra backup NAS device. This gadget sits in the closet making continuous backups of files as I save them. (Remember the save part). Let's call this redundancy number 2. Finally, I have a Carbonite account. (www.carbonite.com) this is an online backup service that also continnuously backs up files in the background as you save (again remember the save part). This will be redundancy number 3. Finally, I have Word creating backup files (WBK) with each save. (There's that "S" work again). Redundancy 4.
So what happened. Well the short answer is, I must not have saved. You would think that with four levels of redundancy (and really more when you combine them - consider that both Mirra and Carbonite also keep previous versions and that both backup the main DOC file and the WBK file) that it shoudl have been a simple matter of restoring one of these multiple levels of redundancy and getting on with my day. HOWEVER, it appears that I just forgot to save. Hard as that is to believe. Or maybe, it was all those dang messages Word kept throwing about the silly Normal.dot file? I like that explaination much better because it makes me a victim rather than an dope.
Backtracking - I was working away in Word, making edits to my file. Time passed (a couple hours it seemed) and I made the classic blunder: I did not SAVE OFTEN. So when I got ready to wrap it up for the evening, I began closing applications and saving when prompted. this went fine in Revit - no lost work there (this time). Fine in Photoshop - all images are intact. Fine - in SnagIt - likewise. Then came Word. As best as I can tell, it decided to bug me about the Normal.dot template. I never know how to answer this because I say "Yes" to save, then it complain about the file being used. So I try again and click "No" that time. So somewhere in this confusing and frustrating stream of dialogs and pesterings I must have clicked No to save on my Chapter file instead of the Normal.dot file. So that means that the DOC did not save. This means that the WBK did not update. This means that Offline files saw no changes and did not update. This means that neither Mirra nor Carbonite saw any changes to either the DOC or the WBK and did not save backups or previous versions. So redundancy 1 was bypassed, redundancy 2 - bypassed, R3 - bypassed, R4, 5, 6... bypassed.... All because I accidentally clicked the wrong stinkin' button.
Man I love computers.
Moral of the story. SAVE OFTEN.
It does raise an interesting loophole in background backup services...
Well, I gotta get back to work ReWriting the chapter I already wrote. Ah well, it's always faster the second time. ;-)
Tuesday, March 31, 2009
Monday, March 30, 2009
CAD Book Process continued
In the last post, I defined the various players in the process. I would like to now go into a little more detail on what happens at each stage. There are basically four phases from my point of view:
Planning looks something like this:
Mid-winter rolls around and the publisher and I begin discussing the new titles for the coming year. I have been blessed with titles that sell well enough for the publisher to be interested in regular updates. So, they usually offer to renew my contract. On occasion however, we have a title that has not lived up to expectations and the publisher declines to renew. This was the case with The Advanced Implementation Guide for ADT. (Reviews and feedback for the book were strong, but there were just not enough sales to justify regular editions).
Once we decide what title (or titles) we will tackle this year, we settle on any new contract terms, add an addendum to the contract, both sign and then off we go. The person who handles these details has the title of "Acquisitions Editor." I have had a few of these in my time. My current one is top notch. She is the very attentive and interested in top quality work.
During planning discussion, I have usually been exploring the alpha and beta releases of the software. I also talk to folks I know at the mother ship (Autodesk) and begin inquiring as to what is new and cool in the coming release. I am interested for two reasons: I want to know what features we have to look forward to as any user would, but the more important reason from a book-writing perspective is planning how much work the update will be.
Based on what I learn about new features, I begin planning chapter by chapter what will have to change in the book. This is still pretty high level, but for example, in the 2010 releases, I knew that the new ribbon interface was the biggie, so that means complete re-write of the UI chapters and all new screen captures throughout the book. This last one is huge. I am responsible for writing the copy, capturing all the screens and/or providing other "art" as appropriate and producing the dataset files for the back-of-book CD ROM. Capturing images and preparing datasets takes much more time that the actual writing does. So this release cycle is a bit of a challenge. I have a spreadsheet that I made to plan all of this. I try to list each item separately and track roughly what percentage is complete as I go. It works pretty well, but is not perfect.
Planning is a good first step, but you cannot really say you are writing a book until you start writing. Writing is done in "extracted word docs" from the publisher. These are Microsoft Word files that have been generated from the final proof files of the last edition. The compositor works in page layout software. So they have to take the final proofs from the last edition, pull all the text back into a Word doc and make sure all the formatting is correct.
We use the "Track Changes" feature in Word to do all the updating. Turn on Track Changes and begin making edits. All insertions and deletions are tracked by word and color-coded by user name. I make all of my edits to the chapter and they show up in a single color. This allows the Tech Editor to see what was changed comparred to what came from the previous edition. This makes it easier for them to focus on the new content. When I get the files back from the editors, I use the review changes feature to accept or reject the changes.
If you have never used Track Changes in Word, it is pretty useful. I woudl be happy to post a tutorial on it here if anyone is interested.
Well, that is it for today. I need to get back to writing. Next time I will elaborate on the flow to the tech and copy editors. I also plan to post a sample from the manuscript for Mastering Revit Architecture. I should have that posted soon.
- Planning - Decide what to write, plan it, scheme it, dream it, talk it up.
- Writing/Production - This is where the work gets done.
- Waiting - That very L O N G period of time between which I have finished all my files and sent them to the publisher and I wait for an actual printed book to appear on my door step.
- Sales - The very S H O R T period of time where the book actually has any viable sales (due completely to the very short release cycles of current Autodesk software).
Planning looks something like this:
Mid-winter rolls around and the publisher and I begin discussing the new titles for the coming year. I have been blessed with titles that sell well enough for the publisher to be interested in regular updates. So, they usually offer to renew my contract. On occasion however, we have a title that has not lived up to expectations and the publisher declines to renew. This was the case with The Advanced Implementation Guide for ADT. (Reviews and feedback for the book were strong, but there were just not enough sales to justify regular editions).
Once we decide what title (or titles) we will tackle this year, we settle on any new contract terms, add an addendum to the contract, both sign and then off we go. The person who handles these details has the title of "Acquisitions Editor." I have had a few of these in my time. My current one is top notch. She is the very attentive and interested in top quality work.
During planning discussion, I have usually been exploring the alpha and beta releases of the software. I also talk to folks I know at the mother ship (Autodesk) and begin inquiring as to what is new and cool in the coming release. I am interested for two reasons: I want to know what features we have to look forward to as any user would, but the more important reason from a book-writing perspective is planning how much work the update will be.
Based on what I learn about new features, I begin planning chapter by chapter what will have to change in the book. This is still pretty high level, but for example, in the 2010 releases, I knew that the new ribbon interface was the biggie, so that means complete re-write of the UI chapters and all new screen captures throughout the book. This last one is huge. I am responsible for writing the copy, capturing all the screens and/or providing other "art" as appropriate and producing the dataset files for the back-of-book CD ROM. Capturing images and preparing datasets takes much more time that the actual writing does. So this release cycle is a bit of a challenge. I have a spreadsheet that I made to plan all of this. I try to list each item separately and track roughly what percentage is complete as I go. It works pretty well, but is not perfect.
Planning is a good first step, but you cannot really say you are writing a book until you start writing. Writing is done in "extracted word docs" from the publisher. These are Microsoft Word files that have been generated from the final proof files of the last edition. The compositor works in page layout software. So they have to take the final proofs from the last edition, pull all the text back into a Word doc and make sure all the formatting is correct.
We use the "Track Changes" feature in Word to do all the updating. Turn on Track Changes and begin making edits. All insertions and deletions are tracked by word and color-coded by user name. I make all of my edits to the chapter and they show up in a single color. This allows the Tech Editor to see what was changed comparred to what came from the previous edition. This makes it easier for them to focus on the new content. When I get the files back from the editors, I use the review changes feature to accept or reject the changes.
If you have never used Track Changes in Word, it is pretty useful. I woudl be happy to post a tutorial on it here if anyone is interested.
Well, that is it for today. I need to get back to writing. Next time I will elaborate on the flow to the tech and copy editors. I also plan to post a sample from the manuscript for Mastering Revit Architecture. I should have that posted soon.
What is the process to create a CAD book anyhow?
Maybe you have always wondered just what it takes to get a book out the door. I wonder too... :-)
Revit and AutoCAD books (and other software books) are a little special because of the amazingly short life span. I always joke that if I had any sense (and talent for fiction) I would try to write the next Harry Potter. Such books don't "expire" every year when the new version comes out (Hogwarts 2010) and I'd have a much bigger potential audience. But alas, we write about what we know, and I know about Revit and AutoCAD Architecture.
There are several parties involved.
In the next post, I'll get into a little more detail on the process. That's all for now.
Revit and AutoCAD books (and other software books) are a little special because of the amazingly short life span. I always joke that if I had any sense (and talent for fiction) I would try to write the next Harry Potter. Such books don't "expire" every year when the new version comes out (Hogwarts 2010) and I'd have a much bigger potential audience. But alas, we write about what we know, and I know about Revit and AutoCAD Architecture.
There are several parties involved.
- The publisher - is responsible for funding, marketing and distribution of the book.
- The Author (me) - is responsible for writing the manuscript and providing all artwork and dataset files for the back-of-book CD. The author also reviews the work of each of the other parties and gives final approval before pages go to press.
- The Tech Editor - reviews all content for technical accuracy. The tech editor is an expert in the software and serves as a "second set of eyes."
- The Copy Editor - reviews the manuscript for grammatical content, consistency, spelling and adherence to formatting conventions. They also do the book's index. (Thank God for Copy Editors, the book would be pretty sad without them).
- Compositor - responsible for taking the delivered Word documents and preparing them into final page layout proof. They generate a PDF at the end that looks exactly like what the final printed page will be. Until this point, everyone is working in Microsoft Word.
- Press - actually prints the pages and binds the books.
- Distribution - all the folks that take the books from the press and get them to the readers.
In the next post, I'll get into a little more detail on the process. That's all for now.
Welcome
I am in the midst of another round of book updates for the 2010 releases of Autodesk's architectural products. This year I am planning updates for both Mastering Revit Architecture (which is well underway) and Mastering AutoCAD Architecture (which so far I have not started). I thought it might be interesting to keep a blog this year to track progress on the books. I have not completely decided what I plan to post here, but some ideas include:
- Progress reports on chapters as I complete them.
- An "inside" look at the publication process from the author's point of view.
- Excerpts of chapter materials.
- Supporting or related media.
- Unique content and tutorials that did not make the book.
Subscribe to:
Posts (Atom)
Welcome!
The traditional print publishing industry requires long production cycles before any book or publication can see print. This situation has become more acute for authors like myself who publish books on annual software releases. I hope to use this blog to publish information, updates, addenda, ruminations, and other "mid-cycle" missives. I hope you enjoy it.
Please be sure to also visit my website.
Thanks for visiting.
Please be sure to also visit my website.
Thanks for visiting.