Delicious

Contributors
	Mark McLaughlin	aim: markmkorn email: mark@mclaughlin.me.uk

Wednesday, 8 February 2006

TITLE OF SESSION: Delicious - Things We've Learned
NUMBER OF SESSION: 1
PRESENTED BY: Joshua Schachter

CONFERENCE: Carson Workshops - The Future of Web Apps | Summit
DATE: 08/02/2006_
LOCATION: Kensington Town Hall, London

-------------------------------------------------------------------------------
REAL-TIME NOTES:
{If you've contributed, add your name, e-mail & URL at the bottom}

INTRODUCTION

Most painful issue - header issues, IE caching, Firefox extensions.
Most problems with SQL... Delicious uses MySQL.
Tags don't map well to SQL.
Cache everywhere possible.
Wait to see what breaks before you fix it.
Put a proxy in front of your server.
mod_throttle on Apache.
API's allow people to adopt and import in, and easy to export from.
Keep your API simple. (REST).
Don't expose external identifiers... people will iterate, abuse, scrape.
Don't implement features that other systems do perfectly well already.
Concentrate on stuff people will use, rather than everything they ask for.
RSS feeds everywhere. - but understand how to cache it properly. timestamps, if not modified etc...
Most of the traffic on del.icio.us is RSS (although partially because of poorly written RSS clients.)
Kill the cruft from URL's (doesn't help anyone other than developers).
Be passionate. Solve a problem you already have.
"Closed Beta"... sign up for information.  Bad ideas.  Get it out there.
Aggregation of attention.  ('Popular' page).
Not all metadata is tags...



set up a notification system, or die.
work out where you can optimise by being lazy.

prepare for abuse -
yr users are more evil than you.
APIs - spring from necessity

Attention
  Keep things on topic or gracefully move into fragments
  
Spam
  lists (top 10, etc) - attractive nuisance

Tags
  not about class - is UI - way to recall things - state of mind when you saved it (the page)
  awful at distribution
  not all metadata is tagged - value is in attention - don't auto choose tags - not helpful for users
  make things too easier --> makes system weaker - make users choose tags, then the system becomes stronger
  beware librarians - drop down list of official tags, bad idea (no kidding!)
  
Motivation
  of users - why are they there?
  base case - expect user to be selfish - user 1 has to find system useful, otherwise no user 2
  build for yourself
  e.g. "social book reviewing" what's in it for me, the user, by reviewing a book?
  
Effort
  watch where you spend it - use it wisely - solve the big problems

Measurement
  watch system carefully - monitor
  numbers on everything - can't measure without them!
  measure system behaviour - features - are they used?
  data in system - measure behaviour
  No need for "stars" why bookmark something that's bad?  You bookmark it or don't.
  
Testing
  User Acceptance - way system looks/feels/works - does it match the users?
  interact with users - discover what they do with the system without your input - unbiased
  Three days of user testing, one-way mirror with team watching.
  Labs are great, but expensive.
  Don't give testers "to-do's"... people don't read, they type random crap. (!)  True...
  Important to prove team's expectations against real usage.

Language
  Speak users language - IE - what is a bookmark??? use jargon at your expense
  Don't create barriers to entry with language.  IE users only know 'Favorites'.
  
Registration
  don't make users reg - allow free stuff - they want to play with func
  let them use system as anon
  save this - use verbs that users understand - make erg short and sweet and take them back to where they were
  What is the user going to get for registration?
  Users are careful to hand over that information.  Let them get familiar first.
  Keep the registration process simple
  Get people back to where they were once they've registered.  

Design Grammar
  if sys is diff - explain it to users, when breaking from tradition, ie menu on top, breadcrumbs
  users get there experience from other websites - so use what they know
  look like a search engine, poeple will expect search capabilities
  Breadcrumb trails, logo for home link in top left.  Don't stray too far from familiarity.
  
Morals
  Develop a sense of morals when building the system.
  It's the users' data - not your data.
  Give the users control of their own data.
  Give the option - take the ball and go home, let them clear their account completely if they want.
  no tombstoning - del is del, data is purged --> makes user feel better (???)
  does lead to a lack of transaction history
  
Infection
  Enable evangelism.
  e-mail is tricky - can appear to be a spammer without meaning to.
  RSS is a good method.  (extra functionality in feeds destined for i.e. Bloglines)
  invade EVERYTHING - (beware of spam)
  "Viral Vectors" - iCal, RSS, podcast - lots of hooks to the desktop via HTTP.
  
Communities
  How do they use your system?
  don't own comm - let them use the system
  It's a tool, the community exist elsewhere.

*** pause ***

Q&A


-------------------------------------------------------------------------------
REFERENCES: {as documents / sites are referenced add them below}

Usability testing - Creative Good, NYC.

-------------------------------------------------------------------------------
QUOTES: {collect nice quotes from this session's speaker}

"guesswork based on numbers"
"ghetto testing"

-------------------------------------------------------------------------------
CONTRIBUTORS: {add your name, e-mail address and URL below}



-------------------------------------------------------------------------------
E-MAIL BOUNCEBACK: 
{add your e-mail address separated by commas for easy mailing of this text}

mark@mclaughlin.me.uk
peter@petercooper.co.uk
chris@randomcat.co.uk
tim@bla.ir
sp@lonres.com
marcusleemitchell@gmail.com
julian.v@virgin.net

-------------------------------------------------------------------------------
NOTES ON / KEY TO THIS TEMPLATE:
HEADLINES
    ... have to be CAPITALISED and stand alone in a line to be recognized
    This differentiates from the text that follows
A _variable_ that you can change will be surrounded by _underscores_
    Spaces in variables are also replaced with _under_scores_
    This allows people to select the whole _variable_ with a simple double-click
A {tool-tip} is lower case and surrounded by {curly brackets / parentheses}
    These supply helpful contextual information.
References should be added as [1] [2] and so forth.
An *emphasis* can be put on a word by adding *stars* around it


-------------------------------------------------------------------------------
DISCLAIMER:
Copyright shared between all the participants unless otherwise stated...
Generic conference template copyright by Tom Coates, tom@plasticbag.org
Additions and Conference.mode by Dominik Wagner, dom@codingmonkeys.de