All of this stuff is being recorded and will be made available, for free, after the event. My notes, therefore, and my battle with WordPress’s rich text editor, seems like a bit of a waste of time…

• Design and Web 2.0: it’s all about the rounded corners and gradients
• Blogger may have started the trend
• Outline
  • What is the web changing into?
  • What can you / should you build on it?
  • Architectural principles of Web 2.0
• Web 2.0?
  • Buzzword, conference, new way of thinking
  • Web 2.0 means so many things to so many people though
• Let’s concentrate on a “web of connected stuff”
  • Web at the moment – data silos
  • Now and in the future:
  • A web of data sources, services for exploring and manipulating data, aways that users can act together
  • Web of pages -> web of mashups – > a web of data
• Mashups
  • two disparate data sources, made more useful by being combined with eachother
  • A network effect of services
  • Build on top of what’s already there
  • What you build enhances what’s already there
• Consequences
  • Massive creative possibilities
  • Accel. innovation
  • Competitive services++
  • Componentised services++
  • Money to be made
  • Use APIs to drive people to your stuff
  • Amazon is the prime example
  • Better service with less centralised development
  • Use syndicated content as a platform
  • Turn API into a pay-for service
  • It’s no good to be a web isolationist these days
• Choosing what to build
  • What can I build that will make the whole web better?
  • Add value to the aggregate web
• Architectural principles
  • Data sources
  • Std ways of representing data
  • IDs and URLs
  • Mechanisms for distributing data
  • Ways to interact with/enhance data
  • Financial/legal stuff
  • hackdiary.com‚ Xtech2005
• Good URLs should:
  • be permanent references to resources
  • have a 1-to-1 correlation with concepts
  • use directories to represent hierarchy
  • not reflect the underlying technology
  • reflect the structure of the data
  • be predictable / guessable / hackable
  • be as human-readable as possible
  • be – or expose – identifiers
• Core types of page:
  • Destination page
  • A core first-order concept and its subordinate info.
  • List view page
    • A slice of your data used to navigate between first-order concepts
  • Manipulation interface
  • Interface for batch manipulation of first-order concepts

“Ten reasons to love Web 2.0″

• 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

• 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