Joshua Schacter - del.icio.us: what we've learned
- Browser inconsistencies
- Scaling - SQL isn’t great under heavy load
- Think beyond one web server, one db server
- Abuse
- “Idiots are a lot smarter than you”
- Wait to see what breaks before you fix it
- Apache
- Know it inside out
- Put a proxy in front that isn’t apache - helm? - to add throttling etc etc
- Images on a separate server
- RSS on a separate server
- Use throttling - mod_throttle doesn’t work very well…
- APIs
- Built in from the start, because the developer needed it
- Greatly encourages adoption
- No lock-in - the user owns their data
- No API key in del.icio.us - low barrier to entry
- Hundreds of plugins have been created
- Identifiers
- Don’t expose the internal ID, especially if computer generated, or people will try and programmatically hammer & scrape the service.
- Features
- Don’t add features that exist elsewhere - e.g. messaging
- Build features that people will actually use, not what they ask for (what they need, not what they want)
- RSS
- important - the native way to describe a list of links
- put them everywhere you possibly can - (msk note: PWA needs RSS!)
- Understand caching & headers, the “if not modified” header
- del.icio.us has more RSS traffic than HTML & API traffic, due to poorly-written RSS readers…
- URLs
- make ‘em simple
- hide your implementation
- design them for the user, not the developer
- Surprises - expect them
- Passion
- del.icio.us started from a text file of links - 25,000 entries
- next step - a single-user db-backed system
- then thought “maybe other people would like to use it too…” del.icio.us was born
- don’t go looking for problems to solve - solve your own problems that you’re passionate about
- Release
- Don’t go closed beta, be open!
- Get passionate users using your app quicker
- Attention
- “The daily popular”
- Aggregation of attention works for small groups
- Less useful when the population of the app grows larger
- But…you can aggregate by tag
- Spam
- “attention theft”
- “social software is that which gets spammed”
- No top 10 on del.icio.us - not very interesting
- If it were there, it would be a spam-magnet, people trying to get to the top of the list
- Don’t provide feedback - let them think things are still working. No error messages to give the a clue that they’ve been rumbled.
- Tags
- It’s not about organisation, but about UI and recall by the user
- Not all metadata is tags
- There’s a bit of difficulty involved in adding a URL to del.icio.us, but not too much. Don’t make it too easy, nor too hard.
- Beware librarians! Don’t try to impose a vocabulary/taxonomy.
- Motivation
- Make it useful for the user in itself
- Make it so the users want to bring other users into the system - evangelism ;)
- Effort
- Don’t spend time building features that no-one will use!
- Measurement
- “Intuition is guesswork backed by numbers”
- Measure the system itself
- Measure behaviour rather than claims
- Testing
- User-acceptance testing
- Test that it matches the users
- Don’t assign people goals and make people do them
- Language
- Speak the user’s language
- Bookmarks only make sense to Netscape/Firefox users - IE users speak “favorites”
- Registration
- Make as much functionality available without registration as possible
- People are wary of spam & marketing
- Short and sweet reg, then send back to whence they came…
- Design grammar
- emulate the structure of the web world out there - don’t deviate from established conventions too much
- Morals
- How users are treated
- It’s users’ data, not yours
- Many systems don’t allow account deletion - it’s good to allow people to jump ship if they want to.
- Deleted data should be really deleted
- Infection
- zero-dollar promotion
- totally word-of-mouth
- RSS important
- E-mail not so much - you don’t want to be seen as a spammer
- “viral vectors” - umm? RSS, iCal etc etc? Bzzt.
- Communities
- There’s no community in del.icio.us in the traditional sense
- Saves having flamewars etc.
- Enable communities to use your system without providing an actual community