Wednesday, February 08, 2006

Joshua Schachter of del.icio.us

Live notes from The Future of Web Apps Summit JS is talking about what they've learned in building del.icio.us Browsers - quirks, headers, caching, lots of pain Scaling - Don't do it! Unpredictability of scale problems (this gels with what 37 Signals have said). Set up a monitoring system for out of hours problems. Selective indexing. Caching wherever possible. Latency is ok in places - figure out where this is and how much. Understand your database intimately. Abuse - Idiots are smarter than you. Wait to see what breaks before you fix it Apache - Tune, use a proxy, split up stuff between servers, throttle. APIs - JS built API early to bring data in, tech 'priesthood' need this for long-term security. Make it easy so people use it a lot. No API key in del.icio.us. Identifiers - Don't expose unique db id - prevents scraping entire database from computable ids. Features - and feature requests. Features (included and excluded) determine how people think about system. Don't duplicate features available elsewhere - messages as example of duplicating email. Get to the bottom of feature requests - why is something being asked for? Solve the problem rather than fulfill the request. RSS - everything that could have a feed should have. Understand headers, caching etc. 60% of RSS traffic is requests to see if something has updated. URLs - keep simple, don't do session ids in URLs, don't expose workings of system. Expose some functionality via URL. Surprises - watch for what people do and determine whether to amplify or supress. Passion - solve a problem you have. You will understand the problem and be passionate about things. It's inexpensive to build things, and even a niche problem is acceptable because of infrastructure for revenue, advertising. Release - Early and update often. Don't be closed and quiet. Each day behind losed doors is a lost opportunity. Attention and Attention Theft (Spam) - Cut off systems whereby people become driven by ratings and figure out how to beat system. Usefulness of error messages in people doing this.. so don't do them. Tags - Useful for recall, ok for discovery, terrible for distribution. Tags are not definitive. Motivation - why are users there? Expect selfishness. What is the payoff for the user? Make the userbase you already have want to bring people in. Measurement - intuition backed by numbers. Put numbers to everything. Measure the system itself and behaviour rather than claims. Testing - Labs or even Starbucks testing :-) Don't give them goals, tast real behaviour. Let people figure stuff out and wander off. Language - what are people calling things? Favorites vs Bookmarks. Speak their language. Registration - don't make them register before they see the site, or even use the system. What are they going to get out of registration? They have to see it, not be told it. Fear of spyware etc. Design Grammar - if it's different from the way other systems work understand where you're breaking from this. Everywhere else do exactly what the Design Grammar is and don't move far from this at all. Navigation positions, logo link to top etc. Morals - things are really purged when you delete on del.icio.us (makes API more complex, but important) Infection - vectors of word of mouth promotion. How to enable evangelism. Invade every communication stream you can. Look for viral vectors - rss, email, desktop apps which handle http etc. Community - be careful unless you're actually building a community. Communities exist elsewhere and enable them to use it without forcing them to use it. Questions for JS later.

Technorati Tags: , , , , , , , , , , , ,

0 comments: