Jeff is arguing that not everybody needs to learn to code, and in fact the world doesn’t need more mediocre coders. So he’s not that enthusiastic about recent initiatives like CodeYear that aim to democratize coding.

And since Jeff is using my design to make his point, I think that entitles me to a counter-point.

I think everybody should learn to code, for one simple reason: knowing how to code is hugely empowering.

I can’t think of many other skills that enable you to create something from scratch and reach as many people as knowing how to set up a simple website.

Just last week, I was able to come up with an idea and then launch a site in 2 days. That site was then seen by about 10,000 people in a couple hours.

Think about it: something I did reached 10,000 actual living people and had an impact (however small) on their life. That would never have been possible if I didn’t know how to code.

What’s Coding?

Now you can argue that you don’t need to know how to code to build a website. You probably don’t think of setting up a WordPress theme as “coding”.

But from where non-techies stand, setting up a WordPress theme and coming up with Ruby on Rails from scratch have about the same degree of complexity.

“Learning to code” doesn’t always mean becoming the next Linus Torvalds, just like “learning to cook” doesn’t mean opening a 3-stars restaurant.

It simply means having a basic grasp of how computers work instead of blindly following whatever a talking paperclip tells you (and maybe eventually being able to program your own talking paperclips).

The first step is letting people know that learning to code is not that hard, and that if they put their mind to it they have a high chance of succeeding. I believe this is what sites like CodeYear are trying to do, and I think that’s a very valid goal indeed.

Also a lot of good points (as always) in the Hacker News thread. And here’s another good response, Please Don’t Learn to Code but Give it a Try

It’s a directory of all the useful single-page sites, apps, and bookmarklets that we often come across but can never recall when we need them.

So now, no need to obsessively bookmark everything “just in case”. Next time you need a tool to generate a color palette from an image, build a grid, or share a mockup, just open your Toolbox.

In case you’re wondering what kind of site I’ll be adding, I will include a site as long as:

• It can be used for free
• It doesn’t require you to sign-up
• It’s somewhat related to web design and developement
• Can be useful for a majority of people

If you know sites like this that I haven’t included yet, feel free to suggest them either in the comments here or via the site submission form.

All the features we use daily for web design probably came to life as side benefits in Adobe’s quest to make Photoshop the perfect photo editing application.

In fact, it’s only with Photoshop CS6 that Adobe has started giving signs that they actually care about people who design for the web and mobile, with new features like pixel snapping and effects on layer groups.

But that might very well turn out to have been too little, to late, because new apps are coming out every day to address the huge, unhappy market of web designers. The latest entrant in the race is Sketch 2, by Bohemian Coding. But can it hold its promises and actually replace (or at least, complement) the Adobe suite? Read on to find out.

User Interface

I really liked Sketch’s UI. It’s much simpler than either Photoshop or Illustrator, yet gives you easy access to most of the same features. I especially liked the small tips that appear near the top of the screen, and really helps jumpstart your first few sessions with the app.

Help is always there thanks to the onscreen tips

The sidebar is also pretty nice. Everything is right there where you need it, none of this hide/show/dock/undock nonsense that plagues Adobe applications.

The Sketch Sidebar

Selecting and Moving

Selecting and moving things is probably the most common action you can do in any graphics editing app, so it’s important to get this right.

Sadly, I thought Sketch really fell short here. Let’s compare Sketch and Illustrator to see why:

Sketch on the left, Illustrator on the right

Unlike Illustrator’s bright blue outline that spans the whole perimeter of the group, you can barely see when a group is selected in Sketch (see the handles at the top?).

And unlike Photoshop (where you can drag a layer by clicking anywhere in the screen while holding Command/Control), I haven’t found a way to move a group or layer with the mouse without having to click inside it, which can be hard to do for layers that are only 1 pixel wide. Actually, command-clicking works the same way in Sketch, so scratch this. My bad!

What’s more, if you have two adjacent shapes, you will often select the wrong one by mistake (it seems a shape’s click target extends past its own border).

Selecting adjacent objects can be tricky

(To be fair, Photoshop CS6 seems to have the same problem when selecting small adjacent shapes. Which surprised me, because I’ve never experienced it in previous Photoshop versions)

There is also a lot of problems with selecting things when digging deep inside groups or combined objects, as a single click anywhere outside the group’s shapes will exit the group, thus making it impossible to select individual components. By contrast, Illustrator requires you to double-click to exit a group, meaning that you’re less likely to exit it by mistake.

Sketch makes it impossible to click+drag to select sub-objects

This accumulation of annoying quirks can make Sketch 2 very frustrating to use at times, especially when dealing with many small shapes.

Vector Tools

If there’s one area where Sketch aims to have Photoshop beat, it’s vector tools. And right away you can see that Sketch developers have implemented a feature that’s cruelly missing from Photoshop: changing a rounded rectangle’s radius after you’ve drawn it.

Changing a roundrect's corner radius: a revolutionary concept

Sketch also has some nifty Beziers curves tools. It looks like it’ll take some time getting to know them, but I can already tell that the rounded corner Bezier tool will be tremendously helpful.

Instant rounded corners anywhere!

Pathfinding Tools

The main reason why some designers don’t like using Illustrator as their tool of choice is that Illustrator is at heart a vector-editing application, and doesn’t play that well with pixels.

Of course, Photoshop provides a lot more control on individual pixels, but on the other hand its vector tools are much more limited. So a vector app that’s also good at pixel rendering would be the holy grail of web design.

Sadly, Sketch 2 still suffers from some bugs that prevent it from taking that crown. When using the “union” tool to combine two shapes, some of the shapes actually shifted for no reason as you can see here:

Original on the left, "union" version on the right

In another case, the Union tool actually ate half of my shape, leaving me with a mangled mess of pixels that looked nothing like what I had started out with.

I have no doubt these bugs will eventually be fixed though, so we might just need to be patient on this one. Still, it seems strange that such obvious bugs would be shipped in a non-beta version.

Conclusion

It’s clear that I’m not ready to switch away from Photoshop and Illustrator. They might have confusing interfaces, hog all my computer’s resources, crash regularly, and be bloated with useless features, but at least I can select things on the first try.

This unfamiliarity with Sketch, combined with the quirks and bugs I encountered, makes it hard for me to advocate switching to it right now. It definitely shows a lot of promise, but I can’t really see myself being productive with it until those problems are fixed.

That being said, I am planning to give Sketch its chance, and keep trying it out for small things like icons or buttons. I’m sincere when I say that I’m looking forward to a real, design-focused alternative to Photoshop. So the least I can do is to give Sketch 2 its chance!

We spent most of the time in Seoul, with a brief detour to Busan that was probably the highlight of the trip. I encourage you to visit both if you ever get the chance, you won’t regret it.

As you’ll see from the photos, we spent a lot of time eating. The highlight for me was definitely getting served still-moving eel in Haeundae:

But don’t worry, thankfully they stop moving once we cooked them!

Also, since I just got a new iPhone 4S, this was the first trip where I relied entirely on my phone’s camera and didn’t bring a “real” camera at all. I’d say the lower weight, ease of sharing, and cheesy cool Instagram effects more than make up for the lower quality.

Anyway, here are the photos:

Jagalchi Fish Market in Busan

Haeundae beach, Korea's answer to Copacabana

Resting my tired feet in a hot spring

Preparations for Buddha's birthday party

Traditional Korean pattern

Korean food is always pretty colorful

Mountains of food at Namdaemun market

Korean Barbecue, Korea's most famous dish

Chess players in Seoul

Scissors, an unexpected addition to chopsticks

Old & new, Seoul's two faces

If you’d like to see more photos, you can find some here and here.

But still, ever since I’ve wanted to go visit the country, and I’ll finally get a chance very soon!

Next week is a series of Japanese holidays that are collectively known as the golden week, and Kyoto (where I live) being the number one tourist destination in Japan, it’s usually over-run by Japanese tourists at that time.

So me and Emi will spend 6 days in Seoul (from Saturday, April 28th to Friday, May 4th) to escape Japan and eat some kimchi and bibimbap.

And if you happen to live there and are into design or startups (or even if you’re not, actually), I’d love to meet up for coffee and say hello!

Since then, I’ve sold the eBook over 2000 times and almost reached $10,000 in profits.

A lot of people have asked me for more details about how I wrote, launched, and promoted the book, so here is a post-mortem to see what went right, what went wrong, and what you can learn from my own experience.

Numbers

A big spike for the first two days

First, some hard stats. These are my numbers since the launch one month ago:

• eBooks sold: 2057 (1023 x Regular Edition, 1034 x Deluxe Edition)
• Total Revenue: $9908
• Profit (minus Paypal fees): $8991

80% of this happened in the first two days thanks to the great launch on Hacker News (where it got upvoted over 300 times), which got me a traffic peak of 22,890 visitors in a single day! In fact, here are the same numbers for the first 48 hours only:

• eBooks sold: 1469 (714 x Regular Edition, 758 x Deluxe Edition)
• Total Revenue: $6663
• Profit (minus Paypal fees): $6022

Those numbers are impressive, but they’re meaningless without knowing how much time I spent working on the eBook itself. Here’s the breakdown:

• Designing the app: 9 hours
• Writing and formatting the eBook: 11 hours
• Designing the landing page: 5 hours
• Coding the landing page: 5 hours
• Promoting the eBook: 10 hours
• Total work time: 40 hours

So it took me about 40 hours from start to finish to build the full product. That’s a $224/hour rate, which happens to be much more than what I charge for regular design work. In fact, in only two days I made back the money I would’ve earned from client work!

The Idea

CodeYear, the initial spark for the eBook

Back in the last days of 2011, I was contacted by Zach Sims of Codecademy. He was looking for some design help for a new project, CodeYear.

Forbes recently covered how they launched CodeYear and got 200,000 sign-ups in a couple days, but long before that I had already blogged about how I designed CodeYear.com in only one hour.

This behind-the-scenes look at my design process became hugely popular, getting retweeted more than 950 times, and even being linked by TechCrunch and Fred Wilson!

This convinced me there was a big demand for material covering design in a simple and straightforward way, focusing on basic principles and not Photoshop techniques.

So when my friend Sean Grove from Bushido showed me the chat app he was working on, and asked me to help with the design, I realized his was the ideal situation to document my design process.

So I opened up Photoshop, started working, and simply took screenshots and notes every step of the way in preparation for the next step.

Writing the eBook

I decided to write an eBook because I find them more convenient than screencasts or videos. You can read them in the train or at work, but unlike a blog post or plain text article you almost feel like you bought something tangible, and not just words.

I knew I wanted to keep the eBook short, because I can’t count the times I’ve excitedly bought a 100-page eBook only to put off reading it for so long that I end up forgetting I even have it.

I also wanted to test the water with a small-scale project first: I didn’t want to spend months on a project without even knowing if anybody was interested. So a short eBook fit that bill perfectly.

I first wrote the book’s basic draft in Google Docs, then moved to Pages for the formatting.

Interestingly, the act of writing about the design actually led me to discover some of its flaws, so this step also included a lot of back and forth between Photoshop and Pages

Selling the eBook

I spent so much time researching various digital delivery services to sell the eBook that I ended up writing an article about this topic for Smashing Magazine.

To summarize, I initially used Quixly to sell the eBook, but after encountering a couple bugs and no reply from support, switched to a combo of Pulley and Gumroad (for people who don’t have Paypal).

No matter which solution you use I suggest supplementing it with Gumroad, since there’s no subscription (they only charge a commission) and it’s one of the few such services to accept credit cards directly.

Pricing

I’ve published a detailed account of how I settled on a price for the eBook (and how that price influenced sales) over at the Smart Bear blog, so I suggest you read it if you’re interested on pricing and how our brain processed different price points.

Also check out the counter-point by Jarrod Drysdale and my subsequent challenge to him and Amy Hoy.

The Launch

Presenting the eBook material at Paris Hackers, via @Zaiste

As you can see from my stats, the eBook’s successful launch was the key to its success. While whether this is good or not is debatable, for now let’s focus on what I did to make the launch go well.

First of all I didn’t publish the eBook straight away. I got feedback from smart people like Hiten Shah, Steve Huffman, and David Bizer, and also presented the eBook’s material live at a Paris Hackers meetup.

After presenting, I told people they could get the eBook for free if they signed up to my mailing list, in order to build a small audience to help me kickstart the launch.

I also spent quite some time on the eBook site itself, trying out multiple designs until I found the right style.

When everything was ready, I finally posted the link to Hacker News. I then emailed the 40 people who had signed up to the mailing list with a link to download the eBook for free, asking them to upvote my link on Hacker News if they had enjoyed the book.

The intention here was not to spam Hacker News, so I specifically only asked people who had read and enjoyed the book to upvote the link if they felt it deserved it.

Press

I didn’t get much press coverage, but I didn’t really expect any since an eBook launch is not a big event in itself. Or another explanation would be that I just suck at PR… Still, I’m very grateful to The Industry, SpeckyBoy, and The Rude Baguette for featuring the book!

• The “Greif” has launched his eBook, Step by Step UI Design — The Industry
• Sacha Greif’s eBook “Step-by-Step UI Design” goes viral — The Rude Baguette
• We Have 5 Copies of Step by Step UI Design (Ebook) to Giveaway — SpeckyBoy

I contacted a couple other design blogs to organize giveaways, but it turns out big design blogs actually charge you to give your stuff away for free to their readers. More power to them if they can do that, I guess!

Lessons Learned

The big lesson I learned is that there’s a market for short, practical eBooks about user interface design. And unless this was a fluke, I’m pretty good at capturing that market.

I love my “normal” job as a contract UI designer, but if I can make twice as much money writing an eBook, and on top of this create a new permanent stream of passive income, then I’d be a fool not to consider doing it more.

Now some things that could’ve been improved on:

• I didn’t ask people to subscribe to a mailing list.
  This was partly a deliberate choice, because I personally hate giving out my email. Still, I’ll probably add this next time.
• I didn’t A/B test anything
  I know I left money off the table because of this, but you got to pick your battles and I simply didn’t have enough time and energy to focus on this on top of everyting else.
• I relied on a single traffic source
  Even though the eBook was written with the Hacker News audience in mind and did very well there, I wish I could’ve gotten other traffic sources, like TechCrunch or maybe a famous startup blogger. As it is, if for some reason my post hadn’t done well on HN, I’d be about $6k poorer…
• I initially relied too much on Paypal
  Although I eventually added Gumroad as a payment option, I initially only had Paypal. A lot of people contacted me to tell me they couldn’t use Paypal, so that means even more people didn’t even bother asking and just left.
• My Unicorn Insult joke bombed
  I thought this could be the start of a great new meme, but it didn’t take… Oh well, better luck next time!

That being said, although I made some mistakes I definitely think this whole thing was a huge success. I never expected to make so much money (almost $10k!) from a single self-published 40-page book.

So if you’re a designer or developer, or possess some other unique skill, I definitely encourage you to come up with your own eBook, screencasts, or tutorials.

It might seem like the web is saturated with them already, but most of the stuff out there is of pretty low quality so there’s always room for well-researched, well-explained material.

His book coincidentally came out the same day mine did, but with a very different pricing strategy. Whereas I set a low price and hoped to make up for it with a lot of sales, he set a much higher price even though that might mean a smaller sale volume.

Last week, I explained my pricing strategy in detail on Jason Cohen’s A Smart Bear blog. So this week, Jarrod wrote a counter-point to explain the strong point of his own strategy.

I’ll let you decide for yourself who won the award for Most Successful Design eBook Writer, but one thing that piqued my interest was Amy Hoy‘s intervention in the post’s comments (as well as on Hacker News).

Amy argues for high prices over low for a variety of reasons (and I guess that’s reflected in her own online seminar’s pricing).

Since she’s more Internet Famous than me, I’m going to apply 37Signal’s advice and pick a fight: I believe low prices can be a valid pricing strategy, and that’s why I’m announcing now that my next product (whatever it is) will be priced at $0.99.

If this product is a success, I will have effectively proven for the second time that super-low prices can work.

So I’m counting on you to help me prove that Amy Hoy is wrong, that there’s no right or wrong pricing strategies, and that nobody knows anything.

I’m taking the plane this Thursday and moving there for the next 3 years. My wife got a scholarship to do her PhD in Osaka, and since I work remotely anyway I’ll be joining her.

We both love Japan and have been there 3 times together. We love travelling, living abroad (we’ve previously lived in Switzerland and China), and learning new languages, so it’s a great opportunity for both of us.

Japan also has all the things that I love, i.e. design, martial arts, and great food. I’m looking forward to meeting new people, having new experiences, and generally beginning a new phase in my life.

This new beginning will also be the occasion to refocus myself on personal projects. Folyo is doing ok, but I feel it could be a lot more successful if I really focus all my efforts on it. And the recent success of my eBook has shown me that even smaller projects can have a big impact.

And then there are the small, fun side-projects like Patternify and bigger endeavors like Locomotive.

So I really have high hopes for this move. I truly believe t’s up to us to make every moment of every day live up to its full potential. But sometimes it takes a big change of scenery to remind us of this!

Required Listening: Once Upon a Time in Japan, by Rakim

So it should come as no surprise that when it was time to select a digital goods cart service to help me sell my eBook, I spent hours analyzing the pricing and features of various services.

This was not particularly cost-effective, since the price difference between all those service was pretty insignificant to begin with. So by trying to save $5, I used up a couple hours that could’ve been spent working for clients at $150/hour…

But I didn’t want to let those hours go to waste. I decided to share the results of my comparison with everybody, and so wrote an article comparing different cart services to sell digital goods for Smashing Magazine.

There’s actually a deeper point to all this: it’s all about using your time and effort effectively.

Indians supposedly used every part of the buffalo, and I try to do the same. For example, when designing for a client, I write about the design process on my blog.

Another example could be selling unused concepts as templates (with the client’s consent, of course!). And a developer might develop a piece of Javascript code into a new jQuery plugin.

So whenever you get a chance, try and make the most of every part of your work process. It might require you to invest a little more time in the beginning, but believe me, it’ll pay off in the end.

In fact, the Buffalo Principle is at play right here: I was originally just going to point out the Smashing Magazine article, but then decided to use the occasion to make a deeper, more general point.