• Flickr is awesome! It certainly is…
• Web 2.0 – kinda awesome…
• Flickr 2.0 is 2 years old on Tuesday!
• About 2 million users – many passionate ones
• The developers are passionate about what they do
• Passionate developers make for passionate users
• User wants vs user needs (recurring theme here…)
• Don’t listen to your users – they say what they want but don’t really want them
• Give them what they need and they’re more likely to be passionate

10 things:

1. Collaboration.

• Flickr used to be a MMORPG, but became MMOPS (Massively Multiplayer Online Photo Sharing)
• Putting photos on web sites isn’t new
• The social network sharing is, though
• Collaborative metadata
• Add tags to my own photos, but also to my friends’

2. Aggregation

• Slice the data in interesting ways
• latest photos from everyone, from your contacts etc.
• slice by tag, geo-location, “interestingness”

3. Open APIs

• web services APIs – SOAP, REST, XML-RPC etc.
• What’s the point? They needed it for Ajax-based apps. Eating. Own. Dogfood
• Do read-only stuff first: RSS etc
• Do read-write later – provide API and data-storage, let others build the UI. E.g. Fastr – a game.
• If you don’t provide an API and people want your stuff, people will screen-scrape instead.

4. Clean URLs

• No need to expose the guts of the app anymore
• Expose the logical structure from the POV of the user
• mod_rewrite under Apache is the easiest way (maybe…)
• URL hacking is an alpha-geek thing to do, but people do it.
• They mustn’t change. If a URL links to a resource now, it should link to it forever.

5. Ajax

• “remote scripting” / “remoting”
• Could really be called ‘A’, as it’s not necessarily about XML or even JavaScript, just asynchronous requests.
• All of the Ajax on Flickr uses the Flickr web service APIs

6. Unicode

• i18n – comes first, l10n comes later

7. Desktop integration

• All happens through the APIs
• Not just desktop apps, browser apps too e.g. bookmarklets
• Interaction via e-mail – great for uploading from mobile phones

8. Mobile

• “next year – the year of the mobile” – said every year since year dot
• Modern phones use decent browsers though, which supports XHTML-MP 1.0
• Still limited by small screen size, so rethink the content and the interface, not just re-present the same content as the desktop browser site
• Still limited by small screen size, so rethink the content and the interface, not just re-present the same content as the desktop browser site

9. Open data

• Import and export of data
• RSS gives me the latest 10, say, but doesn’t provide access to the entire dataset
• The API lets them do this
• The more you make it easy for people to leave, the more they’re inclined to stay

10. Open content

• The data is owned by the user, not by the service provider
• Various Creative Commons licenses can be applied to define how other may use your stuff

• 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
]]> http://www.timandkathy.co.uk/journal/2006/02/08/joshua-schacter-delicious-what-weve-learned/feed/ 0 http://www.timandkathy.co.uk/journal/2006/02/08/liveblogging-carson-workshops-summit/ http://www.timandkathy.co.uk/journal/2006/02/08/liveblogging-carson-workshops-summit/#comments Wed, 08 Feb 2006 10:11:30 +0000 Tim http://www.timandkathy.co.uk/journal/2006/02/08/liveblogging-carson-workshops-summit/ The wi-fi is pretty clogged, so I’ll cut to the chase…
]]> http://www.timandkathy.co.uk/journal/2006/02/08/liveblogging-carson-workshops-summit/feed/ 0