ShoppingCartProposal-Talk
A page to discuss the Shopping Cart Proposal
What I've seen from "traditional" shopping cart programs is that they're mainly inflexible and thus people have to match their business to the cart rather than the cart to their business. Or hire a programming team to make a custom cart for them.
I'm inclined towards open-mindedness for what constitutes products or services, the attributes allowed on a per-item or service basis, the output look/feel of the cart, and whether or not there are multiple merchants allowed per website. Whether this is feasible or not is another story.
So I'm proposing a mix-n-match language full of features that allow people to entirely customize their products. Customers would order the products, the application would process each added item methodically, and process the order as a whole.
Object Orientation
No need to be object-oriented. Stick with PmWiki's standard way of extending things: provide variables (or arrays) where recipe writers can plop names of functions that do what they want.
This technique is one of the key factors that make it so easy to extend.
I know what I'm talking about here: I have spent years of programming and architectural work with languages that have better OO support than PHP has, and even with these, and despite the best efforts of a bunch of reasonably bright people, the resulting code wasn't half as flexible as PmWiki.
OO is appropriate if you know what kinds of interfaces the various objects will have, and are 100% sure that you'll never have to extend the interfaces. For the kind of flexibility that's being discussed for the shopping cart, OO if done right is too inflexible, and OO done "flexibly" just doesn't give any advantages.
JoachimDurchholz September 24, 2006, at 04:22 AM
Features
Two features that EU-based shops would need:
- There must be a way to force "workflows". EU law says that a shop's terms&conditions are inapplicable unless the customer has explicitly agreed to them, which means you need a terms&conditions page with a checkbox "I have understood and accepted the above conditions" and an "OK" button. (Ideally, such a page would be part of a larger architecture.)
- We need location-based and product-based tax rates for VAT. VAT must be listed not only on each article, it must also be separately listed on the invoice, and *before* the customer initiates payment.
A surprisingly large number of shop systems fails on VAT issues, even shop software that was written in the EU. Merchants that use such shop software incur a litigation risk - the costs involved are not too high by U.S. standards, but they can still easily break a small business.
JoachimDurchholz September 24, 2006, at 04:36 AM
Replies to Joachim
First I want to thank you for telling me the EU specific information! I'll be sure to take that into account, though that might well be something to do with ZAP's next page mechanisms, just insert the agreement in the workflow. The problem will be creating a working model so people can grab code then do whatever they want to fix/break it from there.
Yes, ZAP can do this easily. Caveman.
On the VAT issues: My plan is to make things as flexible as possible. But I'm not sure how that plan may change. Someone on the Users list said that shopping carts could be much more simple than say ZenCart or VirtueMart make them out to be. I think they are much more difficult than that person thinks. The cart itself is the easy part. It's the SHOPPING part that's hard ;)
On your earlier comment about whether this is Object Oriented. There are two things here:
I want something store or product oriented -- not programmer oriented.
I think best in OO code. I've been very pleased with it in general. That won't stop me from making hooks in the PmWiki tradition for people to extend it. People can either choose to extend it as extending classes, or change it through PmWiki config.php variables.
On VAT - is VAT a single % value depending on the region of the merchant? I've seen VAT separate from other surcharges when I visited England, but that was before EU considerations. If it's a matrix dependent on the location of the buyer AND merchant, it would be much more difficult. I hope you've looked at my code snippets. What I'm thinking for "TAX" is
apply same tax rate to all products
(:metacart TAX=.07:)
If there are multiple taxes in EU, I'd just find out how they work, supply extra "variables" for them and change the formulas to calc taxes accordingly
apply same tax rates to all products
(:metacart TAX=.07 VAT=.05:)
If rates change on different items -- you can change the default for an item. If an item is exempt you can add NOTAX NOVAT or TAX=false VAT=false to the item itself.
This is all in theory, of course. I haven't written any code. My main purpose is finding out whether a merchant-oriented system would work for people, or if I should give up on it and go to a data-oriented or programmer-oriented system just like other shopping systems. I'm having some problems with the theory I've come up with, since it's really a way of defining the products not displaying them visually to the visitor. I don't have an elegant way of translating the definition of a product to a display of a product -- yet. :) I am considering that options would be drop-down by default, but that you could define their "display=" variable and change them to checkbox, radio button, etc. Many fields would simply be invisible -- like tax -- until the checkout.
I want three broad types of items that people can add to their cart -- "item" "service" and "file". An item is a physical object, probably to be shipped. A service is a non-physical act that the merchant or merchant's representative will perform on behalf of the customer and may need to be scheduled. A file is any deliverable the shopping system may handle directly, and may actually deliver on its own.
Any time a definition of an item ends, an add to cart button appears. So the user of this system never has to think in terms of wikiforms unless they want to customize the look of the form.
This may be something difficult to achieve, but I've been wrestling with several shopping cart systems. QuickCart (very EU based) has a blanket tax on the whole shopping cart -- so in New Jersey you can't exempt clothing from tax, or out-of-state shoppers. That was one thing that was a make-or-break for me. I could go on & on about other shopping carts and their flaws or problems, but I'm also not sure whether we'll be able to make one cart system SO flexible it will work for any situation.
XES September 24, 2006, at 06:27 AM
Someone had made markup change suggestions. I corrected my proposed markup document and uploaded it -- the code is a little simpler. I'm still very open to suggestions for markup language for shopping items.
I also added a "checkbox" flag for option items, "tax" as one of the shopping cart OR item flags, and will incorporate the "VAT" flag as suggested by an international interested party.
XES September 27, 2006, at 06:45 AM
Posting to this a bit late, but had a few comments, in relation to ZAP and the ZAPcart module...
1) While I wasn't thinking Mall, I do believe a way could be configured for multiple merchants to set up separate shopping carts. It would require you to have a configurable Order.Items page (where item info is stored), or better yet a configurable Order group which would make each store fully independent.
2) Sounds like the proposal you are suggesting is a bit complex, but it may be necessary for complex needs. The ZAPcart module is really designed for small shops with simple needs. But there may be other ways to solve the flexibility needs. Namely:
3) The javascript function can be modified by any programmer fairly easy to calculate shipping and taxes any way desired. You could also specify the javascript file in a SDV (or perhaps in the markup), so different checkouts could use different approaches. Defined in a local config file.
4) The format of the ZAPcart order and checkout sections could be defined in a separate PmWiki page (like ZAP's email templates), to make them quite easy to configure. To allow multiple kinds of forms, I could change the markup to allow an optional pagename into the zaporder directive. Otherwise the current default would be used. This *should be* easy enough to do.
5) I think, without looking closely, additional parameters could be stored for items fairly easy and made accessible to the order and checkout sections, and to the javascript functions the same way it is currently done. Basically it explodes the item info by pipes--so other fields in that array should be just as available as the price and name.
6) As for options for items, I don't know any *easy* way to do that. But without too much trouble, each variations of an item could be stored as a separate item, and a special code could be put in the zapcart markup that would create a pulldown menu with options. A bit of coding but not much.
7) Things like discounts, coupons, gift certificates, shipping options, payment options, would be more complex but could be added *perhaps* using ZAP's conditional capabilities and/or replacement fields. The javascript would also have to be written to make the appropriate changes.
8) I suppose a way could be set up for ZAP to handle inventory control (in stock or out of stock) but I have no idea how, and would probably rather not tackle that within the ZAPcart module. It seems it would be for a more industrial strength application with direct tie in's to a company's database. Something way out of ZAP's limited scope.
I really appreciate the conceptual work you did Crisses, but think starting with something very simple and building extensibility into it might be a better option. I know the basic ZAP cart system works like a charm and it is extremely easy to set up. Making the various parts of ZAP more configurable would make that same ease of use available to much more diverse applications with minimal editing, and without having to reinvent the entire framework.
Any thoughts? ~Caveman
It is certainly complex. I'll agree with that. But there's more complexity for the programmer -- on the user end it only gets complex when setting up a complicated store.
Here I'm selling one product, with 2 size options:
(:cart XES1 seller=XES pmt=PayPal;info@example.com tax:) (:item XyZ name="Product Name" desc="Product description" pic=http://example.com/products/pic.gif:) (:pic http://example.com/products/pic2.gif:) (:options QHI name="Size" select=1:) (:option 8oz name="Small" default amt=123.45:)(:optionend:) (:option 20oz name="Large" amt=10.50:)(:optionend:) (:optionsend:) (:itemend:) (:cartend:)
"cart" sets basic cart defaults -> a code for the cart (XES1), who the seller is (XES -- which could tie back to the Profile page I guess), what method(s) of payment are accepted (PayPal & its email for payment), and that the default for all of the XES1 cart items is that they're taxable. I could leave "tax" out and put it into the item instead. Because it's modular, I can specify the picture for the item, or a picture for each item's size options. Of course, if I weren't putting in pictures of the item(s), and the item had no options, it would be pretty simple:
(:cart XES1 seller=XES pmt=PayPal;info@example.com tax:) (:item XyZ name="Product Name" desc="Product description" pic=http://example.com/products/pic.gif amt=10 :)(:itemend:) (:cartend:)
I've considered whether to use explicit open/close tags or a different method, but until I get even close to proof-of-concept, this is simply a "concept" for how to set up a store. The store is product-driven, rather than trying to cram one's products into the available features of the cart. The only requirement in each item, option, coupon/discount, or cart as given is that the item have a code.
Then there's issues about how to display something so flexible. I was considering that in the (:options:) tag I would allow people to specify whether they want a drop-down, checkbox, radio button, etc.
So my idea has issues. :) I was hoping that people would catch on to the concept behind it, and help move along the problem-solving phase of the concept brainstorming.
I've used ZenCart, and it's also complicated, but part of the problem is that there are SO MANY menus for setting up the store -- it's complicated for the USER. Much too much back-end administration complexity. Usable? yes. Better than oscommerce? By a long shot. But OSCommerce's back-end was easier to administer; ZenCart merged several oscommerce plug-ins into the core, which complicated the administration.
XES November 08, 2006, at 01:14 PM
I'm very interested in this new feature. It seems to be in a kind of preparing state. Can you say, when it possibly might be available?
~Subhash November 27, 2006, at 01:49 PM
Hi, Subhash --
I am hoping for more feedback, and this is not the first priority on my plate, though I do regard it as very important. Caveman created a mini shopping cart with very few features using the ZAPData recipe -- see http://www.pmwiki.org/wiki/Cookbook/ZAPdata, http://www.zapsite.org/ and especially http://www.fast.st/zap/pmwiki.php?n=Snippets.Cart (you must log in as Guest with password test or sign up for an account to see the shopping cart code in action). This is a VERY basic PayPal cart by Caveman.
For me to get going on this, first I need user logins with PayPal subscription fees tied in (will be an add-on for AuthUserDbase). Then I will be looking in to a generic shopping cart module more directly -- and I know it's going to be VERY complicated even to just make a PayPal payment module for it. Patrick (PM of PmWiki -- the PmWiki core author) also said something about needing a shopping cart, but has not given any feedback on my proposal yet -- he's been very busy on several projects including PmWiki's version 2.2.
If you can let me know what ideas I have had that you like, or whether you just need a shopping cart, let me know. I'm still in the thinking and planning stage, because my idea is very complicated to program, and should be pretty easy to use when I'm done.
When I start programming it, I expect it to take a couple months to get it right, so I don't think it will be done before 2007-03-01 -- maybe later -- but more interest and feedback about my ideas will help, because it is so complicated an idea behind the markup that more minds will help think it out faster, and show me where I may be thinking down the wrong path.
XES November 27, 2006, at 08:51 AM
It just occurred to me that while my system is good for tracking products, I have yet to consider how to track what people have ordered. People need to be able to track their order history, for example. That could be tracked on a wiki group like OrderHistory/Username (a glorified pagelist), and Orders/OrdNum###### (for specific order details). The specific final details would have to be hard-coded into the order page, since discounts or sales can change the prices of items, and item details can be altered at any time.
More thinking to do.
Please send more feedback! :)
XES November 27, 2006, at 08:58 AM
I just need an order form for about 200 products. Some are in a "group" together (CDs, books), some are only one item on the same level as the "groups". No payment is required. But it is important to be able to use different VAT tax. There are some requirements in the EU, I have to meet them.
Thank you for the links to ZAPcart. Maybe this would be all I need but I was not able to try it because of being prompted endlessly to login. I guessed he wanted to set a cookie and allowed it but also then I was not able to get the "Amount due" button to work.
Subhash November 30, 2006, at 21:16 PM
I strongly suggest you contact Caveman/"The Editor" on the PmWiki user's list. He's exceptionally responsive to questions and giving people customized ZAP snippets, because he wants to see his work used and expanded on. You can also ask him about VAT & tax calculations to make sure they're done correctly for your cart. It will probably take me quite some time to get to the point that I feel comfortable recommending my cart to people for live use, especially in the EU where I have less knowledge of how VAT works or what payment processing options you might be using. I expect to make the core, then a module for accepting PayPal, then some other popular US processing company. By then, I can give people instructions on creating their own payment modules. Same thing for shipping modules -- I'll use one or two US shipping companies as examples, then try to work things out so it works outside the US.
Good luck!
XES December 01, 2006, at 06:06 AM
Thank you I will do this. But I have to strain my English to explain to him what happens and what I'm looking for. So it will take some time ...
Subhash Dezember 3, 2006, at 13:53 PM
Talk page for the ShoppingCartProposal recipe (users?).