But what’s more notable is the number of pop-overs that appear on the new Facebook. “Click here to see this”. “Where’s my stuff gone?” “If you want this, then do that”. Surely, that’s the sign of a bad design?

It’s not just Facebook. “New” Twitter is now for everyone. Every time I use it I get slightly confused – how do I do that? Where do I go for this?

I’ve always said that Twitter is proof that user-interface design is hard. All it is is a list of posts in chronological order, plus a text-area to allow you to post. Yet there are a myriad of different twitter clients, all working slightly differently, all with an alternate take on the ideal Twitter UI.

It seems that no matter how simple things are, the current trend is for complexity. More popovers, more boxes, more sliding widgets!

It’s confusing, it’s annoying and it is a massive step backwards.

Measure is a tool designed to scan your website and point out errors and potential warning signs. From broken links and missing images, to more subtle problems, like duplicate page titles or missing “alt” tags – all of which are important when looking at search engine optimisation – and just for making sure that your website is performing as well as it should.

Measure is still in closed beta at the moment, but we’re ironing out the bugs and it’s not too long till we can look forward to an official launch. If you’d like to give it a try, just get in touch.

Which means you are secure enough in your development to add functionality like this:

ApplicationHelper greeting
- should say 'morning' between 4am and 12pm
- should say 'afternoon' between 12pm and 5pm
- should say 'evening' between 5pm and 9pm
- should say 'night' between 9pm and 4am

One of those tiny details that most people won’t even notice – but makes a subliminal impression on your users (in this case, greeting them with a “Good morning” or “Good evening” depending upon the time).

• Redis: the only ‘NoSQL’ database that interests me
• Resque: I love queueing and messaging and Resque looks like the simplest, most performant, way to get started (especially when Redis gains clustering)
• JSON: not really a new technology but the idea of having a server-side app that is nothing more than a JSON API is gaining traction
• Backbone.js: I really liked the look of Sproutcore but it was just too heavy, backbone gets us many of the benefits without the weight
• Mustache.js: No point having a JSON API if you can’t display your results on the page
• Sencha Touch: Commercial and/or GPL but produces amazing results

But overall, this came down to one simple principle – “top-to-bottom, left-to-right“.

Eye-tracking studies showed that people’s eyes scan from top-to-bottom, left-to-right (at least for “western” readers – I don’t know if it applies to Hebrew or Arabic readers). The eye starts and lingers in the top-left corner and stops and lingers in the bottom-right corner, following an across and down pattern as it moves along the page.

Why is the Apple menu in the top-left corner? Because that’s where you start. Not in the bottom-left, as on Windows.

Why is the trash can in the bottom-right corner? Because that’s where you finish up. No in the top-left, as on Windows.

Why is the default button in the bottom-right corner of every pop-up box? Because that’s where your eye lingers when it has finished scanning the box. No point using that valuable scanning time to show you the Cancel button, as on Windows.

Why is the “close” button in the top-left corner of a window? Because closing a window is a “dangerous” action and so should be taken as far out of the flow of normal operations as possible.

Apple started to give up on this with the transition to Mac OSX. Early versions had the Apple menu in the centre of the menu bar. And the Dock breaks the model completely – the application launcher at the bottom of the screen (although I understand why they did it). But after a period of experimentation, Apple settled down into a reasonably consistent pattern by the time OSX 10.5 (Leopard) was released.

The iPhone changed this. For the better. The iPhone could not use the top-to-bottom, left-to-right pattern. Partly because it is less important on the smaller screen. Partly because the bottom two corners are “dangerous” areas – it is extremely easy to hit any buttons there when using the phone one-handed. For this reason, the default button is positioned in the top-right corner in iOS. That, coupled with Apple’s minimalism (if it’s not absolutely essential then get rid of it) makes the iPhone UI, and it’s associated interface guidelines, better than the rest. All good.

But what about the iPad? It’s an iOS device with a larger screen. So should it follow the top-to-bottom, left-to-right pattern or should it use the iPhone pattern? I don’t know and I don’t think Apple knows either. I have to say I find some of the iPhone apps that Apple has built confusing – especially iTunes and the App Store. Not enough to put me off, but enough for me to stop and think. Which is very un-Apple.

And then last night I installed the Facetime beta. Unsurprisingly, Apple has started borrowing from iOS in its Mac designs. This isn’t a problem. But during the signup phase I suddenly got stuck and didn’t know what to do next. It took about a second of searching around before I noticed that the “next” button was actually positioned in the top-right. That’s right – it was positioned out of the ordinary flow because on an iPhone it would be too easy to hit accidentally if it was in its natural position.

There are reasons for things being the way they are. Apple has known these reasons for twenty five years and are choosing to break with them for no real reason. That bodes badly for the upcoming OSX 10.7 (Lion) release.

At first glance, this allows a suite of automated tests to be run against your code – the idea being that you have proof that your system does what it is supposed to. Bugs are caught early and, most importantly, a new feature cannot break existing features without you knowing about it.

But there is a much bigger advantage to behaviour-driven-development.

The very act of writing your tests before writing your code clarifies what you are trying to achieve and results in designs and code that are actually simpler – and hence easier to maintain.

I was reminded of this when trying to build a data importer. My colleague wrote a huge piece of code that seemed to work at first. But upon further investigation, it appeared to get some internal references wrong – and as the import took an hour to run, debugging became a pain.

So I started over. I wrote out a series of names for my specification: it should import a single product, it should import all variations of that product, it should import the images for a product, it should update an existing product.

These bullet points are a simple description for what it was supposed to achieve.

I then implemented the first bullet point in code – I took a copy of the import file, stripped out most of the data till I found a relevant piece, loaded that and then called the importer. My test just checked the results and ensured that the results were what was expected. The first run failed – because I didn’t have any code in my importer. But I implemented the simple “import a product” case and the test passed. Then I implemented the second bullet point in code. The first test passed, the second failed. I added the code to get the new test to pass – two passing tests and a very simple piece of code for the importer. Continue till all the tests were implemented – fantastic. The importer worked. But the most important thing – because it was built incrementally, it was simple. Even better, if it did start getting messy I could rewrite and rearrange the code to simplify it – and still be sure it was working as the tests proved it.

Writing the tests does not take much time – in fact it saves time as you have to explain to yourself what you are doing before you begin. But even more importantly, it results in clean, simple code. Which saves even more time (and money) in the long run, as that becomes cheaper to maintain.

From the customer’s point of view it’s pretty essential. You need to know how much you are spending before the work begins so you don’t get stung.

From the developer’s point of view it’s pretty difficult to do because you don’t know how long things will take until you know what you’re building. And you don’t know the details of what you are building until they become apparent, which is normally while you are doing the work.

For this particular client I wanted to get this piece of work out of the way as quickly as possible and the requirements were deceptively complicated. As trying to deal with intangibles is a recipe for disaster, and time was short, I was pretty sure that whatever estimate I came up with would be totally inaccurate.

So to deal with the intangibles I thought I may as well get stuck in with the actual work. And what’s the first thing that I do? Write a cucumber story.

I went through the requirements documents (which after weeks of to and fro were actually quite detailed and refined) and broke it down into four features, each with a number of scenarios. Each scenario was then broken down into individual steps – however, I did not write any step definition (ruby) files. This is cucumber as customer documentation, not as integration testing.

We agreed that the features met the requirements (the client was very impressed with the level of detail and the clarity that cucumber offered) and I simply went through each feature, scenario and step and came up with a price for the step individually. It’s still guesswork, but it’s guesswork on a small scale, so you’re less likely to be way off. Total the lot and there’s your estimate.

And even better, once the client has agreed the price and you’ve started development, you’ve got a development plan, a measure of progress and proof that it all works – all just a simple rake features away.

Image by lemon drop

Balsamiq Mockups

The UI is pretty straightforward – create a screen, select some controls (via drag/drop or by typing in a name) and place them where you want them. Each control can then be roughly edited (for example, the table control lets you put comma-separated values in) so that you can make it look something like the expected data.

I have to say that it’s a pretty good application. It’s the first thing I’ve found that comes anywhere near the convenience of a whiteboard (or even better a piece of A3 and a 6B pencil). Even more amazing is that it’s also the first Adobe AIR application that doesn’t want to make me gouge my own eyes out in frustration at its non-standard user interface.

So, overall I have to recommend it (and if you ask nicely, they may even give you a free copy).

Is it better than a piece of paper? No.

Is it better than everything else I’ve tried on a computer? Yes.

However, sometimes its laissez faire approach is too unstructured.  So you may move to a bug-tracker.  The big problem there is, no matter how simple you think things are, how many fields you make optional, there is always an issue about complexity.  What takes precedence?  The issue-priority or the version that it has been assigned to?  Or does something over due date take precedence over both of those?  

You see, adding anything increases the complexity exponentially – going from three variables in Basecamp to eight or nine in a bug-tracker (and that’s a simple bug-tracker, not like the beast that is Bugzilla) means you have to define what each of those fields means to you and how they interact.  

Even the most apparently simple piece of software has this inherent complexity – look at the massive variation in Twitter clients – despite Twitter being nothing than a single 140-character text field.  All of which shows why software development can sometimes be very very hard to get right.