Volume 2, Issue 1 - January 2002
   
 

Understanding V-Commerce

By Greg Harman

Introduction

With the advent of VoiceXML technology, V-commerce has become the newest paradigm for using technology to re-invent commerce. The web enabled E-commerce, allowing the entire sales and purchase process to happen over a computer. Data-ready PDAs and mobile phones extended this to M-commerce, allowing the same transactions to be made anywhere. Now, V-commerce allows these transactions to be made in a more natural way by using normal speech, and allows these transactions to be made without any special equipment (phones are generally ubiquitous).

In order to delve into the proper design of a V-commerce application, we will create our own sample: an electronic hat store. We will start by creating a high-level architecture by examining common architectures for M-commerce and E-commerce applications, and then modifying them accordingly.

A common architecture for an E-commerce application consists of three tiers: the database logic, the business rules, and the user interface, as illustrated in Figure 1. The database logic contains all of the raw data about the products: the styles and sizes of hats carried and the number of hats available. It also contains customer and order information.

The business rules dictate that when a new order is placed the items are removed from inventory. They also dictate that each order of three or more hats is sent with free shipping.

The user interface displays the product catalog to the customers on their home computers, and creates the form for customers to enter their billing and shipping information. In addition, it displays targeted advertisements for scarves (to go along with the hats).

Figure 1 - E-Commerce Application Architecture

Next, we consider our hat store as an M-commerce application. We are selling the same products and handling orders the same way, so our database logic layer remains unchanged. We still want to handle our inventory the same way and offer free shipping on large orders, so the business rules also remain unchanged. The only thing that has changed is our presentation - the catalog, order form, and advertising must now be displayed on a smaller PDA or mobile phone screen, hence from the architecture view, we have a very similar application as illustrated in Figure 2.

Figure 2 - M-Commerce Application Architecture

In addition to formatting issues, there are certain changes in presentation and content that must be made to the user interface. A very limited amount of information can be displayed at one time, so information must be made deeper. For example, instead of presenting a page showing every style and color hat available, we must now create a two-level menu. The first level allows the user to select the style, and the second level allows the user to pick the color.

Information input can be very difficult on a mobile device - imagine punching in a long address on a phone keypad - so M-commerce user interfaces must strive to limit the amount of information that the user is required to input to make a transaction. For this reason, we should input as much of this information as possible through the E-commerce application and store it in the database for access by a mobile device.

Now, we will examine the hat store as a V-commerce application. Again, the database and business rules remain unchanged, since the business itself remains unchanged. What does change is the user interface. Now, the menu options need to be presented such that they are understandable verbally. The choices of inputs are again limited to selection from simple lists; arbitrary inputs should still be entered through the E-commerce application.

Continued...

back to the top

 

Copyright © 2001-2002 VoiceXML Forum. All rights reserved.
The VoiceXML Forum is a program of the
IEEE Industry Standards and Technology Organization (IEEE-ISTO).