homepage Welcome to WebmasterWorld Guest from 54.237.99.131
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Pubcon Platinum Sponsor 2014
Home / Forums Index / WebmasterWorld / Ecommerce
Forum Library, Charter, Moderators: buckworks

Ecommerce Forum

This 48 message thread spans 2 pages: < < 48 ( 1 [2]     
Why don't shopping carts have usability built in ?
Lots of feature comparison, but none have basic usability
louponne

WebmasterWorld Senior Member 10+ Year Member



 
Msg#: 3992089 posted 8:45 am on Sep 19, 2009 (gmt 0)

I have by now done tons of comparisons of shopping carts and tried out a number.

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?

 

plumsauce

WebmasterWorld Senior Member 10+ Year Member



 
Msg#: 3992089 posted 12:02 am on Sep 24, 2009 (gmt 0)

Here is a general observation, do with it what you will.

Programmer's should also answer trouble tickets.

The reason behind this is that it shows the programmer where the problems are. It also convinces him that it is not all someone's imagination.

If 16 tickets come in that all talk about the same point of confusion about a program, whose fault is it? Got to be the program.

If the developer takes the attitude that a series of trouble tickets all arising from the same cause indicates that *he* has done an inadequate job, then the program improves.

If this is applied in a wash, rinse, repeat cycle, the application will improve incrementally over time.

The temptation is always there for a programmer to beat up the users and assume they are stupid or lazy. Well no, it is the programmer who is being stupid, stubborn, lazy or all of the above. If the users are having trouble, it is the developers' fault. The solution might be something as simple as putting a bit of instruction on the page. But, there is almost always a solution.

The goal, if the programmer is answering trouble tickets, is to drop the number of trouble tickets to zero. And yes, you can get very close to that state of nirvana if you adopt the attitude that it is *not* user stupidity, it *is* a defect.

signed,

a. programmer

incrediBILL

WebmasterWorld Administrator incredibill us a WebmasterWorld Top Contributor of All Time 5+ Year Member Top Contributors Of The Month



 
Msg#: 3992089 posted 3:04 am on Sep 24, 2009 (gmt 0)

I've yet to see a solution that didn't require programmers to maintain it

That describes all software, it's not peculiar just to ecommerce.

Wlauzon

WebmasterWorld Senior Member 10+ Year Member



 
Msg#: 3992089 posted 4:43 pm on Sep 24, 2009 (gmt 0)

Over the past 2+ years, we have looked at over 40 different carts, and actually tried or demo'd 8 of them.

Not a single one was what I would call "all around friendly". Every one has issues of one sort or another - ranging anywhere from a clumsy product setup UI (by far the most common), to such obvious things as forcing me to fill in fields that never change instead of having a default.

One basic issue we ran into with a fairly expensive pay-for cart system was that it could not tell UPS to split shipments into under 70 pound packages even if the total order was hundreds of pounds - instead it would just let the customer happily see a "0" for shipping costs when UPS real time errored out.

We are having a new ecommerce platform built from scratch in asp.net, but to be honest I don't expect results to be spectacular, mainly for the programmers vs user problems mentioned several times in previous messages.

rocknbil

WebmasterWorld Senior Member rocknbil us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 3992089 posted 5:27 pm on Sep 24, 2009 (gmt 0)

it could not tell UPS to split shipments into under 70 pound packages even if the total order was hundreds of pounds

When you get to this part in your new script, you will see something very difficult, and one of the reasons I question why the O.P. claims "building a shopping cart is simple." Trust me, when you fully digest all of the parameters, liabilities, and nuances of a functioning cart and it's companion administrative area, it is not, a good programmer only makes it look simple - or - the script creator is so busy arguing how great their cart is they are blind to all the security holes and usability problems they've created.

Think about it: you have the parameters of a maximum size box, a maximum weight per box, and an order that exceeds both. Your task is to automate

- Getting total volume, after compensating for packing material

- Getting the total weight, after compensating for packing material and it's weight, as well as box weight

- Splitting that volume into the largest possible boxes

- insuring that ordered items do not exceed the dimensions of the largest box

- insuring that the boxed items don't exceed the maximum weight per box

- shift ordered items around accordingly so it distributes the ordered items among the boxes and follows all of the rules above

- follows any additional rules - for example, internationally shipped parcels have limited shipping services and also have different parameters on allowed dimensions, etc.

So when you come out the other side, you should have number of boxes, dimensions of each box, then post this to UPS and get a shipping estimate.

No one has this, I can almost promise you (see below*). I spent months working out algorithms and functions to do this with some form of reliability. It's still not perfect, but it's works. Our numbers at the post office are within a dollar or two on larger orders, within under a dollar on small ones.

It was, by no means, a simple task. And it's only one of the rabbit holes you will chase down in building a "simple cart."

Well no, it is the programmer who is being stupid, stubborn, lazy or all of the above.

Amen, add to the list: extremely focused on the task at hand, so focused that they cannot see some issues because they are not looking for them. * As I may be in saying "no one has this" - I don't look at O.S. software because I'm always coding it. But that doesn't mean it doesn't exist.

In the same way, programmers are focusing on doing the best job they can do and aren't looking for problems outside their expertise. This is what we need designers, marketers, and usability experts for, to tell us what we are missing.

Unless you're fortunate enough to have invested years in these other areas and profess some sort of expertise in them, which is rare.

Demaestro

WebmasterWorld Senior Member demaestro us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 3992089 posted 7:20 pm on Sep 24, 2009 (gmt 0)

To me a shopping cart should only do a handful of things.

1) Hold items in memory until checkout
2) Give the ability to alter quantity of items already in cart
3) Give the ability to remove items from cart
4) Pass items to a checkout process
5) Some admin reporting about cart stats, like abandonment rates.

Ask yourself, what is a shopping cart?

Have you ever been to a grocery store where the checkout was attached to your cart?

A cart and a checkout process shouldn't be muddled IMO.

I don't know why you would mix the two.

aleksl



 
Msg#: 3992089 posted 7:52 pm on Sep 24, 2009 (gmt 0)

++ to what rocknbil said. a "simple" software is only simple to those who know little.

whaulzon, good luck with that, it is not a very easy task to do. i hope you have a guy who knows both sides and drives all this.... not just a bunch of managers, users and programmers ==> a good recipe for a disaster.

Demaestro, how many shopping carts you've seen in real life that are useful outside of a store? Well maybe for racing down the street....carts are inseparable parts of the store and shopping experience, and they are useless otherwise. Why would anyone want a cart but not a product catalog or checkout process? :)

Demaestro

WebmasterWorld Senior Member demaestro us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 3992089 posted 8:36 pm on Sep 24, 2009 (gmt 0)

alek,

Maybe I am splitting hairs here but a shopping cart should be just that. Something you can add/remove/alter items and stores those items in memory until such time you are ready to "checkout"

E-commerce sites I have developed seperate cart functionality from checkout functionality which are both seperate from the catalog functionality.

Having a "cart" that does all those things shouldn't be called a cart it should be called something like "enterprise online shopping tool"

I have never built a cart that figures out shipping costs or weight. Maybe my cart is crappy I don't know. But my checkout process does figure those things out, but not until such time as they are ready to checkout.

My cart doesn't know your shipping info, but my checkout process does.

As a side effect I can use the same shopping cart code base for sites that use a third party hosted payment page, and by sites that do complex checkout themselves. Same carts, different checkout processes.

I as a developer I find keeping the logic of each process seperate makes maintaining and customizing them a lot easier. I find this fits with my OOD mantra.

aleksl



 
Msg#: 3992089 posted 11:00 pm on Sep 24, 2009 (gmt 0)

Demaestro, just don't get too tangled up into OOD mantra. One of the reasons shopping carts have no usability .... because that mantra turns out a huge number of code that doesn't work in the real world.

So you get your perfectly OOD-ed software that loads a page in 4 seconds, out of the box with 10 products and 3 categories in a catalog.

A lot of programmers read too literally into 3-rd and 4th and 5th normalization. Remember, there's always DE-NORMALIZATION at the end.

plumsauce

WebmasterWorld Senior Member 10+ Year Member



 
Msg#: 3992089 posted 10:27 am on Sep 25, 2009 (gmt 0)

We are having a new ecommerce platform built from scratch in asp.net, but to be honest I don't expect results to be spectacular, mainly for the programmers vs user problems mentioned several times in previous messages.

Well, you should be able to expect the best. But, also expect to pay through the nose. Because:

In the same way, programmers are focusing on doing the best job they can do and aren't looking for problems outside their expertise. This is what we need designers, marketers, and usability experts for, to tell us what we are missing.

Unless you're fortunate enough to have invested years in these other areas and profess some sort of expertise in them, which is rare.

But, they exist, and are at a huge premium. The problem is that project managers don't want to pay. I quoted 10K to audit a backend system used by the likes of Nike and Clark's having SQL perfromance problems. No go, scope too broad. My prediction is that whoever they do get will not solve the problem. Why? Because the elements that the project manager considered out of scope are the likely cause of the problem. Experience counts, yet she took great umbrage that someone might review the SQL code written by her asp.net developers. Not a DBA in sight. Perhaps it would reflect on her managment abilities.


- Getting total volume, after compensating for packing material

- Getting the total weight, after compensating for packing material and it's weight, as well as box weight

- Splitting that volume into the largest possible boxes

- insuring that ordered items do not exceed the dimensions of the largest box

- insuring that the boxed items don't exceed the maximum weight per box

- shift ordered items around accordingly so it distributes the ordered items among the boxes and follows all of the rules above

- follows any additional rules - for example, internationally shipped parcels have limited shipping services and also have different parameters on allowed dimensions, etc.

Quoting only for the purpose of illustration, such systems do exist. Since 1990. The point of sale system used by certain post offices.

In that little venture, I pointed out that proper banker's rounding in implementing a new tax was essential for two reasons. First, if it was off by a penny, some retired school teacher was going to find it. Second, the tax auditors will not accept an incorrect answer just becuase the machine does it differently than it is done with pencil and paper. Being a government agency, this would be a huge political problem. Especially with a new tax. Why did I know this? My background was not in comp sci.

Getting it right, even in cobol, took 6 weeks to pass acceptance testing. The original budget was 5 days. The tax, and running sub-total had to be correctly displayed on the customer LED pole display throughout the transaction.

I didn't want to open up that particular can of worms, but did anyways because it was the right thing to do, and the right way to do it.

BTW, the platform was PC/AT running MS-DOS networked to mainframes on 56k leased lines. :D

Wlauzon

WebmasterWorld Senior Member 10+ Year Member



 
Msg#: 3992089 posted 2:22 pm on Sep 25, 2009 (gmt 0)

...
- follows any additional rules - for example, internationally shipped parcels have limited shipping services and also have different parameters on allowed dimensions, etc.

So when you come out the other side, you should have number of boxes, dimensions of each box, then post this to UPS and get a shipping estimate.

No one has this, I can almost promise you...

Actually, I have seen at least 3 carts that do most of that for UPS, and there is an add-on for Yahoo stores that does pretty much all of it.

It can be done, it will never be perfect unless someone takes the time to enter ever single parameter for ever single product being sold.

But on the on the other hand, it does not have to BE perfect, it only has to be usable. We are not going to worry if it is off a couple of bucks either way on a $200 shipping cost. We worry when it is $50 off, or has no results at all.

Perhaps that is not a feature needed by 95% of ecommece platform users, but even rather simple setups like sending the dimensional weight to UPS instead of just the product weight seems far beyond most platforms.

Wlauzon

WebmasterWorld Senior Member 10+ Year Member



 
Msg#: 3992089 posted 2:26 pm on Sep 25, 2009 (gmt 0)

..Maybe I am splitting hairs here but a shopping cart should be just that. Something you can add/remove/alter items and stores those items in memory until such time you are ready to "checkout"..

Strictly speaking, that is correct. The "shopping cart" is only one part of a total ecommerce platform, which includes the catalog, the various payment and shipping API's, graphics options (such as auto-thumbnail) etc. etc.

There are a lot of decent "shopping carts" out there, there are very few good complete ecommerce platforms.

rocknbil

WebmasterWorld Senior Member rocknbil us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 3992089 posted 5:09 pm on Sep 25, 2009 (gmt 0)

Quoting only for the purpose of illustration, such systems do exist. Since 1990. The point of sale system used by certain post offices.

But don't post office systems use the packages present at the location as a "starting point?" I can't imagine someone bringing 10 items to the post office and asking for an estimate. If they did, they'd put it in a box first, pad it, THEN submit their calculations, not weigh and measure each item, calculate for postage, and respond" it will fix in [this] box." Right?

The task of shifting items around to find the best box for a shipment is fairly trivial when processed by a human brain. Automating it via scripting is a whole different task, that is my only point.

While carts and checkouts are different processes, they must be integrated in some fashion. Try selling a client a shopping cart without a method of checkout, they'll think you're padding the project or not too sharp. :-)

Demaestro

WebmasterWorld Senior Member demaestro us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 3992089 posted 6:00 pm on Sep 25, 2009 (gmt 0)

While carts and checkouts are different processes, they must be integrated in some fashion. Try selling a client a shopping cart without a method of checkout, they'll think you're padding the project or not too sharp. :-)

Well try selling them all those things without a hosting package or a website to put them on, same thing.

They are all different things. A cart is seperate from a checkout process, which is seperate from the catelog, which is seperate from the CMS part of a site... and so on.

A great example would be a shopping cart that passes things to pay-pal or Google-checkout. Why have a cart do all that stuff when Google or pay-pal is going to do it as well?

Some people may already have chosen a third party checkout system in place and need a cart, and need that cart to interact with the checkout process they have already chosen.

In this instance having a cart that does things other than what a cart should do would be bloated software.

I guess I am still splitting hairs here.

plumsauce

WebmasterWorld Senior Member 10+ Year Member



 
Msg#: 3992089 posted 9:59 am on Sep 26, 2009 (gmt 0)

Quoting only for the purpose of illustration

It was an illustration that complex POS systems have existed for a long time. Not that it met a specific point in a checklist.

But, for example, as in all POS systems, it had to be able to backtrack(aka cancel) items on the fly. This included of course weight adjustments.

Now, the real kicker to the system was that the particular tax mentioned was applied in some jurisdictions additively, applied as a compounded amount in other jurisdictions, and not applied at all in some other circumstances.

Combine that with the fact that there are something like 300 international postal handling rules covered by treaty, the running calculation. These cover things like taxation, insurance limits, signature handling, size limits, weight limits, diplomatic exemptions and whatever else bureaucrats can dream up.

You have integrated weigh scales, bar code scanners, postage "franking" printers, postage meter refilling interfaces, display poles, cash drawers, receipt printers, label printers, all hanging off of this PC with 1MB of memory running a single tasking operating system.

Pushing x items into y boxes with specified limits starts to look like a walk in the park. It's just a logic problem with some well known algorithmic approaches. Very similar to a scheduling problem.

The trick of course is getting a programmer who understands this and who can deliver.

BlueYon

10+ Year Member



 
Msg#: 3992089 posted 12:32 am on Sep 27, 2009 (gmt 0)

if people are going to mention Magento then I recommend looking at OpenCart.

aakk9999

WebmasterWorld Administrator 5+ Year Member



 
Msg#: 3992089 posted 12:25 pm on Sep 30, 2009 (gmt 0)

It was an illustration that complex POS systems have existed for a long time. Not that it met a specific point in a checklist.

Developers involved in POS applications in the past were more used to developing applications with intuitivity and usability in mind because users of POS applications (checkout operators) could be a 16-year old computing whizz-kid or 63 year old lady who is scared to push a wrong button. And POS had to cater for both and more.

Further, the users (e.g. EPOS operators) are workforce whose fluctuation was very high, and hence the training on how to use the system had to be minimal so the system had to be intuitive.

POS apps development mistakes are very visible because it is all there in the front line in the store, visible to the world - kind of like a web, isn't it?

Hence, many developers who moved from the POS (or similar real time front end) environments onto web (eg. onto web eCommerce) are "trained" to think a bit different, or better, the experience had thaught them that if there is a button/key that should not be pressed and it does not make sense to be pressed, don't put it there or, well, someone was going to press/click on it.

The problem with web is that you need to know where to go to get similar kind of feedback. Whilst on POS you would get the feedback from the client (shopping chain) because either the checkout operator or the customer would complain to the store and it would eventually make its way to developer together with a "code change request", the anonimity of web and a "silent dissapearance" of a customer makes this more difficult - you have to conciously search for this kind of a feedback rather than it being pushed in front of your face by screaming client. Becajse a small POS error could defraud the store for $$$ in a mater of hours.

We have to understand that we (people working in IT industry) think differently and use computers differently. Whilst to us some thing look logical and obvious, to ordinary Joe Blogs they are not. Develop a shopping cart and ask your mother/grandmother/neighbour housewife next door to try to use it and silently watch what they do. It may surprise you!

aleksl



 
Msg#: 3992089 posted 10:07 pm on Oct 1, 2009 (gmt 0)

On topic, sort of.

[rant]
Can someone please shoot developers who designed and built US Postal Service online shipping system?....SERIOUSLY, I am VERY frustrated today, it is a classic example of how NOT TO design a user interface...or how to design it to blind and whatever other unfortunate groups the gov is pretending to care about, AND FORGET THE REAL PEOPLE.

How many clicks it takes to print a shipment with a third-party app? Maybe 5. With USPS.com you will get tired counting.
[/rant]

Wlauzon

WebmasterWorld Senior Member 10+ Year Member



 
Msg#: 3992089 posted 12:54 am on Oct 3, 2009 (gmt 0)

..Well, you should be able to expect the best. But, also expect to pay through the nose...

We ended up cancelling the project. The nose just kept getting bigger and bigger - went from a $15K initial estimate to a $40K estimate and still climbing. For that kind of money we could buy an off the shelf package such as ASPDNSF and pay for the setup and still be $20K ahead.

This 48 message thread spans 2 pages: < < 48 ( 1 [2]
Global Options:
 top home search open messages active posts  
 

Home / Forums Index / WebmasterWorld / Ecommerce
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved