Ada Lovelace Day

About The Authors

Suw Charman-Anderson

Suw Charman-Anderson

Suw Charman-Anderson is a social software consultant and writer who specialises in the use of blogs and wikis behind the firewall. With a background in journalism, publishing and web design, Suw is now one of the UK’s best known bloggers, frequently speaking at conferences and seminars.

Her personal blog is Chocolate and Vodka, and yes, she’s married to Kevin.

Email Suw

Kevin Anderson

Kevin Anderson

Kevin Anderson is a freelance journalist and digital strategist with more than a decade of experience with the BBC and the Guardian. He has been a digital journalist since 1996 with experience in radio, television, print and the web. As a journalist, he uses blogs, social networks, Web 2.0 tools and mobile technology to break news, to engage with audiences and tell the story behind the headlines in multiple media and on multiple platforms.

From 2009-2010, he was the digital research editor at The Guardian where he focused on evaluating and adapting digital innovations to support The Guardian’s world-class journalism. He joined The Guardian in September 2006 as their first blogs editor after 8 years with the BBC working across the web, television and radio. He joined the BBC in 1998 to become their first online journalist outside of the UK, working as the Washington correspondent for BBCNews.com.

And, yes, he’s married to Suw.

E-mail Kevin.

Member of the Media 2.0 Workgroup
Dark Blogs Case Study

Case Study 01 - A European Pharmaceutical Group

Find out how a large pharma company uses dark blogs (behind the firewall) to gather and disseminate competitive intelligence material.


free page hit counter



hit counter script


All content © Kevin Anderson and/or Suw Charman

Interview series:
at the FASTforward blog. Amongst them: John Hagel, David Weinberger, JP Rangaswami, Don Tapscott, and many more!

Corante Blog

Wednesday, February 8th, 2006

FoWA: From web site to web application - Cal Henderson

Posted by Suw Charman-Anderson

Works at Flickr. Ten things that have been learnt from Flickr than can be applied to other web apps. Ways to move from a web site to an app. Not very geeky. Not going to talk about MySQL and nerd stuff.

Flickr

Is awesome. Photo sharing app. Has tags. Has an API. All these Web 2.0 buzzwords. Obviously there’s been the Web 2.0 conference for a couple of years. Has taken off as a term. Lots of people will be talking about what web 2.0 means whether they say it or not, and trying to explain some of those principles. It’s nothing really, just a name for a tech that’s been around for a while.

Flickr is going to be 2 on Friday. Big party in San Francisco with cake. All welcome to go.

Flickr has 2m users, who are very passionate. Passionate users are important to Flickr, but the developers who built it who are also passionate. People don’t start a business to make money. you do it because you care about what you’re doing. BNy having passionate developers you get passionate users.

have to start from a pov where you care about what you’re building.

With Flickr, there’s a difference between what users want and what they need. People didn’t necessarily want the things that Flickr built, but maybe they needed it. We thought about feature that people needed first and foremost. You don’t listen to what your users say because they will tell you what they think they want. You have to watch what users do and look at their behaviour to understand what they need not what they say they want. If you give them what they need you’ll make them passionate.

Collaboration

First of the ten things is collaboration. At the beginning of Flickr, before Flickr, there was Game Neverending, which was a realtime MMP game, based around a realtime engine. Flickr was built on the same tech - massively multiplayer photosharing.

Very much like a game - social network, friends list, etc. Already a load of photo site, not a new tech. That’s not a big deal. What is a big deal is sharing your photos with your friend. Very bottom up, is social network.

Create network effect, by create incentive to add people to the network, so people add value by encouraging others to sign up.

Collaborative metadata also core. Tags, notes, great, but if i can add tags to others, then that’s collaborative metadata. More uses than just pointing out things you missed.

Aggregation

A lot of web apps where you upload your own data would all be siloed into users, a ghettoised space. So huge collection by data, but instead of showing by user, show by other ways, e.g. latest photos. Loads of interesting slices of the data. So think about the whole bunch of photos as one big blob, can slice by tag, by geolocation, relation to other tags, interestingness etc.

Open APIs

Many apps have open API, but what’s the point? We needed it for our own development, for building in throttling and abuse protection etc., so why not let other people use it? Had a bit impact early on with it.

Whole tonne of value in just pushing out read data, without exposing your system.

Started build sites, then web apps, now web services. We can allow other peopel to build our interfaces, and allows othe rpeople to do really interesting things, stuff we hadn’t thought of, wouldn’t have had time fork, or which sounded insane.

Something really cool is that people built a game called Fastr, multiplayer game with a series of photos and you have to figure out as fast as poss which take the photos came from. It’s really cool, but there’s no reason for usto have built it.

If you don’t provide an API, people will just scrape data, so it makes it easier for you and them.

Clean URLs

Getting very popular in Web 2.0. Core reason is that you don’t need to expose the core workings of your system in your URL. Use mod_rewrite under Apache. So the URL doesn’t have to point to a file name, so just translate from file name to URL using mod_rewrite. Core to Flickr URL.

The URLs don’t reflect the folder structure at all, so none of the URLs map to physical part of the disk. But that’s good because they are human readable and they are guessable. If you can guess the URL to a page, then people can get around fast.

Sometimes we’ll find we’ve removed a link from the nav, though, and never realise because the developers always type in the URL.

URLs can’t change. If they point to one resource now, they have to point to that resource forever. When we started Flickr we picked some really bad URLs, but we can’t change them because people have used those URLs and you can’t break those links.

This was a problem when scaling. When the URL scheme was changed, have to support the old URLs forever, because you can’t have them break for people.

AJAX, been around for a while. Worst name ever. Asynchronous Javascript And XML. Not always about XML or Javascript, because you could write an AJAX-like script in VB if you wanted. But the Asynchronous bit is important.

After you’ve loaded a Flickr page and you want to add a tag, the box appears without the page reloading, and when you submit it the page doesn’t need to reload either.

Need strong API so that it can be accessed via AJAX. It’s used primarily to streamline interactions that you already have. E.g. keeping the tags on the same page instead of having to go to a new page to add them in. AJAX saves a bit of bandwidth, stops page reloading, don’t lose context etc.

Also use it for creating new experiences. Not seeing this so much on the web yet, but we build self-contained apps in AJAX which have no way to address in to them.

Unicode

Internationalisation comes first, and localisation later. Important thing to consider is whether you want basic international support from the beginning. E.g. do you store all your data in unicode?

Usual use is to store, present and receive data in UTF-8. Some apps use UTF-16.

Desktop integration

Or platform integration, because your platform isn’t necessarily a desktop. Need to move interactions out of the browser. Most of this is grounded in APIs.

Bunch of desktop apps which work with Flickr, e.g. the upload app. Some tasks are crappy on the web, especially uploading photos, and especially more than one photo. Desktop app allows people to perform tasks that would be difficult, suck or just be stupid, in a browser.

Not just desktop apps. Also possible to do browser apps, such as bookmarklets.

More complex platform integration, e.g. toolbars or dialogues into the browsers.

Also integrating the app with email. Everyone has email, and email is integral to the way people interact online, but we don’t often think about building it in to a web app, e.g. to send email to our system as well as receive it. Difficult to get a photo off a mobile phone, but most can email, so as soon as Flickr could accept photos via email then that’s an uploader for every phone.

Also, simple notification emails to draw people back to the system.

Mobile

Will become the most important platform. Heard this for the last five years. You probably remember WAP and how influential that was… but there are some standards so you can build stuff, and so some people will use them. But they usually all support XHTML Mobile, quite a sensible standard.

Build small apps for mobile devices using XHTML Mobile will work on most phones.

People used to think that it was about creating a smaller logo, but that just doesn’t work. Can’t have more than a couple of lines of text and expect anyone to interact with it. It’s not just a case of re-presenting the same content using a different format. Need to think about what you’re presenting. Needs to be snappy. Think about stuff you wouldn’t want to do on the website, maybe. But not all data is suitable for mobile devices. Need to think in small chunks.

Open data

Import and export of data from systems we build. Export through RSS feeds, but can only get 10, 15 or 20 most recent photos. But doesn’t give a mechanism to get a few hundred out of Flickr. Provide a method to get all their data out, or to import everything in from another app.

If you give people the feeling that they can leave at any time, they are more likely to stay.

It’s not just primary data that’s important. People may already have a photo back up because they upload it from somewhere. But they don’t have the metadata, so what’s important are the notes, tags, comments etc. and getting some sort of local back up. That’s done through the API.

There are 3rd party services that back up your photos to a DVD and then sell you the DVD. Makes people feel safer.

Open Content

Previous to Flickr, a lot of web apps that stored data, once you uploaded your data, they own it. Still the case with Google Video, and other photos sites - they can sell it, use it, do whatever with it because they own it. Flickr does not own their user’s data. Allow users to use Creative Commons licences if they wish.

Through the open APIs, open data, open content, and allowing people to reuse and remix and use the data for interesting purposes. There’s a video someone did with CC licensed photos, blog.flickr.com, and wrote a song about it.

All photos used in presentation were CC’d, and attributed in presentation, which is online at http://iamcal.com/talks

Email a copy of 'FoWA: From web site to web application - Cal Henderson' to a friend

EMAIL THIS ENTRY TO A FRIEND



Separate multiple entries with a comma. Maximum 5 entries.



Separate multiple entries with a comma. Maximum 5 entries.





E-Mail Image Verification

Loading ... Loading ...

3 Responses to “FoWA: From web site to web application - Cal Henderson”

  1. hodgers Says:

    Great notes; thanks for sharing.

    It’s amazing how many of those ten things are just plain ignored by industry people all the time (particularly the clean URLs).

  2. Andrew Garrett's Scroll of Emptiness Says:

    Just some notes from a conference I wasn’t at.

    More for my own future reference than anything else, but I know some readers will find this osrt of stuff interesting.
    Building a webapp on a budget. Not a generic webpage, not just an app - a Web Application Business - in this case, Dropsend. Came i…

  3. abdul Says:

    “When we started Flickr we picked some really bad URLs, but we can’t change them because people have used those URLs and you can’t break those links. ”

    Any body now what “really bad URLs” he is referring to?