These are the notes I took at Joshua Schachter’s talk at the Future Of Web Applications (futureofwebapps) conference, in London on Wednesday 8th February 2006.

Lars Ploughman posted a great mind map of the talk.

• del.icio.us started as a text file of 25 000+ links on Joshua’s computer. Each one had a descriptive sentence, that got shortened down to a single word -> a tag. When building an application, it must solve a problem you have. You need passion.

• Cross browser compatibility is difficult

• Monitor your app.

• Optimize: Add database indexes. Cache. Monitor user behaviour to find out what they do. This allows you to optimize certain parts – for example no-one ever goes to search results page 100. Figure out where latency is acceptable and use that; for example the RSS feed can be a few minutes behind the live site.

• Aggregation of attention is interesting: What are people looking at, etc. Top 10.

• Your application will be used in unexpected ways, so react to it. Monitoring helps.

• Learn the ins and outs of Apache, including mod_rewrite.

• Put a proxy in front of Apache – for example pound or perbal.

• Build an API, and make sure it is easy to use. Avoid SOAP, CORBA, etc. Stick to simple XML. The API should allow uses to save their data offline, to script your application, etc.

• Don’t expose internal ids, especially if they are consecutive. Otherwise people will try and iterate over them to get all your data, and overload your site.

• Don’t add features that already exist elsewhere. For example your site doesn’t need a messaging system – use e-mail instead.

• Add features that people will use; this is not always what they ask for. Get to the root of each feature request – what exactly is the user trying to do, and is there a better way of doing that than what they asked for.

• RSS is the web’s native style for a list of links. Put RSS everywhere you have a list. It’s another way for users to get data from your system. del.icio.us has more RSS than HTML traffic.

• Sensible URLs: They get passed around, bookmarked, mailed, etc. They should be user-friendly, not developer friendly. Don’t include session ids, or implementation specific details on the URL.

• Release early and often. No closed beta.

• When you block spammers, don’t let them know. Don’t display an error message, or change visible behaviour. Otherwise they start trying different methods.

• Understand user motivation. The application has to be useful for user number 1. Users are selfish. Ideally people use the system and evangelise it. They come for themselves not for the data others created.

• Measure how people react to new features and how long they keep using a feature. Rely on what people do not on what they claim.

• Do user acceptance testing. Everyone involved in the project should watch this. If you can’t afford a test lab (with a two-way mirror for the team to stand behind), do ghetto testing: Buy people coffee in the local Internet cafe and show them the application. Don’t give them goals, just let them be normal users.

• Speak the users language: Only Netscape / Firefox users call them bookmarks – IE users call them favorites.

• Don’t force users to register. Or if you really need to, delay it as long as possible. Give as many public features as possible. Make registration short and afterwards send them back to where they were.

• Understand the Internet design grammar and choose when to follow it and when not to. For example clicking the logo in top left corner goes back to the home page.

• Remember that the data is not yours, it belongs to the user, and you’re just borrowing it. Allow users to export their data, delete themselves completely from the system, etc. Having an API helps with this.

• The clients to your web app aren’t just browsers. Think of everything that can take data from your server: RSS readers, iCal clients, Excel, widgets (Konfabulator and Dashboard) etc.

• Build a tool, not a community. Unless you are explicitly trying to build a community.

  http://del.icio.us