Welcome to WebmasterWorld Guest from 220.127.116.11
Forum Moderators: buckworks
I have also built my own basic one, but of course with the myriad features now necessary, it would be silly to try to keep up.
What really surprises me is how dismal the usability of the shopping carts is, often both on the public and the admin side. For example, something as basic and as essential as managing categories of products and even the products themselves, can be really confusing.
Why is it that none of the people/groups/companies who have built shopping carts have designed for usability? A good application, especially something where the interfaces are used constantly, needs both features AND usability. If a feature is missing, you can add it. However, if the usability is bad, it's not ... usable.
Anyone have any thoughts?
As a programmer, my answer is that what we are doing as programmers is attempting to automate a process that anyone can do if they take the time to learn it, but they don't want to take the time to learn it, they want to click a button and cash the checks.
Example: html markup is the simplest "language" anyone can learn, a small set of keywords (img src) between carats (<>) to affect the layout and presentation of a page. But clients demand they should be able to click a button and edit a page, they should have complete control over what can be some fairly complex layout issues, it should do all the work for them, it should have no security vulnerabilities, and they shouldn't have to read or learn anything. It should be up to us to lead them by the hand with graphic representations of tasks.
There are hundreds of times I've encountered this response. "When I do [this] it should do [that]." Well, I'm sorry. Computers are not human brains. There are no built in behaviors, they have to be programmed, and I'd be happy to add that but it is going to take some time to solve it and code it - are you willing to extend your budget for this? Invariably, the response is no, I'll settle to complain about how "I never really got what I wanted, so you can't be very good."
The simplest tasks - insert spoon in bowl, scoop cereal, set spoon on path to mouth without losing balance and spilling, open mouth, insert spoon, close mouth, remove spoon, chew, swallow - all have to be programmed, and it is very seldom a simple task to automate what is a simple tasks to the human brain. You have to code, then predict error in user action, manage those errors in some way that the end user will "get it" and unfortunately, the standard method of communication - TEXT MESSAGES - often fails. In response to the message "An error has occurred, your credit card was declined" site owners often receive messages that are always the same: "I tried to order on your site but it won't let me."
My point is that what you call "usability" may or may not be a problem with the programming, interface, or related functions. I completely agree with you that a lot of solutions are duct taped together and a total mess, but for the most part, in my solutions, I can account for a good deal of complaints simply because the user doesn't want to do the work. "I'm not a computer geek like you, make it simple."
I tried to. But you have to meet me halfway. :-)
The tools we build need to be as close to intuitive as possible.
I agree with you, they can't be entirely intuitive because apart from a few things like being scared of lions and breathing are *really* intuitive, but still.
As I said above, I have now tried innumerable shopping carts. There are some things - managing products is one - that are not rocket science. They can easily be made /relatively/ intuitive. And yet in these carts, you have to hunt around just to figure out on which tab you click to manage the families and products! That's crazy.
I think that what has happened is this. Building a shopping cart is a relatively simple programming task. A good programmer or an agency, that can finance two months of programming, can build one. And that's what has happened. An agency builds a shopping site or two and then say "hey, if we invest a few weeks, we can make a generic shopping cart" and presto, they do.
However, those agencies don't have a usability expert. They have built their cart with programmers, and then don't user-test it. Or they rely too much on the reasoning you have given (which I don't deny entirely) and don't walk that extra mile so that their cart not only works, is secure, has a good feature set, but it also a snap to use. There's a lack of maturity, I think, in these applications.
To take case of open-source CMS's, I think that we've seen them "grow up" over the past few years. They have gone from good systems, to intuitive easy-to-use ones. In fact, the last couple of years most people who have created a CMS have taken that additional step of working to make it intuitive and fun-to-use. Probably because there's a larger market, that they are more mature apps, and also because of platforms for blogging, things like that, that absolutely depend on ease-of-use.
But I think that it has NOT happened for shopping carts which are hopelessly caught in "developer-design".
There are hundreds of times I've encountered this response. "When I do [this] it should do [that]." Well, I'm sorry. Computers are not human brains.
I regularly lecture clients on how "stupid" computers are. "They do exactly what you tell them to do, no more and no less. Good programmers create an illusion of intelligence, but a computer has exactly the same intelligence as a light switch - off or on."
However, those agencies don't have a usability expert....
A common problem in all kinds of programming - not just shopping carts. I will save for another time the story of a govt agency displaying a new application that autogenerated graphs in reports to an audience of about 300 end users, one of which interupted to ask, "Which is the green?" After a few minutes of confusion it was determined that no one had checked the pretty displays for color blindness (and that end user was color blind!). :o
I don't know how many hundreds of thousands of dollars were burned on that mistake.
In my mind there are several key elements important to a good cart. These include (but are not limited to and not in any order):
The big conundrums are the GUIs for both the visitor AND the admin. Many of the Open Source carts I've looked at seem to have grown out of a particular need by a programmer. They appear to be built without the help of usability testers or marketing people and in some cases, someone familiar with coding large projects for long term growth and upgrades. But these projects largely cover the basics. I think the general functionality most developers aim for are to make the carts customizable and provide a catalog/cart/shipping calc, and full CC transactions ability. After that it depends upon the particular project the cart will be used for.
I think most programmers of carts believe their product is flexible enough that anyone with enough skill can take their catalog/cart code and modify it to suit. And I think this is the crux of the issue. Just how much tinkering/customizing are you willing to do before you achieve the product you want? Everyone that wants to do eCommerce comes into it with different skill sets and desires. In your case, you have programming skills and know pretty much what you want. You can sift through the offerings and choose or build your own. A greenhorn cannot do the same without a programmer's help and might not be able to foresee issues with one cart over another and chooses one based on either someone elses input (like a programmer's or website designers), price, or because the closed their eyes and took a guess. (Gosh I'm tired of cleaning up these messes.)
There are several products that are reasonably good out of the box. None of them is good enough though. I always expect to do some modifications as I build. For me, it's a matter of choosing one that gets reasonably close to what I want and then use it as a starting point. I've pretty much settled on one cart now and use it for all of my installs unless asked to use something else. Largely because it matches the way I think and I am comfortable with it enough to make it do pretty much anything I want. But any programmer that becomes intimate with a particular cart will feel the same about it.
So we come back to - how far away from ideal are you willing to start?
Sorry, but when you want everything for free nobody has any incentive to stick around and build anything of any significant improvement and quality so you get what you get.
Note that those big companies willing to buy a premium product and throw some money into customization have some AMAZING ecommerce sites both on the customer and admin side.
Basically, you get what you pay for and free is just what it's worth.
You start with a simple shopping cart: User can add a products, description, price and picture. All is well, simple and self-explanatory.
After a while someone wants to create categories. So this is added, too. Then someone wants to mangage different products attributes, like different colors. Then someone needs 20 different tax classes since he is shipping internationally. Then someone wants to add a new payment interface. Another wants multiple shipping options. The next wants specials, multiple language support and the list grows and grows.
Then you come and say: Oh my god this is all so complex, no usibility at all, all I want is to create a category and then add a few products, why is this so hard.
Many shopping carts are like houses in third world countries: One floor after another is put on top - and at some point the building collapses.
My thought is, you should be delighted at the apparent lackings of the competition, and you should be selling your clearly superior shopping cart.
The big conundrums are the GUIs for both the visitor AND the admin. Many of the Open Source carts I've looked at seem to have grown out of a particular need by a programmer. They appear to be built without the help of usability testers or marketing people and in some cases, someone familiar with coding large projects for long term growth and upgrades.
I'm in agreement with what you folks are saying and I'm not "complaining" about what "I'm getting" in open-source apps. You can't complain about something that you get for free.
However, the business model here is clear, I think: you built an open-source app with the idea that business will then come in by way of custom installs, modifications, etc.
So what I'm saying here, is, given that choice by a developer or company, I'm surprised that they don't go the extra mile and think usability while they're building. As I've said, open-source CMS developers do that (otherwise, nobody would choose their systems). Why don't store/cart developers? I think it's because up until now, the client base has been small, and there's the sense of keeping it among developers.
My bet (and hope :) is that within 6 months, we'll see some companies come up with more mature systems. At least I think that there's a market for them, and a justification for the investment. Magento has gone the full "pack in all the features" route which is fine. I think that there will be a few companies who do a more modest store/cart that concentrates on ease of use. One example, Interspire is clearly doing that, but their system is too expensive.
One example, Interspire is clearly doing that, but their system is too expensive.
Thank you for making my point because their product pricing is completely reasonable for a viable online business, especially it their ease of use saves you lots of admin man hours and contributes to the bottom line with more sales.
their product pricing is completely reasonable for a viable online business, especially if their ease of use saves you lots of admin man hours and contributes to the bottom line with more sales.
And I'm seeing this completely differently. I'm a developer, not a store owner. What I'm saying is that I want any site/application I build or deliver to a client to be as close to "intuitive" as possible. a) because I know very well that if the admin and public sides are intuitive, then the site/app will work and be successful and b) because if it's intuitive, I won't need to spend hours in a hotline-like relationship, which isn't productive for anyone.
I'm repeating myself, but again, the far majority of the folks making open-source stores/carts (or reasonably priced ones) just don't have usability in their equation. I go along totally with lorax' list:
- intuitive GUI
- admin options/flexibility
- compatibility with bolt on services (gateways, shippers, search, etc)
(though I'd add on professional-quality coding - and at least in my case, LAMP)
Fact is, practically none of the players are including that first item. What I'm saying is that's really a shame.
1. Lots of programmers lack the ability to create good designs, you need a graphic designer and usability guide. Just like Linux began with great programs, it lacked gui and usability until more and more graphic designers got into the game.
2. One product and solution cannot be universal. The same product might not satisfy multiple users so there you go. Your own great solution might generate complains on other clients as they see and understand "usability" as a big red button.
3. I have created software and online apps for clients CUSTOM MADE, according to what they need and how they need it. Still, what they want and say is wrong (they don't like it once is finished) just as some people hate how they come out on their own pictures (pictures don't lie!).
4. Most "general" solutions are too general to be specific... so people need to learn how to use them. That's because the app has so many integrated functions related to the client own configuration that you begin to rely on general terms. Is understandable.
5. If you see a light at the end of the tunnel and somehow you've been able to see a solution you just might have found a great market opportunity! I'm serious, you might have seen a new way to approach the solution so study it. **I agree on the gui failure on the shopping carts**.
** and that's why I created my own shopping cart, the funny thing is it appears amazingly intuitive only for me :)
Intuitive is for the birds, ie. mostly what the birds leave behind. One gets what they pay for. (If free, don't bit*h) Or One gets what they contract for. (And demand all you can afford)
There's no middle road. The freebie guys give you functionality, then contract for expansion.
The commercial guys give it all For A Price (and probably more than you want) then contract for expansion.
The original query "usability" means different things to different folks in different situations and, because of that, there's no incentive for the cart makers to make more than basic carts since it is impossible to guess what "usability" means for each and every potential client. What's out there makes perfect sense to me... then again, I'm an old time programmer who has been down this road too many times before.
If you see a light at the end of the tunnel and somehow you've been able to see a solution you just might have found a great market opportunity! I'm serious, you might have seen a new way to approach the solution so study it.
The store/cart I have built is _very_ simple and there's no way I have the resources to complete it with all the fancy features a good cart needs nowadays. However, it has very good usability :) It's extremely easy to manage the products, orders, etc. Now, I know that part of the reason that the usability is good is because the app I have built is extra-simple. But still...
The programming task to make a viable open source cart user-friendly (nebulous idea!)is more complex than you make it out to be in your OP.
If a feature is missing, you can add it. However, if the usability is bad, it's not ... usable.
Honestly, in the apps I've used, I've never had a problem figuring out how to manage products and categories, and few clients have either. More often the difficulties lie in customization of advanced features or in web design/incorporating the cart into existing web design.
Whenever you are investing time and money into a new open source project you are taking a risk. Perhaps the investment will pay off. Perhaps not. I think the focus is more on feature lists than gui right now, because the feature list is what is going to attract users. No one knows what the user interface is like until they install, and they install because of the feature list.
A greenhorn cannot do the same without a programmer's help and might not be able to foresee issues with one cart over another and chooses one based on either someone elses input (like a programmer's or website designers), price, or because the closed their eyes and took a guess. (Gosh I'm tired of cleaning up these messes.):)
And after all that, I think you may be right, and the open source apps may really focus on intuitive interfaces soon. But if you want it, don't wait for them to do it. Open source moves slow. :)
I think the focus is more on feature lists than gui right now, because the feature list is what is going to attract users. No one knows what the user interface is like until they install, and they install because of the feature list.
I agree in a general sense with your thoughts on "if you add lots of features, the gui will become complex", but without wanting to get into a huge debate I do think that it can still be made /relatively/ intuitive.
Um, and if you want to let me know which store/cart you're using and finding relatively easy-to-use, I'm all for it! :)
Most shopping carts are either:
1) started by a company hiring someone to build ecommerce solution, or
2) built by inexperienced programmers, or by experienced programmers with lack of GUI sense, or
3) were originally designed to be used for a one type of online business and gradually added features but never thought these features through or piled up so many features it became unusable to everyone
Wrong people driving the development.
IMHO it is RARE that a shopping cart is created by people with experience of three things:
2) running ecommerce, and
3) knowledge of graphics/usability
Just because a brick-and-mortar business is hiring a team of programmers to build an ecommerce site doesn't make this duo expert in either of the above.
And of course the fact that there's gazillion open source free carts out there doesn't help, it typically makes it so much harder for someone experienced to enter a niche with a quality product.
Most of the open source shopping carts out there are lacking in usability "out of the box", but that doesn't mean they need to stay that way.
I see the "demo" as the basic framework of the shopping cart, not what it should look like to the end user. It just saves me the programming time to put all the *functionality* of a shopping cart together.
A designer and someone who has some knowledge of usability *should* be involved with how the final ecommerce site looks to customers. To me that's essential.
From my experience in reading comments on webmaster forums for small business owners who are looking at shopping carts, I think many people don't realize that most of the "off the shelf" shopping cart solutions that are out there can look like ANYTHING you want them to look like if you take the time to customize the theme/skin/templates (as you should).
Most don't want to take the time and would rather be up and running as soon as possible.
To me the shopping cart is just the the wood, hammer and nails that make up the house framework. It's up to an architect (designer) to make the actual house pretty. worst analogy evar
@Rodney, I agree with you for the public side, I guess (though still, some of the store/carts are pretty pitiful there too). On the other hand, the admin side should have basic ergonomics built in from the start. It's as aleksl said, they're built by programmers, without ease-of-use and ease-of-training in mind.
Just this Friday I wanted to order a high-end PC ($3000) from an online dealer in my state.
1. I HAD to register to make a purchase. I couldn't do without. #*$!?
3. I emailed the shop owner, trying to place an order directly. He replied by "could you send some screenshots".
4. I emailed screenshots. He replied that "after talking to the web designer, the problem should be fixed now".
5. Indeed, the shop accepted my mail address now. I hit OK, and the shop said "you'll get an order confirmation soon".
6. The order confirmation never came.
7. After a few hours I inquired by mail whether the order had reached them.
8. "The time between the clicks was too long, and the Cookie storing the information lost the configuration. Could you please do the entire process again?"
A customer who would have done $3000 in revenue lost due to a bad shopping cart.
I guess I don't play in the same field... My web limit (carts, etc) is $50. Anything more than that I need a voice on the end of telephone, a street address, and verification. But that's just me...and perhaps a few others as well...
That doesn't preclude usability or you wouldn't have the sales to call on the phone in the first place.
Trust me, there were companies out there creating carts that did all the usability stuff jacob neilsen's studies recommended and the PHP give-it-to-me-free cheapskates of the world drove them out of business.
Backend admin panels that would make you drool.
But they are no longer sold, they could be, but the make-me-rich-for-free mentality drove them all into extinction.
Funny, if someone wanted to run a B&M store the rent, electricity, phones and all the rest of the monthly expenses would pale the expense of a good cart asking $1K one-time purchase free yet people expect it free.
Go out in the real world and ask some Realtor if you can set up a shop in his business park and if he'll only charge you $2/month for it because it's "shared space" with other tenants and watch the Realtor die laughing hysterically.
That's why a lot of good ecommerce hosts that specialized in hosting specific carts went away as well and when the hosts went away, the demand for their software went away.
A few good combo cart software and hosted solutions still cling to life but as this thread has proved, if they want a fair fee for a solid solution it's "too expensive".
The best I can suggest is find some Open Source that best suits your needs, improve upon it, and THEN submit those improvements it back to the Open Source project.
If everyone did that the collective improvements made to various Open Source projects would already be reaching the goals the OP wanted except here's the next rub, everyone that customizes their cart or improves upon it then wants to keep their improvements confidential to have an edge on the other online vendors.
You can't have it both ways, you either need to rally around a good paid cart and hosting and keep them going and evolving or participate in the evolution of a good Open Source cart and be a major contributor to that cause.
Otherwise, this problem will be a vicious cycle until the end of time.
And as mentioned by tangour, you are buying a $3000 item, you better be prepared to register. See...you look at it as a customer who has money and wants a product and doesn't want to deal with issues; but it is way harder than that on business end. A business may get 10 fraudulent requests on this product a month, and would have to screen every order. Or he'll be out of $3000 AND a PC in no time.
IMHO as all this Web 2.0 stuff blows over, and 90% of these companies go bust, a good thing that'll hopefully come out of it is better overall web usability. And that'll eventually trickle down to free and "almost free" tools like shopping carts.
+ to what incrediBill said. having open source carts put a lot of businesses on the web, alright ;) but a demand for good carts is there, so most of the cost is hidden in the need to hire a programmer to build the cart into something that suits your particular need. which, in a sense, may be the right way forward...
I agree with you 1000000%.
Here is the DudelyDude that got a great deal(Open Source) on e-com Package that was developed by a newbie (*H* developer wanna be a Designer) with no understanding what he/she is doing, due to a fact that "niche Cart/checkout" process needs to be a certain way, then it goes into Open Source and gets Adapted(copied) by a niche that has another DudelyDude Developer(s).
But it's not that way in a real life where 3 lines of code solves the issue.
As developers we need to know what the "SITE" will be all about.
And only then:
99.99%(Free or paid) of the carts out there are:
1. Dupe Content AWAL
2. NO SEO in mind, Just Functionality(generic)
3. Needs a team of Developers(Design, Usability, SEO) to fix the thing after Site Goes Up.
1.Site Developed by local or outsourced XYZ.**(won’t go into details here) Ranking/Link Bidding in mind 4 Half Life(tm) site.
2.1. ZXY comes in 6 month later screaming obvious. After All that doing the same thing all over.
3.1. People Book mark the side in the process, then when the site 301'nd come to Dead links; thus goes the Biz;
Wasted Time by ABC Company.
so most of the cost is hidden in the need to hire a programmer to build the cart into something that suits your particular need. which, in a sense, may be the right way forward...
Again, this is how the designers/programmers put the screws to the clients because often the more expensive software already had those features but you can't make more money off the client unless you bill them to reinvent the wheel with every cart you install.
Most clients don't know any better, they just go along for the wild ride, and the non-stop pay-the-programmer moving forward once they're locked into a customized solution.
Pay up front or pay in the end but you're gonna pay regardless.
Pay up front or pay in the end but you're gonna pay regardless.
Sometimes people think that ecommerce is easy money picking. :)
I've yet to see a solution that didn't require programmers to maintain it...or to put it differently that didn't require programmers to move it forward, or that didn't become obsolete or overtaken by competitors in a short while when left alone.
In my experience the more expensive the software, the more expensive the consulting fees (and I am talking about stuff like SAP, Oracle eBusiness etc. etc - millions in consulting fees).
If your business is working and sound, what is it that keeps an owner from paying programmers/designers?