It Could Be Worse

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

The wi-fi is pretty clogged, so I’ll cut to the chase…