betterton.net

Are you looking at me or the girl in the red dress?

These trees down near the UBS building in the City of London always look a bit disconsolate, although autumn gives them a bit of colour.

Captive audience

This got quite a few nice comments when originally posted on my photoblog, perhaps due to the busker's sheer enthusiasm in the face of next to no passing traffic.

Happy!

Another photo from my photoblog, of my brother and his daughter. Love the mood it captures.

Hove seafront

I'm going to post some of my favourite photos from my photoblog (http://15years.aminus3.com) on here. I particularily like this one because it was one of the first I took with an old Konica 50mm film lens. The ability to adapt old lenses is one of the many benefits of the Micro Four Thirds system I use - it both makes economic sense (my current 50mm cost £10!) and is also fun, in a retro sort of way.

Launch quick and learn

It's now a well established principle in software development that an iterative approach works best for the majority of projects. Unless you're running life support systems or a nuclear power station, the best approach is to launch with a small but coherent set of functionality, learn from your users, and then launch another small update. That way you continually incoporate feedback from your users in your project and can adapt it to changing requirements as you go along.

It still surprises me how many people try and build community solutions and don't take an iterative approach. They have a vision of what their community want and they can often be so focused on that vision that they end up with something that is:

- too big. If you have too many places to interact you'll dilute your community, often to a point where they feel no one else is there. Nobody wants to be first at a party.

- too complicated. KISS is a good principle in many areas of life and community is no exception. A clever community solution will be beaten by a clear simple one every time.

- too expensive. If you spend a ton of development effort on building your vision it's going to make the solution more expensive. Proving the value of community can be one of the big challenges you face, so why make it even harder with a bigger upfront cost than necessary?

- too late. Building something big, complicated and expensive takes time that you may not have. What your community wants may have moved on considerably from what you originally thought if it takes you six or more months to build it.

I always try to encourage customers to keep their initial implementation of community functionality small, focused and using out of the box functionality where possible. Those projects that have done this and followed an iterative approach have tended to be the most successful.

Photography - the perfect social activity?

I've been thinking a lot about what makes a good social activity around which a community can be built. I don't think there's any perfect formula out there, but clearly some activities work better than others.

Out my own interests, I've noticed that photography is the activity that seems to work really well on social media. Customers of ours who include photo based functionality are rarely disappointed with the response. Communities like Flickr, Aminus3.com and more recently Google+ have hugely vibrant, engaged and activities.

I think this is due to a number of factors:

Photography can be highly technical. The gear and the processing has always involved a high degree of complexity and whether discussions are motivated by gadget lust or by understanding processing techniques there is a lot to talk about.

At the same time photography is also artistic. As Nikon recently found when they posted that "a photographer is only as good as his equipment" photographers are aware that for all the technology, the best photographers are more like artists. As art is subjective this gives another angle for discussion.

Photography also has a shareable outcome. Unlike running or cycling (my other interests) photography produces rich, interesting results that can be easily shared online. It's a lot harder to share a great run or ride online and involves a lot more work.

It's also interesting that photography is most often a solitary activity at the time you carry it out. Running or cycling lend themselves well to carrying them out with others, but most of the time a photographer will be on their own when taking or processing photos. This probably increases the urge to share your experiences with others when you can.

Finally photographers want validation. They're doing something technical, artitistic and solitary and by sharing it they're often asking for validation that they've done it well. It's interesting that constructive criticism is a rare sight on photography sites - almost all comments tend to be simple "great photo" responses - which probably reflects an understanding at some level that photographers just want their photos to be liked and don't necessarily want them criticised.

I think this is an interesting exercise when planning a community, to think through the characteristics of the activity or subject you're going to focus on. Being realistic about what buttons the community is going to push will help keep your expectations realistic and help you design the community well.

Finally, the best of both worlds - offline web apps

I started out as a developer with client server applications (Oracle Forms apps, to be precise). When I moved to the world of web applications like many I never looked back, thinking all the frustrations of client side apps were solved.

They weren't (at least not straight away) but as time has gone by web apps have got better and better from a usability point of view - give me Gmail over Outlook any day. So that old usability argument for client apps is now pretty much dead in the water.

But web apps have always been limited by their need for internet connectivity to function. When you spend a lot of time on trains with intermittent connectivity - or you want to quickly add something to a list without waiting for the server to refresh - that's a seriously big problem.

I'm currently reading HTML5 and CSS3 by Brian Hogan (http://www.amazon.co.uk/gp/aw/d/1934356689/ref=redir_mdp_mobile) and with WebSQL and Offline support, we may finally have bridged web and client apps. I can now develop a web app that has its own local database and assets, and will work just fine disconnected from the server.

This probably won't be news to those who have been looking at HTML5 before, but to me this is truly game changing. Cross platform disconnected web applications are now finally a reality, and I can see why for organisations like the Financial Times they are a serious alternative to native applications.

As web developers we may finally be approaching the best of both worlds and I'm personally really excited about it.

The importance of showing visitors stuff is happening in communities

I've written a blog post over at pluck.com about how important it is to show casual visitors to your site that stuff is happening in your community. There's some quite interesting results from one of our customers who made a change to surface what was going on and saw a 60% increase in activity.

(I originally wrote the whole blog post here, but felt it was more appropriate for the company blog).

Where there's muck there's brass and Dropbox

Back in 2007 Joel on Software wrote a great blog post on how solving gnarly problems is what makes a business successful. As the yorkshire saying goes, where there's muck there's brass - nobody in our industry got rich solving easy problems.

It's a saying that has stuck with me for a long time. In the social solutions group at Demand we solve three gnarly problems - building scalable community solutions, live blogging events, and moderating community content - and that's what makes us successful. Google solve search, Facebook solve social, Apple solve great design, the list is endless.

But to my mind probably the best example of a company that is making A LOT of brass for solving a gnarly problem is Dropbox. I still remember when I first got a Palm Pilot Personal in 1996 and started encountering the problem of How To Sync Stuff Reliably. The Palm Pilot was good if you wanted to sync with one PC, but syncing to your home and work PCs? Not so much.

Then it was keeping local files synced with files on a Windows file share so I could work disconnected from the network. Windows 2000 supposedly had a solution, but it never worked reliably. Various other solutions have been tried and discarded over my career in IT, but none of them worked - until Dropbox.

It works great as a file storage and sharing system both within our London office and in giving us access to our colleagues files in Austin, and their new Dropbox for Teams offering is a thoroughly convincing solution for small groups. I also use it to keep my Photoshop Lightroom catalog and photo archive backed up and accessible on different computers. It "just works" and everyone I've recommended it to has loved it.

By solving probably the gnarliest problem I've encountered as a computer user, Dropbox throughly deserves the $4bn valuation they recently received. It's also a great lesson that all businesses and projects need to ask themselves - what gnarly problem am I solving?

Why Steve Yegge was spot on about Google+

Recently a Google engineer, Steve Yegge, posted an epic rant / manifesto / resignation letter about what he sees as Google's biggest weakness. He says that with a few exceptions, people there think of Google as a product company. Because they've had such a phenomenal success with some products (search, gmail) and because they're all so clever, they assume they can consistently design the perfect product.

He contrasts this with Facebook and Amazon, who think of themselves as platform companies. They provide platforms and let other people figure out how to deliver products on that platform.

He points to Google+ as a prime example of this. There is still no full API available, so the Seismics and Hootsuites of the world can't add features, we're reliant on Google for Android and iPhone apps, and if you're on another platform like Blackberry you're totally out of luck except for a very average mobile optimised site. (One of my first thoughts when I started playing with Google+ was "wow, I bet the API for this is really cool." My next thought was "oh.")

I think Yegge has hit the nail on the head. Too often in software we think we know our users and audience so well that we can design and build exactly what they want. We're often wrong, which is why successful software projects tend to be ones that start simple and grow based on feedback from their users. It's an approach we reccomend to Pluck customers - start building your community with our out of the box functionality, then learn what your community wants before you spend loads of time building custom features for them. After all, we've learnt from our customers and incorporated what _they_ want in our functionality, so it's normally an excellent starting point. I do hope the powers that be at Google take on board what Yegge says and make the kind of radical transformation into a services based organisation that delivers platforms Yegge advocates. I'd hate to see Google+ fail - our industry needs a serious competitor to Facebook and Twitter - and I fear for Google in the long term if they continue on their current path.