Instead of the stress of fighting for the deals at your local shopping center, why not lean back in your pyjamas and learn all about HTML5 Mobile pro development from the comfort of your home?
And even better, if you buy HTML5 Mobile Pro Desktop Edition until midnight on Friday, November 22, you get 55% off the regular price. Just use coupon code BLACKFRIDAY!
Happy Thanksgiving! 
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:
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.
Incidentally, looking at the hourly rate tells you how many copies you should target for—if the rate you project is below a certain number, it’s simply not worth writing the book. My lifetime-copies-sold goal of this particular book is 3,000 copies (at the current rate of sales, without additional marketing, I’ll reach this in a year or two, with an additional $50,000 coming in). For comparison, JavaScript Performance Rocks! a book Amy and I wrote in 2008, sold a total of 2686 copies so far, for a total amount of $79,964.96. (This is doesn’t include some site licenses we sold as well).
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.
Oh, and now that you know how much money it will save you, grab a copy of Retinafy your web sites and apps!
P.S. Want to discuss? Here’s the hacker news thread.
TweetHere’s three things you can do easily to improve your low-density website or app for people on Retina screens:
background-image with high-resolution versions and use background-size to scale them accordingly (works great with CSS sprites!)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 devil is of course in the details—but there’s no need to research all this yourself (which likely takes weeks!), just grab a copy of my ebook about Retinafying your web sites and apps!
Tweet
It’s easy to confuse these, so here’s the gist:
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.
An other term used is “pixel ratio”, especially when dealing with high-density displays in JavaScript and CSS. The pixel ratio specifies how a physical display pixel compares to a pixel on a “normal” density screen. A “normal” display is anything between about 100 ppi (desktop, laptops) and 175 ppi (mobile), give or take. “Retina” displays are roughly 200 ppi and up, give or take.
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!
There’s a bunch of JavaScript helper libraries around to make your site “ready for retina”, and it’s tempting to think that there’s an easy solution that only loads in retina images when required. However, as I’ve laid out it’s better to think “retina-first”, and assume you’re running on a retina screen and make exceptions or adaptions for “normal” screens, as high-density displays will soon be the norm rather than a special thing (and they are the norm on mobile devices already!).
Combined with the extra overhead of loading in a “retina” JavaScript library, parsing and replacing items in the DOM (which causes expensive layout reflows and re-rendering) and of course downloading extra versions of page assets (depending on the library up to 3 total HTTP requests have to be made for each image!) it quickly becomes clear that there’s no quick and easy “silver bullet” JavaScript solution.
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.
Anyway, here’s how it looks like:
And for future reference, here’s the code for it:
If anyone knows a way to make this work with IE, I’m happy to add it to this post (just fork the gist!).
TweetJavaScript is a modern, flexible and malleable scripting language, and it deserves to be treated as such—to this extend, I’ve extracted the style guide Mislav and I wrote for Zepto in a new project called Pragmatic.js.
There are a lot of style guides out there, but they are all a long and tedious read and, in my opinion, often read like people are scared of using JavaScript and want to make it look more like C or Java. But it’s not. It’s a super awesome scripting language with lots of wonderful features (and arguably some quirks as well!).
Writing pragmatic JavaScript is all about optimizing the process of writing JavaScript for you as a programmer, using all the facilities the language provides.
Read more (and feel free to contribute!) at the Pragmatic.js GitHub repository.
Tweet
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!
Learn more about the Retinafy ebook and grab your copy now!
P.S. As a reader of yours truly, you’ll get a $5 off coupon—hurry and use code MIRACULOUS, this code will expire on September 15!
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!).
I’m super-excited to introduce my new ebook Retinafy your web sites & apps to you. It’s out now in beta!
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.
Learn about…
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!).
Head over to Retinafy.me to grab your copy!
Tweet
The aerogel-weight mobile JavaScript framework, which also works great for Safari and Chrome extensions. The jQuery-compatible API makes it easy to pick up, and it's just 5k to 7k in size!
The JavaScript UI framework used on sites like Apple, CNN.com and NASA. Open source goodness so you can use it too!
Next-generation HTML-based visual effects for a more delicious web.
slash7 is Amy Hoy and Thomas Fuchs. We produce the interface uncommon: useful, stunning, revealing, unexpected & mesmerizing interactive software.
Why not try Freckle, which is the best time tracking software ever! :)
Questions, corrections or constructive criticism? Write me an email.
Follow me on Twitter @thomasfuchs
© Copyright 2013 Thomas Fuchs
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
