Leon,
I am indeed to a certain extent duplicating the existing system, purposely
in order to preserve some measure of compatability with future Freetrade
developments and because I can see areas where it has merit. Want to have my
cake and eat it too.
In the current structure the shirt manufacturer who modifies the color1
attribute makes a global modification which affects all skus using the
color1 attribute. While in some instances this might be desirable, in others
it would be disasterous - especially since this happens without advising the
administrator of the consequences. I suggest that an alternate mechanism
should be provided, or the current mechanism modified.
I have provided for a measure of global level control by allowing the admin
to create option templates. These templates can be used as the basis for
creating item-level option lists. ie when creating option lists the admin is
presented with a list of templates which he can use and modify, or he can
create new lists. I therefore now have two co-existing mechanisms -
attributes which are global in scope, and options which are specific to the
current item. These could easilly be combined using a flag for scope, but I
havn't done so for compatability reasons. Besides I've only added 4 tables
and 6 screens - hardly a huge overhead.
The list of attributes that appears on each sku can indeed be quite long. On
the smallish (200 item) site I'm working on now there would be at least 20
(multiple color lists, sizes, legnths, etc..). Managing attributes at the
item/sku level simplifies the screens for the administrator, with less
chance for confusion.
I'm still left with my initial question (my fault for the long preamble). In
real life each color/size/whatever combination is a separate sku. This could
be accomadated by allowing the admin to create a base sku, then duplicating
it, assigning a new sku# and selecting the unique combination of attributes
for that sku. This would be presented to the web user using Javascript
arrays to build the co-dependant select dropdowns.
Is this reliance on Javascript suicidal in the real world? How many users
have Javascript disabled? Is it reasonable to insist that Javascript be
enabled in order to use the site?
The only alternative I can see is to build a post-processor that converts
base-sku-attribute combinations into final sku's for order-entry and
inventory tracking. This could also be used as a fall-back when the user has
Javascript disabled.
This may all seem like nit-picking, but once you look at maintaining on-line
inventories and integration with off-line order processing systems these all
become serious issues.
Earl Wyllie
[EMAIL PROTECTED]
>> The current implementation of attributes and variations seems to
>> lend itself
>> more to programming flags than actual item attributes. For
>> example this is a
>> great mechanism for implementing flags for items on special, high profile
>> items to display on department pages etc. The scope is global
>> rather than at
>> the individual item level.
>> In order to implement variations such as color or size , which are item
>> specific and selected at the sku level, I added tables for options (you
>> hogged all the good terms). They are created and managed at the
>> item level(I
>> did provide for global templates), included or excluded for display at the
>> sku level.
>> I choose to implement options as suffixes to the base sku (sm,
>> med,lg..etc.)
>> rather than have each color/size combination generate a unique sku. This
>> will cause problems for inventory tracking and a few other areas.
>> The proper
>> way would be using Javascript arrays to generate co-dependant select boxes
>> and the final sku based on the user's selections, much the way
>> Leon's store
>> selector at Restoration Hardware works.
>> I am reluctant to use Javascript for something as critical as product
>> selection and would appreciate any comments from those with more practical
>> experiance.
>
> Earl,
>
> I really think you're duplicating the system that's already there. Yes,
> it's true that one type of shirt may come in one set of colors, and other
> type in its own set of colors... so, you can either deal with all the
> possible colors being in one attribute, or you can make two
> attributes...like shirt1_color and shirt2_color. When someone buys
> something, these attributes are saved with the line item. Check out the
> chair in subdepartment A on the demo site.
> <http://www.working-dogs.com/freetrade/demo/htdocs/index.php3?SCREEN=item&it
> em=2>
>
> For a big hetrogenous store, it would be nice if the giant list of all
> attributes didn't show up for all SKUs, perhaps. On the other hand, it's
> makes managing the attributes more difficult.
>
> I think the issue you may be getting at is that a red shirt may come in
> small and medium, but not large. And a blue shirt might come in medium and
> large. If you create one sku for the shirt and click off red/blue and
> s/m/l, you can get people buying stuff that doesn't actually exist. MS site
> server handles this by giving the user an error message! With FreeTrade, I
> suggest making two SKUs, one for the red shirt and one for the blue shirt.
> Then you just click off the sizes that apply. If there's three variables,
> it's starts to get crowded...but we haven't encountered that situation yet.
> Has anyone else?
>
> I feel fairly strongly that the existing system can handle almost any set-up
> you can imagine, but sometimes it takes talking to me because I understand
> it better than anyone else.
>
> Leon
>
> ------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Site: http://www.working-dogs.com/freetrade/
> Problems?: [EMAIL PROTECTED]
>
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Site: http://www.working-dogs.com/freetrade/
Problems?: [EMAIL PROTECTED]
