Viral Sites, the Blogosphere, and SEO

I wanted to say more about viral sites. I think there are two really cool features that can be implemented to improve your SEO and also utilize the Blogosphere more.

Widgets – get people linking to you
Offering widgets makes it very easy to get people to link to you. For example, I could create a widget for Best Seattle Bars that allowed people to drop some code on their site and display a list of the best Seattle bars. I could also create a widget for Best Seattle Bars that allowed people to drop some code on their site to display a search box. The two best advantages of using widgets are 1) you get people to link to your site, which improves SEO and also increases referrals, and 2) you get to control the way that people link to your site. Here are two examples of widgets that Trulia, a Redfin competitor, offers:

truliamap.gif

whitebox.gif

Pretty nifty, huh?

Trackbacks – encourage bloggers to link to you
Bloggers love to blog. If you have rich content on your site such as homes for sale, restaurant reviews, or travel tips, then chances are good that bloggers are already blogging about you and linking to home, restaurant, and travel pages. Reward them and maybe they’ll blog about you more. Setup a mechanism on your site to capture trackbacks sent by blogs, and put a link on the page that’s being linked to, linking back to the blog post. On Best Seattle Bars, an example would be to put a link to each blog post that links to a particular bar page at the bottom of that bar page. You would probably want the link to be nofollow, but bloggers would still get referrals from these links.

The largest factor of PageRank is link analysis, so the more people that link to you, the better you’ll perform in search engines.  The better you perform in search engines, the more people you’ll get coming to your site.

helpd.org, Reworked

LN, my former dorm neighbor and good friend, recommended that I rework helpd.org. I reworded the site to motivate people to post ways that other people have helped. I really want the site to just be an anonymous, free-form way for people to share stories about being helped or helping out, and LN helped me realize that. I also added a RSS feed so you can subscribe to updates.  I’m open to suggestions on how to improve the site; write a comment.

Share some stories! Thanks.

Introducing Best Seattle Bars

Today is the official launch day of Best Seattle Bars! I made the site for a friend of mine, and I had a blast doing it. Features include:

  • Interactive map of the best Seattle bars
  • Popular neighborhoods
  • Basic bar information (name, address, phone, and website)
  • User reviews and a wiki-style description for each bar
  • An RSS feed for review and description updates – check it out

Given that Kyle’s domain is pretty unbelievable, I wanted to make the entire site as SEO driven as possible. I have pretty URLs, and keyworded titles and headers. Kyle and I are hoping to get tons of organic search traffic, and we’re hoping that the RSS feed gets people coming back for more.

I wrote the site in PHP with a MySQL backend. Everything is inline, and I’m really glad I made the decision to not write good code. I’ve wasted too much time writing good code in the past. Eric did the layout and design – I think it took him 30 minutes.

Kyle has some pretty awesome ideas with this, so stay tuned for more updates. Enjoy!

Computing for the Developing World

The University of Washington CSE department is offering yet another awesome class that I pounced on thanks to the recommendation by two friends, Jim and Sierra. First they offered a joint class with Google on distributed computing, including topics and projects on Hadoop, MapReduce, GFS, etc. Now I’m taking a class focussed on computing for developing parts of the world. This quarter is focussed on defining a problem and a mechanism for fixing it. Next quarter is focussed on solving that problem by making whatever devices, services, and products necessary for success.

I took this class in direct response to this former post of mine, because now I get a chance to work on a project that might actually help someone who truly needs help.  I’ll describe our project later once we have our heads wrapped around it more.

More on a Viral Site

I made a post a week or so ago about how to make a viral site, and I wanted to add to my list of TODOs.

  1. Make the registration process easy
    1. Either require as little information as possible or use a social framework like Facebook Platform or OpenSocial

This great blog post describes a usability study that looks at the registration frequency for different types of required information such as email, password, address, etc. Go take a look if you’re designing a registration process.

Update: more here.

War Story: Software Engineering a Startup

Disclaimer: I totally disagree with the post below, and I’ve written a response to it here.

I’ve published two serious websites: helpd.org and cellarspot.com. Each has a similar success story (there isn’t one), and they were both developed in very different ways. The code we wrote for Cellarspot is super scalable and robust, and the code Eric Fisher wrote for helpd is inline. I wanted to share my thoughts on which engineering approach I think is better and why.

Helpd
The code written for helpd is all inline PHP – the same, single PHP file has SQL queries, HTML, and AJAX request logic. There aren’t any classes, and there are only a few functions to simplify SQL queries. All the engineers out there are probably saying to themselves, “What are these dudes thinking? Idiots.” No. Eric wrote all of helpd in 90 minutes, which let us very easily and quickly test the helpd idea to see if it would take off. It didn’t, so only 90 minutes were wasted (we’re going to try to rework the site, so those minutes weren’t actually wasted). Inline PHP allowed us to throw something up insanely fast to see if the idea would work. Eric and I are both students making websites in our free time, so we want to get things shipped as fast as possible to see who they’ll do.

Cellarspot
The code written for Cellarspot is exquisite and is written in JSP using Spring MVC and Hibernate. We have a data access layer, a business layer, a search framework, and an index framework, etc (see the end of this post for references). We pursued Cellarspot in a software engineering class at the UW, so it was our job to write robust code. We definitely succeeded, but it took five of us three months to complete the site. Five people working an average of about 10 hours a week for three months adds up to 36,000 minutes. That doesn’t even include the first version of Cellarspot I worked on and the newest version I’ve been working on.

So what are the lessons learned here? First, I don’t regret spending so much time on Cellarspot, and the reason why is because I learned a whole lot about software engineering, design patterns, and teamwork by pushing for awesome code. I’m super glad that I learned these skills. However, I’m also super bummed that I invested so much time in Cellarspot only to see it not do well. I’ve thought up two different cases and what I would do in those cases if I were you:

Personal Project Startups
If you’re spending your free time on a project, then your time is valuable. If you’re looking to learn about engineering, then spend time writing awesome code. If you’re looking to create a website that could potentially make you millions, then write something quick and don’t worry about the code. Keep in mind that if your project turns into a 300+ person company and you chose to write shitty code, then the chances of having to rewrite most of your code is high. I suppose there are worse problems, though, like spending hours upon hours on a project that doesn’t go anywhere ;). I think you should also consider your future when deciding on how you’re going to engineer your code. If you’re planning on being an engineer in the future, then spend the time to learn how to write awesome code. If you’re planning on being a PM or someone else more business oriented, then write inline code so you can get your product off the ground quickly.

I think that I should also touch on programming languages. Languages like PHP and Ruby on Rails are great for getting a site up and running quickly. Languages like JSP are great for learning about engineering, but that’s not to say that PHP and Rails can’t be used for good engineering practices.

Funded Startups
If there are more than a few programmers at a funded startup, then write good code. Your peers will appreciate it, and the programmers that will use your code in the future will appreciate it even more. If there are only a few programmers at a funder startup, then you can probably get away with writing bad code, but be prepared to improve it later. I think that if you’re getting paid, then there is no reason why you shouldn’t spend a little extra time to write good, robust code.

I’ve spoken to a few Redfin engineers, and most of them are insanely frustrated and annoyed with the terrible code that was written by some contractors back when Redfin was first started. We’ve had to refactor over and over again at Redfin because of that shit-ass code. I’ll save contractor work for another post, though.

I think that I approached helpd and Cellarspot in the right ways. My first project taught me great programming practices, and my second project made me realize that you shouldn’t always write good code. It’s up to you to decide how you want to engineer your startup.

Software Engineer Resources

Update: I removed the “disgusting” adjective from Eric’s inline code. I suppose that I view all inline code as disgusting, even though his inline code was beautiful. The other advantage to writing inline code is that you can avoid dealing with multiple files.  Eric also wanted me to be more precise and say that inline code is great for prototyping, which is exactly what we did with helpd. Sorry about that, Eric!

You Want a Viral Site? Do this.

I’ve now failed twice at making a viral site (Cellarspot and Helpd). I’m starting to notice that this blog is growing virally. I think I learned something tonight. If you want a viral site, then you must at least do the following things:

  1. Create features that will allow users to share
    1. Invitations, tell-a-friends, etc
  2. Create features to get people to link to you
    1. RSS feeds, widgets, etc
  3. Offer a good product and/or good content

Invitations and tell-a-friends make it easy for users to get their friends involved. RSS feeds and widgets make it easy for your content to be placed on other sites. When your content is placed on other sites, it’s much more likely to be viewed by people who haven’t heard of you yet. For example, my blog has an RSS feed (thank you, WordPress), and some people subscribe to my RSS feed with their Google Reader. Some of these Google Reader people share certain posts with their gFriends, which puts my blog in front of the eyes of people that haven’t heard of me yet. Item 3 is a tossup, because I’m not convinced that my blog has good content ;).

Perhaps this is old news to some people, but I wanted to share just in case.

Am I missing anything? Want to add anything? Write a comment.

Update: more here and here.

Cellarspot: Why It Failed

Some classmates and I launched a social network for wine lovers called Cellarspot, which was my first pseudo-business endeavor. We had about 90 registered users within the first week of launch, and now, about nine months later, we have about 100 registered users. I thought some other young internet entrepreneurs would be interested in hearing why I thought it failed and what I would change if I did it again.

Before diving in I should spend some time describing Cellarspot. The main purpose of the site is to allow people to become friends and share taste notes, bottle collections, and blog posts. There are a few other smaller features as well, but the core of the site focuses on taste notes, collections, friends, and blogs. I worked on Cellarspot in class and also outside of class with a few of my classmates.

Problem 1: UI
The largest problem is the UI. Our original thoughts were that we should focus on a functional site and not on an aesthetic site. We thought that as long as features were discoverable and intuitive that they’d be used and loved. We were wrong. According to Google Analytics, our overall bounce rate is roughly 70%. That is, of all the users that come to our site, 70% of them leave after viewing the first page that they landed on.

This metric implies that either the content being presented on each page isn’t useful, the content isn’t easily discoverable, or the look of the site doesn’t leave people wanting more. I think we got all three of these wrong. First off, the site is very unattractive. In fact, there isn’t a single image on the entire site – just plain text. I questioned some of our preliminary users about why they didn’t like the site, and most of them said that they didn’t enjoy looking at the site. We should have spent more time on an aesthetic UI, which for me means delegating the UI work to someone else. I’m confident in my CSS abilities, but I absolutely cannot make pretty looking layouts with images, design elements, awesome colors, etc. I think we did a good job of making data discoverable and useful, though.

Problem 2: Landing Pages
Landing pages are pages that people land on when they first view the site (in most cases this is the front page). We should have spent more time thinking about how people would access our site. It turns out that people won’t always land on the front page and might instead land on a bottle page. We didn’t even consider this, and it turns out that most of our traffic comes from organic search and lands on a bottle page. I’m sure that most people who land on this page say, “What the hell does this site do and why is it so ugly?” We should have included some descriptive text on the bottle page so people would at least be able to learn more about Cellarspot.

Problem 3: Understand Your Demographic
As much as we thought we understood our demographic, we didn’t; we were too general. For example, we said that our demographic was “wine lovers.” What does that mean? How old are they? Are they computer savvy? What background do the come from? Why are they going to be using our site? These are questions that we should have answered better. If I could do it again, I would build the site for young Web 2.0ers and not so much for older wine lovers. There are a few reasons for this belief. First, young people are less likely to have lots of wine, making their initial commitment to Cellarspot very small (they don’t have to type in lots of bottles and notes). Second, Web 2.0ers are easier to market to in that viral, internet-based marketing would probably do the trick. Generally you have to spend money on various ad mediums to attract less tech-involved people to the internet. Third, Web 2.0ers are more likely to understand design elements such as tabs, drop down arrows, etc. If we targeted young Web 2.0ers from the beginning, we could have catered the UI more, making the probability of it being used and spread higher.

Problem 4: Know Your Use Cases
We should have spent more time thinking about use cases, which go hand-and-hand with understanding your demographic. When a user is on page X, what are they looking for? Why are they on this page? What is the main thing they are trying to accomplish? By truly understanding use cases, you are more likely to create a site or feature that will be used. Don’t try to figure out these use cases on your own either. Ask questions to people that might be using your site at some point. I did tons of research for Cellarspot, where I spoke with young and old wine lovers about how they would use the site. I did a poor job of synthesizing those thoughts and understanding Cellarspot’s use cases.

Problem 5: Make Economic Decisions
I spent a lot of money on a rack-mountable Dell server thinking (knowing) that Cellarspot would be successful. I also spent (and still spend) too much money colocating that server, although now the server is actually being used by lots of other sites, including this blog. Start small with hosting and scale your hosting options as demand rises. Start with a standard web host or Amazon EC2 and buy your own servers later only if you have to. Don’t get me wrong, buying my own monster rack-mount and colocating it in a data center was awesome, but it’s absolutely not economic. Here are some bonus pictures of the server and data center:

img_1169.jpg
Robert playing with things.

img_1172.jpg
Tony, our network admin, hanging out in the data center.

It Doesn’t Matter What You Think; It Matters What Your Users Think
While rereading my post before publishing, I realized that I say “I think blah” a lot. This made me remember the words of a former professor of mine, John Castle. You can make claims about what your users will think, but you have no way of validating those claims unless you actually speak to your (potential) users. Prior to making a product, do some research. Talk to some people in your demographic. Ask them what they want in a product and how they would use that product. It doesn’t matter what you think; it matters what your demographic thinks. The best way to know what your demographic thinks is to interview them and find out for yourself.

Cellarspot was a failed business but not a failed experience. I learned an insane amount from pursuing Cellarspot, and to this day most of my interviews involve Cellarspot. I don’t regret anything about it at all, but I wish I had the time and motivation to launch a sweeter, more badass Cellarspot. Try your best to launch an awesome product, and make sure you learn as much as you can from the launch. In my case, the experience gained from launching a product greatly outweighed all other aspects of the product, especially the (negative) cash flow

Speaking of Helping People, Presenting helpd.org

I’ve had an idea for a long time to create an anonymous forum for people to post little ways that they’ve helped out. This idea was mostly inspired by those insurance commercials where someone will do something nice or courteous and another person will observe the act. Then the observer will also do something nice or courteous, and the chain contains.

After thinking a lot last night about jobs and helping out, I decided to make my idea a reality. I contacted a friend of mine who I met at the Google APM batch day, Eric Fisher, to see if he was interested in whipping up a quick layout. I’m absolutely awful at making pretty layouts, so I try to delegate as much as possible. Anyway, I sent Eric an email with a quick description of what the plans are. He sent a reply about 90 minutes later with a link. Eric is a magician. He managed the code a beautiful, functional, AJAX-enabled site in 90 minutes. How did this guy not get hired by Google? Thanks, Eric!

Eric zipped up the source and sent it my way along with a SQL dump. I spent about an hour changing a few things, adding a captcha, and getting it setup on my web server.

I present to you helpd.org, a place where you can make anonymous posts about ways you’ve helped out. Helpd is pretty basic at this point, and my plan is to greatly expand it if people find it interesting. I have a few thoughts in mind: RSS feed, pagination, browsing capabilities, voting systems, categories, community aspects, etc.

Go take a look at the site, make a post, and tell your friends. I think it’d be really cool if this site took off, and my plan is to give all the proceeds to Wikipedia and Craigslist.