DESIGN CONSIDERATIONS OF INTEGRATED COMMUNICATION APPLICATIONS.

Introduction

As we've learned that there are several places where these three API sets provide overlapping services. Here we try to show we how to determine when each of the three API sets should be added to a program. we'll also learn how to best implement each of the services depending on the Windows operating system and programming tools available to us.

There are a number of things to consider when building an application that combines multiple services. This chapter will cover the following main points:

General Considerations

When first beginning the design phase of an application, ideas about what users need and how they will interact with the system are purposefully vague. The general flow of a software system and the interface needed to support that flow are only hinted at. Once it comes time to actually build the application, however, things are different. Now all the promises and hopes of the design group rest on the few brave souls who have the task of implementing the design.

As Windows services become more common and familiar to users, the minimum requirement for new applications is constantly being increased. A few years ago users were pleased to get friendly screens that beeped at the moment they entered invalid data instead of waiting until the batch was completed and the error report printed. Now users expect to see drop-down list boxes, context-sensitive help, and "wizards" and "assistants" that will tell them ahead of time what data they should be entering! And they often get just that.

It is very common for users to expect e-mail to be an integral part of every application. Now users are learning the possibilities of linking telephones to their systems, too. And where telephones appear, speech processing cannot be far behind. The hardest thing to keep in mind is that not all applications need all the extensions. And even the ones that do need extension services can often get by with less than a full plate of service options.

Adding features and services without taking the time to think about how they will interact can lead to major headaches. This section covers some general rules to keep in mind when designing and implementing multiservice apps.

Rules of Complexity

The first thing to keep in mind is that each new service we add to our system adds complexity. And this complexity increases by orders of magnitude. When we decide to add one of these services, think long and hard. And if we still want (or need) to add the service, prepare for additional time to redesign, code, and test ourr application. Despite what anyone tells us, adding e-mail or telephony or speech services to an application is no simple matter.

For example, adding e-mail to a system doesn't just mean we need to add a few menu items to the screens to allow users to send documents. we now have to deal with users attempting to format documents for printers and for e-mail messages. Now users will want to send multiple copies of the same message, possibly to someone halfway around the world. And that person probably uses a different e-mail format, too! While good e-mail service models (like MAPI) will mask much of this detail, we can still end up with requests for features that push the limits of our system.

Now consider adding telephony or speech services to the same program. While the possible applications of new technologies are exciting, the possible collisions of APIs can be daunting. For this reason, it is always a good idea to limit the feature sets we build into an application. While users will often ask for (and get) the latest technological breakthroughs, they don't often use them to their fullest potential. It is important to keep a clear head about just which "bells and whistles" are required and which are desired. Each new service extension adds a level of complexity to the system-for designers, programmers, and users. It is a good idea to do our best to limit the extension sets that are added to any single application. Usually this can be done without sacrificing features.

Native API versus High-Level Tools

Once we decide on just what services we will include in our application we need to decide on how we will deliver these services. Often the first inclination is to acquire the latest API/COM specification documents and begin coding function and class libraries to encapsulate the desired services. While this is good, it may be unnecessary. Often there is a very good high-level toolkit that we can use to gain access to the service. And these high-level tools come with support and documentation already built.

Visual Basic programmers tend to think first of third-party add-ons. This is because they usually live in a programming universe that is inundated with OLE, OCX, and VBX solutions to problems most of them never knew existed! But even C++ programmers can find more high-level tools on the market today-especially MFC libraries that encapsulate complex APIs. It pays to look around before we start any "deep coding" of the API set.

Of course, there are drawbacks to using high-level third-party tools. Sometimes they are limited in their performance. Sometimes, they even turn out to be buggy. While the latter is a rarity, the former is often the case. Most third-party tools are designed to solve a particular set of problems. If we attempt to use the tool to solve problems outside the original scope of the tool, we can easily become frustrated and disappointed. It's a good idea to thoroughly test controls and libraries before adding them to a production application.

Finally, using home-grown libraries or native API calls means that we will need to keep up with the latest bug lists and upgrades for the underlying API. This, too, can be a big job. Often, it is easier to spend the time shopping for a good tool and keep current on its upgrades. (Assuming, of course, that the product we purchase actually keeps up with the latest releases. Nothing is more annoying than discovering that the product we based our whole system upon is no longer in release!)

Standalone versus Extensions and Add-ins

The last thing to keep in mind when designing and implementing applications that take advantage of the new Windows services is the standalone versus extensions/add-ins debate. Is it better to write our own standalone voice-activated e-mail client or to create extensions or add-ins to existing clients already on the desktop (such as Windows Messaging or Microsoft Mail clients)?

Often it is easier to build our own standalone versions of common applications. It takes very little time to build a working e-mail client using the MAPI client interface. This allows we to add whatever features we need without concern for generating conflicts or confusion when adding features to existing products.

The advantage of extensions and add-ins is that we don't have to reinvent major portions of our application. Most of the primary desktop tools (e-mail, databases, spreadsheets, word-processors, and so on) are easier than ever to program. Most of the Microsoft Office applications are able to host the Visual Basic language, and even ones that do not will allow simple API calls into predefined "hooks" inside the target application. With a bit of reading and lot of experimentation, we can get our extensions to coexist comfortably with the desktop application.

The general rule to use in deciding whether to go the standalone or extensions/add-ins route is: Check our client base. If most clients have the targeted desktop application (and they are likely to keep it), then go the extension route. However, if most of our users have a mix of client applications, or no client applications at all, we would be better to build our own standalone application (based on the pertinent Windows extension service). Then we can deploy it among a wider collection of workstations without having to battle different hosting applications, and so on.

MAPI versus Comm API

A common dilemma for programmers is whether to use MAPI services or Comm API services to perform file transfers and retrievals. In the past almost all file transfers (such as daily payment batches, sales figures, and so on) were handled using dedicated applications. It sometimes took hours for these specialized transfer routines to perform their tasks and, instead of tying up existing systems, this kind of transfer work was off-loaded to dedicated machines.

With the maturing of e-mail and the expansion of the Internet, much of this activity is moving through electronic mail instead of direct dialup applications. For the most part this is good. But there are times when a simple dialup application can be a better solution than e-mail.

The advantage of e-mail is the widespread coverage that is so easy using a single protocol (MAPI). Also, the MAPI model has fairly good recovery in the cases of non-deliverable messages. While it is quite possible that an e-mail message will get routed to the wrong address or return to we marked "undeliverable," it's rare to actually lose a message sent via e-mail. Another plus for MAPI services is that there is a wealth of utilities and support software for both programmers and users. MAPI is the standard and almost any e-mail client supports MAPI services.

The disadvantage of MAPI is that this protocol can be quite limiting in the types and lengths of message formats that can be sent. The most reliable data format is an ASCII text file. If we plan to send binary data, we'll need to be sure our routing path to all points is able to handle the binary format. Also, large files tend to get garbled when sent using MAPI protocol. Many public mail servers even truncate messages to reduce bottlenecks in the system. This can lead to tedious conversions of binary data into multifile messages that must be reassembled and converted back to binary before they are usable for the recipient. While utilities exist for this type of arrangement (MIME encoders, for example), it's not always the best way to go.

The advantage of using a dedicated Comm API-based application is that we can write small, fast, and relatively simple file transfer programs using any one of several reliable and well-documented pc file transfer protocols (the X-, Y-, and Z-modem protocols are good examples). By writing small, dedicated applications, we can focus on the things we need and leave out all the "headroom" required by MAPI e-mail systems.

One of the biggest headaches when using dedicated programs is file transfer scheduling. Usually both systems must be up and running at the exact same moment. This is often handled by establishing a fixed file transfer schedule. Each machine is expected to be available at a certain time of the day, week, or month to receive or send data files. Anyone who has nursed a system like this knows how troublesome this kind of scheduling can be. Unless the calls are timed correctly, sites that receive a lot of calls will send out frustrating busy signals. Also, if a receiving site goes down (due to power failure, for example) the whole system can grind to a halt in short order. As long as there are not a lot of sites involved in this kind of arrangement, dedicated binary transfers can often be faster and more reliable than ASCII text e-mail messaging.

So, to sum it up, if our application needs to distribute information to a wide number of locations on demand, mostly in ASCII text format, then e-mail and Internet/Intranet distribution is probably the best method. If we need to send binary data to just a few sites on a regular schedule (daily, weekly, and so on), then we should consider building a dedicated dialing application that uses the Comm API (or OCX) instead of MAPI services.

Assisted TAPI versus Full TAPI

As TAPI systems become more commonplace, it is more likely that creative minds will come up with a reason to use the new extensions for as yet undreamed-of applications. While the benefits of Full TAPI services are clear, most applications-especially client-side applications-do not need full use of the TAPI extension. For the most part, server systems tend to work with inbound calls and client systems usually handle outbound calling. If we are building a TAPI application, we need to determine if we are building a client- or a server-side application.

Of course, just what constitutes a server is hard to define. With the introduction of Win95 to the market, lots of end users have all the tools they need to act as a server in telephony or any other Windows extension service. But, despite changes in the operating systems, the rule still holds-clients place calls, servers answer them.

If we are designing a system for sales force automation, we may be able to provide solid support for key features using only Assisted (outbound) telephony services. In fact, some telemarketing shops do not want their employees handling any inbound calls at all. Keep in mind that we can still build serious "power-dialer" applications using only Assisted TAPI services. we can create applications that read phone number databases, automatically place calls, and present telemarketing staff with dialog boxes that contain customer-specific information without using Full TAPI services.

Another major advantage of using Assisted TAPI to meet our telephony needs is that almost any data modem is capable of successfully placing outbound calls. we will rarely need to purchase specialized hardware in order to allow users to call out using their workstations.

On the flip side, if we are in charge of building customer service center applications that can accept and route incoming calls based on ANI (Automatic Number Identification), caller ID, or other values such as an account number entered at the telephone keypad, we'll need the Full TAPI service model to reach our goals. If we decide we need to accept digits and other call-progress information from incoming calls, we should also consider using a third-party TAPI development tool. These are relatively inexpensive and usually provide excellent support and documentation. A good TAPI tool can make telephony programming relatively painless.

Of course, with the added capabilities comes the requirement for increased hardware features. TAPI applications that handle inbound calls will need to use at least a high-grade voice-data modem. If we are building an application that will get heavy use or one that uses multiple lines, we need to replace our modem with a telephony card. While these cost more, they mean a huge increase in capacity for our Windows TAPI applications.

So, again, if we are building client-side applications that will be used primarily for placing outbound calls, it is quite possible that we can solve our problems using Assisted TAPI services. If, however, we are building applications that will act as telephony server devices-answering and routing incoming calls-we'll need to use Full TAPI and we will probably need a full-featured telephony card, too.

When to Use the Speech API

Knowing when to use SAPI services can be a bit tricky, too. While speech systems for computers have been around for some time, the Microsoft SAPI model is still a newcomer. For the most part, SAPI works best as a text-to-speech engine instead of as a speech recognition system. Even as a TTS tool, the SAPI system has its limits.

Reading extensive amounts of text using SAPI's TTS engine can quickly tire the average user. This is because the computer-generated voice lacks the human prosody (speech patterns) to which users are accustomed. If we have material that is relatively stable (for example, directions to our office), it is a better idea to use a recorded WAV format file than to have SAPI "read" the text to users.

Another consideration is the amount of processing power needed for SAPI services. The SAPI system requires more memory and processor time than the other two services covered in this book-and for good reason. The amount of calculation needed to convert ASCII text into recognizable human speech is quite large. Converting speech into models that can be compared to registered voice menus is even more resource intensive. If we expect most (or even some) of our users to have less than 16MB of memory on their workstations, we'll have a hard time successfully deploying SAPI services within our applications.

Finally, the accuracy of SAPI speech recognition (SR) is highly variable. The current state of technology is only able to reliably handle single words or short phrases. SR systems are best used as an addition to keyboard or mouse controls within an application. It's frustrating to have to repeat the same phrase over and over again (getting ever louder each time) in an attempt to get our workstation to perform some simple task that could have been accomplished with a few clicks of the mouse or keyboard.