Category Archives: Published Articles

Creating something new is exciting, but don’t get carried away.

This post originally appeared on the Community Knowledge Transfer website.

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.

Coding for Kids – Why I think creative environments are the first step

Notes from my talk at last night’s Coding for Kids Barcamp at the Guardian

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?

Disposable Memory Project at the IPA

I was asked to talk last night about the Disposable Memory Project at an event held by the IPA in London. The videos of the talk should be online within the next week, but in the meantime, the slides are available here and on slideshare.

Update: Chris from Vizeum wrote about the event here for an overview of what was spoken about.

An apple a day

An Apple A Day / Randoms at the Bar

I was asked to speak at last night’s “An apple a day” talk, held by the D&AD at the Hoxton Pony. The speakers were asked to consider ‘what piece of technology has truly changed the way you work’. You can see my response in slideshow form over at Slideshare, and preceeding my ramblings were Alex from de-construct, Ranzie from Tonic, Flo from Dare, Clare from The Partners, and a handful of other people with really interesting perspectives on the question.

Perhaps unsurprisingly, everyone pretty much had the same thing to say – remember the human element, interaction and connection within everything you do.

The Visual Dictionary article

Someone sent me this newspaper clipping about The Visual Dictionary. We still get regular submissions and the database is just growing and growing. I’m going to try and pull together a team of people to do something with the content this year. It’s funny how old it feels now – especially as the images are quite small (it wouldn’t do print), and its all hosted on a server, rather than in a cloud, and it doesn’t use flickr APIs or any form of interconnection with any other services, but the content is still great, and concept is clearly still liked.

if you haven’t seen it before – check out www.thevisualdictionary.net

ps. i have no idea why people think its an american website.. it’s not! i’m english, and the site is internetional (sic)