Back on December 20th, I posted an article about Working with Unix Processes, an ebook by Jesse Storimer, a developer at Shopify. Naturally, he sold it using Shopify along with the digital delivery app FetchApp and priced the book at US$27, which includes lifetime updates.

Here's a quick description of what the book was about, in Jesse's own words:

Become a Unix guru without any C programming

You’re a modern master of Ruby. Want to impress your coworkers and write the fastest, most efficient, stable code you ever have? Don’t reinvent the wheel. Reuse decades of research into battle-tested, highly optimized, and proven techniques available on any Unix system.

This book will teach you what you need to know so that you can write your own servers, debug your entire stack when things go awry, and understand how things are working under the hood.

Jesse wrote in his blog entry that at first, if he managed to sell a single book, he'd consider it a success. He then changed his mind and moved the goalposts a little farther afield and decided that if he sold $1,000 worth in the first month -- about a book a day -- he'd say that he'd succeeded. 

Imagine his surprise when he sold $1,000 worth on the first day, and almost $18,000 by the time four months had passed.

There are a number of lessons that we can take away from Jesse's example. Here are mine.

Lesson 1: Put a stake in the ground.

Creative Commons photo by Official U.S. Navy Imagery.

This isn't Jesse's first shot at writing an ebook, but it's the first one that he completed. This time, he took an idea from Tim Ferriss' 4- Hour Work Week and set up a "fake" sales page for the ebook before he'd even written a single word. Doing this yielded a number of benefits:

• It was a "sanity check" to see if there was even any kind of demand for his book idea.
• The feedback that he got was motivating.
• Creating the page and writing a description of the book probably helped crystallize his ideas of what should go into the book.
• The act of announcing the book probably made it more "real". It's easy to decide to write a book and change your mind; declaring that you're writing one publicly can give you the push to need to follow through.

Lesson 2: Make a plan, and do it where you can focus.

Jesse planned out the book in the free moments of a wilderness retreat with his family, away from his computer, or in fact, any electronics or even electricity, unless you count the electrochemical reactions of his brain.

Being away from the interruptions of the internet and the temptations to noodle with code to test an idea for the book helped him focus. By the time he got back from his trip, he had a solid idea in his head of what he wanted to write about.

Lesson 3: Consistency beats intensity.

Jesse returned to work and didn't take any time off to write. Instead, he worked on the book as a side project: a couple of hours a night, several nights a week. He didn't work on it every night, but probably more often than not. Two and a half months later, he had 130 pages of text in a handful of formats and accompanied by source code. 

The fact that we have so many sayings that capture this idea, such as:

• Slow and steady wins the race,
• It's not a sprint, it's a marathon, and
• Consistency beats intensity every time (my personal favorite)

Lesson 4: Manage the scope of your project.

Jesse's book was about a specific topic: an introduction to Unix systems programming for people who want to do it in Ruby instead of C. That kind of focus probably helped ensure that the book would get finished. The problem with writing the Grand Unifying Book on a subject is that it's too easy to come up with new things to add to the book, and that's a near-guarantee that it will remain unfinished.

The end result was a book that covers its material in 130 pages. In a world where tech books have at least 250 pages, with many stretching to 400 and beyond, 130 is rather refreshing.

Lesson 5: Overnight success takes much longer than you think.

Keep in mind that Jesse didn't write this book with a blank slate. He's a Shopify developer by day, building an ecommerce platform using Ruby that runs on Unix systems. He's also gotten a fair bit of practice teaching people programming and doing writing.

Any project like this is powered not just by the effort you put into seeing it through; it also draws on your experience. If you're going to undertake a project like Jesse's, you're more likely to succeed if it's in an area that you know and love.

Lesson 6: The right word-of-mouth can make all the difference.

Jesse spent less that $200 on advertising, $100 of which was on Google AdWords (you get a $100 AdWords voucher when you sign up for a Shopify shop). The AdWords got his sales page 300 visits, which led to 15 sales, a 5% conversion rate and about $400 in sales.

The rest of sales came from word of mouth via Twitter. He got some influencers interested in the book, and the word of mouth carried his sales. As he wrote in a comment in hacker News, "Twitter has always been the best way to spread news about the book."

Lesson 7: It's nice when you have more control over the price.

Creative Commons photo by DaMongMan.

Many of the online stores that specialize in ebooks want you to keep the price at $10 or less because that's what the market will bear for many books. Programming books are a different creature: not only does the writing have to be good, but the ideas within also have to be provably sound. At the very least, the code in the book had better work!

There's also the online bookstore's cut of the book price. They can claim up to a third. Your $10 book makes you $6.66 (the profit of the beast!).

Here's where Shopify shines: with the cheapest plan, we ask for $29 a month and a 2% cut of your sales. Not 22%, and certainly not 30% or more. You won't be hit with bandwidth charges, even if Reddit and Hacker News point to your store and you get flooded with views (after all, that's supposed to be a good thing, right?). And you'll be able to set your price as high or low as you please.

Jesse's book sells for $27, and it's worth it. You're paying for his effort, his experience and his teaching style. 

Let's imagine that you decide to make a book, and like Jesse, you price it at $27. Let's then go with some (very) rough arithmetic and say that his $27 price point lets him make $25 per book, once you've factored in the costs of Shopify and FetchApp (the app that enables Shopify shops to deliver digital goods). That's about 4 times what you would've made had you sold your book some other way.

The Challenge

I have a couple of tech book ideas. I've also got my own established tech blog with a couple thousand readers a day and a reasonably-sized horde of Twitter followers. I think I might see if I can do what he did. At best, I get a hefty chunk of change. At worst, I've gained some valuable experience and will probably have sharpened my tech skills.

Do you have a book idea? (It can be any kind of book, not just a tech book.) Maybe you should see if you can do as well -- or better -- than Jesse. Sign up for a Shopify plan (the first month's free and the basic plan's $29 a month), get FetchApp for handling the digital delivery and set up a shop. Put up a "coming soon" test page and see if there's a demand for your book. Write it, set your price and sell it. Tell me about it and I'll write it up here.

Hmmm...maybe I should make this a contest! Let me see what we can do about that.

Recommended Reading

• Jesse's blog entry on his sales
• The Hacker News commentary on Jesse's blog entry
• Jesse's shop for his book, Working with Unix Processes

Continue reading article ›

RailsConf is coming up next week and a few Shopify Devs are heading down to Austin, TX to join in the fun. We're going up a little early so if you want to hang out give me a shout on Twitter @johnduff and we'll set something up.

We're planning on checking out The Gingerman Pub Saturday night (April 21st) so if you want to talk Shopify, Rails or whatever, stop in and we'll buy you a drink. We'll be wearing the Shopify T-Shirts :).

See you there!

Continue reading article ›

We're going to start looking for the next set of apps to be funded by the Shopify Fund soon, and a number of people have asked about the sort of apps we're looking for. We're looking for apps for which the answer is "yes" to at least a few of the questions listed below. If you're thinking about writing a Shopify app, keep these in mind:

Does the app help shopowners make more money? If your app does this, shopowners will definitely be interested; in fact, this is probably the number one question in their minds when they're considering your app. An app can help shopowners make money in a number of ways. Possibilities include:

• Does it bring in more customers? One way to do this is to extend the shop's reach beyond its own web page. There are a number of apps that integrate Shopify with a shopowner's Facebook page, and there are also apps that let users easily add "widgets" to other web pages (personal sites, blogs, and so on) so that customers can start the purchase process on those pages.
• Does it help increase the number of sales? One example is the category of "abandoned cart" apps, which give shopowners the ability to find customers who've filled their carts and went through most of the checkout process, but didn't make that last step of providing a credit card number and making the purchase. They can then contact these customers and try to convince them to take that last step.
• Does it help increase the money customers spend per sale? Customers spend more money when they can easily find what they want, and especially when they can find related items in a shop. You could write an app that shows customers specific products based on the search keyword that brought them to the shop or on their browsing history.

Does the app make shopowners' lives easier? Anything that lets shopowners do less work (especially tedious error-prone work) or make better decisions is welcome. Consider these questions:

• Does it give shopowners better insight into what's happening with their shops? Shopowners love getting information about their shops: reports, the ability to sift through information in different ways, being able to tell whether a promotional campaign is working, knowing what their conversion and abandonment rates are, and so on.
• Does it help with tedious, repetitive and error-prone tasks? Every line of work comes with some kind of boring task that needs to be done over and over again, and it's these tasks where people are likely to make some kind of simple, but potentially troublesome, mistake. This is especially true for shops, which have big collections of data to be entered or edited. Apps that help automate these tasks or at least help shopowners catch errors made while performing these tasks are helpful.
• Does it "mind the store" when the shopowner is busy or away? We're not talking about artificial intelligence here; instead, we're talking about apps that watch the shop and make adjustments based on simple rules or notify the shopowner when certain events happen (e.g.: when certain products become out of stock or a customer makes an unusually large order).
• What about shopowners who also have brick-and-mortar stores? We're interested in helping people with brick-and-mortar stores expand into the world of ecommerce. Any app that helps integrate their existing systems with Shopify, whether it's point-of-sale machines, inventory software, accounting software or any other application they use for their brick-and-mortar store is useful.

Does it enhance the customers' shopping experience? Customers make purchases and return visits to shops that give them a good shopping experience, so any app that helps in this area is a good one. If you're trying to come up with an app in this area, answer these questions:

• Does it improve communications between the customer and the shopowner? Examples of this sort of app include one that gives customers the ability to talk to a sales representative when they have questions about a product or a post-purchase survey. 
• Does it provide personal touches that will bring the customer back? Examples of this sort of app include one that sends a "thank you" note to a customer after a sale, or one that sends out the occasional marketing email tailored to the customer's preferences and purchase history.
• Does it simplify the shopping experience or make it more pleasant? Examples of this sort of app include letting people set up "wish lists" for items they'd love to receive as gifts, ones that let customers participate in "points" programs or an app that lets customers personalize items they buy, either with custom text or images.

Continue reading article ›

The Shopify Fund -- Shopify's million-dollar fund for encouraging developers to build apps on the Shopify platform -- is in full swing, with the first set of developers to receive funding hard at work on their applications (and in one case, a book). Here's a quick recap of their projects:

We're going to start looking for the next set of apps to be funded soon, and I thought I'd let you know about the kinds of apps we're looking for:

• Apps that integrate Facebook and Shopify: With 845 million monthly active users (425 million of whom are mobile), 1 in 2 North Americans being a Facebook user and Facebook accounting for 1 of every 5 web pages viewed, Facebook is a great place for shopowners to promote themselves and their shops, products and specials. We'd like to see more apps that bring together Facebook and Shopify, and especially those that make it easy for shopowners to set up a storefront on their Facebook pages. Mark Hayes recently wrote about these kinds of apps; check out his article titled How to Sell on Facebook to see examples of the sorts of apps we're looking for.
• Customer image and text uploads: Many shops sell items that can be customized either with custom text (such as the customer's name on a sports uniform or a monogrammed towel) or photo (such as the customer's photo on a mug or t-shirt). Some shopowners have come up with manual workarounds such as following up via email with their customers to get the custom text or image. We'd love to see an app that automates the process.
• Follow-up email: Here's a simple one, but it's an opportunity to get imaginative. There's a lot of call for an app that emails customers after they've place their orders, thanking them for shopping at the shop and providing extra information such as "If you have any questions or concerns about your order, here's an email address you can write to". Follow-up emails help keep shopowners in touch with the customers and can also be a great way to point customers to new products and events such as upcoming sales.
• Rentals App: Shopify is great "out of the box" for selling products that you can ship to customers who will then own them, whether they're physical or digital. However, there are people in the business of loaning out rather than selling things. We'd like to see an app that lets people book things for rental, whether they're cars, computers or cooking equipment. Rental products can be mapped to products, but an app would have to take care of who's renting which item and when, and prevent things such as two customers renting the same thing at the same time.
• Resource-Booking App: In a case similar to the one with the Rentals App (see above), there are people in the business of selling things that aren't shipped butbooked, such as: memberships (for gyms, clubs and all sorts of organizations), booking training and courses and services (such as catering, dog walking, housekeeping and so on). Resources such as these can be mapped onto products, but we'd like to see an app that helps take care of the extra stuff involved in booking resources, whether it's availability (such as the maximum size for a class, or the availability of a dog walker at a certain day and time).

If you've got an idea for an app and would like Shopify to fund its development, drop us a line at the Shopify Fund email address: fund@shopify.com. We're already looking around for apps to fund, so sooner is better!

Continue reading article ›

Artwork based on a Creative Commons photo by John R. Southern. Click here to see the original.

HackTO is a hackathon taking place in Toronto this Saturday, April 14th, in which developers will be challenged to come up with and implement an application that takes one or more of the sponsors' APIs and does something interesting, useful or cool -- all in the space of a few hours. The APIs that you'll be able to use at HackTO include:

Shopify will be there! Developer Relations guy David Underwood and Yours Truly, Platform Evangelist Joey deVilla, will be there to walk you through the Shopify API should you make the really excellent decision to include it in your project.

Here's the schedule for Saturday:

There are prizes! HackTO will offer three prizes to the apps deemed by our panel of judges to be the best:

• First prize: $2,000
• Second prize: $1,500
• Third prize: $500

Continue reading article ›

We (Dan, Ryan, and myself) launched a small page called "I have a business idea". Check it out, if you haven't already — especially in Chrome or Firefox or Safari. Assuming you have JavaScript turned on (as most of you do), you should see some fun animations as you scroll down the page.

I have to admit that the animations that I had in my head were of a much grander scale but there was a time crunch: the site from design to implementation needed to be pulled off in two days. So how did we do it?

The design idea was to have our man-of-the-hour, Skip, put on the various hats that he'll need to wear to get a new business off the ground. Where do you even begin when you have an idea? We broke it down into a few steps with some helpful links along the way.

The steps were thought of as slides, like a Powerpoint presentation, but clearly better. As the user scrolls from slide to slide, Skip transitions from role to role.

Deciding what slide we're on

The first thing to figure out was what slide the viewer was looking at. This was the easiest part. All slides are the same height and are the same distance apart. We look for the window scroll event and then divide that by the height of a slide (plus its margin).

var slideSize = 700;
var scrollTop = $(document).scrollTop() + 100;
var newSlide = Math.round(scrollTop / slideSize);

The 100 that is being added is the margin at the very top of the page. Now that we know what the current slide is in view, we can change the state of the page and change the state of that slide.

First up is the subtle (or maybe not so subtle) background colour change to match the current slide.

document.body.style.backgroundColor = slides.eq(currentSlide)
    .children('.slide-content')
    .css('background-color');

We used jQuery to handle the heavy lifting. The slides variable is an array of all our slides. We grab the current slide and then grab the background colour from the slide content. That gets applied to the body. Just like that, the carpet now matches the drapes.

Handling the slide transitions

The next step in setting slide state was handling transitions. A slide comes in from the top or from the bottom. The animations should be different to reflect the different movement. Each slide has three states: the current (or default state), the before state, and the after state.

As we transition the slides, we set the state on those by changing an attribute:

if (oldSlide > currentSlide) {
    oldSlideContent.attr('data-state', 'is-after');
} else {
    oldSlideContent.attr('data-state', 'is-before');
}

currentSlideContent.attr('data-state', 'is-current');

If the old slide is below (or after) the current slide then it's set to "is-after". If it's above then it's set to "is-before". The current slide is aptly set to "is-current".

Slide CSS

Each slide is then made up of a number of components. If you look at the CSS, it's a little messy but you can see the different components of each slide.

#s4-1 { ... }
#s4-2 { ... }
#s4-3 { ... }

Each of those defines the current (or default) state of each slide. For browsers that don't have JavaScript turned on or don't support CSS transitions and animations, it'll just be the normal static slides. For everybody else, we set the before and after states.

.slide-content[data-state=is-after] #s4-3 { top: 400px; }
.slide-content[data-state=is-before] #s4-3 { top: -200px; }

CSS Transitions do the heavy lifting for us. As we set the state, the browser sees that the top value has changed and transitions that property smoothly over a brief period of time.

Since I knew I was going to be animating a lot of stuff on the page, I just transitioned ALL the things!

* {
    -webkit-transition: all 1s;
    -moz-transition: all 1s;
    -ms-transition: all 1s;
    -o-transition: all 1s;
    transition: all 1s;
}

Animations

We added a few small animations along the way, like the flying money on the last slide. Something fun along the way. First, we defined the keyframes of our animation.

@-moz-keyframes float {
    0% { -moz-transform: rotate(0deg) translate(0,0); }
    30% { -moz-transform: rotate(-20deg) translate(10px,10px); }
    70% { -moz-transform: rotate(20deg) translate(-10px,10px); }
    100% { -moz-transform: rotate(0deg) translate(0,0); }
}

In this case, the floating money moves the element at different points in the timeline. It rotates and shifts (or translates) the element from its current position.

With the animation keyframes defined, the animation needs to be applied to an element.

#s9-3 {
    -moz-animation: float 8s infinite linear;
}

The animation is done over 8 seconds to create a nice soft effect and loops infinitely. To have each dollar bill float at a different frequency, we just changed the animation length.

#s9-4 {
    -moz-animation: float 10s infinite linear;
}

Browser Compatibility

We used a bunch of cutting edge CSS to do this and as a result, we added all the vendor prefixes for the major browsers out there. For browsers that don't support it, it should still show the default state of the slides.

Tools

In a way, building this felt like doing animations in Adobe Flash. Elements were laid out on a canvas and then keyframes were defined for each of the elements that we wanted to animate. There are a number of tools, like Adobe Edge, that allow you to create these types of animations in a graphical way without necessarily needing to get your hands dirty with code.

Continue reading article ›

App devs everywhere, rejoice! Shopify is pleased to announce that we’re replacing our current API authentication system with one based on OAuth 2.0.

Anyone who knows anything about webapps will tell you that OAuth 2.0 is quickly becoming the de-facto standard for authenticating users against an API. Facebook, Foursquare, Google, Github, and other big names are already using it. We’ve been working on our own implementation here at Shopify for a while now, so we’re really pleased to finally make it public.

Why Use Oauth2?

Our previous authentication scheme was pretty good, but it lacked in some key areas. Primarily, it was completely custom and so the first thing a new dev would often have to do was implement our auth mechanism in their favourite environment. By implementing OAuth 2.0, developers can tie into existing auth solutions that implement the spec for them. We hope this makes getting stuck into the Shopify API much easier.

Secondly, we’re adding the ability to request granular access scope for your application. If you’ve ever used a Facebook or Twitter app, you’ve already seen this in action. We’ve divided up the API into a number of categories and apps can request read or write access to these individually. Now merchants won’t have to trust a product-related app with all their customer info for example. The available scopes are as follows:

• Content: Blog posts, pages, comments, etc.
• Themes: Themes and theme assets.
• Products: Everything product-related. Images, variants, etc.
• Customers: Customers and customer groups.
• Orders: Orders, transactions, and fulfillments
• Script Tags
• Shipping: Coming Soon!

Related to this, you can also change the scopes you ask for as your app functionality evolves. You’ll need merchants to approve the changes of course, but it’s a lot more flexible. A full scope reference is available in our documentation.

What This Change Means

If you’re the owner of an app that uses the old auth system (i.e. everyone at the moment), don’t worry! The old system isn’t going to be going away any time soon. We're phasing it out eventually, but there will be lots and lots of notice before we do that.

One thing that is going to change is that new apps are going to be required to use Oauth 2.0 starting soon. We’re  leaving both options up for a short while so that the authors of our various community API clients have time to update their libraries but after that it’s Oauth all the way down.

Resources

We’ve updated our technical docs with new instructions on how to get up and running with the new auth scheme. Read this page throughly before you get started.

There’s already an updated version of the shopify_api gem available that works with Oauth 2.0. We’re working on converting the shopify_app gem as well as bringing our other official adapters up to date. There’s also an omniauth solution available here.

Feedback

We’d love to hear what you think of the new changes. You can leave a comment on this blog post or head over to our developer mailing list and discuss it there.

Continue reading article ›