email: mark@mclaughlin.me.uk
| Contributors | ||
|---|---|---|
| Mark McLaughlin | aim: markmkorn email: mark@mclaughlin.me.uk |
Wednesday, 8 February 2006
TITLE OF SESSION: Building Flickr NUMBER OF SESSION: 2 PRESENTED BY: Cal Henderson 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 "From web site to web application" Hello! Passionate users are important to Flickr. And are created by passionate developers. Passionate developers attract passionate users. Love Flickr don't start business to make money - care about something - get passion make something to solve one of your problems build it for what users need - need to understand their problems first watch what users do Watch user behaviour to determine new features. 1. Collaboration behind it was diff app "game never ending" - Flickr built on same tech - had social network already share photo's with friends - network, create incentive to add friends, encourage Collaborative metadata --> tagging, add tagging to friends photo's usecase --> family, one member is admin, friends tag Predecessor was GNE - MMORPG Flickr was MMOPS massively multiplayer online photo sharing (!). Adding friends/family makes the product better for the end user. 2. Aggregation Traditionally data silo'ed by user or maybe by time. Slice content by tag, location. As many interesting aggregations as possible - tags, geolocation, interestingness think about all photos as one big blog - can slice and dice in various ways - geographical, how interesting it is - can do any sort of slicing Create new views upon existing data. 3. Open APIs Web services API - REST, SOAP, XML Needed it for Ajax first RSS first (readonly stuff first) - allow others to extract Flickr crated API's because they needed them for themselves for AJAX interactions. Move on to write API - people can change the data, so provide the data storage and processing "Fastr" game - built on top of Flickr, utilizing API site > app > service API allows 3rd parties to put together cool stuff they didn't have time to do. -->"Fastr" game http://randomchaos.com/games/fastr/ Don't provide an API: end users will scrape the data anyway. 4. Clean URLs Use them as branding - top of screen, everyone can see the URL and the name of your company Core principle - no need to expose the physical workings of an appllcation. mod_rewrite on Apache. Easily guessable URL's. People will navigate by hacking URL's. take URL and translate it to URL resource, display file (mod_rewrite) have a virtual URL system over the physical folder structure - mapping don't change URL (unless you handle the change in httpModule/httpHandler - can redirect) Immutable URLs. Must be permanent. else future scaling becomes difficult 5. AJAX Async Javascript and XML "remoting", "remote scripting". all about async - do something while the user is doing something else (no page reload) eliminating two-step page actions Saving bandwidth. Don't lose state. all about user experience - build self contained app in AJAX - currently there are AJAX desktops on web 6. Unicode Store data and transactions as Unicode from the start for i18n support. Localisation comes later. store all data and receive it in UTF-8 (std) 7. Desktop Integration - ref. back to api How do we pull interactions outside of the browser - grounded in API's. Flickr Uploadr. Multiple file upload is painful on the web. API's allow tasks that are easier on the desktop to take place on the desktop. integrate browser into the desktop bunch of desktop apps that work with Flickr - upload photo's / file upload desktop app plug into web API (web services) Could build a XUL uploader using browser chrome and UI. Integrate with email - important, everyone uses it, integral to way people use the internet allow people to interact with it - tasks become easier - allow people to use something they are familiar with using existing infrastructure, which people already have It is very difficult to transfer a mobile file - e-mail is supported on most devices. You can upload to Flickr via e-mail - perfect for smartphones. 8. Mobile Will become important platform... (maybe) "WAP is dead". Most smartphones run Opera, Nokia, SEM browsers. XHTML Mobile Profile 1.0.(XHTML-MP) Small apps on mobile devices. Building content for mobile - tiny screens, mobile phones have small screens Create small consumable chunks of information. Don't replicate the full-screen web experience. Cut down on the metadata; repurpose it for mobile devices. not all data suitable to push out to mobile devices 9. Open Data Import and export of data from systems. Export - RSS feeds. give feeling that people can leave - gives them that comfort level - they still own the data - not the app/company Also ability to export not just the photos - the comments, the tags and so on. 10. Open Content Upload to Google Video - they own the content. Also the case with several photo sites. When you upload to Flickr - it still belongs to you, the user. All rights reserved. End user can license the data using Creative Commons. founding principle - user still owns data (see above - 9) blog.flickr.com --> video slides --> http://iamcal.com/talks/ *** pause *** Q&A ------------------------------------------------------------------------------- REFERENCES: {as documents / sites are referenced add them below} Fastr (online game) http://randomchaos.com/games/fastr/ Englaze (Flickr backup to CD/DVD) http://www.englaze.com/ Creative Commons http://www.creativecommerce.org/ blog.flickr.com (Music video made from CC licensed photos) Slides available at http://iamcal.com/talks ------------------------------------------------------------------------------- QUOTES: {collect nice quotes from this session's speaker} ------------------------------------------------------------------------------- CONTRIBUTORS: {add your name, e-mail address and URL below} Levent - lebreeze@gmail.com | purebreeze.com Marcus - marcusleemitchell@gmail.com | marcusleemitchell.co.uk Mark McLaughlin - mark@mclaughlin.me.uk | undercrank.com Chris Stainthorpe - chris@randomcat.co.uk | randomcat.co.uk ------------------------------------------------------------------------------- E-MAIL BOUNCEBACK: {add your e-mail address separated by commas for easy mailing of this text} sp@lonres.com chris@randomcat.co.uk ------------------------------------------------------------------------------- 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