User Interface Considerations in Software

Generating Denso QR Bar Code in Software User Interface Considerations

User interface considerations are extremely important in the design of a programmed telephony application In this context, however, the user with whom we are principally concerned is the person at the other end of the call, not a computer user The person who is interacting with a programmed telephony application has a very limited interface: The person hears sound generated by the programmed telephony application The person can dial digits The person can speak As a result, designing the other-end interface presented by a programmed telephony application can be much more challenging than designing a visual interface for the CTI user, where it is much easier to provide feedback and many more options can be presented simultaneously This section presents a number of things to keep in mind when evaluating or building a programmed telephony application Consistency The most important consideration in user interface design, regardless of the context, is consistency A programmed telephony application should behave in a consistent fashion no matter where it might be in its logic flow This provides callers with a sense of security and reliability that makes them much more comfortable about interacting with an automated system Examples of consistency rules include: Reaching an operator A single digit should be reserved for reaching a live operator (if appropriate for the application in question) There should be just one value (typically it is ''0" or "*") used throughout the application If the caller presses the designated digit at any time (except perhaps in the middle of entering a multi-digit number), the call should be transferred to a designated operator If no operator is available, an appropriate message

should be played (For example, after hours on weeknights the message might say, "There is no one available to take your call at the moment Please leave a message and we'll return your call tomorrow") Reaching the main menu Most programmed telephony applications present a hierarchy of menus and allow callers to navigate by pressing digits that identify a desired choice The root of this hierarchy, the starting point, is referred to as the main menu A single digit may be reserved for returning to this main menu at any time If this feature is supported, the same key must be used throughout the program and the option must be available at all times Number entry format Programmed telephony applications often prompt callers to enter a number of some sort, such as a credit card number, account number, product number, etc The application should always use the same methodology for collecting a number from the caller The best approach generally is to use numbers that have fixed numbers of digits The prompts in these cases would say something along the lines of, "Please enter the six-digit account number now" The caller would then enter six digits (or a time-out would occur) Another methodology allows entry of a variable number of digits by using the "#" key to indicate the end of the sequence (This has become a de facto standard as a result of its use in paging systems) In this case the prompt would say something along the lines of, "Please enter the account number followed by the pound sign" All spoken prompts for a user to enter a number should be identical so as to reinforce that the same methodology is being used consistently The application might supplement this prompt with a tone (such as the bong tone)

Date format Another type of data that callers are frequently asked to provide is a date Dates always should be entered numerically (as opposed to using the letters printed on the dial pad buttons) Whatever sequence of prompts is used should be consistent throughout the application Canceling an entry The application should expect that callers frequently will make mistakes when using this primitive interface While supporting a backspace mechanism is unrealistic, a single digit should be used throughout the system to cancel an entry and start over A good digit for this is the "*" When the designated digit is pressed, the system should discard the partial number or date and play a variation of the last prompt that incorporates the word "reenter" Fail-safe Confirmation Any time that a significant entry is to be made that cannot be undone, there should be a confirmation step to ensure that the last request was not entered by accident The consistent support for this confirmation step represents a safety net that will make users much more confident in how they use the application Always Allow Interruption Once a given caller has become familiar with the operation of a particular program he or she will want to move more quickly, without listening to each prompt in its entirety It is therefore important that programmed telephony applications be prepared to interrupt the playback of a prompt if the response has already been received Support for type-ahead means that a user can enter a sequence of responses in anticipation of a prompt, so the prompt may be skipped entirely Type-ahead should be supported except in the case of confirmations

Presenting Spoken Information When presenting information in spoken form, it is very important that the most important, desired, or unique information be spoken as early as possible in each statement The key is to allow the caller to comprehend the desired information as quickly as possible, without abbreviating the language used Statements should be complete sentences in order to sound natural and to provide the redundancy that is important in spoken communication An example illustrating the application of this principle might be the choice of statements in a system that provides order status If the enquiry was to determine if a particular order was shipped, a system might say, "Your order, #12345, consisting of 2 items was shipped today at 12:02" This could be improved by saying instead, "At 12:02 today your order, #12345, consisting of 2 items, was shipped" Given the likelihood that the person already knows the order number and the number of items ordered, the fact that it shipped should go first In this example it is also a good idea to have a very different-sounding phrase to state that the order was not shipped For example, the statement "Order #12345 has not yet been shipped" allows the listener to identify the difference between the two possible cases after hearing just the first syllables of the response This principle is applied to menus by listing items in the order of frequency of use; callers can press the digit for the option desired as soon as they hear it, minimizing the time spent listening to prompts On a related note, the digit corresponding to a particular menu choice should follow the item, not precede it This frees the listener from having to remember each number while listening to each description Assume a Noisy Line The design of a programmed telephony application always should assume a noisy phone line and therefore the possibility that a caller might be having difficulty making out what is being said In particular, callers from cellular phones drop out of a call for a few seconds at a time Especially in cases where a name of some sort (person's name,

company name, street name, etc) is being read back, it is very important to allow the caller to request that the statement be played again In fact, it is highly desirable to allow the caller to request something be spelled out letter by letter, if necessary using disambiguators (such as the phonetic "N as in Nancy") Assume Errors A good programmed telephony application will devote at least half of its code to handling errors It is certain that, at every step in the logic, something other than the correct input will be received A good design will anticipate all of the possibilities This makes for a robust solution and a positive user experience