webponce rants

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.

Hello

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

Position: Full-time Lead Developer
Location: London
Salary: Negotiable + Equity (Based upon Experience)

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.

My biggest problem is sticking with something – I love the ideas creation process, and the excitement of creating something new, but 90% of projects when ‘completed’ have only really just begun. For instance, The Visual Dictionary, a typography photography site I started some years ago, was great fun to develop, and build up, but it has subsequently been over-shadowed by other projects since I launched the site. That being said, there are still daily submissions, and still receives decent traffic. I really want to do something with it, to refresh the design, its functionality, and generally invigorate it a little bit, but I don’t have the time currently.

I think the same is likely to happen with The Disposable Memory Project, which is already taking a fair amount of my personal time to curate. There is no doubt that this project is a long-term one, I expect it to run for a minimum of five years, by which time I may well be on other projects which need my time.

So, how to ensure that the DMP continues to exist and grow over the next five years with the possibility of me not being at the helm? Well, its all about the community!

When I originally threw together the blog suggesting the idea, I had planned on releasing cameras around London personally, making it a relatively small and managable idea – but when it grew from being London based to having a presence in almost 45 countries, with a handful of emails coming through every day – the management shifted into a more involved job. We have some wonderful people who are already helping out by acting as local representatives in countries who accept the cameras mailed to them to save on postage. The next step will be finding people who are happy to help out maintaining the site and project itself, performing updates on the blog and camera tracker so I don’t become a bottle neck.

The tools don’t currently exist to make it particularly easy to update the site (its all run off a database, but it doesn’t have an interface to update the cameras very easily, other than the excellent phpMyAdmin), so I’m very much focusing on creating those tools to allow others to help out in managing the site. I don’t ever want the site to become ‘automated’, allowing users to create their own codes and updates via the website as I think the personal touch is important in responding to people – but we can still automate much of the grunt work like uploading images, geotagging the updates, etc.

In any project, working out the shift of ownership from creator to community is a pretty important consideration once you start to get an amount of growth. Whilst you shouldn’t start out with this in mind, you might need to think about it earlier than when you’re at breaking point. Equally, don’t be afraid to relinquish control to members of your community who are advocates or offering help, as they’re just as eager to see the project succeed as you are. I know my efforts are usually better in helping create and drive projects, and direct the vision, rather than day to day detail. I don’t want to see the project stall because of my potential lack of time, so if that means “giving up” the project in some way, I’d rather that than neglecting it.

It is something often forgotten in commercial projects, that a project launching isn’t the end, but the start (unless you’re creating something broadcasty, rather than conversationy).

I don’t actually see it as ‘giving up’ the project at all, more of a graduation from a personal project to a community based one – which is the best thing in the world. Creating an engaged community is the hardest thing to achieve, but if you do manage it – you need to reward them for their support however you can, and I reckon ownership is a major part of that reward.

I’m currently in Amsterdam at the Picnic 08 Conference, and have managed to see Clay Shirky speak twice (which brings my attendance level up to to three of his talks). I managed to fail miserably in giving him a disposable camera, having seen him wandering into the press/speaker lounge at the conference, but scrabbling around in my bag took too long and he’d disappeared, but hey ho, just getting to hear him chat around topics of collab is always good enough. Here is one of the Picnic TV girls talking to him outside the Gashouder about the changing concept of ‘we’

I’ve just started posting at excellent creative spotting blog No Legacy, setup by a bunch of the guys at de-construct, and contains the thoughts and braindumps of many very talented designers, including Jakob Nylund from Frost and Joel Corneer from The Apartment.

Yes, i’ve checked the date, no it is not an april fool:

Publisher plans printed version of Wikipedia