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.
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.
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.
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.
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.
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.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.