Shopping Cart Operations > Existing features
Product Option Pricing Defect or Design Alteration?
Nimitz1061:
--- Quote from: abantecart on August 01, 2012, 09:39:55 PM ---David
Thank you for all the comments. Here is a summary with reply to all your posts in this topic.
- Yes. Manual needs to be updated. We are working on it.
- You are right about "prefix" it has to be renamed. Good catch. We will rename it
--- End quote ---
Actually, renaming may not do it. I'll expand on this below.
--- Quote from: abantecart on August 01, 2012, 09:39:55 PM ---- Regarding Global options. Let me clarify.
Global Attributes set the template that can be used for grouping and unifying option value name. Once added to the product you need to select actual option values based on given product. System can not copy all option values, because this is something that requires specific setting.
Important to notice that it is not required to create global options. You can add new option and values directly in the products.
--- End quote ---
I'm familiar with the concept. This still does not explain why values may be added in global attributes, but never appear in the product option tab when adding global attributes of the selectbox type. If the values can't be copied, why ask for their input in the first place? Does your development team understand the concepts as they apply to a single, unified implementation?
--- Quote from: abantecart on August 01, 2012, 09:39:55 PM ---Global Attributes are begin used across other areas, such as customer, order, product attributes. These are to extend details in other areas across application.
They simply bare responsibility to set a template data that can be used (copied or linked) to other areas.
- For setting up option values with positive (no sign) or negative (-) values. If you put "-" sign in the number it works just fine. Price is adjusted according.
See images attached.
--- End quote ---
I'll grant you that the pricing adjusts accordingly, when the code works. What does not happen is any clear indication in the presentation that the price adjustment IS an adjustment from a base price. This is just silly on two levels. Just doing it this way in the first place. Compare with what happens in a brick and mortar store when you shop. Does Walmart tell you that the blue bicycle costs $25 more than the red one and leave you calculating the price?? Doing it poorly in the second place. Some language in the option block that price is "base price + X" or "base - X" or 'base price' itself would be more clear. Notice also that the drop down select box offers no information about pricing adjustments whatsoever, even when there is one. These are going to become bigger conversion blockers as the number of older users increases, which it has been doing rapidly for several years.
The old +/- prefix setting offered one programmatic approach to addressing this, though I've never seen it addressed as fully as it could be in a stock distribution of any non-commercial cart. Example: The base price could be labeled as a base price with its own prefix. "As low as $xx.xx", "From $x.xx", "Starting at $x.xx" or something similar makes it clear that the parent product price is not fixed. This has legal ramifications for the store owner, and probably should not be left to a template designer.
The single biggest problem I see with this entire system is that it attempts to solve a display issue by working backwards from a form input feature to a set of inventory items, or object elements if you persist in generalizing the system. I have grave doubts about the usefulness of this approach. In practice, it is highly annoying to the store owner, and very time consuming to all involved. My main concern at this time is getting the existing system to work well enough to get this store deployed within the next week or two.
David
abantecart:
--- Quote ---This still does not explain why values may be added in global attributes, but never appear in the product option tab when adding global attributes of the selectbox type. If the values can't be copied, why ask for their input in the first place?
--- End quote ---
Option values are available to be selected once you add global option to the product. User needs to select option value that applies to given product and set other data.
Pretend that we load all option values from global option. There are no details about other information for these values. User needs to populate and delete unneeded values. it is extremely easy to pre-populate values.
Any suggestions to make it UI friendlier are welcome.
--- Quote ---Does Walmart tell you that the blue bicycle costs $25 more than the red one and leave you calculating the price?? Doing it poorly in the second place. Some language in the option block that price is "base price + X" or "base - X" or 'base price' itself would be more clear.
--- End quote ---
I am not sure this is applicable to large retailers. They use SKU based products that will be new product for each variation and later combined to 1 set. I was looking for any large online retailer to see example with option and price modifier and could not find any. If you have link to some, example would be great.
I understand what you say and we will try to put it more clear.
--- Quote ---Notice also that the drop down select box offers no information about pricing adjustments whatsoever, even when there is one.
--- End quote ---
Confirmed bug.
--- Quote ---The old +/- prefix setting offered one programmatic approach to addressing this, though I've never seen it addressed as fully as it could be in a stock distribution of any non-commercial cart. Example: The base price could be labeled as a base price with its own prefix. "As low as $xx.xx", "From $x.xx", "Starting at $x.xx" or something similar makes it clear that the parent product price is not fixed. This has legal ramifications for the store owner, and probably should not be left to a template designer.
--- End quote ---
I propose to have this as a set up:
Price Modifier: -$, +$, -%, +% (this will be as current prefix select box)
What is your take on this?
--- Quote ---The single biggest problem I see with this entire system is that it attempts to solve a display issue by working backwards from a form input feature to a set of inventory items, or object elements if you persist in generalizing the system. I have grave doubts about the usefulness of this approach.
--- End quote ---
I am sorry, but I do not understand your comment. please clarify.
Nimitz1061:
--- Quote from: abantecart on August 02, 2012, 03:49:34 PM ---
--- Quote ---This still does not explain why values may be added in global attributes, but never appear in the product option tab when adding global attributes of the selectbox type. If the values can't be copied, why ask for their input in the first place?
--- End quote ---
Option values are available to be selected once you add global option to the product. User needs to select option value that applies to given product and set other data.
Pretend that we load all option values from global option. There are no details about other information for these values. User needs to populate and delete unneeded values. it is extremely easy to pre-populate values.
Any suggestions to make it UI friendlier are welcome.
--- End quote ---
I think I've already acknowledged that it makes little sense to pre-populate option values from the global attributes. I'm taking it that you are accepting that this is a bug where it occurs and that the behavior will be removed from the cart. I'd agree with this approach.
--- Quote from: abantecart on August 02, 2012, 03:49:34 PM ---
--- Quote ---Does Walmart tell you that the blue bicycle costs $25 more than the red one and leave you calculating the price?? Doing it poorly in the second place. Some language in the option block that price is "base price + X" or "base - X" or 'base price' itself would be more clear.
--- End quote ---
I am not sure this is applicable to large retailers. They use SKU based products that will be new product for each variation and later combined to 1 set. I was looking for any large online retailer to see example with option and price modifier and could not find any. If you have link to some, example would be great.
I understand what you say and we will try to put it more clear.
--- End quote ---
All inventoried products everywhere are sku based. SKU is the Stock Keeping Unit number used in counting products. That you don't find any big box retailers using this approach is confirmation of my point - that this type of approach makes little sense when trying to communicate a clear offer to buyers. Any attempt at clarification will be welcome.
--- Quote from: abantecart on August 02, 2012, 03:49:34 PM ---
--- Quote ---The old +/- prefix setting offered one programmatic approach to addressing this, though I've never seen it addressed as fully as it could be in a stock distribution of any non-commercial cart. Example: The base price could be labeled as a base price with its own prefix. "As low as $xx.xx", "From $x.xx", "Starting at $x.xx" or something similar makes it clear that the parent product price is not fixed. This has legal ramifications for the store owner, and probably should not be left to a template designer.
--- End quote ---
I propose to have this as a set up:
Price Modifier: -$, +$, -%, +% (this will be as current prefix select box)
What is your take on this?
--- End quote ---
I wouldn't do it. There are two aspects to be managed here - the sign of the modifier in the calculation, and the display of it in the catalog. Handling the issue this way tends to create confusion in both aspects. Developers will be tempted to flip the sign of the input based on the sign indicated in the selector. It would be more clear to say "Modify Price By" or "Price Modification Type" rather than just "Price Modifier". In any case, this decision may not need to be made.
--- Quote from: abantecart on August 02, 2012, 03:49:34 PM ---
--- Quote ---The single biggest problem I see with this entire system is that it attempts to solve a display issue by working backwards from a form input feature to a set of inventory items, or object elements if you persist in generalizing the system. I have grave doubts about the usefulness of this approach.
--- End quote ---
I am sorry, but I do not understand your comment. please clarify.
--- End quote ---
I'll try. The global attribute system is basically used to select a form input method (check box, radio button, dropdown, text, text box, etc). The basic approach here is "I have a page, this is what I want it to look like". It switches the store operators mindset towards page display, rather than product offer construction.
Two major problems with this are that the offer construction is the actual make or break process that the store owner has to perform and that this approach splits that process up, asking them to map out the page, BEFORE asking them to map out the offer. Another way to put this is that the application is asking store owners to use page design terms to draft a product offer. This is bad in that few store owners KNOW how to use page design terms. In a brick and mortar environment, no one maps their shelving placement by option or option value. Its done by a number of approaches centered around things like the products department, style and sku.
It may be helpful to start with looking at how global attributes addresses the issue of offerings which:
A. Allow the selection of a quantity (any quantity) of one item from a simple list of selections (as in, do you want red, blue or green pants?).
B. Allow the selection of a quantity of more than one item from a simple list of selections (would you like some red pants, blue pants AND green pants?)
C. Allow the selection of a quantity of one item from a layered list of selections (Would you like your red pants with a 32 inch waist and 38 inch leg length or ??)
As we examine these carefully, you will often find that the logic in defined selection options simply can't or don't match the real world relationships between inventory on hand and a complex product offering.
abantecart:
Thank you for your help and effort to explain this.
I am working on this section now and I think it is all clear what needs to be done. We will be included in version 1.1 (next one).
Navigation
[0] Message Index
[*] Previous page
Go to full version