Coding is like gardening...

Archive for the ‘design’ Category

How we made #ykyat

Friday 13th February 2009 was going to be just a normal day, as far as we knew. Then Chris arrived at work at 9am and said, “We’re all going to write a new web app today!” The idea for “You know you’re addicted to” had occurred to Chris the previous day, upon realising that checking Twitter before email represents a pretty serious Twitter addiction! Chris thought it might be fun to see what else people were addicted to, and bring the funny anecdotes together in a place where people could rate them and comment upon them.

We had a quick 15-minute meeting where Chris outlined the concept to us and drew some sketches. Tris and I got straight to work on designing the models whilst Chris put together a visual concept. We had lots of discussion about the colour scheme before agreeing on the bright pink. James and Richard were to design the front end, Tris did the backend data manipulating and URL routing. As the person with previous experience in the Twitter API, my part was to get data in from Twitter and send responses out.

By 10:20 we knew this was going to work! Having looked up search.twitter.com for a few select phrases, we discovered that people were indeed twittering about their various addictions!

Data found on Twitter!

Data found on Twitter!

(more…)

Announcing ykyat.com

Screenshot of ykyat.com

Screenshot of ykyat.com

I’ll blog more about this next week, but just wanted to quickly let you know about our new web application, ykyat.com.

It’s a very simple service built on Twitter. It collates classic ‘you know you’re addicted to…’ jokes on a central website, and allows them to be rated so that the funniest are promoted for all to see.

It was built partly for fun, and partly as a grand experiment in rapid application design and development: we designed, built and deployed the entire app from the ground up in 8 hours 42 minutes. We learnt a lot from the process and I’ll be posting a minute by minute diary with some screenshots next week.

The downturn (with style)

The BBC have seen fit to give the downturn its own logo:

I find it slightly bizarre that even economic cycles have their own branding departments now…

Taste can be acquired

Acquire Taste by DHH got me thinking.

Having ‘taste’ is a really important skill you can have as a developer – even if you don’t classify yourself as a ‘designer’. It’s a great thing to be able to add User Interface elements in just the right place, or code a feature up that just feels right. When a piece of software has been crafted lovingly, everyone loves to use it.

Having taste as a developer is a bit like what my wife says about being tidy around the house. Now, I’m not a naturally tidy guy, but I’m learning to be; mostly because if I wasn’t I would drive her crazy! Sometimes the problem is that I just don’t see the mess, but that’s really laziness. It’s because I’ve not yet learned to take a second look each time and judge my attempt at cleaning the kitchen with her standards. Usually at that point I see where I could do better.

It’s the same with code/feature design. Most of the time it just takes another look, and not settling for just “good enough”. It’s a choice, and making the right one will make someone else that much happier with the work we do. Food for thought.

Why design completeness should track the project schedule

The level of the completeness of the design for a website should accurately track the completeness of the project. It’s been said before, but it’s worth saying again…

In the past I’ve been guilty of two equal yet opposite mistakes on website projects regarding design implementation. There’s a temptation to leave the implementation of the design right until the end of the project (”It’ll only take a day or two, after all”). There’s also a strong urge to get the design done right at the beginning of the project, to really show the client what the finished article will look like.

Both of these approaches turned out to be mistakes.

When we’ve left the design until the end of the project, the client ends up directionless. Unless they’ve got a programming background, or heck of lot of vision (and most don’t), they just won’t put your lovely design concepts together with your naked ‘Times New Roman’ HTML wireframes. Sure, the site works, and works well, but it just won’t feel right. The client won’t be able to get past how it looks and will ignore all your fervent feature demos because they’ll be thinking about that ugly font.

With one project on which we did this, the client ended up changing their mind too much about what they wanted; had they seen the design progressively improving look and feel they may well have been able to catch the vision for the site quicker. With less understanding clients, you run the danger that all your hard work behind the scenes will be dismissed just because it looks awful and they wonder what you’ve been doing with all that time and money.

So why not get those concepts right onto screen straight away in their full glory? That way they’ll know exactly what they’re getting, right?

Big mistake. When we’ve done this in the past, we’ve noted that clients often equate the progress of the design with the general progress of the site. With one project, we rolled up at the end of the first iteration with a beautiful website that showed the finished design in all its glory. The client was very pleased. However, the very next iteration, after we’d spent just as much time on functionality and ‘behind the scenes stuff’, they were less pleased. Despite us telling them how much we’d accomplished, they just couldn’t quite see it. We then spent quite a while on the back foot trying to convince them stuff was happening, even though the site looked much the same as it did at the start!

So where’s the balance? I’m not sure there’s a perfect middle way; it depends on the client you’re working with and the type of project you’re working on. These days however we progress with the look and feel in stages; it tends to ensure both client and consultancy are on the same page and everyone can measure progress in their own way.