Find the link…

I’ve signed up to receive our power bill via email.

So, I get an email telling me our latest bill is now available online.

Here is the page I’m redirected to.

It’s not the bill.  

It’s a landing page full of noise.  

See how long it takes you to find the link to the bill.

(click for larger size)

There are actually two links.  Neither of them exactly jump out at you.  

I never even noticed the link in the top-right until I took this screen shot.  This is not especially surprising as this position is so often used for advertising that people will just block it out.

It’s reasonable to assume that the link would be somewhere in the body of the page, but as you scan that area everything which looks vaguely like a link says “Find out more >”.  More about what, exactly?  

Why don’t they link directly to the bill, I wonder?  

Or even better simply include the important information (e.g. total amount owed and due date?) in the email itself and let me avoid this hassle altogether.

Is online billing about making things easier for customers or creating opportunities for the marketing department?

Mobile Banking [Guest Post]

This is a guest post by Jay Nielson from Kiwibank. Enjoy!

To coincide with the launch of the iPhone in New Zealand, we at Kiwibank decided to launch a new Mobile Internet Banking system. We knew from the start that we wanted to support many different devices, but unfortunately, we were stuck with a full timeline of just three weeks. We had this time to design, build, test and implement essentially a new Internet banking platform and we had one developer and one tester to do it.

My name is Jay Nielson and I was that developer and I’m hoping that this guest post that Rowan has allowed me to write will give a bit of insight into how we approached this project, some issues we came across, some of the tricks we found and lessons we learnt especially for developing for the iPhone.

We launched the first version of the site in July with basic support for the iPhone. Of course, we wanted full support for many devices, but the iPhone was going to bring the publicity that a basic site may not be able to. Behind the scenes we set up the architecture of the site to be able to dish out completely different code depending on the device.  We were able to include different style sheets as necessary and, of course, different images.

For example in the latest version, the login page is designed to fit the device if you’re browsing on an iPhone but is stripped down if you’re browsing on a simple Sony Ericsson phone.

iPhone Login Page

Mobile Phone Login Page

We knew from the start that there were other mobile sites out there but the difference between us and them is that we never meant to have just a single version of the site.

We had the basic design used on some of our other websites from our design company (Springload in Wellington) to use as a base. Because our current site is written in classic ASP (and I know that site inside out) I decided that the limited amount of time we had meant that the site was going to be built with the older technology, with a rewrite at a later stage.

I developed it with a very rudimentary controller/presenter system where I bought all the page logic out from the presenters and left them to render the page as they needed. This was the way I managed to easily add new device support – with the page logic separated out (and most of the presentation data bundled into classes) adding new device support was easy. As for detecting the different devices we found plenty of information on the net about which phones use which user agent strings, it was just a matter of finding the common attributes and taking them out. In all there are about 20 checks to determine the 6 different devices (iPhone, Browser, Windows Mobile, Mobile, PalmOS and Blackberry)

We decided to include the 90% most used features of our Java mobile application:

  • View Accounts;
  • View Transactions; and
  • Transfer funds.

We restricted funds movement to only within your own accounts, which allowed us to defer implementing the KeepSafe security used on our other sites.

The trick with all of this is getting the site working as a web page but looking like an iPhone application that people are familiar with. This meant big buttons, simple layout, uncluttered and to the point. Our friends at Springload helped immensely at this stage.

The biggest issue we had with the iPhone (apart from being able to only test on a Mac) was the fixed width.  Browsing the web on the iPhone is pretty simple. The device can render the page using Safari and you simply zoom in and out with a pinch motion with your fingers. Now, there are META tags you can add to the heading of the page to restrict the zoom levels and while they are pretty straight forward, but the device would never seem to return the text back to the font size it was to begin with after you rotate it to landscape mode. A bit of research was needed and we found the following code seemed to overcome it:

<meta name="viewport" content="user-scalable=no" />

<meta name="viewport" content="initial-scale=1.0" />

<meta name="viewport" content="maximum-scale=0.6667;" />

<meta name="viewport" content="width=device-width" />

<meta name="format-detection" content="telephone=no" />

The first four lines dictates that with width and zoom levels are to be static while the final one stops our accounts numbers being turned into phone numbers for auto dialing!

iPhone Accounts Page – with option to rotate to widescreen for more detail

With the iPhone version of the site working it was release time. We got it live the day before launch and have received positive reviews. As far as marketing it went, we decided to keep it a little low key and went more for word of mouth with a single press release rather than full page newspaper ads. It worked well. As far as our estimates are concerned, we had about 10% of the iPhone sold in New Zealand logging in and the only limiting factor was that no one could buy any more – we’re still waiting for our three to arrive!

Something else we tried which we haven’t done much before is to be quite open about it. We posted on blogs, answering questions people had and set up email addresses for feedback. We knew this was going to be an iterative process and took steps early on to get the feedback from customers that we needed.

With the launch a success we looked to the future. We had given out an email address for people to post their ideas about the site and the number one requested feature was support for Windows Mobile, so of course that was a priority in the new release. There were a few layout issues as well we needed to fix, but we also decided to try out hand at multiple language support.

A little addition that I wanted to sneak in was changing the page layout to display more information if the iPhone is rotated to landscape. There are a few issues at this stage, but the concept works perfectly. On Rowan’s post about us, the comments got into renaming accounts. I added that functionality in as well after the discussions there.

The latest version of the site, launched this week, now has the extra features we wanted including support for multiple languages, starting with English (the default), Russian (as the tester’s wife could speak Russian and it was a perfect way to test international character sets) and my favourite, Swedish Chef Bork Bork language, for a bit of fun (Bork! Bork! Bork!). All the language strings needed to be taken out and are stored in a database which is then cached in the session for the customer when they first log in (or change their language). I created a C# GUI front end to that database to allow us to update/add new string values without a full release of the code. In reality, we could release Arabic tomorrow without any updates to production. The language strings are per device and per language. So for mobile, if needed, we can summarise a lot more text as it has a smaller screen real estate.

Login Page – Russian

Login Page – Swedish Chef!!

The new version of the site works on the iPhone, Windows Mobile devices and mobile phones with sufficient browsers.

To top it off we have even been nominated for three TUANZ awards, including innovation of the year so wish us luck on the 28th.

We’re always looking for new ideas and feedback and would love to hear it. You can email us at

From Rowan:

Given that most of their competitors measure their progress in months or even quarters, I think it’s great to see a bank turning something like this around in just three weeks.  And also to iterate quickly – already they have released a second version which incorporates a lot of the feedback they’ve received following the launch.

Plus can you imagine any other bank launching a Swedish Chef version of their site?  It’s fantastic!

What do you think?  If you’re a Kiwibank customer, how do you find this application?  If not, would a good mobile app be enough to make you switch?

I’m interested in your comments.

Also, if you’re interested in writing a guest post here about something you’re working on please feel free to get in touch.  My email address is on the right hand sidebar.


The iPhone has been a catalyst for a number of mobile versions of popular sites, including many I use most days:

Xero, NZ Herald (*), TripIt, Kiwibank, Google Reader.

(*) if you haven’t discovered I recommend you check it out – I’ve completely abandoned Stuff since they launched this.

I’m interested to see how these mobile versions have been designed.

They don’t try and cram in too many features.  They use super large fonts and large buttons, and as a result there is not a lot of room on each page for too much noise.  The things you can click (or do we say “touch” now?) are immediately obvious.

They are not bogged down by lots of unnecessary images or scripts … so they are FAST!

Here is a quick comparison of the corresponding login/home pages:

Site Version Page Size Download
Xero Standard 938.4kB 7.86s
Mobile 12.7kB 2.92s
TripIt Standard 334.2kB 8.15s
Mobile 13.7kB 1.78s
NZ Herald Standard 595.8kB 8.89s
Mobile 126.5kB 3.58s
Kiwibank Standard 69.5kB 4.79s
Mobile 34.3kB 3.06s
Google Reader Standard 71.1kB 3.82s
Mobile 3.7kB 1.12s

I realise that this is completely unscientific.  For example, I used an empty cache in each case.  No doubt many of these sites are faster the second time you visit because of caching.  I also tested only one load of each page, and there are any number of things which could have caused the speed to vary.  And it’s a somewhat random sample of sites to choose.  But, I hope it is a rough drawing of the point I’m trying to make nonetheless – that is, the mobile versions are much smaller and as a result much faster to load.

I wonder how much of this thinking will filter back into the main standard browser versions of these sites?

Hopefully designers and developers will start to see the benefits of some of these things (less design, bigger fonts, etc) into ALL of the sites they work on, whether intended for mobile users or not.

At the extreme of this trend is a site like Muxtape which only has a mobile version of their site.  If you visit using a normal browser, you get the mobile version – a simple, fast-loading page with big obvious design elements.  In other words, you get a great usable webpage.

Which makes me wonder … if I’m just wanting to see the latest headlines, check my balances or lookup a travel booking, why wouldn’t I load the mobile version of these sites in my standard browser, rather than waiting around for the full versions?

Loving TripIt

I’ve raved about TripIt here before.  But, it’s worth repeating.  If you travel a lot and don’t use this service you’re missing out.

Here are a couple of aspects of their service which I’ve only recently discovered, which make it even better …


They now have a version of their site designed specifically for mobile browsers, so you can quickly and easily get details of your itinerary and bookings from your phone on the go.

They’ve even included a “Check Flight Status” link for upcoming flight bookings, which is very handy.

More information

2 iCal feeds

Previously whenever I booked flights I would manually add the details to my calendar – including times and flight numbers etc.  I would also usually enter an all-day appointment for the days I was away, so I didn’t accidentally make other appointments when I would be out of town.

TripIt can take care of all of that for you automatically.

Just add the iCal feed to your calendar and any trips and flight bookings will automatically show up on the appropriate dates.

Those two things aside, the single greatest feature of TripIt is still the complete lack of data entry required – just forward on the confirmation emails you get from airlines, hotels and rental car companies and they will pull them all together into an itinerary for you automatically.



Enough slagging off banks, let’s talk about some of the good things some of the NZ banks have been doing lately …

I see Kiwibank have launched an iPhone version of their online banking site.

Very cool.

I love it how they have stripped back the functionality to just the essential bits – check your balance, transfer money.  The only thing that’s possibly missing is making a payment.  As a result the interface is not cluttered with lots of unnecessary noise.

However, look closely at the screenshots and you’ll see an interface still dominated by lots of mostly meaningless numbers.

Is “38-9007-0581259-00″ your cheque account or your savings account?  Or your company account?  Or maybe your joint account for shared expenses?  You’ll have to either have a memory for long strings or (more likely) guess based on the balances.  But, good luck with that approach on the transfer screen – there are no balances displayed.

As far as innovations go I’m much more impressed with a small change that ASB recently made: you can now name your own accounts.

So simple.

You can choose names, like “Cheque” or “Savings”.  But, if you like, you can also call them whatever you want.  Use this to your advantage – I imagine it would be much harder to frivolously spend money from your savings account if it was called “Fiji Trip”, for example!

Little things…


Affordance is a simple but powerful idea.

I first came across is in Don Norman’s book The Design of Everyday Things, but according to Wikipedia it’s much older than that.

At Webstock this year Liz Danzico defined it as: “providing uninscribed and detectable cues that loosely govern a set of actions or interactions”.

I would say: “make it obvious to me what I can or should do with things”.

The classic textbook example …

When you approach a swinging door how do you know which was the door opens? Do you push the door away from you? Or pull it toward you?

The “handle” that’s placed on the door should make this obvious.





If you think about it the flat piece of metal with the word “push” commonly placed on doors is an odd design element. It has no real purpose other than to remove the doubt about the direction of the door, and perhaps to indicate where is an appropriate place for your hand to push. But, we’d struggle without them.

Some other examples from web design:

  • Links should look like links (i.e. normally blue and underlined)
  • Buttons should look like buttons (i.e. rectangular with a label, and probably with a subtle 3D effect to give the impression that you can press them in)
  • Scroll bars should look like scroll bars (i.e. to the far right of the page and, ideally, using standard controls from your operating system)
  • Tabs should looks like tabs (i.e. with the selected tab appearing to sit physically in front of the other tabs)

Notice a pattern here?

What other affordances make your life easier every day without you even noticing?

Who’s using RSS?

The stats for this blog show that most readers are using a feed reader of some kind (predominantly Google Reader).

But, that’s not normal.

Matt Mullenweg has posted some stats across the entire WordPress universe of blogs for the month of May, and the numbers make interesting reading:

  • Active Blogs: 965,041
  • Page Views: 1,134,796,234
  • Page Views (in an RSS feed): 71,351,276

In other words, fewer than 7% of page views to WordPress blogs are via a feed reader.

I’m sure that number is much lower than most technical people would assume.  Not using a feed reader is so inefficient, eh, and who would be that silly?!

Don’t assume that everybody is like you.

Speed is not a problem you can solve

There are, in my experience, two types of websites:

  1. Websites which are slow; and
  2. Websites which are noticably slow.

It’s important to understand which of these categories applies to your site.

If the people using your site tell you that they think it’s slow then you are definitely in the second category.

What you can do about this?

Also, you can make sure that you include time in your work plans to make small performance improvements whenever you make changes to the site. This is important because (despite developers expectations to the contrary) it is unlikely that the day will ever come where you’ll be able to stop working on new features or bug fixes in order to just focus on performance.

Making your site faster needs to be part of what you constantly do, rather than something that you hope to have time to work on at some point in the future.

We’re not normal

This week web folk from around the country will head to Wellington for Webstock (shouldn’t it really be Webstock 2.0?) to hear a great line-up of speakers coming here from around the world (some of them are here already).

So, it’s timely to remind ourselves just what an unusual bunch we are.

Here are some browser stats the Webstock organisers recently published on their blog:

Firefox Internet Explorer Safari

And, here are the equivalent numbers for Trade Me in January:

Firefox Internet Explorer Safari

Spot the difference?

We’re not normal, but if we put our mind to it we can empathise, surely?

PS I use Firefox on my chunky Mac, so if I’m throwing stones here I’m throwing them at myself first. :-)

Registration Revolution

If you do any traveling and you haven’t yet discovered I strongly encourage you to check it out.

(You also need to go and subscribe to Joel Spolsky’s RSS feed. He wrote about this at the end of last week, and if you’re reading my blog and not following his articles then you clearly have things in the wrong order).

All you need to do is find a booking confirmation email from an airline, hotel or rental car company and forward it via email to They will convert your email into a simple itinerary page for your trip and send you back a link. If you have other bookings to include in the same itinerary, simply forward them on.

No more searching through your inbox to find all of these confirmation emails before your trip, which is good.

But, what’s really great in my opinion is that they have revolutionised the registration process. In fact they have eliminated the registration process altogether. By making the first interaction email based there is no need to fill in a cumbersome form on the website – entering you email address twice to make sure you don’t have any typos, choosing a password (which we all know usually means entering the same password you use on more or less every site), waiting for a confirmation email and then clicking on the link to validate that your email address is actually yours, etc etc. All of that is history.

I really like this idea – replacing a complex process with a simple email – and I think it could probably be used in lots of different situations.

Are there other websites ballsy enough to replace their entire registration page and process with an email address?

Are there any other examples of email-as-interface that you’ve seen out there? If so, I’m keen to hear about them.

Getting to the third user

The scene: some developers are observing their first usability test on some software they have built.

The first users walks in and completely misses the seemingly obvious cues in the user interface. The button the user needs to click might well be big and red and flashing with a marching ants border, but they just don’t see it.

“Dumb user” everybody thinks.

The second user walks in and also ends up hopelessly lost.

“Two stupid users in a row … what are the odds?”

The third user walks in. Same story.

At this point, the smart developers in the room are, hopefully, slapping their foreheads and thinking “how could we have been so stupid”.

The key here is getting to the third user.

Otherwise you haven’t really learnt anything.


Anybody who has worked with me on UI design will be familiar with my sarcastic request for a marching ants border. I always assumed this was impossible in HTML, but apparently not …

How to add “marching ants” Photoshop selection style to your links


Garr Reynolds Wisdom, Part II

This is Part II in a two-part series. Part I was published on 24-Jan.

Another one from Guy and Garr

Question: What is the single most important thing people could do to enhance their presentations?

Answer: Turn off the computer, grab some paper and a pencil, and find someplace quiet. Think of the audience. What is it they need? What is it you want to say that they need to hear. Identify what’s important and what is not. You can’t say everything in a twenty-minute talk—or even a two-hour talk.

The problem with most presentations is that people try to include too much. You can go deep or you can go wide, but you can’t really do both. What is the core message? This time “off the grid” with paper and pencil or a white board is where you can clarify your ideas and then get them on paper visually. After your ideas and basic structure are clear, then you can open up the software and start laying out the story in the slide sorter view.

Replace the word “presentations” above with “software” and the same great advice holds, I think.

Certainly the part about turning off your computer and spending some time thinking about what your audience needs and considers important, as tempting as it is to jump straight in and start coding.

But the real gem here in my opinion is the observation that you can go deep or wide but not both.

Just like presentations I think that most people building software try to include too much. Adding more features is a natural inclination. It’s actually ingrained in the social order of software developers – within teams enhancing existing features never seems to have the same status as adding something new. But, it should.

Can you have both the most features and be the easiest to use?

When you look around there are not many examples of software products which have achieved this.

So which of these two alternatives are you choosing, consciously or otherwise?

Garr Reynolds Wisdom, Part I

This is Part I in a two-part series. Part II was published on 25-Jan.

Garr Reynolds from Presentation Zen (who I’ve linked to before) recently answered a bunch of questions for Guy Kawasaki.

Ten Questions with Garr Reynolds

It’s a great post and I recommend that you read it. But a couple of the questions and answers especially jumped out at me. I thought it was worth highlighting them here – one today and one tomorrow.

Question: Are PowerPoint and Keynote part of the problem or part of the solution?

Answer: There is no question that PowerPoint has been at least a part of the problem because it has affected a generation. It should have come with a warning label and a good set of design instructions back in the ’90s. But it is also a copout to blame PowerPoint—it’s just software, not a method.

True, the templates and wizards of the past probably took most of us—who didn’t know any better anyway—down a road to ‘really bad PowerPoint’ as Seth Godin calls it. But today we know better, and we can make effective presentations with even older versions of PowerPoint—often by ignoring most of the features. Ultimately it comes down to us and our skills and our content. Each case is different, and some of the best presentations include not a single slide. In the end it is about knowing your material deeply and designing visuals that augment and amplify your spoken message.

How depressing to have an expert like Garr is telling people that the best way to use software is to consciously avoid features. Of course, he’s right. But, what a waste of time spent designing, developing and testing those features. Imagine instead if that time was invested in those parts of the software that people should use.

What’s more, not everybody is lucky enough to read this sort of advice. Death by bullet points is still the most common presentation experience.

Who is responsible for that outcome?

Those of us who design software should always focus on guiding users directly into “The Pit of Success”.

“In stark contrast to a summit, a peak, or a journey across a desert to find victory through many trials and surprises, we want our customers to simply fall into winning practices by using our [software]. To the extent that we make it easy to get into trouble we fail.”

– Rico Mariani, Microsoft Research (quoted by Brad Adams).

You need to make the right way the default. A new user should be able to just follow their nose, make the obvious choices, and end up in the right place.

Of course, this requires that you take a view about what the “right way” and the “right place” actually are (even where this requires you to be a bit of a dictator).

I think this is where software developers often let themselves down – by giving users almost unlimited flexibility, giving all features equal prominence in the navigation, by adding all of the features that users ask for (as opposed to those features that are required to get them most directly to the desired place), etc etc.

Those working on PowerPoint over the years have fallen into all of these traps.

As have many of us.

BONUS: Garr has a new book, also called Presentation Zen. If you do any public speaking, or even in-house presentations at work, go get a copy.

400 pixels or less

One of the fundamental decisions for a web designer to make when working on a new site, or updating an existing one, is what canvas size to allow themselves.

At the risk of showing my age, when I first started working on the web one of the key questions was how the site would look for those using a monitor with a resolution of 640×480 (for the younger readers: this wasn’t THAT long ago!)

Thankfully, time and screen sizes moved on.

When we updated the design of Trade Me late last year we increased the standard resolution that we supported up to 1024×768, although with code in place to ensure that the site still works well at 800×600.

If you’re interested load up the home page and try re-sizing your browser window – you’ll notice that, thanks to the magic of JavaScript, at 800×600 the logo and advertisment in the top-right corner jump up above the tabs and the font size on the category links in the body of the page is smaller.

By comparison, Xero, which has slightly more modern browser requirements, uses a fixed-width design which more-or-less fills the screen at 1024×768.

Why is this stuff important?

Well, as it turns out, people are not so quick to increase their screen size or resolution as web designers like to think.

Whenever I speak to a tech crowd I normally ask for a show of hands from anybody who is using a low-res screen (lately that has been 1024×768 or less). It’s unusual for anybody to raise their hand. But, out in the real world there are still plenty of people browsing at that resolution.

In fact many thousands of them…

Using the Neilsen Online stats for September ’07 of the ~3.5 million unique visitors to Trade Me during the month around 15% of them were using a resolution of 1024×768 (that’s 515,000 visitors) and even more incredibly just over 4% were using a resolution of 800×600 (that’s 145,000 visitors). Many of these people will be using a monitor that is capable of a higher resolution, I’m sure, if only they could work out how to increase it!

At the other end of the spectrum there are a number of different very large resolutions now in use. I’m typing this on a screen that is bigger than could have even been conceived of in the late 1990s, which of course makes life difficult for sites like Trade Me that use a liquid design.

Where it really gets interesting is when you look a little further down the list of browser resolutions. For example, the fifth most common resolution, with 1.82% market share is 214×138. That’s pretty small!

After I mentioned these numbers at the WDANZ conference I spoke at in Auckland a few months back Harvey Kane from RagePank picked up the analysis and came up with some even more interesting findings.

He made the observation that what really matters is the number of horizontal pixels available.

He looked at the Trade Me data and found:

Horizontal pixels Market share
400 or less 14%
800 or less 22%
1024 or less 45%
1280 or less 77%

That is a lot of people using little screens! Presumably many of them handheld/mobile devices?

So, there might be a role moving forward for those of us who remember designing for tiny resolutions after all! :-)

The lesson from this…

Design for your audience, not just for yourself, and always remember that they are probably nothing like you.

Right column navigation

It’s a brave person who challenges design conventions…

“Traditionally navigation on the web either appears on the left or at the top. Right hand navigation has somewhat been frowned upon. However, more recently this trend seems to have been changing with more websites adopting it. I think this is partly due to blogs, which seem to have right hand navigation by default. However, it has always struck me as strange that the convention is towards left. If you think about it there are a lot of good reasons for right hand navigation…

  • It puts the content first visually
  • Your cursor naturally hovers near the scrollbars on the right
  • We are familiar with right hand navigation from tabs in books
  • We know from usability research that whether navigation is on the left or right, it makes no difference in the time it takes to complete a task

Overall I am hugely in favor of right hand navigation and I am glad to see it becoming more popular.”

From: Emerging Design Trends

What do you think? Agree or disagree?