Posting in the Magento forums has been disabled pending the implementation of a new and improved forum solution which should better serve the community.

For new questions please post at magento.stackexchange.com, the community-run support site for the Magento community. We will be providing updates on the new forum solution soon. For questions or concerns please email community@magento.com.

Magento Forum

Plan on creating a new product type (Catalog Product Type)
 
Mark_Kimsal
Sr. Member
 
Total Posts:  186
Joined:  2007-09-12
Michigan, USA
 

I’m doing a site for a large manufacturer of air filters and, after weeks of setting up demos, we don’t feel that either Configurable Products nor Grouped Products are right for us.  Here’s the problems I’ve found with both configurable and grouped products.

Configurable Products: 
* You must have a pricing model that is explainable in terms of options (i.e. option 1 is +$1.00)
* The way you select a simple product is by using a *directed* configurator… you can’t see all the choices at once
* Adding another simple product that is cheaper than all the others messes up your pricing logic
* Price and pricing logic are not correlated with the associated simple products.
* Un-real pricing is displayed on the category page
* Un-real SKU is required when making a configurable product.

Grouped Products:
* When simple products are displayed in a table only their name is displayed (not what makes them unique)
* Un-real pricing is required when making a grouped product
* Un-real pricing is displayed on the category page
* Un-real SKU is required when making a grouped product.

It seems that each of these product tires to *be* a product in its own right at certain time (category page).  What we’re thinking of doing is creating a new product type that does not act like a product ever, it only occupies a place in the catalog.  For lack of a better name, I can only call this “Catalog Product Type”.

Desired Behaviors of Catalog Product Type:
* Do not show a price until a simple product has been selected.
* Show all possible options on one page allowing the user to scroll
* Allow certain attributes to group choices visually (split tables, add extra TR row between, etc etc...)
* Do not force SKU, price, qty, etc for “Catalog Types” master products as a user will never be buying this product
* Update all related products’ descriptions when the Catalog Type product’s description is updated (.. maybe)

I’ve read this post on how to make core Magento changes, but I cant’ seem to implement it:
http://www.magentocommerce.com/boards/viewthread/1286/#t6327

There is no Mage_Catalog_Model_Product in the config xml for the catalog module… it seems that the name of the class that I need to modify is peppered throughout the code as :
Mage::getModel(’catalog/product’);
This gets translated into:
Mage_Catalog_Model_Product
because in the XML we have:
<global>
<models>
<catalog>
<class>Mage_Catalog_Model</class>
so, the first part of Mage::getModel() ... the “catalog/” gets translated into the XML value of global:models:X:class (where X is the first part of “catalog/product”.  The second part, “/product” gets appended via Camel_Case.  I’m not sure how I can intervene in this sort of setup to load a custom sub-class of Mage_Catalog_Model_Product and include some extra behaviors for the new type.  It seems easier to just keep track of changes in 1 file rather than trying to change the value of 5-6 Mage::getModel() calls all over the system.

I would like to know why, or how, this system can make sub-classing and including a special sub-classed file any easier than just making a change in 1 file.  Perhaps I’m missing something.

My next question is… is Magento going to support any of the desired behaviors of a “Catalog Type” product before launch?  I really can’t see configurable products nor grouped products being extremely useful because they act just like simple products in so many respects in the admin backend, but not on the frontend, that it’s confusing to some people.

Example of confusion:
I have a product… an air filter, that has certain properties.  This product is available in 20 different sizes (HxWxD).  When making the 20 simple products, you are forced to duplicate the description and images 20 times.  Then you wonder… will these ever show up?  (i know the answer, yes if you put the simple products into a category and set their visibility).  Then when you make the Configurable or Grouped product to display your 20 different sizes of 1 type of air filter, you are presented again with things like price… well there’s 20 different prices, what should I put for this product?  are people going to be able to order this product?  Then you have to enter a description again, that makes you wonder why you bothered to enter it 20 times before (well because it’s required).  Same goes for images.  And you start to see how it all pulls together, but you wonder why all the same stuff is required when it will never be used.

So, that’s just a quick run down of my thoughts when using the system, and questions I got from people when demoing it to them as a solution.  Perhaps this client is just unique in that every product is available in dozens of sizes, perhaps not.  I think the concepts of configurable and grouped are good, and they work for the proverbial shirt with 3 colors, but I’m not sure they work for manufacturing industries in their current implementation.

But, the point of this thread is not to complain about the available product types, it is to illustrate a real situation that calls for different product behavior, ask for some advice on the best overall way to modify the code, and to find out if this development goal falls in line with any existing Magento plans so as to better integrate/partner/share/etc.

Thanks for any pointers.

 
Magento Community Magento Community
Magento Community
Magento Community
 
sofasoft
Jr. Member
 
Total Posts:  11
Joined:  2007-11-11
 

Good point Mark.

Was Varien/Magento looking into a solution for this ?

Many industries and products have this requirement when you need to know the facotry integrated features before you order at manufacturer.

Let’s look at a simple example.
PDA - you have the following factory integrated features for the same modell:
- with integrated GPS or not
- with integrated Wireless LAN or not
- with qwerty or pen 4 key
- with camera or not
- with 64MB or 128MB ROM memory
- with different Windows Mobile localizations (English, German, French, Italian) etc.

These would expand into 128 different SKU’s - and it’s a quite simple example.  Sure out of these 128 there are about 30 which are common products but also the other combinations are orderable.

What is very important for these type of products:
- get just once listed as browsable product .... - the product family - description / image - and have specified for price “depends on config” and/or maybe “starting with ...”
when the visitor browse the product family details is should be able to configure his product based on his specific needs - and get the individual SKU and price.
or to have a configuration matrix showing the different combinations of features - corresponding individual SKU’s and prices.
- to be found by searches driven by individual SKU’s and SEO ranked by individual SKU’s.

PS: Magento: great job.

 
Magento Community Magento Community
Magento Community
Magento Community
 
seldon
Sr. Member
 
Total Posts:  92
Joined:  2007-11-08
 

Yeps this is something that is often needed. Magento, what do you think about it?

 
Magento Community Magento Community
Magento Community
Magento Community
 
sofasoft
Jr. Member
 
Total Posts:  11
Joined:  2007-11-11
 

Hi Magento stuff,

We really would like to have some feedback about this.

Expect the case when you sell very simple products all the others somehow are similar to the situations described here.

Also for the T-Shirt from your Confiugrable Product screencast - case - probably there are separate selling prices for different sizes ... at least ...

 
Magento Community Magento Community
Magento Community
Magento Community
 
Mark_Kimsal
Sr. Member
 
Total Posts:  186
Joined:  2007-09-12
Michigan, USA
 
sofasoft - 15 November 2007 11:14 PM

Hi Magento stuff,

Also for the T-Shirt from your Confiugrable Product screencast - case - probably there are separate selling prices for different sizes ... at least ...

I think what you’re talking about is my first point:
* You must have a pricing model that is explainable in terms of options (i.e. option 1 is +$1.00)

If you need to charge an extra dollar for red dye, and an extra 2 dollars for XXL sized tee shirts, you’d better hope that the cost of your red dye doesn’t exceed $1 for XXL sized shirts.  Now, I know the argument is, just price it down the middle and the average will work itself out.  But not every product is as simple as a T-shirt with 3 sizes.

Specifically, we have air filters with 3 dimensions (WxH, and Depth can probably be expressed as just 2 attributes), filter material, frame material (cardboard, plastic, metal), number of pockets, efficiency rating (90%, 80%).  It’s just not possible to say that 90% adds 50 cents to the cost of the product when you sell things like 10x10x1” and 48x48x4”.

So, as good as the concepts of Configurable and Grouped products, I think we can add one more type that takes a little from both and makes manufacturing products easier to sell.  I just want to hear Varien’s side to see if they want to include this type of product, or if they’re going to change the behavior of existing products before launch… Just knowing their plans will make my job possible.

 
Magento Community Magento Community
Magento Community
Magento Community
 
sofasoft
Jr. Member
 
Total Posts:  11
Joined:  2007-11-11
 

Mark - yes you are right.

Let’s see what is the point of view of Varien.
We should stress them a little bit.
Altough based on the database structure does not seem a quick and easy implementation.

 
Magento Community Magento Community
Magento Community
Magento Community
 
YoavKutner
Guru
 
Avatar
Total Posts:  491
Joined:  2007-08-08
 

@Mark_Kimsal - You make excellent points. We are aware and are working on improving the process of creating a configurable product so it is much faster and straight forward. One thing that we are planing on adding is the dynamic pricing of configurable products. This way the configurable product will not have to deal with the prices and these will be determined automatically by the simple products that belong to the configurable product.
One point that is not going to change is the SKU. I don’t really understand why in your example each filter does not have a SKU. Magento uses SKU’s as a unique identifier of the products. This is also going to be used for reporting and stock management. In any case we have plans to release the new way of handling configurable products by the first stable release.

@sofasoft - For your example I have a question: your products are built to order or does the customer selection mapped to a specific product?
If the products are built to order then you are looking for bundle functionality that will be added to Magento early next year. If your products do map to a specific pre-built product then you should have as many SKU’s as you have products.

Thanks

yoav

 
Magento Community Magento Community
Magento Community
Magento Community
 
seldon
Sr. Member
 
Total Posts:  92
Joined:  2007-11-08
 

I’m looking for the bundle functionality. Could anyone commment on what it takes to implent this?

 
Magento Community Magento Community
Magento Community
Magento Community
 
YoavKutner
Guru
 
Avatar
Total Posts:  491
Joined:  2007-08-08
 

Varien has plans to develop this feature early next year. You are more then welcome to start this as a community effort.

Thanks

yoav

 
Magento Community Magento Community
Magento Community
Magento Community
 
Mark_Kimsal
Sr. Member
 
Total Posts:  186
Joined:  2007-09-12
Michigan, USA
 
YoavKutner - 18 November 2007 04:08 PM

@Mark_Kimsal - You make excellent points. We are aware and are working on improving the process of creating a configurable product so it is much faster and straight forward. One thing that we are planing on adding is the dynamic pricing of configurable products. This way the configurable product will not have to deal with the prices and these will be determined automatically by the simple products that belong to the configurable product.
One point that is not going to change is the SKU. I don’t really understand why in your example each filter does not have a SKU. Magento uses SKU’s as a unique identifier of the products. This is also going to be used for reporting and stock management. In any case we have plans to release the new way of handling configurable products by the first stable release.

yoav

Each filter does have a SKU.  I don’t know where I said that they didn’t.  I think maybe you misunderstood my bullet point about SKUs:
* Do not force SKU, price, qty, etc for “Catalog Types” master products as a user will never be buying this product

That was in reference to the Super product (i.e. grouped or configurable).  Since the user will never ever be buying this super product… why must it have attribute values, a SKU, a price, and a quantity?  This is what I mean when I say things like “behave as a product.” There should be no way to buy a configurable product or a grouped product, they should be like *abstract classes*.  They exist, but you must choose/buy a concrete sub-class.

In my other bullet point:
* Un-real SKU is required when making a grouped product.

What I mean to say is, the Super Product (i.e. configurable or grouped) requires a SKU, but will never be purchased.  You cannot buy the parent product of a Grouped product because there are never any quantity boxes presented to the user for such a purchase.  The same applies for configurable products.  If the user wants none of the extra options that a configurable product offers to them, the store admin must still create a simple product that holds a SKU referencing the product in question with no options.  It is very confusing to tell clients to just make up a SKU for the Super products (configurable/grouped) because Magento admin requires it.  They start to ask if they will see it on the order screen, or how will they get the shipping department to understand these new SKUs.  I have to tell them that these will never appear on an order.  That is what I mean by “un-real SKUs”.  If I am mistaken on this, please correct me in a hurry, because I have made a grave mistake explaining Magento to people.

We have decided to represent our selection as “grouped products” to avoid the limitations presented to the user by the pulldowns.  I have developed systems like this before so I’ve had to endure lengthy conversations about the limitations of the pulldown method.

For our air filters, we are not sure which dimension is the most important to the customer.  Perhaps they *require* a plastic frame, and can take any size filter, or perhaps they need 4” thick filter, and can take at least 24"x24" or anything bigger for the area.  With the “configurable product” pulldowns, the customer is forced to choose 1 arbitrary attribute first, and cannot select the attribute they feel is most important to them *first*.  So it becomes a guessing game to the customer to try and find they one combination of attributes that yields 4” thickness, or whatever.  So, whatever changes you are making to the “configurable product” will probably have no impact on our store implementation or new product type.

I really would like specific details on the new implementation of configurable products with respect to my initial points.  Without some bullet points about the specific changes that are planned to configurable/grouped products, I’m forced to just develop my own product type because I cannot rely on hope that Magento’s future versions will behave exactly how my client wants them to behave by launch time.

I’m happy to hear that you are improving these product types, but i will also be doing the same.  It seems like we are right next to each other in a darkened room.

 
Magento Community Magento Community
Magento Community
Magento Community
 
YoavKutner
Guru
 
Avatar
Total Posts:  491
Joined:  2007-08-08
 

Mark_Kimsal - I think you understood Magento correctly in regards to grouped product SKUs. Since we regard a grouped product as a product we have to give it a SKU which is the unique identifier of a product. Again this might be improved later to allow for auto-generated SKU for grouped products. We hope to have a preview of the new way of working with the grouped and configurable products before the end of the year but I cannot commit to that.

Please let keep us updated on your progress so that we can learn from your progress.

Thanks

yoav

 
Magento Community Magento Community
Magento Community
Magento Community
 
seldon
Sr. Member
 
Total Posts:  92
Joined:  2007-11-08
 

So, any progress with this new type?

 
Magento Community Magento Community
Magento Community
Magento Community
 
Mark_Kimsal
Sr. Member
 
Total Posts:  186
Joined:  2007-09-12
Michigan, USA
 

The new product type is on *hold* right now, possibly never to be implemented.

First of all, we need to sell products, not make PHP code, that is the overriding rule with doing anything with Magento.  That’s what we need to keep in mind while we (as a company) are evaluating Magento (i.e. throwing products and categories in a bunch of different ways).

After analyzing our situation further, we realized that the main goal was to have a product that only occupied a place in the catalog hierarchy and allowed the customer to choose from a vast array of options on the product info page.  This sounded like a job for Grouped Products.  But, when we realized some products also have options, the interface for mixing Grouped and Configurable on 1 page grew beyond the point where we could provide a good shopping experience to customers.  Moving our products “up” one level in the catalog hierarchy is probably going to solve almost everything without the need to create a new product type.

Our “catalog product type” is now just a terminal category in the catalog hierarchy.  Instead of:

Air Filters > Disposable Filters
* Fiberglass filters (new product type that comes in 30 sizes)
* Polyester filters (new product type that comes in 30 sizes with gasket options)

we have:

Air Filters > Disposable Filters > Fiberglass Filters
* 30 Simple products that we can group and search with layered navigation

Air Filters > Disposable Filters > Polyester Filters
* 30 Configurable products that we can group and search with layered navigation (60 simple not viewable in the catalog)

This method of listing our products still requires hacks for us.  We have to change the product listing page to show more attributes, but it is much better than trying to hack the product info page and create a new Frankenstein-esque product type that behaves differently if it has options or not.  We thought it would be too confusing to the end-user to have the product page look vastly differently depending on if the product required options or not, because that would not be immediately clear to the end-user (that the difference in pages is because of extra options).

It’s not exactly what we want, but it is very close to what we want.  We don’t really think of our “catalog” as having 30 products in the “polyester disposable category”, we think that we have 1 “polyester disposable filter” in the “disposable categories” available in 30 sizes (attributes).

This new way works *with* Magento and doesn’t require us to change large portions of functionality while Magento is still being developed and changing often.

We still have a need for making *custom* sized products and that will require changing the product info page, but it will be done in a more standard manner.  I think that this “made to order” product can be done with a complex front-end widget and many back-end attributes attached to a simple product.

Here is my original list of desired features:

Desired Behaviors of Catalog Product Type:
* Do not show a price until a simple product has been selected.

Solved by changing the category listing page and by listing each simple product in the catalog.

* Show all possible options on one page allowing the user to scroll

Solved by defaulting the the category listing page to “list” type and setting a large LIMIT (50 or 100)

* Allow certain attributes to group choices visually (split tables, add extra TR row between, etc etc...)

Solved by combining layered navigation with duplicate attributes (size: 10"x10"x1, width:10”, height:10”, depth:10").  Size is visible as part of the product description, but width, height, and depth are all part of the layered navigation.

* Do not force SKU, price, qty, etc for “Catalog Types” master products as a user will never be buying this product

Solved be cause this “master product” (non-simple product types) is now just a category.  So no one can buy a category and we don’t have to duplicate the information in the back-end.

* Update all related products’ descriptions when the Catalog Type product’s description is updated (.. maybe)

Some of the info is now part of a static block for a category, so it is not duplicated as much as it was before.  We are willing to live with this one limitation and avoid building a completely new product type.

I still think Magento could benefit from having a sort of “made-to-order” product type by default, but we are willing to wait for it, or launch first and build it later.  It doesn’t seem as necessary once you start using layered navigation.  Layered navigation has really caused us to rethink our catalog layout and provide flexibility to the end-user that we can’t predict right now.

 
Magento Community Magento Community
Magento Community
Magento Community
Magento Community
Magento Community
Back to top