Jonathan Snook's Blog, page 22

Book Review: Content Everywhere

After seeing the book mentioned in a Karen McGrane keynote, I decided to pick up Content Everywhere: Strategy and Structure for the Future-Ready Content by Sara Wachter-Boettcher. It's a somewhat lengthy but easy read with great examples and helped me gain a better perspective on the work that I do.

What is the book about?

As you can probably surmise from the title, Content Everywhere looks at content strategy and content creation for a better experience in various contexts. With content appearing in snippets on a summary page, or being arranged in a responsive design, or being fed out via an API, your content needs to be broken down (or chunked) in a way that makes the content more versatile than just entering all your content into a big rich text editor.

Who is this book for?

Content Everywhere is a good read for someone just getting into larger content management systems, both from a development side and especially from the content creation side. The book is really targetted to the latter but developers would gain some insight on how they build out interfaces for content creators.

I read this book and tried to map the concepts to the work I'm doing at Shopify. While we are an e-commerce platform, we are also a content management system. How do we facilitate the chunking of content to allow for easy reuse. The book gave me ideas and helped me reframe the work we're doing.

As a seasoned CMS developer, especially at the enterprise level, the book didn't offer up much new insight. However, I liked the way that it frames content management problems in contexts beyond just the standard desktop environment most of us create in. Content Everywhere is true to its title when it talks of content in responsive (or adaptive) web design and APIs and provides great examples as demonstration.

A Career in Transition

For nearly 15 years, I’ve called myself a web developer. The twelve years of this blog’s existence is a testament to that. I’ve written hundreds of blog posts that document my trials and tribulations with web development.

In those 15 years I’ve had job titles like Technical Architect, Project Manager, Lead Designer, and even Director of Technology. Underneath it all, though, I just built web sites. Ask me what I did and I’d tell you that I was a web developer, fancy job title be damned.

Over a month ago, I took a new title: Product Manager.

When I accepted the new position, I still thought I’d spend time coding and designing and… well, being a web developer.

What has transpired, however, was something quite unexpected.

From customers, to support, to our team, to other teams, managing a product requires a great deal of coordination. I’m contributing on the forums, I’m assisting with blog post announcements, I’m writing emails keeping everybody abreast of how things are going, and I’m talking to everybody to get their feedback into what we’re building.

It also requires plenty of research. We have a data team that I can request this report or that. We do A/B testing. We do user experience research. Plenty of reports to scour over. It’s quite fun to dissect problems based on numbers.

But I’m not coding anymore. And I’m feeling a little uneasy about it.

Now, my life certainly isn’t devoid of development. I still hop into code reviews. I frequently use the SQL console to whip together queries that join a half-dozen tables to piece together what I need. I’ve been able to commit a few small pull requests. And I like to push myself with a personal project from time to time.

But my day-to-day life is not coding.

Why does this make me uneasy? Because I’ve always shared my experience as a web developer and I suddenly find myself wondering how long I can continue to do that. I am, after all, speaking at a number of conferences this year on web development.

I am, however, enjoying my role as a product manager. I’m excited to see what will come of it.

It’s a career in transition.

Selling my e-book on Amazon

After reading Thomas Fuchs’ post, 5 rules to sell thousands of copies of your ebook, and the ensuing Twitter discussion, I decided to share my thoughts on selling my book, SMACSS, on Amazon.

Had you asked me before I wrote this post whether I would sell on Amazon again, I’d have flat out said no. Having researched and compiled numbers for this post, now I’m not so sure. Let’s dive in to see why.

Selling on Amazon

Selling on Amazon is relatively easy. Create a mobi file and upload it. Add a cover photo and a description, set a price, and you’re pretty much set to go.

It’s that setting of the price that initial ruffled my feathers. See, Amazon is trying to drive down e-book prices by creating an incentive to price the book under $10. Normally, you only get 35% of every book sale but if it’s under $10 then you can get 70% of every sale. Sort of.

First, if it’s under $10 then you also have to pay a delivery fee. The larger your book is, the larger your fee is. The other catch is that you only get 70% if the book is sold to someone within certain countries. For books sold to people outside of that list, you still only get 35%.

From the launch of the book in November 2011 up to and including September 2012, I’ve sold 338 books. For those 11 months, 30% of those were sold at the 35% royalty rate. The average royalty per book has been 61.8%.

In my case, pricing the book at $9 on Amazon made sense. I sell the book for $15 on my own site but that includes PDF, ePub, and mobi formats and includes screencasts. On Amazon, you just get the mobi version. I felt this was fair.

However, let’s assume that I just had the e-book with no other frills. At $9 getting 61.8% from every sale means $5.56 in royalties. I’d have to sell the book for $16 to make just as much at the reduced price point.

Clearly, it’s better for consumers if I sell for the cheaper price, since I make the same either way.

Versus self-sold

One commenter on Twitter figured Amazon would be worth it based on sheer volume of sales. However, that’s not the case. Through self-marketing alone, sales through my own site have far exceeding anything that I’ve sold on Amazon. I’ve sold almost 6 books on my own site for every book sold on Amazon. Every book sold on my own site makes about 96% of the sale price (and sells for a higher price!).

Based on this alone, it really doesn’t make sense to push people to Amazon.

Pushing to Amazon

When I first launched the book, I actively encouraged people to buy the book from Amazon. When you went to the purchase page, one of the pricing options was to buy it from Amazon and explained the benefits of doing so. (Namely, price.)

When I released the print version of the book back in May, I changed the way my site presented pricing and dropped any mention of Amazon from my site. Sales dropped off considerably. Looking at June sales on Amazon.com, they were at the lowest they had ever been.

Clearly, this demonstrated that pushing people to Amazon was just not worth it.

No more Amazon?

It was at this point that I said to myself (and others) that I would never bother selling through Amazon again. Why bother?

But then I started compiling numbers for this very blog post and I started to see some trends that caught my attention.

1. Sales on Amazon are climbing

While overall sales are still down, the trend has been climbing since June. Why is this? It’s hard to say for sure but I’m going to chalk it up to one reason: Reviews. I used to only have one review. It was only 3 stars. Not a glowing review by any means. But in September, I got two more reviews that were definitely more positive. I believe these positive reviews have helped increase sales.

2. Sales have closely mirrored my own site

Sure, sales dropped considerably in June on Amazon but having finally compiled numbers from my own site, I realized that sales dropped there, too. Maybe my site wasn’t contributing as heavily to Amazon sales as I originally thought.

In fact, month over month, sales have increased more on Amazon than they have on my own site over the last three months.

In Review

My takeaway from all of this is that Amazon may still be a worthwhile addition to sales that may not be taking sales away from my own site (as I originally suspected). However, doing well (or better) on Amazon means having positive reviews to help push sales. This makes sense. (Maybe you’d like to review it!)

In the end, I’ve made $1882 from Amazon.com since the launch of the book. I’m not about to say no to that! And I’ll continue to sell the book on Amazon for the foreseeable future. More importantly, I’m more likely to recommend Amazon as a viable option for e-book sales as a supplement to regular sales.

Previous Parent

Plenty of people in the CSS world want a parent selector. It’s complicated and I understand it if browsers didn’t implement it.

However, something that could work and could be useful is what I call the Previous Parent selector.

Since CSS is essentially read from right-to-left, and from current element to top element, it should be possible to find a child element of a parent element that has already rendered its children.

Imagine the following HTML structure:

<div class="A">
<label>
<input>
</div>
<div class="B">
<div>
<label>
<input>
</div>
</div>
<div class="option">
<label>
<input>
</div>

Ignore the lack of closing tags, as the pedant in you may be so inclined to mention. This is just to get a sense of the document structure.

How can we effect change on the DIV with the class of option if they’re children of a sibling element? The Previous Parent selector would allow drilling down into previously rendered parents.

.option { display:block; }
/* clicking on A > input would hide the option */
input:checked <+ div ~ .option { display:none; }
/* clicking on B > div > input would hide the option */
input:checked <~ div ~ .option { display:none; }

You’ll notice the use of <+ to indicate that the input:checked should be the immediate child of the DIV. The use of <~ indicates that the input:checked should be a descendant (at any level) of the DIV.

The fact that the elements need to appear before the current element does limit the effectiveness of this but would allow for more complicated interactions to be expressed in CSS that aren’t currently possible.

Get Jacked

Jack the Lumberjack was getting a little tired of hanging out on book covers and has decided to expand out into the world of fashion. I don't blame him. He has a face made to adorn the chest of many a geek, male and female. In fact, he has inspired me to grow my own beard all bushy and bold.

Where might you find Jack? Why, on a United Pixelworker Tee, of course. Get yours before Monday!