Unnovation – the digitisation of a non-digital experience without additional thought around whether simple transfer from physical to digital really works. Using new technology either for the sake of technology or not using the technology to any potential..

Digital fridges are unnovation. Putting a screen on the fridge to display a to-do list, digitally replicating the photos, magnets and notes.

Digital signage is unnovation. Being able to replace paper with screens that do nothing more than being able to swap the bit of paper slightly faster.

It sits within the ‘Adjacent Possible’ concept that Steven B Johnson eloquently describes, where ideas are only possible by taking the next logical step from the current behaviours and technologies we have.

Unnovation, however, is fascinating for me.

In a recent research project for a client, I was exploring current and upcoming techniques in retail (offline and online) especially around new technology and emergent behaviours. What was striking was the amount of duplication and replication of ideas. Square, for instance, has inspired a dozen other mobile POS devices, and I lost count of the number of Shopping List applications for smart phones.

The shopping list apps are generally unnovation – digital versions of scraps of paper. Sure, you might be able share your list (although who cares that I need a can of tomatoes and a new bra?), you might want to find them for the cheapest price, but they’re all the same model: find a scrap of paper, itemise your list, purchase your items. Disconnected, and not smart.

Yet, the vast number of apps which display Shopping List functionality is encouraging.
We still need to remember stuff to purchase, and purchase it.

Innovation can often focus too much on external directions, moving from your passion centre and exploring new spaces for your business, when sometimes it can be far better to look inwards and identify the problems and opportunities right in front of you or that people are demanding. Asking people what they want can lead to a recommendation of a faster horse, but as Russell Davies puts it:

“Imagine what horses might be like now if science/industry had devoted as much attention to improving them as we’ve devoted to the internal combustion engine and industrial production. Horses would be INCREDIBLE.”

That there are many many many clones and examples of unnovation suggests there is an itch which is not being adequately scratched. It suggests no-one has provided a strong enough solution to address the process. When looking at a busy area of supposed innovation, such as retail, disregarding ideas like Shopping Apps simply because there are already 100 in the app store is not always a good idea. Sure, you need to do more to stand out, but that’s the opportunity, asking why a shopping list on a digital device needs to replicate its physical counterpart.

Understanding users’ demands, existing behaviours and looking at popular areas of development are massively valuable to innovation.
You might not start with a radically different product, but if there is a demand for something, it could help you fund the more visionary work you hope to continue investing in.

Update: There’s a really great article at Fast Co which expands upon the idea of spotting the value in popular suggestions.

TLDR: Make data policy statements accessible, else they’re worthless.

There is currently lots of discussion about privacy policies, and the use of data by applications (not just mobile, but any application, whether it be desktop, web or unicomp) after a number of notable examples of companies taking/using data from you without explicitly asking permission to do so.

At the same time, Google have recently changed their privacy policy across all of their services, to provide a simpler, singular, shared policy, which not only aims to keep the policy more simple, but also allows data to be shared across their services.

And, today, a shared privacy policy has been agreed by the major ‘app store’ owners, which further aims to make policies clearer and arguably more strict when it comes to use of your data (ergo life).

Admirable (or forced into doing so) or otherwise, having data policy statements is only part of the job.

I challenge you to find me three people in your network who have read a EULA when purchasing software, or read every letter of the terms and conditions when buying a product from an online (or offline, for that matter) retailer. If you can find me three, and they’re not all lawyers, good on you – you’ll know just how much spare time your friends have on their hands to enable them to read the lengthy legal documents, and how intelligent your friends are that they can intepret the often complex and grey language.

In the main (me included), consumers and users do not read license agreements, and rarely privacy policies. They generally make an assumption that the organisation aims to not be naughty with their data. They place a great deal of (sometimes misplaced) trust and faith in these organisations to respect the data they have access to. Sometimes, the assumption is stretched to breaking point.

Personally, some of the techniques used by apps like Path, Twitter, Color and Facebook, are innovative and magical. They provide a layer of intelligence to the application which you don’t have to think about. If a centralised system has access to your address book, and your friends’ address book, it can see there is an overlap, and suggest that you connect also via their service. This is smart. This is using data to create a better connection between two people. I’m all for these sorts of clever approaches to making smarter experiences.

I’ll go a step further. If you had to approve every single data transaction, or clever technique like this, two things would happen: a) user experience would become so poor, that most apps would rarely seem like magic, dramatically reducing their appeal and adoption, and become less likely to succeed to be frictionless and b) new and left-field techniques would rarely be implemented, and apps would become functional, and progress and exploration of new mechanisms to create ambient and passive interaction would falter.

These are bad things.

So, what is the solution? If people don’t read privacy policies, that there is an important moral point to ensure users know how their data is being used, but all with progress, and painless user experience in mind, how can we make sure that apps ‘do good’?

Accessibility.

Accessibility is not just about making sure people can get through doorways in a wheelchair, or see small text in big letters.

Accessibility is the provision of information in a usable form to all.

Accessibility in the context of privacy policies are making those policies clear, and immediately understandable, so they are read (in some form) and understood, and AGREED to.

And it is the explicit agreement for applications to use the data in the way explained which allows apps to continue to innovate and be magic.

How do we make privacy policies accessible? Plain English? No. Hire a lawyer? Probably not.

I think its through the use of icons. Those funny little dingbat symbols we see all around us which evoke meaning.

A picture of a man on a door, means men can use this toilet.

A horizontal line through a red circle means do not enter.

An arrow pointing upwards means we take your personal data and upload it to our servers.

An arrow pointing left and right means we share your data with other systems.

A arrow pointing up with a dollar symbol means we share your data with advertisers.

The first two examples you might recgonise, the final three I just made up, but with a globally recognised icongraphic data policy system in mind.

It works for food (red/amber/green lights for salt content on UK food packaging, for instance).

It works for film and computer games (BBFC ratings on films, or ESRB ratings on games).

It works for copyleft (Creative Commons licenses for instance).

In fact, Facebook already employ a basic similar concept for their “Approve this Application” screen when you’re using an app for the first time.

When installing or choosing to use an application, a quick prompt with a set of icons which quickly describe what the application will potentially do with your data.
This then allows you to make an informed decision on whether to continue installing the application.
It means you can make an informed decision on whether you’re happy for your data to be used, without crippling the user experience or innovation, and without you having to read through paragraphs of legalese.

This concept doesn’t remove the need for application developers and platform owners to develop honest, open and sensible data and privacy policies, it just calls for those policies to be made accessible, in a format that everyone can understand.

Once again, accessibility (and good information design) to the rescue.

Now, over to you, application platform developers.

Creating something new is exciting.

Hopefully, you’ll be so excited by your idea that dopamine will be rushing through your body, and you’ll be falling over yourself with energy and eagerness to get stuck in, hire a developer, and get making the thing.

Before we do anything, however, let’s take a deep breath, count to 10 (don’t worry, that’s only two in binary), and look at some of the techniques which help make sure that your new project runs smoothly.

First of all, do you actually know what you want making?

You might be able to pitch the idea in a lift to raise funding, or sell the concept to someone with wavy hands and waggling eyebrows, but do you know what the thing you’re making will actually do, screen by screen, click by click?

If not, you probably need to spend some time developing the ‘User Experience’ – as in “what will the user experience when they use my application”. What do they see when they first arrive? How many articles appear on the homepage? How do they register a new account? What happens if they’ve already got an account and try to register again?

Depending on the size of your idea, this project could be relatively quick, or take a few days exploring all of the features and functionality. I often use post-it notes to quickly list out all of the features, and group them together per screen, perhaps using a large wall as a working space. It allows you to very quickly move features and functionality around, and encourages you to think quickly and sketchily, rather than focusing on detail. Drawing up each screen can come at a later date.

It is always best to involve your developer in this user experience design process (or UXD, if you want to impress others with abbreviations), so they understand the reasons behind each decision, and when they come to create each screen, they understand how things connect and why.

It is even better to involve the end users in this UXD process, as they’ll often provide many wonderful insights, suggestions and comments you might never have considered.

In fact, the more collaboration at this stage the better, as its easier to discuss around post-it notes than change designs and code.

Once you have this user experience piece, and everyone is roughly in agreement with what the application will do, your designer can go away and make it beautiful, and your developer can go away and write up a specification.

This specification doesn’t need to be hundreds of pages long, perhaps just annotated drawings if you created screen by screen drawings in the UXD phase, or short ‘user stories’ describing what the system will do, hopefully in plain and simple English.

If you don’t understand what the specification is saying, it’s a useless document. Don’t encourage someone to write something just to tick a box, as its waste of time for both parties; create something that acts as a living guide for making sure you’re creating what you need and want.

And now, the exciting part, the coding begins.

The most important thing to make sure that DOESN’T happen is that your developer just locks himself or herself away in a room for several months, ‘getting it done’, and presents you with your application in a ‘tada!’ moment.

If you were building a house, you’d want to be on site every week, talking with the foreman, checking the plans, making sure any necessary changes are included, or any unforeseen circumstances are dealt with suitably. Creating software is no different.

At the start of the project sit down together and work out the order in which things are done, and rough time-scales for how long each piece of functionality should take to build. Think back to the post-it notes, and work out which parts are the most important to see first (either because they’re more complex or because you need to start demonstrating it).

Again, the UXD will have defined most of the elements of your application, so you use that as a guideline. Your developer will be able to guide you on a sensible order (you can’t build a roof before the walls in a house, and software is similar to a certain extent).

Plan with your developer to have a weekly review, where you look at the functionality that was built that week, and discuss what will be built the following week, in case things have changed, or the developer has any questions. Ideally, in these reviews, everything should have been tested and working, so you see actual functionality, rather than half-completed code.

Sometimes, things won’t be exactly what you expected, or once you’ve seen it working, you might realise some elements need to change, but hopefully, they’ll be small things (as there was only one week of work that passed since you reviewed it last).

These weekly reviews will pass, and your software will continue to grow, in the order of priority that you agreed up front, and hopefully to schedule (or at the very worst, each week, you’ll know whether your deadlines are slipping or not!)

At some point, you’ll have a version of your application that you’re happy to share with others, and you can start testing.

Again, get the UXD documents out (see how useful they are??), and review what you originally agreed upon against what you what you’ve ended up with. Apart from where you’ve made decisions to change things along the way, you have a wonderful tool to check you haven’t forgotten anything, and your application works as it should.

And finally, once everything has been built and tested, your developer will be able to help you launch the application, and make it publicly accessible. Before this happens, it is really important to agree with your developer how support will work. If something breaks, how quickly will they react to fix it (and for how long will they do this for free?) If you need something changing, what is the process for asking that to happen? How long notice might they need for future updates?

You’ll see that the key to running a successful project is good and regular communication, and getting the original user experience agreed between you and your developer, and making sure that people are involved from early on in the project, not just when they need to be doing ‘their bit’.

And when you make a billion pounds from your application, don’t forget to buy your developer a beer or two.

- creation: someone very clever or opportunistically creates a new technique or technology, often an engineer with specific purpose in mind.
- beautiful implementation: someone also very clever uses the new technology, often slightly subverting the original use, and in a very striking way.
- saturation/mainstream: many many many other people use the technique again and again, but generally in the same way, just variation on a theme.
- hibernation: the technique often loses its main appeal, or the excitement of its original use lessens.
- blended use: someone, very clever or opportunistically, then blends the original technique with something else, a mashup, to create something better than the sum of its parts.

Whilst I love the creation and beautiful implementation phases, what really excites me is the second stage of use, the new subtle application of the technology, often combined with another technique or technology to create better effect. Location aware technology has been through the creation and beautiful implementation phases, and probably is coming through the saturation phase, and we’re starting to see some interesting blended location based ideas.

It is not the ‘I am here’ which is the cool thing about Foursquare, its the ‘I am here, and two of my friends have been here, and suggested not to try the coffee’ which is interesting. It is not the oyster card which is interesting, it is the email which I received about Farringdon being closed next week, initiated through my regular use of the station, rather than any explicit instruction for alerts.

This second stage use is what creates interesting ideas.

We’re not far from walking into Starbucks having already ordered our coffee whilst on the train, and it being hot and ready for you when you walk into the store, because it knew when you were 90 seconds away from picking it up.

The interesting comes from the result of an action, not from the action itself.

I’m Matthew Knight, and I’m extremely fortunate.

When I was a child, my father was a broadcast journalist, he worked on national and local BBC radio as a presenter, so I spent a great deal of my time in and around tools to make content.

At a very early age, I was editing quarter inch tape, which was at the time, a storage mechanism for broadcast audio, which you literally cut up using a razor blade, and joined together using sticky tape.

By the age of ten, I knew how to use a BBC Local Radio MKIII mixing desk, and would hang out in the redundant studio whilst my Dad was on air, making mix tapes, less about the music, more about the links between the tracks, making my own fake jingles and trails, inviting friends to call in, and recording the output.

I have hundreds of cassette tapes lying around at home of me as a kid presenting fake radio shows.

It wasn’t long before we had a computer at home, with a dial up internet connection, and whilst I cannot remember if my dad encouraged me to learn programming specifically; he had brought me up in an environment where I was surrounded by the tools for creating.

I pretty much knew I’d end up with a career in media, although at the time, there was absolutely no way of knowing what the media would look like when I was my father’s age. I thought I’d be editing clips of audio or video, rather than now splicing together entire technologies to create new things.

It is impossible to say how much my childhood, surrounded by the creative process, had an impact upon my career path, but I’m sure it did. I was brought up in an environment of creation, not consumption, so it has never seemed weird to just make something.

These days, I’m asked by people for my advice. That advice is still about making things. The people who ask my advice are usually much smarter than I am. They’re strategists, creatives and business people. I get paid to live in the future and tell the past what is going to happen, or how to make it happen.

And I’m pretty sure I’ll be discovered as a charlatan at some point this year.

Just under a year ago, after a nine month collaboration with my wife, I made something very special – my daughter. To be fair, my wife did most of the work, I provided a little bit of seed-capital, and I was there at the launch, but it has completely changed my perspective on life.

I still live in the future, but instead of pondering what the future will bring in opportunities to sell cigarettes to minors for my clients, I seem to worry myself half to death about what world my daughter will grow up in. Will there be water? Will there be political stability? Will Arrested Development have been finally made into a film?

And combine this with the recent discussions which I’m increasingly having with people, around the importance of teaching our children to use tools to create their own future, my mind is starting to be blown.

Picture this.

We’re a transitional generation that has seen so very many amazing things created by so very few.

The shift in just my short time on earth has been monumental, from holding a piece of physical tape in my hands in order to edit sound, to the completely virtual nature of projects like soundcloud.

Yet already, despite technologies like cloud computing being so very new, we already expect and demand so very much from them.

We can listen to Spotify whilst on a plane flying to Germany, but are pissed off when it buffers a little bit, or the bitrate is a little too low, despite the fact we’re flying at 30,000 feet over Europe to a piece of music we don’t own or physically have in our hands.

If we, the generation who have been gifted these amazing new technologies, both appreciate the benefits they provide and opportunities they create, but already take issue with things which are not multi-touch, endless battery life, fit in our pocket, cloud based and always on real-time streaming, what on EARTH will our children, when they are our age, or even when they are just fifteen years old, expect and demand from their technology.

Hoverboards are just the start, the rest is almost inconceivable.

And when their frustrations kick in, what will our children create to circumvent that hurdle, or to solve their problems? What will they envisage and re-appropriate? What will they be forced to do in order to connect and exist in their society?

Inspired by this dystopian and utopian question, I’m in the process of collecting the responses to this pondering from other parents.

I think parents have a unique, inspired view on the future when it comes to their own children, and I’m interested in asking that question to other technologists. It isn’t simply future gazing, but begs questions about the foundations and future opportunities we’re offering our children today.

In those responses, already some themes have started appearing, which I think could be useful context to discussions today:

Less reliance upon government, more upon society – if something doesn’t exist, don’t complain about it, create a solution.

A mindset of “Show and tell”, rather than privacy – in a world where everything is captured and shared, whether you opt-in or not, what does the content that surrounds you say about you, if you expect your future manager to google you, rather than are surprised if they do, what does this mean about your actions in life.

A shift away from device-centric computing – why do you own a device, when everyone’s device does the same thing, it’s just the content loaded on the device that matters.

A shift away from ownership – why own something when you can just access it for the period of time you need it for, physical and virtual.

Decentralisation, physically and virtually – why do you need to arrive at a defined location to do what you do? why do you need to login to a single server or a single point of potential failure?

Hyper Partial Attention – the concept of beginning, middle and end is analogue. Dipping in an out of streams of consciousness is the new method of absorbing knowledge and taking part in things.

But these are all from our own narrow little minds, with our one foot in the nostalgic memories of analogue, I cannot imagine my daughter having much interest in Lomography or Instagram, and our other foot in the business of being excited about the future, and excitement often creates things that are not there.

My daughter is already a consumer. She loves books, and will pull ‘Noisy Zoo’ and ‘Peekaboo Peter Rabbit’ off the side, demanding that I read one to her. I cannot wait until the first day that I can give her a crayon, and rather than her eating it, she scribbles on the wallpaper, and like my father did for me, hope that I can foster an environment where making things is as important, if not more, and as natural as consuming things.

There will be lots of discussion today about the role of schools and curriculum, and tools and processes to teach code, and these things are essential.

But it has never been about the code or the tools, but rather the attitude to know that tools are available to break something apart and reconfigure it, in order to understand it better, to improve upon it, or to make something entirely new.

An attitude towards it feeling entirely natural to question and create, rather than to just follow.

And our role is to foster the creative environment where this constant questioning and creation is encouraged, expected and demanded, where our children keep asking ‘why why why’ until we can no longer answer their questions, and they go off and answer it themselves.

I’d like to finish with a joke that I hope sums up tonight’s conversations:

How many children does it take to change a light bulb?
Why a light bulb?

Activate the widget, and using the bottom navigation select ‘Push Project with Nokia & Burton’

I’m looking for five (or more) people to take part in a year long experiment.
You must be able to commit to taking one photo a day (same time, same place, same angle), and doing this for 365 days (or thereabouts).
You can of course have holidays, we’re not going to be too annoyed if you miss the occasional day.

We’re looking for a geographic spread of volunteers across the UK.
Ideally, you’ve got experience with using Wordpress, or at the very least a computer and your fingers.

This is a completely non-profit, non-commercial, and just-for-fun project.

If you have a camera, an internet, and one minute free every day – please email or tweet me.
matthew@webponce.com or @webponce

We’re a start-up in the health space, developing a groundbreaking multi-platform application to be launched in 2011. The team is a council of excellence across commercial, creative, clinical and technical strategy. We have already formed key retail and clinical partnerships. Now we need the final piece of the jigsaw: the team member who will develop the application software.

You’ll be working closely with our Technical Director and Managing Director to understand and define how the application will function, and play a key role in shaping the underlying technology, but will be given the space to determine how this should work in practice. We’re looking for someone with experience in developing web-based applications which can also work in mobile contexts, someone who understands how to architect a solution, not just build to a spec, someone who wants to take responsiblity for the code and own the project, rather than just churn out controllers, models and views.

You’ll be paid a salary, but also equity in the company and genuinely be a critical partner in this small team developing a new business. Your experience may be digital agency, self-employed developer, or just a general code ninja. You’re probably a PHP, Rails or Django hacker, and know your way around jQuery and CSS, REST APIs and JSON. You see yourself as a middle-weight or senior developer who is maybe fed up with working to a brief, and wants to create something with longevity as part of a small energetic team.

Email matthew@webponce.com for more details and secret squirrel information.

I’m looking for a web developer who is interested in helping us out on a project for the NHS.

We’re building a physical device which will use embedded software to send data to a platform in the cloud you’d be developing.

You’d be required to build the APIs for the device to connect to, some integration with an SMS platform (dead simple), and the dashboard and tools on the platform itself.

There isn’t a huge budget, as it is an early stage trial, but should it go ahead, you’ll be helping people with mental and emotional difficulties use digital tools to improve their wellbeing.

You’ll also get the change to work alongside a great little team of social innovators, and of course, me (don’t let that put you off).

You’ll need skills in:
- Front-end development (HTML, CSS, JS etc)
- Server-side development (ie. PHP, Rails, Django, etc)
- Ideally some experience in frameworks rather than building everything from scratch
- Some experience in building RESTful APIs
- Some experience using Google Charts would be cool.
- Some experience using Facebook and Twitter APIs (including OAuth, Facebook Connect, etc) would be very handy

Drop me a line via twitter or email or just leave a comment if you’re interested in finding out more.