From the outset I knew exactly what I wanted to do with my theme because I’d struggled to find anything similar, with most WordPress themes following this format:

• Two or three columns
• Endless sidebars filled with widgets widgets
• Multiple advert support
• Not much of a focus on imagery with posts

Binx is all about keeping it simple, hence the one column approach and availability in only two colours; light and dark. For anyone in the market for a theme that is a bit different from the rest hopefully you’ll consider Binx, which you can buy from Themeforest right now for $22 (I didn’t decide on the pricing, Themeforest does).

I’m pretty sure I’ll be doing another theme in the not too distant future, so keep an eye out but I’m going to do some posts in the future to explain how I went about creating this theme as there were a lot of things I learnt in the process that I’m sure others will find useful.

We need to focus way more on the execution of our ideas instead of the nitty gritty details. Deciding if you should use a <div> instead of a <span> or if HTML5 validation would be better than Javascript validation should be an extremely quick decision on your part. Yes or no.

Using the right tools for the job is good to a point, but your average user, the one you should be building and designing for, will not give a crap as long as it works for them so spend your time and energy on meeting their needs as much as you can. If you’re putting the kudos and praise from your peers before your users you are doing something very wrong.

It all comes down to prioritisation and I think a lot of people are spending more time on the technical details than they are on the idea and execution. A site that validates 100% and uses the latest technologies but doesn’t solve a problem or feels like crap to use is a waste of time.

Stop worrying about all the small stuff, this isn’t like sending a rocket into space so it doesn’t matter if something you do is “not by the books”. So what if your peers give you crap for doing it the “wrong way”, let them worry about the small details while you go build something awesome.

How you execute on the idea you have is what matters, so spend your energy and time on that and ignore the rest as much as you possibly can.

One of the things that always bugged me about working for someone else was the daily commute. I’m sure the recent snow in the UK hasn’t helped, but I can’t think of anything worse to do every morning and evening than stand on a platform waiting for a train, that may or may not turn up on time. A special shoutout has to go to Southeastern, the worst train company in the world. Fact.

My commute was 3 hours a day, easily, but now I’m able to spend this time writing blog posts (a more regular schedule is coming I promise) or working on my side projects such as nicetripper and Thumbslap. To me this just seems like a better use of my time, and thankfully I work in an industry which doesn’t require me to be in an office from 9-5.

Obviously being on your own does have it’s disadvantages, I’ve had to set myself up as a limited company and deal with all the associated costs that go with that, but the big hurdle is going to be finding work. When you’re working for someone else it isn’t even something you consider so that’s going to be a bit of a learning curve for me but something I’m looking forward to, although if work just fell on my lap that would be excellent :)

Accompanying this post is a new design for my website. I was looking at the previous design a few weeks ago and realised it wasn’t really suitable for someone who was working for himself and relied on new clients, so I did a bit of a rework and come up with what you can see now. I’d love to know what you all think, good and bad, so please add a comment below.

One of the best things about Full Frontal was the venue. The Duke of York cinema was a 15 minute walk from Brighton train station which would have been fine had it not been for the almighty rain storm. However all was forgiven once I got inside and was handed free coffee and croissants (I love free stuff).

As a venue the Duke of York was superb and the more I think about it, I can’t believe more conferences don’t use cinemas. Not only are they fully geared to handle such events (video and audio built in) the seats are simply amazing with plenty of room between you and your neighbours.

The Speakers

The lineup for Full Frontal 2009 was outsanding with no (major) overlaps in the talks but special mention must go to Jake Archibald of the BBC not only because of the battle crabs (fuck yea!) but because his talk was the one I think the majority of people will get the most benefit from. Stuart Landrige also gave a great talk and for a moment I thought I was in a scene from Braveheart with his calls to arms against Internet Explorer.

The Content

Like I said before I was a bit skeptical that the content would be above me as a low to mid level javascript programmer but for the most part I was able to take away plenty of useful tips from every single talk which is more than I can say for a lot of conferences I’ve been to recently. The only time I was perplexed was during Robert Nyman’s talk when he explained closures, but I am sure that has nothing to do with Robert and more to do with the limitations of my brain!

Full Frontal 2010

I believe Remy has already confirmed Full Frontal 2010 is happening and that is great news for all front end developers and designers who missed out this year. I’m sure it will be just as amazing :)

There are plenty of sites and apps out there at the moment that know their purpose and everything they do is designed to make this obvious to the user. Twitter puts its “what are you doing box” right at the top on every page, because you share your thoughts on Twitter. Google makes sure their search box is prominently displayed on every page, because you want to search on Google.

There are three things I ask myself whenever designing an interface:

1. What is the most important thing on this screen?
2. What does the user need/want to know at this point?
3. How do both of the above feed into the overall purpose of this site/app?

What is the most important thing on this screen?

Cash machines have a purpose, but there is something I’ve noticed recently that really bugs me, even more so because the name of the machine is its purpose.

When I use a cash machine, I expect to be given cash, so the logical thing would be to have “Gimmi Cash” as the first option right? Well, banks are now insisting on flogging you things you’ll rarely need such as “Mobile Topup”.

Wouldn’t it be better to ask the user if they need cash first, given that this is, you know, a CASH machine?  I know it makes them money and might be valuable to some people, but this is not the purpose of the machine, so why is it the first option I’m presented with?

Have a think about your interface and decide what is the most important thing on the screen and design around it. Like I mentioned, Google does search so the first thing they focus on is the search box and results. Anything else comes way down on the list of things trying to get your attention.

What does the user need/want to know at this point?

You’ve probably noticed a lot of login & registration pages at the moment that remove all of the visual noise found on the rest of the site, and there is a very good reason they do this. In the case of logging or registering for a site, other things on the page just get in the way of the user finishing that action. By removing the clutter, it makes it clear to the user what you want them to do, and I’m sure it will increase your conversions as well.

Amazon do something similar when you want you go through the checkout process. They remove all of the temptations o deviating from this course because they want your money as quickly as possible.

Amazon want you to keep going until you’ve handed over the money

No links to other products, next to nothing to stop you from going ahead with the purchase. They even make it difficult for you to get out of the process by not even providing an option to cancel your purchase. And have you ever had a bad experience buying from Amazon? I’d hazard a guess of less than 1% of people who’ve bought from them have, so it’s worth noting what they do and how they do it if you’re creating interfaces.

How do both of the above feed into the overall purpose of this site/app?

Obviously there is a big balancing act that needs to be made when designing an interface. On the one hand having all of these nice to have’s can potentially generate more traffic around your site, but they also dilute the main purpose of the application, so please, if you’re making an application, focus on its purpose and don’t dilute it with extras just because you can.

Sorry its been so long since my last post, but I’m currently in the process of changing jobs (yay) and working on some very exciting projects that I hope to be able to share with you all soon :)

Using good design and some creative thinking, you can help stop these problems from becoming more painful to the user than they need be. Today I’m going to do a quick rundown of the do’s and don’t of helping your interface prevent errors that will frustrate and enrage your users.

Can’t do it? Don’t show it.

Your interface should be smart and intelligent, knowing when to show something and when not to show it. Take this screenshot from John Lewis’ website as an example.

Why let me add to the basket if it’s out of stock?

Notice how they’ve kept the Add to basket button on the page, even though they say just above that the product is Out of Stock? Ok, this might not be such a bad thing if you were to click on the button and it asked you for your email address so it could let you know when it was back in stock. Instead, they present you with this.

An endless loop of pain.

What is the point? Why show the same thing twice? In fact, why even show the Add to basket button when they know they won’t be able to fulfill your request.

Inline validation

You’ve probably see this on loads of sites by now, but inline validation is one of the best things to come out of the Web 2.0 boom. Now, that’s not to say you should do it for everything just because you can. What’s a good example of inline validation anyway? I would say nearly all forms these days ask for a username and email address, so that is a good place to start. Have a look at this screenshot from Twitter’s registration process.

Excellent use of inline validation.

This is perfect use of inline validation and saves the user loads of time. Imagine if they had to press Create my account each time they entered a username to see if it was available? Of course, this is the experience people will have without JavaScript, but for those that do have it enabled try and make the experience as click free as possible.

The only thing that could make Twitter’s page better would be to disable the Create my account button until all data has been input correctly, as all the validation is being done inline using JavaScript. It’s worth noting however that you should probably only disable the submit button on short forms where you can see all of the inputs and submit button without the need for scrolling, otherwise any error messages next to inputs might not be visible which could create some mega confusion to the user as to why the button is disabled.

Limit characters

One of the things I hardly ever see is clever use of character limiting. Loads of websites ask for numeric only data yet they allow users to input alphabetical characters when they know the database won’t be expecting that kind of data. Why not just limit the input box to accept numerical data only? Speaking of inline validation, you can ever do this with a little bit of jQuery using this excellent jQuery plugin.

When all else fails, offer alternatives

Sometimes you just can’t help it. No matter how much you’ve tried to prevent errors, there will always come a time when an error is pretty much going to happen. I had a recent experience on the Ticketmaster website trying to buy some tickets for Michael Jackon’s upcoming tour in London.

Ticketmaster’s web experience is terrible and I’m not the only one who thought so on the day. The problem was you had to check for tickets for each day individually. So I’d click on a date, see if they had X amount of tickets, waited in a 15 minute queue while it searched (what is that about?!) and was then told no tickets were available for that day.

What Ticketmaster should have done is told me what dates they DID have tickets for, instead they left me frozen with rage and I vowed never to use their website again. And I told everyone I knew. To this day you can go on the Ticketmaster page for Michael Jackon’s tour and “Find Tickets” but in fact, you can’t. Why don’t they just tell you no tickets are available instead of making you go through a process they know is doomed for failure from the start.

I did get some tickets in the end though. I used the phone.

There are plenty of examples of contextual user interface design on the web and if done correctly, you won’t even notice them, but without them you’d end up feeling frustrated and lost.

Limit choice, maximise speed

Google Calendar has an excellent contextual example of how to limit choice and maximise speed.

Notice how the list of time zone’s changes depending on the country you’ve select above it? People don’t want to spend their time reading through hundreds of options and deciding which is the best fit for them. Where it makes sense, always limit choice. Not only does it improve the experience of your interface but it streamlines it so that users only need to focus on the bits that matter to them.

It’s worth noting however that some users DO want to see as many options as possible, so always give them a way of doing this. Google do this by offering a simple “Display all time zones” checkbox. Very simple, but very important.

Help users get back on track

When things go wrong in your application, whether user or machine created, always help the user get back on track. One of the most common examples of this are login screens. I’ve lost count of the amount of times I’ve forgotten a combination of usernames/passwords, and when this happens I want an easy way to get going again.

For something like a login screen, presenting users with a simple link to get their password emailed to them is the answer. Welcome to contextual user interface design. Giving users what they need, when they need it.

Don’t rely on menus

At the bottom of each page on Thumbslap there is a small footnote that simply says “All dates & times are GMT”. This is a useful bit of information due to the nature of the site, but what about users who realise they need to change their time zone?  They could click on the Settings link near the top, but wouldn’t it be much better to give them a way of doing it without changing their thought and requiring them to hunt down the page that will let them do this. This is why I added a simple link directly after that statement called “Change”.

If you print a setting on a page that the user can control, give them a quick and easy way to edit it without having to navigate menus. There is nothing more frustrating than knowing a setting is wrong in your profile and not being able to change it without going through a list of menus, hoping to stumble on the right page.

User efficient, not machine efficient

There are plenty of other examples of where contextual user interface design can really improve the efficiency of your interface. Remember that you should aim to be user efficient, not machine efficient. Don’t get hung up on the idea of a link or option only being accessible from one place. Make it accessible where it makes sense, not just where it fits in a menu or structure, and your users will thank you.

UPDATE: Mark Notess made an excellent observation in the comments below about programmers not putting in enough time and effort to ensure the interface is as easy to use as possible.

To your “user efficient vs. machine efficient” I would add “programmer efficient”. I think many cumbersome designs are simply the result of programmers not putting in the time so users don’t have to. We want user efficient designs rather than programmer efficient or machine efficient ones (as long as it isn’t so machine inefficient that it slows users down). Simple things, like with travel when you have to enter a start and end date for hotel stays or airline reservations: when you put in the start date, you shouldn’t have the option of putting in an end date that precedes start date!

I guess the first thing anyone will notice when opening Safari 4 is that the tabs have now moved directly to the top of the application window, ala Google Chrome. I won’t beat around the bush; this part of the UI is horrible.

Safari 3

Safari 4

Moving tabs

Because the tabs are at the top of the window Apple have had to introduce an icon that allows you to move the order of the tabs around. Now I don’t know about you but that icon looks suspiciously like the resize icon that appears in the bottom right of Safari 4 (and all other windows), with the only difference being it has been reversed vertically!

As soon as I saw that icon in the tabs I wondered why Apple would let me resize individual tabs, but no, apparently that is the icon for moving something. If only there was an icon that symbolised movement. Oh, how about this icon?

The best solution would be to just not show an icon, but Apple can’t do this. Because the tabs fill out the whole width of the application, with no space below or above, they have had to allow you to move the window on your desktop by dragging the tabs around. This contradicts all other browsers on the market, which means users are going to have to change their behavior just to use Safari.

One of the best ways to get people using your product is to keep it familiar to what they know. Car manufacturers understand this extremely well and keep the same order for accelerate, brake and clutch pedals. By doing this cars don’t change the drivers behaviour at all and means they can simply get in, turn the engine on and drive. Not thought is required. No new rules to learn. Easy.

The first tab in Safari also has some issues with the minimize, auto size and maximise icons as they appear to be part of that tab. Take a look at this screenshot and you’ll see what I mean.

Hmm, why are those circle icons in my tab?

These icons apply to the window overall, not that particular tab, so a visual separation wouldn’t go amiss here.

Better, but not perfect.

Where is the progress bar?

When you make a phone call to a company and are put in a queue it’s nice to get a reminder of where you are in the queue isn’t it? Safari 3 had a similar way of handling this by showing you  a progress bar behind the URL in the address bar that filled up as the page loaded. This was a nice way of showing the user how much longer it was till the page was done loading. For some bizarre reason Apple have decided that this is not needed in Safari 4 and have simply replaced it with a spinning icon that gives no indication of progress to the user.

About 1/3 of the way there.

Giving feedback to the user in an interface is key to making it easy to use and helps keep them sane. Imagine a DVD player that didn’t tell you how far into a movie you were and how much time was left. That would be pretty annoying wouldn’t it?

Refreshing the page

Ok here’s a little test for you all. How long did it take you to find the refresh icon in Safari 4? If you didn’t find it, look to the very right of the address bar and you’ll see it.

Now I can see why Apple have done this, the spinning loading icon replaces the refresh button while the page is loading and if you hover over the spinning loading icon you’ll get the stop button. All three of these UI elements are linked together and should be located within close proximity of each other, but I don’t understand why Apple decided to move this into the address bar. The back, forward and bookmark buttons all control the address bar in the same way the refresh and stop icon do, so why have they been given a different design treatment?

Rounded or not?

One really small thing that bugged me in Safari 3 was the rounded search box in the top right. The address bar was square, the search bar was rounded and the buttons were semi-rounded. You had three different styles in the header of the application! In Safari 4, Apple have managed to get the address bar semi-rounded but they’ve kept the search box rounded. This isn’t  a massive problem but I am somewhat alarmed that Apple have not noticed or bothered to fix this and makes a bad impression on Safari overall.

Seriously, how did they miss this?

Needs work

There are lots of things that are great about Safari 4; the new address bar results are nice, the quick sites is very useful and it is VERY fast at loading sites. I’m sure Apple have their reasons for some of the UI choices and I wouldn’t be too surprised if we see some UI changes in Snow Leopard that reflect Safari 4 but overall I feel the UI feels a bit sloppy and rushed. I’ll be keeping with Safari 3 for now at least.

Update

Apple have since released the final build of Safari 4 which has fixed quite a few of the issues I’ve raised above, most notably moving the tabs back down to the same place as Safari 3 as well as being able to move them by dragging the entire tab, not some random image/icon. Much better :)

This has been a breath of fresh air, but many websites are using this “one size fits all” language when users really need to know a bit more detail. Errors are going to happen in your interface, it’s a fact, so when the time comes do you want to help the user or frustrate them even more? Language plays a vital role in deciding which way you’ll go.

Don’t be lazy, give me the info

There is a time and place to be chatty on the web and one of those is not when something is going wrong. When a user comes across a problem on a site they want to know exactly what went wrong and why. Generic “Doh, my bad” sentences have no place here as they don’t mean anything, it’s just fluff.

Login forms are one of the biggest culprits. Most websites simply telling you “Either your username OR password is incorrect” if you enter your login details incorrectly. Now, this isn’t a problem for people who visit sites daily and have it saved, but what about those sites you rarely visit and can’t remember if you have an account their or not?

Facebook.com – What email address did I register with? No idea.

Why can’t they just tell me which piece of information is incorrect so I might actually be able to better understand if I have an account with you already or not? This IS helpful information to the user and removes any questions.

Thumbslap.com – Half the battle is done for me without any thought on my part

Does it make sense out loud?

As with a lot of manuals I sometimes wonder if web designers/developers even read or look at their interface after they’ve built it or perhaps it’s the fact they see it so often that things are missed.

The social bookmarking site Delicious is one of the sites that could do with some editing. The main action for a user on Delicious is to add a bookmark, so I found it slightly odd that the “add bookmark” page on Delicious made me think a little too much. The picture below highlights an area of their interface that let’s you change the order of your tags – nice idea, bad wording.

Delicious.com – This doesn’t sound right. What is Alpha anyway?

Firstly, the words in this bit of interface make no sense when read out loud. Go on, try it. Sounds odd right? Secondly, why don’t they just say “Alphabetically”, they’ve got plenty of room to the left.

Below is a screenshot of the revised wording that I think improves on the original as it makes sense when read out loud and also makes it clear what the actions will do.

Ahh, much better.

The next time you’re not sure about the wording of your interface, read it out loud and see if it sounds right. People will read out the words on your site so you’d better make sure they make sense.

On a side note I’m still trying to find out the right length of article on this blog so I would love to know if you think this is too short, too long or just about right.

Here are some tips and thoughts on how I layout forms. Sorry if some of this is super obvious to you already, I thought it best to cover everything in case some people out there don’t know.

Fieldsets

Every form should have at least one fieldset. Don’t know what a fieldset is? Fieldsets group items together where it makes sense. If you have a form asking for an address and credit card details, I would suggest having both of these in their own fieldset.

Legends

Every fieldset should have a legend. Legends describe what the group of form elements are or do. Using the same address and credit card detail example you could have a legend that said “What is your address?” and “How would you like to pay?” in each of their respective fieldsets.

Labels

Every form element should have an associated label. Labels link a description of the form element (input, select, radio, checkbox, textarea), but in some cases I don’t believe these are necessary to show for things like textarea’s as long as the legend is named properly. For example this site doesn’t show the label for the textarea in the comment section (scroll down to the bottom) as it’s overkill. Users are asked to add a comment if they wish, they know what the big box is used for as they’ve used it on other sites, so why bother adding unnecessary clutter to the page? The inputs on the other hand are all the same length and size , so without their label the user would have no idea what to do. The same goes for search boxes, why show a label that says “Search” when the submit button also says “Search”?

Inputs

You already know about this one (I’m hoping). Be sensible and don’t use it for something where you want an exact match to something in your database in case somebody spells something incorrectly.

Selects

Now this is an interesting element, and one of the most overused of all the form elements. Select boxes do a great job of hiding a large amount of options into a very small area but also have excellent discoverability due to their click affordance (the arrow pointing down). The main problem with select boxes however, is the same reason; they conceal options for the user.

Radio buttons are an excellent alternative to select boxes and in many cases should be used instead of a select box. Take these two pictures for example:

Select boxes for date & time make sense due to the amount of options for these elements (12-30 at least) so using radio buttons wouldn’t make any sense here as that would be information overload to say the least, not to mention it would take users much longer to fill out the form. But what about the Where, Game Type and Who fields? Of course, you don’t know how many options are behind these until you click on them but I can tell you there are no more than 3 options for each. This doesn’t sound like the right use of a select box to me, why not just radio buttons and show the user the options?

Now compare the first screenshot to the second. I think you’ll agree that not only is the form easier to fill out (less clicks for sure) it also gives the user a much better understanding of all the options available to them. After all, isn’t that what select boxes/radio buttons are meant to do? The rule I tend to stick to is for 5 or more options use a select box and for less than 5 use radio buttons.

Radio buttons

We’ve covered the use of radio buttons above so there isn’t much more to say on these. Radio buttons should be used for a set of options where you only want ONE answer, such as a rating system. I’ve seen a few sites replicate the functionality of checkboxes (where multiple answers/results are ok) and you can only think they did it because the like the look of circles over squares. Sigh.

Checkboxes

So when do you use a checkbox? As mentioned above use them if you are asking a user a set of questions and you don’t mind how many answers/results you get back. A good example would be something like a user settings page that allows users to select which email notifications they would like to receive, they can either select all of them, some of them or none of them.

How long?

The length of an element gives the user immediate feedback on what type of data they should be entering or alternatively, what they are being asked for. Take these two pictures as an example:

Notice the CV2 field in both images, this is the 3 digit security code that is on the back of your card (except for American Express which is actually 4 and on the front!). The first picture makes it clear without even looking at the label roughly how many characters to enter in the field due to its length. The second picture on the other hand, doesn’t make it clear without first reading the label. This is a really small thing, but it speeds up the process a lot. As Steve Krug says, “Don’t make me think”!

Phew, I think that’s about it. I’m sure I’ve missed some things and I am as guilty as any for disobeying these guidelines at times but overall I hope it gives you some ideas on how to make your next form, or existing forms, even easier to use.