Model complex product. (Color/Size)

[microposmp]

I've been trying to model different kind of products and are thinking of a complex product that can contain many variants of a product.

The idea is that when creating a product, it is given a name, description, price and other common data. Some of the common data could be overridden in the data for the variant of the product.

Each variant of the product is represented as a sub product with the unique information for that variant. The Product (SKU) part is connected to each variant of the product. Could be automatically generated by combining some data. For example: ProductId, ColorId and SizeId. The Product (SKU) will be the unique identifier connected to inventory, shopping cart etc. The other attributes (for example color/size) would only be for information/presentation and not part of the identifier.

For a simple product that have no variants the Product (SKU) part would be connected directly to the base product. Inventory, shopping cart etc. would have the same unique identifier to the product sold.

In combination with for example a list of different colors the subitems could be generated automatically. A nice way to render the data would be in a grid where for example stock data for each variant can be displayed/modified in an admin part of the site.

SizeCurve
Ordering in the size curve should be considered when rendering data on the admin (product maintenance)/frontend (product pages).

Sample content items in the recipe
The attached recipe contains the following content types:

• ComplexProduct
• ComplexProductItem (variant of the product, for example: color/size combination)
• Size
• SizeCurve (using a bag part to describe the available sizes)
• SizeCurveWithContentPicker (SizeCurve where predefined sizes (Size) can be selected to be available in the size curve.

The content items in the recipe are minimal to discuss the idea. For example: Size might need an id and sort order.

Create a product

1. Create some sizes. For example: S, M, L and XL
2. Create a size curve. For example: S-XL.
3. Add the sizes in the size curve.
4. Create a ComplexProduct.

It doesn't render correctly on the frontend when the Product (SKU) is attached to the sub product, but it't possible to create content items in the admin.

The screenshot below shows a ComplexProduct with one variant (size S) added manually.

My main goal with this is to get some feedback/discuss the ideas. I think it's possible to model as content types but will require some development of new editors for the UI. Some logic for generating variants automatically will also have to be considered.

[bleroy]

Thanks, that's interesting. Can we discuss how this differs from product attributes? I pushed those yesterday, and they seem to enable the same scenarios. For instance, size can be a text product attribute restricted to predefined values, and you can pre-define the available sizes from the field's settings. Varying the SKU based on the choice of attributes sounds like something we're not currently doing with attributes though, and that seems like an oversight, so I'll see how we can get that in.

[bleroy]

Small detail on the form of this: it may have been better to post this as a bug, including that recipe as a block of code in the description or a linked gist. You'll get more eyes this way. Also, I'll almost certainly never merge this even if the suggestion and discussion are valuable.

[microposmp]

I'm quite new to the Git workflow, so I really appreciate the feedback on this. I'll change this to an issue (bug/enhancement). I made a product with the attributes yesterday. The main difference that I see is that the attribute restrictions are defined on the type. My proposal is to have this as data defined in its own types to be able to create fewer content types in the system.

I might have misunderstood the attributes and will do more experiments after work today and change it to an issue.

[bleroy]

OK, so I better understand now, thanks for the clarification. I still think being able to adapt the SKU from attributes is going to be something we should explore, but I disagree on the rest (although you should be able to do it if that's what you want).

I think attributes are the better approach for the following reasons:

• If you sell shirts and mugs, those products are likely to be described differently, and as such to have different properties and attributes. Having distinct content types is the right way to handle that. Otherwise, you end up with a kitchen sink type and confusing UI (that is by the way what Amazon does and it goes a long way to explain why their product management UI is so terrible).
• If variants are actual distinct products, it makes it more difficult to present end users with a consistent navigation and catalog: you need to group multiple products under a single product page, and make multiple products behave like one, and add selector UI to pick the one you want. Attributes are better at this: you have a single product, with a single product page, and the user can easily select attribute values when adding the product to the cart.
• The combinations just don't scale: if you have more than one variant (like color and size), you get a number of distinct products (that you need to all manage) that is the product of all values of all variants. That's growing with the number of values per variant, to the power of the number of variants. With the attributes, you just have one product, and you can add as many attributes as you want without trouble.
• Having variants be content items seems overkill to me, and re-uses UI that was not designed for that usage.
• It only works for predefined discrete values, whereas attributes allow users to choose their own arbitrary values. Imagine for example you want to sell tailor-made suits. You're going to have to ask users to enter measurements. You won't be able to handle that case with pre-established sets of variants.

[bleroy]

Oh, and it's not going to be necessary to create a bug, we already have one for attributes: #25 and this discussion is relevant to that. I'll just link. I'll also close this, because I'm not going to merge the change, but anyone is welcome to continue commenting.

[microposmp]

Ok, thanks for the feedback. I'm experimenting with the attributes now. Will comment on issue #25 if I have some more questions/input.