Too long.

It takes more work, but try to make it shorter.

The best value I've gotten from books is being able to avoid the slew of occasionally useful factoids and be told what stuff I should really care about.

The endless details I can find on the Web if I need them; the problem a tech author should solve is in helping the reader know what to care about and when.

That is to say, if you're going to write something, every word has to have potency. This gets at the cut in half, cut in half, cut in half advice.

In short, good writing is concise.

A friend then said he would be happy to pay even twice as much if the author could have made it half-again as short.

BTW, I could have sworn that quote was from Chekov. Either way, on the money.

When I was one of two co-authors of a book I don't recall being told to hit a specific page count, but there was a push for a certain degree of "thoroughness." This typically meant going into possibly tangential details to avoid sending someone off to another resource. (Though if the other resources was another Wrox book then allowances we made.)

For example, in a book about XML (Pro VB 6 & XML[0]) there was a need to go through the XML specification. A whole chapter. I ended up using this as an opportunity to explain the spec and build some helper libraries that would make interacting with a DOM easier later on, so not a total loss, but it had a feeling of busy-work to me.

That was sort of a best-case scenario; two authors splitting book. I also worked on assorted individual chapters for other books and there I had an incentive to bolster the word count because in some cases it affected the pay.

In my experience writing a single chapter meant either a flat amount or a per-word rate. Writing multiple chapters opened up the option of royalties instead. I took royalties on the VB book and did OK. Sadly this gave me a false impression of tech writing as a profession.

Many Wrox books were more a collection of padded chapters than coherent, well-planned, guides. OTOH I think many people plunked down $40-50 just to get specific chapters that would get them past some problem.

[0]: As the Velvet Underground sang, "Those were different times." :)

The biggest thing to understand that isn't obvious for a first-time author is that as soon as you sign the dotted line, you'll be on the publisher's schedule. They have to plan out when to release and sell your book months in advance.

All of those chapter deadlines are also for the other people involved - tech reviewers, copy editors, production, etc. So if you run late, it squeezes them. I've done tech reviewing for a couple of programming books, and when the author gets behind, the editor pushes the tech reviewer to get the chapter turned around extremely quickly. Guess what that can do to the quality of your book!

Another thing to know is that the "control" of your book is very strange, especially if its successful and the publisher wants 2nd and 3rd editions - check your contract, but they may have the right to assign another author to the book and release an update if you refuse to do the update. What this means in practice is that you end up having to do the update yourself whether you have the time scheduled or not to keep someone else from doing a crummy job updating your book.

I would suggest thinking about what kind of a book it's going to be, and who the audience is. Is it more of a reference book for people who know HTML and want a hard copy? Or is it for people who are learning HTML for the first time, and want to learn HTML5? Is it a book that assumes people know what vim and emacs are? Or is it a book that takes 1-2 paragraphs to explain what a text editor is? Is it a book for nerds? Or a book for retired dads looking to make their first website?

I'm not going to say 500 pages is too much or too little, because I don't know what kind of a book you're writing yet.

Also: some hackers here already mentioned that a lot of HTML5 information is available on the internet. I would think carefully about what your book will do that a google search can't.

-Make examples as small and concise as possible. I hate paging through example code in a book. -Consider the book a complement to people working through code samples you provide on their computer. -Make a single place to download all of the examples easily.

-Build a good outline and refine it carefully. -Build a way to track your progress through the book. Ex: a jar of candies counted out for each chapter or milestone.

-Write with as much maturity and wisdom as you can muster as that will make an exceptional book. -Plan how to handle every distraction that will come up.

-Smile when you write.

Something I have found in common with many of the thicker books (400+ pages) that I liked is they are broken up into a couple of very distinct sections. The first part is usually an intro and explanation of the material. The middle is more elaborate examples of how to use the materials. The back is more of a reference section.

Something that drives me crazy is when books skip steps. Don't assume that the reader knows what the middle step is just because it's mentioned in chapter 2 doesn't mean I'll remember it when I get to chapter 9. Or 6 months later when I am looking at the book trying to remember how to do something. It's a book not mysql you can have something in more than one place.

Org-mode is an Emacs mode with a first-rate outliner and a Markdown-like syntax. It easily exports to LaTex and/or to PDF.

Firstly congrats on the contract. You must be an expert in the field to be offered a contract.

The aim of quantity (pages) rather than quality is troublesome. I would be aiming to write something that achieves an objective - like an average web developer will understand how to apply HTML5 after reading; or a complete newbie will be able to start using HTML5....

I recommend going to a bookshop and checking out the current books on programming languages/frameworks. Try and find a style that matches your objective. Look back at books you read and what helped.

Unless this is an extensive reference guide, focus on quality content rather than reams of paper.