d7uc: The Future of Products
This is the second in a series of posts outlining the ideas driving the Ubercore Initiative forward. We've had a lot of positive feedback from developers eager to dig into Drupal 7 to re-implement Ubercart's features like the awesome vision of products outlined below.
For starters, when we gathered for the Ubercore planning sprint in San Francisco, we began by nailing down the core systems without which we wouldn't have an e-commerce system and which we needed to build out other essential features. The links above are our whiteboard scribblings based on Ubercart's current features, but the one we gave the most time to was the core product system. The resultant notes and discussion summarized in this post may be viewed here.
In short... it's gonna be awesome, and it's all thanks to Drupal 7's Fields API. Products are already great in Ubercart, but as one person recently tweeted, the implementation thus far has been a little awkward. Furthermore, from a data standpoint, it's been quite limiting.
How about a visual? It's my first go at Omnigraffle...
Currently, Ubercart defines a new product node type on install and gives you the opportunity to clone multiple new product node types called "product classes." These can then have default attributes assigned to them, which are customer selectable alterations to products at the point of purchase. For example, your merchandise store can have a t-shirt product class with a size attribute attached to it that your customers choose when adding the shirt to the cart. Each of these attributes can result in a price, weight, or SKU adjustment as well. There are also multiple product types defined at the module level, so that regular products function differently from product kits, each having their own add to cart form and functionality in the cart.
Problems come in you try to define just what a product is. Is it a node? Well, with SKU adjustments, aren't more than one products visible on a single node? How does Ubercart know those altered SKUs exist? There are implications here adversely affecting the development of stock control systems, sales and product reports, the shopping cart and order product handling, representing non-tangible products, and more. Happily, we have a plan we think will address these shortcomings without losing any of our current features.
So, what is the future of products? As fago hinted in his post, the future of products is entities, not nodes. We're separating "what a product is" from "how a product is displayed" and making products themselves top level, fieldable entities. Thanks to bundles, we'll still have multiple product types with various attributes, but instead of the current system where attributes are very loosely defined, we'll be moving more toward a product database where each individual product is defined and described by fields you add. Whereas before you might have had a single t-shirt product node with three variations thanks to a size attribute, you would now define a t-shirt product bundle and enter in the three variations with their SKUs and sizes set.
To handle product display, we'll be using a field that lets you specify which products to show on whatever the field is attached to (like a product display node) and how to prepare them for display. The products selected might all be listed individually for the user to select from a radio list. They might be grouped on their size field so that a size select list appears on the add to cart form as it does now. They might be sold all together at a set price as a product kit. We want this product display field to be flexible and to correct the difficulties people have in working with the current add to cart form.
This approach will clarify what a product is (a bundle of fields, including at least a SKU and a default title / price) and provide greater flexibility in how it is displayed (contributed field formatters, anyone?). Modules working with the product system, like stock control modules, will now have a unique product ID to refer to instead of a node ID with an array of attribute selections. We'll have better Views integration and end up with a product entry field that could attach an add to cart form to any entity.
Honestly, I could go on, but I'll stop here. This is already more gushing than I was planning to include in a single post. If you want to read more, hear what other people are thinking, and provide some feedback, you can check out the brainstorming thread, comment here, or keep an eye on the fieldable product meta issue as we flesh out the development tasks.
If you want to help make it happen, don't be shy.