They both took their eyes off the ball.

Last night the Cardinals blew a 20 point third quarter lead on one of the messiest comebacks in recent NFL history. How could they have let this happen? It looked like a sure win.

Well, that was Friendster’s thinking in early 2004. Their rival was MySpace but they were just too arrogant to pay them the attention they deserved. The Friendster demise is a really good case study for how to blow a significant lead in the market by tripping over your own self. If you take a look at the top 10 things that will make or break your website, you will see that Friendster broke all 10.

There are two excellent Friendster articles that every entrepreneur should read: The New York Times article (free registration required) and Danah Boyd’s analysis. The Times gives you a more business/management perspective, while Danah’s analyzes the demise from a sociological point of view.

In essence some of the biggest problems were:

• Focusing on new features and pie in the sky issues over the most basic one - that the site did not work (due to scalability issues - at times pages took minutes to load.)
• Trying to innovate on the tech side when easier solutions existed: “We had often chosen the more exotic solution over the more simple solution.” (Mr. Lindstrom - NYT).
• Not innovating on the features side - after a while you ran out of things to do on Friendster.
• Not listening to its core audience and forcing the direction of the company instead of allowing its users to guide it.

Friendster blew a significant opportunity because they really took the eye off the ball and became too complacent.

Whether you’re up 20-0 in a football game or have 20 million more users than your competition, always remember - you’re only 20 minutes or 20 months away from coming in second if you don’t focus on the game.

If you’re like me, you have probably wasted hundreds of hours of your life trying to fix glitches in your CSS-based designs. Cross-browser issues, alignment issues, and various CSS bugs like the IE peekaboo bug, make standards-based design a massive headache.

Some time ago I learned about two new services that offer outsourced CSS/XHTML coding. This was a pretty interesting concept and so I took both for a test drive. They both essentially convert your design from a PSD (Photoshop), Adobe Illustrator, JPG, or any type of “flat” file into standards-based CSS and XHTML. If you’ve ever “sliced” up a design into tables (back when that was the norm) – you get an idea of what these services do. But proper CSS/XHTML is quite a bit more complicated than slicing a design into tables, so it’s imperative to know what you’re doing to get cross-browser compatible, valid, accessible code.

Basically these services take the economies of scale approach to outsourced semantic coding. Since these people are pros and do it full time, they can crank out very good code in a lot less time than it would ordinarily take you.

Here’s an overview of the two services:

XHTMLized

XHTMLized is a network of 12 coders from 7 different countries who share the workload for the service.

• Time to completion: 7 days.
• Included:
• Support for all major browsers – IE, Firefox, Safari, Opera, Mozilla, etc.
• SEO-friendly code
• Accessibility compliant
• Pricing: $149 for 1 page, $259 for 2 pages, $359 for 3 pages, $439 for 4 pages, $499 for 5 pages, etc.
• Payment terms: Pay via paypal or moneybookers once work is completed. If you’re not happy with the quality of the work, you don’t pay.

My experience: The process took 1.5 days or approximately 36 hours from the time I submitted the work to the time it was emailed back to me. I needed a few tweaks that I had not specified originally and they were happy to oblige. Once again the work was delivered back very quickly – within hours. Total cost was $149 for one main page and another slightly modified version of the same page. The code was everything they promised (seo, cross-browser, lightweight, etc.) and worked well in IE6, IE7, Firefox, Opera, and Safari. The CSS was well commented.

PSD2HTML

PSD2HTML is a single company (as opposed to a distributed group of coders) that offers 3 different levels of markup: basic, professional, and high-end. They offer a menu of options in addition to the three levels such as “optimize for load speed” and “implement dynamic menus”. They make it very easy to contact them via email and every type of instant messaging service available and offer expedited and weekend work options (at a premium, I’m sure).

• Time to completion: 8 hours, sometimes longer depending on workload (12-16 hours)
• Included:
• Varies depending on level. See site for details. All include IE and Firefox compatibility.
• Pricing: $117 for basic, $153 for professional, $211 for Hi-End. Each additional page is 50% off.
• Payment terms: Work is paid up front via 2Checkout.com. There is a money back guarantee if you are not satisfied.

My experience: The process took 24 hours from when they received the order, 36 hours from when I actually placed it (which was in the evening at 8PM EST). The communication was good during and after delivery. The CSS/XHTML code was lightweight and efficient and worked well in IE6, IE7, Firefox, Opera, and Safari. I opted for the professional level of markup and received everything as promised. My total cost: $243 for 2 pages.

---

Overall, I was very pleased with both services – they both produced excellent code and delivered everything they promised within a very short amount of time. Personally I think PSD2HTML offers too many options and levels, but some people might like that. Also, on the business end, I think the XHTMlized business model might do better since it’s distributed and can scale a bit more as needed. I for one am very happy that these services are available – they will help me save a lot of time and avoid all the aggravation that comes with trying to create valid, cross-browser-friendly, accessible code.

My Future of Web Apps post made the front page of Digg yesterday, so I got to learn what it’s like to ride the Digg wave. It was an interesting trip to say the least.

I posted the entry yesterday morning, Dugg it once myself, and messaged a few friends to check it out. I then went about my day and in the early afternoon came back to find my site was down. I checked Digg and there it was: #6 in the list. Whoo hoo!

A Diggaggle⁽¹⁾ had already started flaming the site in the comments for being down. Now I myself appreciated the irony of the article ending in “…Break Your Website”. However, I didn’t really anticipate it making the front page, especially when others in the blogosphere had better coverage of the event and had posted about it much earlier.

I emailed Dreamhost as soon as possible about the site being down and called up Duane (the other half of AU Interactive) to redirect the DNS to our own server so we could put up a temporary page. (This blog is hosted on a separate shared account which usually suffices for small projects.) My email to Dreamhost had the following subject line: “Site Dugg! Is Down! Please send reinforcements!” and body: “I just got Dugg! Site is down! Please help!”

I was a little surprised to get the following email back from them about 15 minutes later:

Can you please explain what Dugg is? It appears you are being DDOS’ed … Your apache server was using up almost all of the system resources … Server uptime: 5 minutes 57 seconds … Total accesses: 5675 - Total Traffic: 4.5 MB … CPU Usage: 93.3% CPU load. 15.9 requests/sec - 13.0 kB/second - 835 B/request … 250 requests currently being processed … in short it is crashing the server.

It was kind of unexpected that they weren’t aware of Digg and the “Digg Effect”– I sort of assumed that a large hosting company would be on top of things like this. They renamed the folder to prevent the server from crashing as a temporary fix.

As soon as the DNS propagated, our servers were taking a brunt of the hits – within about an hour, we had received 4,000+ unique visitors. Duane informed me that the page was pretty bloated (300K+). AHA! That was my mistake. I had installed a number of plugins without thinking too much about it and it really “obesified” my pages. I had the wp-cache plugin activated which helped, but the extra plugins, namely Lightbox V2 (which uses prototype and scriptaculous libraries, both of which are a bit hefty ) were really to blame.

So I took out the unnecessary JS and waited for the traffic to die down. Duane let me know when the server relaxed a bit so I renamed the folder back at Dreamhost and changed back the DNS to point to its proper home.

Later in the evening Dreamhost responded again, explaining the situation and noting that currently the server appeared to be having a normal level of traffic. This is the only problem I’ve ever had with them, so I’ll probably stick with them, even after this fiasco. Plus they have a nice affilate program. *wink*

Now I’m just moderating comments and having fun with it. Thank you to everyone who took the time to give their feedback. I’ll leave you with some fun screenshots from yesterday:

This is kind of funny: The Digg mirror advertising the very service that couldn’t handle the site traffic.

Yes, I just coined a new term:

Diggaggle: n. 1. A gaggle of Diggers. 2. A rowdy group of commenters who leave snide remarks. Usage: “I just had a pile of virtual poo tossed my way by a bloodthirsty Diggaggle” [Origin: 2006 from Digg (n.) social networking site, and gaggle (n.), a “flock of geese when not flying”. Hence Diggaggle: a "flock of geeks".]

These are the top 10 things I learned from attending the Future of Web Apps Conference 2006 in San Francisco earlier this month. The summit was hosted by Carson Systems and included speakers like Kevin Rose, Mike Arrington, Mike Davidson, and more. It’s a condensed and aggregated summary of points covered by different speakers throughout the conference that I found most useful.

1. EASY is the most important feature of any website, web app, or program.
   Discoverability – everything is easy to find, features meant to enhance, not distract – can still be advanced, as long as it’s easy. Recoverability – actions should be without cost (ex: Digg, UnDigg). The web is about fulfilling needs – create things that let people do this as easily as possible. Drive usage. Generate touchpoints for easy spreading – easy to tell friends, relentlessly remove barriers to account signups. Make the website easy to use. Then make it easier.
2. Visual design and copy are extremely important.
   Your credibility is at stake. Don’t have your coder do xhtml/css. Start with the design, then markup, then develop the backend. Obsess about your copy and how you communicate to your visitors via text to complement how you communicate with your visitors visually. Remove distractions and simplify.
3. Open up your data as much possible.
   The future is not in owning data. Expose every axis of your data for people to mash up. Get an API and release it out to the wild, but stay conscious of abuse, whether intentional or not (ex: newbie programmers unwittingly making 100 server requests/sec.) Offer an RSS feed for everything on your site.
4. Test, test, test.
   You can do your best to make educated guesses about what will work, but you will never know unless you create it and then test it. Create goals and measurements to be able to gauge progress. Good example: contrary to previous predictions, it looks like contextual ads don’t work well in RSS feeds. (Branding ads perform better). That was only known after testing. Then again, this may not apply to your niche – test, test, test!
5. Release features early and often.
   Start with a core set of features (and create plugins on top) – always know your end goals. Don’t offer “me too” features just to to have them – stay true to your core. Small increments show visible progress. If you stay personable and honest and set expectations, people will be a lot more receptive when things break. Ideally your development should be modular, incremental, and well documented to mitigate future problems.
6. Be special.
   Passion for what you are doing and creating is paramount. If you believe it, do it. Don’t let anyone else tell you that it’s not possible or shouldn’t be done. Create purple cows. Challenge the status quo. Do it against the odds and with little startup money. (Raising too much money can hurt you and make you lose focus.) Prove all your detractors wrong. Passion and a belief in yourself will get you through the rough times.
7. Don’t be special.
   Use common standards or open source frameworks whenever possible. Don’t reinvent the wheel unnecessarily. Also, try to share user databases, ecommerce systems, and other elements between your projects to prevent siloing.
8. If you plan on developing a successful webapp, plan for scalability from the ground up.
   Anticipate growth and plan for problems ahead of time. Document everything. If you want a good real-world case study on scalability, check out Inside LiveJournal’s Backend (PDF). Find a top notch hardware partner if you don’t want to deal with the nitty gritty yourself.
9. Watch, pay attention to, or implement right away:
1. Microformats (opens up your data easily and contextually)
2. Adobe Apollo (deploy Rich Internet Applications easily)
3. Whobar (manage digital identity)
4. Akismet (stop comment spam)
10. User generated content and social software trends
    This is a bit of a catchall, but I’d like to list what has been working and not working in the user generated content space.
1. Not working:
1. Requiring participation from square 1. Not all users need to participate to generate social value.
2. Buying communities.
3. Social networks for the sake of social networks.
4. Wikipedia consensus model (many people contribute to one idea for the greater good) is not a good model in general and probably cannot be duplicated outside Wikipedia.
2. Working:
1. Giving users control, being open to different uses you did not anticipate.
2. Dunbar principle – segments of under 150 people.
3. The individual should get value and the organization should derive aggregated value from all the individuals.
4. Social sites have and need different types of users and each should be motivated/rewarded equally.
5. Many voices generate emergent order: you can get much value out of all that data.

There was a lot of other really good information and insight that I’ve not covered here. For more in-depth coverage and summary of each speaker’s contributions, check out Allen’s excellent summit notes and recap.

Hopefully by paying attention to these points you will make it to the winners list and void the losers list, next time Paul Scrivens does a roundup.

(Also, thanks to Copyblogger for guidance about writing a better headline.)

Techcrunch gave a rave review of oDesk yesterday, which is prompting me to share some of our recent experiences with outsourcing. I started subcontracting some projects through Rent-A-Coder in November of last year and most of the experiences have been positive. I also tried out oDesk earlier this year, with less than stellar results.

Rent-A-Coder

Rent-a-Coder works on a per project basis - you throw out the project requirements, different people bid, and then you choose the combination of best price and reputation. Choosing coders is rather subjective - each coder or team has a profile, ratings, the number of previous projects, their prices, etc. - so it’s up to you to decide who you’re most comfortable with. The money is escrowed until the project is complete.

I started with small projects - little bits and pieces. Found a few coders who were pretty proficient and gave us top notch work. 23 projects (of various scopes) later, I’m still pretty satisfied. The most recent project, which was the biggest we submitted, we actually had to arbitrate. The work was of poor quality, the deadline was not met, and the whole thing was a waste of everyone’s time. Since the contract was not met, though, we got our money back from escrow. This is why I would recommend keep the projects small or breaking them up into smaller pieces.

oDesk

oDesk, on the other hand, is a system that lets you “rent” a coder at an hourly rate. They have software in place that lets you keep track of progress via screenshots, progress reports, and webcams. It’s a good idea in theory and I think the oDesk team has the best intentions in mind with their system.

However, our project, which was estimated to take X amount of time, ended up being a huge money pit. After bleeding a good chunk of money (they withdraw every week), we had to end and close out the project when it was only about 75% done due to the slow progress. We were only able to gauge this after several weeks had passed, though - after we had already paid the coder for work. We ended up finishing the project through Rent-A-Coder at a much lower price. To be fair - it was only 1 project so my experiences are limited, but I will never try them again - the experiment proved to be way too costly.

Techcrunch said of oDesk:

“oDesk is also unique in that it doesn’t fix the cost of a project, instead charging an hourly rate, which allows the project manager to use the providers as required”

Yeah, it’s unique, but not optimal. Paying per project is FAR better in my opinion. There’s no point in outsourcing if you have to babysit your coders on the progress every step of the way (which would be how you would prevent bleeding too much money via oDesk). I’d much rather pay per project. When the coders encounter technical issues (which ALWAYS happens), you’re not charged for the overtime of fixing them. oDesk is probably good for coders, but not for buyers. Another thing that left me a bit wary of oDesk is that coder reviews were almost all very low - it should probably have raised a flag for me.

If anyone else has outsourcing experiences they want to share, please feel free.