Hats Size [...] Shoes Size Womens Shoes Size Children Shoes Size [...] Book Size etc.
Each of these Sizes has its own variation logic and standards/unit measures. Classes of classes within subclasses of the general idea of Size...
I've been thinking on how to best organize such features, but it's very circumstantial (what sort of products you sell, whether the CSV/XML files from your suppliers have different types of sizes under one name, etc.) But even if you use one "Size" for all kinds of sizes, only the relevant variants will appear in the filter on the category pages. We've taken note of the problem with import and similar feature names though.
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.
First of all, thank you for taking the time to go through the interface and provide detailed suggestions. It is definitely food for thought. I'll try to address your comment point by point.
1. I doubt that we'll improve the flow of variation creation before 4.10.1. Changing the interface of something as basic as variations shouldn't affect backward compatibility, so it's not a reason to keep the add-on in beta. Besides, it is a significant undertaking, so we'd first need feedback from more merchants (or usage statistics from those who have explicitly allowed us to use it).
2. "Variation" is the state of a product when it belongs to a "variation group" based on some specific features. When a variation group is created around a product, it's important to understand what features to base the variation group on. That is determined by whether or not the values of these features have been specified. That's why a product must have some feature values before we can create a group.
3. Unfortunately, making variations based on options wasn't feasible. We did just that with variations 1.0, released it to the public as the Product Variations (Beta) add-on to gather feedback. It's been around long enough, and we've been investigating how to address all the feedback we received. So, variations 2.0 are the result of feedback about variations 1.0. The way I see it, this topic is more about adding finishing touches.
Please let me know if there are some concerns I haven't addressed.
It will not solve the problem because of a few reasons
1. In our use case there are too many changes with new colors coming to the offer and old colors leaving the offer. Changing all the time seo name would be frustrating and dangerous. What if we need to delete old color and we've spent our SEO budget for linkbuilding /toyota-rav4. We need to create 301 redirect, right? If we change this multiple times a year it also influences performance which leads to SEO penalty for given URL...
2. Right now there is no color picker in this purpose so we cannot use this.
@Ikoszkin
You didn't reply to this matter. I'm not sure how new product variations will be able to solve the problem with product models (e.g. baby strollers) where color is of secondary importance. There are 2 main concerns:
1) Content duplication and SEO
If I want to rank for a specific model keyword and color collections are introduced frequently than I will not have a unique url for link building. E.g. Writing a post on a forum or in social media like 'Check out brand new model of stroller XYZ here'. Will only lead to specific color variation. If this color has been removed (it's no longer available to buy from our supplier) I will loose all of the backlinks. What you could do at least is to provide a way to link to a specific product group.
I know that I could create a custom 301 redirect, but managing this in a big product database with thousands of products is not possible.
Moreover, I will have to copy all of the descriptions across the different color variations (the functional description of the stroller is the same) but I will get the penalty and it will lead to keyword cannibalization.
At least you could create an option to create a seo url that would lead to the given product group. It would solve this matter.
2) Duplication of effort
If you have three different colors of an a stroller, it’s probably feasible to write specific content for each one so that search engines aren’t seeing duplicated content.
However, if you have 30 collors of the same stroller, it’s much less feasible (and useful) to write that much specific content.
Moreover, right now it's not possible to copy features between product variations which have separate positions in a catalog.
I cannot imagine to constantly play copy&past if e.g. one stroller model has 40 features and one model can have 30 color variants.
Please, adress this issue and create some kind of mechanism that will solve those matters. I've proposed adding an option to create an abstract product from a product group. You will introduce soon common name. I don't understand why you cannot introduce common description and common url.
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 shouldn't have to be familiar with a product in order to define a system that supports what's stated. Limiting the perspective to garmets (tee shirts) is overly simplistic and only addresses one use-case.
Not sure you answerd the question on the work flow. Several issues.
1) this product has 3 colors. What about other products that have 10 colors and those 10 may not match any of the 3? Will they have to use one feature named Color?
You didn't confirm/deny how the option modifier might work as it relates to price for a Corvette option selected for one of the variations.
Color is pivotal feature, while size, in all its variants, forms the variations of the one chosen color feature, say, green. Select green as new product variation and all sizes will be created as sub-products with different titles but sharing one SEO name - medium for all sizes
There must be some logic behind all this, but I fail to see it.
Color is pivotal feature, while size, in all its variants, forms the variations of the one chosen color feature, say, green. Select green as new product variation and all sizes will be created as sub-products with different titles but sharing one SEO name - medium for all sizes
@imago, @Jacek, thank you for pointing that out. We've listed it on our internal issue tracking system, and it may be addressed before release. We could add the ability to specify a "Common SEO name" for a catalog item along with the "Common product name" that we're planning to implement. But currently, if you change the default variation for the catalog item, the SEO name of the catalog item (as well as features and description) will remain the same.
So, a "Common SEO name" can only address one issue, and that's automatic generation of a SEO name based on the common name. You can already achieve the same result by setting the SEO name of a default variation once (it won't change if you delete one of the products or change the default variation).
You shouldn't have to be familiar with a product in order to define a system that supports what's stated. Limiting the perspective to garmets (tee shirts) is overly simplistic and only addresses one use-case.
Not sure you answerd the question on the work flow. Several issues. 1) this product has 3 colors. What about other products that have 10 colors and those 10 may not match any of the 3? Will they have to use one feature named Color?
You didn't confirm/deny how the option modifier might work as it relates to price for a Corvette option selected for one of the variations.
1. Either way works. You can either have 1 feature called "Color" for all kinds of colors in your store, or multiple features called "Color" and have them assigned to specific feature groups/categories. What way is better depends on many factors (whether you use CS-Cart or Multi-Vendor, how your suppliers structure the data in CSV/XML files, etc.).
We realize that having multiple "Color" features calls for an internal name (just like we've done with global options). This request is listed and may be addressed.
2. Variations are based on feature variants. Feature variants have no modifiers, but each variation has its own price/weight (as intended). However, options work with variations. You can create a global option and apply it to the default variation of the catalog item as a link. That way, the option will apply to all other variations of the catalog item, and option variants will affect prices of variations. I've just tested it at the demo to be sure.
Please, adress this issue and create some kind of mechanism that will solve those matters. I've proposed adding an option to create an abstract product from a product group. You will introduce soon common name. I don't understand why you cannot introduce common description and common url.
Common name (and probably, common SEO name) will be specified on the "catalog item" level (default variation). Catalog items are separate products and are treated as such. Their properties are specified via default variations and won't be affected if another variation becomes default.
Essentially, the new variations are the refined product groups, but simplified to avoid complicated terminology and multiple tabs. Here's a scheme that might help:
Variation group───Catalog item===Default variation
│ ├─Some other variation
│ └─Some other variation
│
└─Catalog item===Default variation
├─Some other variation
└─Some other variation
Simple product (no variations)
Simple product (no variations)
Variation group───…
On the list of products, a customer sees only “catalog items”. A catalog item is either a “product”, or “a few variations grouped into one catalog item”. A “variation group” can include multiple catalog items. SEO name, product description, options and features are something that are determined on the level of catalog item (via the default variation), and aren’t affected when the default variation is changed. A simple product can be attached to the group to become a variation, and a variation can be removed from the group to become a simple product.
2. Variations are based on feature variants. Feature variants have no modifiers, but each variation has its own price/weight (as intended). However, options work with variations. You can create a global option and apply it to the default variation of the catalog item as a link. That way, the option will apply to all other variations of the catalog item, and option variants will affect prices of variations. I've just tested it at the demo to be sure.
I understand that for the backward compatibility reasons you leave product options. But I thought that the goal of variations 2.0 was to solve all of the headaches of product options in one solution. You cannot expect us to use both product options and variations at the same time.
If we decide to go with product variations we should avoid using product options. Why?
1) Store owners should have on product structure in order to be able to use datafeed generation, API etc. If we want to implement e.g. Google Shopping then supporting both solutions is very complicated. If we want to have a 3rd party ERP integration, we should have one implementation for the whole product base, not separate for different kind of products.
2) 3rd party addons will work only with product options or product variations. The logic to support both would be very complicated.
@tbirnseth, did you mean displaying price difference between variants on the dropdown list?
I've mentioned the lack of this feature in previous post. If I'm on the 'blue t-shirt size xl' page I should be able to see that 'blue t-shirt size l' is +$5. It should be calculated dynamically.
Moreover, I still believe that there is one scenario missing. Variations 2.0 should allow to implement abstract product in order to be able to solve the "model product" scenario. I've sent a PM to @ikoshkin with a video, which shows what are the problems right. I'm waiting for the response.
I understand that for the backward compatibility reasons you leave product options. But I thought that the goal of variations 2.0 was to solve all of the headaches of product options in one solution. You cannot expect us to use both product options and variations at the same time.
The purpose of variations was to address the problems of option combinations, not options. Options, variations, and option combinations are different things that serve different purposes. Feature-based variations do almost everything that option combinations (not options) did, and a lot more. And that's what they aim to replace.
But if you want a custom input field ("Custom engraving") or checkbox ("Extended warranty" that adds 20% to product price), you'll have to use options (not option combinations).
I've sent a PM to @ikoshkin with a video, which shows what are the problems right. I'm waiting for the response.
I've replied to your first PM and gone over the video you sent in detail, but I won't be able to reply to your second message today. In short: most of the points you raise there have already been listed as "feature requests". Some of them are even being worked on, and we're hoping to include them in 4.10.1. Others may be included in future versions.
The purpose of variations was to address the problems of option combinations, not options. Options, variations, and option combinations are different things that serve different purposes. Feature-based variations do almost everything that option combinations (not options) did, and a lot more. And that's what they aim to replace.
But if you want a custom input field ("Custom engraving") or checkbox ("Extended warranty" that adds 20% to product price), you'll have to use options (not option combinations).
For products that have only two variations, say, paperback and hardcover, what will be the preferred method for listing - via the old options, or by using the feature Cover as variation base? In the latter case, should there be a second feature for unfolding the variations - like Size for the base Color, and what will happen if the second feature is ISBN and its variants stick to one only Cover variant, one for paperback and one for hardback?
In the current v.2 logic, if we select hardcover as variation base, the system will create two product variations:
1) Book Title, Hardcover, ISBN 123-456-789-0
2) Book Title, Hardcover, ISBN 123-456-789-2
Only one of these two variations will be real, the other should be deleted as irrelevant.
Now, imagine that the second variation feature has 200 variants, out of which only two are relevant.
What if there is a third variation feature to be taken into account?
For products that have only two variations, say, paperback and hardcover, what will be the preferred method for listing - via the old options, or by using the feature Cover as variation base? In the latter case, should there be a second feature for unfolding the variations - like Size for the base Color, and what will happen if the second feature is ISBN and its variants stick to one only Cover variant, one for paperback and one for hardback?
In the current v.2 logic, if we select hardcover as variation base, the system will create two product variations: 1) Book Title, Hardcover, ISBN 123-456-789-0 2) Book Title, Hardcover, ISBN 123-456-789-2 Only one of these two variations will be real, the other should be deleted as irrelevant.
Now, imagine that the second variation feature has 200 variants, out of which only two are relevant.
What if there is a third variation feature to be taken into account?
To create variations, one feature with the right "Purpose" is enough (the choice of purpose depends on whether you want separate catalog items on the product list). But you can have 2, 3, or more features, even with different purposes, and a variation group will work with that.
Cover: Paperback / Hardcover most likely means you have X paperback books and Y hardcover books and keep track of their quantity separately. Then variations are the best choice. They'll let you set different price, weight, and images for each book. It will also customers to subscribe for a specific type of the book (paperback or hardcover) to receive an email notification when it's back in stock.
Some books may be only available in paperback, and others in hardcover. It's no problem as well: you just select the feature value and don't generate variations.
I don't think that ISBN is a feature that should have a variation-related "Purpose" (if I were to run a store, I'd set up ISBN as a "Help customers find products" feature).
I don't think that ISBN is a feature that should have a variation-related "Purpose" (if I were to run a store, I'd set up ISBN as a "Help customers find products" feature).
Thanks. I missed the Purpose thing. So, now features will have Group and Purpose.
Unfortunately, the final release of 4.10.1 will probably happen in May. Ilya Makarov's monthly video report should provide more information. We'll post the monthly report topic in the coming days.
By the end of April we'll release 4.10.1 RC. It is supposed to be installed separately from your store, and only for testing purposes. This will allow us to track down any issues that aren't possible to catch at the dev.demo. That's important, because the changes in 4.10.1 are pretty big (yet we're still backward-compatible).
Unfortunately, the final release of 4.10.1 will probably happen in May. Ilya Makarov's monthly video report should provide more information. We'll post the monthly report topic in the coming days.
By the end of April we'll release 4.10.1 RC. It is supposed to be installed separately from your store, and only for testing purposes. This will allow us to track down any issues that aren't possible to catch at the dev.demo. That's important, because the changes in 4.10.1 are pretty big (yet we're still backward-compatible).
I've just seen the Video Report that you just uploaded on russian youtube channel (I've watched it with automatic translation to English). Unfortunately, I have to say that none of the concerns that were raised in this topic have not been answered.
Please, before you upload english version, ask Ilya to read this thread. It's crucial to address the issues that were raised here.
I've just seen the Video Report that you just uploaded on russian youtube channel (I've watched it with automatic translation to English). Unfortunately, I have to say that none of the concerns that were raised in this topic have not been answered.
Please, before you upload english version, ask Ilya to read this thread. It's crucial to address the issues that were raised here.
I haven't watched the English version yet (it's in post-production at the moment) However, the contents of videos may differ, depending on what topics are brought up on each forum. But either way, the content of this month's video report won't change much. I'd like to explain why.
CS-Cart development is split into separate periods (sprints). A sprint lasts 2 weeks. Developers get all their tasks for the sprint on Monday, first week. New tasks aren’t usually assigned to developers until the sprint is over. This approach allows the developers to focus on their current tasks and prevents them from being distracted by the new tasks that arrive mid-sprint. It’s also easier for supervisors, because they know what will be done by the end of the sprint. This approach is a part of Scrum.
This topic was started in the middle of March, and feedback continued until April, all over the course of one sprint. Points raised in this topic could've only ended up on the following sprint, that was already in April. The video report covers the previous month (March), and has already been fully recorded.
P.S. I regularly gather points raised in this topic, record most of them as tasks on our internal tracking system, and bring them up with Ilya and the development team. The fact that I'm the only one replying doesn't mean that Ilya doesn't read this thread.