Wednesday, February 08, 2006

Notes from Josh Schachter's Presentation

Josh Schachter of just finished giving his opening speech. Some nice insights in there that brought a few wry chuckles from the audience. Here's my notes:


  • Browsers suck.
  • You will spend a vast amount of time trying to cater for every browser version under the sun.
  • You will try to plan for scaling - don't bother! Whatever you predict ahead of time will turn out to be wrong.
  • handy tips about DB setup
  • try to partition your db to get maximum load-balancing across disks, machines, etc...
  • you can configure your DB table indexes to only index part of the table - e.g. if viewing items for a tag, no-one is going to go to page 150,160, etc...
  • all this scaling is necessary because people will come out with all kinds of weird stuff that you never would have thought of, that will break your app in all kinds of ways that you never thought possible.

  • tuning Apache can be just as important as tuning the DB.
  • put a proxy IN FRONT of Apache, to get e.g. images coming from one server, RSS coming from another, main app coming from another, etc
  • make your APIs AS EASY AS POSSIBLE to use
  • SOAP & XML-RPC are quite heavyweight - take time to set up
  • has an incredibly simple XML API - you can make a command-line script to do it => lots of people use it.
  • giving everything a unique id might not be best for scaliability
  • don't expose internal ids to outside world, especially if sequential - because some idiot is going to try to script a GET for every single possible ID to try and scrape your db!
  • build features that people will actually USE - rather than what they ask for
  • always ask WHY they want a particular feature. That way you get at the core of the problem.
  • there are lots of really poorly-written RSS readers.
  • caching is vital
  • design your URLs according to the usage pattern of the site
  • keep your framework hidden
  • people will surprise you with what they try to do
  • do you ignore it, block it, discourage it, or embrace it?
  • build something to solve a problem that YOU YOURSELF have
  • otherwise someone else who does have that problem will be more passionate than you about it, so they will do a better job than you.
  • Every day you don't have something out there in the world, that's another day that you're not picking up users, your users are not getting other users on board, you're not learning anything.
  • => release early, release often
  • As community grows, bias drifts - most popular is not as interesting as it used to be, due to averaging out
  • figure out a way to either keep things on topic, or fragment the attention
  • people will always try to spam you, and use your service to spam others.
  • any "most popular" or "hot" list will attract spam
  • figure out ways to cut off the easy routes to that
  • DON't give spammers an immediate error message.
  • if you cut people off, don't tell them - let them stay scratching their heads
  • if you tell them straight away, they'll know, and they'll try another route
  • The value of tagging is in the attention - you saw this and you thought it was worth saving and this is what you thought it was about. THAT's what creates the social connection - you saw this and thought it was about X, someone else saw the same thing and thought it was about X (or Y)
  • Any automatic tag generator is kind of defeating the object.
  • Make people do the minimum amount of work - but always SOME work

  • Why are users there on your system? What do they get out of it?
  • They are selfish - they're in it for them
  • Ask what the app does for users? What's in it for them?
  • Make the userbase that you already have, want to bring others into the system.
  • If you spend a lot of time building a feature that nobody uses, that's wasted time
  • Be careful about where you expend your effor
  • Monitor everything, put numbers on everything
  • If a user is using something in week 1, are they still using it in week 5?
  • You want to measure how people are reacting to features, implementation
  • delicious has no rating system - why would you bookmark something that's bad?
  • Make sure the system you're building - in terms of look, feel, behaviour - matches your users
  • delicious did two days of user testing with a one-way mirror - it threw up big surprises
  • don't give people a listof todo's - they have vastly different behaviour when they do that - not like real-world usage at all
  • let people wander off on their own as they would do in real usage
  • speak the user's language
  • delicious is about "bookmarking" - but most people didn't know what a bookmark was. They called them "favourites" because that's what IE calls them
  • over half his users didn't understand it
  • don't make users register before they can see stuff
  • give them as much functionality as possible before they have to sign up
  • even let them use it as an anonymous user account (session cookie?)
  • be very careful about when and where and WHY you ask for registration
  • let them wander around and get a feel for the app
  • if you have to ask them to login/register, then make it as short and sweet and painless as possible, THEN TAKE THEM BACK TO EXACTLY WHERE THEY WERE

  • use standard navigation elements / structure
  • don't try to break the mould - people expect things to work a certain way
  • if I put the title underlined in blue, then a summary, then metadata below, then i look like a search engine - with all the implied usage pattern that implies
  • your data belongs to your users, NOT YOU
  • let your users "take their ball and go home" - remove themselves completely including all their data
  • e.g. if a user bookmarked something personal that they might not want others to know about, then they want to remove it completely

  • invade every communication stream you can find to promote your app
  • figure out how to turn every RSS reader into a client app - there's functionality in the RSS reader/feed itself
  • look for viral streams - email / rss
  • desktop apps consume vast amounts of info via http - work out how to use this to work for you
  • how do communities use your system>?
  • don't think of your site users as a community in itself - unless you're actaully trying to build that
  • delicious lets communities use the system, but is not a community itself
  • there's a lot of community dynamics that Josh didn't want - flame wars, battles for alpha male status, etc


David Collie said...

intersting that he mentioned the diffuculty of tags and SQL after your post the other day!

enjoy the rest of the summit, the guy from yahoo was excellent.

Alistair Davidson said...

Yeah, I smiled to myself at that. I thought Tom Coates of Yahoo did a great job too. By the way, I'm by the hall entrance in a brown shirt, typing this on a big red laptop if you fancy saying hello....

david collie said...

sorry alistair, haven't got back on the net til I read this til I got home five mins ago!

was an excellent conference and given a lot to chew on.

couldn't stay til the end of the conference as flight to catch and was leaving just a few questions into the panel session... course as I left the hall I heard your question getting read out! Wasn't about for the answer tho :(

anyways, sorry I missed you and keep up the blog work, always a pleasure to read :)

Alistair Davidson said...

Cheers David - shame we missed each other, maybe next time... Was it the question about re-engineering that you heard? Cal's answer was quite reassuring, actually - "Refactoring takes place about every half hour" :)