Wondering what your “hourly rate” is when you go out and write a technical book? Traditionally, publishers will tell you that you do it for “exposure” but we all know that you can die from that. Seriously, even for the publisher it’s a big gamble, and with all the extra costs for printing, marketing, publishing, whole-sale prices, etc. there will be nothing left over for you. And “exposure” will not pay the bills.
There’s a much better approach: self-publishing and learning the basics of marketing to sell your book to the right audience. As an added bonus, you’ll know each and everyone of your readers and can build a strong relationship with them—which is awesome for you as you can fine-tune your book to reader’s needs and for your readers because they feel there’s an actual human being there listening to them.
To achieve this, you have to keep your costs low and your profit margin high. It’s no good to sell many copies with almost no profit, as the market for highly specialized books is limited.
Here’s my 5 rules to go for:
(Rule #0: Have great content that is relevant to your target audience. That goes without saying!)
Rule #1: No publishers. Publish the book yourself.
Rule #2: No 3rd-party sales channels. No Amazon/Kindle, iBookstore, etc.
Rule #3: No DRM. DRM has never stopped anyone from pirating stuff.
Rule #4: Publish as a PDF. Optionally also as EPUB, depending on topic/audience. No dead-tree version, please.
Rule #5: Price high. Price for the value you provide, not for what feels right.
No publishers obviously cuts out the middleman. Of course, you’ll have to learn how to market your book—you can’t just sit there and wait for people to come. You might say, “But Thomas, you have a billion followers on the interwebs, your stuff sells by itself!”—I’m hearing this all the time, but being “internet famous” (in a very small circle) isn’t going to sell your book. I have to work on getting the marketing right just as hard as anyone else does.
For ebooks like this, email lists work well. For people to trust their email address to a stranger (you), you’ll need to give them something useful in return—for example, a coupon code to get the book cheaper, free chapters or weekly tips and tricks. Email marketing done right is a bit of work, but it will pay for itself. And if you don’t market, you won’t sell. Additional things you should do is try to land interviews and guest blog posts on blogs relevant to your topic.
For Retinafy, I’ve built initial interest by giving away a Retinafying flowchart for free (the flowchart was downloaded almost 100,000 times), and I sent out approximately weekly emails to the list of people that signed up to be informed about the book, each with a little tidbit and reason why retinafying is important and necessary, why the book will make it super easy, and a quote from a reader (collect those!).
As for Rule #2—100% of the profits (after payment fees) will go to you. For some topics, 3rd-party sales channels work really well, but most highly specialized technical topics are not among those. (If you sell more than a 100 copies you’re selling more than most other self-publishing authors. But most of those authors fail to market right.)
Once you figure out the price (you need to set the price first, and remember to not base your price on what feels right, see #5), to be profitable and worth your time, you should calculate what you want your minimum hourly rate to be. For example, Retinafy took me about 50 hours of research and writing, and maybe another 30 hours of marketing. As of today, October 20 2012, I’ve sold 1088 copies, for a total sale amount of $22,393. For PayPal, you can assume that you’ll end up paying 5% or so in fees, so the profit so far is about $21,300, give or take a few. This makes my hourly rate when working on the book $266.25, and this is only going to increase with more sales.
No DRM (rule #3) is a no-brainer. It makes it harder for you and for your readers, breaks things, is ugly and most importantly never stopped anyone from pirating. Don’t bother.
Now as for rule #4, depending on your audience and book topic, just a PDF is enough. For example, I sell Retinafy.me only as a PDF. Now some people will give you flak about that, but the book has a lot of illustrations, screenshots and tables that can’t be formatted in any sane way (meaning not weeks of work) with EPUB, so I choose to have a PDF only. If it’s not a book about design and UI issues in particular, you’ll probably want to publish as an EPUB. (I’ll try to write about the toolchain I use in an upcoming blogpost.)
And we come to the last, and probably most important rule, price high. Your readers get value out of your book. If someone works for an hourly rate of say $100, reading my Retinafy ebook will save them perhaps a full week of research, trying to read through blog posts, compiling information, running tests, trying things cross-browser, and so on. That’s $4000 spent on a book that costs $29. That’s less than 1% of the money you lose if you’d research it all yourself (and I’m an expert on this topic, so it will probably take you more than a week, and you wouldn’t be sure if you found the right answers). Never forget that your target audience is professionals. They spend money every day on things that are useful and provide value to them. $29 for an ebook that provides thousands of dollars in value to them is a no-brainer. (Heck, I should probably have priced it higher!)
Anyway, this how you can sell a book yourself, provide tremendous value to people—and make a tidy profit.
Use the same high-res background images for both normal and retina. This works great if you don’t support IE before version 9 (like Google!)—just replace images used by background-image with high-resolution versions and use background-size to scale them accordingly (works great with CSS sprites!)
Create a proper Favicon. This will make your websites icon not look ugly in bookmarks and browser toolbars, and will only take a few minutes.
If you’re willing to spend a little more time, I’d highly recommend to look into replacing bitmapped images with CSS gradients and effects, and/or with SVG-based images. It’s more work, but it will pay off in faster loading times, less complex HTML and more flexibility to change designs and adapt them to new requirements (for example, if you decide to implement responsive design).
The display resolution of a screen describes the total amount of pixels available in each dimension—for example, the original iPhone has a resolution of 320×480 and a 2012 27-inch iMac clocks in at 2560×1440. Some people use terms like “VGA” resolution for some of the more popular resolutions (VGA is 640×480). Don’t bother trying to memorize all of them, as there are too many screen sizes these days.
Pixel density, on the other hand, is how many pixels fit into a fixed amount a space, and is most often given as pixels per inch (ppi) or dots per inch (dpi). These units are the same and can be used interchangeably. For example, the original iPhone sports 163 ppi, while the 27-inch iMac has a density of 109 ppi. It follows that the iMac compared to the old iPhone has a much higher resolution but a much lower pixel density.
So what is “Retina” exactly?
Glad that you ask. First off, “Retina” is a marketing term Apple uses to say something is “high-density”, but for the sake of simplicity I’m liberally applying this term to anything that’s not a “normal” density, or more specifically any display where, by default, one CSS pixel is larger than one physical screen pixel.
A screen that is, in Apple-speak, called a “Retina” screen has twice the pixel density of a “normal” screen with the same physical size. That’s four times as many pixels. There’s also some in-between densities on some Android phones, for example the Google Nexus One phone has a 1.5× higher pixel density than a “normal” phone. This is equal to slightly more than 2× as many pixels. In Android-lingo, that’s called a “high DPI” phone.
Read on in my ebook!
Want to make your websites all ready for the smorgasbord of screen resolutions and densities? Fear not—my latest ebook Retinafy your web sites & apps now will guide you through the jungle! Learn how to deal with all this in 30 minutes reading, and have your site all shiny by tomorrow!
Just design “retina-first”, use SVG and modern CSS whenever possible and for bitmapped images, go high-resolution and let the browser scale down. Make exceptions when you have to.
Yesterday I sat down and implemented a cross-browser (WebKit and Firefox, I don’t count IE) way to achieve a “fade out the element on the right with a mask” effect for our upcoming web app Charm Customer Support—it’s harder than it should be, and here’s how it works:
Fist off, for WebKit-based browsers, the -webkit-mask-image CSS property is used with a CSS gradient. This is really easy to do and straight-forward. However, on Firefox, you need to use a SVG-based gradient that’s piped into the mask CSS property. As far as I know, you can’t just copy+paste the mask property into an external CSS file—if you do that you’ll need to specify the SVG gradient in an external SVG file as well.
While there are relatively few expensive laptops that have a Retina screen, practically all mobile devices have a high density screen. And if you think this is just an Apple-thing, you’re dead wrong—all Android phones and tablets, the Amazon Kindle Fire, the Playbook, and Windows Phones have high-density screens. On the enterprisey side of things, Microsoft announced that Windows 8 will have full support for high-density desktop computers and laptops.
Let’s put this in context: mobile internet usage has doubled last year, and right now about 20% of all web traffic in the US is from mobile devices. This means Retina screens will soon become the norm.
If your websites and apps aren’t Retina-friendly, you’re going to be showing standard definition websites in a high-definition world. It’s not going to be pretty.
I’ve done weeks of research on it and put together the first, definitive guide on the essentials to make your websites and apps shine on high density displays. You can learn all that in just 30 minutes. And it’s out of beta now—updated with the latest and greatest information.
30 minutes to websites and apps that shine on high density displays—in the amount of time it’ll take you to sort through what to read on the web, you could instead read my ebook and be half done with Retinafy-ing your websites already!
An assumption that a lot of web developers have is that retinafying images by doubling their resolution results in files that are four times larger.
The reasoning goes like this: If I take a 100×100 pixel image, that has 10,000 pixels, and has a file size of, for example, 10kb, doubling the resolution to 200×200 means that there are 40,000 pixels now, and the file size must increase to 40kb accordingly.
However, image compression doesn’t work like that—it hardly scales linearly with the amount of pixels in the image.
Let’s look at PNG images first. These are often used for interface elements, logos and so on. There are huge areas of transparency, of single colors and of repetitive color patterns that doesn’t change. Because of that, actual file sizes of images that are twice the resolution of the original don’t differ that much.
For JPEG images, you can just double the resolution (or go as high as possible depending on your original image source), and lower the JPEG quality. Don’t be afraid to go as low as 15 to 25, as shown in these example photos from my Retinafy.me ebook. Yes, on a normal density screen this would cause all sorts of ugly JPEG artifacts—but don’t forget that on a retina screen pixels are so small that you can’t see them, which results in JPEG compression artifacts being far less visible. And when you scale the bigger JPEG image down for display on a normal screen, you get results that rival much higher quality JPEG images at the small resolution.
Note that exceptions prove the rule, and you may end up finding an image which doesn’t compress well or which has visible issues on low quality JPEG settings. For these, I highly recommend spending some time to figure out the root cause and implement workaround (you’ll find information about what to look for in my book!).
Whether the small pixels of retina screens scare you (just kidding!) or you’ll simply don’t want to spend countless hours researching it, my book will be your guide. Step-by-step instructions will show you how to upgrade to high-resolution screens with the least effort. Plus, I’m obsessed about loading speed and image quality.
What’s a Retina screen, and which variations are out there
Why you should use high-resolution images by default
The most efficient way to target retina screens in CSS
How to use CSS and SVG to replace bitmapped user interface elements
Deciding if you need two versions of an image
Creating beautiful favicons that work great on any screen
How to keep file sizes of images in check
And create Retina-ready web sites in no time!
The book also includes easy to follow rules, a decision tree and case studies; as well as detailed comparisons of various quality settings when dealing with high-resolution photos. You’ll also learn how to workaround issues when features are not supported (SVG on Android, hah) and when things are rendered badly.
Right now, the book is in beta and rough around the edges… but you’ll save a cool $10 off the final price if you buy before it’s finalized (the final version should be available in late Summer 2012!).