[ic] various (hopefully interesting) newbie questions

Bob Ramstad interchange-users@interchange.redhat.com
Thu Nov 1 12:44:00 2001


Howdy!  I've been playing around with 4.6.x of Interchange for a while
now, and we're getting ready to install the latest and greatest on
some production hardware and build our first real catalog.

I have a few hopefully interesting questions... My best guess is that
someone out there has already attacked these problems, and I'd love to
know what approach you used, so we hopefully can avoid reinventing the
wheel.  If we can get the architecture right and make good decisions
now, I'm sure it'll really pay off over time.

The questions are pretty varied, so if you don't have any ideas on
one, just read along... you might be able to help with the next one!

We have one unified group of items in inventory, and have a number of
different web stores which sell overlapping sets of items.  For
obvious reasons, we're very interested in only maintaining one
database table of items and referencing that table from each of the
different stores.  Kind of an "in house mall" I guess.

So, could someone give me a concrete example of a good way to share
one item table between multiple stores?  How about a solution which
allows for the possibility of different item pricing per store?

It had also occurred to me that it might be helpful to our customers
to be able to have one unified shopping cart, even though they are
shopping at different sites that we run.  (The sites do reference each
other.)  A unified shopping cart would simplify our fulfillment and
save shipping charges for our customers.  Obviously a single secure
domain would allow for a single checkout process across a group of
domains.  I know that many people have indicated that it's a really
bad idea to use one secure certificate across a group of stores.  That
said, has anyone tried this as a way to unify checkout across multiple
stores?  What are the drawbacks of this scenario?  Any suggestions as
to how to most cleanly accomplish this?

One bit of feedback that I received here was that many folks felt the
single checkout page system in the demo catalog was confusing.  We
would prefer to have a multiple page customer account building system
and a simplified checkout system.  We like the paradigm that we've
seen on the net where each page just takes in a small amount of
information, and the pages are numbered i.e. step 1 of 5 or some such.
Has anyone coded a multi page customer account or multi page check out
process?  I'd absolutely love to see some code.

Finally, my last questions deal with presentation of items.  We
currently use Yahoo! Store and there are some limitations and some
good things about that solution.  One concept that it allows is the
idea of a "nil" item.  This is an item which is orderable but does not
have any detailed information attached to it.  Take a look at:

http://www.condom.com/cal-xpll.html

The main page is an unorderable item "Lifestyles Xtra Pleasure" with
caption and large picture but no price.  It references three orderable
items of varying quantities each with different prices.

Obviously in Interchange we could simply select an option for the
quantity and set different prices... but we kind of like the current
situation where the customer can see all the options up front without
pulling anything down.

I guess more generally, the Yahoo! Store system treats section,
subsection, item and nil pages all the same way.  If it has a price
and is orderable, an "Add to Cart" button appears.  If it does not
have a price or is not orderable, the item cannot be purchased.  If
there are "contents" they are rendered at the bottom of the page.

Has anyone done anything similar with Interchange?  Are there any
obvious workarounds which would get me similar behavior without too
much effort?

I don't necessarily like the Yahoo! method, but initially we're going
to be loading Interchange with data from Yahoo! and it would really be
a boost to morale -- and good for our customers -- if we could start
out with something that behaved mostly like our current solution.

Special thanks to anyone and everyone who has gotten to this point in
the message... All of your help is VERY appreciated!

-- Bob