Introducing A New Prototype—Product Variations (A Better Implementation Of Product Option Combinations)

General News and Announcements
61

I think that all of the cs-cart owners want to have finaly good solution for such an important future. We've been watching your efforts to do something way too long. 1,5 years in beta, postponing further development of our stores waiting for the releases, independent developers not able to improve their addons and not knowing how the things will be handled. And in the meantime you focuse your efforts on other things which noone needs or wants

Excactly! Im close to giving up waiting.

The interneational forum seems abandoned and no one is paying attention to it anymore. Please clarify if you've decided that you concentrate your efforts on the russian builds only?

Things do seemed to have slowed somewhat,

62

If you don’t mind, I’ll stick to the essential information in this message. That way it will work even out of context.

-----

Variations are a crucial part of CS-Cart, and a widely-requested one as well. That’s why one of our current goals is to bring product variations out of beta. We’ll be able to do that once the basic functionality of variations (as in, what they allow merchants to do on their storefront) meets the needs of merchants who use CS-Cart. There are many needs (like ERP integration, convenient export and import, etc.), but in this message I’ll focus on the needs related to the basic functionality.

Here are some of the needs we see:

1. Multiple variants of a product with different prices, quantities, images, etc.

2. Showing those variants in the product list either as separate products, or as one product (with the selector on the product details page). Maybe even both: for example, if a T-shirt has different colors and sizes, I’d display colors as separate products (with own URLs and SEO names) and leave the size selector on the product page.

3. Filtering these variants.

4. Easy management, not only via import and export, but also in the admin panel.

Variations in their current form only address point 1, and, partly, point 4 (I’m saying “partly” because of some import/export complications and the presence of extra entities, such as “configurable product” and the old “option combinations”, which is confusing). For technical reasons, we need to address point 2 and 3 before moving on to 4. The goal was threefold:

• Find a solution that will address all the points above (and a few others mentioned earlier in this topic).

• Find a solution that merchants can start using without a hassle (just like there was a way to turn option combinations into product variations).

• Find a solution that is feasible from the programming standpoint.

• Find a solution that doesn’t overcomplicate CS-Cart (and preferably, simplifies product management for merchants).

The introduction of “product groups” mentioned by Jacek is the first step in that direction. In their current state, product groups act like variations, but are based on product features and allow customers to switch between separate products. So, there is no “parent product”: customers see all these products appear on the list, but switch between them just like they switch between variations. If you don’t want some products appear on the storefront as separate items, you can create them as variations.

Ultimately, we’re planning to base the mechanism of switching between similar products (be it the current variations, or the to-be-implemented product groups) on features, and have all variations appear on one tab on the product editing page in the admin panel (regardless of whether or not they appear on the storefront as separate products). Just as I’m writing this message, we’re working on tasks that aim for that goal. For now, product groups just exist alongside the current implementation of variations.

Please note that product groups are at an early stage of development. We wouldn’t have mentioned them at all in their current state, if it weren’t for a question on the Russian forum whether or not CS-Cart allowed switching between normal products just like between variations, and without an abstract “parent product”. We simply said we were working in that direction and provided an example.

-----

I realize there are still many questions, but I can only tell so much at this point. If you’d like to have a look at what we’re working on, product groups in their current state are available at http://dev.demo.cs-cart.com. We’ll announce the upcoming changes officially once we’ve made enough progress, once there’s something solid to give feedback on. Until then, things may change significantly (potential shortcomings addressed, bugs fixed without mentioning it, etc.).

Still, I hope that clears up some things about our plans and what we’re working on.

63

Ikoshin, first of all I would like to thank you for your answer.

I know that you're trying to improve the software and I understand that it is complicated process. Managing this kind of a change in a software architecture and providing backward compatibility is never easy.

Anyway, try to be in our shoes. As an entrepreneur and a person responsible for the e-commerce channel in my organization I need to have some reliable answers on which I can base my decitions and plan the feature growth and actions. Right now, even after your answer I'm still not sure what will hapen in the feature.

1) Should I switch to product variations right now (even though they're in beta and are missing some of the basic features)?

2) Should I wait for the product groups even though in my opinion their design will introduce chaos for the catalog management?

3) Will product variations and product groups be marged together? If yes then when and how? If not, will they function as a separate solutions?

4) How to transform product options in bulk to one of the above solutions? Will this function be available or should I write some kind of a migration tool all by myself?

5) Should I develope missing features as a form of addons for the current state of product variations? If yes, how many changes will you introduce and how expensive will it be for me to keep up with those changes?

As entrepreneurs and store owners we have to keep up with our competitors.

For 1,5 year I've been saying to our teammates that essential e-commerce features they need are gonna be introduced by cs-cart team very soon. In this time nothing happens and our competitors gain market share in our niche because they've gone with another software vendors.

In e-commerce we make promise to our customers that we will deliver them goods within given time. We don't tell them, give me your money and someday you will get this and that but I can't promise you when it will be and how the delivered product will look like. In my opinion, the second statement shows your behaviour right now.

So please, no more "we will", "we're working on it" etc. Simply tell us exactly when you will introduce final solution and how it will work.

I'm sure you have already figured out the software architecture of this and that you know how the final software will look like. Share this knowledge with us, give us solid timeline and keep the fingers crossed that we will be willing to stick with you until you launch it.

E-commerce is changing dynamically. We need to adapt or we will die.

64

I've got to agree with Jacek here. I'm in the same boat...

65

+1 to Jacek.

Customers will only hang on for so long.

Thankful that I can stick with option combinations on our 200 product catalogue.. couldn't imagine dealing with 20,000 products.

Good luck!

66

+1 to Jacek.

We must at some point decide whether to wait for csc developments thus fall behind our competitors or to move on. Crunch time has passed and we are setting up a new VPS to use an alternate eCommerce software. Its a lot of work and learning new software is painfully time consuming, but we now see no choice. We will keep CSC licences active, living in the hope, but right now we must seek a more suitable platform.

A few months ago Simtechdev asked for suggestions regarding addon development, my reply was:

My suggestion is that Simtechdev lend to cs-cart a few programmers so that they can finish Product Variations and then update the eBay sync addon!
Otherwise cscart will die, and there will be no cscart to addon to.

There was a little sarcasm there, but they seemed to take my point.

67

I’ve compiled a short list of questions and answers. This is all I can say until the official announcement, and a lot of things are subject to change.

—

What is all this about?

It’s about product groups, a new functionality of the Product Variations add-on. They are available at http://dev.demo.cs-cart.com/admin.php. Currently they work as follows:

1. Create a product feature (or multiple features).

2. Specify the right purpose for it (switching between similar products).

3. Go to the product editing page and specify different values of this feature for a few products.

4. Create a product group in the corresponding tab on the product editing page.

You’ll be able to switch between different products just like between the current product variations.

—

Why add product groups when variations already exist?

Variations don’t address some of the needs of merchants. They can’t be displayed on the storefront as separate products; instead they require a parent product (a so-called configurable product). Also, variations can’t be filtered, because there is no filtering by options right now.

—

What are the differences between product groups and product variations?

Note that I’m speaking about the current state at http://dev.demo.cs-cart.com/admin.php. As any yet-unreleased and unannounced functionality, product groups are subject to change.

Variations: you create one product, then generate its multiple variants based on options. All these variations appear as a single product on the storefront. Also, a variation doesn’t have its own URL or a unique SEO name.

Groups: you create multiple products (with unique SEO names and URLs) and add the ability to switch between them via features. Each of the products is displayed separately on the storefront, but to customers it looks just like switching between variations.

—

Why are product groups based on features rather than on options?

We realized that there should be a clearer distinction between features and options.

An option is supposed to be something extra, and not necessarily required for a product or specific to it (like gift wrap, prolonged warranty, etc.)

A feature is an inherent trait of a product (for example, color or size), inseparable from the product. Changing a value of a feature means having a different product (even if it’s only slightly different).

—

Does it mean that product variations should also be based on options?

Yes, that’s the plan right now. Naturally, if variations exist in your store, they’ll continue to work as they do now, even if you upgrade to a CS-Cart version where variations are based on features.

—

Can groups and variations work together?

Yes, absolutely. They complement each other: use groups when you want to display separate products on the storefront (for example, different colors of the same T-shirt), and use variations when you don’t want to display separate products on the storefront (for example, different sizes for every color of the T-shirt).

—

Will product variations and groups be merged into a single entity, or will they work separately?

Technically, groups and variations will probably remain for separate use cases (see the example with T-shirt above). But they may end up on one tab, and one of the goals is to make them easy to manage.

—

How do I transform option combinations to option variations or product groups?

There is a way to turn option combinations into product variations. However, it currently needs to be done product by product. When that functionality was implemented, it didn’t account for product groups. That’s why we are not developing it further right now. That question can be revisited once we finish implementing product groups.

—

Should I switch to product variations right now, or wait for product groups?

It depends. If you’d like to use the functionality of product groups (such as unique SEO names and URLs for some “variations”), it’s best to wait. There might not be a functionality for turning the existing variations into groups.

—

Should I develop missing functionality as add-ons for the current state of product variations?

It’s best to avoid customizing the current implementation of product variations. We will make changes to them; the extent is unclear, but can be approximated from the answers above. For example, before the release of product groups we’ll be looking into simplifying product management by getting rid of parent products for variations.

—

What is the release date of the new functionality?

We don’t have an exact date. We’re hoping to finish implementing product groups within the next couple of months.

68

A feature is an inherent trait of a product (for example, color or size), inseparable from the product. Changing a value of a feature means having a different product (even if it's only slightly different).

You will arrive soon at the fundamental philosophical question of primary and secondary qualities :-)

69

I'm finding that when I use combinations, the first combination's main image is the thing that shows up as the thumbnail in category view.

I assigned a special image to the "parent" product, but this just shows up on the back end as a thumbnail. This should also be what appears in the category grid so the user knows that there are many more colors available.

In other words, to use the t-shirt example, I should be able to assign a special image (that shows all color variations) so the user knows what’s going on as he clicks through the category view. Right; now, he’ll just be looking at whatever color the first combination happens to be.

Am I missing something?

70

I have tried to use features on a variant without success. I have lets say a t-shirt that on the Configurable has the feature color: "black". The color black is shown as the feature on the product. I have a variant on the product that is white, so I specified the color" White" on this variant. When I choose the white product, it still says black on the color feature. The SKU updates correctly, but not the color (or other features specified on the variant.) Any ideas?

71

I'm finding that when I use combinations, the first combination's main image is the thing that shows up as the thumbnail in category view.

...etc

That's actually the default functionality, and not the first report of the shortcomings of such design.

There are pros n cons of doing it this way , and I think if the option is not-required then the main image shows until a selection is made? Problem is that you may want both main image to show in cat list and have non-required options.

I think there is a workaround..

72

@ikoshkin

I've been thinking about the implementation, which you are proposing. I've got additional important questions, could you answer them?

1) As you've come to a conclusion that each of the product should be a separata single product just grouped by a feature (moving away from options to features) how will this affect e.g. "Buy together addon" and other up-sell and cross sell natvie cs-cart functionalities and 3rd party addons . If you deny the users ability to display product group as a single entity and if I sell e.g. same T-Shirt but in 20 different colours then I will have to create and manage 20 different "buy together sets", right?

Same goes for "customers who bought this, bought also" and even 3rd party adddons like intelectual selection of products, product sets etc.

Don't you think that it will add more complexity to managing catalog, promotions, blocks etc?

If yes, do you plan to adress this issue and how?

2) Groupping products require store admins to fill out product data which in most cases is duplicate content (features which might be only slightly different like color, product descriptions, buy together sets, additional shipping cost and other). Will you provide any functionalities which will allow to clone e.g. product features from the base product to other similar products?

E.g. I sell baby strollers, each stroller has about 40 features. The stroller can be sold in 20 different colours. I can't imagine filling out the same data over and over again. Additionally, if I want to create a "Buy together set" where my customer can add compatible car seat (1 of 4 compatible models) and each of them is in 10 colors... It will be a nightmare not only for the admin but also for the customers.

Am I missing something?

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

Product groups and product variations have some critical flaws which couse that using them for us will be almost impossible.

Pros and cons of product variations:

[+] They allow to select which data should be unique for the given variation and which data is common (features, price, images, etc)

[+] Easy to use with upsell and cross sell adons and blocks

[-] No ability to filter product variations

[-] No ability to display different options on product category

Pros and cons of product groups:

[+] Easy to implement

[-] Difficult to manage duplicated content when managing big product catalogues

[-] Requires a lot of manual work in order to group products

[-] No ability to implement reasonable upsell and cross sell management.

So there is one idea how to solve this problem:

1) Every product is a single record in the db (like in product groups).

2) You can display all of the product groups in a new view (Menu: Product -> Product groups). There you can see all of the product groups which are unnamed (behaviour just like in current version of product groups).

3) You can decide if you want to name the unnamed product group, then:

a) You give it a model name

b) You give the display options (display as separate products in category/display as a grouped product in category)

c) You can overwrite the given data, e.g. set common description for the group, set common "Buy togheter sets", common features, shipping costs etc.

For store owners it's crutial to quickly create new products. Let us decide later what and how we want to display.

What do you think?

73

Hi,
following the Topic @ikoshkin enrouted me here.

As previously told and also noted from other CS cart user above,

while we all, at large, do apreciate the efforts to always improve Cs Cart, This Not answer many business needs

I'm sure there are many business who need the variation on CAPACITY.

All those selling Liquids but not only.

-even Presta ( !!!) has a way to Post a Product ( IE: wine )

with Different Capacity ( Bottle : Mignon, midi, Standard , Magnum , Jeroboam and on...)

on Same Product page and then, on customer selection ( Capacity based : 0,20, 0,75L. 1,5 L. 3 L 50L )

having the Image switching accordingly AND the possibility to give Diferent Quantity Discount Based on That Choosen Item

Because I can give a 5% off on the box of midi, but not on Magnum, or 20%Off on a Jeroboam pack of 3.


And same goes for Parfumes, oils, or Weight....

WIthout the need to do l, ets say for rhe sake of our purpose, 10 Products page for the SAME Product.


This told without prejudice, maybe,

hopefully, it's just we who get it wrong

74

I've been thinking about the implementation, which you are proposing. I've got additional important questions, could you answer them?


Of course. But there's something I must point out first: I can't delve into details just yet. Product groups are still a work-in-progress, so many things (such as their import and export, optimal creation & management process etc.) haven't been addressed yet. For example, for import purposes we're thinking about having a field such as "Group identifier" (I saw that you suggested something like that earlier).

The main point you brought up (filling out data for multiple instances of the same product) is supposed to be addressed by product cloning, bulk editing, or export/import functionality.

I can't speak about third-party add-ons (for obvious reasons), but as for "Buy together", I think we're approaching the same problem from different angles. Instead of asking "How will product groups work with Buy Together?", I'd ask "How will Buy Together work with product groups?" I think that in a technical way, product groups and variations are a more essential functionality, and "Buy together" should be built around them, rather than we build product groups around "Buy together".

When choosing between product groups or variations (there'll be both ways), you'll have to answer a question: "I sell a product with 40 color variants. Do I want each color occupy a separate spot in the catalog?". If yes, then you'll specify that when creating a feature. If not, you'll also specify that when creating a feature, and you'll have a single product in the catalog, with the ability to switch between its variants (just like the case with variations right now).
75

Post a Product ( IE: wine )
with Different Capacity ( Bottle : Mignon, midi, Standard , Magnum , Jeroboam and on...)
on Same Product page and then, on customer selection ( Capacity based : 0,20, 0,75L. 1,5 L. 3 L 50L )
having the Image switching accordingly AND the possibility to give Diferent Quantity Discount Based on That Choosen Item
Because I can give a 5% off on the box of midi, but not on Magnum, or 20%Off on a Jeroboam pack of 3.


Variations can already do all of the above; please check the T-shirt product at our demo. Product groups (here's how to try them) will add to that by allowing you to display different bottle capacities as different products in the catalog, but will preserve the ability of variations to switch between these products.
76

The main point you brought up (filling out data for multiple instances of the same product) is supposed to be addressed by product cloning, bulk editing, or export/import functionality.

-----------

Bulk editing and managing the data

This will not solve the problem. In case of import/export there is no option to import features right now. Even if there will be, you still need to do plenty of manual work.

Same goes for product cloning. You are all the time forgeting about the users who create products in store via API or by integration with ERP systems.

The only way I can imagine it right now is following:

1) You fill out the features for one product

2) You go to product list view, select the similar products with no features

3) You click "Copy features from another product" option and you point the product from which you want to copy the features. In the configuration you have the ability to point out which features you want to copy and which you don't want.

Probably there will be plenty of other bulk editing options needed for the product groups. That is why I would suggest to create a product groups view in the menu where you could see all of the products which are grouped (something similar to MVCommon Products. If you could name the groups there, then you could also create an option to display "named" product groups as a single entity in category view.

-----------

Buy Together architecture

You should have an option to select the product group and other products/groups that create the buy together bundle and apply the business logic to those entities.

-----------

Ability to display other products from the group in the single product on category page

Plenty of users want to have the ability to display other products from the group on hoover or below the main product on category page (just to show that there are other color/size etc. options). Will you implement this or it's not possible in the architecture of your solution?

-----------

Displaying additional data on the product view (store front)

If I sell 3 T-Shirts in the group (Blue, Green, Red) and the the user is currently on the Blue T-Shirt page and the Red T-Shirt costs much more then the user should get this information. Same goes for the availability of the product.

-----------

UX of the product group in product view

This one is linked with the issue above. If we have to display additional data, then maybe you should rethink the design of the dropdown. You can use e.g. Select2 library to show the image/price/availability in one place. Or you could create a mini grid with thumbnails, subtitles, availability indicator (green/red dot) and price.

Right now you have duplicated funcionality. The list and the thumbnail are used for the same thing, switching between products.

-----------

Adding barcode field in the products table

Right now the only way to add barcode (ean/gtin) to the product is via features. Gtin/ean is not translatable and should be moved to cscart_products db table. It would improve the speed of generating datafeeds for price comparison engines, google and other services which rely on the barcode. If variations and product groups are separate recrods in the db, it's the proper way to place it.

-----------

You should address those issues before you decide on the final architecture of the product groups. Otherwise the same thing will happen as with product variations. 1,5 years of development without any results which can go to the production environment.

Simply said, you should first go back to the whiteboard, figure out all of the problems and only then start coding.

77

Hi,

I hope when the change of new variation complete, it will not affect the current variation products much because i dont want to relist few hundred to thousand products.

78

We are very happy with the Product Variations feature. It solved a few issues for us as we have deep integration with ERP system.

The two issues we have now is:

1. We would like an easier way to edit the Product Code (SKU) on the variations. Now we have to click on each variant, edit, save, click on variants again, click on correct variant, edit, save etc.. this is time consuming. the Product Code is very important as it gets stock, price, status etc from ERP.

2. We would like to get updated features/functions when you change the variant with the drop down on the product. The features seems to be static with the values of the default product. We have for example GTIN on each variant, but it only shows the GTIN for the default product, not for each variant.

79

Which ERP have you integrated?

80

It seems that product subscriptions are not triggered correctly with product variants. Does anyone know if there is a way to trigger the sending of subscription e-mails (Product is now back in stock) thru the API?