Oh Shopp plugin, how I loathe thee.
You make the checkout process an absolute sonuvabitch for both designers and the website’s eventual users.
But let me start at the beginning.
WordPress, as a CMS touts its ease of use and its extensibility. The general feeling is that WordPress makes it easy for anybody to make a website but it’s also powerful enough to satisfy real code monkeys. It can do this because of two things: themes and plugins. Themes govern the look and feel of the website and plugins extend the functionality of the website.
For example, the name of the theme of this particular website is iNove. [Editor’s Note: This part was written when we were on the wordpress.com domain. We no longer use this theme.] It’s a default theme that comes with a wordpress.com account. It governs how the pages are laid out, how they look, and to some degree how they function. If we so chose, we could use a bunch of plugins to allow us to extend how the site works. We could install a Google Analytics plugin or a plugin that creates XML sitemaps, or that makes contact forms easily, or that keeps our comments spam-free.
We don’t need to know the code behind any of that. Instead we install a plugin and that plugin does the work for us. It’s not exactly magic, but for people who turn a puke-ish yellow-green at the sight of code, it might as well be.
Enter the Shopp plugin.
The Shopp plugin is an e-commerce plugin for WordPress. It came recommended to me by another designer.
Most carts – WordPress or not – look horrendous out of the box. I don’t know that anybody has ever been impressed with OSCommerce or WP e-Commerce after a fresh install. You might hear an ‘ooh’ but it’s actually spelled ‘eww’. Even with a heavyweight like Magento Commerce it’s daunting to create something impressive without dedicating yourself to getting over a learning curve.
I have a big problem with this. The job of an e-commerce solution is to provide a flexible platform by which to sell things. This part, vendors will argue, is what they do and I would agree with them. But I believe it’s also the job of the vendor to put usability best practices into use when creating their product.
When somebody buys a car, they have a chance to sit in it… to take it for a test drive and there’s an understanding that they are tested for performance and safety. Nobody would seriously look at a car today if it were manufactured without seat belts and air bags and think that was okay. It would be derided for its deficiencies.
Now imagine that a new car comes out with all of the familiar bits but they’re all in different places… The steering wheel can slide from right to left. It can detach and be used in the backseat. There’s a brake pedal and a gas pedal but the gas pedal is right next to the input for the gas tank. There are headlights but the whole thing looks rushed. You could swear that they’re just balled up lines of Christmas lights. Oh, and the hood doesn’t open but GOOD NEWS! The dashboard comes out.
Would you accept that? Would you think, “Just look at it! It’s everything you’d find in a car! Ooh, leather seats!”? Of course not. You’d be too busy wondering which village had lost their idiot.
The point of an e-commerce solution isn’t just to provide a platform to sell things, it’s to BE GOOD AT SELLING THINGS.
It’s at this point most programmers I know would raise their hand and say that they don’t know the first thing about web usability and that rather than learn it, they did one better and made their program flexible enough for designers to do whatever they want.
Okay. I’ll let you make that argument but only if you promise to leave it in the year 2005 where you found it and you don’t say that nonsense in front of Jakob Nielsen who has been writing on this topic since the days you used to watch the Power Rangers after school.
I’m saying that’s an immature point of view… get it?
The great promise of the Web 2.0 was the communal web. It was largely enabled because technology – XML and CSS – enabled us to separate content from design at the code level. And I’m not arguing against this separation. It makes sense on a technical level because it was already happening at the human level. It’s no surprise that websites were/are largely built by two people: the designer and the coder. Breaking a website into content and design was perfect for both personalities.
The coder got to make sure the machine functioned as it was intended to. That is to say that if the website sold things, as is the case for an e-commerce developer, all of the steps involved in the purchase process worked. The programmer eschewed all design choices, claiming that it’s not his responsibility. His job was to make the machine work and by-God it did that. If you want to talk about why more people aren’t buying your product, you need to find the designer or the marketer or somebody whose job encompassed that responsibility.
The graphic designer meanwhile would be off satisfying the artistic whims of the client.
This is an important point.
In this duo, the graphic designer is guaranteed to have more direct contact with the client than the programmer. Programmers, as a stereotype, are dirty, stinky, (oftentimes bearded), and always anti-social.
Graphic designers as a stereotype are all skipping work today to be one of the first to get their fashionably grubby mits on the iPhone 4S.
In practice it means that the programmers decide what they want to build and defend it to the death. Because they rarely talk to the client they are divorced in a meaningful way from satisfying the client. The quality of the code both in how its written and in how functions is left to the programmer and whoever can influence them. While this may sound backwards: employees do what the boss says or the employee gets fired, it’s not that easy when the employee is the lynchpin of a key part of the company’s product.
My point is this: programmers are known for being difficult and for defending their own interests above all else. As a group (sorry outliers) they tend to be detail oriented and myopic to their discipline. These are great traits for programming but are a hindrance when it comes to being proficient in non-programming but related fields of study.
The designer has a different problem. A designer is responsible for creating a look for the website that the client likes. All of the trouble in that last sentence lies at the end of it “that the client likes”. This is a problem because when it comes to web design WE CAN ASSUME THAT THE CLIENT DOES NOT KNOW WHAT THEY ARE TALKING ABOUT unless proven otherwise.
Why would any non-web business owner have the first clue about how a checkout should work? The simple answer is that they wouldn’t and that they don’t. It’s not their job. Not only do they not know how the checkout process should work but they don’t even know that it’s one of the most crucial aspects of an e-commerce solution.
It’s like that old quote from Donald Rumsfeld. “…as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns — the ones we don’t know we don’t know.”
When it comes to building a website – especially when it’s a ‘easy to use platform’ like WordPress, it’s safe to assume that your users are not knowledgeable about what they’re doing and thus these people are full of unknown unknowns.
Users, for the most part, don’t use WordPress like a new, shiny tool that helps them do their tasks quicker and easier. They use it like a crutch: to allow them to do things they couldn’t do on their own. Why? Because they know that their ignorance means there are tons of unknown unknowns out there.
When somebody hires a web dev firm or uses a CMS they are relying on somebody else’s expertise to accomplish a task. The problem is, both the graphic designer and the programmer have sworn off being responsible for the efficacy of the website, putting the responsibility squarely on the back of the client. “If only you had told us you wanted it like that we would have built it for you.” they’d say. And that’s a cop-out of the highest order. They’re telling you “it’s not my problem”. They’re also telling you that you’re not valued as a client.
There are at least three tiers of responsibility. They are:
- Programmers
- Graphic designers
- The client
If you’re using WordPress, as in the case of the Shopp plugin, that list looks very similar but appropriates the WordPress conventions:
- Plugins
- Themes
- The webmaster
When a website doesn’t perform up to standards, the first person on the hook is the programmer. Whether custom designed or designed as a plugin, the structural nature of the website is defined through the code.
Say Whaa?
Let’s look at an example from the Shopp plugin.
The checkout process for websites has coalesced over the years into something approaching a standard. And if the word standard is too strong for you then it’s at least been distilled into a number of best practices.
Among those best practices are obvious things like:
- Provide a step/progress indicator throughout the entire checkout process
- Provide shipping and tax cost sooner, rather than later, and
- Retain customers’ previously entered information
What’s going on here with these best practices is that they are reducing the friction of the checkout process.
Take Me Down to the Circuit City
Remember the electronics retailer Circuit City? Somebody made the awesome design decision at their stores to make it hard to find a manned register. The registers in their stores were often located in non-obvious places throughout their store and they were notoriously undermanned. Ninety-nine percent of the time customers would wander up to the customer service counter to checkout. It was so unintuitive that Circuit City went out of business. Sure, you could check out there… if you could find a register and an employee who wanted to take your money but it wasn’t easy. There was too much friction involved.
It’s the same way with websites. If the friction is too high, people will go elsewhere. That’s why Amazon came up with the 1-click checkout and then PATENTED IT. They sued Barnes & Noble for using a similar process and forced B&N to move to a 2-click checkout process. It’s why users of Apple’s App Store can install an app in 2-clicks. It’s why there’s such a big push into NFC and Bluetooth payment mechanisms for phones. The whole game is to make it as easy as possible for people to buy what they want. It’s frictionless buying! Hooray!
Except that it’s not because the guys behind the Shopp Plugin don’t know the first thing about these best practices. Or if they do, they go out of their way to ignore them.
In a typical checkout process, the steps are as follows:
- Cart
- Shipping
- Billing
- Review
- Receipt
The two most important steps are the shipping and billing pages. Shipping comes before billing because the desire for the product comes before the desire to pay for the product. So the first bit is to find out where the product is going and who it’s going to.
Then, after the user has done that, it’s appropriate to ask for billing information. And, to keep things simple, there should be a way to copy the shipping info over to the billing information so the user doesn’t have to enter the same information twice. Remember, it’s all about reducing friction.
Now, let’s see how Shopp does it.
In the Shopp universe, billing comes before shipping.
We know this because Shopp provides a bunch of hooks for designers to use when designing their site. As stated above, we want to have the user enter shipping information first and then billing information. And if the shipping and billing information are the same, the user should easily be able to copy the shipping info into the billing info.
You cannot do this with the Shopp plugin without learning how to code it yourself. You cannot design your way out of this corner, it is the fault of the program.
See, Shopp has a hook called same-shipping-address. It’s job is to copy the billing info into the shipping info – the exact opposite of what we want to happen.
And this wouldn’t be too bad if they had also included a hook called ‘same-billing-address’ but they don’t. This leaves me two possibilities: I can learn how to code this behavior myself or I can leave it how Shopp wants it. This, simply, is unacceptable from a modern plug-in. It’s also a detail that’s likely to be missed by all but the UX obsessed.
This is the root of the issue. Programmers are responsible for crafting a working product. Their job is more complicated than learning a WAMP, LAMP, or MAMP environment. Their job is to make tools that work. As part of that process they should also know WHY their programs behave the way they do. Anything less is mere translation.
The job of a graphic designer is to bring clarity and aesthetic appeal to a website. The job of a programmer/plugin is to deliver the best working machine possible.
To go back to the car anology, the programmers are responsible for how the car works and the designers are responsible for how the car looks. If the programmer puts the gas pedal next to the input for the gas tank, all the designer can do is make it look pretty.
The Bottom Line
To look at it through the WordPress process, think of it this way: Themes can’t do anything that WordPress or its plugins can’t do (unless they are custom designed to make up for their deficiencies). Therefore the primary responsibility for how a website should function falls first to a programmer, and then to a designer, and finally it falls to the client.
Even after nearly 2,400 words on the topic so far in the blog post this will seem like a counter-intuitive statement. It sounds like graphic designers are getting off easy. But that is not the case. Graphic designers are also responsible for the user experience. It’s just that their involvement happens at Step 2 and the programmers happen at Step 1. It’s the difference between designing a car to have air conditioning and deciding where in the car the interface buttons should be placed.
If there’s no a/c, then there’s no need for the buttons. But just because there are buttons doesn’t mean that punching one will make it colder because that all depends on whether or not the car also has an air conditioner.
When you’re somebody like me – a jack of all trades but not highly specialized in any one thing – it feels like a last mile problem. When we use these tools: WordPress and plugins built for WordPress, they are supposed to be ways of shortcutting to a solution for a digital problem. In the case of WordPress, I don’t need to know how to program in order to write this blog. I can just sign up and start typing. And for this website, that’s largely what Newman and I did.
But when it comes to more complex issues like an e-commerce cart, we have to rely on the expertise of the plugin builders to deliver the functionality we need.
When that functionality is missing or difficult to implement it frustrates users and makes them use less successful methods that increase friction in the checkout process and overall lower sales. In the case of the Shopp plugin, I would say that easily 25-50% of the sites I’ve seen punt on the checkout process so hard that they just send their users to PayPal to complete their transaction.
Let me say that again: [highlight color=”eg. yellow, black”]Up to half of the site’s I’ve seen that use the Shopp plugin find it so hard to use that they send their customers to PayPal’s website to complete their transaction.[/highlight]
How can any e-commerce cart claim to even be competent when this is the case? They’re just building a digital version of Circuity City – all products with minimal attention paid to checking out.
They have plans to release version 1.2 soon. From what I have seen, none of these usability issues have been addressed.
You’ve been warned.
Questions:
- Have you ever seen a good e-commerce solution that paid attention to the user experience right out of the box?
- Is it fair to make programmers responsible for a significant portion of the web ux?
- Is there a minimal level of understanding that a business owner needs to have before getting a website? How does somebody with no expertise know how to find somebody who knows how to look out for the best interests from a web ux point-of-view?
Ben,
First, I’d like to say I’m glad you started the conversation, although it’s hard not to take offense to the way you’ve portrayed us.
Shopp is in a somewhat unique position as a WordPress plugin in that it has to, at some level, present a lot of front-end information to a web visitor. Most WordPress plugins do very little front-end display. When they do it is focused in a small area of the page (such as widgets) or a larger area of a page like comments.
The way Shopp is designed it is not directly responsible for the front-end display of product pages, or categories, but it has to provide a way to display that information in a flexible layout and does so through the use of a suite of tools to display information from the Shopp catalog, and tools for building a checkout experience.
We are acutely aware a lot of Shopp’s developers are “glue-ware” consultants and in some cases, we get the website owners themselves. So to address the need for instant gratification when setting up a store using the plugin, we developed a set of out-of-the-box templates. The problem is that Shopp is applied to a lot of different verticals that don’t all follow the checkout “standard” you cite which really only speaks to the retail site verticals. What about music sites selling whole albums and singles? Or software merchants? Or service consultants? In all of those cases no shipping address is collected at all. The checkout should be flexible to serve all those verticals. Unfortunately, there comes a point where you cannot deliver a one-size-fits-all, out-of-the-box solution to fit all markets. The needs of the different ultimate-usability checkout experiences becomes mutually exclusive.
As a means to satisfy as many markets as possible, the out-of-the-box template experience tries to do as much to support a “billing and shipping address” checkout as well as situations where only a billing address is required. Yes, it sacrifices retail user experience out-of-the-box to achieve a do-able dual checkout experience for the both use-cases. Doing otherwise and we would be called out as being totally inept.
We can, of course, say it is possible to re-order the fields to change the flow of checkout. You could put the shipping fields first. At every level we provide a “way out” where you can take control of every facet of the experience. In some areas it may take more unwiring than others. You can ditch the supporting Javascript behaviors and write your own. You’d still have had 90% of the e-commerce work done for you since you don’t need to engineer payment gateway integration or shipping calculators or think through the minutia of tax problems.
What you’re not telling your readers is that you believe all plugins should be perfect glue-ware plugins: Don’t make me think. About anything. Seriously. Ever. Read my mind an imagine all of my client’s possible requirements so all I have to do is activate and click a few buttons. I can focus on making it look pretty and not have to worry that in making it look pretty I have to write any real code.
One of our driving goals for Shopp is to eliminate developer barriers so that they can do whatever they need to do without altering core plugin code at all. Shopp should be extensible, and customizable without resorting to hacks.
We work very hard to erase limitations in the development APIs, so it’s not as if we don’t care about this issue. We do, probably, take for granted that developers will want to develop their own experiences from scratch and that if something doesn’t work out-of-the-box, they can just take care of it themselves. That in some cases is a cop-out that cause us to skip over some burdensome issues in customizing checkout that need not be so cumbersome to work around. We really do care a great deal about providing developers, designers and ultimately the end store owner the tools to craft perfect usability, frictionless checkout experiences for whatever they are selling. We want the entire pipeline of individuals involved to succeed in their goals from the developer (glue-ware or DIY), designer, merchant and of course the shopper. That’s a lot of stake holders to make happy and puts the stakes really high.
At any rate we agree it really is a “last mile” problem. You propose a rather simple solution on the backs of our team being usability-ignorant. We may be a little to focused that we miss some things, but that’s where constructive feedback from developers and designers that use Shopp comes into play.
In fact, I read this article way back in the middle of development of our 1.2 release. Shopp 1.2 was released yesterday, and your rant did at least have an impact. The shopp(‘checkout’,’same-shipping-address’) is now paired with a shopp(‘checkout’,’same-billing-address’) Theme API call. Usability concerns addressed. Enjoy.
I enjoyed both of the professional opinions you have displayed on this shopp plugin blog. Both opinions have very good points. This is a well written article, very helpful and informative. I like that you offer both opinions and each author accepts constructive criticism professionally. As an entrepreneur and jack of all trades myself I’d like to see you offer a solution or possible plugin that is turn key or better to use for a jack of all trades that knows nothing about programming, web design, or marketing and can just plug something in that will offer the experience the end user/client and ultimately the buyer will enjoy. Am I wrong here or, are you missing an opportunity to promote a product on such a well written article. Why you would choose a solution/recommended plug-in would get people to purchase anything you suggest and also give shopp a chance to gain additional users that are deciding between picking between shopp or something else. Seems like you to could play good cop, bad cop and both benefit. Just my two cents.
Johnathan with the shopp plugin. It looks like you missed an opportunity to mention some of things you did right in developing your plug-in. It would have been easy to argue his points by pointing out some features and benefits no other plug-ins offer. Features and benefits are what sell products in addition to moving and inspiring people.
Great article.
Too bad there are ZERO e-commerce bolt-ons that remotely do “best practices”.
Shopp actually BLOWS. Their “support” is really a system of coercion to sell inflated-rate “consulting” by their “support techs”.
Their “updates” are nothing more than periodic “break-your-site” bombs designed to get a “fix” of revenue for those money-junkies – and not in return for actual benefits or features but for repairing the web site they just vandalized.
This is not different from the neighborhood Mafia that comes in to periodically trash the mom-and-pop store and extort some “protection” money.
May *someone* produce an actual, quality solution and may that actual quality solution put Shopp where it belongs – out of business.
@John, Not sure why you took the time to type out that spew of vitriol because by the third sentence it was obvious that it was about your frustration with your personal limitations, not anything constructive. Yikes dude!
Glue-ware developers often fall into the trap of wanting everything and wanting it now dammit because they don’t understand the sandbox in which they play, thinking everything is possible for free or nearly so. The truth is, for certain, generalized types of ecommerce, the Shopp plugin is a very affordable and high quality solution representing a lot of knowledgeable programming effort made available at a reasonable price. I don’t think their paid help system is perfect yet but what do I know? If I don’t have a better solution then I’m not gonna criticize the existing one.
I am one of those part designer, part glue-ware, part developer people who can’t create something like the Shopp plugin but I understand enough of the process to respect the effort and accomplishment achieved by the Shopp team and find them undeserving of such harsh criticism.
If I may join in here, I tried a few WordPress ecommerce plugins before I settled on Shopp. I didn’t like what I was seeing in the others and was hoping Shopp would do the job for us.
We immediately encountered a lot of problems with Shopp, but the support team was very helpful. Most of our problems I think came as a result of corrupted files and database tables on install and required that we reinstall (no fault of theirs and I thank them for pointing me in the right direction. They even stepped in and replaced files for me.)
Things improved after that. But usability problems still exist such as: If your login doesn’t work on checkout and you’re being told your password doesn’t work, there is no way to reset your password. (However,one of the developers wrote some new code to fix that for me so a proper error message comes up.) Another problem is if your email address isn’t in the customer database when you try to login, you’re told it doesn’t exist but no instructions on what to do next. And now we’re getting reports from some customers that the system won’t accept their credit card no matter how many times they try. It’s happened enough that I have to believe there’s a bug somewhere. So I’ve reported it and they are looking into it. Could be user error in which case we need a proper error message. Right now it just turns the field pink and that might be enough info for some shoppers.
I do wish there was more functionality, particularly the ability to leave reviews and sell gift certificates. And it is weak on SEO, not giving you control over the meta tags. And the shortcodes they provide for embedding products in posts aren’t well thought out.
I think Shopp is off to a good start but would benefit by some beta testing and subsequent late night coding and usability fixes. There’s enough good with it to keep me holding on.