next »

[Dr. Scotty Delicious]

So which part of that should be in a ShopX framework, which part is already in MODx/other snippets and which part should be user customization? I.e. where is the line drawn?

I think the nice part about MODx is you don't have to "draw a line".  If there is an existing snippet out there that would add functionality to shopX, it will undoubtedly become part of shopX.  On the other side of that coin, we may develop a very useful addon to shopX that may miraculously have a very useful life in another aspect of MODx.  The customization of it will be limited (initially anyway) by lack of imagination and/or initiative.  Neither of which seem to be an issue looking at the posts here in the last 24 hours.  I for one am very exited about this.  Now I have to think of something to sell!

-sD-
Dr. Scotty Delicious, Scientist.

[Andy Ayre]

What I meant was, regarding the products download aspect, what needs to be part of ShopX? For example, if the download is only available for a limited, time, does the ShopX system use a plugin to remove access to a specific page for a specific user, or is that left up to the developer to write their own plugin, etc?

Andy

[sottwell]

Ah, there lies the beauty of using the MODx documents for your products! Simply set the publish/upublish dates for your document, and it will automatically be removed from your catalog on the date set for unpublish! You only want the item visible to a logged-in user? Put it in a document group attached to the web user group in question.

[Andy Ayre]

Sorry, I didn't explain what I meant clearly. 

Suppose you have a product that is downloadable, i.e. software. But you only want to allow the user to download for the next year so they can get updates. At the end of the year they need to purchase the product again for another year of updates. Or suppose that you only want download links to work for 30 minutes to stop people sharing username/password info with others.

These are just a couple of situations that I've already had to handle in stores that I have built in the past.

Andy

[Andy Ayre]

Some other random thoughts:

The system should store the total number ever sold of each product. Then developers can build snippets to show the top n products.

It would be nice if the system can connect products together via a sale. For example, know that frequently product x was bought at the same time as product y. Then people can build snippets to show "Customers who purchased this product also bought ..." ala Amazon.com. Although probably not a feature for the first version, any design shouldn't stop features like this from being easily implemented later.

Andy

[PaulGregory]

As long as the sales are stored in the db with an ID that can still be cross-referenced to the actual product, then such things are possible. Yes, storing some information (total sales) against the product itself can be a useful timesaver.

Back on the digital download thing:
Of course, sharing the file itself is as much a danger as people sharing the username/link. I think digital downloads are outside the scope of ShopX, but things need to be in the core to enable them. Basically what we're talking about is an extra privilege that a user has gained through payment - I'm going to call this a user token for the sake of argument.

ShopX:
* Saving of user token upon successful sale with start date and expiry date with ID specified by product purchased
* Triggering of external routine upon successful sale (activate product URL)
* Inclusion of instructions in confirmation page / email based on products purchased

Other System:
* Creates link for dynamic instructions
* Checks user has token and valid credentials before serving file.

Other Uses
That user token might even be a store membership that entitles them to 10% off future orders.
Or it might be checked elsewhere in MODx - Gold Membership might disable all ads on a community site, for instance.

[ZAP]

Lots more good ideas. It's amazing how much easier it seems to be to build a complex system like this when the assorted parts are modular and not all jumbled together. So far I'm not doing anything but display sales info for order fulfillment purposes, but now that you've started me thinking about that info it's certainly true that upselling and sales reports would just be a matter of query and output.

[OpenGeek]

Then I'm going to rework the whole thing to use a couple of database tables instead. I'll only store a key and a tag for preventing re-submissions in the SESSION.

Susan, let's chat about this before you decide to do that, if you don't mind.  IMO, session data needs to be handled by the registered session handler in the standard way provided by PHP, and trying to maintain what is session-related data in other forms is not really the most efficient approach to solving this problem of shopping cart "state".  What is the real motivation for doing this?

[ZAP]

Then I'm going to rework the whole thing to use a couple of database tables instead. I'll only store a key and a tag for preventing re-submissions in the SESSION.

Susan, let's chat about this before you decide to do that, if you don't mind.  IMO, session data needs to be handled by the registered session handler in the standard way provided by PHP, and trying to maintain what is session-related data in other forms is not really the most efficient approach to solving this problem of shopping cart "state".  What is the real motivation for doing this?

I think that the motivation was the intransigence of PHP sessions (24 minutes by default), combined with occasional flakiness and possible security issues on shared servers. But I'm not sure that storing everything in dedicated db tables is the best solution either. Personally I was going to use a cookie for basket contents and either PHP or MODx-native user sessions for checkout info (excepting the credit card info, which I'm not storing in anything except a post variable).

But I actually haven't made this leap yet, and I'd definitely be interested in alternative ideas before I do. Especially from someone who knows the future path of MODx so intimately. And if we are going to set up a collaborative effort on this then we should all be on the same page, so I don't want to go off on my own tangent if it's not what most people think is the best course of action.

Speaking of collaboration, how shall we get that rolling? I'd be happy to set up a test installation (0.95? 0.97?) on a server and give access to folks who are working on this. Susan already has one set up as well, but maybe we should have one stable test site and one for development purposes?

[PaulGregory]

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.

[ZAP]

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.

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.

I'm not sure those arguments convince me personally, but I'm not so committed to cookies that I care all that much and 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 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.

[grad]

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.

Personally, I don't like to register an account to make a single purchase. Especially when I know (for the moment) I will not be a returning customer. I prefer to be able to make a purchase without needing to create an account and at the checkout be offered with an option to save my creditentials for future. This way I can check the exact price (including shipping) and all details before making the final decision. Once I decide to buy, I don't mind saving my data for future.

This is of course my personal preference, however, as mentioned above, SHOPx should follow the MODx best practices of flexibility and allow to choose the preferred solution.

[grad]

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.

Definitely, the ability to have customized document types for different kinds of products, including different product options (size, color etc.), would be the ultimate solution. This will eliminate the need for dozens of tvs and simplify the implementation.

After having read the Rethinking MODx thread I assume this will be the way to go in MODx 1.0.

[rthrash]

The way I have ShopX set up at Corangics is to automatically create an account for someone after they're done checking out the first time. They don't have to use it, but they can if they wish to. The second step allows them to log back in: http://corganics.com/store.html

[PaulGregory]

I think we'd still need TVs (or their future equivalent), but inheritance is an exciting area.

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.

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.

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 ideally it would be abstracted so that things could differ, but there was a common way to ask for the value.

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.

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...

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.

[ZAP]

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.

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.

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.

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 ideally it would be abstracted so that things could differ, but there was a common way to ask for the value.

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.

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.

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...

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.

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).

So shall we start with a proposal for table structures (basket items, order summaries, order line items, customers...)?

[Andy Ayre]

I think it's best to start with a functional specification. It can be as simple as a list of functionality that ShopX will provide. Making that list will help clarify exactly where ShopX stops and user customization starts. It will also make it easier to later describe how ShopX will be implemented and what chunks/snippets/TVs /database tables will be needed.

Andy

[grad]

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.

[ZAP]

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.

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?

[rthrash]

I hope that the split web/manager systems merge and the silly built in extras just go away. The user auth system should not be used as a contact manager... the silly thing doesn't even have a line for an address for goodness sakes... city/state/zip, country, phone, name... but not even a single address line. Oh... and that photo thing. And the sex of the user. :/