X-Cart forums

[Sativo]

Here's a new module that's currently in beta -- and will be released shortly.

This presentation is directed to business stakeholders, and not really meant as a marketing presentation, so if you just want to skip to the good stuff, slide the movie timer to 11:40

http://s209066815.onlinehome.us/adv_prod_options/adv_prod_options.html

Enjoy!

[Asiaplay]

Hi there,

Seems a nice approach - might get rid of the nightmare which exits when one adds more than one language and how X-Cart variants handles these.

Wondering if your new module also handles multiple languages?
Also if it can handle more than 2 languages (e.g. English, Russian, Chinese & German etc. etc. at the same time)?

Of course it would be even nicer if when languages are handled that the "attribute" in your example is a table where the attribute translated in the alternative languages sits (so we do not have to translate this product by product, but the option is recognised from the attribute language version automatically).

Thanks in advance for your advice.

Best regards,

Asiaplay

[somekindahate]

I watched the whole thing and was in agreement with all the flaws mentioned about the built-in variant system until the actual module functionality was discussed.

How typical is it that you would actually want variants of a product to show up as a single product? To me, that is horrible from an end-user perspective. If you are searching for a product, you would then have to sift through the product times the number of variants available. For example, if you are selling T-shirts, you wouldn't want separate product listings for every variation, you would want a single "parent" product and all the variants to be listed within that product page.

From an admin point of view, you wouldn't want to manage duplicate product descriptions for every single variant, as if it is a product like a T-shirt, you would have to update the description for X amount of variants if there was a typo in the description. Note, I am not bashing this module, just trying to see in what situation it would be beneficial.

[carpeperdiem]

I agree with somekindahate -- I sell makeup. I may have a single product that comes in 11 colors. I don't need a different description for the 11 colors - and the fact that I can have unique thumbnail images for each color variant is good --

Please tell me how/why you feel I need to change the paradigm, as you say in your video.

BTW, very nice presentation... but I am not understanding (from a merchant perspective) why the current parent/child relationship for variants needs ot be redone. As you said in your presentation, the entire world does it this way (including amazon, gap, old navy, etc...) Especially for clothing or makeup or other items where the item is essentially identical, with only the color or size changing.

Please enlighten me. What benefit will your module bring that we don't already have? What was your motivation to re-invent this? What specificaly do you find missing from the parent/child metaphor?

Thanks,

Jeremy

[Sativo]

Thanks for the comments... let's me try to explain the benefits a bit more:

The main reasons for keeping each product separate in your inventory record is that it's a more accurate reflection of the real world. From a system design perspective, you always want to mimic the real world as close as possible.

You guys do bring up some good points, and I've seen those addressed in other (non-cart) system where they create a matrix or a phantom product that acts as a container for all the other variant products. They use it as a way to help administrators locate each variant. Some systems allow you to link/unlink fields so that you can make global edits across all variants in your matrix (or options group).

My design doesn't offer this type of functionality, though probably could at some point.

Let me give you a couple scenarios where this module might be useful:

1. If you're managing your inventory records with a back-office ERP or inventory management system, most of them will have an record/entry for each product SKU as a separate item. So by doing this, your import/export data will more closely match these systems, making it easier to manage.

2. Say you have a shirt with two colors. If one color sells better than the other, you may want to promote the color that isn't selling very well to move your inventory. This would be easier to do if you could use functionality like Special Promotions (and other merchandising and promotional functionality) to apply promotions to that product.

3. Let's say you use multiple images to present your products (different angles of the same product, etc.). Currently, you could do this with the parent product, but you can only have 1 image for a variant. With this module, you can have all the functionality that the parent product enjoys... even multiple images.

BTW.. Jeremy, regarding the paradigm... I probably wasn't as clear on that point. Most all entry level carts like X-Cart get into this paradigm (as well as some mid-market carts like Elasticpath -- although their approach is a little nicer in that their variants product objects are just nested versions of the parent product chained together, so the do offer all the functionality at the variant level). But most enterprise level carts keep a separate record for each product... so I'm sure Amazon, Gap, etc... are in that boat.

Thanks.

[Sativo]

Asiaplay,

Sorry, but at this time, the language things is a limitation. I'll let you know if that changes in the future.

[carpeperdiem]

Nathan,

I'm not sure I am am following you re:

1. If you're managing your inventory records with a back-office ERP or inventory management system, most of them will have an record/entry for each product SKU as a separate item. So by doing this, your import/export data will more closely match these systems, making it easier to manage.

As it stands right now, using variants, my items have a unique sku per color, and when sales are exported, it imports very nicely into our accounting software. Inventory reconciles. We have a separate record for each variant. I still don't understand what your method brings to the table (besides variant groupings, which can be very cool for non-parent/child products, but then we're not really talking about variants then, rather, related products, yes?)

In xcart 4.1.8, if you sell a product that is identical except for color or size, a variant is the logical choice: the seller has one product description for the identical items; each color can have its own image; each color has its own sku/inventory tracking; it's easy/logical for the customer if they are buying more than one of the item-- shirt, blue - shirt, red. 2 items in the cart.

Where I see store owners not "getting it" is when they don't treat variants as unique items... using "product options", where variants should be used.

Amazon's system is just like xcart. A "parent" item is created -- and the "child" items have the skus. There is no "sku" for the parent (well, there is, but it's meaningless). When the customer navigates to any child item, they can switch to any other "child" variant at any time. All child products are related, but inventoried and tracked individually.

BUT, as you said in #3 - all items share a common description -- and this (in my opinion) is good. How many product descriptions do you want to see (as the customer) for the same shirt in 9 colors? Personally, I don't want to see any, except the color of my selected shirt. I really am not understanding what it is you're trying to do, and it seems like re-inventing the wheel to me.

I am really not understanding your motivation for this...

I get that you know your stuff, and are very qualified to do this, but I am not seeing the real-world application - that is, with version 4.1.x of xcart, it's already there, isn't it?

2. Say you have a shirt with two colors. If one color sells better than the other, you may want to promote the color that isn't selling very well to move your inventory. This would be easier to do if you could use functionality like Special Promotions (and other merchandising and promotional functionality) to apply promotions to that product.

How about change the Orderby field to put the lesser selling item as default? Of course any variant can have a different price. Ok, it may take a few extra clicks, but it's not hard to do. We do that on some of our products (that is, a variant has a different selling price than its siblings)

I guess I just don't get it.

[Sativo]

Sure, I understand. It may not be for everyone.

As for your points/questions, here's the idea:

You mentioned that your accounting system reconciles when an order is imported, so long as the variant SKUs are in the order. And you're right, from that perspective, there isn't a problem. But unless I'm mistaken, your accounting system probably represents each variant SKU as a separate item -- which rightfully so, more closely resembles your real world inventory situation.

So why do it any different at the cart level? It just introduces new conceptual models for users of systems to learn. If you hire on more employees that go between these systems, you can reduce risk if you streamline the way users view and interact with inventory from one system to another.

So that's the argument for the back-end.

Perhaps more compelling is the argument for the front-end:

You mentioned changing prices. Now, pricing/costing (for profit analysis) is really different than discounting (sales) or promotions (buy 1 get 1 free, etc.). Your pricing really should be handled in your accounting system anyway, since there you have the budget and financial reporting needed to do profit analysis.

But discounts and promotions are really just marketing/merchandising abstractions that are layered on top of product prices. So given all the new and fun tools that are always being innovated to help promote and discount products (ex: X-Cart's Special Offers, AlterCart's Buy Together module, and so on...), the current variant paradigm is limiting.

Example: Say you have blue, white, and red socks, but only the read ones aren't moving. You may want to put them in a discount bin. But, if a user views them, you might still want them to have the choice of selecting another color option.

There's really no end to the possibilities because the variant product uses the same product object in the cart framework as any other product.

[Asiaplay]

Originally Posted by Sativo

Asiaplay,

Sorry, but at this time, the language things is a limitation. I'll let you know if that changes in the future.

Opps... this is a huge issue for your present mod then... as I must admit I found the options & variants workable for a single language using CSV import etc. (real hassles that have caused us to code around it, is when we added a 2nd or several languages - as then it is near impossible to track which variant code matches which product).

Cheers - Asiaplay

[Sativo]

Can you tell me how languages work? I'm just not familiar enough with it.

Do you have to clone each product to the number of languages you plan to support?