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?
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.
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.
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.
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.
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.
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.
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?
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.
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.
I am sorry, but I do not understand your comment. please clarify.
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.
