I think just about everyone at some time or other has wondered whether they have the makings of a best selling book within them.  An old school friend spent several years tyring to get himself published, before giving up and throwing his lot in with Lulu.com .  Occasionally, when we meet up for a drink, the conversation drifts towards the state of the current book market, and he recounts tales of woe involving rejection letters.

Well, it took me about 45 minutes to become an author, and I wasn't even trying.  JavaFX in Action,  my first book, has just hit the printing presses, and for all those (like myself) who've wondered how a computing text book gets written, the following should be a real eye-opener.

[Freebie copies are available for those who survive to the end of this posting.]

The phone call

The journey started with a phone call.  Actually, the journey started with an email requesting a phone call, but let's not complicate things.  The email was from Manning, who I'm sure many of you recognise as the publishers of numerous computing books, each sporting the picture of a colourful character from bygone times.  I'd received email from them before, usually to ask if I would review a proposal for one of their books -- but this time it was different, this time they wanted to phone me.  The call was arranged, and at the appointed hour I duly found myself chatting to Micheal Stephens (an Associate Publisher) about the state of the Java market, and the industry in general.   The conversation moved around to JavaFX, a topic I'd recently blogged about, and I told Micheal I thought the technology showed a lot of promise.  He then , bold as brass, dropped the question "would you like to write a book?"  "Urm, sure", I responded.  "What would you like to write about?"  Well the answer seemed pretty obvious -- JavaFX.

And with that, I became an author.  (Well, okay, there was all the stuff about contracts etc -- but in the best Hollywood style I'm skipping the boring bits.)

Initial thoughts

Once you've agreed to write a book it dawns on you you've just given birth to a few hundred blank pages crying out to be filled.  What to write is one concern, but a more pressing concern is how to write it.  The structure of the book needs to be decided before a single word can be typed; and as an author that's where you begin, trying to map out a few basic principles that will guide the content as it is created.

I began by wondering why anyone would buy a programming book in this day and age?  Twenty years ago text books were the dominant way to become informed about a technology, but now every major programming tool comes with on-line documentation, if not context sensitive IDE help.  Do computing text books have a future?.

Technology moves fast, and books can't easily keep up.  The latest developments always arrive on pixels before they arrive on paper -- that's why with JavaFX in Action my intention from the start was to try something different.

On-line content is fragmented; it's great if you want to further explore a technology once you're already an insider, but if you find yourself on the outside trying to find an easy route in, it's often next to useless.  With JavaFX in Action I didn't want to merely regurgitate the on-line documentation, but compliment it; taking the reader by the hand and leading them on a journey of discovery, so they become familiar not only with the how of JavaFX, but the why.

My feeling was that it shouldn't be necessary to get bogged down with examples of every class variation, as so many technology books try to do.  Just take a representative sample, show some imaginative applications, then let the reader apply their new found learning to the on-line documentation for themselves.  That way the book would still remain relevant even after the technology has expanded with later releases.

JavaFX is a fun technology, and I felt it was important JavaFX in Action reflected that fact.  Each chapter should present a project with a unique set of challenges, then show how to solve those challenges using JavaFX.  The reader will learn JavaFX in a natural setting (rather than abstract code snippets) and end up with a series of mini-apps they can use as the basis of their own experimentation.  Each project should be fun and imaginative, but exhibit functionality that can easily be translated to a wide range of real-world applications.  Enjoyable and entertaining, but practical too!

With these ideas in mind I quickly rattled off my first attempt at a table of contents, emailed it off to Manning, and counted the hours to the conference call where it would be dissected.

Know your readers

Lesson #1: book buyers are fickle.

Book publishers do an awful lot of research on the reasoning behind our buying decisions, and the general consensus seems to be we're a finicky bunch.  For example, if an Eclipse user sees only NetBeans screen shots in a book he'll likely put it back on the shelf.  For books with a very specialist subject the market is too tight to risk alienating one group or another, so you have to be careful what the readers see as they skim the pages of your masterpiece in the local book store.

In my particular case the choice of whether to centre the book around a particular IDE was a particularly important one.  When I started writing I didn't really know who the intended audience was going to be.  JavaFX is new technology that spans programming and design, and it wasn't immediately clear from the noises coming out of Sun who they expected would be using it.  A lot was being made of the user-friendliness of the JavaFX Script language, with its plain-English error messages; did this mean the intended audience included graphic designers?  At the same time JavaFX Script contained some pretty powerful programming features; perhaps the intended audience was seasoned programmers?

I decided to hedge my bets.  I'd write the book from an IDE agnostic viewpoint,  but direct the reader at relevant junctures towards IDE specific on-line tutorials and resources.  The bulk of the prose would assume the reader had solid programming skills, but sidebars would explain unfamiliar coding terminology to any novice.  The book was intended as a tutorial, not a reference, so I didn't think it was necessarily impossible to meet the needs of both audiences, so long as I was careful.

Everyone's a critic

Lesson #2: your readers often know more about what makes a good book than you do.

At several points during the writing of their books, Manning like to take the unfinished manuscript and show it to half a dozen or so critics.  Some may be deeply involved with technology being written about, others may be totally unfamiliar with it, and one or two may even be advocates of rival technologies.  Their comments are fed back anonymously to the author, who is then charged with writing a plan of attack to answer their criticisms.

The first review of JavaFX in Action wasn't all that bad.  They thought the project based format was good, each concept was explained well (if a little verbose in places), and generally the book had a friendly tone which suited the material.  One thing they didn't like, however, were the short detours intended to explain basic programming concepts to designers/novices.  Even though most were outside the main flow of text, reviewers just didn't understand why they were there.

I gave the prose more pace, without losing the friendly tone, and moved all the novice material into an appendix.  After a few more chapters were written the book was reviewed again, by a mostly new set of reviewers, and the result was a big thumbs up.  But this second set of critics contained some developers of big commercial projects, who wondered how the techniques demonstrated in the book related to the business-oriented applications they worked with in their day jobs.  To answer these criticisms I added mini projects to the foot of some chapters, spotlighting techniques of particular interest to commercial or business developers.

The extra mile

Lesson #3: if you go that extra mile to produce a better product, you'll find a lot of people are prepared to pitch in and help.

One of the strengths of the book was also its greatest curse for me as the author.  I didn't want to just reproduce the available documentation, I wanted to get underneath the skin of JavaFX to really give the reader an appreciation of what was happening, but without descending into jargon.  Luckily the engineers at Sun were only too willing to help out, ensuring my easy-to-understand explanations didn't give misleading impressions, or contain factual errors.

Like other publishers Manning operates an early access programme -- at regular intervals the book was released to readers, who jumped onto the web site forum and posted corrections, comments, suggestions and encouragement.  I have to admit the prospect of having dozens of back seat drivers commenting on the book as it was being written was not immediately an appealing one, but I soon discovered the early access readers are an invaluable sounding board.  You can throw ideas out and get meaningful responses, long before you commit yourself to several evenings of hard slog at the keyboard.

Published and be damned?

A crunch moment came as we approached JavaOne.  Sun would be releasing a new version of JavaFX at the event, featuring a controls API that would be invaluable for serious application development. The reviewers had been particularly keen to understand how JavaFX could be used in a commercial context, and the 1.2 release would be a big step in that direction.  We knew other books were being rushed to the presses to meet the JavaOne deadline, and this left us with a dilemma: do we rush JavaFX in Action out to compete with the rivals, or hang back and spend more time polishing the 1.2 content?

After an extended conference call, Manning decided to back me in taking a risk: we'd miss the JavaOne deadline and use the time to boost the 1.2 content throughout the book.  I also wanted to write an entirely new 1.2-specific chapter, which I did in parallel with the final review process.

The final review takes the form of a technical proofreading, where an expert (and we were particularly lucky to get someone very close to the JavaFX project) pores over the prose and listings, picking holes and finding errors.

Once that's done, you're into the home straight.  First the index has to be created, which involves trawling through every chapter, marking every keyword and phrase; then the front matter has to be written (the dedication, preface, etc.); and finally the typesetters start laying the pages out, giving you one final chance to fix errors and make changes.  And then it's all done.  Cast in stone.  Nothing can be changed.  And a few weeks later the doorbell goes and a box of promotional books is deposited on your doorstep -- and then it dawns on you, you've actually written a book!!

Freebies

Do you want a free copy of the book?  Are you prepared to write a review on Amazon, or on your blog?  I've got a few to give away, and all you have to do is finish this sentence in the comments section: I DESERVE A FREE COPY OF JAVAFX IN ACTION BECAUSE ____________