Regardless, this post is not about that bundle. It’s about my checkout experience. It was amazing. Textbook UI for checkout. Here’s a screenshot of the payment section:

Lets talk about what they did right here. Firstly, they allow you to pick between Credit Card and Paypal. Note, they don’t make you select which type of credit card you are using. They only support Visa and Mastercard, and they can use the digits of the card to determine which you are using, so they don’t need you to provide that information.

Next two fields are standard, “Name on Card” is easy is enough to figure out and if you don’t you know where to find your credit card number, you’ve got bigger problems.

Next is the expiration date. Lets talk about what makes this field so great. Firstly, they list both the month number and the name. This is very clear. It shows you that you are talking about months and displays the context in relation to the month number. The key here is that they number is first. This means that if your browser supports it, you can start typing with the field selected and get straight to the month number. Also note how this field is a two digit number? Add clarity as the numbers will align in the pull down.

Next is the security code, they have a little credit card graphic to indicate where to find your code. Very helpful.

Next you move on to the address information. There is a clear separation between the Credit Card info and the address info. Breaking forms up makes them easier to parse. None of this information is overly hard, but large blocks of form fields can be intimidating.

All in all, this is the best online checkout experience I’ve had for some time.

Yesterday, I got an email about Mozy redesigning their website. When I first went to check it out, the site was unavailable. Not just the page they sent me to, but the entire site, mozy.com was down. That is a real good sign from someone you trust with your data. I mean it’s not a security concern so much as a reliability concern.

When the site finally did come up, I was putt off by parts of it. One part in particular and that is what I want to talk about now. Lets talk about blue text.

Before I get ahead of myself, here’s a screen shot of the entire site.

At first, not bad. Nothing that I think is radical about it. It wouldn’t make my list of top sites, but it is clean simple and clear. Looks like they have a good message and they are using imagery to convince me this is a personal company that wants to help.

My eye got drawn the gray box in the center of the page.

This was again, okay, because they want want me to sign up, and that is where the sign up link is. Alright. Now, I see “Mozy has a plan just for your size.” in blue text. Yes, there is a clear “Learn More”, but I see blue (highlighted) text and and I want to click on it. Granted I’m picky, but I believe if you have blue text it should be a link. Especially if you have content related to that text.

Take a second and look back at the main image. You will notice that in the boxes below, blue text does represent a link. In the “Sign up for Mozy” button, blue text is a link. In the “View the Mozy intro video” graphic in the top box, blue text is used for a link.

In this one case, blue text is just that, text. The link is right below it. This is confusing, and frustrating. I got upset and ended up not even clicking on the “Learn More”.

Why is blue text bad? Honestly, it’s legacy reasons. When the web was first recreated, links were highlighted in blue and underlined. With the introduction of CSS, many sites have switched away from blue text as a link.

Aside from legacy reasons, there is notion of consistency throughout the site. If you are going to use blue to highlight links, do it throughout the site.

Now I have been a big Facebook fan in the past, but of recent, I’m more dissapointed with them. I feel like they have started to remove the “fun” aspect of the application. Facebook used to be more about the network, and it is has turned into almost a twitter status message board. I’ve gone from checking Facebook twice a day, to checkign it once a week, if I get an email.

Please Facebook, bring the fun back.

However, even iLife has its drawbacks in an educational setting. It simply hands so much to the students that they struggle with software (whether Windows, Linux, or even pro-level software on the Mac) that isn’t so brilliantly plug and play. Yes, iLife rocks in many ways, but the level of spoonfeeding it encourages actually makes me think twice about using it widely, especially at the high school level.

To which Gruber responds

So the problem with Apple’s iLife apps is that they’re too good, and kids never learn that they need to struggle with technical issues before using software to express themselves creatively.

I agree with Gruber. However, I don’t think we should limit the discussion to just creative Apps. Modern day software is built on complexity. A consultant at my company once said that if we made the software too easy to use, then the consultants would be out of work; our product wouldn’t sell because it would to be too easy to use. I don’t necessarily agree with the argument, but the fear is common, and not unique to my current company.

Would easier software put people out of work?

I don’t think so. I think it would change the focus. If we started designing our software with a greater attention to user experience, the access time could be spent on further improving that experience, instead of support calls. Apple’s iLife wasn’t easy to create. Each of the apps has had millions of reviews, UI meetings, discussions, arguments and refinements. This wondrous amount of work has lead to an incredibly intuitive suite of tools. It would be fantastic if we could switch our focus (as an industry), from simply providing more tools, to providing better tools. Perhaps than our software will “too easy” for them to teach in school.

Very not cool. I pay for this service, and while I don’t depend on Flickr for hosting images, I haven’t seen my hosting over there go down. While I’m happy that SmugMug is trying to preserve my data, if I were a professional photographer who used their site for my material, I would probably be pretty frustrated if I couldn’t upload a bunch of images. On top of which, if you are going to be down, post more updates to your status blog. Keep the users informed. I know you are busy trying to fix it, but let me know what is going on, more information == happier customer.

I think it funny, yet sad, that I will enjoy a restaurant more based on their selection of chop sticks, but really, can you imagine eating a Michael Jordan’s steakhouse rib eye with a plastic fork and knife? I choose the place with better chopsticks.

It would be really great if we could find a way to make the call from the text message. I’ll leave the exact design and implimentation up to the people at Apple, but this feature would totally improve my testing experiences.

MFC is Microsoft’s old Window framework. Basically it is an object oriented wrapper around the traditional Win32 programming environment presented by Microsoft to help develop windows. Win32 is many years old, and so is MFC. Microsoft’s new frameworks, .NET and WPF (Windows Presentation Framework) are supposedly better than MFC, but I have yet to play with them.

MFC has tools for many different types of controls, from buttons to dialogs, windows, and menus. MFC allows the user to create the button, override some basic functionality, provide message callbacks and otherwise manipulate the application. Buttons are particularly interesting because the base class for buttons actually provides a ton of functionality for many different types of buttons. From this one class, you can get push buttons, check boxes, radio buttons, owner draw buttons (the programmer handles the rendering of these buttons), etc.

A Group of Radio Buttons

I have several problems with this class design, but today I just want to talk about my gripe with Radio Buttons. The term radio button comes from the buttons on old car radios, where only one button could be pushed at any one time. Radio buttons on a computer form, are by definition grouped with other radio buttons so that only one in the group can be selected at any one time. Any time a user selects another button in the group, the previously selected button should become unselected.

Taking this even further, logically, you should only use a radio button in certain situations. You have several options, usually less than 10, and you want the user to select from one of them. You should be able to have a default option set, and this choice should somewhat make sense. This functionality is very similar to a drop down box. In a drop down, you have a bunch of options (please put them in some order), where the user should select only one item. The difference in use between radio and drop downs depends on your application, but in general, you can put more items into a drop down. Drop downs will take up less screen real estate, but not all the choices may be obvious to the user, and sometimes the user may select the first option that seems relevant rather than looking through the whole list. In a radio group, all the options are present at the start.

This brings me to my gripe. MFC radio buttons are just the same as any other CButton. The way you define that a radio button is a radio button is by passing a style flag that is either BS_RADIOBUTTON or BS_AUTORADIOBUTTON. The difference is that auto radio buttons will look to be part of a group. This group is defined by ORing the BS_AUTORADIOBUTTON style with WS_GROUP for the first element of a group. All subsequent radio buttons will be part of that group until you create another WS_GROUP.

This upsets me because radio buttons in a group are associated with the other buttons in that group. They shouldn’t just be loosely coupled like this. It puts a lot more responsibility on the programmer to understand how the grouping is done. If you look at the picture above, you will notice it is from my Mac. In Interface Builder, Apple does not provide you with individual radio buttons, it instead provides an object called a “Radio Group”. This group is a collection of radio buttons that handles all the magic I wish existed in MFC. To be fair, Apple’s implementation is pretty new, they have redefined the way to create code on the Mac no less than 8 years ago with release of OS X. Microsoft’s MFC is much older than that and they have new technologies out there which probably better handle this problem. My issue is simply that I am working with legacy code here, and am incredibly frustrated by the lack of UI thought that went into designing this library in the beginning.

Apple’s biggest problem isn’t with its product quality (which, overall, remains very high), but with its communication to customers.

If your reading this blog, you probably know that I’m a big Apple fan. I will stand up for Apple all over the place, but I have been increasingly frustrated with their communication, this needs to change.