Then how are options applied to the variations?
Options are turned into feature variations. Each color or model variation is now an option. A combination of different feature variations is getting a distinctive product_variation_id and is the only concrete product in your store. I don't say real product, because according to some philosophers, abstract notions have more reality than concrete ones and have the power to generate them.
As far as I understand, all products having a product_id are turned into abstract products, each representing a set of general ideas (called features). The concrete products are now those that bear a variation_id, which represents the materialization of this or that general feature, say, color, into feature variation red, blue, yellow, etc. If a general product Shirt has no color or size variations, it will remain in the Plato's cave, hovering in the limbo of abstract ideas.
I would disagree. But since we won't see it unil they're done with it, we're both speculating. But my bet is that there is an underlying product that when the type of that product becomes a variation, that it is hidden from the user (but visible on in the admin panel) and only the variations are shown to the customer. However, things in common across variations (descriptions, opotions, option modifiers, etc.) will all come from the main product from which the variations are created. Again, it would have been much more straight-forward to extend option combinations to support, name and price versus generating a whole new data type.
Other areas that are not yet addressed and mostly relate to MVE. I.e. are features not to be both global and local to a vendor and/or a product? I.e.. a merchant may want only 2 methods of providing "Size". ( I.e. 4, 6, 8, 10, 12, 14, 18, etc.and XS, S, M, L, XL, XXL). Both would be called "Size" but a vendor would choose which they wanted to use. Merchants want consistency among products sold on their sites. Hence names of colors can also be an issues (we're talking exclusively clothing here). Not clear how the feature "Size" will use one method or the other if everything is global and not local to a vendor or a product.
Options are turned into feature variations. Each color or model variation is now an option. A combination of different feature variations is getting a distinctive product_variation_id and is the only concrete product in your store. I don't say real product, because according to some philosophers, abstract notions have more reality than concrete ones and have the power to generate them.
Can't be. If I have sequential options for 25 car manufacturers, each with 20 models and 50 years of "car covers" where I have 3 variations based on color (black, white and blue)., I can't have (25X20X50*3 variations). That would be 75,000 variations for 3 colors of my car covers. That would be pretty lame. So I contend there should be 3 variations of a product that has options that the user chooses of manufacturer, year, make and model and that the variations are the 3 colors of black, white and blue. There would be 3 products in the listing for black, white and blue and the user would then select from the options AND features to choose their product. Note also that the product might contain a modifier of +$10 if the 'model" chose is Corvette which would then be applied to the price identified by the variation.
a merchant may want only 2 methods of providing "Size". ( I.e. 4, 6, 8, 10, 12, 14, 18, etc.and XS, S, M, L, XL, XXL).
Actually, there will be a multiverse of Sizes:
Hats Size
Shirt and Blouse Womens Size
Shirt and Jacket Mens Size
Children Clothes Size
Trousers Size
Socks Size
Mens Shoes Size (EU, US, UK, JA, CH)
Womens Shoes Size
Children Shoes Size
Bike Size
Ring Size
Wrist Size
Elbow Size
Book Size
etc., etc ad nauseum
Each of these Sizes has its own variation logic and standards/unit measures. Classes of classes within subclasses of the general idea of Size...
Yep, how will they be distinguished in the back-end while making it readable/useful to the customer. I.e. for hats, bikes, rings, etc. the customer should only see a liable of "Size". What's needed is a label and identifier. I.e. an identifeer might be ring-size (only visible on backend) and the label would be Size. (presented in display to customer).
This seems to be a big issue. If the name of the feature is Size, and there are 10 feature groups containing different features with different ID but one and the same name Size, import will mix them up, as reported here
https://forum.cs-cart.ru/t/har-ki-s-odnim-nazvaniem-na-raznymi-id-ne-sozdayutsya/7861
This is because the feature name taken into account is derived from the name of the feature, i.e., feature_size in English, feature_размер in Russian, feature_größe in German, and so on. We can have 10 different instances of feature_size multiplied by the number of the active languages. Feature-id is not referred to - or is referred only once, to make the things worse and replace the other FIDs, CODE of the feature is also being left without attention. All these variation factors are not taken into account, hence the total mess.
Additionaly I have a question regarding performance of the new design.
- Should I create a single global feature "Color" for all of the categories or should I create many "Color" features for different categories e.g. "Color" (strollers), "Color" (car seats), "Color" (baby cribs) etc.
I've asked about this from the standpoint of performance, but I agree. It would be much better to have a backend name for the feature, which would be used to import/export and a frontend name for the customer.
It would make managing features much easier.
It would be much better to have a backend name for the feature, which would be used to import/export and a frontend name for the customer.
It would make managing features much easier.
Let me summarize for you the gist of the above BugTracker issue.
feature_size in Group1 has ID 2345
feature_size in Group 2 has ID 3456
When importing products of the two groups, feature_size of group 2 is imported with the wrong ID because the system finds first that the ID of feature_size is 2345, looks for all instances of feature_size and assigns to them ID 2345.
That's why it's important to separate the "identifier" from the "label".
For import/export, it should be the identifier and the backend should allow selection by identifer.
Display is for SEO and what the customer sees. So you might have:
ring_size, dress_numeric_size, dress_sml_size, hat_size for "identifiers", all of which would have a display of Size.
This seems to be a big issue. If the name of the feature is Size, and there are 10 feature groups containing different features with different ID but one and the same name Size, import will mix them up, as reported here
https://forum.cs-cart.ru/t/har-ki-s-odnim-nazvaniem-na-raznymi-id-ne-sozdayutsya/7861
This is because the feature name taken into account is derived from the name of the feature, i.e., feature_size in English, feature_размер in Russian, feature_größe in German, and so on. We can have 10 different instances of feature_size multiplied by the number of the active languages. Feature-id is not referred to - or is referred only once, to make the things worse and replace the other FIDs, CODE of the feature is also being left without attention. All these variation factors are not taken into account, hence the total mess.
Let me summarize for you the gist of the above BugTracker issue.
feature_size in Group1 has ID 2345
feature_size in Group 2 has ID 3456
When importing products of the two groups, feature_size of group 2 is imported with the wrong ID because the system finds first that the ID of feature_size is 2345, looks for all instances of feature_size and assigns to them ID 2345.
"identifier" and "display name" for features will solve that issue. This will allow global features (and should also be applied to options) to be used to ensure consistency and to allow for management of those features across products.
That's why it's important to separate the "identifier" from the "label".
For import/export, it should be the identifier and the backend should allow selection by identifer.
Display is for SEO and what the customer sees. So you might have:
ring_size, dress_numeric_size, dress_sml_size, hat_size for "identifiers", all of which would have a display of Size.
For the sake of the SEO Templates, the variable should be construed in this way
feature_lang_group_name
lang is needed for this rare case when the group and feature display name are the same in both languages, say, Монитор and Размер in Russian and Bulgarian, or Editor in English and German.
Using feature ID as differentiator will not work because there can be many different languages attached to one feature ID, and if their display name is the same, there will be mess again.
Easiset just to make the 'label' a language variable. Can easily support the common names like size, shape, length, widht, height, color, etc. So the label should simply match up to the converted variable.
On import, if identifer is provided, it should be used to distinguish the feature. If not, then the first hit on the name should resolve to @this. It's not that complicate to do from the beginning and provide backward compatibility for import, but it's much harder to do later AFTER things are implemented and base data exists. The upgrade should attempt to resolve all feature names to common identifiers. The list of those common identifiers should be published.
@Imac, @ikoshin - any comment about it from cs-cart team?
I've noticed that you've asked for the feedback but when the problems started to appear you stopped replying.
One more thing, we started to create new products as a single products and we stopped grouping them in option combinations. Could you confirm that everything goes according to the plan and 4.10.1 will be released soon? I don't want to be left high and dry.
@Imac, @ikoshin - any comment about it from cs-cart team?
I've noticed that you've asked for the feedback but when the problems started to appear you stopped replying.
One more thing, we started to create new products as a single products and we stopped grouping them in option combinations. Could you confirm that everything goes according to the plan and 4.10.1 will be released soon? I don't want to be left high and dry.
Love the darkness of product development at cs-cart. How can you still be targeting a mid-April release with the issues that have been raised. It would help us all if you would respond specifically to the issues raised given that you actually asked for input.
I for one would like to see a response on each and be able to have a discussion related to your responses if necessary.
If the points we've raised are valid (which I believe they are and are critical) then there is no way you can refine and communicate the requirements (so we're sure you get it) and have time to specify, develop, test and integrate a solution into a product release within 2 weeks.
The risk of taking this out of beta and making it product where it does not address the real business problems that exist would be a huge mistake on cs-cart's part. It is a significant change to how products are defined, managed and presented within your product. It affects both back and front ends. It wouldn't be unusual, but I would hope that over the years you might adjust your process to be more transparent and inclusive of customer responses.
It would help us all if you would respond specifically to the issues raised given that you actually asked for input.
I for one would like to see a response on each and be able to have a discussion related to your responses if necessary.
And (not having tried to use variations yet) [...]
I will try to take a deeper look at the demo over the weekend (but I'm packing to move so time is limited). Your last "Note" causes me concern. Seems like any "options" related to a product's variations should apply whether they are global or not. I.e. my car-cover example options and modifiers should apply to all variations whether year/make/model are global options or local and specific to the base product. Year/make/model are options of a car cover product that vary by color and fabric. Requiring options to be global will just pollute that global space by forcing things that should be local as global. And then the naming conflicts become greater too without identifier/name as separate properties.
I may be old school, but when trying to communicate functionality and specifications (especially via written responses), having them in the form of functional actions, requirements and use-cases makes reviewing by many a lot easier (can see the whole picture rather than an overlooked tab or link in a demo). It triggers people to think about things they may not have considered.
I spent some time this morning on the demo site. The workflow is horribly confusing and there is no real flow when creating a new product that will use variations. I strongly suggest when one creates a new product (click the + icon) that you ask them up-front whether it's a standard product or a variation based product. Then have the flow be applicable for that type. Having to create, save, then bounce between tabs trying to get options and features defined/configured is not very intuitive and you can't see the "picture" of what you've done or are doing. You can leave the tab based approach for "editing" a product, but to create a new one, you should have a workflow.
On the features tab, why is it asking me to select the feature value after I've defined the product as a variation? Shouldn't it just be a checkbox for each feature that I want to use for that variation? I would enter feature values for non-variation features. Thought this was supposed to be inclusive. I.e. if I selected Color that it would create a variation for each color based on the feature values for color. I could then delete the variations I don't want for this particular product.
The implementation is muddled and really looks like it was scabbed onto the object type "product".
See my concerns above for the requirement of things to be global. Defining variations to use Features is going to make feature management a huge support nightmare.
Seems that the best approach to doing variations would be to have the products table use product_id/type as the primary key and have a completely different workflow and presentation in admin for the two very different types. If you're going to do variations with the restrictions you have in place for all this global data, then you certainly want to separate it from the main product process/definition.
Since you're trying to model what Shopify does, you should make it simple and easy like Shopify (though the have significantly less capability) to establish the options that make up the variations.
But if you really wanted to do it right, you'd make variations based off options and support modifiers for the variations. Price would be a computed value based on modifiers. Then you could really leverage the power you have over your competition. It would only take adding a name field to the option combination (for customer side display) that could be defaulted based on the combination values.
I only got involved in this discussion because I'm working with a client on a Shopify integration for their MVE clients. Converting between Shopify and option combinations is awkward, but quite doable. Shopify as well doesn't have the concept of a base product unless there are no options defined. You also can't edit options once they're in place, you have to recreate a product to redefine it. But all "variants" of a Shopify product are local, not global.
So you can be "better" or "me too". But your current "me too" is 20X harder to understand/implement than Shopify.
Not trying to be overly critical, but when you take a major step like this, you should really get it right and get lots of feedback before you start developing anything so you know what to build.
As far as I understand, all products having a product_id are turned into abstract products, each representing a set of general ideas (called features). The concrete products are now those that bear a variation_id, which represents the materialization of this or that general feature, say, color, into feature variation red, blue, yellow, etc. If a general product Shirt has no color or size variations, it will remain in the Plato's cave, hovering in the limbo of abstract ideas.
Thanks. Will the variations have a "child" access to the main product_id-related features, descriptions, etc., or they will be reproduced in a separate product table raw?
If I have sequential options for 25 car manufacturers, each with 20 models and 50 years of "car covers" where I have 3 variations based on color (black, white and blue)., I can't have (25X20X50*3 variations). That would be 75,000 variations for 3 colors of my car covers. That would be pretty lame. So I contend there should be 3 variations of a product that has options that the user chooses of manufacturer, year, make and model and that the variations are the 3 colors of black, white and blue. There would be 3 products in the listing for black, white and blue and the user would then select from the options AND features to choose their product. Note also that the product might contain a modifier of +$10 if the 'model" chose is Corvette which would then be applied to the price identified by the variation.