Automatic Wisdom

21 June 2005

Flickr is a widely successful online photo sharing site, and it’s success can teach us desktop application developers a few lessons. I’m going to be writing from the point of view of a mac software developer, but most of these points are relevant for anyone doing application development. Also, Flickr is by no means the only site or company that we can learn from, the web development world is moving pretty fast at the moment, so keep your ear to the ground!

So, to the points:

Rapid Updating

According to Cal Henderson (via Tom Coates’ post ‘Cal Henderson on How We Built Flickr…’ ) on a “good day”, Flickr releases a new version every half an hour! Traditional desktop software, in comparison, at best releases new versions maybe once a month for smaller software, going up to years in the case of programs like Microsoft Office.
This goes back to the days where software came on physical media (floppy disks!), and is really a very outdated practice that is way past it’s sell by date. However, there is a lot of mindshare and “automatic wisdom” behind the idea; “It’s what we’ve done for years.”; “It works well.”; “Why change it?” etc.

From a technical perspective, with the vast majority of uses (if not all users) having internet access, why not move to an rapid update model in desktop software? When you’ve added a new feature, why wait till the “next update” in 3 weeks time when you can roll it out to your uses straight away? Many apps currently having a version checking framework, allowing users to be notified straight away when updates are found – it wouldn’t be hard to extend this to automatically download new features on the fly, transparently to the user. It used to be that with every system update we used to have to restart the computer; we’ve overcome that so why not abandon restarting our apps when they update? With a good enough, plugin-based architecture, this becomes fairly easy.

Quicksilver , does a lot of this already, with plugins (which make up most of the app) being downloaded and installed by the app itself. However, the main functionality of the app isn’t based this way, with versions still being released on a monthly (ish) basis, so it could go a bit further.

Another issue with rapid updating is with testing and bugs. Now, this is a bit more of an issue with a desktop app then it is with a site such as Flickr, as there is much more chance of data loss. However, with proper software development methodologies, and using things like unit testing and built in test cases, major bugs can easily be avoided. Also, the benefit of the updating turnaround can be found here to: if you do introduce a bug, you can roll out a fix instantly.

The best way of achieving this, I think, would be to utilise some form of “push” system – pushing the updates to the user as and when they are available, as opposed to having daily/weekly schedules. Obviously, the user would have to have control over whether they want to update, so just pushing a notification to the user would be the best way. They could then click one button to download and install, or first view the changes in the update. A nice feature would be to allow rolling back to the previous version, which would be quite achievable with a plugin based system (i.e. download new plugin, backup old one).

The most important aspect that this system would allow is rapid reaction to what your users want, which leads us to…

Listen to Your Users

When Flickr first launched, it was really not much more then a nice looking flash app. However, if you go to Flickr today, it takes a bit of digging to find any major flash bits – the main interface and most used pages are all html, with a simple clutter free appearance.

Why?

Because they listened to their users.

The flash aspects of Flickr are quite nice, but they are quite secondary to the main experience, but this is all they launched with. After launch, they (producing a new version every half hour, remember) iterated through many different features, based on the feedback they were getting from their users.

Now, this is all very well and good, but what if your users have “dumb” ideas? It doesn’t matter. As long as too much time isn’t invested in an idea that doesn’t end up working, there is no harm in trying – and remember, your users can test it out straight away and tell you if it doesn’t work (and you can fix it just as fast).

Also, if your users aren’t you (in other words, if you are developing anything other then a tool for programmers), no matter what you think, you don’t know your users as well as you think you do. So pay attention to what they tell you.

Of course, it’s all very well saying “pay attention to what your users say”; what if they don’t say anything at all? You have to make sure there is communication between you and your users, so make it easy.

How to make it easy for your users to talk to you (and make your app better):

Firstly, make sure you have any email address in an obvious place on your site, and in your app. Make it clickable.
In your app, build in a “Feedback Tool” so that they can just type a quick message in-app, and hit send.
If your app crashes, make sure you have a bug reporter pop-up, so users can send you bug reports (If you don’t want to build one (and you’re a mac developer), use Zonic’s BugReporter ).
Have a company blog on your site, and update it with any upcoming features, current bugs or any other related news. This is probably the most important point, as it lets your users converse with you about your product.

Play Nicely With Others

One of the main attractions to Flickr is the ability to get at the data contained in Flickr, and do cool stuff with it. They have a set of open API’s, available to anyone, and let people do whatever they want with the data.

Now, earlier I talked about having a flexible plugin architecture, and this plays right into it:

Make your plugin architecture open.

Let anyone do anything they like.

What this means is that people – other people – can add value to your product, without you having to lift a finger. How cool is that? All you have to do is to be open, open about how your program works inside, open about what changes you make in the future and open about how to go about working with your program. All you really need is a fairly stable API for your plugins, and some decent documentation about, and then just let people do what they want.

This point can also be turned the other way round; make sure your users can interact with other users. The tagging system that Flickr has, where anybody can tag (almost) any picture, combined with the ability to comment on any picture are some of Flickr’s best features – the social aspects can really add value and bring in users to your software, so don’t overlook them. Make sure you have a user forum, make sure users can share data easily and see if you can find a way to build a community around your software. See if you can enable collaboration using your software (for example, SubEthaEdit’s Bonjour multi-user editing feature), or let users interact with each other (even something as simple as iTunes’ library sharing function).

And lastly…

Be Friendly

A couple of days ago I received an email from Flickr (when I subscribed and ticked “yes” to their mail list, it wasn’t automatic) and it was signed “- The Flickroobies”. In this day and age, a little bit of friendliness goes a long way, and it costs nothing. It’s a little thing, but helps build a community around your product, and helps get the word of mouth (which is probably the only effective form of advertising) going.

So, in Summary…

Update quickly, don’t wait to coalesce features into a point release, do a release per feature.

Listen to your users; the customer is always right, especially when you think they’re wrong.

Be open, and let people do what they want with your software.

Be friendly. Why not?

Of course, the one issue I haven’t tackled is: how to make money like this? For this style of development, the user will inevitably be using “beta” software (in fact, Flickr has a (possibly permanent) “beta” on their logo), which possibly means they will be less inclined to pay for it. I’m not really sure of the best method to combat this, but I would be inclined to either go for a “lite” and “pro” division, so that if people don’t like the possible beta-ness they don’t have to pay (and then get hooked and pay anyway), or possibly some form of subscription model (as if you don’t have true “versions”, how do you get people to upgrade?), so you get – for example – 2 years of updates for £20, then another 2 years for £10 (or whatever).
Also, NetNewsWire recently went though an extended rapid-ish release beta cycle, and throughout that they were selling upgrades to the new version – a similar model to what I’m suggesting, and (from what I’ve heard) quite a few people bought upgrades before it came out of beta.

So, there we go: add features, get them out, listen, repeat, make money. Simple, really?

From: Articles

21 June 2005