Previous month:
March 2005
Next month:
May 2005

18 posts from April 2005

Amazon Pages – How Crowded Can It Get?

I hope my colleague Steve Hayes is right on his blog when he reports that Amazon is working on adjustments to their product page design. It seems that every time I visit Amazon there’s yet another new component on the page. Here’s a list of just a few of the elements of the current design: Book Information, Most Wished For Items, Join Amazon Prime, Ready to Buy?, More Buying Choices, Add to Wish List, Add to Wedding Registry, Recently Viewed, Better Together, etc., etc. These aren’t menu options from one box – they’re separate objects scattered all over the screen, and I didn’t even bother to scroll down to list the rest!

Amazon obviously knows what they’re doing. They continue to grow, and as I’ve mentioned in an earlier post, even when new programs aren’t right for me, I applaud their innovation efforts. To me though, the typical page is starting to look like the bumper of an old car with loads of stickers and other messages plastered all over it. I admit that the page still works well for a quick in-and-out transaction, but with all the various bells and whistles on the page the elements start to blend together like wallpaper. The result is that I haven’t played around much with many of them. How many other consumers feel the same way? Should Amazon try and clean it up, only putting a few of these on the page at a time so that I’m more inclined to try one or two of them out every so often? They use dynamic page design in other ways (e.g., hit the refresh button a few times on any of their Subjects pages and see how they rotate various promotions in and out) – why not extend it to something like this?

On a related note, I love what they did awhile back with the pop-up Search Inside the Book window. Hover over the cover image of a book in the Search Inside program and you get a nice, clean box with links to things like Table of Contents, Excerpt, Index, and more. This is a great example of how they’ve cleaned things up in one area. It’s nice to have these options hidden away until you really want to use them. Maybe this is an approach they could/should use on some of their other product page elements…


When Is a Topic “Big” Enough to Warrant a Book?

This is one of the great questions of the computer book publishing business. Once upon a time, many “experts” felt that the installed base for a piece of software had to exceed 100K before it was worthy of a book. Why 100K? The thinking was that you’d try to capture a minimum of 10% of the market with a book, which means you’d sell about 10K copies. Let me tell you something: Capturing 10% of the prospective market with a book would be pretty phenomenal.  It may have happened a time or two, but that’s a very high success rate.

So how do you judge when it’s time to roll the dice on a new topic? A lot of this has to do with how hot the topic appears to be today, how much it's projected to grow in the future, how soon you can get a book out the door, what competitive books are likely to beat you to market, etc. For my money, I'd rather be the first out on a small market topic with promise than the umpteenth book out on a topic with a huge base.

In general though, it's hard to get excited about a topic with only tens of thousands of prospective readers, unless the growth projections are extremely high or you can point to some other reason why a much higher percentage of prospective customers are likely to buy a book. That's still a bit of a tough sale.

One other consideration: These days, it seems like the hot new topics/books tend to be more of a flash in the pan than they were 5 or 10 years ago. The high sales rates for a hot new title/topic seems to only last for weeks instead of months. There also seem to be fewer hot new topics each year than there have been in the past. We’re all a bit starved for “the next killer app”, I suppose. Also, competitors pounce on new topics faster, causing there to be more than one book available, but I think even after factoring that in, the sales peak is much shorter these days.

At the end of the day, it once again shows that this business is more of an art than a science. You have to go with your instincts. If the topic has significant momentum and the author has a strong platform, it’s probably a risk worth taking.


“Safe Blogging”

What exactly does “safe blogging” mean? An interesting article on InternetNews.com (with quotes from Wiley author Shel Israel) talks about the EFF’s advice that “safe blogging is anonymous blogging.”

I hope I’m not the only one who thinks that’s lame advice. Why would you feel compelled to blog anonymously? Is it because you’re providing confidential information about your company? If so, you should be fired, regardless of whether disclosure happens on a blog, in an e-mail or anywhere else. Are you blogging anonymously because you want to complain about a co-worker, boss or your company? If so, are there better ways to address the problem? How about talking to that co-worker, boss or someone else in the company? If you’ve already tried all those options, maybe it’s time to change companies/jobs.

I realize there are some situations where, on the surface, anonymous blogging seems like a great solution. Every time I come up with another scenarios I wind up picturing a coward with an ax to grind…someone who really needs to just open the lines of communication and work to fix the problem rather than simply complaining anonymously.

I guess this is just a further extension of one of the nasty problems you often see with e-mail: People sometimes say things in e-mail that they’d never say face-to-face. I’ve been guilty of it too. Perhaps that same person is more likely to think they can hide behind a blog and say whatever they want. If I feel strongly enough about something to state my case publicly, I’d like to think I’m willing to put my name behind that statement.

Even if you disagree with me, do you really feel there’s a 100% foolproof way to blog without a trace? If someone really wants to hunt you down they’ll probably find a way.  It’s the same hubris that results in the occasional “anonymous” virus writer getting caught and prosecuted.


The Acquisitions Editor’s Role

After earlier posts about the role of the Development Editor and the Author, I asked Jim Minatel to talk a bit about the role of the Acquisitions Editor (AE). Jim is a top-notch AE with loads of experience. He recently launched a new blog that is dedicated to “finding good programmers and helping them write good books.” His post on the role of the AE is well worth reading. I also like what he has to say in a separate post entitled “Writing a good book proposal for me.” Here are a few excerpts, but be sure to read the full post on his blog:

Show me you can write.

If you want to write a book that several hundred pages long, or even a chapter within a book, you should be able to construct enough sentences and paragraphs to fill a couple of pages. Especially if you are a first time writer and want to break into book writing, your proposal will be a big part of what we use to evaluate your writing skills.

Be specific in your topic.

Don't write to me "I want to write an ASP.NET book." Tell me "I want to write a book on ASP.NET for experienced web developers. I'll cover X, Y, Z and those are important to experienced developers because…"

Do a little research about other books on the topic or similar topics.

If you want to write on a topic that many books already exist on, you should have read some of those books and should be able to explain what they do well and what you'll do better in your proposal.

Sell me on you.

Including your resume or CV is good. A one-paragraph description of your expertise that relates directly to the book topic is better.

Most of these can be boiled down to two key things: Do your homework and invest quality time in the documents you submit. I can’t tell you how many times we’ve received proposals on interesting topics but had to reject them because the author didn’t communicate well, didn’t study the market/competition or clearly did a rush job writing the proposal. It may sound obvious, but I get the feeling very few proposals are proofread these days. The more time you spend polishing your initial proposal documents, the greater the likelihood that you’ll stand out from the crowd.


The Author’s Role

In a post made earlier this week, I attempted to shed some light on the development editor’s role in the publishing process. I’m asking other members of our publishing team to do the same – you’ll see those posts in the not too distant future.

How about the author’s point of view? To get a good perspective, I thought it would be best to find an author who has worked for more than one publisher, has written at least a couple of books and has been in the industry for at least 5 years. Naba Barkakati was an easy choice. I’ve known Naba since his days as an author for The Waite Group. He’s written more than 25 books and is currently revising Red Hat Linux Secrets for Wiley. Naba also recently started his own blog: “Naba Tech, A New Light on Technology, Book Writing, and All That”. Here’s what he has to say about his role as an author:

While I focus primarily on the writing, I do get occasional glimpses of the publisher’s decision-making processes and I get to work with some of the professionals who take care of the behind-the-scenes details from manuscript review and copyediting to production and marketing.

I work with two key individuals - - the Acquisitions Editor (AE) and the Development Editor (DE). I start with the AE. We discuss ideas for the book and I submit a book proposal to the AE. The AE often wants some clarification or more details so that she can make the case for my book at editorial meetings. If all goes well and the book proposal is accepted, we sign the contract (I don’t have any agent, so it’s just myself and the publisher). The book is then launched and I start working with the DE, but we always keep the AE in the loop.

I write and submit chapters to the DE and the DE reminds me of submission deadlines and missing figures and so forth. The DE gets the manuscript reviewed by the Technical Editor (TE) and one or more copy editors (CE). I do the final author reviews and after a short while the book is in print. After the book is in print, I may sometimes participate in some online events such as chats that are aimed at promoting the book. Every so often I get email messages from readers with comments and corrections. I usually keep track of any corrections for the next revision of the book.

That’s a simplified view of my role in the publishing process. I do have a few lessons-learned from my years of experience with the publisher:

  • Prepare a good outline, set up a writing and manuscript submission schedule, and follow it as much as possible.
  • Give the DE and AE heads-up of any potential delays with the submissions or other problems with the software you are covering in the book.
  • Respond to all queries from the editors - - DE, TE, CE. If a change makes sense, gracefully accept it; if not, explain why the change should not be made.

Naba’s final points about delays and queries are important, but his first one about preparing a good outline is always at the top of my list. Authors who rush the outline or don’t give it the consideration it deserves are only setting themselves up for failure. The outline is the structural foundation of the book – even the most insightful, entertaining writing can’t hide the flaws in a weak outline.

Think you’ve got a killer outline ready for submission? Put it to the test: Find a trusted colleague or other expert on the topic to review it. Or if you’re really brave, leverage the blogosphere like Robert Scoble and Shel Israel are doing on their book: Post the outline for public view and comments. Just be sure you’re thick-skinned and ready to hear constructive (and sometimes not so constructive) criticism.