Author Topic: Call for Input: Red Leaf Product Matrix  (Read 3783 times)


  • President
  • Administrator
  • Rock Star
  • *****
  • Posts: 1612
    • Precision Solutions
Call for Input: Red Leaf Product Matrix
« on: March 29, 2011, 09:33:27 AM »
With RL3 officially released, attention now turns to the next release, tentatively scheduled for early September 2011.

One feature that has been requested a few times now is something that's been described as a "product matrix".  As I understand the concept, a "matrix" is a single product on the website that represents multiple products in Prelude.  A good example of a product matrix might apply to a garment.  This product - let's say it's a shirt - comes in 4 different sizes and 10 different colors.  In Prelude, this would be represented as 40 different products.  As things stand today, those 40 products in Prelude would be 40 products in Red Leaf.  With our product options as they exist today we can filter these products by color and size and whatever... though it's still 40 separate products.

The goal of the matrix is to have these 40 variants represented by a single product in Red Leaf, so that a customer could find the product and then choose the various options to narrow down to a single Prelude product for ordering.  It sounds so simple when I say it like that...

I have no problem visualizing one Red Leaf product representing multiple Prelude products.  However, I'm having some difficulty wrapping my head around what the configuration might look like in Red Leaf to link the single product to the multiple Prelude products.  Bottom line, the configuration is going to have to be simple for people to use the feature effectively.  Sure, we can do the Excel export and imports to help, but at its core the configuration has to basically make sense.

This is complicated by the fact that each product matrix could be of varying depths and complexity.  A shirt might have size and color.  A pipe, however, could have length, bore, thread, material, ... any number of variants.  And then there's those products that might have matrix with additional options based on previous options, for example, if someone selects a pipe with material = "plastic" that may add an additional "color" option from which to choose.

From a pure software architecture point of view, organizing these options into a tree seems to make the most sense at first.  Select color, then size, then whatever until finally enough information is known to identify a specific Prelude product.  But for the site visitor, this may not make the most sense.  They may want to choose color and then size, or any configurable option in any order, and the remaining options need to adapt to the selection.

Going back to our shirt example, if we have shirts in sizes S, M, L, and XL, each size may come in 10 colors.  But on the other hand, one size may only come in 6 colors.  If someone selects that size from the site, we need to adapt and show only the colors that are applicable to that size.  This then needs to ripple through all of the options exactly the same way.

How would you visualize the setup of such a matrix?  I figure we identify the Red Leaf product number and then instead of tying the Red Leaf product to a specific Prelude product number we would instead tie the Red Leaf product to this Prelude product matrix, but what would this matrix look like?  How would you want to see it?
Accidents "happen"; success, however, is planned and executed.