Back to the Drawing Board
I suppose it should have been expected that there would be a few delays pop-up. Unfortunately, I’ve recently discovered a core area that has a critical flaw that I wasn’t aware of until implementing the catalog. As it is so central to why Shopp will be among the best e-commerce solution out there, it is key that I get it right. So, back to the drawing board I go…
I’ve been really working hard on Shopp and tackled quite a bit as of late. The installation procedure is now working great. The defaults are getting set properly. On the catalog side, I’ve been working on implementation of those interface templates. All of the templates themselves use the shopp() tag that will be heavily documented so they can be modified to do just about anything.
It was in the process of working on the catalog interface that revealed a critical design flaw in how Shopp handles product options. For single menu options, Shopp works great. For multiple, though… that’s another story. So, I’m going back and rethinking the interface for editing products so it will fully support this. Thankfully, so far as I can tell, the data model still works just fine. It’s just the interface that’s the main issue. It could work as is, but it wouldn’t be the “right way”.
So, in really thinking this through with the help of Dave (told you he’d be around) the thing I’ve realized when it comes to handling product options (or variations) is just how multi-dimensional the problem is. There are really 3 pricing scenarios that are used in the retail world that need to be modeled. The first is the easiest: single price. No brainer there really. The next is where it gets really difficult. For purposes of discussion we’ll call it the “T-Shirt Problem”.
T-Shirt Problem
The T-shirt problem illustrates a situation where, as a store owner, you would likely have inventory (or stock) of many variations of the same base product, say a shirt with the same logo. For simple understanding of the problem we’ll look at two basic variations: color and size. And just so things don’t get too complex, let’s say you have red and green shirts available in small and large. These are really variable attributes. From the shopper’s perspective, they are selection options. From the store owner’s perspective though, they need to price and track inventory on the final product (a small red shirt, for example), not the options. As a store owner you have inventory of small red shirts, large red shirts, small green shirts and large green shirts.
In Shopp, somehow I have to design an interface where store owners can setup the attributes and attribute options where all of the possible permutations of those attributes have pricing and inventory control. It’s just not going to be simple no matter how you slice it.
The next problem, though it would seem more complex is actually easier to implement than the T-Shirt Problem. It also has multiple options, but they are used slightly differently. This scenario I call the “Build To Order Problem”.
Build To Order Problem
In this pricing scenario, the options provided to the shopper are actually just that: options. The base product they are looking at has a price, and the options provided are actually add-ons. Unlike the T-Shirt problem, the options aren’t required selections. They are optional options. From the store owner perspective, and this is where it gets really interesting, you track pricing and inventory on the options because the options are add-on components.
A scenario where this makes the most sense is a built to order computer. The computer has a price and inventory. But so do the add-on components (or upgrades) such as RAM, Hard drive, etc. The RAM is a component that itself has price and inventory, and the same goes for the hard drive. It’s not the final configurations that have a set price and inventory like the T-Shirt problem, each of the add-on components have their own price (affecting the total price of the configuration) and inventory.
So, now that I’ve explained the issues, here’s my question to the Shopp-community-in-waiting: What would you feel is the best, simplest term to describe these pricing scenarios so that they are easy to understand for the public-at-large?
The terms I’ve come up with so far that make the most sense to me are:
- Options (Single price, or one set of options)
- Attributes (Product variations)
- Add-ons (Build to order)
Now, of course, you have the benefit of knowing what I’m trying to model. But do these labels make sense? Have anything better to offer?
Side comment: It’s amazing how much different the language makes in making software simple (or complex).
Feeds
