Meant to write this entry a couple weeks ago, but I thought building an extension from scratch in front of you would be a bit more helpful at the time. Here it is though, a quick little update on the progress of the Commerce module. It might interest a few of you to know that a commerce module was almost released with ExpressionEngine 1.4 but it was scrapped towards the beginning of December. The module was called Simple Commerce and used in conjunction with the Weblog module and Paypal it would have allowed a user to sell items on their website, track purchases, and perform certain actions when an item was purchased.
nice one! thought of dropping a really cool ecommerce site which’s very versatile at the moment and brilliant for us internationally.
http://www.mals-e.com you probably seen this already
Thanks a lot for the update Paul! Sounds very promising.
I understand it’s a little early to start throwing in requests for the Commerce module, but here it goes anyway:
The abillity to have discount coupons. Great for advertising, contests, certain member group benefit thingy, “shop for at least $XX and get a $X cupon” etc etc.
I think it would be a much appreciated and useful feature to have.
Thanks Paul for sharing your thoughts. I’m looking forward to the new module.
Just a quick question (or comment)...
Will the commerce module only be used for providing commerce on the weblog entries level, or would it also work at the member level, thereby providing a means of handling member subscriptions?
I maintain a site for an auctioneer that requires the shopping-cart aspect of ecommerce, something like an Amazon wishlist that enables visitors to mark off items and submit advance bids for semi-annual auctions. I’m hoping the new module will be able to handle this.
Korak - Well, yeah, I mean, how can you have a store without coupons? This is how I intend to sell the remaining hair on my head when the module is finished. By two locks of hair get a third free!
dpotter2 - It will definitely have member subscription handling abilities on the member group level.
Adam Khan - Like EE itself, the Commerce module will be quite extensible so such features should be just as easy to add as a module is added to EE, but I do not see the wish list or auctioning stuff making it into the first release by me.
———
Can I just say how exhausting this module is? So much things to think through and plan out. Me brains hurt. I have rewritten the code for the [super-secret] stuff three times now.
Wish list seems to me just like a second parallel shopping cart labelled differently and without any money changing hands, so I doubt it would neeed anything extra. And that the site is auction-oriented shouldn’t matter either—the auction doesn’t actually happen online, people can merely place reserve bids ~= Amazon wishlist ~= shopping cart. I think.
You wrote something on ellislab about not considering whether something’s impossible and just going ahead and doing it. Sounds like you were speaking from experience. This experience. O labor on, ye fulcrum to the universe.
As Adam mentioned, most “Wish Lists” I’ve seen have been slight mods of the shopping cart, no checkout but options to add to the main cart. Sometimes open to the general public so they can buy it for you, but usually just open to you.
Tutter makes a good point, a site’s wishlist would generally need to be able to allow the passing of items to the shopping cart (though not in my particular scenario since the purchases are made offline).
Without wanting to make the Brain hurt further, I wonder if a wishlist can be added to the module wishlist.
I disagree. Having designed a shopping cart already for our own store and thinking about the Commerce module’s shopping cart, there might be some superficial similarities but the shopping cart is dedicated to many specific purposes while a wish list like the one used by Amazon has features totally unrelated and unnecessary to a shopping cart. They will use similar data though, which will be available to any additional modules so my response remains the same.
If you look at the Amazon wish list, I would agree Paul. But, in it’s simplest form, it does have some similarities to the cart. If I had a choice of no wish-list or a modification of the cart, I would take the latter. In studies we did when I was doing the BestBuy cart/checkout/etc., we found that if there wasn’t a “wish-list”, people used the cart as such and your abandoned cart stats went way up. We studied all competitors and top ten sites of the day (1999) and a wish-list was considered a “basic” requirement rather than a nice extra.
We also found that keeping the user/customer apprised of how many items were in the cart and the total value to cut down on abandoned carts also. It was too easy to add stuff to the cart and then get sticker shock at checkout. One sticker shocked, most abandoned their cart entirely rather than just eliminating a few items.
::taps fingers on desk:: Similarities does not make a good case, Randy. Starting with its simplest form is not the wisest way to do development in a project of this scale either. The cart will, of course, have an option to show the current order and it would be rather easy to set a status so that an item is viewed as merely desired and not fit for check out. Thus, allowing a wish list. Would you care to guess the numerous limitations and complexities this will add in the long run though when you move beyond the simplest form of a wish list? What if you want other people besides the current person to view and use the wish list. Well, then it is not tied into the cart. Oh, but it is! So, we have people accessing the cart data of another. What if you want to add priorities for wished items? Comments? Quantity? Should I keep on tacking this onto the cart data when in fact it is unrelated to normal cart items?
A cart should contain the items someone wants to purchase now.
A wishlist should contain the items someone wants to purchase later or have other people purchase later.
The similarity here is that both contain store items. So, what they need is access to the store item information. Why does not force us into using the cart? It does not. The only thing that the wish list needs to do is put things into the cart of the current customer. That little tie in does not force us to use the cart, merely allow the wish list to insert things into a cart.
——
As for this being a “basic” requirement. This module is not aimed for someone trying to build a Best Buy, Sears, Amazon, or anything that incredibly large. It is aimed for a smaller audience where a wish list will be required for a small subset but not the majority. Looking through our long list of emails, forum posts, and research I have determined that while a wish list would be darn nice to include in the initial release, it is not crucial for the audience we are aiming for at this time. Instead the Commerce module is going to be as expandable as ExpressionEngine so that additional features and abilities should be added in rather easy (even by third party developers). Should I put off release waiting to get everything everyone thinks is required for a Commerce module or should I determine the necessary components for a working Commerce site and release when those are finished? Rhetorical question.
Would you care to guess the numerous limitations and complexities this will add in the long run though when you move beyond the simplest form of a wish list?
Nope, been there done that with a large IA team locked in a room for weeks, food slipped under the door, analyzing every cart/checkout/wish-list/guest-registry on the net. Plus all the variations of MAP pricing vs. actual pricing and how they affect pricing displayed in cart vs. price presented at checkout.
What if you want other people besides the current person to view and use the wish list. Well, then it is not tied into the cart. Oh, but it is! So, we have people accessing the cart data of another. What if you want to add priorities for wished items? Comments? Quantity? Should I keep on tacking this onto the cart data when in fact it is unrelated to normal cart items?
Fun isn’t it. And then just when you think you have it all figured out, you take it behind the one-way glass and watch people use it in a real life usability lab. Oh my.
The similarity here is that both contain store items. So, what they need is access to the store item information. Why does not force us into using the cart? It does not. The only thing that the wish list needs to do is put things into the cart of the current customer. That little tie in does not force us to use the cart, merely allow the wish list to insert things into a cart.
In our iteration of the “wish-list”, it not only had the actual item but links to all relative information (glossary, buying tips, side-by-side compare, accessories, etc.). Gets rather elaborate and complex very fast doesn’t it :-)
As for this being a “basic” requirement. This module is not aimed for someone trying to build a Best Buy, Sears, Amazon, or anything that incredibly large.
I didn’t relate our inquiry to size of site, only to the ramifications of not having some similar feature which resulted in abandoned cart escalation.
Should I put off release waiting to get everything everyone thinks is required for a Commerce module or should I determine the necessary components for a working Commerce site and release when those are finished? Rhetorical question.
:-)
I think we’re all getting antsy for it. I know I am. eCommerce is more important to some of us and we’ve been trying to be patient while the gallery/forum/etc. have been developed. And, yes, I know it makes those developments look like child’s play in many respects.
Wow, and that was the best way to design a commerce site? Interesting.
No, the fun part is making it configurable and expandable so that anyone can use it in the way they want/need. Be it people who have a usability lab or those just selling a few t-shirts. Which was my point.
