You are going to develop a personalized and flexible phone application? Okay, bad news first: You may get into hot water, if you are not able to ensure a manageable application definition because of increasing complexity. The good news is that VoiceObjects Desktop and VoiceObjects Server have been designed to cope exactly with this complexity, what makes your life much easier.

Sure, you are right: In most of today’s phone applications personalization is key, because it allows for adapting the user interface

• to individual users, e.g. by preferred language, persona or input mode,
• to user segments, e.g. post-paid customer vs. pre-paid customer, or novice user vs. power user, and
• to other relevant conditions, e.g. workday vs. weekend, happy hour vs. unhappy hour, or back-end available vs. back-end unavailable.

Real-life applications typically apply a combination of different conditions in order to offer the best suited user interface under certain conditions to a certain user. Additionally those conditions should be dynamically changeable at call time, e.g. to switch to another dialog language instantly at any dialog step. In the same way a web application server enables personalized web sites, the VoiceObjects phone application server supports personalized phone applications.

And it is not just about delivering the highest quality of service to your users! VoiceObjects Server based personalization also helps to relieve the media platform or browser from processing all these conditions during each call, ensuring best media platform performance during dialog execution. In other words: In a VoiceObjects setup the browser is used for dialog presentation, but VoiceObjects Server is responsible for any business logic and cares for “handpicked” (dynamic) dialogs for each user. Additionally all applied dialog conditions are automatically logged into the system database (Infostore), and the out-of-the-box reporting of VoiceObjects Analyzer can be used to analyze which conditions have been applied when and how often. Last but not least, you can apply these conditions as selection criteria (so-called dimensions) to other statistics, in order to analyze and compare user behavior, task completion or recognition scores in more detail.

VoiceObjects allows for such powerful applications by offering a single concept, called layers. Layers can be thought of global definitions or filters defined in your application. A developer defines a layer first, and later on applies the layer to each dialog step where this conditional behavior is required. However, in order to use the layer concept to its full capacity, you have to know how to design, configure, switch, apply and manage layer conditions. This article (to be continued) wants to shed some light on what you should keep in mind using layers.

Let’s start with an important basic distinction: VoiceObjects Desktop is equipped with standard (meaning application-independent) layers, which are already built-in to other dialog objects. These so-called system layers can evaluate the current dialog language (English-US, Spanish, etc.), input mode (voice / DTMF), phone channel (like voice or mobile Web) and occurrence (visit counter per dialog step). All other (typically application-dependent) layers are so-called custom layers. Each custom layer in your project has to be defined by a Layer object.

The second important concept focuses on the switching behavior of layers: Each layer has a set of so-called states, which are switched on or off following a well-defined process and logic. On the one hand automatic layers are switching… (guess!)… automatically, i.e. some internal logic controls which layer states are currently on (active) or off (inactive). On the other hand manual layers have to be switched “manually”, i.e. by calling the Layer function in an Expression object. The same Layer object type is used for defining both manual and automatic layers. By the way, all system layers are manual layers.

You may ask: What determines if a custom layer defined by a Layer object should be automatic or manual? Consider the following: Are there any settings (variables or other indicators, like contract number or time of day) which can/should be constantly monitored in order to control the layer states? This would argue for an automatic layer. Or is this layer more dependent on certain events or exceptions and changing more on individual incidents rather than switching frequently throughout the whole dialog? This would call for a manual layer. You should also take into account that a manual layer always has exactly one state activated, whereas automatic layers can have any number of active states (including none or all states). In general, many custom layers can be configured as an automatic or manual layer, and the choice will be a matter of best practice and personal preferences.

Looking deeper into the configuration of automatic layers you will notice two alternative mechanisms offered by the Layer object: First a state indicator and sets of indicator values assigned to each state, working like a Case-Else construct, and second state conditions working like pre-conditions per state. Mind that both approaches cannot be mixed in a single layer definition.

Typical traps working with layers are:

1. During development ensure that your state IDs (which will be used internally by VoiceObjects Server during layer processing) are subject to the same restrictions as other object reference IDs, especially use no special characters (incl. space!) and be unique within your project.
2. Do not try to switch an automatic layer using the Expression function Layer(). This would cause an internal server error at call time.
3. Do not forget to define the initial (default) state that is required for each manual layer.

Feel free to add comments based on your experience working with layers. A follow-up article will continue on some best practices about switching layers and applying layers to your dialog definition, and will provide some more references and examples. Stay tuned!