How FedEx.com Could Increase Customer Satisfaction and Profits with 10 Minutes of HTML5

Earlier this week I needed to setup a FedEx account to have a package delivered. Since I use my iPad for most web site interactions these days I decided to sign up using the tablet and the on screen keyboard. Needless to say the experience did not go well or I would not being this as a teaching opportunity. I was able to register, but it could have gone much better and taken quite a bit less time. So today I am going to show how spending about as much time as a typical user needs to register FedEx could radically increase customer satisfaction, increase new customer registrations and reduce overhead by having frustrated users contact FedEx support channels for help.

Mobile devices are becoming a common way to access the web and devices like the iPad, Android tablets and upcoming flood of Windows 8 tablets are large chunks of market share from classic desktop and laptops. Mobile commerce is growing by numbers similar to the mid 90s when consumers began shopping online in large numbers, giving way to huge growth in package delivery companies like FedEx and UPS. So having a quality tablet experience should be a top priority for FedEx and any company wanting to interface with modern consumers and businesses.

If I have not shared enough on my blog or you have not been to one of my recent presentations on mobile development I preach a mantra of developing touch/mobile first. This includes form design. The first rule of thumb in the modern mobile, touch first architecture when it comes to online forms is to minimize the amount of fields a user needs to complete. The next rule is to drive the soft keyboard to accommodate the user. Next you want to provide the customer as much guidance and real-time validation as possible. Fortunately HTML5 gives us some new tools to enhance input types with browser native functionality.

When you create a new user on the FedEx.com site it is a two part form. The first part collects basic contact and shipping information. The second part collects credit card information. Knowing what I know about e-commerce and shipping I am not sure they could streamline the fields in the forms much more than it is. But what they could do is spend about 10 minutes of time upgrading their form's markup to leverage the new input types and attributes to drive a much better user experience.

For a traditional desktop user these fields add some value, but where they really help is on today's touch interfaces, like the iPad. As I will show in the screenshots below there are numerous times the experience could be much improved with very little additional markup. As tablets and smartphones become more and more ubiquitous utilizing the new HTML5 features becomes a required feature of any web form.

To start with, the first time you load the FedEx site you are prompted to select your home country. Not to divert from the main thread of this post, but using the built in geolocation functionality would make this a lot nicer the majority of time. You have a drop-down list to select your country. And FedEx does list every single country in the world, which is a rather long list to scroll through. You may be asking why not just use the keyboard to type the county? And yes that would be a good option, but most users will not realize this is an option.

NOTE: Tap or Click each of these screen shots to see a full-sized version.

After selecting your country and you have selected to create a new account the registration form appears. Another side note, make the link to open the registration form more touch friendly, just saying.

Personally I wish the first field had focus automatically set, but this is not a huge deal to me. However you could use the new autofocus attribute to make this happen.

HTML5 Input Types - http://www.w3.org/TR/html5/states-of-the-type-attribute.html#states-of-the-type-attribute

E-Mail

The first field I have a real problem with is e-mail. Because all the text input fields are type='text' there is nothing special about any of them. HTML5 has some great new INPUT types to help users enter correct values. One of those new types is email. These new input types provide a couple of things that traditionally have been the realm of JavaScript. The email type will cause touch devices like most smart-phones and tablets to display an e-mail optimized on screen keyboard. If you notice the screen shot below you will see the keyboard is a traditional QWERTY keyboard. But when type='email' an e-mail optimized keyboard is displayed. So instead of the a large space bar being displayed the @ key is displayed. The QWERTY keyboard requires you to select the numeric keyboard to access the @ key.

Additionally when using type="email" automatic validation occurs when the form is submitted. Again this is very helpful to users. One thing I have learned over the years is how little our customers actually know about the data we are collecting from them, in particular what is and is not valid. So any guidance we can offer can go a long way.

A second thing to note is how the first letter is automatically capitalized. This is often problematic because many systems are case sensitive. This too can be dealt with by adding autocapitalize="off" to the INPUT tag markup. As far as I know this is an iOS 3+ feature and not officially part of the HTML5 spec at this time.

Auto Correct

The next helpful feature new HTML5 input attributes offer is turning off Auto Correct. Last week I discovered the site, DamnYouAutoCorrect.com and found my self laughing in tears for about an hour. Some question the validity of some of the auto-corrected conversations, but after being corrected numerous times by all the current mobile platforms I think they are very believable. Just yesterday I sent a message with 'Tom' in it and auto correct changed it to 'Turk'.

I find iOS to be extremely frustrating because the auto correct just happens and you have to go out of your way to not have text changed. So instead of focusing on the keys, and if you are not a teenage girl most likely this applies to you, you have to keep an eye on that little balloon and disrupt your typing flow to tap it so the word you are typing is not automagically changed to something completely strange.

Fortunately mobile Safari supports the autocorrect attribute. You can set this to either on or off. Setting it to off will turn off auto correct for that input field, thus freeing your users to type what they need. Which when filling in an address could be very helpful on just about any field. Think about how many times some odd sounding street name or town would be improperly corrected without the user noticing.

Postal Code

My next suggestion is the Postal Code field. In the US this is going to be a 5 digit value. Sometimes users will actually know their 4 digit extension, but this is very rare. In fact the FedEx form is configured for 5 numbers. So setting it to type="number" is the correct choice. This will display the numeric keyboard, making it really easy for users to enter the correct value.

By default the input field will display up and down spinner buttons on a numeric field. In WebKit this can be suppressed with the following CSS:

input::-webkit-outer-spin-button,
input::-webkit-inner-spin-button {
   
    -webkit-appearance: none;
    margin: 0;
}

Applying the -moz- vendor code where -webkit- is used seems to suppress the spinner in FireFox. I tried adding -o- for Opera, but no luck. I am not even going to try Internet Explorer 9 because none of this is supported sadly. I believe we will see a much improved experience sometime next year.

I am going to sidetrack for a moment here because this is one of the things that has lingered with me for about a decade now. I have done hundreds of sites where a user needs to enter an address. Zip Code and address validation services are plentiful these days. I have had a full US zip code database for about 10 years now that I maintain through a subscription. It is real easy to lookup a city and state once the zip code is known. By convention we place the postal code field after the city and state, which make the user type both of those values. If you live in some city named by Native Americans you know what I mean.

With modern AJAX techniques, up to date postal code databases and address validation services I propose the conventional order of these fields be changed to Postal Code, followed by City and State. Not only are you releasing users from typing these values you are reducing the amount of errors entered that cause confusion later in work flows and create even more work later. In a few cases a user might need to select from a list of 2-4 cities covered by a zip code, but this too can be solved with a simple tap to select metaphor. For a company like Fedex this could probably eliminate thousands upon thousands of mis-delivered packages each year.

Phone Number

Back to how HTML5 can make registering for a FedEx account much easier, phone numbers. Again this is numeric, but we also need delimiters or at least the convention is to include grammatic delimiters like dashes or parentheses and dashes. I personally like periods or none at all. You can add some JavaScript to the mix to accomplish this, but with HTML5 comes the placeholder attribute. Here you can provide a valuable watermark to guide the user before they start typing in numbers.

Another new Input type is 'tel'. Like the 'email' type it will validate the user's input as a valid phone number using the native browser capabilities. It will also drive the on screen keyboard, making it much easier for the user to enter the correct values.

Credit Card

My next suggestion for FedEx's new customer registration is on the second page, where the user enters their credit card. The first field is really not needed. Credit card types can easily be detected using the first few numbers. 6011, for example means Discover, numbers starting with 5 are Master Card, Visa starts with 4,  3 === American Express, etc. But if you really must have the user manually chose a list of touchable brand icons are much easier for user to navigate. A user can simply tap the icon to select, swipe to select in Windows 8 and move on. Currently FedEx uses a drop-down list. While functional, not as simple. Icons are quickly recognizable and are easily touched.

Next the credit card number and security codes both need to be numeric fields. Since I have already covered this, I one spend more time here.

The next two fields are the expiration date. In the past I have use the exact same combination used on the FedEx site. However, in light of today's growing use off touch screens I think changing this to a more visible, touchable metaphor would be better. There are only 12 months in a year, so just list them, maybe in a 2 or three column list with the months touchable. Even a radio button list would work. Next the years, you are typically not going to need more than 10 or 12 years. Banks generally do not issue expiration dates beyond 3-4 years, but I have seen some as far out as 8. So covering 10-12 years should make you safe here. Again a touchable list is helpful.

One thing I did run into trying to select the year on my iPad was the list of years showing for a split second, then opening the list of months. I spent several minutes trying to select the year before I noticed the next and previous buttons at keyboard's the top left corner. I said aha! This was the tab button I had been looking for on the iPad. So I had to select the months then hit the next button to tab to the next field, the expiration year. I imagine 9 out of 10 users will not realize this and simply give up on registering, costing FedEx thousands of customers, hello UPS.

On a side note, I did consider the new date input types, but because this would lead to a user scrolling far in the future I thought it might not be as easy as just touching the month and year.

The remaining fields should all be numeric.

Finally, what about non-HTML5 browsers and those that do not support the Safari only attributes? This is where graceful degradation and polyfils come into play. Modernizr will 'fix' older browsers do you can still apply styles correctly to these fields, if you have created any custom styles. When a browser encounters a type it does not recognize it will just assume it is type='text' so the user can still enter the values be none the wiser. Also, yesterday Microsoft announced they would finally be automatically upgrading everyone to IE 8 and 9 yesterday, which is a huge victory for web developers everywhere! It also looks like Microsoft will support a large portion of the new input types and attributes in IE 10.

Another feature included in the latest Modernizr is Yep-Nope support. I wont cover that here, but basically it allows you to load any JavaScript functionality needed to implement unsupported new HTML5 INPUT features covered today as needed.

I have setup a jsFiddle page with some of the new input types needed for the FedEx updates for you to try out on your touch devices. I used it to create some screen shots and do some verification. I testing this sample in Chrome, Safari, FireFox and Opera as well as the iPad and a Motorola Xoom.

 

I hope this real-world example demonstrates just how easy it is to upgrade an existing form to make your users much more successful and satisfied with your web applications. My suspicions are if FedEx will spend about 10 minutes upgrading this registration form they will not only increase measurable customer satisfaction they will also have a measurable increase in new customer registrations. Applying these simple techniques site-wide will have an extreme impact for FedEx, especially when you count the daily volume their site supports. Even if your web application does not handle the same amount of volume as FedEx these simple techniques can go a long way to making you a success. Little things add up and mean a lot over time.

Share This Article With Your Friends!

Googles Ads Facebook Pixel Bing Pixel LinkedIn Pixel