Phenotypic

There’s been a huge amount said about the recent reddit/4chan hunt for those behind the Boston marathon bombing, it’s even broken into mainstream media - albeit while being criticised for presenting incorrect and misleading information. Irony aside, the hunt for those responsible was a single example from myriad disturbed action networks which appeared on the 15th April.

I won’t curate a list here (the links below tell the full story), but to name a few:

• Hundreds of people signed up to a simple spreadsheet offering those in a need of a place to stay safe refuge,
• Google launched their Person Finder
• Communications via the mobile network were inevitably taken down by the volume of traffic, so Bostonians unlocked their WiFi networks,
• Humanitarian networks such as GWB and Humanityroad curated live streams to disseminate useful information and news of other crowdsourcing efforts, while the mainstream media focused on voyeurism.

The question is: why was the online manhunt the only case reported with such fervour?

These sorts of crowd based action networks are only going to grow stronger and more frequent as we become comfortable with our new connected society, but it’s up to us to choose which crowd we want to be part of, and remember that positive action often goes uncelebrated.

Now, go give this guy some money, Crowd:

Naturally the guy who had both legs blown off in Boston bombing and IDed bombers to FBI has no health insurance: bit.ly/14CDzWT

— Mike Madden (@mikemadden)

April 19, 2013

…but it seems we’ve only seen the beginning of what’s possible when that data is placed in the right hands.

Recently the term API entered into non-technical digital/product folk’s parlance, as we can see from the above quote found a press release from Nike.

This is no bad thing; a world of hackable services and products has long been the dream of open data activists, I won’t go into why because a lot has already been said about that, but perhaps this is a good time to remember that when any technical term enters the world of strategy, we must be wary of its meaning being diluted by those who would use it to sell us more crap we don’t need.

Opening your service by means of an Application Programming Interface introduces the chance that someone will hack it into something all together unexpected, surprising and brilliant.

You open things up to supercharge innovation.

However, this is only truly the case when you open wide enough to embrace uncertainty; when you take a risk hoping the pay off will be the serendipitous discovery of something you could never have foreseen, and that no amount of ‘innovation’ insight was going deliver.

If you carefully select who is going to have access to your API based on the preconceived notions of what your product or service is, and how it could evolve, all your doing is inviting people to work for you, for free.

… and that’s not cool.

With the lines blurring between what we call prototypes, MVPs and the rise of iterative product development it’s tough to know when is right time to let the public loose on your service. Crowd behaviour research will tell us that:

Certain conditions must be met for crowd wisdom to emerge. Members of the crowd ought to have a variety of opinions, and to arrive at those opinions independently.

This is why we expend so much energy testing on diverse user groups before releasing a service into the wild. However, to continue with this logic… wisdom of crowds can be polluted by the cross-pollination of opinions:

Opinion polls and the mass media largely promote information feedback and therefore trigger convergence of how we judge the facts

Convergence of opinion is never good. Sure, sometimes the crowd will – due to peer influence or hype – converge on the opinion that your service is super-amazing, but there’s no longevity to an opinion that isn’t borne through real, first-hand experience.

This poses an interesting question: how do we, in order to maintain a level of honest feedback, avoid this convergence when launching a new service into the very medium that encourages convergence?

I’m now going to wildly speculate – so apologies to readers who understand the crowd behaviour better than I – that the best way to ensure our services have a fair shot on the Internet, is to spend less time on pre-launch hype, closed user testing, and polishing interfaces; and go back to the age of the early public Beta, or, if you’re really brave, Alpha releases.

The early release opens up first-hand experience to as many people as possible, while the ‘viral’ teaser campaign generally gives us no real facts about a service. It focusses its efforts on being polished, exciting… viral.

So, put simply, an early release gives us:

More people + More facts = More opinions ∴ Less convergence

As terrifying as it may be to open up a service to the crowd while it’s in its infancy, it does allow you to both build and test with a real, live user base. So long as you’re prepared to develop quickly and respond to criticism (constructive or otherwise), you may be surprised to find the crowd far more forgiving than you’d imagined.

Over the past few months we’ve encouraged our peers to create fresh and innovative fundraising campaigns for the famine in East Africa as part of the 50/50 Project. At the same time, we set out to break down some of the barriers that often face online fundraising campaigns. It’s been an interesting process; we started with a simple site to showcase the projects, but it has since evolved into a platform offering two key barrier-busting features:

1. A mechanism for projects to start gathering donations immediately. Simple enough, but complicated by a self-imposed caveat: all funds donated had to go directly to charity–no middle-man, no fees, no set-up costs. 100% of money donated right into the charity’s bank account.
2. An API allowing projects to integrate into the 50/50 platform in order to track, analyse and have some fun with their donor data.

Currently, it looks a little something like this:

In short: Users complete their donation using a simple, one-page donation form on the 50/50 site. Donation information can then be immediately sent to a project’s application via a callback and subsequently made available on our API for search/analysis later. You can get the nitty-gritty details from our API docs.

The embryonic product

When we started to build the 50/50 platform we had no idea what was required. We were learning and building at the same time. Not usually recommended practice, but it’s worked out rather well, due, in part, to our accidental realisation that the definitions of Minimal Viable Product and prototype have started to blur: Did we really need to build prototypes that will be destroyed once we’re confident that we’ve validated enough learning to move on and build a MVP?

What if, instead of a prototype, we focused on building a product with Minimal Viable Functionality, but didn’t cut-corners on the underlying structure of the application, then applied the principles of validated learning and progressive enhancement as the project progressed?

Setting the scene

Thankfully, the beauty in a sustainable platform rarely comes from innovative tech: It’s how you use existing, tried-and-tested code that counts. The first question you should ask yourself before tackling each and every problem is “has someone done this before…?” Just be wary that you don’t stray into the wilderness of reverse engineering. Every line of code should be carefully considered: don’t use anything you don’t need; re-factoring should be an ongoing process.

Careful consideration takes a fraction of the time you’ve save by borrowing other people’s code, and will ensure that you’re able to keep on rapidly evolving without having to engage in costly refactoring sessions when you realise you’re drowning in technical debt.

By ensuring that our underlying code was modular, extensible and scalable we didn’t end up with a disposable prototype, we created an embryonic service. Quickly.

Responding to the environment

Throughout the process we were swamped with brilliant ideas for the platform. However, due to limited resource and a desire to ensure we were building a sustainable and focused platform, we decided to tackle feature development by asking the following questions every time we were presented with a new idea:

1. Is this a feature that could provide a solution to issues that other projects are likely to face?
   If we could envisage that a particular feature would be beneficial to a number of current or future projects, we simply built it into the platform, documented it, and felt confident about adding another tool to our kit.
2. If this a feature that is unlikely to be re-used, can find a way around it without building anything new?
   We maintain a strong focus on the project owners as makers, so if something felt a little too bespoke we would suggest ways that the API could be hacked to achieve the desired result. However, we kept a note of these requests; you can never be sure if you’ve answered the first question correctly…
3. Is this a bespoke piece of functionality that can not be satisfactorily hacked into existence?
   Sometimes it’s worth building throw-away features into the platform. Just remember to document well and code them modularly (let nothing else depend upon its existence). Take a note and remove it when no longer required.

Mutating for good

We’re not sure what our next move should be. Cath, Tim and I have all thrown ideas around with the help of some fine 50/50ers, but we’re probably not going to know for sure until we start experimenting again.

So, early next year we’re planning to open up the 50/50 platform to the US public: anyone will be able to register and create their own projects using our payment gateway and API. During this phase we’ll continue to gather feedback from project owners and improve the platform as we go.

It’ll still be limited to supporting only the East African famine, and we’ll be sticking with the brilliant UNICEF, but I think it’ll help get us closer to knowing if there is a desire for a hackable space around online fundraising, a simple one, available to all without the fee-based approach most current services offer.

Open data is awesome, until it’s not

Local government geolocation data, for example, is often supplied with OSGB36 Eastings/Northings coordinates. Here’s a little thingy to help make the connection smoother, it looks a little something like this:

(@b * @OSGB_F0)\
* (((1 + @n + ((5.0 / 4.0) 
* (@phiPrime - @phi0))\
 * Math.sin(@phiPrime - @phi0)\
 * Math.cos(@phiPrime + @phi0))\
- (((35.0 / 24.0) * @n * @n * @n)\
 * Math.sin(3.0 * (@phiPrime - @phi0))\

…so I won’t embed it all here, head on over to Gist for the full script.

When we took on the 50/50 challenge to do what we could to relieve the suffering of those affected by the famine we started with a plan to create a single campaign, something that would raise awareness, and a little cash.

So we’ve all been trying to work out how to leverage networks and new models of digital engagement to raise money for famine relief.

50/50 was borne out of a feeling that we had something to give to charities beyond hard cash, something unique, something they needed. In the past few months teams around the globe have taken part, raising a respectable amount of cash and awareness. Along the way, we believe we’ve learned a few things too: smaller, personal appeals are the way forward; people prefer action over emotion; big budgets can drive huge donations.

… these seemingly contradictory statements are the source of my floundering.

So instead of burying my head in project data analysis in order to figure out the answer, I headed over to a few fundraising blogs. What I found, surprisingly, was a thread of negativity towards traditional advertising firms that try to “do fundraising” (see this post from Mark Phillips on the D&AD awards blog for a biting summary).

While it’s all too easy to assume that the not-for-profit sector has been exposed to a lot of bad “digital” for digital’s sake, and that what we’re doing is different, experimental, it’s equally valid to assume that these discussions highlight a real problem: maybe we’re just not doing enough listening to those who have dedicated their careers to causes such as this.

However, it’s not all bad news. Reading a bit further I started to notice some familiar sounding theories:

“Things are moving so fast that spending time writing a ten year strategy is worthless.”

AJ Leon, Misfit Inc

“The creative process that ignores the needs of donors is a waste of time and money.”

Mark Phillips, Bluefrog

“On the Internet we can put up any crap…so we forget to prioritise, we forget to ask and we forget to rigidly monitor and analyse”

Beate Sorum, Norwegian Cancer Society

Sounds a lot like that thing we refer to as “Lean”…

Our thinking is converging. Charities know their donors; we know how easy it is to #buildshit quickly. We could learn a lot from each other. Shall we talk?

Ideas are pretty useful. Without them we wouldn’t have much going for us as a species – they help drive evolution; keep us happy, busy, warm, satiated.

In the realm of the geek, he who has the best idea is King, or at least, was; something has invaded our space recently: the investor. The investor has turned a world that was once driven by passion — in which the only currency was e-kudos — into a simple search for that ever elusive next big thing.

As a result of this two things have happened:

1. Geeks, creative technologists (or whatever the advertising world is calling us these days) have become reluctant to create anything, unless someone has placed a large chunk of cash on the table, and…
2. …they are afraid to accept that a bad idea, once it has been brought to life, was a bad idea; terrible products linger on far beyond their fail-date.

The commoditisation of our pet projects has stifled creativity and is beginning to seriously damage developer communities. I wonder how many great ideas persist as ideas, and nothing more, and how many poor ideas we are going to have to suffer before we can claim this world back for ourselves. After all, our tools have become so abstracted that making stuff for the Internet is now ridiculously simple (shh).

So, how do we get things moving again? For that, we need your ideas. Here’s mine:

Made by Ideas (made.byideas.co.uk) is an attempt to address at least part of the problem: getting those great ideas out of heads and into the open.

All ideas are donated, anonymous and broadcast from a single Twitter account. Anyone is free to take an idea and, in turn, see where it takes them. There’s no pressure to deliver, and no penalty for failure.

It’s either a chance to see that idea you’ve not have time to produce come to life, or a place for inspiration when you have an itch to build something.

Let’s stop investing in the future, and start building it.

As we reported yesterday, we have had so many great suggestions posted to Good by Ideas that we have decided to try to do justice to as many of them as possible by building a temporary countdown site. Online for just 50 days, this site will showcase some great fundraisers and their efforts, as well as telling some of the stories of those affected in East Africa – and we are assembling it as we speak!

We are in a rare position running this project through Made by Many and Good for Nothing: there are lots of talented agencies and individuals in our network, and we realised that if we pool our skills and audiences, we can vastly boost the reach of this appeal. So, rather than banking on just one idea and hoping for donations, we’ve decided to increase the number of opportunities for success by building a platform that will amplify 50 fundraising efforts over 50 days. Our rationale is pretty straightforward: the more contributors we have, the more audiences they can reach‚ and the more fundraising efforts we feature, the more chance of one going stratospheric!

As with many things we do, this is a bit of an experiment. We don’t know if it will work but we know we’ll learn a hell of a lot from it for next time. With a short space of time available and an urgent need, we feel the most important thing is to get something out there and give it a go.

Of course, we’ll be documenting our journey through our favourite online social spaces: Twitter, Facebook, Instagram, etc, so with a bit of luck you’ll join us on this journey. Remember to check back frequently; we have deliberately limited this campaign to 50 days for maximum momentum. It’s not a charity project, and it doesn’t belong to any of us, but we invite you to join in if , like us, you believe that online networks could be a very useful tool in addressing this important cause.

It’s no secret that we’re pretty huge fans of Instagram, so I won’t spend too much time waxing lyrical about its potential (Tim is probably your man for that) instead, I’d like open up something that we’ve been working on to allow us to rapidly develop real-time Instagram-fed web apps.

Since the API was announced in February, only a few (albeit fantastic) real-time Instagram apps have surfaced. Which is pretty strange; this innovation could, and should, finally push us away from the photo-bank model, and into the stream.

But it hasn’t, and after spending a while working with it, I’ve started to realise why: the available open source code just isn’t abstracted enough to encourage technological creativity; there are too many new technologies involved, the learning curve is just that little bit too steep. I understand that there may be some contention around this point, but abstraction, and the copy+paste culture, is another post entirely, so, I give you the alpha release of Insta.Platform…

Insta.Platform

For those sick of reading already, here’s the demo.

Getting stuck into the official real-time demo was a great place to start, but it was only really created to demonstrate a portion of the API’s functionality. Insta.Platform aims to take this further by mashing it up with some other really nice libraries to give us a simple, extensible platform that allows us to concentrate on the idea, and not the code dependencies.

That said, most of the technology used is shamelessly stolen from the official real-time demo, so all credit to the Instagram team; we simply ran with their idea. So, in the spirit of releasing stuff early and often, you can head over to the github repo to grab yourself a copy of the platform-in-progress.

How it works

In order to tame the asynchronous nature of Node.js and Socket.io everything server-side is based on the Pubsubhubub protocol. Using the Redis Pub/Sub framework this has been extended to the client so that front-end developers can easily subscribe to channels and start receiving asynchronous updates from the server thusly:

  // Subscribe to a channel
  socket.send('tags:subscribe:cats')
  
  // Listen for an event signalling new media from this channel
  $(document).bind("newMedia", function(update) { 
    // Give/render the media to the user
    if(update.media.channel=='cats') {
      alert('Oh hai');
    }; 
  });

What does this actually mean?

Put simply, this means that, without much effort on your part, users of your app will be able to create real-time streams for #tags, locations (e.g. “London”), places (based on Foursquare’s database), arbitrary geographical areas (e.g. for use with ‘nearby’ geolocation apps), or simply for a specific user.

This is all accessible via a simple front-end subscription-based API, and hopefully, at some point, a nice JavaScript/HTML5 library to make it even easier to create slick real-time applications.

Next steps

Insta.Platform is very much a work-in-progress and I’d love some help from the Instagram API developer community, so, please, contribute on github, submit your app ideas to made.byideas.co.uk, or just start building something on the platform, and let me know what’s missing. If you need a few app ideas, there have been plenty posted up on made.byideas:

• Insta-nt-weather
• A “What would Instagram sound like?” App
• Instagram Project - “Nearly Everything I Saw Today”

Recently the W3C branded a selection of their emerging standards as ‘HTML5’. It didn’t go down so well with some purists… probably because under the new ‘HTML5’ brand sit various technologies that aren’t, well, HTML5.

While it’s been argued that all they’ve done is jump on the bandwagon and officially back the term, I’d counter that, in doing so, they’ve taken ‘HTML5’ and made it the new ‘Web2.0’ – it’s a term everyone can get excited about, a common language that allows developers, designers, planners and clients to embrace emerging web standards – they’ve made standards sexy.

So, why stop with HTML, SVG and CSS? Other standards could be re-branded and given the Web2.0 HTML5 treatment. A couple of (oversimplified) examples:

Multimodal Architecture and Interfaces

Multimodal Architecture and Interfaces helps define the ‘right’ in ‘do it right the first time’. Wouldn’t it be nice if your apps were available on your desktop, your phone, your tablet, your fridge or whatever comes next?

Navigation Timing

Navigation Timing is really quite niche in comparison; it deals with how you make your web-technology based applications feel super-slick.

Really Simple Syndication

That’s right, RSS could be sexy again. It’s most definitely not dying – although, traditional RSS Readers may be, which is what I suspect this post was getting at. RSS encapsulates standards that have freed us from the shackles of traditional web-based content consumption. If every piece of content on the web was served with a standardised XML feed alongside it, we wouldn’t have to rely on proprietary APIs and scraping; the world would be a far more connected place.

Don’t stop there

There are dozens more… please, someone go make them fashionable so I never again have to cringe when someone asks me which emerging web technologies I’m most enthused about – transience and me just don’t get on, and I have no real desire feign excitement about the latest bullshit web service to come out of Silicon Valley.