James Yu

Staring at Zero

2013-06-13T13:32:36-07:00

Seeing Parse reach 100,000 apps is humbling.

Everything starts from zero. I remember the early days when we would measure the number of apps that used us on a daily basis, and then write that number big and bold on a white board.

This meant that for many days, we would look up from our desks and be faced with a big fat zero. Nothing motivates you more than zero.

That summer, we coded as fast and as hard as we could.

I recall when the number hit 2. Wow! 2 apps used us! People actually found our service useful. As the weeks and months went by, that number slowly went up. From single digits to double, then to triple and beyond.

Eventually, we stopped writing the number on the board and instead sent out an internal daily email with various important stats. Waking up to that email is still the most motivating part of my day.

So, my suggestion for when you're starting any project: write your daily number down. Seeing the number in ink and not pixels is much more visceral. You'll find yourself looking up once in a while, motivated to changing that number.

The importance of startup momentum

2012-11-29T12:32:36-08:00

A startup just had its big launch. The fundraising is over and the champagne has been poured. For some, this is the great beginning. But, for others, it's the zenith.

The problem?

Momentum is easy to lose, especially after a big adrenaline rush.

Momentum is that invisible force that makes it easy to execute when things are moving, and difficult to get anything done in a languishing environment. The problem is that the natural resting state of companies (and really, anything) is to lose momentum. You have to actively work to maintain momentum.

On Y Combinator's homepage, Paul Graham emphasizes that the program doesn't end on demo day. A network of support continues throughout the life of each company.

But, there's an underlying message: just because the dinners have ended doesn't mean you should stop working hard! Building a company isn't a 3 month affair.

Demo day is only a passing milestone--the important work is when you build on the foundation to create a sustainable business after the launch dust settles. Many startups, even the most hyped ones, sputter after launch. They fail to achieve the momentum necessary to carry the ball forward. And this is a shame, because many of these companies haven't even had time to test their business hypothesis.

So, how do you maintain momentum?

1. Don't pin everything on one moment

It's a red flag when companies place too much importance on a single event like a launch, partnership, or funding. These have significance, but, by themselves, they do not equal success.

A string of these events, coupled with sustaining a culture of execution leads to success. After hitting a milestone, your eyes should already be fixed on the next one.

After a successful demo day, my co-founders and I at Parse were already looking ahead to the next big milestones in the months after. There was no time to waste.

2. Set both short and long term goals

Setting and achieving goals is crucial. There are always goals for your company to achieve, and to get there, you need action. You need to set achievable short term goals alongside big goals.

Hitting small goals gives you the momentum to hit other small goals. Soon, you'll find that you're well on your way to hitting the big goals.

Some people find it difficult to set a timeline for goals, simply because life doesn't hand you a timeline on a silver platter. So, set artificial deadlines! You'll be surprised by how much the simple act of circling a date will motivate you.

3. Don't get complacent

Reid Hoffman compares building a startup to jumping off a cliff without a parachute while building a plane. If you get complacent, you'll hit the ground hard. Every startup is trying to prove a business model. Every day, you should be working hard to achieve that proof.

Getting lazy after a big launch is like relaxing after assembling only one wing. You still need to assemble the other wing! Not to mention the engines.

4. Build a culture of doers

When momentum is lost, there usually isn't one person at fault. Every single person contributes to how well a company executes. The key is to be a doer and hire people who are doers.

These are people that will be able to conquer any task. Even if the task is outside their wheelhouse or seemingly insurmountable.

In the end, building a startup is hard work. Momentum is the flow needed to launch and vet your product in the market.

Don't lose your momentum!

We're also hiring at Parse. Check out our jobs page.

Do everything. Then hire.

2012-11-23T12:32:36-08:00

When starting a company, it's essential that you get involved in every aspect of the business. This is true whether you're a hacker, designer, or MBA. No exceptions.

The obvious reason for this is that getting your hands dirty will force you to understand all parts of your business, and eventually, your industry. This is knowledge that will give you key business insights, paying dividends down the road.

But, the equally important reason for doing everything is that it will enable you to hire the right people to expand your business.

Lots of people will tell you to only focus on "high leverage" activities—things that are strictly in your wheelhouse. Delegate everything else. While this is true as you scale, it's a grave mistake when starting out.

How do you hire A+ people if you have no idea what their jobs entail? And after hiring them, how would you evaluate their work? The most sure-fire way is to understand the skill from a firsthand perspective.

Now, I'm not saying that hackers should spend copious amounts of time attempting to make world class logos in Adobe Illustrator, or that designers should pick up a computer science book and attempt to code a scalable distributed database from scratch.

What I'm advocating is that entrepreneurs should obtain a baseline working knowledge of each business segment.

To do this quickly, there are three aspects to focus on:

Techniques
What techniques do people employ to execute on a skill? For example, designers employ storyboards, wireframes, and mockups. Engineers understand data structures, do code reviews, and thoroughly test their code. Marketers understand lead generation, funnel analysis, and know how to segment an audience to reach them more effectively.

Tools
Tools are the way people execute a technique. Learn how these tools are used and how they fit into daily workflows.

Results
Most importantly, study great work. Google for it. Talk to people who are in the field. If you want to understand design, find some great works that are admired. For marketing, seek out successful campaigns from other companies. Always ask yourself: what makes this good?

The best time to gain firsthand experience is when your company is small. Don't waste the opportunity to gain insights from doing something outside of your comfort zone. In the beginning, it's okay to do work that doesn't scale.

So, the next time you need to balance the books, try doing it yourself. If you need a new layout for your blog, try fiddling with some HTML to make it work. Need to run a marketing event? Just try doing it. Don't be scared of making mistakes. Mistakes are how you learn.

And only once you learn can you effectively scale.

Startups should think big and start small

2012-11-18T12:32:36-08:00

Every so often, I meet an entrepreneur who has big ideas for their startup but who never seems to get anything done. It's a pattern that I see in smart people who haven't had experience building real world products.

"It's gonna be huge! Revolutionary is only the beginning of how you would describe it."

This is when they launch into their vision. And it is a grand vision, full of moving parts and exclamations. Their excitement is contagious.

A few months later, I'll have another chat with them only to discover that they're overwhelmed and nothing concrete has happened. The problem is that they're thinking big but failing to start small.

Repeat after me: big things start small!

If you try to tackle too much in the beginning, you'll get overwhelmed. Not only that, but you'll lose precious time optimizing your product with too little data. This is, after all, the main reason you should always start with a minimum viable product.

You need to be able to shift decisively from brainstorm mode into execution mode. It's fine to pontificate about the big world changing vision. But, at some point, you need to clear the cruft and make a beeline to launch, then iterate quickly with real customers.

People are always surprised that Parse was started with a simple landing page to gather user feedback. And, when we launched the beta, it was an iOS and Android SDK that let you save structured data. There weren't user accounts, social integration, or other features that we have now.

Our goal is to be the foundational platform for all mobile apps. However, we started off small, with a focus on the core of what was valuable. We iterated with our users to add everything that you see today. If we had built all the things in the beginning, we would not have had the benefit of the wisdom we gained each step of the way.

In essence: think big and start small. Make a concrete plan with small milestones that roll up into a grander vision. Without that, you risk never shipping at all.

Converting CloudEdit from Backbone to Parse in 5 minutes

2012-05-20T13:32:36-07:00

In Part 1 and Part 2 of the CloudEdit Backbone tutorials, I showed you how to create a simple Backbone app using Rails. Now, I'll show you how to get rid of the Rails server entirely and convert CloudEdit into a Parse app using the Parse JavaScript SDK.

As usual, you can follow along with the codebase on GitHub and view the live app here.

Look Ma, No Servers!

My team and I at Parse have worked hard to create a platform that lets developers avoid having to think about or code anything on the server-side. You'll notice that the codebase is just a static HTML5 app. You can easily throw this behind Nginx or even host it directly on AWS. Before embarking on this tutorial, you can sign up for a free account on Parse and have your app keys ready.

You can think of the Parse JavaScript SDK as completing the other half of Backbone: data persistence. Backbone doesn't provide anything out of the box to store your data. Parse solves this (usually messy) half of the equation transparently. What you'll see is that everything will Just Work™ without any server code.

From Backbone to Parse

The Parse JavaScript SDK is based on the Backbone codebase, and the core Parse.Object and Parse.Collection classes are compatible with Backbone Models and Collections. This tutorial is a step-by-step guide on how to convert CloudEdit to use Parse. There are also general conversion instructions on the Parse documentation page.

Let's get started!

Directory Structure

The structure for the HTML5 is extremely simple since the whole site is static. We've reduced down to two main directories, with a similar hierarchy in the js directory:

index.html
stylesheets/
js/
    application.js
    controllers/
        documents.js
    models/
        document.js
    views/
        show.js
        index.js
        notice.js

Converting the Document Model

CloudEdit lets users create simple documents that have a title and body, and that are immediately publicly editable. To convert the document Backbone model to Parse, we simply replace the classes appropriately and specify a Parse className:

// The old Backbone Model
var Document = Backbone.Model.extend({
    url : function() {
      var base = 'documents';
      if (this.isNew()) return base;
      return base + (base.charAt(base.length - 1) == '/' ? '' : '/') + this.id;
    }
});

// The new Parse Object
var Document = Parse.Object.extend({
    className: "Document"
});

And that's it. Notice that we can get rid of the notion of urls entirely and reduce the model to be backed by a named class on Parse.

Converting the Collection

Converting the collection is just as easy:

// Old Backbone Collection
App.Collections.Documents = Backbone.Collection.extend({
    model: Document,
    url: '/documents'
});

// New Parse Collection
App.Collections.Documents = Parse.Collection.extend({
    model: Document
});

Again, we simply get rid of the url attribute and point the collection over to the new Parse Object class. Everything just works the same.

But, it turns out we can get rid of the collection class altogether. Since it's such a simple collection, we can automatically create an instance of this collection from a Parse.Query. Here's how we do it:

var query = new Parse.Query(Document);
query.limit(50);
query.descending("createdAt");
var documents = query.collection();
documents.fetch();

We create a query to get all documents and limit it to 50 documents. We then generate the proper collection using the collection method.

Views and Controllers

We don't have to do anything major to convert the Backbone views and controllers, since they don't involve the data models.

As for the templates, I converted from the original JST templates over to underscore templates directly in index.html. Also, I combined various Rails templates to make index.html. You could also simply copy and paste the rendered output directly to create the index page.

Initializing Parse

There's one last thing we need to do, and that is to initialize the Parse SDK with your application keys:

Parse.initialize("YOUR_APP_ID", "YOUR_JAVASCRIPT_KEY");

We also create a user automatically for each client by generating a username and password. This is crucial for security. You can read more about security and ACLs in the guide.

And, that's it. You can check out the fully functioning app here.

Backbone Apps Without Servers

With Parse, we're hoping to usher in an age of apps without servers. Or, at least, without servers that you as the developer have to worry about. What's great is that by following this guide, you'll be able to convert your existing Backbone apps to Parse with ease.

And, this is just the beginning. Read the full documentation to learn about user authentication, security, queries, geopoints, and much more.

Double Down

2012-01-13T12:32:36-08:00

People always quote the platitude "the only thing you have control of is how hard you work." But, ask most people what they thought were the big factors in the success of people they know, and you'll get a combination of timing and hard work.

I argue that along with hard work, you need to know when to double down. You need to be able to recognize that moment in time when something just clicks. The lightbulb goes off. The stars align.

The problem is, many people who get confronted with this moment are at once excited and scared. There is a fear of not being able to accept the upcoming challenge and succeed. The fear of letting yourself down in the face of good opportunity. You then start to make excuses like "oh, I'll just put it off for now, I'm sure I'll get another opportunity like this when I'm more prepared."

News flash: opportunities don't just come knocking. When it appears, you need to seize it. When I feel myself having doubts, I always ask "what is the worse that could happen?" The answer 99% of the time is: not much.

The key to success (both in business and in life) is the ability to know when to double down. People often talk about trusting your gut to make judgements when situations are bad. However, too little is said about trusting your gut to sense when good opportunities arise.

When they do arise, you need to execute, and execute with as much effort as you can.

This is how great things are made.

Hone the Core of Your Product

2012-01-06T12:32:36-08:00

Every product has a core—a feature that is the heart and soul. Everything else is secondary and is supported by the core. The product would not exist without the core.

Parse => remote object storage
DropBox => files
Facebook => friends
Netflix => movies
YouTube => videos
WordPress => blogs

Successful products and startups hone and keep a tight focus on the core of their product. This may sound obvious, but it's something that a lot of failed startups forget as the product matures and the core gets occluded.

1. Make sure the core is valuable

As a product grows and adds more features, the core is at risk of becoming sidelined. Keep the core the core of your product. This is a fine balancing act, because rich features on top of the core can make the product better.

From a UX perspective, The key is to avoid complicating core user flows. For example, uploading a YouTube video shouldn't require that you understand video annotations.

Most likely, 100% of your users will come to use the core. Don't make them think about any other features until they've mastered the core.

2. Maximize the value that the core provides

Most users will use your product just for the core feature. If it doesn't provide that much value, then it's time to rethink your product. A user shouldn't have to understand every feature of your product for it to be valuable.

A great product is one where users are happy just using the core.

3. Onboard users slowly, especially for complicated products

I do a lot of thinking about this because Parse is a developer platform, which is inherently more complicated than your average consumer product.

The way to onboard users for platforms is to have a quickstart flow that teaches users how to use the core. Nothing else.

For Parse, which provides an SDK to add backend features to your mobile app, the core is saving a single object from a mobile app. The quickstart flow methodically guides the user to the point where they can save an object. If you're a mobile dev, sign up and check it out.

Even though Parse offers much more, it makes no sense to clutter the flow for new users. When you're new, you need to learn the core, then slowly digest the rest of the features.

This is important for consumer products, and crucial for developer products. You can apply this to any kind of product.

Are you building a new document editor? Your onboarding should get users to write a few sentences and save a document. Nothing else. I took this to the extreme with QuietWrite.

Are you building a photo sharing site? Your onboarding should have users upload a single photo, then show it to them with a success message. Nothing else. Instagram did a great job at this.

4. Give users feedback as they complete tasks

A successful product is one that constantly teaches users how to use it. At the end of the Parse quickstart guide, we have a button that lets users test whether they've successfully saved an object. We give direct feedback, and users can immediately course correct if they've made a wrong turn.

This gives users the confidence that they understand the core feature of your product. From there, they'll be able to explore everything else, and hopefully become a power user.

At the end of the day, a product that is trying to be too many things at once is going to just confuse users. People want products that solve specific problems well. And the best way to do this is to focus on core features and teach users how to use them. Everything else is secondary.

Things I Learned Building a Company in 2011

2011-12-31T12:32:36-08:00

It would be an understatement to say that 2011 was a packed year for me. In one year, I

Left my job
Started a company (Psst.. we're hiring)
Made it into Y Combinator
Raised funding
Got married to the most beautiful girl
Turned 30

It was a year of action. I barely had time to think. It was always go-time. And, I feel particularly lucky to be alive. This was probably my best year ever.

Throughout, I tried to write down the things that I've learned. So, here they are, in no particular order.

Everyone is flying by the seat of their pants

No one knows exactly what's going to happen. No plan ever goes perfectly. If people say they do, they're lying. Everyone is winging it to some degree. This is especially true at the very beginning of a company. This is when ideas are raw and untested.

The key is to continually learn from the pant flying, and don't be afraid to course correct. And most of all, you need to be okay with uncertainty.

Pay attention to market signals

The best products are the ones that are literally pulled out of a company. These products solve hair-on-fire problems that affect a big market. Building a startup is finding this type of product: one that will fly off the shelves.

If you're currently building a product, you're looking for feedback from customers like "Oh my god, where were you 2 years ago? This solves a huge problem for me. I want to pay tou now." If instead, you're only getting "That's cool", then it's time to worry. You need to get to "Oh my god" as soon as possible.

Keep talking to customers and iterating.

Product marketing is minimizing the time to WOW

When a potential customer is evaluating your product, you literally have seconds before they bounce. You need to minimize the time from when they first see your product, to when they exclaim in their head: "I understand this, and WOW do I need this."

Also, instead of listing what features your product has, you need to communicate what problems it actually solves for your customers. Rob Fitzpatrick has a great article on how abstractions make us stupid. Remove the abstractions, and your product will communicate more clearly.

Content is king

Rand Fishkin says this much better than I do. A strong marketing strategy is one that is centered around organic and shareable content, rather than interruption style marketing like ads.

People on the web don't like interruptions. But, you'll be praised if you're adding something to the ecosystem of knowledge. Just make that knowledge relevant to your product.

Build custom dashboards

"You make what you measure."

No analytics solution is going to be as fully integrated as a custom solution you roll. If you have the resources, make your own dashboards that show your most important metrics. This is different for all companies. The act of creating these dashboards can itself be an enlightening exercise.

The main dashboard should only the top 3 metrics. Nothing more. Put this dashboard on a big screen and refer to it often. As you go through the day, think constantly about these metrics as you make decisions.

Of course, you can use Google Analytics, MixPanel, and other solutions. But use these in conjunction with your own dashboard.

Do if for passion and fun

This is an oft repeated meme, but it's worth repeating. If you're building a company just because you want to get rich, it will show in your product.

Do it because you believe in what you're building. Do it because you love building things that other people use. Do it because you think the world will be a better place.

On Being an Early Startup Employee, and a Farewell

2011-03-10T12:32:36-08:00

I was one of the first hires at Scribd, the social publishing site that garners over 100 million visits per month. My journey as a fruitful early startup employee has lasted over 3 and half years, and this Friday, that journey comes to an end. I will soon be pursuing my dreams of starting my own company.

It's hard to put in words the amount of experience an early employee gets at a fast moving technology startup. My time at Scribd wasn't just another job — it was a kaleidoscopic learning experience spanning all aspects of business and technology. For those of you weighing the benefits of an MBA program: join a startup instead. You'll not only learn about real world business problems, you'll also execute them in the real world with smart and passionate people.

In essence, there isn't much difference between what you do and what the founders do. Everyone is furiously iterating on the product, making the user base happy, and growing revenue.

If you're the kind of person that likes to make an impact and learn faster than you've ever learned before, being an early startup employee may be an ideal job. The following are some of the highlights of my experience.

Jared, Trip, Tikhon, and I at the 2008 Scribd Holiday Party (photo by joeywan)

Millions of Hats

I still recall the night before my first day at Scribd. We had just gotten our first office space in downtown San Francisco, and Trip Adler, one of the founders, called me up to see if I could help put together some office chairs. Of course, I happily obliged. There we were on a Sunday night, the CEO and I assembling chairs for the new office. We didn't get very far, and quickly realized that we had better things to do with our time and hired someone from Craigslist the next day. The point though, was that were ready to roll up our sleeves and get anything done that was necessary.

Eventually, I did much more than assemble a few chairs. In my time at Scribd, I have managed to work on (in no particular order): backend and frontend Ruby on Rails development, UX design, graphic design, A/B testing, user testing, viral marketing, SEO, ad optimization, database query wrangling, Facebook app development, localization, large scale redesigns, managing a team and probably a dozen more things I don't remember.

And typically, many of the projects I took on had some component where I had little or no experience with. I found myself going from "I don't know how to do X" to "Well okay, that isn't too hard" to "I have something working, let's try it in production." This kind of fast and fearless execution with little bureaucracy is exhilarating. It's an experience that you will rarely find at larger companies.

Fast Iteration and Big Changes

One of the big advantages of a startup is its ability to change strategies overnight, and execute on those changes almost immediately. Startups aim to shorten the time between the inception of an idea to deploying it in production. In doing so, they are able to iterate quickly and out-maneuver competitors.

This is exemplified by the handful of major site redesigns that I've been involved with at Scribd. It's not trivial to redesign a site as large as Scribd, but with our fantastically focused team, we were able to pull off radical changes while keeping the site stable and also measuring the impact on business metrics. Many times, we literally transformed and finessed every page on the site.

Here's a fun timelapse of me slinging some frontend work that was shot over 4 hours during our first major redesign (we were neck deep in execution mode at the time, and that day was probably one of the most productive days in my life; shortly thereafter, we launched a totally rebranded site from the ground up):

And here's a quick timelapse of the code development at Scribd, using code swarm to visualize the git commits over time:

More recently, we converted all our documents from Flash to a new HTML5 format that we built from scratch. This was a radical change to the most important pages on our site that was enacted over a short period of time. The end result was a dramatic improvement to the user experience that blew our users away.

Big Impact

The right startup environment allows you to be super productive and make a big impact. On a site like Scribd, developers push features that affect literally millions of people a day. In other words, the user-to-developer ratio is extremely high.

However, maintaining this high ratio is meaningless if developers aren't empowered to push changes to the product. At Scribd, we deploy code daily. Sometimes, small features are launched; while other times, huge site-wide changes are pushed. There isn't any hand holding from superiors when these deploys go out. Is the feature ready, tested, and does what it's supposed to do? Does it also make the site better? Then let's deploy! In fact, the title of our Campfire room at Scribd is "Working hard to make Scribd better!"

This brings us to the most important quality that enables impact: trust. Without trust, employees aren't empowered. And without empowerment, there can be no impact. Needless to say, Scribd puts a lot of trust on its employees.

This is exactly the reason why startup hiring is difficult: the amount of trust required in the candidate is magnitudes above that of large companies. In fact, the difficulty factor is inversely proportional to the number of employees in the company. When you're only one of a handful of employees, you have a big influence on the company, for better or for worse.

The People

The people make the startup. At a well-oiled startup, they are passionate, hard working, and sincere about improving the business. There really is no other way for such a tight knit group to be successful.

The biggest part of Scribd I'll miss is the people. The relationships that I've forged while working in the trenches building great products are unparalleled. Over the past few years, I have collaborated with a wide range of smart and passionate people to create the site that Scribd is today, and I'm proud of it.

Coincidentally, Scribd is hiring! So if you're looking for a fast paced environment working on one of the largest sites on the planet with a boatload of awesome, smart, and passionate people, check out their job page for open positions. There will be big things happening at Scribd in the near future, so it's the perfect time to join in on the action.

Feel free to contact me if you have more questions about my experience at Scribd.

Farewell and The Future

And with that, I am saying farewell to my Scribd friends and the company that taught me an immense amount about running a web startup. I will be starting a new venture, and will have more to share about that soon.

Progressive Signup

2011-02-16T22:21:13-08:00

This article originally appeared on the QuietWrite Blog. I'm reposting it here because it may be of interest to my readers.

At QuietWrite, we have a philosophy about the user signup process that we call Progressive Signup. Basically, we eschew the typical signup wall for a more gradual process over a longer period of time. As the user plays with our product, we gently prod them at certain checkpoints to give us more info. This results in a better and more natural user experience.

Think of Progressive Signup as being similar to visiting an electronics store to buy a TV. What you expect is to be able to walk into the store, peruse their selection, play around with some of their floor models, and then begin the process of deciding on the best TV for your needs. After making a decision, you walk up to the cash register and hand over your credit card and credentials to make the purchase.

Throughout all this, you didn't really have to pause to think about "signing up." You did what was natural: progress at your own pace with the goal of leaving with a TV.

Now imagine that your visit to the store were more like the traditional signup model, where you're presented a long signup form before you can do any member activities on the site. This would mean that before you could even enter the store and play with their products, you would have to hand over your credit card and fill out a long survey form with your personal information. I don't know about you, but I would probably turn around and head for another store that doesn't have such costly entrance procedures.

As we design websites, we need to keep this simple brick and mortar example in mind: don't force the user to jump through hoops just to play with your product! You have enough to worry about with just getting the word out about your new website. When a user lands on your homepage for the first time, the last thing you want is to create barriers between them and your core product. Remember, users are poised over the back button, just waiting to leave your site if it isn't compelling.

But how do you decide on the checkpoints for Progressive Signup? Bokardo has a great article about keeping user lifecycles in mind. As the user transitions from being Unaware to a Passionate user, we should gather information about the user in proportion to their passion. If the passion-to-information ratio is too low, we risk losing the user altogether.

At QuietWrite, we've sectioned off the various stages of user signup like so:

1. New User

When a new user lands on the homepage, we show a big button with some quick bullet points explaining the benefits of QuietWrite. When the user clicks the big button, we immediately drop them into our editor, which is the core value of our site. No signup information is necessary to edit and save writings on QuietWrite. We cookie the user so they can still access their writings at a later time, even if they give no further information.

2. Invested User

As soon as a new user starts writing, we show an email and password field in the header, with a quick note saying they can signup in order to ensure that they can access their writings later. After the user decides that our product is worth it, they give us their email and a password. Note that there is always a good reason for a user to give information, and we emphasize it here by saying an email and password combination is a much more reliable way to retrieve your writings than with a cookie, which can get lost.

3. Publishing User

Currently, the final stage of our user lifecycle ends with the user publishing their writing. Right now, publishing isn't the core of QuietWrite, so a user with many writings that starts publishing is using our product to the full extent. When a user publishes their first writing, we prompt them to give a display name, which will better identify them to visitors. We could have done that at step 2, but it wasn't necessary.

By partitioning the signup process like so, getting information from the user feels less like a chore, and more natural. We've seen a lot of engagement from users that would never have played with our editor if we had a big signup wall in the beginning.

The biggest thing to keep in mind when designing a Progressive Signup process on your site is to ask: what is the minimal amount of information we need from the user in order for them to progress to the next step. Many times, you'll be surprised how little you need.

Update: Luke Wroblewski also has some great thoughts on this here, with respect to Twitter's redesigned signup flow.

Backbone.js Tutorial with Rails Part 2

2011-02-09T00:04:13-08:00

In Part 1 of the CloudEdit Backbone.js Tutorial, we developed a basic Rails application using Backbone.js that lets users create and edit documents in the cloud. Now, in Part 2, we'll do some refactoring to clean up parts of the app and make things more readable and maintainable.

Specifically, we'll be doing the following:

Use Backbone Collections.
Use Underscore templating.
Use event binding to refresh views.

This update won't change anything in the UI: it's simply some housekeeping to tidy up the code.

As always, you can follow along with the CloudEdit GitHub repo, and also play with the live app here. They both have been updated to reflect this part of the tutorial.

Backbone Collections

As you may remember in Part 1, we loaded the list of documents for the documents#index action via a call to $.getJSON, and then instantiated all the documents in an array. But, we can provide a better abstraction by defining a Backbone Collection as follows:

App.Collections.Documents = Backbone.Collection.extend({
    model: Document,
    url: '/documents'
});

public/javascripts/collections/documents.js

It's pretty simple: we tell the collection that it should hold the Document model (via the model attribute), and that the resource to fetch the documents from the server is located at /documents. Also notice that I'm organizing collections in the same way as the MVC components: the definition is located under the App.Collections object.

Now, we can update the documents#index action in the Backbone controller as follows:

App.Controllers.Documents = Backbone.Controller.extend({
    
    // ... snip ...
    
    index: function() {
        var documents = new App.Collections.Documents();
        documents.fetch({
            success: function() {
                new App.Views.Index({ collection: documents });
            },
            error: function() {
                new Error({ message: "Error loading documents." });
            }
        });
    },
    
    // ... snip ...
    
});

public/javascripts/controllers/documents.js

All we did was instantiate a new instance of the Documents collection, and then call fetch with a success callback that passes the collection to the App.Views.Index view. We didn't even need to change any Rails code: the original RESTful /documents action is identical.

Underscore Templates

Previously, we built up our views using string concatenation. I did this so that we could focus on Backbone.js itself, and not any particular templating language.

However, for anything more than trivial views, string concatenation is a maintenance nightmare. Luckily, http://documentcloud.github.com/jammit/ provides an easy integration with http://documentcloud.github.com/underscore/ templates, which are powerful and very similar to ERb.

.jst Files

Jammit expects your javascript templates (or JST) to live alongside your regular ERb templates as .jst files. It will package up the templates into a global JST object that you can use to render your templates into strings. To make Jammit aware of these files, I simply added an entry for app/views/**/*.jst in my app package in assets.yml.

Convert the Views

Next, we need to convert our views to Underscore templates. This is the fun part, since we get to see the ugly jumble of strings turn into beautiful templates.

Let's first convert the strings in the App.Views.Edit view into the document.jst template. This would turn the following code:

var out = '<form>';
out += "<label for='title'>Title</label>";
out += "<input name='title' type='text' />";

out += "<label for='body'>Body</label>";
out += "<textarea name='body'>" + (this.model.escape('body') || '') + "</textarea>";

var submitText = this.model.isNew() ? 'Create' : 'Save';

out += "<button>" + submitText + "</button>";
out += "</form>";

into:

<form>
    <label for='title'>Title</label>
    <input name='title' type='text' />
    
    <label for='body'>Body</label>
    <textarea name='body'><%= model.get('body') %></textarea>
    
    <button><%= model.isNew() ? 'Create' : 'Save' %></button>
</form>

app/views/documents/document.jst

If you're familiar with ERb templates, this is pretty straightforward. Basically, the template now uses the model object that is passed in to fill in all the data. The call to render this template is:

$(this.el).html(JST.document({ model: this.model }));

No more complicated string concatenation!

Now let's convert the strings in App.Views.Index into the documents_collection.jst template. This turns:

if(this.collection.models.length > 0) {
    var out = "<h3><a href='#new'>Create New</a></h3><ul>";
    this.collection.each(function(item) {
        out += "<li><a href='#documents/" + item.id + "'>" + item.escape('title') + "</a></li>";
    });
    out += "</ul>";
} else {
    out = "<h3>No documents! <a href='#new'>Create one</a></h3>";
}

into:

<% if(collection.models.length > 0) { %>
    <h3><a href='#new'>Create New</a></h3><ul>
    <% collection.each(function(item) { %>
        <li><a href='#documents/<%= item.id %>'><%= item.escape('title') %></a></li>
    <% }); %>
    </ul>
<% } else { %>
    <h3>No documents! <a href='#new'>Create one</a></h3>
<% } %>

app/views/documents/documents_collection.jst

Similar to the document.jst template, this template derives all its data from the collection object that is passed in. We would render it like:

$(this.el).html(JST.documents_collection({ collection: this.collection }));

If you take a look at the App.Views.Edit and App.Views.Index models, they are now significantly simpler after moving the HTML out.

Model Event Binding

One last minor cleanup that we'll do is to avoid calling render in the save method of App.Views.Edit. Instead, we'll bind the render call to any model changes, like so:

App.Views.Edit = Backbone.View.extend({
    
// ... snip ...

initialize: function() {
    _.bindAll(this, 'render');
    this.model.bind('change', this.render);
    this.render();
},

// ... snip ...

});

Now, whenever the document model changes, the view will be re-rendered. This ensures that the view will always stay up-to-date with the model, no matter what piece of code happens to change it. This is actually fundamental to the philosophy of Backbone, which is to separate the model data from the controllers and views.

Conclusion

Let's take a look at the updated directory structure after these changes:

app/
    controllers/
        documents_controller.rb
    models/
        document.rb
    views/
        home/
            index.html.erb
        documents/
            document.jst
            documents_collection.jst
public/
    javascripts/
        application.js
        collections/
            documents.js
        controllers/
            documents.js
        models/
            document.js
        views/
            show.js
            index.js
            notice.js

We added two items: the .jst files, and the Backbone collections folder. Overall, the structure is still nicely organized, and its easy to see at a glance how everything connects.

After this update, we have a robust base that we can powerfully extend with more features. What you'll discover is that with Backbone, you avoid a lot of churn that is usually present in persisting data and view fragments in a javascript heavy Rails application. There is now a logical place for all client-side code.

In Part 3, learn about how to convert CloudEdit from Rails to Parse, so you don't need to do any server side coding at all!

Empathetic Product Discovery for Hackers

2011-02-08T00:00:27-08:00

Hackers tend to look inward. It's only natural: we spend our days thinking about intricate, abstract pieces of code. In order to focus on these concepts, your mind has to do away with distractions. You have to buckle down and think about the problem as it relates to your perspective, and how you're going to solve it. Notice the word you shows up a lot.

But if you're a hacker that wants to brainstorm the next big consumer product idea, an inward-facing thought process is exactly what you don't want. It can lead to products that:

Are built only for yourself, and thus, never really delivers value to real users.
Miss out on a significant market because you discounted it entirely.

The root problem is a lack of empathy. Without the ability to empathize with potential users, there's little chance that you'll discover the right product.

Empathy is defined as "the capacity to recognize and, to some extent, share feelings that are being experienced by another semi-sentient being." So, empathetic product discovery is simply learning through other people's experiences in order to discover potential solutions to their problems.

It's Stupid

Too often, I see hackers dismiss phenomena that occur outside of their world, like in popular culture or world news. A lot of times, they'll say "it's stupid." They feel like they're above it.

This is foolish. When a lot of people suddenly give attention to something, that's usually the sign of an opportunity.

The question you need to ask yourself is: why is this important to people?

If I had dismissed the whole Gap logo redesign debacle, I wouldn't have come up with Make Your Own Gap Logo. Nor would I have seen the opportunity with Did My Zodiac Change. These two projects may be small (and trite), but they're examples that highlight how important it is to keep your ear to the ground.

Putting Yourself in Their World

By now, it's cliché in the hacker-turned-product-guru community to talk about "putting yourself in someone else's shoes". I want to take this a step further and say that you need not be afraid to put yourself in someone else's world. Furthermore, you should be seeking out opportunities to get an inside view from the people around you.

This means that the next time your little cousin talks about his favorite video games, you should listen to him for once. What kinds of games does he like? Why does he like it?

The same goes for your girlfriend. When she starts to talk about Sex and the City, ask her why it's such a phenomenon, and why she identifies with the show.

You'll be surprised at what you'll learn.

Take life as one big opportunity to learn about other people's thoughts and desires. Innovative product builders are always listening and analyzing the world around them. This is the key to anticipating business opportunities.

Problems = Ideas

Most good ideas come from people's problems.

Ideally, you would have potential customers line up and have leisurely discussions with you about how they use the web, and what problems they're having. But these days, it's relatively easy to do this research without leaving your living room.

For example, are you planning on building a photo sharing app? Take a look at how people are currently sharing their photos on Twitter, Facebook, and other sites. Start identifying patterns and problem points. Specifically, look for users who are complaining about specific issues, or are trying to jury-rig a complicated solution to a problem using tools that aren't quite doing the job. This is usually a sign of an opportunity.

For QuietWrite, I was inspired by the growing movement against cluttered interfaces. I also looked at products like WriteRoom and Ommwriter, and how they were able to strike a nerve with productivity oriented users. But I also noticed that these products were all offline — so QuietWrite was born out of the convenience of having your data in the cloud combined with an interface for minimalists.

Don't Cover Your Ears!

To summarize, the big points behind empathetic product discovery are:

Don't cover your ears! This is especially true when you're talking to people who are very unlike yourself. Try to understand their point of view.
Research the pain points people are having. A lot of data is already in the social web.
Find patterns of complaining and jury-rigging tools to uncover potential product ideas.

Did you like this post? If so, you might be interested in reading How My Gap Logo App Became Viral and Zodiac Hacking: An Accidental SEO Experiment.

Introducing Gmailr: A Javascript API for Gmail

2011-02-05T13:27:59-08:00

I'm happy to announce that I've decided to open source Gmailr, a Javascript API for Gmail. It's the code that is used to run one of my pet projects, 0Boxer, which is an extension for Gmail that turns organizing your inbox into a game.

A few days ago, the 10,000th user signed up for 0Boxer, so I figured this would be a great time to share some of the code that makes the realtime gaming mechanics possible. Go ahead, grab the code and play with it, make your own extensions and apps, and improve it!

A Thorny Road

Developing the code behind Gmailr was fraught with frustration and dead ends. There is no currently supported official javascript API for Gmail. There was a greasemonkey script that was released a few years ago, but is now broken, with no plans from the Gmail team to fix it.

Also, no one else (as far as I know) has released any kind of frontend API for Gmail. And, in order for my app to work, I needed access to the various user actions in the UI — the backend APIs weren't going to cut it. So, I was stuck writing my own library from scratch.

But this was no easy task. Gmail runs its code through the closure compiler, thereby obfuscating everything. On top of that, Gmail is probably one of the most sophisticated javascript apps out there. Needless to say, I am now intimately familiar with the various DOM elements that make up the Gmail interface, as well as how the data is transported.

A Call to Stop Duplicating Risky Work

I had the chance to actually speak with some people on the Gmail team. Basically, they are reluctant to release any kind of javascript API, for fear of making Gmail slow (ironically, I find Gmail already pretty slow these days). There is no hope in the near future for an official javascript API.

And yet, there are many companies, like Rapportive, Baydin, and Unsubscribe.com that build their own APIs. They're all building out complex APIs with similar functionality, that can all break independently if Gmail decides to significantly change their app structure (which they inevitably will).

What we really need is for many people to come together and build out a robust and easy-to-use javascript API for Gmail that is shared across many extensions and applications. This is my hope for Gmailr.

Right now, Gmailr is pretty barebones. There are a lot of missing features. However, it has been used for the past half year at 0Boxer, serving thousands of active extension users per week. What I'm hoping for is that developers will improve Gmailr, and over time, it will be the robust API that many developers will find useful.

And maybe, if we get enough apps built on top of it, the Gmail team will take notice.

The API

The architecture of Gmailr and the process of reverse engineering Gmail probably deserves its own blog post. For now, I'll just show you a quick code snippet of what using Gmailr looks like. If you want more details, head on over to the GitHub repo.

A typical use case looks like this:

Gmailr.init(function(G) {
    G.observe('archive', function(count) {
        alert('Wow, you just archived ' + count + ' emails! Great job!');
    });
});

Basically, this will show a nice annoying message to the user everytime they archive email. The call to init does a bunch of work to bootstrap the Gmailr API. After that, there is a callback that passes in the API object, which provides the Gmailr API methods.

Let's say you want to insert some custom DOM elements. That's easy:

Gmailr.init(function(G) {
    G.insertTop($("<div id='my_div'>Hello World!</div>"));
    G.insertCss("/path/to/my/css");
});

This will insert a div on the top of the Gmail API, and also inject your own CSS. You can use this to add new features to Gmail.

The Future

I don't have much time these days to devote to Gmailr. What I'm hoping for is to pass the torch to other developers to improve upon the seedlings. In particular, here are some ways to improve it:

Expose methods that allow insertion of UI elements into various places in Gmail, like the sidebar.
Improve the reliability of the API, taking into account the various weird states that Gmail can get into.
Add capabilities to read the contents and metadata of emails received, sent, and interacted with.

If you want to get in touch, please contact me at jamesjacobyu -AT- gmail.com.

Did you like this post? If so, you might like reading Empathetic Product Development for Hackers.

CloudEdit: A Backbone.js Tutorial with Rails (Part 1)

2011-01-27T23:37:29-08:00

Backbone.js is a javascript MVC framework, and is the newest addition to my frontend toolbox. What's great is that DocumentCloud, the team that released it, is actively developing and using the framework, making it better everyday. I'm currently using it in various projects, including QuietWrite, a javascript-heavy document editing service.

The major advantage of Backbone is that it's simple, lightweight, and gets out of your way, but provides just enough structure to organize large javascript projects.

In this tutorial, I'll go over the code for CloudEdit, an example Backbone.js app backed with Rails that outlines some basic patterns that I've used successfully in my Rails Backbone projects. I'll start by describing the spec for the app, and then detail how the models, controllers, and views hook up. This tutorial assumes you already have some basic knowledge about Rails — I'll be focusing mainly on the Backbone.js concepts.

You can grab all the code for the example app in the GitHub repo. You can also play around with a live version of CloudEdit here.

The Spec

CloudEdit is an extremely simple document editing app. Here are the specs:

Users should see a list of the latest documents. To edit, the user clicks the document in the list.
Users should be able to edit documents with a title and body, and should be able to save their edits to the server.
Users should be able to create new documents.

Directory Structure

First, let's get the directory structure organized. For our Rails project, we have the usual MVC directory structure underneath the apps directory. For the Backbone files, I like to create another set of MVC directories underneath the javascript directory:

app/
    controllers/
        documents_controller.rb
    models/
        document.rb
    views/
        home/
            index.html.erb
public/
    javascripts/
        application.js
        controllers/
            documents.js
        models/
            document.js
        views/
            show.js
            index.js
            notice.js

Notice how the MVC directories mirror the Rails MVC directories.

I like to use Jammit to deliver and package the CSS and Javascript files. It also allows you to specify load ordering. So, for example, you can tell it to load all the vendor javascript files before loading the application specific files.

Let's first go through all the Backbone related code, and then tackle the Rails code (which is much simpler).

Backbone Models

We only have one model: the Document. It has a title and a body attribute. But take note that you don't actually need to specify that in the Backbone model: they're populated by JSON data, either from the server or from the client.

var Document = Backbone.Model.extend({
    url : function() {
      var base = 'documents';
      if (this.isNew()) return base;
      return base + (base.charAt(base.length - 1) == '/' ? '' : '/') + this.id;
    }
});

public/javascripts/models/document.js

The only method defined is the url method, which tells Backbone the URL to persist the Document model when calling save() or destroy(). In this case, it's a pretty typical Rails RESTful model: if it's a new unsaved model, then it should POST to /documents for a CREATE action, and if it's not new, then it should POST to /documents/id for an UPDATE action.

Backbone Controllers

There's 3 actions in our app:

Index: Show a list of documents.
Edit: Shows a specific document ready to be edited and saved to the server.
New: Shows a blank document ready to be created and saved to the server.

Note that these match up with the RESTful pages we would expect from a Document resource. You certainly don't have to organize it this way, but I find that it really helps to have your Backbone structure follow a RESTful pattern.

App.Controllers.Documents = Backbone.Controller.extend({
    routes: {
        "documents/:id":            "edit",
        "":                         "index",
        "new":                      "newDoc"
    },
    
    edit: function(id) {
        var doc = new Document({ id: id });
        doc.fetch({
            success: function(model, resp) {
                new App.Views.Edit({ model: doc });
            },
            error: function() {
                new Error({ message: 'Could not find that document.' });
                window.location.hash = '#';
            }
        });
    },
    
    index: function() {
        $.getJSON('/documents', function(data) {
            if(data) {
                var documents = _(data).map(function(i) { return new Document(i); });
                new App.Views.Index({ documents: documents });
            } else {
                new Error({ message: "Error loading documents." });
            }
        });
    },
    
    newDoc: function() {
        new App.Views.Edit({ model: new Document() });
    }
});

public/javascripts/controllers/documents.js

There's a lot going on here, so let's tackle it piece by piece.

Naming

I like to organize my Backbone controller and views under App.Controllers and App.Views, respectfully. This helps to disambiguate all the object names, especially at the time of instantiation. Thus, our documents controller is App.Controllers.Documents.

Routes

The controller expects you to define routes for each action in your app. In our case, we have the 3 routes we talked about earlier, specified as a javascript object mapping from the url hash structure to the method that is invoked. So, for example, when the user goes to /#documents/3, it will show the edit page for the document with id 3.

Methods

The rule that I use for controller methods is that they should only do 3 things: (1) get the data from the server to populate the models, (2) process that data for the views, and (3) instantiate the views.

For example, in our index method, we make an ajax JSON call to the Documents#index action on the server to get a list of documents. Then, we iterate through the list and instantiate a Document model for each of the JSON data. Finally, we instantiate the App.Views.Index view with the array of models.

The edit method is equally simple: it instantiates the Document with the given id, and then fetches the data for it from the server. Upon success, we instantiate the App.Views.Edit view.

Just like with Rails controllers, it is best to keep them skinny. You should delegate most of the complications to the views and models.

The Main App Object

Now that we have the controller setup, let's actually get our App up and running. The root route for the Rails server will serve up the following HTML, which our Backbone app will use as its scaffolding:

<h1><a href="#">CloudEdit</a></h1>
<h2>A Backbone.js Rails Example by James Yu</h2>

<div id="notice"></div>
<div id="app"></div>

<script type="text/javascript">
    $(function() {
        App.init();
    });
</script>

app/views/home/index.html.erb

The #notice and #app div elements will be used by the app as a scaffold for the UI.

The main App object itself is dead simple:

var App = {
    Views: {},
    Controllers: {},
    init: function() {
        new App.Controllers.Documents();
        Backbone.history.start();
    }
};

public/javascripts/application.js

The two main things to take note is the instantiation of the Documents controller, and the call to the Backbone.history.start(). These combined will kick off the necessary listeners to make the hash routing work.

Backbone Views

Now that we have the plumbing done, let's work on the views, which is the actual user facing interface.

For the purposes of this tutorial, I'll use simple string concatenation in my views. Of course, for more complicated apps, I would highly suggest using a templating framework like jQuery templates or jQote.

Index

App.Views.Index = Backbone.View.extend({
    initialize: function() {
        this.documents = this.options.documents;
        this.render();
    },
    
    render: function() {
        if(this.documents.length > 0) {
            var out = "<h3><a href='#new'>Create New</a></h3><ul>";
            _(this.documents).each(function(item) {
                out += "<li><a href='#documents/" + item.id + "'>" + item.escape('title') + "</a></li>";
            });
            out += "</ul>";
        } else {
            out = "<h3>No documents! <a href='#new'>Create one</a></h3>";
        }
        $(this.el).html(out);
        $('#app').html(this.el);
    }
});

public/javascripts/views/index.js

This view accepts a list of documents, and simply lists them out with links to edit each of the documents. I want to highlight a few things:

Backbone automatically (and conveniently) captures the hash passed to the initialization of the object, and sticks it into this.options.
The only method really required by the views is render, and you can do anything you want to render the view. In this case, all we do is some string concatenation, and stick it into the #app div element.
I like to call render immediately at the end of initialize. What this means is that as soon as you instantiate the view object, it gets rendered.
Note that there is no event delegation specified. The links to each document is handled automatically by the controller by simply specifying the right hash url to the Edit action. Backbone's History object automatically handles routing the clicks to the Edit action. This greatly simplifies views which usually have a million events flying around just to do routing correctly.

Edit/New

App.Views.Edit = Backbone.View.extend({
    events: {
        "submit form": "save"
    },
    
    initialize: function() {
        this.render();
    },
    
    save: function() {
        var self = this;
        var msg = this.model.isNew() ? 'Successfully created!' : "Saved!";
        
        this.model.save({ title: this.$('[name=title]').val(), body: this.$('[name=body]').val() }, {
            success: function(model, resp) {
                new App.Views.Notice({ message: msg });
                
                self.model = model;
                self.render();
                self.delegateEvents();

                Backbone.history.saveLocation('documents/' + model.id);
            },
            error: function() {
                new App.Views.Error();
            }
        });
        
        return false;
    },
    
    render: function() {
        var out = '<form>';
        out += "<label for='title'>Title</label>";
        out += "<input name='title' type='text' />";
        
        out += "<label for='body'>Body</label>";
        out += "<textarea name='body'>" + (this.model.escape('body') || '') + "</textarea>";
        
        var submitText = this.model.isNew() ? 'Create' : 'Save';
        
        out += "<button>" + submitText + "</button>";
        out += "</form>";

        $(this.el).html(out);
        $('#app').html(this.el);
        
        this.$('[name=title]').val(this.model.get('title')); // use val, for security reasons
    }
});

public/javascripts/views/edit.js

I decided to collapse both the Edit and New views into one view: the Edit view. Basically, when a Document is passed in that is newly instantiated (and hasn't been persisted to the server), it acts like a New view, otherwise, it's an Edit view.

The instantiate-and-render pattern is similar to that of the Index view. The new thing that we see here is the event delegation model. Here's how it works:

If you specify an event key on the view object, Backbone will automatically delegate the events. The key to each event is in the form "event selector". In our example, Backbone automatically binds the save method to the form's submit event. This is a very handy shortcut that allows you to organize and peruse events in view easily.

The final thing I want to point out is the save method, which really bears to fruit the power of Backbone. Unlike normal save routines, you don't have to jump through hoops to remember how to persist your data. All of that is already specified in your model. So, all we do is call save on the Document model (with the parameters taken from the title and body form elements), and we're done!

Rails

The great thing about using Backbone is that it makes your server side code very clean. The main meat of it is simply controllers that pass back JSON data to the client via XHR.

Document Model

class Document < ActiveRecord::Base
  attr_accessible :body, :title
  
  def to_json(options = {})
    super(options.merge(:only => [ :id, :title, :created_at, :body ]))
  end
end

app/models/document.rb

The Document model is simple, and only contains a body and title attribute (along with timestamps). One thing to note is that I specifically set body and title to be the only attributes that can be mass assigned, and also specifically set which attributes should be returned when calling to_json. Both of these are for security reasons (you don't want to client to be able to set or receive attributes they don't need).

Documents Controller

class DocumentsController < ApplicationController
  def index
    render :json => Document.all
  end
  
  def show
    render :json => Document.find(params[:id])
  end
  
  def create
    document = Document.create! params
    render :json => document
  end
  
  def update
    document = Document.find(params[:id])
    document.update_attributes! params
    render :json => document
  end
end

app/controllers/documents_controller.rb

As you see, the Rails controller is dead simple: 4 RESTful actions that return data via JSON. No views and no instance variables. This is RESTful design at its finest!

Conclusion and Part 2

Backbone.js really introduces a new kind of data flow for Rails apps. Instead of data flowing like this:

Rails Model => Rails Controller => Rails View

It now flows like this:

Rails Model => Rails Controller => Backbone Model => Backbone Controller => Backbone View

What I've found is that overall, Backbone.js makes it really simple to create highly responsive Javascript heavy applications.

Read on with Part 2 of the Backbone.js and Rails Tutorial, where we'll work with Backbone Collections add Underscore templates. and Part 3 where I show how to convert CloudEdit to use Parse and get rid of the Rails code entirely.

Zodiac Hacking: An Accidental SEO Experiment

2011-01-27T22:55:41-08:00

Around January 12, 2011, news was quickly spreading about a potential change to the Zodiac system. Apparently, Parke Kunkle, an astronomer from Minneapolis, asserted that the Earth's axis has shifted over the past 2,000 years, resulting in a potential change to the Zodiac signs.

I didn't know much (or cared) about the Zodiac. But, this was a hot button issue that got a ton of people riled up. When there's such intense attention on a topic, my first instinct is to look for potential app ideas that could go viral. I launched a parody Gap logo maker a few months back which took off on the coattails of the news of the horribly designed logo.

The Idea

The first thing I did was do some simple queries for "zodiac" and related keywords. Most of the top sites on the SERPs were timing out or simply returning errors. This was my first real clue that there was a lot of interest, and that there was massive traffic surrounding all things Zodiac.

But why did people care? It was simple: people's Zodiac signs may have changed. And to the people who put weight in their daily horoscopes, this was a Big Deal. All the articles about the Zodiac change listed a table of the old Zodiac dates, and a table with the altered new dates.

But there was no site that simply told you what new Zodiac sign you were.

This was it: I could build a simple app that lets users enter their birthdate, and then tell them if their sign changed, and what that new sign is.

Implementation

I kept the implementation as dead simple as possible: just a static HTML file with some javascript. The site functionality was:

Ask the user to enter their birthdate.
Show a nice message saying whether their sign changed, and what that new sign was.
Let them tweet out a message about their new sign.
Some ads for a little revenue.

I built it in about an hour, and the result is at http://www.didmyzodiacchange.com.

Update: Bemmu asks: But how did you get the site noticed initially?

I didn't do anything besides send it to a dozen friends and told them to like it and tweet it. It got picked up into the realtime widget almost immediately. This probably was a factor in getting the site up so high in the SERPs.

Results

The results surprised me.

I thought this would be another viral winner, driven by Facebook likes and Tweets. But instead, the majority came from unexpected Google traffic.

On the morning of January 14th, my site got above the fold for the search term "zodiac change", which resulted in this traffic:

My speculation is that my site was riding a "freshness bump" due to two reasons:

Zodiac was the topic of the day, and new material on Zodiac changes were being ranked very high.
My site was new and had fresh content that was extremely relevant.

I was pretty excited, because not only was the search volume relatively high, but I was seeing CTRs on my ads of up to 2-3% at a $5 CPM. Take note: the horoscopes industry is very lucrative.

However, by 11am, Google had already started bumping me back down to the second page for "zodiac change", and the traffic immediately died. I got another bump back to the first page around 2pm, but only for about 20 minutes.

Over the next week or so, the site bounced around the 1st and 2nd SERPs, and finally rested on the 3rd page where it is now. The traffic to the site now is minuscule.

In the end I learned a few things:

Google values fresh and relevant content, and will give you a bump up because of it.
You'll also get a good amount of traffic from their "realtime" results widget.
After the bump, I speculate that sites get properly "reindexed." In order to maintain high SERP position, you'll need to do the usual hard work of providing quality and consistent content.

All in all, it was a fun experiment.

And by the way, I'm still a Sagittarius.

My New Jekyll Blog

2011-01-26T18:59:35-08:00

It's been quite a while since I've rebooted my blog. So, I present to you the latest incarnation. I decided to finally migrate from a self-hosted WordPress blog to Jekyll, a Ruby-based static site generator.

In my opinion, blogs should really be a set of static files, since each post is create once, and updated rarely. This has several benefits:

Scaling is easy. Serving static files is trivial.
Highly secure. There is no app to hack.
Everything is stored as plaintext, which neatly side steps any legacy format issues.

And finally, having my blog as simple text files (flavored with Markdown) makes the minimalist in me very happy.

If you want to get started with Jekyll, I highly recommend the exhaustive guide written by Paul Stamatiou.

I've also shared my Jekyll blog template on GitHub. Go ahead and use and modify it for your own purposes.

A Throwback

There's actually been a lot of chatter around static site generation with tools like Jekyll and toto. But this is nothing new. I remember launching my first blog back in the late 90s as static files, and then moving to an early version of MovableType which required static regeneration whenever you created a new post.

It's funny how old tech re-emerges again as a response to over-complication.

How My Gap Logo App Became Viral

2010-10-09T00:00:00-07:00

It's been a fun ride over the past couple days. I launched Make Your Own Gap Logo (MYOGL) a few days ago, and it has since gone viral, receiving over 100,000 page views, and almost 10,000 logos made so far. This is the story of a viral news-based app and the frantic journey that launched it.

October 4th, 2010: The News

New hits the wire that Gap is rebranding with a new logo. In a sea of rebranding stories, why did this get so much attention? In short, (1) because Gap hasn't changed their logo in over 40 years, and (2) because the new logo is terrible: Helvetica paired up with a puzzling gradient square, something a first year design student would come up with.

I was in disbelief. Did some intern mess up and leak a joke logo that was being passed around internally at Gap? I even mocked up a version of the logo using only Powerpoint.

October 5th, 2010: The Idea

The Gap logo story is still blowing up. People all over the web are creating parodies and suggesting better versions of the logo. Someone even created the @GapLogo Twitter account.

I remember the distinct moment when I knew that I had to make an app that lets people create and share their own logos. It was around 9pm, and I was sitting on my couch while my fiance was dozing comfortably beside me. I shot up like a bullet the instant the idea culminated. It was one of those ideas that I knew would go viral: (1) it capitalized on a popular news story, (2) people are getting more opinionated about design and logos, and (3) it allows people to be creative and funny at the new logo's expense.

Designing and Building the App

I allowed myself only 2 hours to create the app from start to finish. A restricted time limit would force me to focus on only what was necessary for the app, and to keep it simple and fun. I'm a strong believer in iterating fast and pushing out a minumum viable design.

For the next 2 hours, I worked as fast as humanly possible, cobbling up a quick design in Fireworks and coding it in Rails. The following are some decisions and specs for the MVP:

It should allow the user to create a logo, and each logo should have a permalink that is easily shareable.
The generated logo should look very similar to the new Gap logo. With the word "Gap", it should be indistinguishable from the original.
The site should include Facebook and Twitter buttons.
It doesn't have to generate an image. (in short, I just didn't want to deal with ImageMagick. The logo is so simple that it's trivial to create an HTML version of it.)
The user should be able to edit the logo and create it inline as soon as they hit the homepage.
The site doesn't have to make money, it's just for fun. So, focus on the fun.

By midnight, I had a functional version up and running, and I pushed out to the new domain.

Marketing the App

I knew that I didn't have to market my app too strongly, because as soon as a handful of users shared their logos, I knew it would take off. What I did was identify all the bloggers that mentioned the Gap redesign and email them the site, and also left a comment on their blog post with the site.

At around 2am, I decided to call it a night, and climbed into my bed and promptly woke up my fiance to show her the site. She thought I was crazy.

October 6th, 2010: Virality

I woke up with a start at about 8:30am. I install Chartbeat on all my apps (it's the best way to keep a pulse on quickly changing traffic patterns). The first thing I did was grab my iPad and check Chartbeat, and saw only about 5 concurrent users on MYOGL. So, I decided to doze off for another 15 minutes.

After dozing, I checked Chartbeat again. Now it was at about 11 users. I kept staring at it, and suddenly it jumped to 23, then 33. 30 seconds later, it was at 70, with the majority of referrals coming from Facebook and Twitter. This was it!

I literally ran downstairs to my laptop to keep checking on the progress. 30 minutes later, I was seeing about 200 concurrent users, and the Tweets about MYOGL were coming at about one every 3 seconds. Facebook and Twitter's referrals dwarfed all the blogs that covered my app, proving that this app was driven all by virality (one of the my first to actually be a purely viral app).

For the most part the app was done: I didn't need to add anything to it, and it drove its own virality. I kept a pulse on the traffic for the rest of the day, and it peaked at about 700 concurrent users in Chartbeat.

Funny enough, there was another app called Crap Logo that also let users create their own Gap parody logos (theres is image based). We both launch at about the same time, but it seemed like they had a slight headstart in hitting virality.

Iterations

The next night, I added a few more features to the site: a Top page (that shows the most popular logos made) and a Random button. The Random button proved to be very sticky.

I even had a hair brained scheme to monetize the site by selling Tshirts with parody logos using Zazzle, but that didn't work.

Post Mortem

The first day saw about 100,000 pageviews, with about 20,000 visitors. Over 6000 logos were created, and the Top page really did reflect the collective sentiment of what people thought. The Top logo created is "Crap."

I even got mentioned on a Forbes Blog article about the Gap redesign.

So why did this app take off? I think that it involved the following factors:

The news was big. People hated the new logo.
The general public is becoming more design conscious, especially about logos and rebranding. People love to give their opinions on designs, more now than at any time in the past.
The app was fun, and gave users a feeling of creating their own parody. People love to share the clever things they come up with, and this app was all about that.
The Facebook Like button was key. Most of my traffic was from Facebook. A blog even mentioned the fact that another designer "liked" the app as a point of interest.
The app was launched fast. If I had waited even a half a day longer to push it out, I don't think it would have gone as viral as it did.

All in all, I had a blast launching this fun little app. I view it almost more as an art piece that crowdsourced people's sentiments about a newsworthy topic. For now, I'm calling the app a success and leaving it as that.

I did, however, throw a Google ad on the site, and it's looking like it'll pay for a few Gap shirts a month.

Tips for the Digital Traveler in Italy

2010-05-31T00:00:00-07:00

After traveling in Italy for the past two weeks, I learned a lot about how digital devices and various other tools can help with travel logistics. This was the first big international trip where I made a significant effort to use digital tools; it's stunning how much easier it is to get oriented when you're not only relying on static offline tools.

Jailbroken iPhone All of Italy (and most of Europe) is blanketed in fast 3G, making the iPhone one of the most useful tools. You'll need to jailbreak your iPhone first. iClarified is the easiest way to do this.

After landing in Italy, all you need to do is go to a local wireless provider and get a prepaid SIM card with data plan, which will run you around ‚Ç¨15. I went with TIM, which provided 3GB of free data and great coverage even in the most rural areas of Italy. I also hear good things about Vodafone and Wind.

Once you get this setup, you'll also be able to tether your iPhone 3G connection to your other devices. This is useful since many hotels in Italy still charge highway robbery fees for WiFi. If you have an iPad without 3G, you can grab the MiWi app to create a WiFi hotspot using your iPhone. As far as I know, this is the only way to share your internet connection from your iPhone to your iPad.

Evernote

I made heavy use of Evernote throughout the entire trip. It's the perfect tool to throw all those random bits of information like receipts, reservations, and itineraries. It's also an easy way to share information between your iPad, iPhone, and laptop.

Language Apps

In bigger urban areas like Florence and Rome, you can get by with English. But, in smaller towns like Bologna, you'll have more problems. It's a good idea to get the basic phrases down, and rely on a full dictionary for more difficult situations.

I recommend these two apps for Italian:

Italian Phrase Book - The best "phrase book" app. It allows you to easily build phrases for various different situations, with clear audio pronunciations.

WordRoll Italian/English Translation Dictionary - Quick and easy to use It/Eng dictionary.

Google My Maps

Google My Maps is the best way to create and manage itinerary of places. You can access it by going to http://maps.google.com and clicking on "My Maps". The UI isn't the most intuitive, but I've found it's really the best way to manage a bunch of locations you want to see. Also, it's the best app to get a "feeling" for a place, especially since you can easily see nearby places, zoom into street view, and add google search results to your maps.

Once you make your map, you can access your map on the iPhone by going to http://my-maps.appspot.com/. This is a 3rd party solution, since Google doesn't yet offer a native solution. From here, you will be able to browse all your maps, and see all your mapped points at once in the Google Maps interface on the iPhone. Very handy.

Using this, I was able to easily navigate the streets of Rome and Milan. And trust me, the streets can get very hairy, with many street names ending and starting at the most unpredictable places.

Here is a list of my maps that I've created: Milan Florence Bologna

TripAdvisor

Yelp may rule the roost for reviews in the US, but TripAdvisor is king internationally. As always, you should take reviews with a grain of salt, but I've found TripAdvisor to be pretty reliable, especially for hotels and restaurants.

Food Books

Okay, so these aren't digital, but if you're into food, and want to taste traditional Italian cuisine, I suggest taking a look at L'Osteria Italia and Fred Plotkin's Italy for the Gourmet Traveler. Many people don't know that it's actually easy to eat badly in Italy by falling into tourist traps.

Understand the food, the traditions, and prepare a list of restaurant options before heading out! The last thing you want to do is to duck into a restaurant that cooks Americanized Italian food just because you were to hungry to look for anything else.

Eating in Italy

2010-05-31T00:00:00-07:00

I spent the last two weeks traveling through Italy, eating my way through various provinces. Along the way, I was floored by the quality of food Italians enjoy. You can check out my photoset to see a glimpse.

Eating in Italy is both liberating and intoxicating.

Americans are afraid of food. We scrutinize our diets, contemplating levels of saturated fats and questioning the origins of every ingredient. Italians simply eat. And eating simply is eating better.

Italian food is the most loved food in the world. Whether you're in New York or Norway, you'll find people dining on some form of spaghetti or pizza. There are three factors to the success of Italian food: freshness and locality, simplicity, and umami. Yes, I'm using a Japanese concept to describe an old world European cuisine. I'll explain soon.

Freshness and Locality

When you eat in Italy, you are eating locally. The Italians have an unparalleled level of respect for their ingredients. Each morsel of produce encountered is the best it can be.

During my trip, I've tasted impossibly sweet tomatoes, deeply savory slices of prociutto, and rich creamy scoops of gelato. Each bite was bittersweet, because no matter how you slice it, Italian produce is just better than the rest of the world. The produce in California, arguably the best in America, even pales in comparison.

So what's the secret? Some say it's the air, others say it's the water. Italy is just naturally the best place to grow many types of produce. Whether it's tomatoes from Napoli, milk and cream from Emilgio-Romagna cows, or olives from the Amalfi coast, Italian cuisine has an advantage even before heating up the skillet.

But more important than the quality of the local ingredients is the Italian philosophy of eating fresh and local. Chefs in Italy are fiercely dedicated to using local, fresh, and in-season ingredients. Through this commitment, the foundation of Italian cuisine is firmly rooted in quality. This is the reason why simple dishes like bruschetta are sublime when the ingredients are right, and disastrously dull when they are not.

Italian chefs, wherever they are, will turn to using local ingredients. One thing to remember is that even the tomato, which we strongly associate with Italian cuisine, originated from the New World. Only after pioneers brought back the plant did Italians incorporate it into their cuisine. It turns out tomatoes grow exceedingly well in the Italian climate. It's a real testament to the Italian philosophy of incorporating local ingredients that grow well.

Simplicity

Italian food is simple. It's an honest cuisine that let's the produce and ingredients shine. You'll be surprised to learn that a lot of Italian dishes only comprise of three or four ingredients. Bruschetta is tomatoes, olive oil, garlic and bread. Bolognese sauce is chopped root vegetables, beef, pork, and wine, slowly simmered.

In the US, we like to overcomplicate Italian food. We overstuff, oversauce, and overdo classic Italian recipes. For example, a typical lasagna in the US explodes with thick layers of mozzarella, meat, sauce, and other random ingredients.

In contrast, the classic Bolognese lasagna is comprised of Bolognese sauce, bechemel sauce, spinach sheet pasta, and parmesan cheese. Each layer contains a balanced and spare amount of these ingredients. Italian chefs understand that one component of a dish should not drown out all the other flavors. After tasting how delicate a lasagna could be, all the other versions I've tasted before felt heavy and overburdened.

Umami

Italians are masters at lacing their food with umami, the delicious savory fifth taste that is associated with the presence of glutamates. This is different from MSG, which is basically artifically injecting glutamates into foods.

The foundational Italian ingredients naturally contain very high levels of umami: ripe tomatoes, parmesan reggiano, prosciutto, porcini mushrooms, ragu. The aging process in parmesan reggiano in particular produces one of the highest levels of glutamates found in any naturally made ingredient. This is the reason why parmesan is a staple in pantries across the world.

With this trifecta, there is no surprise that Italian food is revered, eaten, and imitated across the world. It is said that Italians, even at their poorest, eat better than the richest countries in the world.

After my trip, I'm hoping to emulate as much of their philosophy as possible. You don't need to be in Italy to cook great Italian food. You just need to remember to use the freshest ingredients around you to create an honest meal. Any Italian grandmother would approve of that.

Foursquare is my Location Memory

2009-04-15T00:00:00-07:00

This past weekend, my credit card was declined at various venues. It turns out, there was a fraudulent charge made on my card.

The problem with verifying fraudulent charges is that they make you do it over the phone. All online access to your account is locked. This can make it difficult to remember exactly which charge you made, especially if you're the kind of person who forgets the various places you've been in the past few days. A lot of context is lost.

As I was on the phone, trying to remember exactly what I did, I remembered my foursquare account. Foursquare is a fun little location aware app I recently started really getting into. They make it a game to check-in online whenever you arrive at a new venue.

With the super secret check-in history page, I had in hand all the places I've been in the past few days, and could easily spot the fraudulent charges.

In essence, foursquare has now become my very accurate location memory. There are definitely fun social aspects about using the service, but what I find compelling is that diligent users of location aware services like foursquare will find lots of situations where location data is a logistical gold mine.

Now, if I only I can figure who's been making those big online retail purchases.

Why Table Tennis is a Great Hacker Sport

2009-01-11T00:00:00-08:00

I've recently been getting really into table tennis, a sport I've played for most of my life, but never seriously. My father taught me when I was just tall enough to reach the table, and I was hooked ever since.

As I began to study table tennis (or more casually, ping pong) in depth, I realized it's one of the best sports for hackers. Here's why.

1. Table tennis is easy to install in any office

Just order a table, some balls, and few paddles and you're in business. No complicated setup is necessary.

2. Table tennis exercises the brain

A simple game of table tennis works wonders for the reflexes and brain. The ball moves fast, and studies have shown that the game keeps your brain sharp. It's also especially refreshing to play a fast reaction after a complex coding session, and can get your mind to drift off of a problem long enough to work out the solution.

3. Table tennis is strategy

Table tennis is one of the few sports that has a wide variety of play styles. Just like programmers have various languages to choose from, there is a multitude of table tennis playing styles. And, just like programming languages, these styles are continuously evolving. Throughout the decades, many styles of play have had their moment in the limelight.

It's really up to you how you'd like to play. Maybe you're an aggressive player that uses the handshake grip. Or, maybe you're an attacker that uses the Japanese penhold grip, utilizing extremely fast footwork. Or, maybe you're a defensive lobber (a rare type, but perhaps you program in Haskell? Don't think lobbing works? Witness the power of the lob below.)

There really is an essence of "hacking" in table tennis as well. Each style has particular strengths and weaknesses. Much of the challenge is to discover your opponents' weaknesses and change the way you play to exploit them.

4. Table tennis doesn't require you to be in super tip-top shape, but it'll get you in shape

Table tennis is an easy sport to pick up (but as the cliche goes: very difficult to master). Most importantly, for casual games, you don't need to be super athletic to play. This encourages everybody in the office to get involved, no matter how fit your are.

On the flip side, the game does offer the rare chance for many hackers to exercise during the day. A game is ideal for any hacker who has been sitting in a chair for the past 4 hours. Get up and move around. A healthy hacker is a productive hacker.

5. Table tennis is social

A game of table tennis encourages conversations, especially if you play doubles. It's a good way to get the team together and participate in something fun and interactive after a day of staring at a lifeless screen.

6. It's just damn fun.

Go out there and get a table, review the rules, and start playing. Trust me, it'll boost productivity.

A Guide for Your First Usability Test

2008-12-14T00:00:00-08:00

Usability testing is an essential tool in any product life cycle, especially at startups, where you live and die by your product. It is the most effective technique to get real user data on how they are using and assessing your product--in real life. If the product stake holders are not already bought into user testing, you need to convince them, now. Usability tests are cheap, and have the potential to save development time, money, and headaches down the road.

1. Determine Your Personas

If you're doing a startup, you should already have a good sense of who uses your site. Is it the normal internet user? Is it business people who are internet savvy? Is it your grandma? Make sure you pin down all the potential user personas before going any further.

2. Recruit Testees from Craigslist

Depending on your location, Craigslist has a rich ecosystem of people willing to give their time for usability tests. Here is a sample text I usually post:

We are a company creating an online consumer product that needs people for usability testing. The test will be no longer than 1 hour, and we'll pay you $35 for your time. Easy money! Requirements: List your demographic requirements here We are located at LOCATION, and we'll be conducting the tests on DATES. If you qualify, and are interested, please reply with the following information: - Name - Date and hours of availability - How much experience you have with internet sites, specifically searching the internet - How many hours a day you spend on the internet - The industry in which you work

Be as specific as possible with your requirements. You can always widen them later if you don't get enough responses. In the San Francisco Bay Area, I received about 20 responses in the first day, most of them eager to help out and that fit our personas. Avoid putting any information about your company or website, as you want the testees to see your site for the first time during your test.

If Craigslist isn't popular in your area, I suggest just grabbing some people from your local coffee shop. You'll be surprised by people's enthusiasm when they know they can help improve a product.

For your first battery of usability tests, take two days and block out 4 hours on each day, and try to set up times with 8 people. Some of them will invariably cancel or flake out, but, that's okay, since you really only need about 5 people to have an effective test.

3. Prepare Your List of Tasks

I highly suggest picking up Don't Make Me Think, which is a great introduction to web usability and usability testing. It's short, and chock full of practical information.

Now, write down all the user tasks that are crucial to your site. This may be the signup flow, or the upload pictures flow, or the browse profiles flow. The point is, you should be testing flows that are most important to your business objectives.

Remember that testees will take much longer than expected to complete the tasks. It's easy to lose sight of this, but as the founder or member of the product team, you're an expert at using your product. Testees have never seen your site before, and they'll have to figure it out all on the fly. Try to limit your first set of tests to 4 or 5 tasks.

Your list of tasks should be derived directly from the user flows on your site. It's best for each task to have a very specific objective for the user with a plausible story behind it. For example, a task on YouTube might be: "You're sitting at home relaxing with a friend, and you're looking for videos of lolcats. You land on the YouTube homepage. Now, I want you to go and find some funny cat videos." The more realistic the imagery you put into the testee's mind, the more comfortable and natural they will be at completing the task.

Try as best you can to make these tasks funnel the user to do one type of action. Of course, you may not be able to avoid multiple paths--just be sure to take into account all them in your task list. In example above, the user might use the search functionality on YouTube, or, they may simply browse by category.

Make a spreadsheet with each tab being a separate task, and list each step of each task on a separate row. This makes taking notes easier during the test.

4. Download Silverback

Seriously, Silverback is the easiest and slickest video and screen capturing tool for usability testing. It captures the screen while also capturing the video from iSight and puts this all into the same video on export. You'll be able to review the videos without missing a single thing the testee did during each task.

At $50, it's cheap.

If you're worried that Silverback is Mac only, and your application must be tested in Windows, you should be able to run Parallels.

5. Conduct the Test

You will need two people: one to take notes and one to direct the user to do the tasks. Here are some simple guidelines:

Make the testee as comfortable as possible. The less comfortable they are, the less likely the user will respond realistically to your site.
Many testees are nervous. Tell the testee that they are not being tested, rather, it is the product that is being tested.
Ask the testee to speak out loud during the session, explaining what they are thinking at all times.
When the testee first sees the site, ask them about what they think the site is. This is the best moment to get their genuine first impressions.
Start off with an open ended task that allows the testee to explore the site on their own.
Tell the testee to do each step of the task, but never tell the them how to do each step. This is by far the hardest part of usability testing. Remember: you need to let the testee struggle, or else the pain points in your product won't reveal themselves. If, after about a minute or two, they still have no idea, ask them, "Is there anything in particular you are looking for?". If it's a total no-go, mark the step as FAIL, and simply point to whatever the solution is and ask, "What about this option/checkbox/button/etc?" Note their response.
When taking notes, no detail is too small. Observe everything the testee does -- did they click on the image that was not hyperlinked? Did they frown when their upload aborted without a message? Were the confused by the order of things in a dropdown menu? It's the little nuances that will tell you the problem areas in your application.

6. Post Mortem

There's no point in usability testing if you don't analyze the results and make action items. Gather the team and go over the notes and videos. Everyone will probably be surprised by the number of small and big problems overlooked when designing the product.

Typically, the solutions to the problems seen in usability testing are obvious and easy to implement. Be decisive and move forward quickly.

I suggest doing usability tests periodically (once every few months) as you actively develop your product. Typically, there are no shortage of features and flows to test on your site, and it's best to catch usability problems early.

I hope this post will encourage you to do your first usability test. A lot of people tend to dismiss conducting usability tests, saying, "I know exactly what the user wants in the design." But, the fact is, in most cases, you're not the target demographic, and your intuition about the design is vastly different than the average joe. It's much better to have empirical evidence that users are responding well to your site, rather than falling back on your own gut feeling.

UPDATED 12/14/08: Thanks goes to Ron from Design Perspectives for his awesome feedback on this post.