Tag Archives: projects

tumblr_ncivg4CrIJ1tm587io1_1280

One Year of Junk Mail – Data so far.

It’s one month of being in the flat, so I’m publishing the September data today – 41 pieces of Junk, of which a whopping zero were interesting or particularly compelling to read (I’ll let you know that already things have changed in October – perhaps September is a poor month?).

You might be surprised (or not) to know that Estate Agents are the clear leader with 7 items (17% share of mailbox), followed by Takeout Menus (5) and Health/Wellbeing (5) – which ironically cancel each other out.

You can see all the data here, and I’ll be posting monthly updates to the data as we go. I’ll also start logging the amount of non-DM mail which comes through (i.e. actual real letters) to truly reflect what proportion of mail is marketing vs. ‘real’.

You can follow the project at http://oneyearofjunkmail.tumblr.com/

One Year of Junk Mail

I’ve just moved into a new flat, and it has prompted me to think about projects which last 12 months, the length of my contract in this place. The first project was waiting on my doorstep before I even moved in.

Junk Mail.

I’m going to capture the entire body of direct mail which I’m sent whilst I’m in this place.

Stuff which is anonymously door dropped, stuff which is marketed directly at me. Stuff which is incorrectly sent to me. I’m interested in seeing how long it takes for my details to appear on marketing lists, how targeted and relevant the content is, and the sheer volume of paper pushed through my door.

I’m not sure how interesting it will be to follow, but there might be some interesting data from the back of it.

You can follow the project at its tumblr, http://oneyearofjunkmail.tumblr.com and I’ll be tweeting project related tweets via #1yearofJunkMail

tube-crop

Edges of London – the numbers

I generally like to look at the data of the projects which I work on (mostly so I can see what nonsense I’ve signed myself up to).

chart

Whilst I am clearly lacking in terms of ability to visualise interesting data, here’s a chart I’ve created to show myself the journey times from shortest to longest from my common starting point of Richmond for the Edges of London project.

The rule is simple – travel only by the tube network (i’m including DLR and overground), no buses, no cheating.

The closest, naturally, is Richmond, of 0 minutes travel time.

The furthest is Chesham, with an estimate of 110 minutes (although as I travel most on weekends, that is probably an underestimate, Amersham was a solid two hour journey).

In total, I have about four days of travel ahead of me.

The scale of the project is clear when you look at the tube maps against a geographical map of London.

Screen Shot 2014-07-06 at 02.05.14

 

As you’ll notice, the map when laid out geographically bears practically no resemblance to Harry Beck’s heavily stylised map of the network.

The edges of the map stretch way way out beyond what would traditionally be recognised as London – with Amersham and Chesham in Buckinghamshire,  and Epping up in Essex. Even Richmond station, my ‘Station Zero’ for the project is in a borough made up of parts of Middlesex and Surrey.

I’ve used the excellent CityMapper as my guide, and I’ll be logging more data as the project unfolds.

The raw data is here if you want it, and i will try and keep it all within the same structure/sheets.

(I’d love to find an visualiser who can help me with making these aspects of the project more appealing to look at too).

An image from my new project - Edges of London.

Take a look at http://edgesoflondon.tumblr.com/

Edges of London

My new project “Edges of London” launches today.

I’m building a slowly growing photographic collection of visits to the end of every tube line.

Over the course of the next 12 months or so, I’ll be travelling to the 35 stations on the London tube network which are the end of a line, and capturing the conversations I have with folk, as well as anything interesting I spot visually.

The first station was Amersham.

#NicerTuesdays

Last night, I spoke at It’s Nice That’s #NicerTuesdays.


Photography courtesy of GT / Its Nice That

It’s their monthly creative talks event, and I stood alongside three other brilliant speakers, photographer Spike Visser, Kevin Haley of aberrant architecture and Hector Harkness from immersive theatre company Punchdrunk, all on the topic of participation.

My talk talked about a couple of projects I’ve run where participation is key, and generally focused on the importance of the role of Curator, someone who is responsible for guiding and directing effort and talent, into the best possible shape; the importance of ensuring that your community is looked after and feels a sense of co-ownership; and that participative projects which include collaboration with a wide group of people are sustainable, so that no-one person can decide they’re bored and give up on a collective group’s input.

All of the talks revolved around the role of the audience in a piece of work, and reminds us that everything we do, ultimately, is for an audience – and without understanding how they fit into ecosystem and the role they play, ideas can be disconnected and inauthentic. Without putting a person and their needs and interests at the heart of an idea, it falls flat.

There’s a larger description of the evening over at It’s Nice That’s blog: http://www.itsnicethat.com/articles/nicer-tuesdays-participation-write-up

The 100 (+2)

Almost 2 years ago, I started a project called The 100.

I dreamt up the idea on Jan 1st 2012 to send 100 cameras to 100 people aged between 1 and 100, one camera per age, in order to capture a week in the lives of 100 different ages.

I intended to complete the project within twelve months, as a quicker project in comparison to the long running Disposable Memory Project (which is five years and counting), and wrap the project up on Jan 1st 2013.

Boy, was that an underestimate. In reality, I’ve effectively finished the project today, with the very last roll of film being published on the site. Whilst there will still be a bit of actively over the coming months, the project in its first state is complete with 100 (actually 102) rolls of film developed and shared, in addition to two special ages 0 and 101.

Why did it take longer than expected? I’ll write a longer blog post over on the project to explain, but in short:

1. Major Life Events. Not least of all, my wife got pregnant and we had a second child in 2012, I moved jobs, and a handful of other significant personal events took place which immediately consumed all of my emotional and cognitive energy.

2. The Post. It doesn’t work. Sending physical things all around the world is costly, hard work and unreliable.

3. Crowdsourcing. It takes a long time to find 100 people. It’s sort of chicken and egg. If people aren’t visiting your website, no-one will apply. No-one will visit your website until you have images online. If no-one visits your website, there are no images. And so on.

4. Major Life Events. This is worth posting for both 2012 and 2013. This year has been even more unsettled, with yet another new job, and a host of other challenges.

Needless to say, its great when a project concludes, and to see the complete set of images is really special.

Check out the complete project at http://the100.thinkplaymake.co/

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.

Child’s i Foundation launches

Through my work at Yarned, I’m involved in a new charity – Child’s i Foundation, which is building a babies’ home in Uganda on the outskirts of Kampala for 50 infants, from newborn babies to five years-olds. The home will have medical facilities to help with premature and sick babies and children with special needs.

This is happening in two ways:

1. To build a “transitional orphanage” with full medical and educational facilities that provides a safe haven for babies and young children.
2. To place these children into secure and happy families, giving them something we believe every child has a right to – a loving home.

Child’s i Foundation will connect supporters to our work in Uganda in real time. Through emails, blogs and videos, people will be able to see exactly where their money is going, and we will have the opportunity to appeal directly for additional help should we need it.

Members of the community can be involved on many levels, from community fundraising, making donations and suggestions to actively volunteering at the Home in Uganda.

Interaction and mass collaboration are the keys to building the charity and achieving our goals.

We are creating a Web 2.0 version of a letter from a sponsored child and creating a new way of giving.

I’ll write more about the approach we’re taking from a technical perspective over the next weeks, but in the meantime, please go and visit the website:

http://childsifoundation.org
Also, follow us on twitter and flickr.

Fancy a pint?

the prince regent

Another quick build project for Andy at de-construct, who part-owns The Prince Regent, a pub down in SE24. Building this has made me hungry. They’ve just been shortlisted in the 60 under £60 category in the Evening Standard London Restaurant awards, so bravo! Its still a bit of work in progress, as we had to get it live ready for today’s announcement, but I’m sure i’ll tidy up the CSS and add some new content later next week.