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 email@example.com
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.