I designed this article to address a problem I have encountered working with business owners who sell products. This article is Number 5 in the Knowledge base but I've put it here because it's that important.

(Click on the magnifying glass images as you go to view the diagrams)

One of the problems I have in getting my clients into e-commerce is the inability to classify their products. I find it to be common that small businessmen know their products extremely well, but cannot decisively categorize them. Ironically, they have such intimate knowledge of their product, they have never thought about organizing their product in a way that someone can find their products without assistance. The purpose of this article is to give Product Businesses some insight into organizing their products for e-commerce, especially how this relates to database organization. Even if you already developed a database or table for your products, this article will be helpful.

Here's the dilemma: business owners want to allow the client the ability to search for a product themselves, yet are worried they are going to miss something they want. On the one hand we are attempting to provide a specific product for a client who we assume knows what they want. On the other hand we are assuming 1) that either the client (OR WE) DON'T know what they want or 2) we might fail to present him with a compatible product, so we attempt to provide him/her with everything that might be what he wants. The paradox never occurs to most business owners, namely that attempting to give the client every choice is counterproductive to finding what they want; if I organize my site to flood the client with everything that they could possibly want, the odds of them finding any one thing they want actually decreases.

On the web, the first objective of a site is to introduce and engage, then to direct. If the customer does not know what he or she wants, you must give them some indication, visually, of what your product is. Here is where the dilemma begins. Let's suppose you as a wholesale dealer have a 250-product line. You store info about your products in a database table called ProductLine. 250 items is too much for a single web page or even three or four web pages. Therefore, you need to break your products down into categories. My goal as a developer is simple-engage your client and have him be 3 clicks away, at most, from viewing a product they will purchase.

Let's suppose that you can logically break your products down into 5 groups of 50 products each (simple, also wishful thinking, but good for here). Let's also suppose that your products each have a name, a picture, a product number, a price, and a description. That's five pieces of information (fields) per product in the database, or 1250 fields total. Now, we'll need to add a 6th field (column) called CATEGORY to these five columns, and we'll enter Category 1, Category 2, etc., in it. We have created 5 links on the left hand side of your site that name these categories.

This is all well and good, but we have some programming to do. First, we need to create the links on the left of the web page dynamically, because you could close out all of your 'Category 5' products, or you could open a new product line thus having 6 categories. Without boring you with code, here is what I use to "tell" the database to fork over the names of the categories:

Select distinct Categories from Products

Now, 50 products are still too many to display on a page, so in the page itself we need to break down the 50 products that result for any of the 5 categories. Let's go for absurdity and assume that each group of 50 breaks down into 5 groups of 10 similar products.

So now we are going to need a new column in the database table, called SubCategories. By the way, that means we have another 250 fields in our 250-product database, or 1500 fields total.

To make the rest of this understandable, let's assume you sell furniture. Instead of "Category 1" we'll call it tables. But of your tables you sell 5 different types of tables: Maple, Walnut, Oak, Pine, and Birch (with 10 of each type).

When the user clicks on the link to the left called "Tables," a page is requested and my programming language looks about like this:

Select distinct subcategory from ProductLine where category = 'Table'

So the server goes through the database and finds five different distinct types of Tables: Maple, Walnut, Oak, Pine, and Birch, and lists them on the center of the page as links.

So, the user is one click into the program, and has found tables, AND he has a choice of tables. Great. He knows what types of tables you have, but as importantly for him he also knows what you DON'T have. You don't have any cherry tables. You may have cherry dinette sets, but since you didn't list those with Tables, you are getting this sinking feeling in the pit of your stomach because perhaps he wanted to purchase a table of ANY type as long as it was cherry wood. Sorry to upset you, but let's get back to the programming because I need to take you to the end of the process. (I promise I'll address this issue later.)

Now the client sees Categories to the left and SUB-Categories on the right. He can even see a sample table from each category. And he can see how many tables are in each sub-category (10 each). One more click on Oak and he has a list in front of him showing 10 tables. That's only two clicks, which is great, but sometimes in real life there will be 48 Oak tables and 2 Maple tables. 48 Oak tables is too many to load onto a single web page, so you need to have an additional set of buttons representing pages with, say, 8 Oak tables per page. But since we have the image, we can present a "thumbnail" (small picture) next to each table, so the user can get a rough idea of what the table looks like. The client clicks on one he likes, and hopefully buys. Objective successfully met: client has been engaged and directed from 250 products down to 1 product he is willing to buy.

A Review and Application; Problems and Limitations

It is important to emphasize that there are limitations to this system, which you must consider if you have a varied product line.

First and most important of all, you must accept the fact that when you "break down" a list by categories within one column, you are by definition separating some products from others. From your perspective, the only justification for doing this is because you cannot show all of your products on a single page. You would prefer to do that; that would make the client zero clicks from a purchase, AND your database would have less columns-since storage and maintenance of a database and columns costs money.

From the programmer's perspective, you have a column (in this case called Category), and some products are defined as Table and others are defined as Dinettes. The server has no way of knowing that Dinettes and Tables have some relationship to each other; it simply splits them up, and if the client doesn't select both, he may miss something. As a programmer, this adds time and expense to my work because I have to come up with a special rule for tables and dinettes so that they relate to each other. And if you add a new product line of Category 'Coffee tables,' my programming might get confused.

Also with this system we designed, the links on the left make no assumption about the number of SUB-categories within each category. Since most of your five categories have 50 items, I have set the programming to show the SUB-categories, not the individual items once a link on the left is clicked. If you added a 251st product, a new category named Persian Rug, and only had one, there will be SIX links to the left when the server queries the database; clicking on this link will just produce a thumbnail and not a full picture, so ALL items in your site are three clicks away. The only way to change this is to have programming that takes into consideration the number of products in any category in deciding how to lay out the products on the right.

Another point is that the categories and subcategories must be DESCRIPTIVE, or the user will not connect what he or she wants with the list of links you are providing. However (and there's always a however), links that are overly long will most likely be ignored as being too busy or wordy.