In the previous chapter, we mentioned how it should be possible to manage an online store through a web browser. This is a good idea, if you consider that you will have to create all the logic needed to run the entire site anyway, and you will most likely be able to recycle a good part of it if you decide to create a management interface for the store.
The creators of MSCS must have believed that this was a good idea too, since a store created with the software provides an interface that makes it possible to handle all the management functions entirely online. Access to the interface should only be granted to authorized users-usually people whose task is managing the store-and nobody else. If your store manager isn't protected, it doesn':t matter how far you will have gone to secure your data, because just about anybody will have access to it anyway!
We can divide the Store Manager interface into four different areas:
Functions that are provided within this section can be used to access and modify the product database. This includes changing actual product data and the way products are organized in departments.
From this section, it is possible to examine and work with the orders as they are received by the store. This includes viewing orders, authorizing their shipment, and so on.
Being able to offer cross-selling, up-selling and special deals is a very important aspect of doing business online. This kind of functionality is usually grouped in the Marketing section of the Store Manager.
Finally, let's not forget that the web site is, essentially, a software product. As such, there are certain tasks that it must be possible to perform, like opening and closing the store, or configuring the purchase process. We'll consider all these operations as part of the System section.
The Home Page
As for the storefront the main point of entry for the Site Manager is its home page, shown in the adjacent screenshot. As you can see, Marketing and Merchandising functions are grouped together-mainly because there is not much marketing functionality in general, since the only supported function is creating and managing promotions.
Now, there is one main problem with this page, and it's that everybody has access to everything. As a matter of fact, once you've made your way through the Manager, you will be able to access all the functionality, regardless of whether you are the CEO or the guy who works in the warehouse. This can be a risky proposition, if you consider that some store owners will not want just about anybody in their organization to have access to certain data-and having access to information you're not supposed to see means that sooner or later somebody will make a mistake where he or she wasn't even supposed to look into.
You will notice how the layout of the main page-whose spirit is more or less maintained throughout the management site-is extremely slim: the pictures are few and very small, and there is little explanatory text. Although this might have been said of the storefront as well, in this case it is so by design. In fact, you will want the Manager to be as efficient as possible, rather than 'good-looking', because its use is limited to a restricted number of busy people who belong to your organization. This doesn't mean, however, that the management portion of a site should not be designed to be user-friendly and easy to use-just that the appearance will not be as important as the functionality it offers.
As you can see from the previous screenshot our store provides two merchandising functions: access to the product database and access to the department database.
The Department Database
Clicking on the Departments button will take us to a page similar to the one shown in the next screenshot. The layout of this page is slightly different from the home page: a header and a footer containing the same information are provided as part of the page. The reason why they provide the same information is that you might be forced by the length of the page itself to hide either one outside your browser's viewable window, and therefore you'll be able to use the other to jump from one section of the site to the other.
The rest of the page shows an interface that we'll find replicated across the entire site (as a matter of fact, many pages are shared by different functions within the Manager). The first link allows us to add a new department; by clicking on it, we'll be taken to the page shown in the following screenshot, which asks us a for a department ID (unique to the store and used to identify the department in the database), a name and a description. The name and description will be used in the storefront pages.
Editing departments is equally easy-all we need to do is click on a name and edit the data. You will notice that we are not allowed to change the department ID in the editing page; this is because that number is used as the primary key in the department table and therefore cannot be changed, otherwise the system won't be able to recognize the correct record for that department.
The Product Database
The product interface shown in the next two screenshots works in a similar way; the only significant difference is in the fact that there are many more fields to fill out here. You will also notice that, because there are more than ten products, the main list has been divided into pages. This is a very useful function, because some of these lists can get very long and, therefore, very difficult to manage. However, you will most likely want to add more functionality yourself, like the ability to reduce the number of items in the list by modifying the database query that generates it.
The fields used to create or edit a product (see next screenshot) are all very straightforward, but a few words should be spent talking about the Sale fields (the last three fields) and the department list. As you can imagine, the sale fields are used to determine whether a product is on sale. It is possible to specify a start and an end date for the sale, and a sale price. The system will automatically apply the sale price to all purchases within the specified amount of time. The department list, on the other hand, makes it possible to associate a product with one or more departments-pressing Control while clicking on any department will alternately add or remove it from the list of linked departments.
The transactions section of our Store Manager only contains one button, which brings us to the list of orders, sorted according to certain parameters. If you choose to view orders divided by month, year or product, you will be shown a non-editable list of orders similar to the one in the following screenshot. Otherwise, you'll see something similar to the screenshot after that: a list of the orders available in the store. If you thought that the string used to identify orders was extremely long, take a look at the Shopper ID! As you can imagine, having it there, as it is, is not a great help-if anything, it makes reading the list more difficult.
Clicking on an order ID brings up a page with more detailed information on the order. Shipping and billing information are provided, as well as a complete breakdown of the items that were purchased. You will probably find the fact that no credit card information is displayed annoying, but I can assure you that it's there and can be retrieved easily, as we shall see in the next chapter.
However, what's really missing here is a link to a line-of-business system. Naturally, there is a reason for this: it's impossible to write a generic sample that will be able to interface successfully with all the possible line-of-business systems. Therefore, the MSCS team thought that they would provide an interface suitable for a store that doesn't have a real system designed to handle and dispatch orders, and leave the implementation of such system to the site developer. As a matter of fact, MSCS does provide all the necessary functionality to do so relatively easily, as we will see later on.
The only marketing function provided by the store is grouped together with the Merchandising functionality. As you can see from the next screenshot, there are two categories of marketing promotions that we can set up: price promotions and cross-selling promotions.
A Marketer's Dream: Price Promotions
If you've had a chance to work with marketing people in the course of your career, you will know how difficult it can be to translate their ideas into something technically viable. Their concept of "special offers" can take on the most convoluted forms, and they will always expect you to promptly generate the code that will make these "promotional Frankenstein's monsters" come alive.
MSCS provides a set of standard price promotions that can save your life. As a matter of fact, out-of-the-box it is possible to generate three different types of promotions:
buy x and get y at z% off
This kind of promotion gives the customer a discount on one item if another one is also purchased. The discount is expressed in percentage points.
buy x and get y at $z off
This promotion is exactly the same as the previous one, except that the discount is expressed as a dollar amount.
buy 2x for the price of 1
The third possible type of promotion is a variation of the first one. If the customer buys two (or a multiple of two) items of the same product, he or she will receive the second one(s) for free. As you have probably already envisaged, this is the same as offering a 100% discount on a product if the same product is present twice in the basket.
With a little effort, it is possible to imagine how all the three built-in promotions are really all variations of the same operation. In fact, if, after adding a promotion, we click on the Advanced Attributes link, we will always be presented with the same page, visible in the following screenshot. This screen makes it possible to modify the parameters of the offer with a higher degree of freedom than by using the pre-canned entry screens that we just saw.
An important element of a promotion is its rank, which expresses its importance or-in other words-the order in which it will be applied to the orders. The need for the rank derives from the fact that two or more promotions might be in conflict with each other and, because only one promotion can be safely applied to any given product (with the goal of preventing paradoxical scenarios from happening), the promotion engine must be able to decide which one is applied in every specific case. The lower the ranking number, the higher the priority that a promotion has; i.e. a promotion with rank 10 will take precedence over another one with rank 20, and so on.
As we mentioned above, cross-selling is an important part of a site's interface with the user. MSCS supports cross-selling promotions through the management interface shown in the next screenshot. As you can see, the system is very simple, and it practically allows the store manager to associate products with others as part of the promotion. Once we have added a new promotion, it appears on the web site in the product information page as a complementary product suggestion.
While this cross-selling system allows us to handle both cross-selling and up-selling (we'd just have to add promotions between a product and its accessories, for example), it readily becomes awkward if you have a large database of products, and it is unable to handle historical cross-selling (although MSCS provides this kind of functionality through the Predictor component that we'll see in the next chapter).
The system functions that are provided by our sample store are very basic (as is the store itself). The first part allows us to edit the pipeline files, which, as we'll see in the coming chapter on Pipelines, are used to configure the Order Processing Pipeline and manage the handling of orders.
Next, we can jump to the storefront (using the Shop Site button), close the site and force IIS to reload the store's Global.asa file, which resets the entire ASP application. We'll talk about the last two buttons, Site Builder Wizard and Promotions Wizard later on in this chapter.
Let's talk for a moment about the closing and opening operations. The concept that they control is quite simple, as you have probably already figured out: when major updates, or redesign changes, are required, the store can be temporarily 'closed' so that users cannot browse through it or make purchases. A closed store will usually display only an informational page, or be restricted to the non-commerce related functionality. In any case, displaying this kind of interface is much better than taking the site down!
How does MSCS handle a 'closed' store? As we'll see in the next chapter, the user is simply redirected to an entirely different set of ASP pages when the Close Store button is clicked on.