Eric Farkas

A while back I found a great set of notes that were taken at a presentation by del.icio.us creator Joshua Schachter at the 2006 Future Of Web Apps summit. They were really helpful to me in my growth as a developer. Unfortunately the notes are no longer available at the original URL, so I've taken the liberty to reproduce them here.

Again, these are not my own notes (credit goes to Simon Willison) but I want to preserve them for posterity's sake. If you know of an "official" location for these notes please let me know.

• Browser quirks. CSS/JavaScript/rendering. IE caching.

• Scaling: avoid early optimization. SQL doesn't map well to these problems - think about how to split up data over multiple machines. Understand indexing strategies, profile every SQL statement. Nagios or similar for monitoring.

• Tags don't map well to SQL. Sometimes you can prune based on usage - only index the first few pages for example. This keeps indexes small and fast.

• Some latency in the system is OK - work out where you have leeway, e.g. RSS feeds can fall a few minutes behind without anyone minding.

• People are always going to abuse your system (scraping, greasemonkey, etc.)

• "Idiots are a lot smarter than you" - wait to see what breaks before you fix it.

• Learn Apache - tuning can make things a lot faster. Understand headers, mod_rewrite (a dark art). Put a proxy in front of Apache e.g. Perlbal from LiveJournal - one guy on a modem can suck up lots of resources otherwise.

• Images off a different server, RSS from a different server.

• "Save site for offline use" feature in IE is particularly nasty.

• The easier the API to get in and out of, the more people will use it. There's a long tail of smart developers. Stuff like SOAP discourages adoption. No API key = people can play with it faster; drives attention.

• Don't expose your unique id's to the outside world (php?id=1 etc.) People can scrape through everything very easily. This is why del.icio.us uses MD5 hashes of links instead.

• Giving everything a unique ID in the database is a scaling problem in its own right.

• Features: the features you put in are as important as the ones you leave out. There's no "send a note" in del.icio.us feature because e-mail already exists.

• I don't add featues that are available elsewhere e.g. messaging

• When people ask for features, get to the bottom of why they are asking for that exact thing. Solve the problem, rather than doing exactly what your asked for.

• With tags, people ask for "A and B and NOT C or D" - but less than 1% of queries even use more than a single tag.

• RSS important in del.icio.us, because it's a native way for people to access lists (of links). Put RSS everywhere you can. del.icio.us does way more RSS traffic than HTML or API stuff - partly because of poorly written readers.

• Understand the headers - especially if-not-modified.

• Make sure the URLs follow the path of the site. DON'T include session data, drop ugly details that are to do with the system, not the user (.php, .aspx, ?, &, etc.)

• URLs are prime real estate - respect them

• When you chose what to build, solve a problem you have yourself so you can be sure to understand it. Passion counts. It's cheap and easy to build stuff, so other people will be building it too.

• A niche product with a limited audience is still good business (with how advertising and PayPal work)

• Every day that you don't have something properly out in the world (not on an invite only beta) you're losing a chance to gain users. Get it out there ASAP.

• Aggregation is often a focus of attention (latest, most active, etc.)

• As the population gets larger, the bias drifts; del.icio.us/popular becomes less interesting to the original community members. Work out ways to let the system fragment in to different areas of attention.

• "Spam is attention theft" - that's one of the reasons del.icio.us doesn't have a top 10 links of all time - it's an attractive nuisance.

• When you've figured out someone is spamming, don't let them know – let them keep posting and just silently junk their stuff.

• Make users do the minimum amount of work. But make them do something.

• Understand the user's motivation: "You have to understand the selfish user" – user #1 has to find the system useful or you won't get user #2. Systems that only become useful when lots of people are using them usually fail, because there's no incentive for people to contribute themselves. The real trick is to make the user base you have want to invite more people in to the system.

• Manage your effort - be careful where you spend your efforts.

• Don't waste time building features nobody uses.

• Measurement: watch your system intensely: "Intuition is ideas backed by numbers"

• Measure behavior rather than claims. del.icio.us doesn't have stars because why would you bookmark something that was no good? This way people bookmark things that they really care about rather than trying to tell the system things.

• User Acceptance Testing (UAT) is important. Make the system suitable for the people actually using the system. Everybody on the team should see this in action. Labs are great but expensive. If you don't have a lab do ghetto testing in Starbucks. We did one day then two days user testing in a user testing lab.

• Goals skew the results. People don't read, they cram crap in to boxes. Let people wander don't give them tasks.

• You have to speak the user's language. "Bookmarks" are what you call them if you use Netscape of Firefox - most users these days know the term "favourite" instead. Half of his population (? users) didn't know what a bookmark was.

• Don't make users register before they can get in to your site. Maybe even give them an anonymous account to play with. A lot of users want to know what they'll get if they register - especially from fear of giving out email address, spyware etc. You can't tell them; they're not going to read it. You have to show them.

• Use Verbs - doing words - to prompt actions.

• If users do have to register, send them straight back to where they were when they're done. Don't dump them on the homepage.

• "Design Grammar" - if you're presenting a system that's different from how other things work (del.icio.us had novel tags, save your bookmarks to the web) you should still try to reflect the design patterns of the web.

• Morals: You have to develop a sense of morals when you build your system. It's the user's data; it's not yours. Make sure they can remove themselves and their account if they want to.

• Infection: Understand infection vectors for promoting your system. "Enable evangelism". RSS lets you get at users who don't use your system directly. Also think about iCal, M3U - anything that a desktop app can consume over HTTP. Do an inventory to get into every desktop app. possible.