Jump to content

  • You cannot start a new topic
  • You cannot reply to this topic

Variations 2.0 In Cs-Cart & Multi-Vendor 4.10.1 Rate Topic   - - - - -

 
  • imago
  • Senior Member
  • Members
  • Join Date: 18-Oct 18
  • 461 posts

Posted 23 March 2019 - 06:45 AM #41

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. 



 
  • tbirnseth
  • CS Cart Expert
  • Authorized Reseller
  • Join Date: 08-Nov 08
  • 11291 posts

Posted 23 March 2019 - 04:53 PM #42

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.


EZ Merchant Solutions: Custom (USA based) B2B Development, Consulting, Development and Special Projects (get a quote here).
Commercial addons, payment methods and modifications to meet your business and operations needs.


 
  • tbirnseth
  • CS Cart Expert
  • Authorized Reseller
  • Join Date: 08-Nov 08
  • 11291 posts

Posted 23 March 2019 - 05:02 PM #43

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.


EZ Merchant Solutions: Custom (USA based) B2B Development, Consulting, Development and Special Projects (get a quote here).
Commercial addons, payment methods and modifications to meet your business and operations needs.


 
  • imago
  • Senior Member
  • Members
  • Join Date: 18-Oct 18
  • 461 posts

Posted 24 March 2019 - 06:23 AM #44

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...



 
  • tbirnseth
  • CS Cart Expert
  • Authorized Reseller
  • Join Date: 08-Nov 08
  • 11291 posts

Posted 24 March 2019 - 05:24 PM #45

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).


EZ Merchant Solutions: Custom (USA based) B2B Development, Consulting, Development and Special Projects (get a quote here).
Commercial addons, payment methods and modifications to meet your business and operations needs.


 
  • imago
  • Senior Member
  • Members
  • Join Date: 18-Oct 18
  • 461 posts

Posted 25 March 2019 - 10:44 AM #46

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-car...ozdayutsya/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.



 
  • Jacek
  • Advanced Member
  • Trial users
  • Join Date: 13-Dec 12
  • 132 posts

Posted 25 March 2019 - 12:09 PM #47

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.



 
  • imago
  • Senior Member
  • Members
  • Join Date: 18-Oct 18
  • 461 posts

Posted 25 March 2019 - 12:46 PM #48

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.



 
  • tbirnseth
  • CS Cart Expert
  • Authorized Reseller
  • Join Date: 08-Nov 08
  • 11291 posts

Posted 25 March 2019 - 05:07 PM #49

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-car...ozdayutsya/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.


EZ Merchant Solutions: Custom (USA based) B2B Development, Consulting, Development and Special Projects (get a quote here).
Commercial addons, payment methods and modifications to meet your business and operations needs.


 
  • tbirnseth
  • CS Cart Expert
  • Authorized Reseller
  • Join Date: 08-Nov 08
  • 11291 posts

Posted 25 March 2019 - 05:11 PM #50

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.


EZ Merchant Solutions: Custom (USA based) B2B Development, Consulting, Development and Special Projects (get a quote here).
Commercial addons, payment methods and modifications to meet your business and operations needs.


 
  • imago
  • Senior Member
  • Members
  • Join Date: 18-Oct 18
  • 461 posts

Posted 26 March 2019 - 06:32 AM #51

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.



 
  • tbirnseth
  • CS Cart Expert
  • Authorized Reseller
  • Join Date: 08-Nov 08
  • 11291 posts

Posted 26 March 2019 - 04:57 PM #52

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.


EZ Merchant Solutions: Custom (USA based) B2B Development, Consulting, Development and Special Projects (get a quote here).
Commercial addons, payment methods and modifications to meet your business and operations needs.


 
  • Jacek
  • Advanced Member
  • Trial users
  • Join Date: 13-Dec 12
  • 132 posts

Posted 27 March 2019 - 01:00 PM #53

@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.





 
  • ikoshkin
  • Tech Writer
  • CS-Cart Architects
  • Join Date: 25-Nov 15
  • 370 posts

Posted 28 March 2019 - 07:06 AM #54

@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.


Sorry, I haven't been able to reply in this topic for a while. It does take a considerable amount of time to investigate each point and to provide a detailed reply. I did it until it interfered with some of my other urgent tasks related to 4.10.x.

I do keep track of all the comments here though, and have listed some of the mentioned requirements on our internal issue-tracking system over the course of this week (either as "bugs", or as "feature requests"). I'll go through the most recent comments next Monday and address as many points raised as I can.

As for the release schedule, we are still aiming for the second half of April. If anything changes, @imac will mention it in the video report. These reports have the most up-to-date information available.

 
  • tbirnseth
  • CS Cart Expert
  • Authorized Reseller
  • Join Date: 08-Nov 08
  • 11291 posts

Posted 28 March 2019 - 04:01 PM #55

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.


EZ Merchant Solutions: Custom (USA based) B2B Development, Consulting, Development and Special Projects (get a quote here).
Commercial addons, payment methods and modifications to meet your business and operations needs.


 
  • ikoshkin
  • Tech Writer
  • CS-Cart Architects
  • Join Date: 25-Nov 15
  • 370 posts

Posted 29 March 2019 - 05:46 AM #56

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.


I'll try my best to reply on Monday, but until then, there is one thing I'd like to ask.
 

And (not having tried to use variations yet) [...]


Have you tried the new variations since then?

They are available at our dev demo: search for tshirt to find the new variations, then switch to the "Variations" tab of any variation – some variations have more properties than others. We call those variations catalog items (here's why). Alternatively, try going to the "Variations" tab of any other product and adding variations – I think the interface does a pretty good job at explaining how to do it.

We've made variations available at the dev.demo because we think it's better to try them rather than hear us describe them. Besides, the demo can answer some of the questions raised in this topic better and faster than I can.

Note: there is one thing that isn't obvious in the interface yet, but will be made obvious: only global options added to a "default variation" as links will appear on all the other variations of the catalog item.

 
  • tbirnseth
  • CS Cart Expert
  • Authorized Reseller
  • Join Date: 08-Nov 08
  • 11291 posts

Posted 29 March 2019 - 06:39 AM #57

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.


EZ Merchant Solutions: Custom (USA based) B2B Development, Consulting, Development and Special Projects (get a quote here).
Commercial addons, payment methods and modifications to meet your business and operations needs.


 
  • tbirnseth
  • CS Cart Expert
  • Authorized Reseller
  • Join Date: 08-Nov 08
  • 11291 posts

Posted 29 March 2019 - 05:36 PM #58

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.


EZ Merchant Solutions: Custom (USA based) B2B Development, Consulting, Development and Special Projects (get a quote here).
Commercial addons, payment methods and modifications to meet your business and operations needs.


 
  • ikoshkin
  • Tech Writer
  • CS-Cart Architects
  • Join Date: 25-Nov 15
  • 370 posts

Posted 01 April 2019 - 06:20 AM #59

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.


That's not entirely correct. There is no such thing as abstract product. Regardless of whether there's a variation_id or not in the URL, it's a still a separate product (with quantity, price, a combination of features, etc.).

"Variation" (or "belonging to a variation group") is more like a state of the product, that allows switching to other products in the same variation group. If the product is removed from the group, it becomes a standard, separate product.
 

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?


Within a "variation group", products aren't equal. That depends on how the features that define the group are configured.

For example, at http://dev.demo.cs-cart.com we have T-shirts of various colors and sizes. Color is a feature that warrants a separate catalog item (as in, SEO name, description, and a separate position on the product list). That catalog item is one page, and it includes sizes (variation_ids). When multiple variations share one catalog item, then the default variation will be available by SEO URL, and other variations (variation_ids) will inherit some of its properties. That default variation is also one of the products you can buy, but it's just displayed to customers by default and provides product properties for other variations in the same catalog item.

 
  • ikoshkin
  • Tech Writer
  • CS-Cart Architects
  • Join Date: 25-Nov 15
  • 370 posts

Posted 01 April 2019 - 06:57 AM #60

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.


First of all, I'm no expert on how car covers are produced or sold, or how their "quantity in stock" is calculated. If I knew it for certain, I might've offered a different suggestion. But your description seems correct.

You said you only need 3 products on the list: "black", "white", and "blue" car cover. Then you create a feature called "Color", with "Purpose: Group catalog items as variations". That will give you the ability to switch between 3 car covers (catalog items) right on the product page. Now, let's assume they're custom-made from the material of selected color, so quantity is not a concern. Then the rest of the parameters of a car cover must be defined as options, for the customers to choose from or enter manually.

With option combinations or variations 1.0 you either had to create one product (car cover with selectable color option), or 3 separate products without the ability to select color on the product page. If that's not a concern, then variations 2.0 weren't even needed for this particular use case. But they were requested by many others.