Client vs. Server side applications

This is one of those issues that never seem to go away - and for which there never seems to be a right answer! Mainly because it depends on the application that you're writing, the environment that it will use and your own personal taste. And your definition of application. So the following are my rather personal thoughts about where I put what part of the application...

The short version is: the user interface happens on the client and as much of the user interface as possible should be on the client. Obviously requests to the server and certain application logic take place on the application server.

Prompts

This one is easy. I always put the logic for prompts in VoiceXML page - i.e. in the client. Invariably I use a variable that I have created and intialised in the root document to determine which prompts should be used. So let's say that we have special prompts for first-time callers. The DB holds a basic profile of every MSISDN that calls the application. If I can't find a calling MSISDN in the DB, then I presume that the caller is a first-time caller. In that case I set a variable in the root document:

<script>
  var firstTime = true;
</script>

This variable is then used to determine which prompts should be played:

<prompt cond="firstTime">
  <audio src="prompts/firstTime_intro.wav"/>
</prompt>
<prompt cond="!firstTime">
  <audio src="prompts/intro.wav"/>
</prompt>

Now as a user interface designer, I can look at this and know straight away what the application does. I think it's a lot cleaner than keeping a variable in the session and writing the following:

<prompt>
<% if (firstTime) {
%>
  <audio src="prompts/firstTime_intro.wav"/>
<% } else {
%>
  <audio src="prompts/intro.wav"/>
<% }
%>
</prompt>

In the client-side approach the overview and testing of the code is easier, because you always see how the UI should behave. In the server-side approach, you need to call the page with different arguments (first-time caller or not) in order to see if the page is generated properly.

Data

My approach here is, if the data is available at the start of the application, then get as much of it across to the client as possible. Obviously if that means a page that is humungous, then forget it - everything within reason. But let's take a simple example - a horoscope. There are 12 star signs and each has a horoscope for work, love and mood. One possibility is to ask the caller which star sign they want and then go back to the server to get the data. Then if they want another star sign, go back again. And again. And again. You get the picture.

Or you could just get the data once and pack it into a few javascript arrays:

<script>
  var Aries = 0;
  var Taurus = 1;
  var Gemini = 2;
  var Cancer = 3;
  var Leo = 4;
  var Virgo = 5;
  var Libra = 6;
  var Scorpius = 7;
  var Sagittarius = 8;
  var Capricornus = 9;
  var Aquarius = 10;
  var Pisces = 11;

  var horo_mood = new Array(12);
  horo_mood[0] = 'You'll feel great today!';
  horo_mood[1] = 'You'll feel lousy today!';
  .
  .
  .
  horo_mood[11] = 'You'll feel queasy today!';
 
  var horo_love = new Array(12);
  horo_love[0] = 'You'll fall in love today!';
  horo_love[1] = 'You'll fall out of love today!';
  .
  .
  .
  horo_love[11] = 'You'll feel romantic today!';
 
  var horo_work = new Array(12);
  horo_work[0] = 'You'll find work fufilling today!';
  horo_work[1] = 'You'll hate work today!';
  .
  .
  .
  horo_work[11] = 'You'll love work today!';
  
  var selectedStarSign;
  var selectedHoroscopeMood;
  var selectedHoroscopeLove;
  var selectedHoroscopeWork;
 
</script>

So now, if the caller chooses Cancer, you can do the following:

<script>
  selectedStarSign = Cancer;
  selectedHoroscopeMood = horo_mood[selectedStarSign];
  selectedHoroscopeLove = horo_love[selectedStarSign];
  selectedHoroscopeWork = horo_work[selectedStarSign];
</script>

All your prompts and variable then only deal with the "selected" variables and you can write quite compact code.

Handling server requests

So your caller has given you some data and now you want to check it out. So you have so send the data to the application server for verification. How are you going to handle that? There are two possibilities: <data> or <submit>. <data> makes a lot of sense, if you can continue to obtain more information from the caller, as the request is being carried out by the server. If however, your application can't go any further without the response from the request, then it doesn't make much difference whether you use <data> or <submit>. The real issue in this case, is how to handle a slow server or no response at all.

With a <submit> you can set a fetchaudio file, as well as a minimum amount of time to play the file for. This is important, as you don't want to start playing "Please wait while I check your PIN code" and only get as far as "Please wait wh-" before "Thank you! Your PIN code has been verified" barges in! So if you want to do this, then you need to know roughly how long your "wait" prompt is. You can also set a timeout for the fetch. If the request takes longer than that you can catch it and then decide whether you want to try again, or maybe ask the caller to try again later. Quite often if a server is in difficulty, trying the request again won't make any difference.

The advantage of <data> is that you can play a prompt and then see if the data has come in or not. If it hasn't then you can play a new prompt - allowing you to randomise the prompts, and not always annoy the caller with the same prompt. However, in the end of the day, you are reduced to the same issue - has the response come in on time or not. In theory, <data> should have a slight edge on <submit>, as you always stay in the same page, meaning that the page has already been parsed by the interpreter and should be ready to go. However, unless the response page is huge, I don't think you'll really notice this difference.

Page size & network latency

The two extremes of writing applications, are to create VoiceXML pages with only once field in them and then play ping-pong with the server. Every dialog state is in effect a new VoiceXML page. The other extreme are VoiceXML applications which put as much of the user interface as possible into one page - an application like that could even make such use of the <data> tag that there's only one page for the whole application! Unless your server is under a lot of load, or your network is slow, you probably won't notice anything. However, if you're crossing the internet to get pages then it's probably a good idea to put as much as possible into the VoiceXML page at the start.

If you have any comments, ideas, issues, etc. about this topic why not try the voice-push forums