A Simple Catalog - Four Flexible Screens

I often break my e-commerce applications into three core e-commerce "features"- a catalog, a cart and a checkout system. The catalog is responsible for displaying products and can be used on its own for non-commerce projects or projects with third party "buy" buttons. The cart allows a user to create a list of products – whether for purchasing, future reference, or for printing out as a "pick list" (perhaps along with a coupon) for in-store purchases, and the checkout handles everything from B2B purchase orders to Paypal, COD and credit card orders – including optional shipping, discounting and online gift certificates.

The simplest comprehensive model I've been able to come up with for a catalog is four screens: category detail, product detail, search product list and cross sell product list . . .

Category Detail
Some catalogs only use this screen, if they don't need search or cross sell and don't have product detail pages (such as some industrial catalogs with thousands of products and nothing more than a price, SKU and 35 character name for each from the mainframe – not much use in having a product detail page for that!).

In the model I use, a category detail screen displays the information for the current category, a list of any sub categories and then either a list of products in the category or in the category and subcategories depending on business rules.

If you set the display up right, this looks equally good for categories that only have products (no sub categories), categories that only have sub categories (no products) and categories that have both. By using an n-level category tree (with a simple recursive CategoryID and CategoryParentID) you can have as many level of sub categories as you want, and in your model you can implement special case rules for "latest products" or "all products" or "most popular" or other dynamic categories which can then be treated on the display side in the same way as any other kind of category page.

By using request specific logic you can use different category detail, category list and/or product list templates for different categories (or users or skins or whatever) and if you have a decent "base list display" you can easily implement filtering, paging and ordering by attribute for the product lists (and even if you wanted for the category lists). A little metadata configuration and some HTML/CSS from a talented designer and it's a very quick way to implement a product catalog with almost unlimited flexibility.

Product Detail
There are typically two reasons to add a product detail screen to a catalog.

• Your product has too much information to display in the product list on the category detail screen (such as a large image, a detailed description or a bunch of parameters or links to anything from user guides to MSDS sheets).
• Your product is purchasable and has too many attributes to display on the product list screen (even if you just have a name and price, if you need to select color, format, material, size, weight and style from drop downs it may be hard to display all of that for each product in a product list).

Some people also create product detail screens as landing/link pages for search engine or usability purposes, but this tends to only be useful if there is enough information about the product to require the product detail page anyway. The product detail page typically just displays some subset of the product attributes and provides for a way to "add to cart", "add to list" or "buy" if appropriate.

The only real "gotcha" I come across is handling any kind of "back" button. Typically, I keep track of how a user got to the product detail page by passing the appropriate URL variables to the product detail screen. If they came from a category, the back button takes them back to that category (as a product could be associated to multiple categories). If they came from a search I currently use a javascript back as I don't yet have good persistence of advanced search parameters in my framework (it's on the list!). If they came in cold (not from search or category page), I typically put in a back button to take them to the catalog home page. Sometimes I also implement "back to page" functionality if my clients want to create links from pages they manage, and usually I offer different captions for the back button depending on the type of "back" being implemented.

Search Product List
The search product list typically uses the same product list(s) used by the category detail screen (although that is not a requirement – it's just a configuration setting). It prefaces this with a search box and a link to an advanced search. There are a lot of possibilities for improving this with "common searches" and a bunch of other features, but I said I'm refactoring a simple catalog in a couple of days, so I'll add the cool stuff next time round!

Cross Sell Product List
The one other screen I often include in a simple catalog is a cross sell list. Basically it is another product list (often using a different list control to the category detail and search product list but sometimes using the same underlying product view HTML). Typically it won't include filtering, paging or ordering as the purpose is typically to display 3-8 cross sells and sometimes it uses a more abbreviated product display template to fit more cross sells onto the page. As with all screens this is designed to play well with other screens so it can be displayed below the cart, to the right of a product detail page in a sidebar, on the home page or anywhere else cross sells might be useful from a business perspective. The screen can be used as a “would you also like” screen on the way to the cart, but I’m not a big fan of that approach any more (a little too intrusive, I feel).