What is it about shopping cart software that causes its developers and installers to abuse the button? Every shopping cart package I’ve encountered uses graphical buttons instead of the ones you get for free with the <input> tag. This causes both usability and development issues. For example:

For a start, users need to become accustomed to what can be clicked on, and what is merely informational. Take that last image – is it something you can click on, or does it point to where you can perform the function? Even big names like Amazon have developed a raft of new button images for their stores. Even stores that pride themselves in their cool use of CSS fall into this trap.

There are also developmental issues: when you adopt a shopping cart package, you usually need to spend time redeveloping the buttons so that they fit with the design of the site. Some packages, including X-Cart, explicitly include size information in such images – if you change the dimensions of the image, you need to examine the templates to determine where these images appear.

What about localising to a particular language, or otherwise changing the text for a button? Instead of a simple configuration file which would pickup the text to be used in an <input> tag, all the images need to be change to accommodate the different text.

Some shopping carts compromise on these issues – they use the <input> tag, and then use CSS to style them as required. However, once you start to adopt rounded buttons, you’ll find that the CSS then becomes populated with special rules to generate buttons of particular sizes to ensure that an appropriate background image is used. Change the amount of text in the label and guess what? You’re back to redesigning the background image to fit. And maybe the CSS too.

Using what web browsers generate by default removes all of these issues and immediately makes an online store familiar to new visitors. Furthermore, it makes customising and testing a store much easier. If a developer feels the need to decorate such standard button, it’s easy to do so with CSS, but one must use caution to avoid potential customisation issues, e.g.:

Easy huh?

[Update: see what Christopher Breen has to say about Zune Marketplace]

Seth Godin writes about an experience of not buying a book because an advertising link from a blog went to Random House and not to Amazon. Random House requires payment a full price, plus shipping charges, and (inevitably) registration. Lots of things that stopped Seth from buying the book.

Which is why I don’t believe in contact forms on websites. Let people use a plain e-mail ‘mailto:’ link. Then you don’t need any pesky ‘required fields’, validation checking, or spam prevention techniques, and more importantly you don’t need to ask questions. A simple e-mail link puts customers directly in touch with you. (In any case, it’ll be the customers you don’t want who spend the time and effort filling in an online form)

Which is why I hate stores that don’t support PayPal. Because, like Amazon’s patented one-click, I don’t have to enter any data. I just login – or not, if I’m on my own Mac – and Buy.

It’s not about margins, or profits. It’s about customers.

This week, Playlist is running a series of features on the Zune. Yesterday it was the turn of the software and syncing. It turns out that Christopher Breen’s experience reflects that posted by Engadget when the product was launched.

What’s interesting in this feature is the following screenshot:

There’s an Options menu, which is more like a generic menu, plus the inevitable ‘More Options’ option – a Microsoft favourite. Oh, and you can find Help there too. Based on this review, I’d agree that the Zune software is intentionally different from iTunes. Indeed it tries not to be anyway like iTunes. Is this because of patent issues? Take the Auto playlist window:

Look where the ’+’ icons are, and where the corresponding ‘Remove’ button is. It’s an extraordinarily bad piece of interaction design.