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.

One of my frequent observations on websites for small businesses and organisations is that they are still perceived as a ‘build-once’ activity. This means that the website gets built, and never gets updated. No new content, no new sections. Just stagnation.

Circumstantial evidence obtained throughout the eight years that we’ve been running Junctionbox Media indicates that there is a strong correlation between organisations and businesses that grow and the frequency with which their website is updated. I’m sure this relationship works in both directions.

It’s often cited that ‘we need a content management system’ in order to update content; rather than providing copy to ourselves. Something remarked upon by customers as well as our competitors. But that’s not the case. We can work in new content to static sites very quickly. We have the tools and experience to do this. Furthermore, many website owners have no idea where to start with new content: the text, graphics, editing. What do you need to say? Why? How?

Thinking that this will all change if you install a content management system is foolish.

Shopify is an excellent, easy to use, hosted web store service, and we have it running an on-line store, together with another one that’s in the works. I’ve subscribed to the Shopify forums ever since the site went live.

The posts on these forums now tend to revolve around two classes of issues:

1. Customising the design of a store;
2. Demanding extra features

The first class of issue is to be expected – it takes confidence and a fair amount of skill to take an existing template and tweak it to a specific ‘look and feel’. One has to learn how the store works as well as how the template language works. It’s not really for design beginners, which is why there are templates to choose from.

The second class of issue is also to be expected. Selling things is a complex business, and it’s inevitable that every person’s requirements are going to be slightly different. This is why one ends up with behemoths such as OS Commerce and X-Cart. Shopify isn’t for complex stores, it’s for simple ones.

Furthermore, because Shopify is simple, it demands that you take a look at what you’re selling and how you sell it. Sometimes simplifying what and how you sell something is easier to achieve than complicating the on-line experience. And, because you complicate that experience, it’s less likely you’ll have (happy) customers.

Basecamp is another example of something rather simple but exceptional. The guys who developed it continue to get thrown additional requirements. But they stand their ground, and remark that they want people to grow out of their product, taking their data with them.

When the API to Shopify is released, people will be able to do that: to move to other stores when their business becomes successful. Keep things simple when you’re just starting out.