ASP 101 - Active Server Pages 101 - Web01
The Place ASP Developers Go!

Please visit our partners

Windows Technology Windows Technology
15 Seconds
ASP 101
ASP Wire
VB Forums
VB Wire
internet.commerce internet.commerce
Partners & Affiliates

ASP 101 is an site
ASP 101 is an site
Internet News
Small Business
Personal Technology

Corporate Info
Tech Jobs
E-mail Offers

ASP 101 News Flash ASP 101 News Flash

 Top ASP 101 Stories Top ASP 101 Stories
Migrating to ASP.NET
Getting Scripts to Run on a Schedule
The Top 10 ASP Links @

Sortable Date Format
Show All Tips >>
ASP 101 RSS Feed ASP 101 Updates


Anatomy of an Online Store

Every time we enter into a real-life store, we immediately recognize certain familiar elements, such as the aisles (or whatever is used to show the products), the cashier, the store's personnel, and so on. The ability to identify these constituents of the store is so automatic for us that we don't even pay attention to it anymore. For example, I have a shirt that looks exactly like the one that the employees of a popular furniture store chain wear while at work. Incidentally, that shirt is also one of my favorites; so there's a good chance that, whenever I go there to see for, say, a new desk, I'll be wearing that shirt, too.

Now, my shirt looks similar to the one worn by the employees, but it is not by any means the same: mine has no logo-of course-and the pattern is slightly different. Nonetheless, every time I go there with my favorite shirt I am continually harassed by customers asking me how much that beautiful sofa costs. People don't stop to consider that, although the shirt I wear looks similar to the one the employees have on, it is by no means identical. They simply direct their attention to what looks familiar and go for it.

In an online store, as we have seen in the previous chapter, the problem is not so much in showing the elements, but in doing so the proper way. After all, we were able to adapt just about any model that we could think of to the basic concepts of store, shopper, shopping cart, and so on. This means that they must be there, even if we don't see them or if they are presented to us under a disguise.

In this chapter, we will examine the fundamental structure of an online store, both for business-to-consumer and business-to-business applications. We will also pay a visit to the sample stores that are shipped together with SSCE and look at the kind of functionality that they offer.Finally, we will take a look at the store creation tools that are part of MSCS, how they work and what the basic architecture of a newly born site is.

In order to be able to see the sample stores on your server, you will have to make sure that they have been installed during the setup of Site Server. If they haven't, simply launch setup again and install them.

Here's a preview of this chapter's content:

  • Architecture of a business-to-consumer site
    This section will describe how a business-to-consumer site works from an architectural point of view. We will also follow the site's structure with online examples that are taken from the basic Site Server-created store. To demonstrate more realistic implementations, we will then take a look at the sample stores that are provided by MSCS.
  • Architecture of a business-to-business site
    Similarly to the previous one, this section will focus on the structure of a business-to-business site. We will examine a typical store and point out how it differs from a business-to-consumer site. Once again, we will take a look at Microsoft Market, the only business-to-business sample store that is offered by MSCS.
  • Store creation tools
    Finally, the last part of the chapter will be dedicated to learning how the two wizards that are provided by MSCS can facilitate the creation of a new store. We will also take a look at the basic structure of a newly created store.

Architecture of a Business-to-Consumer Store

A plain online store-one that only provides the functionality that is strictly needed to make a purchase-can be divided into three different areas. The store browsing part corresponds to walking around in the aisles of a store with your shopping cart and choosing the products you want to buy.

For customers who are really interested in something but can't find it by just browsing through the available products (something that happens all-too-often in real life and can only get worse in an online store with thousands of products), the search functionality makes it possible to find just about anything without going crazy. This corresponds to asking a store clerk where a product is located in a normal store, with the difference that (a) a good online search system will know of all products (try that with a clerk) and will (b) actually show the customer all the products that match his or her description in the same place, rather than directing him or her to the various aisles.

Finally, all sections converge into the shopping cart, sometimes called the shopping basket, which contains all the products that the user wants to buy. From the basket, they can proceed to the order processing section of the site, which guides them through all the steps necessary to complete their purchases, computes all the costs and performs all the operations needed to pass the order on to the line-of-business system.

The Home Page

The entry point of an online store is, usually, the home page. The reason why I'm using the term usually is that this might not always be the case: for example, if you're entering the store following the URL provided by an online ad for a special offer, you may be taken to an introductory page first.

As you can see from the following screenshot, the home page generally contains some information about the nature of the store (although more information is usually provided in a separate section, which is not strictly needed to purchase something) and, often, provides direct links to products that are on special offer. Everything that you see in an online store should be done with the goal of increasing the possibility that a customer makes a purchase; as such, the home page often contains direct links to products that are on sale, information about special offers, and so on.

For consistency, every store should contain certain recurring elements that appear as part of every page-no exclusions allowed-and occupy always the same spot. These elements have two main aims: first, they represent the fingerprint of the store and make it easier for the users to remember where they are; second, these elements provide navigational elements that are useful throughout the entire shopping experience. In the previous screenshot, they are on the left side and provide links to the main sections of the site: the site information section, the home page (called 'Lobby' here in respect of the store's metaphor), the search section, the shopping cart, and the purchase process ('Pay').

In our case, the body of the home page contains links to various departments (our aisles), and, although this is not always the case, on many sites departments are often part of the navigational elements common to every page. Here, each department link is our main door into the store browsing section.

The Department Page

The screenshot that follows shows what you see when you click on a department. As you can see, the first step into store browsing is usually a list of products that belong to a given department. Each list entry provides a link to a page that offers more information about a specific product, as we will see in a moment. In addition, a brief description of the department itself (usually together with a brief portrait of the products it contains) is given as well.

Again, a more evolved store than ours might want to maximize the potential of this page, which will probably register most of the impressions after the home page, and display more focused information, like the department's specials or best sellers. The list of products, in that case, will be displayed as a secondary step into the navigation.

This approach to shopping, which is the most common in a real-life store, has a significant handicap in the online world. As you can see from the picture, the entry for each product is pretty anonymous-you can only see the product's name. No picture, not even a price. Once again, more evolved stores do offer additional data, like a price and, sometimes, a small picture. The problem is that the store can't really offer more than that because the download times for the page would dilate significantly, since several different products are displayed in it.

In addition, an online store often offers a variety of products that a normal store, for stocking reasons, cannot provide. As a result, a department might be made of hundreds, or even thousands, of individual products. Showing all these products in a single list is impractical-that would mean a lot of bandwidth usage both on the store's and the user's end-and having to browse through many pages of dull product entries is a time-consuming experience. This is especially true if the user doesn't know where the product he or she is looking for is in the list-sometimes, albeit not always, products are sorted in alphabetical order, and the only navigation possibility offered is a link to the next page and a link to the previous one. Now, if the department contains ten thousand products and the one the user is looking for begins with the letter Z, an arbitrary number of pages further on, then you can be certain that the user will go somewhere else. Other sorting options, such as by price and by availability, can be chosen as well, and in some cases they will offer a better approach to listing the products in your store. In general, however, you should also provide some sort of search functionality to help the user.

The Product

Clicking on a product entry in the listing provided by the department page will cause more information about that specific product to be displayed. As you can see from the next screenshot, this page provides much more detail about the product than the previous one: there is plenty of space for a good picture, a detailed description and pricing information. If the product is on sale, or part of a special promotion, this would be the right place to let the user know about that too.

Looking at this page, you can probably imagine how inconvenient it can be for the user to access information about many products in this way. Therefore, when designing an online store, much care should be taken in making the navigation system as flexible and powerful as possible, to guide the users to the correct products without annoying them.

This is also the very first page where we see an Add to basket link. As I'm sure you have already figured out, clicking on this link causes the product to be added to the user's basket (whose page we'll see later on). Usually, the product is added with a quantity of one item, but this may vary according to what the store sells (if you're into groceries, for example, and sell something by the gram, then maybe you'll want to add a minimum quantity of 500g).

In a more realistic store, the Add to Basket link will be all over the place-main page, department page, special offers page, and so on-because the store designer will have wanted to facilitate the act of adding products to the basket to the maximum extent possible. Maybe it's not so evident by looking at the generic store that we see here, but let's assume that you had found a product you really like in the listing. If you know the product well, then it's annoying to have to view one additional page to be able to add it to the basket!

The product page concludes the navigation section of the site. As you can see, even in this simple store of ours, the navigation is very streamlined, and the user doesn't need more than three clicks to add something to the basket. This is a very important particularly because, once again, you want to keep the store as straightforward as possible for your users.

The Search Functionality

In the previous paragraphs, we have mentioned how department browsing is really not the preferred method for finding a product in an online store. As a matter of fact, statistics show us that most people who buy online have a good idea of what they want even before they enter the store.

As a result, when a user enters an online store, most often he or she will want to find something using some focused search tool, rather than having to guess where that product might be in the store. The search functionality offered by the store, then, arguably becomes its single most important aspect (besides actually having what the user is looking for and being up and running).

If we click on the Find link provided by the site navigation of our store, we'll end up in a page similar to the one shown in the next screenshot. As you can see, our search functionality is extremely simple-all the user has to do is type in some text and click on Find. The search results (in the second screeshot) are somewhat similar to a department listing page, and the links to the individual products point, once again, to the product page that we just saw a moment ago.

Many online stores offer the basic functionality that our store provides as part of the navigation elements that are common to all pages. This means that, from any page in the store, the user can just type in what he or she is looking for and click on a Find button to launch a'quick search' against the site's product database. Obviously, tools like natural language search-that allow the user to type in questions in plain English (or any other language that the store supports) and find what he or she is looking for-are extremely useful in this context, even though most stores only provide simple keyword search on the database's contents.

Characteristic of more and more online stores is an Advanced Search, which makes it possible for the user to specify targeting parameters with greater detail than the quick search. For example, in a music store, the advanced search functionality might allow the user to specify price range, title keywords, producers/publishers, format (CD or tape), and so on. The result is a much more focused search, usually producing results that better reflect what the user was looking for.

From a technical point of view, it's important to understand that there really isn't any huge difference between performing a search and browsing the catalogue. In most instances (excluding the natural language search that we mentioned above), both actions will result in a query being executed against the database and the same result set being shown to the user.

The Basket

Whenever the user decides that he or she wants to buy something, the product ends up in his or her basket. As we saw in the previous chapter, the basket is more similar to a shopping list than to a shopping basket, in that the products it includes are not really 'taken off the shelves ' until the order is processed.

The next screenshot shows the basket page of our bare-bones online store. Notice how certain information is displayed about each product: the name, the per-item list price, the actual cost (after applying discounts), the quantity and the total price that the user will be paying (excluding taxes, shipping and handling). To be honest, our store has nothing to add in this case, because the information that is displayed is exactly what's needed-there would be no point in including a picture of the product or its description here, since the user has already expressed the intention of buying it.

Naturally, this model doesn't necessarily apply to any store. A site whose products are very visual, like a clothing store, for example, might need to include a picture or a better description so that the user knows exactly what he or she is going to buy. This is particularly true in those cases in which a single product can be purchased in many variants (i.e. a shirt can have different colors and sizes).

It's important that certain tools be provided to the user as part of the basket page. First of all, the user must be able to change the quantity of a product that he or she is buying (hopefully to increment it), and be able to proceed quickly to the order processing phase. In our case, the quantity of an item is stored in an edit box, which means that the user can change it at any time. If we had more than one item in the basket, naturally the user would be able to change the quantity of as many items as needed and then click on the Update Basket button to commit the changes. Moving on to the order processing stage is equally simple-all the user has to do is click on the Purchase button.

As you have probably already guessed, setting an item 's quantity to zero and clicking on Update Basket causes that item to disappear from the basket. If you have several items in your basket, however, this deletion method can be awkward-the fact that you don't want your users to delete items is understandable, but this might be a little too obvious-and therefore the store provides an Empty Basket button that does the job of clearing up the basket 's contents.

The Purchase Process

A decision has been made by the user: I want to buy! Now what? Well, there are a few things that you must still ask the user before you can be sure that (a) you'll be able to send him or her the merchandise (whatever that is) and (b) he or she will be able to pay for it. The procedure of asking for the necessary information and evaluating it is called the purchase process, or sometimes the check-out process.


The first thing you will want to know is who the recipient of the merchandise is. In a physical goods delivery store, this is an important step because the ship-to location will most likely influence the total cost of the order, and in certain cases (e.g. if you're selling regulated encryption software) will determine whether you can ship the merchandise at all.

The next screenshot shows our shipping page. As you can see, there is a strange-looking box in the middle of the page, instead of the more familiar form fields that one would expect. That's the Microsoft Wallet, whose task is safely storing the user's data on his or her computer and then releasing it, upon authorization from the user, of course, whenever a site needs it. Its goal is to improve the shopping experience by facilitating the exchange of data between the user and the site.

The Wallet also provides storage for the user's credit card information (remember, all the data is stored in encrypted format on the user's local machine and released only if the user decides to by typing in a password that is not sent to the site), and features a COM-based interface that can be extended to include private-label cards, debit-cards, and so on.

For more information on the Wallet you can refer to Appendix B; for the moment, take note of the fact that it exists and that it is obviously a browser plug-in. This means that (a) not all the browsers will be able to support it and that (b) in most cases the users will have to download it from either your site or Microsoft's. Since you want the store to be accessible to as wide an audience as possible, you will also provide the appropriate means for your users to avoid using it. In our case, this is done by clicking on the Click here if you have problems with the Wallet link, which brings the user to an alternate shipping page that uses standard HTML forms (see the next screenshot). The same page is also shown if the browser does not support the Wallet at all.

The data that is asked for during the shipping phase is pretty straightforward. With a little hands-on experience, however, you will find that the Wallet asks for more information than the HTML forms. In particular, the latter doesn't require the user to type in an e-mail address. Now this is understandable, because the recipient, who is not necessarily the person who is placing the order, might even not have Internet access at all. However, e-mail is arguably the cheapest and best way to get in touch with a person, therefore it is a good idea for an online store to be asking for it, too.

Clicking on the Total button will cause the system to verify the information that the user has typed in and, if it doesn't find any problems with it, it stores it in its internal database.


The next page in line is there to ask the user about how he or she intends to pay for the purchase. The screenshot shows us the billing screen from our store. As you can see, a complete order detail is presented to the user again; there are two reasons why this happens.

First of all, the store is now able to calculate the final cost of the order, including shipping, handling and tax fees. This wasn't possible before, as we didn't know where we were going to ship the merchandise and, therefore, were unable to calculate all the fees correctly. Second, the user is now going to officially approve and authorize the purchase, therefore it is important that he or she be able to see what the costs are going to be, particularly from a legal standpoint.

Once again, there is a box on the page, and this time it's got a huge Visa logo on it. As you probably have already figured out, this is just another manifestation of the Wallet, which this time can be used to send over pre-stored payment information. As was the case for the shipping page, here we have a link that allows us to use a standard HTML form rather than the Wallet. As you can see from the next screenshot, the page asks for the usual credit card information. If you go back and forth from the shipping to the billing page, you will notice that any text that you store in the credit card information box is not retained by the store and doesn't appear when you go back to the billing page. This behavior is by design, because it is possible that the same computer be used by two different people and keeping this kind of data might prove to be disastrous. We'll talk more about tracking users later on in the chapter.

Using the Wallet

For the moment we'll focus on the Wallet's interface with the user. As you can see, the Wallet initially contains no data. This means, of course, that it's not possible to use it for completing a purchase unless some information is stored in it.

To do so, the user clicks on Add Address� (or Add card� from the billing page), causing the Wallet to display a dialogue box similar to the one shown in the next screenshot. Once all the data has been filled out, the user can click on OK to save it in the Wallet's internal storage system.It is worth noting again that any data entered in the Wallet is stored on the local computer in encrypted format. The user is also asked for a password whenever this information needs to be released, and the password is never sent over to the requesting site. This offers a good degree of security for your personal information.

Installing the Wallet

Let's talk for a moment about how the Wallet is installed-this is particularly important if you consider that most of your users might well not have it installed when they first visit the site.

First of all, Microsoft provides two versions of the Wallet, one for Internet Explorer and the other for Netscape Navigator. In both cases, however, the amount of data to download is pretty high, resulting in a wait time of several minutes on a typical modem connection.

As a result, those users who do not already have the Wallet (it comes as an option even in IE4 and IE5) will not really want to wait for their browsers to download it and install it on their computer. The problem here is that IE, contrary to Netscape, will automatically start downloading the plug-in without any manual intervention, and this might be confusing for your users, who will not easily realize what's going on.

In consideration of all these issues, I recommend that you include the Wallet as a second-choice option for your customers, and offer the HTML forms as default, essentially inverting the scenario that we just went through. This way, you will be sure that all your users are able to complete a purchase without any problem, while those who want to take advantage of the Wallet's advanced features will be able to do so by clicking on the appropriate link.

The Confirmation Page

When the user clicks on the Purchase button from the billing page, the store proceeds with the final processing of the purchase. This includes making sure that all the information entered is correct and compatible with the operating parameters of the store, that the merchandise requested is available for delivery, and that the payment information is correct from all points of view. Larger online stores also pass the payment data through a credit card processor to make sure that the data provided by the user is correct, but this involves the purchase of (often) expensive verification software that not all site owners can afford. As a result, most small to medium stores still process credit cards manually, and the user's order is accepted without really verifying that he or she has the buying power needed to complete it.

In any case, once the purchase is approved, the user is redirected to a confirmation page, similar to the one in the next screenshot. The goal of this page is to tell the user that his or her purchase went through successfully, and to provide a reference number (or Order ID) that can be used to reference the order in the future. This number becomes particularly useful whenever a communication of any kind must take place between the store and the customer concerning the purchase; in that case, understanding what the conversation refers to will be much easier.

Unfortunately, as you can see, the order IDs that MSCS provides are way too long for any practical use. As a matter of fact, asking a customer to remember-or even write down-such a long sequence of letters and numbers means almost certainly that you will be in trouble sooner or later, when your users start calling in for questions or complaints and your attempts to find their orders only add to their frustration. The reason why MSCS uses such a long number is that it generates a GUID (Globally Unique IDentifier)-a 128-bit number that is likely to be unique among all the machines in the world-and uses that to uniquely identify each order.

This ensures that, no matter what database system is used in the backend, each order will be assigned a unique number. The same, however, can be achieved, if you are using a SQL Server, by implementing a self-incrementing primary key integer field that starts from any number (usually 100, so that your customers don't think your store is that new to the scene) and automatically updates itself every time a new order is added to the appropriate table. This way, the order IDs will have a shorter length (it will take a lot of purchases before you'll even reach six digits!) and it will be easier both for you and your customers to track them.

©1999 Wrox Press Limited, US and UK.
Home |  News |  Samples |  Articles |  Lessons |  Resources |  Forum |  Links |  Search |  Feedback

The Network for Technology Professionals



Legal Notices, Licensing, Permissions, Privacy Policy.
Advertise | Newsletters | E-mail Offers