Widgetopia

FedEx Transit Time Calculator

I arrived on this page to calculate international transit time for a FedEx package before sending it. The image shows the second step of the process. The first step involved selecting the two contries and the date of shipment.

I liked the fact that they seemed to have eliminated the "State" field, making it easier for me to enter just city and zip. But after I filled in the city, I learnt that the Zip field was actually optional. This was a bit annoying. Why is an Optional field blocking my way? An easy solution would be to move it alongside city.

The name of the city I entered is not unique so I'm required to select the correct one from given close matches. This is a clarification feature but why does FedEx displays it as an error message? Although they try to reduce the pain by taking an apologetic tone but it doesn't make sense. It's not their fault that there are 18 cities in the US with the name Austin!

I would not have gotten this error if the previous page carried a State field. Obviously, at some point in the design process a decision was made to keep State out of that page. Whether it was the correct decision should depend upon the uniqueness of an average city name entered in the field.

If most users get through to the next step without getting this message then it makes perfect sense, otherwise it's a bad decision. So I decided to conduct a little experiment to see what happens when I entered random city names. I collected names of five US cities from a listing of the safest cities in the country [#1-5] and tried each one on the form. After every attempt I took notes.

1. Amherst
There are 12 close matches
Yes Amherst, New York is present

2. Brick Township
There are 20 close matches but no Brick Township in New Jersey. Instead, I see three matches that are similar:
Brick, New Jersey
Brick Town, New Jersey
Bricktown, New Jersey

I don't know what a real user would do now. Clicking the Quick Help button opens a pop-up that doesn't help. [Note the previous page had a link for finding the Zip code for a location, to which I didn't pay any attention so it doesn't occur to me to head back. Even if I do head back, the link would offer no matches for Brick Township].

3. Mission Viejo
2 close matches
Mission Viejo, California is present.

4. Simi Valley
Bingo! I get a confirmed match.

5. Cary
6 close matches
Cary, North Carolina is present.

So, in 4 out of 5 cases I got the same error message and there were a total of 41 close matches for five cities. Clearly conclusive evidence that it's not a good idea to remove the State field on the form.

In view of the poor support for the city field, it also makes sense to prioritize Zip to a better position - entering zip eliminates the chance of an error. That doesn't mean making it mandatory which would cause further harm. It means making sure the user understands that entering Zip is a better option than just entering the name of the city.

Bad billing

from Dreamhost

I'm extremely fond of my ISP, which is composed of friendly helpful and smart folks who perpetuate some of the worst design crimes I've ever seen on a regular basis in their homegrown interfaces. One of these days I'll get ambitious enough to outline the monsters. The one in this post is a misdemeanor, but I thought I'd capture it since it's simple.

Small issue #1: the credit card icons are not functional.
From a technical point of view, it's not necessary to have a user enter the card type; it's implicit in the number of the card. However some businesses ask for it; some do not. Users are asked to do so often enough that they will expect to enter the type of card.

Also, in Dreamhost interfaces, almost everything is functional, so the cards seem like they are the tool for selecting card type. At first I tried to click them, then when I realized they didn't click, I looked for a place to select what kind of card I had to enter. Which didn't exist. A few seconds wasted annoyingly.

Since dreamhost is merely showing what cards they support, a bit of explanatory text-- we accept X,Y, Z-- would go a long way.

Small issue #2: Unlabeled boxes

I entered my name above. then when a started to enter my billing info, I entered the street address in the first line, the city and state in the next. Then I got confused--- what was the third line for? It took me a second to realize they wanted my name in the first line. Why not label each line, to avoid confusion?

Affordances are not enough.

One good thing; they do address the problem I noted in the ryze guestbook writeup with some warning text-- just click this once. Considering that folks would not care to be billed twice, it's good advice.

I still love you Dreamhost, you provide good functionality, you are helpful and stable. Someday I hope you hire an interface designer.

name entry

Found on yahoo.fr, in mail set up.

Note that unlike USA sites where first name is usually the first field, here we see last name first, first name second.

localization

Found on yahoo.fr, in mail set up.

French data entry field in the French order: day, month, year.

date entry

This date entry format avoids typos by using dropdowns, but limits the number of dates one can choose. Also, the dropdown quickly becomes unweildy.... even though there are only twelve months, thirty one days is a bit much, and how many years are possible? Considering photography was invented in 1816, 187.

Ofoto avoids this by only going back to 1991. Considering scanners allow me to put my great-grandmother's silver plate photos online, I'm not sure that was a good assumption. I find it odd you can make an album set in a future before you've taken your photos. I can make an album set in 2013 right now, but can't make one before 1991.

date entry

Simple and clear-- the affordances are good-- the year field is four characters, the day is two. Helpful text underneath. One question... month dropdown has a choice that is a dash... would it have been better simply to have January showing? Also, the tip says mm, but the dropdown is in "month" full word format... tiny thing, but not quite right.