Cal Henderson, Flickr ===================== "From web site to web application - Ten reasons to love Web 2.0" Web 2.0 - a name for a bunch of technologies that have been around for longer than the term. Flickr has a couple of million users, some of whom are passionate. Passionate users are important, as are passionate developers. Typically people don't start businesses to make money. You have to care about building an interesting product that people like. People didn't necessarily want the features that Flickr was building, even though they needed them. Don't listen to what your users say - they'll tell you what they think they want. If you give them the things they need, you'll end up making them passionate. The ten things: 1. Collaboration Before Flickr was GNE - Gave Never Ending. Flickr was originally built on the same technology - "massively multiplayer online photo sharing" - so friends stuff was in there from the start (listing who your enemies were was dropped). Putting photos online so you can share them with your social network was the big deal. If I get my friends to use Flickr, it gets better for me and for them. Collaborative metadata (tagging friends' photos) is cool too. One person in a family or social group might be the organised person, so the whole family's photos end up getting tagged. 2. Aggregation Latest things matter. There are lots of interesting slices that can be taken. Slice by user, time, tags, location, relationship to other tags, "interestingness". 3. Open APIs Before talking about APIs: I was talking about APIs in another talk; at the end a Java programmer (bless them) came up and said "surely all programs have APIs". We're talking about web APIs. The original reason for the Flickr API was that they needed it for Ajax-based applications. Later on (since it had throttling protection and so on) they realised they may as well release it. Flickr was one of the first Web 2.0-space applications to do this. Flickr eventually just provides the data and the processing, letting other people build the interface. Example: people built a multiplayer game called "faster", where you guess what tag a bunch of photos represent. All Flickr had to build was the API. It's a mistake to think that if you don't build an API people won't do this stuff - they'll just hurt you more by scraping your pages. 4. Clean URLs Core principle: there's no reason to expose the guts of our application any more. Expose the logical structure instead. The core to this on Unix is to use mod_rewrite and Apache. URLs are not filenames - they don't have to point to something on the filesystem. mod_rewrite lets you translate incoming URLs to whatever you need for the thing to work. Power geeks navigate by hacking the URL. Guessability matters. Downside: you might forget to link to things as the application designer! When Flickr started, made some bad URL decisions (e.g. link to the actual photo file). Originally was flickr.com/photos/12.jpg - really hard to scale. You have to support the old style URLs for ever. Lesson learnt the difficult way. 5. Ajax Previously called "remoting" or "remote scripting" - Ajax is possibly the worst name ever. It's not about XML (it's about asynchronous data). It's not necessarily about JavaScript either - you could use VBScript in IE if you wanted to. XMLHttpRequest is another bad name - nothing to do with XML. Used to streamline existing interactions as well as create new experiences. Ajax is hard to debug; thought also needs to go in to how to still have addressable URLs. 6. Unicode i18n - internationalisation - building the capability in to an application for it to support different locales - different character sets, date formats etc. l10n - the actual translation of your UI. Comes after i18n. Decision: should you build i18n from the start? If so, use unicode - a standard to let you store practically any character in any language. Unicode has millions of code points. UTF-8 is most common for implementation. 7. Desktop/Platform Integration Using APIs to bring the interaction onto the desktop and integrate with desktop apps. There's a bunch of desktop apps that work with Flickr. Uploading files is painful on the Web. Flickr had a PC and Mac upload client from very early on. Bookmarklets are cool too. Soon you'll be able to build chrome in to your apps with XUL and XAML. Email integration is important too. Everyone on the Web has e-mail. It's also a mechanism available on mobile. Letting people send e-mail to the system as well as recieve it is great. Mobile devices can send photos by email! Can also draw people back to the website using email. Joshua talked about not rebuilding tools that already exist; Flickr's messaging system is a bit stupid. 8. Mobile Mobile will "one day" become the more important platform - we hear that every year will be the "year of mobile". Remember WAP? XHTML Mobile Profile is a sensible standard (subset of XHTML 1.0) which is widely supported by phones. Just re-skinning things for mobile phones isn't adequate - they still have rubbish tiny screens. Don't just represent the same content in a new markup language - think about what content you can serve to mobile devices in a sensible way. Flickr might serve up a thumbnail image and the description and that's it. Not all data is suitable for pushing out to mobile devices. 9. Open data Push stuff out and pull things in in standard formats. "Flickr have just been bought by Yahoo!; maybe I should pull my photos out and move elsewhere". If you give people the feeling they can leave whenever they want and take their data with them they'll be more likely to stay. 10. Open content Google Video: if you upload your content, they own it and can put ads on it etc. Flickr says that the user owns it and can't do anything without permission - BUT it allows people to license under Creative Commons. This lets people do all sorts of fun creative things. --- Gareth Rushgrove - http://morethanseven.net/ Simon Willison - http://simon.incutio.com/ Ian Bellchambers - http://www.torchbox.com/ Olly Willans - http://www.torchbox.com/