You think? I’m open to storing basket contents on the server, but personally I’m not sure I see the need for it. I would just as soon potential customers keep their clicks to themselves on their own machines so I don’t need to clean up the database periodically. Although I guess arguments can be made that a) being able to browse abandoned carts might alert you to a problem, and b) some people are still paranoid of cookies, so storing them in a database table avoids that issue.
The ideal is to have cart data stored on the server (in db or whatever), with a cookie so that the cart can be picked up again later. It’s much easier for all concerned, is more secure and is more flexible. When a user logs in, the cart is stored against the user, and they can log in anywhere and see the same cart. Having a cart purely as session data works, but it is limiting. Also, abandoned carts are useful to study.
I think that there are two parallel models of carts to consider here as well: with user accounts vs. without. User accounts can be very useful for repeat customers, digital downloads, etc. but tend to make the checkout process longer and more complex. For those who don’t need user accounts, I think that there should always be an option to not have them.
Of course, documents *are* in the db. So here we definitely need to consider MODx 1.0, as that appears to let us define a ’product’ type of document and thus gives us the best of both worlds.
MODX Staff
I just think that the amount of data that needs to be passed around from client to server each time should be minimised. And there are limits to cookie size. More importantly, these *are people trying to buy something from you*. You can therefore afford the db time, as this will rise in line with the turnover of the store. Guest carts could have a natural expiry of 30 days, and db clean up would be pretty much automated.
You think? I’m open to storing basket contents on the server, but personally I’m not sure I see the need for it. I would just as soon potential customers keep their clicks to themselves on their own machines so I don’t need to clean up the database periodically. Although I guess arguments can be made that a) being able to browse abandoned carts might alert you to a problem, and b) some people are still paranoid of cookies, so storing them in a database table avoids that issue.
Well ideally it would be abstracted so that things could differ, but there was a common way to ask for the value.
I think that where the data is stored is something that we should all agree on and do the same way if possible so that everyone knows where to look for those values in their add-on modules.
Well, the cart is either associated with a user account or it isn’t. A system with user accounts may still let people add to cart in guest mode before they log in. As for the checkout...
I think that there are two parallel models of carts to consider here as well: with user accounts vs. without. User accounts can be very useful for repeat customers, digital downloads, etc. but tend to make the checkout process longer and more complex. For those who don’t need user accounts, I think that there should always be an option to not have them.
I guess that’s true, although it’s not that much data and it’s only needed when adding to the cart or calculating totals. But still that’s one more reason added to the anti-cookie pile. Pretty much the only one that I have as a counterwweight on the pro-cookie pile anymore is that it’s the quick and easy way to do it, but that doesn’t even convince me.
Quote from: ZAP at Nov 20, 2006, 01:47 PMI just think that the amount of data that needs to be passed around from client to server each time should be minimised. And there are limits to cookie size. More importantly, these *are people trying to buy something from you*. You can therefore afford the db time, as this will rise in line with the turnover of the store. Guest carts could have a natural expiry of 30 days, and db clean up would be pretty much automated.
You think? I’m open to storing basket contents on the server, but personally I’m not sure I see the need for it. I would just as soon potential customers keep their clicks to themselves on their own machines so I don’t need to clean up the database periodically. Although I guess arguments can be made that a) being able to browse abandoned carts might alert you to a problem, and b) some people are still paranoid of cookies, so storing them in a database table avoids that issue.
We could do that. Still we’d probably want a common set of arrays or whatever to store the values in so different modules know where to expect them. Which is why deciding on things like user accounts (= a customers table and array) is important now.
Quote from: ZAP at Nov 20, 2006, 01:47 PMWell ideally it would be abstracted so that things could differ, but there was a common way to ask for the value.
I think that where the data is stored is something that we should all agree on and do the same way if possible so that everyone knows where to look for those values in their add-on modules.
I think that your last point on user accounts is where most carts fall down terribly ("Ability to order without having to remember password from existing user account "). That seems to be the cause of pretty much all the complaints I receive on mandatory account systems (they require a password, and users never seem to remember it or type it correctly). So fixing that would resolve the only reall issue that I’ve ever had with user accounts (except for that other non-convincing reason: that it’s easier not to add them).
Quote from: ZAP at Nov 20, 2006, 01:47 PMWell, the cart is either associated with a user account or it isn’t. A system with user accounts may still let people add to cart in guest mode before they log in. As for the checkout...
I think that there are two parallel models of carts to consider here as well: with user accounts vs. without. User accounts can be very useful for repeat customers, digital downloads, etc. but tend to make the checkout process longer and more complex. For those who don’t need user accounts, I think that there should always be an option to not have them.
Require user account before checkout = bad, unless they need one to see the products (eg trade only site).
Ability to create user account during checkout = good.
Ability to create user account at any point = good.
Ability to *not* create user account during checkout = may be of some use to some people.
Ability to log into user account during checkout and prefill most details = good.
Ability to order without having to remember password from existing user account = nice.
In all likelihood, every time anyone checks out without an associated user account, a customer account is still created because the details need to be stored somewhere. The user just can’t log in to it or reuse it. So yes, shop owners should be free to remove the ability to reuse accounts if they so wish. But I’m with grad on it being an additional option for the customer - albeit one that would default to yes.
And certainly, the user account info should only require the information needed to fulfil the order - eg if payment is via PayPal, for a digital download, we don’t need the customer’s full address, so we don’t need to ask for it.
Of course, the user account is also useful so that they can log in and track the status of the order.
And shipping should be calculatable just from postcode and country. Don’t need full details at that stage, and it’s much better to see the final total before entering checkout.
deciding on things like user accounts (= a customers table and array) is important now.
Another good point. That’s the way that Ryan has it set up now I believe. Are there significant changes to the web user system coming up in 0.97 that we should be taking into account/taking advantage of?
Quote from: ZAP at Nov 21, 2006, 11:17 AM
deciding on things like user accounts (= a customers table and array) is important now.
One more note concerning user accounts. SHOPx should allow to use existing (web) user accounts. This would be especially important in community sites, where registered users have access and actions privileges (the good example is MODx site itself) and where they might occasionally make a purchase (say a t-shirt with community logos etc.). So only the extended information needed to complete the purchase should be stored for those users.
MODX Staff