Variations 2.0 In Cs-Cart & Multi-Vendor 4.10.1

Store Builder Feedback
1

In April 2019 we're planning to release version 4.10.1. It will include the reworked product variations, which should be more flexible and easier to use. Try them at http://dev.demo.cs-cart.com (see the “T-shirt” products on the storefront) and let us know if this functionality suits you.

In version 4.10.1 we are planning to bring variations out of beta. Once that happens, they won't change significantly, and third-party developers will be able to adapt their add-ons to work with variations.

--------------------

What's Different in Variations 2.0?

1. Variations are based on features rather than on options.
Features are distinguishing properties of the particular product, such as color, size, etc. Options are additions to any product (such as gift wrap or extended warranty). Previously, options partly played the role of features, and that was wrong. To create variations based on features, you'll need to select a correct "Purpose" for the feature. This is a new field in the feature settings. The tooltips in the interface should explain everything.

Check the demo to see how features for variations are configured: Color / Size

2. Some variations can now appear on the product list, if you let them.
Previously, all variations shared one product page, and that didn't suit every merchant. For example, if a T-shirt came in multiple selectable colors, all these colors couldn't be seen on the product list, and the customer could leave without finding the right product. Now, everything depends on the feature type. Different colors of a T-shirt can appear in the catalog as separate products with their own SEO names, and size selection can be limited to the product page, as before.

Check the dev.demo for a variation group based on 2 features (see the "Variations" tab).

3. Creating product variations got easier.
Previously, the variation import easily updated prices and quantity for variations, but creating new variations via import was complicated. In 4.10.1, to turn any product into a variation (or to create a new one), it's enough to set the values for the required features and specify the common ID of a variation group.

Compare the import procedure before and after the change.

4. Filtering by variations was added.
This was one of the most common requests, but it could be done right only after we moved variations from options to features. Go to http://dev.demo.cs-cart.com, proceed to the “Men's clothing” category and try filtering T-shirts by size.

How to Try Variations 2.0?
The demo at http://dev.demo.cs-cart.com/ already has the new variations. The homepage has multiple T-shirts of different colors (previously it was just one product, with all the colors on the product page). Every color has its own page with a unique SEO name, but customers can still switch from one color to another from the product page.

--------------------

Do let us know what you think about new variations. Do they suit all your needs? If not, tell us what task of yours they can't solve. That way we'll understand what else there is to be improved.

2

hard to understant how is working :-(


also api ready for this ?

3

Thank you very much for the information. I have a question regarding this use case:

I sell baby strollers, which can be in many different color variants (usually up to 20 colors). Our customers usually choose stroller based on the functionality (model) and the color is of secondary importance for them.

  • As far as I’m concerned, I should create a feature “Color” (Group catalog items as variations), right?
  • If above is correct, how am I able to clone descriptions and features for all of the colors.
  • How will it affect SEO. All of the color variations will have the same content (duplicate content). Is there a way to set rel=cannonical or avoid in any way problems with duplicate content? Did you in any way consult this with any of the SEO experts?
  • The same model of the stroller in different color can have different price. In option combinations there was an option to show price modifiers on the product option list. Right now this is not possible. Could you add an option to show it? Or at least add the hook to be able to implement it by 3rd party developers. E.g. The user is on the model-x-color-blue stroller page - price $1000. He can see that the model-x-color-special-edition costs +$200. I know that there is a show product variations list option but it requires additional click. The user should know before the navigating to another product page that the price might be different. It’s important in case of many color variants.
  • Right now there is no option to set the position of the variations on the dropdown list. If I want to display the green color first on the list (e.g. I have 20 in stock) I should be able to do this. It would be best to implement this based on drag-and-drop interface. Additionaly, in some cases I want to sort the list of variations based on price (Lowest to Highest) or in alphabetical order (A-Z). Could you add the sorting and position setting mechanism for this?
  • Right now I have 300 stroller models. If every model has up to 20 color variations it would make it really difficult to navigate through the category page (300x20 = 6000 products in the category). It would increase the number of category pages to paginate from 12 to 250). I think that you should be able to set on the category page if you want to display all of the color variations as separate products or display only first product of any model and add color variations as mini thumbnails below the first product. If I change to feature on which the variations are created to Group variations in one catalog item to sell strollers there are 2 problems: a) I cannot set different Gtin (Ean) feature for each product B) the user cannot see thumbnails on the product page in order to choose color
  • I think that you should add in cscart_products table additional field gtin (ean, barecode). It should not be in the features because it’s not translatable and it’s highly related to the product. It would also speed up datafeed generation for google and any other 3rd party markeplaces and price comparison engines. It would also allow to assign different gtin value even for products which has “group variations in once catalog item”
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.
  • There should be an option in bulk editing features to add a new variant. E.g. I have 20 different colors of the same model and I want to assign the value “Color” on which the variations are based. I select the products → bulk edit features → and there is no option to add a new value. I can only choose from the previously created feature values. Please add this.
I hope that you will answer all of my questions.

Good luck with new product variations. It’s really needed feature and the good design of them is crucial for further development and success of our store on cs-cart platform

4

hard to understant how is working :-(


also api ready for this ?

Yes, it can be hard to understand at first. Article https://docs.cs-cart.com/4.10.x/user_guide/manage_products/products/product_variations.htmlshould explain the basics, and the rest is covered by the descriptions in the interface. If you have any specific questions (what part is hard to understand), feel free to ask them here.

The API isn't ready for this yet, but it's planned.

5

then when we begin use this, we dont need options right ?

6

but i really love it. show all combinations like different product ( title, url) its really important for seo, cs-cart will be master when done common products and that.

7

I'm currently working on a Shopify interface for one of my clients. Will product Variations more closely map to Shopify Variants? I.e. if I have features of

Color: red, green, blue

Size: 1, 2, 3

Fabric: Cotton, Silk, Wool

Will it automatically generate a variant for each combination of those features and give me the ability to assign a SKU/product_code and price to each?

Will prices now be based on the variant versus a modifier of an option (I.e. size 3 is + 5%)? I.e. a Size 3 with Silk fabric might be +10% and for cotton 0% modifier.

And (not having tried to use variations yet) what the exact relationship is between options and variations especially as it relates to inventory control (like current option combinations) If the product is a configurable product and has a feature that matches an option name, will the option selection use the feature values? Or are they completely separate?

8
This new feature is awesome!
In my personal opinion:
1 / In each Variation should allow sellers to create more options.
2 / Instead of displaying Variations in the select form, we should add another way of displaying that the radio will be richer.
3 / If a Variation has other features, then it must apply the position? While Variations 1.0 does it
9

then when we begin use this, we dont need options right ?


Correct. New variations are based entirely on features. Options can be used for something different (as described in the first post of the topic).
10

I.e. If I have features of
Color: red, green, blue
Size: 1, 2, 3
Fabric: Cotton, Silk, Wool
Will it automatically generate a variant for each combination of those features and give me the ability to assign a SKU/product_code and price to each?


It will let you generate variations automatically (either for each combination, or only for selected ones), assuming that all the features have a correct value for Purpose (it's a new property on the feature editing page). The tooltips in the interface should be able to explain the rest.

Will prices now be based on the variant versus a modifier of an option (I.e. size 3 is + 5%)? I.e. a Size 3 with Silk fabric might be +10% and for cotton 0% modifier.


Even in the original implementation of variations (the one that we released as [Beta] earlier) each variation had its own base price. It could be further affected by option modifiers, but the new variations are based on features, so it isn't the case. In terms of price, every variation is a separate product.

And (not having tried to use variations yet) what the exact relationship is between options and variations especially as it relates to inventory control (like current option combinations) If the product is a configurable product and has a feature that matches an option name, will the option selection use the feature values? Or are they completely separate?


Option combinations and product variations are 2 ways of achieving roughly the same result (except that variations give merchants much more control). They are completely separate. Ever since we released the first implementation of variations, we knew that we'd be further developing them, not option combinations. Now that we've moved variations from options to features (hence the name Variations 2.0) and are planning to get them out of beta in the nearest future, it's the best time to check them out.
11

v2 support disable default variant selection ? coz main page listing show all time default variant image. not show main product image..

12

hello good news for version 2.0 ... i used beta version of variations in cs cart version 4.9.3 ...

if update to version 4.10.1 and variations add on 2.0 I will lose the products i make with beta version ??

13

I sell baby strollers, which can be in many different color variants (usually up to 20 colors). Our customers usually choose stroller based on the functionality (model) and the color is of secondary importance for them. As far as I'm concerned, I should create a feature "Color" (Group catalog items as variations), right?

If model is important, and color isn't essential, then I'd go with Purpose: Group variations in one catalog item for "Color". Model may or may not be a feature (depends on if you want to switch between models on the product page). If it is a feature, then you'd probably want to use Purpose: Group catalog items as variations for "Model".

The same model of the stroller in different color can have different price. In option combinations there was an option to show price modifiers on the product option list. Right now this is not possible. Could you add an option to show it? Or at least add the hook to be able to implement it by 3rd party developers. E.g. The user is on the model-x-color-blue stroller page - price $1000. He can see that the model-x-color-special-edition costs +$200. I know that there is a show product variations list option but it requires additional click. The user should know before the navigating to another product page that the price might be different. It's important in case of many color variants.

Thanks for pointing that out. We are keeping that scenario in mind during development. Though I can't promise that it will be included. I think it will mostly depend on performance.

Right now there is no option to set the position of the variations on the dropdown list. If I want to display the green color first on the list (e.g. I have 20 in stock) I should be able to do this. It would be best to implement this based on drag-and-drop interface. Additionaly, in some cases I want to sort the list of variations based on price (Lowest to Highest) or in alphabetical order (A-Z). Could you add the sorting and position setting mechanism for this?

The order is set via the positions of feature variants on the feature editing page. The implementation of other mechanisms would significantly prolong the development of variations and might have a negative effect on performance. So unfortunately, these changes are very unlikely, at least for the time being.

Right now I have 300 stroller models. If every model has up to 20 color variations it would make it really difficult to navigate through the category page (300x20 = 6000 products in the category). It would increase the number of category pages to paginate from 12 to 250). I think that you should be able to set on the category page if you want to display all of the color variations as separate products or display only first product of any model and add color variations as mini thumbnails below the first product. If I change to feature on which the variations are created to Group variations in one catalog item to sell strollers there are 2 problems: a) I cannot set different Gtin (Ean) feature for each product B) the user cannot see thumbnails on the product page in order to choose color

That is set via the two different Purposes of features. We're planning to improve the interface a little, so that customers would be able to select the desired variant of a feature, even if only one of the many variations is displayed on the product list.

I think that you should add in cscart_products table additional field gtin (ean, barecode). It should not be in the features because it's not translatable and it's highly related to the product. It would also speed up datafeed generation for google and any other 3rd party markeplaces and price comparison engines. It would also allow to assign different gtin value even for products which has "group variations in once catalog item"

We exchanged opinions regarding this in another topic. I still think that it's important not to clutter the interface with a lot of fields (that's what "Features" are for), but I understand the importance of some of the points you bring up, and we'll see if we can do something about it.

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.

It shouldn't be much different from the performance standpoint, although having a universal "Color" means you'd be able to create a universal filter by "Color". So, a universal feature is probably better, but that decision is up to you.

There should be an option in bulk editing features to add a new variant. E.g. I have 20 different colors of the same model and I want to assign the value "Color" on which the variations are based. I select the products -> bulk edit features -> and there is no option to add a new value. I can only choose from the previously created feature values. Please add this.

Unfortunately, there is a technical reason why we ask to add a new variant to a variation-capable feature first before assigning that variant to products. However, the restriction applies only to bulk editing in the admin panel; you can still use product export and import for that purpose. Variation-capable features can even be exported as separate columns.
14

How will it affect SEO. All of the color variations will have the same content (duplicate content). Is there a way to set rel=cannonical or avoid in any way problems with duplicate content? Did you in any way consult this with any of the SEO experts?

Variations that don't have their own catalog item will have rel=canonical to the catalog item. That doesn't work on the demo yet, but we'll address that.
15

hello good news for version 2.0 ... i used beta version of variations in cs cart version 4.9.3 ...

if update to version 4.10.1 and variations add on 2.0 I will lose the products i make with beta version ??


The plan is to make the transfer as smooth as possible. We still haven't implemented automatic conversion of variations 1.0 to 2.0 during the upgrade, but we're planning to look into it and implement it.
16

v2 support disable default variant selection ? coz main page listing show all time default variant image. not show main product image..


When you have variations, the image of a variation is always shown. Now, some variations share the same position in the catalog (more on that in the documentation). When variations share a position in the catalog, only the image of one variation is displayed. That variation can be selected on the "Variations" tab on the product editing page (use the gear button next to the variation).
17

If model is important, and color isn't essential, then I'd go with Purpose: Group variations in one catalog item for "Color". Model may or may not be a feature (depends on if you want to switch between models on the product page). If it is a feature, then you'd probably want to use Purpose: Group catalog items as variations for "Model".


I would do the same but if you add different images for different product variations under color, then you cannot see color thumbnails on the product page. In current implementation of product variations you cannot group variations in one catalog item for Color and have color picker (image thumbnails) on the product page. I think that this scenario might be essential to many users especially if you sell product where model is important and customers are aware that there might be many different color options. Try to implement a car purchase scenario, you first pick model, then you pick color etc. (e.g. https://www.toyota.ru/new-cars/).

Moreover, if model is important the description is the same for all of the color variants. If we copy paste descriptions we will get penalty for duplicate content in search engines. Please address this issue somehow.

Thanks for pointing that out. We are keeping that scenario in mind during development. Though I can't promise that it will be included. I think it will mostly depend on performance.

Great, I hope that you will include price modifiers in the 4.10.1 I've talked with an UX about this issue and it turns out it's pretty essential especially when you have to reload the whole page in order to know that the price has changed.

The order is set via the positions of feature variants on the feature editing page. The implementation of other mechanisms would significantly prolong the development of variations and might have a negative effect on performance. So unfortunately, these changes are very unlikely, at least for the time being.

What if you add new variant on the feature page. Default position is 0, are they sorted out alphabetically?

That is set via the two different Purposes of features. We're planning to improve the interface a little, so that customers would be able to select the desired variant of a feature, even if only one of the many variations is displayed on the product list.

Great! Can't wait to see that. Please remember of the mobile view as well. Using hoover to achiev this would be good but only for desktop. It would also allow to implement good category view for the model based products (as described above). Any mockups or ETA of this future? Will it be available in 4.10.1

We exchanged opinions regarding this in another topic. I still think that it's important not to clutter the interface with a lot of fields (that's what "Features" are for), but I understand the importance of some of the points you bring up, and we'll see if we can do something about it.

Please remember, that in new product variations if you choose purpose "Group variations in one catalog item" features are inherited from the base product. That is why barcode cannot be displayed on the product page after choosing different variant.

18

The plan is to make the transfer as smooth as possible. We still haven't implemented automatic conversion of variations 1.0 to 2.0 during the upgrade, but we're planning to look into it and implement it.

this is very important to implemented automatic conversion of variations .. i have make with beta 800 products for one shop and 650 products for other one!

19

Sounds like there are a lot of use-cases that need to be investigated. That you've announced that it's coming out of beta and there are still all these use-cases with responses of "we're thinking about doing" sounds like you don't really have a product to take out of beta yet.

Given this is a pretty radical change to the definition and presentation of products (along with many changes on the back end to deal with pricing, etc) I'd encourage you to get this one right BEFORE releasing it into the mainstream.

I personally don't see a lot of difference between this and option combinations (other than price can't be applied to a combination, it comes from the option modifiers). Seems the difference is in grouping and presentation within the catalog.

Seems to me an easier path for existing clients would be:

1) Add price override to combinations indicating that any option modifiers within that combination should be ignored and the fixed price used (then calculate quantity discounts and process promotions).

2) Add a title/name to the combination (default is value1/value2/value3)

3) Modify the listing pages and catalog data to show option combinations like products if they exist for a product.

With those 3 changes, what is the difference between having a whole new data type and fixing an existing mechanism that's been in place for years (not requiring all addon developers to make changes to existing addons nor really any re-training of merchant personnel).

It will then look just like Shopify. Note that Shopify is inferior to cs-cart in that once you set the variants for their options, you can't edit/add to them later. They also only support only 3 options and every option is a selectbox (no radios, checkboxes or text input in standard Shopify). And products with any options are always variants. I get that you want to compete with Shopify, but I think you're on the wrong track to do so. You'll be crippling cs-cart to compete with an inferior product.

20

Hi i just test some combinations, we cant create variants like v1 , right?

I just fnish my erp integration with api on v1, now you says v2 please fnish api support urgently