When was the last time you built a store from scratch? For the Internet, I mean. If you haven't done it already, don't. Not that I've done it myself, at least not completely. I'll admit that I can be a very stubborn application developer, especially when I think my way is the best way. In the case of the online store that I started to build with raw HTML and some Perl (with a dash of database connectivity from who knows where), I was convinced that the learning experience was justification enough.
It wasn't. At the time, there was no pressure to finish an online store project, at least not exactly. I knew there was a project on the horizon, about two weeks away, and that getting the jump on it by learning how to build an online store was undoubtedly a good idea. Given the schedule, I believe the ancient Greeks had a word for this kind of thinking: hubris.
I will spare you the gory details. In fact, I'll spare you the bloody outline. Building an online store (a Web store by another name) is a big project. Much bigger than I thought, even without programming from scratch. I hadn't done more than construct a few forms and diddle with middleware database connectivity before the two weeks were up and I had a real project in my lap. Fortunately, my clients were hip to the scale of the project and never entertained the idea of developing the entire store with primitive tools. They didn't want a log cabin; they wanted, if not the Taj Mahal, at least a Bauhaus creation. Luckily, things weren't all prearranged, and they suggested I look into online store development products and select the best tools for the job. Winnowing e-commerce products, however, was no small challenge. Here I come to the point of this column. If you haven't experienced all that follows about choosing online store software (or even if you have) we can share a few groans, guffaws, and grimaces.
In my other life as a writer/journalist I keep my hands on some of the newest e-commerce software by reviewing it. This is something like getting an impossible crossword puzzle on a regular basis. I've learned that most e-commerce software can create an online store, but there's hell to pay in the fine print. I've also noticed that the software comes in different sizes: hosted store (no size at all, they do it for you), semihosted store (you do the work but they have the Web server), basic online store (your work, your server, but modest in scale), and enterprise online store or commerce server (the big time). These shouldn't serve as categories of e-commerce software, but they're descriptive of the available variations. Naturally, you try to pick a size that fits for today and keep one eye cocked to the future.
All the software will create what I'd call a standard store. This consists of a product catalog (where the online customer selects what she wants to buy), a shopping cart (where product selections are collected), transaction security (credit card authorization and other payment schemes), and order processing (shipping, taxes, inventory, and so on). But this isn't all there is to a store. If done right, a store has personality -- a shopping experience -- that is the sum of the presentation (visual design) and process (registration, ordering, and so on). The result is not very different from shopping in a store on Main Street, but the means are quite different.
I'm not sure why, but some people (clients) have a way of assuming that building an online store can be handed over to a programmer or webmaster and that's that. It's not, of course, any more than you'd turn over the entire construction of a bricks-and-mortar store to the plumber. It takes a lot of skills to make a successful online store, just as it does any other kind of store. I bring this up because when you get your hands on some tool for developing online stores, it may not be readily apparent that it's pure folly for one person to attempt everything. Nowhere in the manuals will you see lines like, "Here is where the Web designer steps in to add a really beautiful color scheme to the shopping cart." About all you'll see is error messages suggesting that you take up the problem with "your database administrator."
Of course, scale makes a difference. The bigger the store (more items, more sales, and more technology) the more likely there will be a natural division of labor. On the other hand, I know darn well that in some circumstances the developer must be a jack-of-all-trades. Been there, done that. However, I'd strongly recommend that, at the very least, you not accept the responsibility for assembling the product catalog content (such as product descriptions, prices, and pictures). Somewhere in every store the people in sales or marketing must have a place for their work; the catalog is one of them.
You can guess why I quickly jettisoned any notion of building a Web store myself. I learned that there were so many elements to a store, no self-preserving (or profitable) developer would be happy with a totally do-it-yourself arrangement. Of course, if you're a developer within a corporation, you probably already work in teams and are familiar with collaborative projects. The trend toward developing software in concert with the client (domain specialists) and other computer people (technical specialists) makes a lot of sense for online store projects.
Enough of the trend analysis -- which is mostly common sense that I wish I had when I needed it -- back to selecting software tools. What is it, exactly, that we are looking for? First, the obvious: the software should provide services and modules that you don't have to write yourself. It should make extending, enhancing, and modifying things as easy and accessible as possible. A little less obviously, it should provide a framework for the online store that guarantees data integrity (transaction control), security, and scalability. I hate to use the words, but there are architectural issues here. The way the software is assembled and works together is important.
I come to these requirements in hindsight, having waded through nearly a dozen of the leading (and not so leading) candidates for e-commerce and online store development. We looked at options big and small, ranging from some hosted systems (such as MindSpring) to the scale-in-the-huge and hugely expensive (such as Open Market). My client wasn't ready for the huge, but no longer fit the small. We figured something in the $3,000-$20,000 price range (software only) was ballpark. Hosting was attractive, but nixed by the client on account of the sensitive nature of the information. (Headhunters are notoriously paranoid.)
Fortunately, that price range put us smack-dab in the middle of the pack where there are now dozens, if not scores, of choices. This is where most companies will find the appropriate products, and why I'm taking your time with a running narrative. The middle ground includes some big names such as IBM Net.Commerce, Microsoft Site Server Commerce Edition, Netscape Business Xpert, and Oracle Internet Commerce Server. It also includes many new names that are specialists in this area such as iCat Corp. Electronic Commerce Suite, Online Corp. ONLINE, Inex Corp. Dynamic NT, The Vision Factory Cat@log, and Mercantec SoftCart, to name a very few.
Because this is a column and not a review roundup, I'm not going to pit these bulls against each other. I'll use them as reference for their highlights and lowlights while touring through the most important components of an online store.
From the customers' perspective, the most important part of the online store is probably the catalog. They're likely to spend the most time here, whether browsing or buying. The catalog is also where they'll pick up most of their impressions about the store. In the basics, the online catalog is closely analogous to the mail-order catalog: product descriptions, pictures, and prices. Fortunately for the Web, you can do a lot more with an online catalog than a page-turner. You can make a Web catalog into a fully interactive, multimedia experience-something the printed version can't compete against.
Unfortunately, turning a Web catalog into an extravaganza can be a nightmare for the store developer. Too many of the online store products treat the catalog as an exercise in database management, with or without a sprinkling of multimedia. Some, like iCat, at least make it clear what your options are for enlivening the catalog. Most don't make it easy. Importing pictures, text, prices, and all the variations for products (man's crew shirt, sizes 12-18, blue, green, yellow, red, and so on) can become very tedious and also complex.
Good commerce software attacks catalog complexity from two fronts. One is the approach to organization. Most of the products organize the catalog into some kind of grouping or hierarchy: departments, sections, and types, for example. For some this is pro forma and dull; for others it's an opportunity to add some excellent graphics to the pages that help visually guide the customer. Grouping the catalog items is also usually an integral part of a search capability, providing the customer with a quick way of finding products. Some, such as Oracle and Microsoft, have powerful index capabilities. IBM's Net.Commerce goes much further by adding a Product Advisor, kind of an artificial intelligence helper to steer the customer through categories and product options.
The second avenue of attack on catalog complexity is through templates. Almost all online commerce products will ship with catalog page templates that you can use by simply connecting them to a data source and adding hyperlinks. Check them out carefully. How many are there? Are you offered a variety of styles? What do they look like - the work of an HTML programmer's late night, or professionally designed? Perhaps equally important is the template's accessibility. Oracle Server lets you know that templates are found in certain directories, but it's up to you to go find them with whatever tool you have. Microsoft Site Server bundles its Front Page 98 Web layout and authoring tool, so when you do find the templates you can modify them. The one aspect of a catalog that will probably drive you to No-Doze is importing the data. On top of what I've already mentioned about sharing the responsibility of gathering the product information, the store developer is usually faced with the monumental task of somehow getting all the data, pictures, and other detritus of several thousand items into the Web site's database system. With luck, the data comes from the same kind of system. Usually, of course, it doesn't.
While all the online store development products give you a way to enter the details of individual items, nobody of sound mind would enter more than corrections and updates that way (unless, of course, the store has a tiny inventory). Most stores are going to have hundreds, if not thousands, of items for sale, and the job of filling the catalog with that information is formidable. You'll find that products closely associated with mainframe-style database systems (like IBM and Oracle) love to use "bulk loaders." What this usually means is that the developer or a database administrator must carefully marshal all the data into a strictly defined data file format for import into the store's database. Some of these formats are, well, elaborate and will probably require programming to get the data into shape.
I personally like the approach taken by The Vision Factory's Cat@log, which uses ODBC in a well-organized and visual way that makes it relatively easy to link disparate tables into the catalog pages. Cat@log also has a well-developed set of HTML tag extensions that give you precise control over the database operations within the store pages. This is very similar to application development programs such as Cold Fusion and Tango (which, incidentally, can also produce an online store). Most products use this same approach, but some are cozy with the tags or make it very cumbersome to manipulate them.
The catalog is not the only use of a database. While the customers shop, they usually put their selections into what is now ubiquitously called a "shopping cart." The database stores these selections and later uses them as the basis for the ordering process. Watch for those products (these days, most of them) that use the database to store various kinds of metadata (user sessions, store status, user preferences, and profiles). There is a natural advantage to storing this kind of information in a database - it's much easier to access it for maintenance and reporting.
"Write it up!" is the happiest sentence in the sales lexicon. On the Internet, it's the beginning of a chain of events that contains some of the most important, yet irritating, details of an online store. The customer usually signals that she has finished collecting items (in the shopping cart) and is ready to buy. Here's where the skein of business logic begins to take over. Is the customer registered? Can the customer purchase without being a member? Is the customer's name, address, and phone number in the database?
Collecting certain customer information (name, address, and phone number) is required, especially if the purchases have to be shipped somewhere. There can be many details involved with shipping, so if you have the type of store where shipping options are important, it will be worthwhile to look for software that supports third party shipping modules (such as Tandata from Tandata Corp.). A similar situation pertains to taxes applied to purchases. Because these vary enormously from state to state, it may be important to select an e-commerce package that supports one or more tax calculation packages (such as Taxware by Taxware International).
There are many other kinds of calculations associated with orders - discounts, coupons, volume breaks, and more. Most e-commerce software can do some of these. You should check your store's needs against the list of supported calculations, or at least be able to add custom calculations easily. This is an area of order processing that usually falls under the "Store Manager" (or some similar name), a module that gives the store operator access to the business logic. Some, such as ONLINE, give you pages of forms to fill in values and operators for the logic; others, such as Net.Commerce give you easy access to the calculation formulas.
As I mentioned, storing customer information is a crucial part of an online store. The more sophisticated packages keep a great deal of customer data, including where they go in the site, and make this information available in the form of analytical reports. Microsoft Site Server is arguably the best at this, thanks to Microsoft's acquisition of two specialist companies that produced the site analysis software. Make sure that the e-commerce package can also use the customer data to drive dynamic Web pages, changing the content and sometimes even the look of pages to suit the tastes and desires of customers (as revealed by their purchase preferences). The same information can also drive dynamic advertising. Here too, Microsoft has the advantage with a new component to the Commerce Edition called the Ad Server. It's part of a comprehensive targeted marketing capability that includes sophisticated push technology.
One of the technically trickiest and psychologically most touchy moments comes when the customer selects a mode of payment, the software verifies the ability to pay, and the transaction is sent out for processing. In general, it's better to select software that offers a variety of payment schemes, ranging from internal bookkeeping to your choice of third-party programs such as CyberCash (the best known), eTill, and Microsoft Wallet. Most of these will entail considerable setup, and require that you have a special account with a bank that you can use for the final (fulfillment) transaction. Up front, with the customer, your program must be able to get the needed financial information and make the customers comfortable with the safety of the transaction - without making them feel like they're tiptoeing around Fort Knox. This is one area where a good set of templates (or other kinds of programming) can save you an enormous amount of work.
As you know, software is never finished. Neither is an online store. Just when you think you're ready to let the customer have at it, you come up against one of the grand logistical problems of our decade - Web deployment. Deploying a Web page means copying it into a subdirectory that a Web server knows about and linking it to some other page so people can find it. If it were only that easy for an online store. Well, some of it is that easy, but online stores tend to be whole sites, complete with Java apps and other executables (ActiveX and CGI), graphics, database connectivity, and many HTML pages. All of this has to get to the right place at the right time.
That's why you want software that makes deployment as clear, automatic, and reliable as possible. It's tough to get all three. Oracle's Internet Commerce Server is very clear - there's staging and deployment directories with their own user accounts and security. Much of the program is organized around these two phases. Microsoft's Site Server has solved the reliability problems of FTP transfer by creating a transaction framework for deployment. Other products muddy the waters by transferring data to entirely different database systems. There are lots of possible complications, especially with updates.
E-commerce may no longer be in its infancy, but that doesn't mean the linen is always clean. There is no such thing as a perfect e-commerce package. Some may be better suited for the scale and type of store you have in mind, others are a good value, and still others are very robust and heavy duty. None, however, will install, configure, run, and update flawlessly. In fact, most of them - even the best - require constant, informed (often expert) attention. I'm waiting (almost longing) for the day when I can install one of these programs without errors or segments that don't run. It will also be nice to see documentation that doesn't assume you're already a grand master of six different programming languages (SQL, Perl, HTML, Java, JavaScript, and VBScript) and a database administrator.
I figure there are a couple of reasons for the current state of inelegance. Commerce packages are complex software built on top of even more complex software. For example, Microsoft Site Server Commerce Edition uses Windows NT 4.0 (with Service Pack 3), coupled with the Internet Information Server (IIS 4.0) for the Web Server, on top of which is applied the Site Server application server that uses a database server (in this case Microsoft SQL Server), on top of which runs the Commerce Server software. Each service or module must properly synchronize with the next - if not, you get problems. So you get problems, and it takes a solid knowledge of the whole chain to debug quickly and accurately.
Having said that these e-commerce programs that develop online stores aren't perfect, I'd also say they're indispensable. However long it takes for you or people in your organization to learn what is where and how to fix it, it's quicker and cheaper than learning how to do it from scratch. In cases where the software has been well designed and executed, it's darn near magic, and it frees the developer to concentrate on look-and-feel issues rather than floundering around in the basement technologies. Most of the programs achieve this level of functionality; others exceed it by quite a wide margin. And what product did we choose? Let me just say I'll duck the question in order to avoid named pipe bombs and possible inquisition from the DOJ.
What did you think of this article? Send a letter to the editor.