And just 48 hours before that, I was halfway across the globe, back home in Osaka. So it’s certainly been an eventful couple of days.

#Rebuild2014

When Justin and Tony approached me about speaking at Rebuild, I was both honored and terrified. I had never spoken at a “real” event before (defined as one where people actually pay to hear what you have to say). In fact, I had never even attended a conference like this before (yes, I’ve lived a very sheltered life).

But the fact that you’re now reading these lines is proof that public speaking didn’t kill me, and I actually quite enjoyed the experience, in no small part thanks to the amazing Rebuild crew.

I also got to meet a lot of really great people, both among the speakers (some of which I had known for years online, yet never met) and attendees.

The Talks

To give you a feel for what the event was like, here’s a quick recap of the talks (I’m sure videos will be uploaded soon as well):

Mig Reyes took the stage first to start things off. His talk was a mix of autobiographical insights and thoughts about design, centered around the theme of not letting yourself be constrained: don’t pay attention to titles, move fast, and make ugly things.

After Mig, Benjamin Dauer talked about his work at NPR, and designing for listening. He had a very nuanced message about designing interfaces that fade away to let the user enjoy the experience, and tied it all back to his own love of music.

The third speaker was Julie Ann Horvath. Her talk was very different and very personal, more monologue than presentation. She shared some of the lessons she learned working with all kinds of people (some good, some bad), and reminded us that being passionate about your work shouldn’t be an excuse to treat others badly.

After the break, Morgan Allan Knutson took the stage to talk about his work at Dropbox and the concept of invention. Looking back, I’m not sure I remember what his talk was actually about. But I do remember that it was beautifully illustrated and extremely funny.

Sketchnote by @chrisbasham

After that it was my turn to speak. In contrast to the other speakers, my talk wasn’t very autobiographical or personal at all. It was basically a 45-minute introduction to Meteor, centered around a step-by-step walkthrough of building a simple Meteor app.

I can imagine the material probably felt a bit dry for a large part of the audience, especially compared to the other speakers, but I think overall it was a good idea to have at least one technical talk.

I was followed by Rachel Andrew, who talked about her experience running 2-person bootstrapped company Perch. Nearly every point she made mirrored my own experiences running my various projects. Which hopefully means we’re both doing something right!

The day was concluded by Michael Lopp, who gave an amazing talk about Stables and Volatiles (people, not chemicals). He kept the audience captivated for the whole 45 minutes, and I’m still in awe of how good of a speaker he is.

Thoughts on Speaking

Overall, I would definitely call my first real public speaking experience a success. I didn’t stumble too much during my talk (as far as I can remember), and although I’m still convinced I put the vast majority of the audience to sleep, a few people at least did tell me they enjoyed my talk.

I want to improve, though, even though speaking (public or otherwise) isn’t really something that comes naturally to me (I’m more the quiet, reserved type).

So if you’re holding a conference and want someone to put your audience to sleep with 60 slides filled with 12-point code, I’m your man! Oh, and did I mention you’ll also need to fly me in from Japan?

The conference will take place on April 18th in Indianapolis, and I’ll be speaking about (what else!) Meteor.

This is going to be my first time ever speaking at a big design conference like this. In fact, it’s also going to be my first time attending a design conference.

I would be lying if I said I wasn’t nervous at the idea of speaking in front of a couple hundred people. I’m not a great speaker, and my topic won’t be particularly fun (after all, it’s coding).

But there’s two reasons why I wanted to do this: first, I won’t know if I like public speaking until I try it. Who knows, maybe it won’t be a total disaster.

But the more important reason is that I honestly believe that Meteor is simple enough that you can gain a decent understanding of its main concepts in 40 minutes.

So hopefully, no matter how bad my presentation skills are, the audience will still be able to come away having learned something. And after all, isn’t that why you go to a conference in the first place?

P.S. I will drop by San Francisco on my way back for 10 days or so. I feel like I’m spending half my time there these days, but then again that city seems to have a never-ending supply of awesome people to meet!

I didn’t do one last year, and I ended up regretting it. Not because I think anybody else cares, but because I think it’s nice to keep a record for yourself. So here goes!

January

After spending the holidays in France, I came back to Japan mid-January. I can’t remember much from that month, probably because the harsh Japanese winter numbed my brain cells.

• Went on Product People.
• Bought a skateboard and started to learn to skate.

February

I spent the first part of February working on Flat Pixels, my essay about flat design and skeuomorphism.

It turned out to be my most popular piece of writing ever, and even if I’m still waiting for that multimillion dollar book deal, I really enjoyed the chance to flex my writing muscles.

February is also when we started writing Discover Meteor (at the time, still just “The Meteor Book”).

Creating the book’s basic outline only took us a week or two, but fleshing out the chapters would end up taking a lot longer.

• Started writing Discover Meteor.
• Designed a logo for Sidebar.
• Published Flat Pixels.
• Acquired three goldfishes, two of which are still alive at the time of writing.

March

I was pretty busy with the book, so March ended up going by pretty fast.

In fact I did so little else that I couldn’t even find a good way to illustrate this month. So here’s a random photo of a shibe.

• Worked on the book.
• Bought a second skateboard.
• Did a hangout with the Hunie crew.
• Talked about email marketing hacks at HNKansai.

April

Like March, April was mostly spent working on the book, although I did get a chance to enjoy the sakura with some friends visiting from San Francisco.

• Kept working on the book full-time.
• Went on the Upfront podcast.

May

May ended up being the most exciting month of the year. It was certainly the one with the most flying around, since my travels spanned across three continents.

First, I went to San Francisco for Discover Meteor’s release party. This was also the first (and to date, the only) time I met Tom Coleman, my co-author.

Then, a few days after coming back from San Francisco I headed for China for my brother’s wedding. Apart from the wedding itself, the highlight of the trip was assuredly eating bee larvaes, bamboo worms, and some kind of enormous grubs just to gross out my wife.

After that, I then flew to France to see my family, before taking the train to London for the .net awards.

• Launched a book in front of 150 people.
• Attended Meteor meet-ups in three different countries.
• Got made fun of by Josh Widdicombe for coming all the way from Japan and not even winning an award.
• Ate a bucket-full of insects. Actually liked it.

June

After coming back from France I would’ve been happy to take a break, but there was still a lot of work to do on the book.

I had stopped training Brazilian Jiu-Jitsu since moving from Kyoto to Osaka in order to focus on Telescope and the book. But in June, I knew it was time to go back to the gym.

• Released the Premium Edition of the book.
• Started training again, felt like a white belt after an 8-months BJJ break.
• Went hiking a few times; saw a boar and some snakes.

July

I can’t remember much of what I did in July, apart from eating a lot of watermelon. It’s pretty much the only way to beat the heat of a Japanese summer. That, and air conditioning.

• Launched my portfolio site after sitting on it for a year.
• Went to Okinawa.

August

I spent a big chunk of August working on a new landing page and refreshed design for Folyo, in hopes of giving what I consider a failed product a second chance.

• Held a hangout about self-publishing with Nathan Barry, Justin Jackson, and Paul Jarvis.
• Redesigned the Folyo homepage.

September

I headed back to France in September for some family matters, but it was also a chance to meet up with old and new friends.

• Was part of the judging panel for a startup idea competition for Recruit.
• Went on The Walking Web (french).

October

October was yet another busy travel month, as I headed to Beijing for the second time this year to attend the ADCC, the most prestigious submission wrestling competition in the world, where two of my teammates (from France and Brazil) were competing.

I also seized the occasion to co-organize the first ever Beijing Meteor meetup with Brent Abrahams, which was a lot of fun.

• Rubbed elbows with some of the best fighters on the planet, including ex-UFC champion Benson Henderson.
• Went to an MMA event in China.

November

November was refreshingly devoid of any meetings, travels, or event.

Well, except for HNKansai that is, which this month was organized in collaboration with the Osaka Innovation Hub.

• Expanded the Telescope site with a blog and a showcase section.

December

With my wife gone away on a scientific research mission for six weeks, I decided to do my own thing as well and catch the first plane to San Francisco.

The highlight of the trip was assuredly Discover Meteor Day, an offline/online event that saw 50 people come to a live workshop at the Meteor HQ, and more than 10,000 join them online to access the book for free!

• Spent my first Christmas in the U.S.
• Spent my first New Year in Japan.

Wrapping Up

So there you have it. One year of coding, writing, designing, and wasting time on Hacker News and Reddit.

Also not mentioned here at the countless hours spent hacking on Telescope and Sidebar, updating Discover Meteor, and writing emails and blog posts.

Overall I’m pretty happy with what I accomplished: I succeeded in focusing my work on a smaller number of projects (I’m pretty much down to Sidebar, Telescope, and the book now), and also managed to turn two of these projects into financially viable endeavors, which is an important milestone for me.

2014 Goals

Work-wise, I pretty much only have a single focus for the first quarter of 2014: Discover Meteor. With Meteor 1.0 coming up sometimes this year, I’ll have my hands full.

And in any case, I find that forcing myself to focus is refreshing, especially. after a few years of jumping from one thing to the other.

Once that’s done, I would love to drastically improve Telescope and Sidebar, and give Sidebar the attention it deserves. I know Sidebar has huge potential, it’s just a matter of finding the time.

On a personal level, I really want to improve my Japanese. So far I’ve been “studying” by watching japanese dramas, and although I’ve picked up a lot of vocabulary my grammar is basically non-existent.

I also want to travel to more new places, get back into producing music, and do more strength and conditioning to complement my BJJ.

I guess we’ll see how much of those I’ll manage to accomplish in 2014!

When I opened Photoshop to design the CodeYear landing page, I definitely wasn’t expecting things to blow up like this. After all, even New York Mayor Michael Bloomberg famously signed up to learn to code (which should come in handy now that he’s out of a job).

Yes We Can (Code)

A few months later, I wrote Please Learn to Code to explain why I thought initiatives like CodeYear were important, and this post too went viral, hitting the top spot on Hacker News and spreading across Twitter. And today, it turns out President Obama is saying the same thing as part of the #HourOfCode operation.

And in the meantime I ended up writing Discover Meteor, a book that – you guessed it – teaches people how to code. So although I didn’t plan it this way, it sort of all fits together.

#DiscoverMeteorDay

So I’m proud to announce the next step in my “World Domination Through Teaching To Code” masterplan: Discover Meteor Day.

Discover Meteor Day is a long name for a simple thing: on Saturday, December 14th, you’ll be able to read the whole book online for free for the first time ever.

Head over to the Discover Meteor blog for more details. And I hope to see you online on Saturday!

Last time I was there, we had the launch party for Discover Meteor and I attended a designer potluck with over 200 other designers. So I don’t know how I’ll be able to top that, but I’ll try my best.

For starters, I’ll be attending the next Meteor Devshop, so I hope to see you there. And I’m also looking forward to meeting people in town for An Event Apart. I don’t have much plans beyond that yet, but I’m sure I’ll find something to do!

P.S. If you’re in the SOMA area and are looking for a roommate for a week or two, let me know!

The ability to undo mistakes is one of the most powerful advantages of computers over their analog competitors. Yet ever since web-apps started taking over, I feel like we’ve been slowly losing this superpower.

After all, undo might be ubiquitous on the desktop, but when was the last time you saw a web app with an undo command?

DROP DATABASE

I first felt that loss right at the beginning of my career as a web developer. I had built a custom CMS for one of my first clients, and while rooting around PHPMyAdmin I mistakenly deleted their whole database.

I still had a previous backup, so in the end the whole incident only resulted in their intern wasting a couple hours inputing the same data again. Yet I distinctly remember the feeling of dread that came over me once I realized my stupid, stupid mistake, as well as how hard I wished it could be taken back with a simple command-z.

Who Needs A Server Anyway?

Since then, I’ve committed my share of dumb deleting, each time cursing myself and wondering why the Internet had apparently never heard of undo.

The latest instance of this occurred last month, when I went ahead and wiped the production Sidebar server from existence, mistakenly thinking I was cleaning up an unused instance.

The only thing standing between you and catastrophe.

Now obviously most of the blame lies with me. I should’ve been more careful, and I should’ve made more regular backups. I know this all too well, and I’ve since taken measures to avoid such incidents.

But am I really the only one responsible?

Blaming the User

Most companies seem to think so, and this “blame the user” approach is often reflected in their product’s design.

A common pattern to deal with dangerous operations is to ask you in big red letters if you’re sure you want to do this. The implication being that if you make a mistake, it’s your own damn fault for being dumb enough to ignore the warning.

To delete, say the word “DELETE” three times in front of a mirror.

But the thing is, a warning might help when you click “delete” by mistake, but it does nothing at all when you’re mistakenly deleting the wrong item.

What’s more, these warnings very quickly lose their effectiveness: as you use the app, you quickly train your brain to bypass them as quickly as you can to save time, which defeats the whole point of interrupting the process in the first place.

So not only do warnings and confirmations fail to make you any safer, but they also slow you down. Not a great solution in my book.

Smarter Delete

So I can’t help but wonder why we think it’s ok to enable destructive operations like this without also letting the user undo them.

Enabling some kind of undo for specific actions doesn’t seem like it would be that hard technically. For example, you could simulate an undo feature by delaying the actual change for a short period of time, during which the order can be cancelled at any moment either through the user interface, or even by contacting support.

This would make sense for the user, and it would also lighten the support burden of companies. Yet I very rarely see this strategy put to use, probably because it requires more implementation work upfront.

Undo: probably Gmail’s best feature.

One notable exception is Gmail’s “undo send” feature, which I probably use at least once daily as I realize that I forgot to mention something in an email.

Implementing Undo

Implementing a full undo might be overkill for most web apps, but it’s actually quite doable.

If you paid attention in Physics 101, you’ll remember the axiom that every action has an opposite reaction. A typical undo works the same way: for every action the user, takes, you need to be able to figure out the counter action that will effectively undo it.

To do this, every undoable action first needs to be represented by an object in your code. This is called the Command Pattern and you can learn more about it on Wikipedia.

Photoshop’s history keeps track of all your previous actions

You then log a history of every action the user takes, and undoing a bunch of actions becomes as easy as climbing up the list and running each inverse action successively.

This is exactly what I did for Patternify by the way (the undo button is the the left-most icon of the toolbar).

Save the Undo!

Believe me, I understand the appeal of producing MVPs with minimal feature sets, and being wary of adding any bells and whistles to your products. And since nobody expects undo to work on the web, people won’t generally ask for it.

But if you want to make your users happy (and spend less time on support!), I would strongly suggest catching up with the 80s and thinking about implementing some kind of undo in your web app.

(See also: this great article by Aza Raskin saying basically the same thing 6 years ago. Not much progress since, sadly…)

Discuss/upvote on Hacker News.

But in French, the word has an additional meaning that’s just as common: a niche is a doghouse, like the ones with triangular roofs that you’d put in your backyard.

So one could infer that according to the French language, niches are best left to dogs. And even in English, niche is often used to dismiss a product as too limited and lacking in usefulness.

However, I’d like to explain why, despite all that, niches aren’t always such bad places to be in after all (once you get used to the dog-breath smell).

Finding My Niche

First of all, a little background on me. I recently co-authored Discover Meteor, a book about the Meteor JavaScript framework. The book has been doing really well, and nearly 6 months after launch, it’s still bringing in enough monthly revenue for both me and my co-author to live on.

Discover Meteor

I’m not saying this to brag (well, ok, I might be a little), but because it’s very relevant to the topic at hand.

If the above made you go, “Huh, what’s Meteor?” you’re not alone. Although Meteor is rapidly growing and getting more popular, it’s still a relatively new and unknown framework. In fact, it’s the perfect example of a niche.

So why did we decide to work on a Meteor book rather than address a larger market like, say, JavaScript, or web apps in general?

Big Fish & Small Ponds

Now sure, part of the answer to the previous question is that we both liked Meteor and were already familiar with the technology. But the deeper reason is that we actually picked Meteor specifically because it’s a niche.

Meteor: picking up steam, but still relatively small.

From the start, our goal was to be a big fish in a small pond and not the other way around.

Being a dominant player brings many advantages. The first one is that once people stumble on your niche, they’ll easily make the jump from there to your product.

What this means in practice is that we don’t really need to promoteDiscover Meteor directly. If we can simply get more people to use Meteor in general, we can trust that they’ll find their way to our book sooner or later.

And this in turns means that anybody helping promote Meteor is also indirectly helping us.

Contrast that with writing a book about Rails: there are already so many other Rails resources out there that there’s no guarantee that new Rails users would find your book, meaning you’ll have to work much harder at making sure your communication efforts target your product specifically.

Helping Hands

Another unexpected benefit of being in a niche is that smaller communities tend to stick together.

People from the Meteor community have been hugely supportive, not only by buying our book, but also by contributing corrections, screencasts and guest posts.

And the Meteor folks themselves have been a big help, sharing the word about our book and even hosting our launch party in their company offices.

Growing Niches

Remember when I mentioned being a big fish in a small pond? The thing is, we made the bet that this pond was special and that it would keep expanding. And just like a goldfish in an ever-bigger aquarium, we would hopefully grow with it.

A chapter from Discover Meteor

It was a risky bet (after all, Meteor could’ve fizzled out), but it paid off. Meteor is slowly progressing towards 1.0, and as it gets more mature, the ecosystem around it is growing as well.

I believe this is why our sales haven’t followed the usual pattern of a big spike at launch followed by a slow, painful descent into oblivion as one saturates the market, but are instead holding pretty steady.

And the best part is that since our book directly targets beginners, new members of the growing Meteor community are the ideal customers!

Lessons Learned

Of course, niches do have one big problem: their market size is by definition smaller. But a lot of the time, their inherent advantages can be enough to offset this downside.

What’s more I believe that by picking a growing niche, you might even be able to get the best of both worlds.

So hopefully this article will inspire you to look around for a niche of your own to conquer!

Note: this article originally appeared on the Gumroad blog. 

I’ve been to Beijing many times, and even lived there for a while a few years ago. It’s one of my favorite cities in China, and I think (as cliché as it might sound) it’s one of the few major Chinese cities that has managed to keep its soul over the years.

Anyway, while I’m there I’ll be dropping by the first ever Beijing Meteor Meetup. Since this will be the first edition, it will serve as an introduction to the framework, so don’t hesitate to drop by even if you’re not a JavaScript expert.

Looking forward to seeing you there!

Realpolitik refers to politics or diplomacy based primarily on power and on practical and material factors and considerations, rather than explicit ideological notions or moral or ethical premises.

Although the overt justification for an intervention in Syria is mostly moral and ethical (i.e. “bombs are fine, but chemical weapons are not”), once you dig a little deeper you quickly uncover many underlying geopolitical factors, like controlling natural resources or limiting Russian influence in the region. That’s realpolitik in a nutshell.

Well, I want to coin a new word: realdesign, with the following definition:

Realdesign refers to designing based primarily on constraints and practical and material factors and considerations, rather than explicit ideological notions or moral or ethical premises.

In other words, realdesign is what most of us do all day long.

Yet you wouldn’t know that just by reading the design blog posts that usually make the round.

“Ideological Notions”

For some reason, design discussion often ends up framed in terms of “ideological notions”, usually promoted by pithy catchphrases like “progressive enhancement” or “gradual engagement”.

First of all, your app better work without JavaScript (and god help you ifyour site happens to run on a JavaScript framework).

And don’t even think about making users sign up before they can try your product. Users deserve nothing less than a perfect user experience, free of annoying form fields. If you ever want to contact them, you’ll just have to guess their email or something.

Oh, and by the way, I hope you’re planning on supporting Android, IE6, Sony PSPs, screen readers, and “foreign language people”. Because not doing so would be exactly like walking up to a blind person in the street and yelling “fuck you” to their face.

Well, that changes everything. Now that I’ve been enlightened, I guess I’ll somehow make my JavaScript web app work without JavaScript, get rid of all my sign-up forms, and buy an Android phone (and a PSP, and a Windows Phone, and…).

Being Realistic

I’m being snarky of course. I know that Brad, Lee, and Daniel are just trying to inch us all along towards better practices. And I picked their articles to make a point about a trend, not because I think there’s anything wrong with them individually (in fact, Daniel’s post is particularly informative and helpful).

But the thing is, we already know all this. We all want our creations to be accessible to everybody, and support as many platform as possible. Nobody has “Make sure site doesn’t work for blind people” on their project’s to-do list.

However, we also have to be realistic. Some of us might not have access to the same resources, or might simply not be as skilled.

So often, the choice is not between a site that doesn’t support Blackberries or one that does, it’s between a site that doesn’t support Blackberries or no site at all.

Practical & Material Factors

At the end of the day, these posts might get some people to “see the light” and change the way they address those issues, so maybe they’re worth it.

But there’s also a risk of shaming people for things they already feel bad about, and painting things in black and white when they’re actually shades of grey.

So this all brings me back to realdesign. We already make choices and compromises based on practical and material factors.

Now we just need to admit it.

Folyo is a service that helps connect companies with great freelance designers. It had been stagnant for a while, so I decided to try and breathe some life into it with a new start.

(If you’re curious about why I took the decision to give Folyo a second chance instead of calling it quits, you can read more about that here)

Today, I’d like to talk about what, specifically, I’m doing differently with this new homepage.

This post is a little long, so here’s a quick summary of what it covers:

• What was wrong with the previous design.
• How to design by focusing on the message first, and visuals second.
• The one place where pain is a good thing.
• Restaurant Menu Syndrome.
• How to write effective headlines.
• Why you shouldn’t dismiss the “long sales letter” format.

Note: if you enjoy this kind of design analysis, I suggest you sign up for my newsletter. It only comes once a week, and I try to always feature actionable design advice. 

The Old Design

But first, let’s take a look at the previous homepage.

The previous homepage

If I had to sum up my goals at the time in one sentence, it would be “look professional”. I launched Folyo as a single founder with no previous business experience and not many connections in the design world, and I had somewhat of an inferiority complex.

The result was a design that looked like a startup homepage should, but with a weak message and no clear focus.

I wasn’t especially proud of it and vowed to replace it with something better “as soon as I had the time”.  But of course, it ended up serving as Folyo’s homepage for the past two years.

“You’ve Got It All Wrong!”

Throughout my interactions with Folyo customers, it was becoming more and more obvious that the old homepage was doing a horrible job at explaining Folyo’s value.

Here’s how it would typically go: people would ask me if I knew any good designers, so I would suggest they take a look at Folyo. They would then come back saying that the site featured some great design talent, but could I recommend anybody in particular?

A typical email exchange after point someone to Folyo

From these exchanges, it was clear that they thought Folyo was just a designer directory, and were browsing profiles one by one. This defeated the whole value proposition of Folyo, which is that instead of contacting designers yourself, it’s much faster to get them to contact you.

And when you start saying things like “why don’t they understand!” and “they’ve got it all wrong!”, it’s probably time to stop blaming users and take a look at what you’re getting wrong.

So for the new homepage, I decided to do a complete 180. Instead of something pretty with a weak message, I would start with the message and worry about the looks later.

Show vs Tell

I rarely sketch or wireframe when working on new designs. Instead, most of the work happens in my head: instead of trying out fonts and layouts, I try out ideas and concepts.

For this redesign, I came up with the idea of directly showing how Folyo works. So instead of explaining how you post a project and then wait for designers to contact you, I used animations to show the whole thing taking place in front of your eyes:

The Folyo process, animated

It doesn’t matter that the actual process looks nothing like this visually. What’s important is that showing is so much more effective than telling at getting a point across.

(For me, the most impressive example of this was Disqus’s previous homepage, which would take you through the whole commenting process, complete with fake commenters interacting with you.)

Once I had this concept, I began to organize the rest of the page around it.

Bringing The Pain

I started thinking about how else I could make things clearer. The first thing I realized is that although I was offering a solution, I wasn’t making it clear at all how that solution related to the customer’s current situation.

With the previous message, even if you were looking for a designer, it was very hard to see the value in using Folyo unless you had already tried other avenues (job boards, Dribbble, etc.) and failed.

So instead of targeting anyone looking for a designer, my message only made sense for the much smaller subset of people who already knew how painful finding a designer could be. And in fact, one of the most common replies I got when suggesting people check out Folyo, was “why can’t I just browse Dribbble instead?”.

The solution was to start things off by putting that pain in writing. In other words, before explaining how you’re going to save the day, make sure the reader understands why the day needs saving in the first place:

Finding a designer is hard: here’s why

Restaurant Menu Syndrome

A lot of landing pages suffer from what I would call “Restaurant Menu Syndrome”.

When you go to the restaurant, you enjoy having a big menu with all kinds of options: here are your starters, and you’ve got a couple entrées to chose from, and here, don’t forget the drinks and desert section, too!

Translate this approach to the web, and you end up with multi-column landing pages that try to give you a little bit of everything. Here’s our blog, here are a few testimonials, and here are some extra links in our footer just to make sure you don’t leave hungry.

But although this strategy might work for restaurant menus, I’m not sure at all it’s a good fit for most startup homepages.

As you can see, the previous homepage had no less than 9 distinct points of focus, resulting in a disorienting and messy experience:

The “Restaurant Menu” homepage

The Omakase Strategy

Instead, I would suggest the omakase strategy. This is a Japanese term roughly meaning “I’ll leave it to you”, and it’s what you say in a sushi restaurant when you’d like to let the chef decide what you’ll be eating.

On the web, that means letting the design take charge and firmly guiding your attention from point to point (and the risk of having to eat sea urchin is also greatly reduced).

This is much easier to achieve with a single-column format, as it removes the “what should I be looking at next?” effect that often occurs with multi-column layouts.

A single vertical linear path

And instead of worrying about eye tracking and f-shapes, your task become much simpler: simply keep the user scrolling down the page. It’s not a coincidence if scrolling-triggered animations have become so popular: it’s a great way to keep the user engaged with minimum cognitive effort on their part.

Scanners vs Readers

When attempting to lead someone down a page of text, another key point to keep in mind is that there are different types of readers: some readers actually read, but most are content to just scan, jumping from headline to headline.

This means that it’s very important that your headlines make sense by themselves. You can think of it as the headlines being a condensed version of your body copy.

Here’s a quick example of what I mean:

Copy:

Folyo designers are hand-picked, and each designer’s application is evaluated individually.

Headline:

• Wrong: Quality Over Quantity
• Right: We Only Feature The Best Designers

While the first headline certainly has a nice ring to it and complements the copy nicely, it doesn’t actually mean anything by itself. So someone scanning across the page will get a lot more information from the admittedly less elegant second option.

Another nice trick I got off the new Freckle homepage is to use an ellipsis “…” to link two headlines together.

Using ellipses to link headlines together

Speaking of the Freckle homepage, it’s a great example of good copywriting, and I had it opened in a browser tab while working on Folyo.

So it’s not coincidence that a lot of the things I talk about here are also covered in this great article about the Freckle redesign (even though I didn’t come across it until after my own redesign).

The Dreaded Long Sales Letter

By now, you might’ve noticed that the technique and format I describe correspond to what’s known in marketing circles as a long sales letter.

While very effective, this format also suffers from being associated mostly with weight-loss formulas and various other scams questionable endeavors.

Red font, ugly design… yep, it’s a long sales letter

That’s not a coincidence: in addition to being an effective sales tool, this format is also comparatively easy to produce, since it’s (mostly) text.

That doesn’t mean the long sales letter can’t be done well. 37Signals famously A/B tested a long sales letter version of the Highrise homepage to great effect, and the aforementioned Freckle homepage is another example that long sales letter don’t always need to make your eyes bleed.

Since I didn’t want Folyo to come across as cheap, I started thinking about ways to take a page out of 37Signals and Freckle’s book and get the benefits of the format without its downsides.

Breaking The Mold

The first thing I did is split the page off in sections. Not only did this let me fit in the animated “how it works” section nicely, but it also visually departed from the standard white page of LFLs.

I also gave the page a bit more character by setting the text in Rooney Sans, a nice rounded font with an approachable and fun personality.

Breaking from the single-column layout

Finally, I made sure to include breaks from the rigid single-column layout throughout the page, for example in the designer profiles. Content like the four designer profiles is not meant to be read closely anyway, it’s mostly there to give context to the page. So setting it on multiple columns isn’t that bad.

The Splash Screen

Even after all this, I still felt like something was missing. Like many text-heavy page, my landing page didn’t have any strong “hero” zone. I tried filling the void with a large headline or even a quick illustration, but it wasn’t working.

At that point, I stumbled on the Mixture site, and noticed that they too used the “full-width bands” format (with nice fade-ins and animations to boot). I also noticed that their first “band” automatically filled in the height of the window thanks to an ingenious CSS trick (setting its height to 100vh, which means “100% of the viewport height”), and I decided to appropriate this idea.

Now it might seem weird to have what is essentially a splash screen on a homepage. After all, I’m creating an artificial barrier that’s preventing people from seeing my content.

The landing page’s splash screen

But on the other hand, the splash screen sets the tone of the site and gives a strong identity to what would otherwise be a fairly forgettable design. And setting position:fixed on the splash screen also contributes to making the design stand out, since the rest of the page doesn’t scroll up like the user expects it to.

As a designer, my perspective on this might be a little different from purely marketing-oriented folks. But I believe strong branding is important, so I’m ready to take risks to establish that.

But Does It Work?

Of course, the only way to really test the validity of all these theories would be by A/B testing each of them, and I intend to do just that over the next couple months.

That being said, just because you don’t test your results right away doesn’t mean you shouldn’t be trying to improve your product.

I’m very happy with the redesign so far, if only because it gave Folyo a new start, and gave me a nice motivation boost (after all, nobody likes working on an old-looking product). And I think that matters a lot when you’re working on your own projects.

So go take a look and share your thoughts here or on Hacker News. And if you have a chance to put some of these techniques to use, I’d be curious to know what kind of results you get!

P.S. On a completely unrelated note, if you have any interest in self-publishing an eBook you should join me and 3 other authors for a live hangout next week.