Wednesday, May 13, 2015

Publishing Effective Modern C++, Part 1



Between 1992 and 2005, I published five books with Addison-Wesley. When I started writing what became Effective Modern C++ (EMC++), I assumed I'd publish with them again. That didn't happen. Instead, I worked with O'Reilly. Several people have asked about my change in publishers. In this post, I offer background information for my decision to change. The decision itself will be part of a later post.

This post is about publishing, not C++. Unless you're interested in some of the business aspects of publishing, I suggest moving on to xkcd now.
 
The post is long. You might want to sit down.

Book Publication Tasks

To me, technical book publication consists of four primary tasks:
  1. Manuscript creation is the writing of the book, including diagrams, tables, code examples, etc. It also includes having draft manuscripts reviewed for comprehensibility and technical accuracy.
  2. Production transforms a manuscript into products for consumption by book-buying customers. It includes typesetting, page layout, and cover design, as well as the generation of files suitable for printing or for delivery to end users, e.g., PDF, HTML, epub, and mobi (for Kindle). Production also includes having physical books printed.
  3. Distribution takes print books and digital book files and makes them accessible to prospective customers. That primarily means getting them into bookstores (both physical and virtual, both domestic and international), but it also includes arranging for translations into foreign languages.
  4. Marketing works to bring the book to the attention of prospective customers and to get them to take a look at it. Glossy brochures, promotional web sites, social media activities, organization of author appearances, etc.--that's all marketing stuff. So is the distribution of sample copies of the book to "big mouths:" reviewers, bloggers, high-profile community personalities, and other "thought leaders."
In a traditional author-publisher relationship, authors are primarily responsible for creating a manuscript, and publishers focus on production, distribution, and marketing. In reality, who does what is fuzzier. Publishers usually provide developmental editors as well as copyediting, artwork, and indexing services that help authors produce good manuscripts, and authors typically assist publishers in the creation of marketing materials that will appeal to the book's target audience. It's also assumed that authors will engage in their own promotional activities to complement those performed by the publisher.

For my print books with AW, I took care of both manuscript creation and production (my deliverables were print-ready PDFs), and I wrote almost all the copy used for marketing. For EMC++, I wanted to produce a book that looked good in both print and digital form, but I knew from people who'd been there that creating digital books that work well on multiple devices is a nontrivial undertaking. I therefore decided to let my publisher handle production.

The Cost of Bringing a Book to Market

For a publisher, taking on a book involves financial risk. It costs money to create a book, but there's no guarantee that the book will sell well enough to cover the expenses. One of the things publishers do is fork out the money needed to go from manuscript to book. But how big a fork are we talking about?

During my work on EMC++, I looked into self-publishing, and I spoke fairly extensively with a freelance firm with experience producing and distributing programming books. They ultimately quoted me a price of $25K to take my manuscript and create files for print-ready PDF, directly-distributable PDF, device-independent epub, and device-independent mobi. That fee also included getting the book into physical and online bookstores. Let's assume a publisher would incur roughly the same costs for production and distribution. We'll also assume that this would also cover the cost of preparing files for Safari Books Online, something that the freelance firm I talked to didn't do, but which I consider to be an important outlet for reaching corporate customers.

After digging a hole $25K deep, the publisher has final book files, but the diggings's not done. If the sales data for my books in recent years is representative, print books account for about two thirds of the revenue for a programming book. That means the publisher has to pony up cash to get books printed. The per-unit cost goes down as the size of the print run increases, but a common refrain in technical publishing circles is that most technical books sell at most 5000 copies, so unless there's good reason to believe that a book will sell better than average, a publisher won't want to print more than 5000 copies out of the gate. For a book the size of EMC++ (about 300 pages), I was quoted about $2.50/book for a 5000-copy print run--a total of about $12,500. (Bumping the print run up to 10K dropped the per-book price to about $1.90, but the cost of the total print run increased to $19,000.)

Those quotes were for a book with a two-color interior. That's the format for Effective STL and the current edition of Effective C++, and it was my plan for EMC++. O'Reilly decided to print EMC++ with a full-color interior, which makes the print book look much nicer, but also increases their per-unit printing cost. I don't know how their costs compare to the ones I was quoted.

I didn't look into the costs associated with marketing, but it's fair to say they're greater than zero. I'll pick a number out of a hat and say $5000 covers a publisher's cost to get marketing copy written, web sites implemented, press releases created, tweets generated, big mouths' egos stroked, etc. 

For a random 300-page two-color technical book with an "average" author and an initial print run of 5000 copies, then, the publisher is out $25K for production and distribution costs other than printing, $12,500 for printing, and an assumed $5000 for marketing--a total of $42.5K. But your average author probably wants an advance to compensate him or her for the 1000+-hour investment needed to produce the manuscript (per my blog post on how long it took me to write EMC++). Let's assume a $5000 advance. (I don't ask for advances, but if I had received one for $5000, that'd mean the 1350 hours I put into creating a publication-ready manuscript would have yielded a sweet $3.70 per hour. And they say higher education doesn't pay.)

The advance pushes the the publisher's up-front cost to $47.5K, which I'll round up to $50K, because I'm sure there are expenses I'm overlooking. Note that I'm not considering costs publishers incur after a book has been released, such as handling returns and tracking and issuing royalties. I'm looking only at the financial situation as of the day the first books are made available to the buying public.

Now, a one-color book would cost less than the two-color book in my scenario, but a longer book would cost more, and there are a lot of books with more than about 300 pages. For the kind of back-of-the-envelope analysis of this blog post, I'm going to go with $50K as the total up-front cost to take a manuscript and bring the resulting book to market.

Per-Book Revenue

My books generally list for about $50, so let's assume our theoretical new book lists for the same amount. For books purchased from the publisher at full price, that's also the publisher's revenue, but very few books are purchased at list price. O'Reilly routinely offers coupons for 40% off, and AW is currently running a sale on some of my books offering 50% off if you buy more than one title that's part of the promotion.

When the publisher sells a book to a retailer (e.g., Amazon, your local technical bookstore, etc.), the retailer pays the wholesale price, not the retail price. My understanding is that the discount off list to wholesalers is comparable to sale prices offered to end-customers who buy from the publisher directly, so let's assume the wholesale price of the book is 40% below list. That is, let's assume that for a book with a list price of $50, the publisher actually gets an average of about $30, regardless of whether they sell directly to individual programmers or they sell to corporate juggernauts like Amazon.

Those numbers are for the print version of a book. The list prices for digital versions are typically lower. For example, the digital version of EMC++ lists for about 15% less than the print version, and the list price for the digital Effective C++ is 20% below that for the print book. Furthermore, the discounts offered off list price for digital purchases are often larger than for print books. O'Reilly often runs sales on digital titles at 50% off list, for example, in contrast to the 40% off they usually offer for print books.

If we assume that our print book with a $50 list price has a digital list price of $41.25 (17.5% lower than print--halfway between how AW and O'Reilly treat Effective C++ and EMC++, respectively) and that digital sales typically take place at 45% off list (as opposed to 40% for print books), the publisher's revenue on digital sales is $22.69 per book. Let's call it $23.

If we now assume that print books outsell digital versions by a 2:1 margin, we come up with an average per-book revenue of $27.67 ((2*$30) + $23) / 3), which I'm going to round down to $27.50, because that matches the number I used in an earlier version of this post where I inadvertently counted the printing cost for print books twice. (Oops.)

Break-Even Points and Royalty Rates

A $50K up-front investment and an average revenue of $27.50 per book means that the break-even point for the publisher is 1819 books. Well, it would be if authors would work for their advances only. Most don't, and that brings us to royalty rates. O'Reilly used to put their standard contract online (they don't seem to do that any longer), and in that contract, the default royalty rate was 10% of the gross revenue they got from sale of the book. In the example we've been discussing, that'd be 10% of $27.50/book. With such a royalty rate, the publisher's take would drop to $24.75/book, the break-even sales number would increase to 2021 books, and we'd find we need a term to describe the per-book revenue a publisher gets after royalty costs are taken into account. I'll call it ARC ("After Royalty Costs") revenue .
 
When I first signed with AW in 1991, the default royalty rate was 15% (I have no idea what it is now), and with that kind of author royalty, our theoretical publisher's ARC revenue drops to $23.38/book. The break-even point rises to 2140 books.

But let's dream big. A 50-50 revenue split--a 50% royalty rate!--would drop the publisher's ARC revenue to $13.75, thus pushing the break-even sales number to 3637 books. If it's true that most programming books sell no more than 5000 copies, that implies that the chances of the book making money for the publisher are comparatively small, especially when you recall that I'm considering only costs that are incurred up to the point where the book is initially released. Also note that the break-even point includes no profit, and publishers generally take a dim view of projects unlikely to make money. We conclude (or at least I do) that for a "typical" technical book published under the conditions I've describe above, the royalty rate must be below 50% for the project to make financial sense for the publisher.

Royalty Calculations

Interestingly, at least one technical publisher offers a 50% royalty as part of its default terms: The Pragmatic Bookshelf. Look what they say:
We pay 50% royalties for our books. ... We take what we receive for a book, subtract direct costs (printing, copy edit, artwork if any, that sort of thing) and split it with you.
From an author's point of view, this is exciting, but note that before "the Prags" pay 50%, they subtract costs associated with the production of the book, including printing, copy editing, etc. That is, some of the $50K in up-front costs that technical publishers traditionally absorb as well as the cost of printing the book itself--something else publishers traditionally absorb--gets subtracted before the 50% royalty is calculated. There's nothing wrong or underhanded about that, but it's important to recognize that what The Pragmatic Bookshelf means by a 50% royalty rate is different from what a publisher like AW or O'Reilly would mean.

Self-Publication

If you want to keep more of the money that comes from selling your book (or if you simply don't want to cede control over production, distribution, and marketing), you need to take on more of the tasks that publishers traditionally handle. In essence, you need to be the publisher, and we live in a world where self-publication is easier than it's ever been.

If you publish using Amazon's Kindle Direct Publishing, for example, you reach the entire world in one fell swoop. The royalty jumps to 70%, too, which looks pretty darned attractive. At least it does at first glance. Of the three tasks that publishers traditionally tend to, however, Amazon addresses only distribution, and it addresses it only partially. The only digital formats it covers are PDF and mobi, and it covers them only for the specific files you provide. That means no epub, no Safari Books Online, no foreign translation, and of course no print books. Taking 30% of the revenue for such a limited service seems kind of pricey to me, though in fairness Amazon also covers the rather critical job of taking customers' money and giving you your share. Amazon also distributes book updates to people who've bought your book (e.g., to correct errata), which I consider an important service.

But look more closely at the 70% royalty rate. First, it's not available worldwide. For example, it's available in the USA, England, Germany, Japan, and several other countries, but not in China, Russia, Norway, or Sweden (among others). For details, consult this page. Perhaps more importantly, it applies only to books priced between $2.99 and $9.99. Where the 70% rate doesn't apply, the royalty drops to 35%. That means that a book priced between $10 and $20 yields a lower per-book royalty than one priced at $9.99! It's clear that Amazon wants books for Kindle priced below ten bucks, which is good for book buyers and good for Amazon's market share, but whether it's good for technical book authors is a different question.

If you succumb to Amazon's arm-twisting and charge $9.99 for your book, you get a $7/book royalty. If it took you 1500 hours to write, produce, and market the book (i.e., about 150 hours--more or less a full-time month--beyond what it took me to write EMC++), you need to sell over 3200 digital copies to have earned $15/hour (a number that is beginning to gain some traction as the new minimum wage in the USA). In view of the conventional wisdom that most programming books sell no more than 5000 copies and my experience that book buyers tend to prefer their book in paper form, that 70% royalty rate doesn't look as enticing as it originally did.

If you color outside the pricing lines laid down by Amazon or if you sell a lot of books outside the 70% countries, you're in 35% territory, and under those conditions, you should probably consider talking with The Pragmatic Bookshelf folks. (This assumes that your motivation for self publication is to increase your royalty rate. If your motivation is to retain control over all aspects of your book's production, distribution, and marketing, you'll probably find that all roads lead to self publication.)

Self publication can encompass more than just Kindle, of course. Kindle Direct Publishing can be one piece of a larger self-publishing strategy, whereby you supplement Kindle sales with epub and print sales through other channels. An example of an author who's gone that route is Bob Nystrom with Game Programming Patterns, which is available in a number of formats and through a number of channels. (The Kindle version costs $24.95. Bob didn't knuckle under. On the other hand, he complements his book-purchasing options with free online access to the book's content, so I think it's safe to say that neither Amazon nor anybody else will push Bob around.)

Another option is to bypass Amazon entirely, assuming the burden of distributing and selling your book directly. This lets you keep 100% of the proceeds from sales, though you then incur the cost of the online transactions (e.g., fees for credit card processing) as well as the rewards, such as they are, of customer service. But it puts you in the driver's seat of every aspect of your book's publication. That's the approach Bruce Eckel and Diane Marsh took for Atomic Scala.

Publishing Effective Modern C++

I briefly considered self publication via Kindle Direct Publishing, because I thought it would be an interesting experiment to publish EMC++ for $9.99 and see what happened. The $7/book royalty would have yielded more income than I'd get from a traditional publisher selling the book to Amazon for $23 unless I could have negotiated a 30% royalty rate (which is very high for traditional technical publishers), and the lower sales price would presumably have led to more sales, hence greater total revenue. I fantasized that it would also have shaken up the market for programming books and paved the way to a world where $10 was the new normal for high-quality technical books in digital form. The result would be parades honoring me, statues of me in Meyers Town Squares around the world, and a recurring role on The Big Bang Theory! (Hey, it was a fantasy, okay?)

However, I really wanted a traditional publisher. I didn't want to deal with production, distribution, or marketing, nor did I want to find people to subcontract those pieces to and have to manage them. Furthermore, the authors I know who've done the self-publishing thing still generally skip some distribution channels that I consider important, e.g., Safari Books Online or foreign translations. Working with a traditional publisher lets me focus on what I want to do (produce a manuscript), secure in the knowledge that it's somebody else's job to address the aspects of book publication that have to be done, but that I don't want to spend time on.

What I was looking for, then, was a publishing partner for Effective Modern C++ that would do the heavy lifting in the following areas:
  • Production: Turn my manuscript into high-quality files for print and digital publication. The digital files should work with and look good on multiple kinds of e-reading software (e.g., Acrobat Reader for PDF, Kindle for mobi, ibooks for epub), on multiple physical devices (e.g., tablets of various sizes and capabilities as well as conventional computer monitors), under multiple OSes, and under a variety of user configurations (e.g., portrait or landscape orientation, varying font sizes, etc.). The book should also look good in Safari Books Online (which is an HTML-based platform). When I update the book to address errata, all forms of the book should be correspondingly updated. (If you check out the EMC++ errata list, you'll see that my work on the book was far from over when I sent the "final" files to O'Reilly last September.)
  • Distribution: Get the book into online as well as brick-and-mortar bookstores, both in the United States and internationally, ideally in both print and digital form. Get the book into Safari Books Online. Arrange for the book to be translated into foreign languages. Push book updates for customers of digital versions out to those customers when updates are made available.
  • Marketing: Get the word about the book out in ways that I can't or that would not occur to me. I have no interest in marketing and, probably not coincidentally, I'm not any good at it, but I recognize that just because a book gets published doesn't mean anybody pays attention to it. 
 Scott

24 comments:

Irfan said...

Hello Scott,

Although the production costs that you’ve listed seem rather steep, however, as an individual who has neither worked in the publishing industry nor ever dealt with a traditional publisher, I can not challenge it with any authority.

That aside, as I once published a book with Amazon, I can tell you with utmost confidence that publishing digital versions suitable for all devices certainly does not require much effort. Unless you plan to launch a digital version that focuses more on creation of interfaces meant to amaze or leave readers in awe, then creating digital content suitable for all devices does not demand an unreasonable investment of time or effort.

Regards,

Irfan.

Scott Meyers said...

@Irfan: Did you publish a programming book, and if so, can you please refer me to it? If so, you're the first person to tell me that getting the formatting right for code examples on multiple devices under multiple configurations (e.g., both portrait and landscape) is not a challenge.

Blackmage said...

Scott, assuming you still hold the publishing rights and copyright (I know other technical authors such as my uncle that have gotten burned there), you could still publish it online via the various self publishers after you hit 5000 copies.

I know that the techdirt folks have been making the argument that lower price means higher returns. But different markets are different markets.

Eirik said...

Aren't your per-book gross-revenue numbers off? At least for the first 5000 books, you've already added in the cost of printing?

You can't both add in the printing cost and round up to 50k, and substract the per-book cost of 2.50 from the revenue numbers?

Scott Meyers said...

@Eirik: Yes, thanks for pointing out that I'm counting the printing cost twice. I'll revise the post to take that into account.

Scott Meyers said...

@Eirik: I've now revised the post to fix the printing-cost-double-count problem. At least I hope I have.

John Sonmez said...

There is another factor to consider—in fact, the primary factor I considering when publishing my book "Soft Skills: The Software Developer's Life Manual" (http://simpleprogrammer.com/softskills) with Manning—reach.

What I mean by this is that even though I have a pretty large audience from my blog, I am only reaching and only have the ability to reach a certain segment of the programmer audience.

A publisher like Manning, has a different reach than what I do. If I self-published, I probably could make a lot more money, considering I've sold over 5,000 copies in just 4-5 months, but by using a publisher, I'm able to reach a whole group of people who aren't exposed to my blog and my personal brand.

So, for me, that value of reaching that many more people is worth more than the money I make from the book.

Some of the people who read my book will come back to my site or be exposed to my brand and buy from me in the future.

I sell much more expensive products and training courses on my site, so even if I made $0 on the book, reaching more people is worth the effort.

Scott Meyers said...

@John: "Reach" is the kind of thing I roll into marketing: getting the word out to prospective readers. Publishers are generally better at that than authors, because publishers have invested years in honing how to do it. When I published my first book, AW asked me if there were any people or groups or publications, etc., ("big mouths") I wanted copies to be sent to so that they could spread the word about my book. I submitted about 10 people and places. I then asked AW how many people/groups/publications they had on their list. The number was close to 150. That's extended reach, and I agree, that's the kind of thing a publisher should be expected to bring to the table.

J.C. said...

Hi Scott,
Let me start by saying that in a short post you dissected how publishing works in 2015. Very impressive!
I own a small publishing house, so what I will say is based on my experience in publishing.

I feel that you didn't give much weight to the fact that you are a well known author. That detail, I think, is key when thinking about royalties. For a publisher it is only a risk when the outcome is unknown. While I don't know exactly how many copies you sell, I can guess that there is no question that the publisher will sell significantly more than what's required to recover the initial investment.
I am not suggesting that self publishing is the way to go. As you conclude, there are several tasks that you wouldn't want to do yourself (e.g. distribution and marketing), but times are changing and for someone like you it should be more like: "Scott pays x% to PUBLISHER for Distribution and Marketing services", and not "Publisher finds a gold mine and gives the miners a penny for each gold coin they get".

It was a great read though.

Anonymous said...

EMC++ is prolly the 1st book that looks very good in Epub format. It also has proper fonts to be viewable on a typical tablet device in a full page view. Mine is somewhat atypical Sufrace Pro 3.

I am amazed folx still prefer printed books. I now go for electronics exclusively. Yes, back in the day I did accumulate a good hundred or so of tech books in printed form, but all they do now is collect dust.

I love ability to have all my books in one spot, dust & curl free, not have to have lights on to read them etc. You can highlight and write notes on them too. Add search, instant index, bookmarks etc.

Irfan said...

Hello Scott,

The short answer to your question, “Did you publish a programming book?” is no. The book, or the booklet considering that it only had around 100 pages, discussed the UX offered by the mainstream web browsers — Chrome, Firefox, Internet Explorer, Opera, and Safari. I wrote it with an adult or middle-aged audience in mind either in the process of converting to a digital lifestyle or unwilling to venture outside of their comfort zone, people of the mindset that IE or Safari provides all of the features, or that they provide those features in their most usable form. I wrote the book with the aim to provide such individuals with as much information as I possibly could — I had yet to become truly proficient in the front-end dev technologies — to enable them to evaluate their options without first installing any other alternative available to them.

Concerning what permits me to state with such confidence that styling content, even that which includes programming examples, for multiple number of devices should not require any considerable investment of time or effort, it has its roots in at least a few different reasons.

1. Prior to commencing the testing of the features exposed by the aforementioned web browsers, I thoroughly studied the CSS 2.1 standard, certainly not a demanding undertaking but mandatory for the aforementioned task. To test the features, where the activity began at some point in the last quarter of 2009 or early 2010, I wrote multiple number of stylesheets to evaluate the accessibility options available to the users, either directly, via an interface exposed by the web browsers, or indirectly, by installing third party apps: you must have heard of Greasemonkey.

2. As an individual with vision (eyesight) related issues, to peruse book length digital content or even those posts which now enjoy, more-or-less, industry wide acceptance as “Long Reads,” posts with approximately 4000 or more words, I have to first customize the appearance to lessen the strain on my eyes. The foregoing has necessitated writing stylesheets for epub versions of the books and “Long Reads” on various topics within the field of computer science, which invariably involve plenty of programming examples. Although I’ve yet to finish the chapter on “Move Semantics” in modern C++ — ongoing investigations in the field of web dev, Bash scripting, and insomnia induced by well wishers — that you shared in your previous post, however, it already has a new stylesheet, and the chapter certainly includes a few programming snippets.

3. As an individual currently working on the 3rd rewrite of my soon-to-become-available website, I have already tested a fully responsive beta version. Although I had to rely on in-browser testing suites to test the responsive features, however, if I had to base my conclusions on the feedback provided by web browsers’ testing suites, then the second rewrite would have worked on devices with 320-480px (iPhone 4 and variants) to the 27-30" inch screens. Third rewrite has more to do with incorporating latest features and reduction of page weight.

Based on the aforementioned experience with writing stylesheets, regardless of the underlying reasons, I can, probably, make such a statement. Since finishing the standard, I have only occasionally, and just occasionally, encountered issues requiring more than an hour’s sleuthing on the Internet to find a proper solution not relying on any type of JavaScript polyfills.


Irfan.

Irfan said...

On Publishing With Major-League Players.

Hello again (complete response exceeded the limit imposed by Blogger),

When it comes to the mammoths of the publishing industry, the major league players, although I can not say with certainty how much an author eventually benefits by agreeing to their terms, however, their books certainly find a place on at least a few thousand, if not a few hundred thousand, shelves. The books published by O'Reilly, Addison Wesley, Prentice Hall, Simon & Shuster, either because of the importance or the tacit agreements with the institutions, not only find a place on the shelf of the interested reader but also the shelves of the government libraries and the libraries of almost all of the institutions teaching courses relevant to that niche. When I left the education system in 2000, Effective C++ and More Effective C++ enjoyed the status of must reads almost all over Pakistan. Anyone applying for a C++ job had to know the concepts discussed in those books inside and out. When publishing with the heavyweights of the publishing world, whether such arrangements — I have come across book marketing websites promoting placement of books in thousands of libraries as part of their marketing packages — benefit the author, I can not say with certainty; however, I can say this much with certainty that their print runs certainly exceed the 5 digit mark, probably even 6 digit mark (conservative estimate).

With the hope that your new book would soon become a must read, as well,


Irfan.

Irfan said...

Hello Scott,

The short answer to your question, “Did you publish a programming book?” is no. The book, or the booklet considering that it only had around 100 pages, discussed the UX offered by the mainstream web browsers — Chrome, Firefox, Internet Explorer, Opera, and Safari. I wrote it with an adult or middle-aged audience in mind either in the process of converting to a digital life style or unwilling to venture outside of their comfort zone, people of the mindset that IE or Safari provides all of the features, or that they provide those features in their most usable form. I wrote the book with the aim to provide such individuals with as much information as I possibly could — I had yet to become truly proficient in the front-end dev technologies — to enable them to evaluate their options without first installing any other alternative available to them.

Concerning what permits me to state with such confidence that styling content, even that which includes programming examples, for multiple number of devices should not require any considerable investment of time or effort, it has its roots in at least a few different reasons.

1. Prior to commencing the testing of the features exposed by the aforementioned web browsers, I thoroughly studied the CSS 2.1 standard, not exactly a demanding undertaking in itself. To test the features, where the activity began at some point in the last quarter of 2009 or early 2010, I wrote multiple number of stylesheets to evaluate the accessibility options available to the users, either directly, via an interface exposed by the web browsers, or indirectly, by installing third party apps: you must have heard of Greasemonkey.

2. As an individual with vision (eyesight) related issues, to peruse book length digital content or even those posts which now enjoy, more-or-less, industry wide acceptance as “Long Reads,” posts with approximately 4000 or more words, I have to first customize the appearance to lessen the strain on my eyes. The foregoing has necessitated writing stylesheets for epub versions of the books and “Long Reads” on various topics within the field of computer science, which invariably involve plenty of programming examples. Although I’ve yet to finish the chapter on “Move Semantics” in modern C++ — ongoing investigations in the field of web dev, Bash scripting, and insomnia induced by well wishers — that you shared in your previous post, however, it already has a new stylesheet, and the chapter certainly includes a few programming snippets.

3. As an individual currently working on the 3rd rewrite of my soon-to-become-available website, I have already tested a fully responsive beta version. Although I had to rely on in-browser testing suites to test the responsive features, however, if I had to base my conclusions on the feedback provided by web browsers’ testing suites, then the second rewrite would have worked on devices with 320-480px (iPhone 4 and variants) to the 27" inch screens. Third rewrite has more to do with incorporating latest features and reduction of page weight.

Based on the aforementioned experience with writing stylesheets, regardless of the underlying reason, I can, probably, make such a statement. Since finishing the standard, I have only occasionally, and just occasionally, encountered issues requiring more than an hour’s sleuthing on the Internet to find a proper solution not relying on any type of JavaScript polyfills.

Irfan. (If it has already been submitted, then accept my apologies; I’ve been having issues with blogger since noon.)

Scott Meyers said...

@J.C.: I'll talk a bit about known versus unknown authors in part 2 of my treatment of this topic. Note that in part 1, I wrote about "a 'typical' technical book published under the conditions I've describe above." My books tend to sell better than average, and, in theory, that changes things. But does theory equal practice?

Stay tuned :-)

Scott Meyers said...

@Anonymous: I'm glad to hear that EMC++ looks good in epub on your Surface. The production team at O'Reilly has worked hard to make it look good on a wide variety of devices.

For some hard numbers regarding the popularity of print versus digital versions of books, check out Bob Nystrom's blog post showing that in the first two weeks, he sold 796 print books and 351 digital copies, a print/digital ratio of 2.3:1.

Personally, I think print and digital books have different strengths and weaknesses. I use both versions (even of my own books), depending on whether I'll be reading longer passages (e.g., entire Items) or looking up short chunks of text or code. For searching and copying, of course, digital is the way to go.

Because I think both versions of books are useful, I wish publishers and booksellers would work harder to sell both versions together. For EMC++, O'Reilly makes the digital versions available for only 10% over the cost of the print book alone, which I think is quite reasonable ($50 for the print book, $55 for the print book and the digital versions together), but that applies only for purchases at the full print price. For print sales at discounts off full list price (which is almost all such sales), the option to purchase the digital books for a small additional fee is not present. I think that's unfortunate, and I've encouraged O'Reilly to reconsider their policy.

Scott Meyers said...

@Irfan: It sounds like you've worked only on mainstream browsers on traditional "non-mobile" platforms, e.g., PCs. Getting something to look good there is likely to be a lot simpler than getting it to look good both there and on the various Kindles (some support color, some don't, and they come with varying screen sizes and resolutions), the various Android tablets, the various iPads, etc. Bear in mind that just because a standards document says something is true, that doesn't mean it's true on all implementations--a fact of life that C++ developers should be quite familiar with.

In practice, my understanding (based on reports from people who've had to do it) is that getting highly formatted text (such as code displays) to look right across a range of devices, device orientations, and device configurations often calls for device-dependent CSS (or its equivalent). It's a labor-intensive, time-consuming, tedious task.

Irfan said...

@Scott Although I can not deny the fact that I have only tested my work on PC and Mac platform — an individual with limited budget — however, I must add that your informants probably forgot to tell you about the existence of node and grunt modules that append or prepend, based on requirements, all of the device-specific and orientation-specific instructions. The labor and time required to address those inconsistencies thus amounts to almost zero seconds.

Irfan.

Brett said...

I bought your book as it was only one of those 50% sales, I would not have otherwise as I'm poor. And I do like to support the writers if I can. So it was a bummer to see that you get such a small cut.
I like the idea of the $9 ebook, I would even be happy if it was more like a journal than a book.
I would also be interested in buying a book via a Kickstarter project. When I could give a couple of dollars or a few to buy the book or more to also get some of your past books.
Thanks for your book it helps me to understand C++.

Scott Meyers said...

@Brett: Don't feel bad about buying the book on sale. I'd do the same thing. Who wants to pay list price?

As for my cut of the book's selling price, I do better than the "default" numbers I mentioned in the post, because I have a track record of selling more than the "normal" number of books. I'll have more to say about this in part 2 of the post. What I wanted to do with this post is give you some insight into (1) the non-writing factors that go into publishing a book and (2) the general financial situation from the perspective of a technical publisher. I also wanted to explain why self publication is, for me, not a terribly attractive option.

Irfan said...

Hello Scott,

My last comment contained a couple of mistakes: a typo and a reference to the underlying technology instead of the actual automation technology or tool.

1. I have, so far, only managed to test most of my work, the stylesheets written when I was evaluating the browsers for the book and most of the other stylesheets that I have written since then — on PC and Mac “platforms,” a couple of different platforms actually.

2. The “node.js,” a project sponsored by Joyent, provides the underlying infrastructure or the API that powers the front-end development automation tool Gulp JS (link to an article that provides an excellent introduction to Gulp JS, and How to make it a part of your workflow). In my last comment, I had mistakenly mentioned Node as the workflow automation tool. If that comment caused any confusion or resulted in wasted time on the Internet searching for the right package, then I offer my unreserved apologies.

3. Although I would, if given the choice, use Gulp.js as the workflow automation tool, however, if anyone or any one of the readers wants to read more about Grunt, then the following article tries to introduce the tool: Automate Recurring Tasks with Grunt. As I have neither read the article in detail nor used the technology, so I can not comment on the quality of the content, or whether it manages to introduce the tool satisfactorily.

Just wanted to make sure that the mistakes made in the previous comment would not lead to wasted time on the Internet.

Irfan.

Jay Blanchard said...

Great insight on the process Scott and even more eye-opening for a nascent author such as myself.

I have been fortunate to work with a publisher who makes things as easy as possible leaving the author to focus on the content and the layout (though the layout of my second book was way beyond my control and is, in a word, ugly). I have discussed self-publishing with other authors at length and some are well-suited to the task of taking on the publisher's role where others just don't have the knowledge or want the hassle.

I personally fall into the second camp and my publisher, at the moment, has slowed their process on asking for new titles. I have tech edited a couple lately though.

Jay Blanchard said...

...I hit enter too soon....

It is unknown if I will be authoring another book any time soon. As I look at the available titles I find it harder and harder to pitch something which would be new and useful. I have started blogging though will continue to do that as the ideas strike.

Varun mishra said...

informative post, Thanks for sharing

Varun mishra said...

Great post, thanks for sharing.