Thread Subject: Comments re: the proposed revisions to 1194.23(c)

From: Michaelis, Paul R. (Paul)
Date: Sun, Mar 04 2007 12:20 PM

• Return to this mailing list's archives
• View all messages in this thread
• Next message in thread: None
• Previous message in thread: None
• Messages sorted by: Author | Thread | Date

Below is a copy-and-paste of the proposed 1194.23(c) requirements. My
comments are embedded.



c) Voice mail, messaging, auto-attendant, and interactive voice response
telecommunications systems shall:



(1) be usable by TTY users with their TTYs and by individuals using
relay services including voice carry over, hearing carry over, video
relay, and speech-to-speech relay services,



I think it's unlikely that anyone outside our community will know how to
tell whether a system complies with this requirement. I suggest
something like this:



(a) All information presented by voicemail, IVR, or automated attendant
systems via the telephone user interface shall be available by voice and
shall also be available as Baudot TTY signals.



(b) Voicemail systems shall be capable of recording voice messages and
shall also be capable of recording Baudot TTY messages.



(c) Regardless of whether the voicemail telephone user interface is
presenting information by voice or TTY, it shall be possible for users
to record a voice or TTY message.



(2) have audio capability sufficient for high intelligibility,



Another example of a requirement that is not testable. I suggest
something like this:



Voicemail, IVR, or automated attendant systems shall use the ITU-T G.711
standard for encoding and storing audio information. If an audio
encoder other than G.711 is employed, the vendor must provide evidence
that the intelligibility is equal to or better than that provided by
G.711.



(3) have highly intelligible recorded messages and prompts without any
background sounds that would reduce intelligibility,



My proposed rewrite for item #2 covers this.



(4) provide full player controls that allow users to pause, rewind, slow
down and repeat all messages and prompts, and adjust volume,



(5) include menus that contain no more than six items,



I support the objective here, but what's being proposed is unrealistic.
A simple example: If the requirements of item #4 were followed, you've
already used up your six menu items.



On the Avaya "Intuity AUDIX" message systems, we have implemented what
we refer to as global commands. For example, regardless of what the
user is doing, star-D is always Delete, star-H is always Help, star-T is
always Transfer, and so on. These commands are available in addition to
those that vary depending on context. When you combine the
context-specific menu items with the global commands, it will often be
the case that more than a dozen options are available at any given time.
Even under these conditions, it is important to note that the initial
prompt heard by users at any given node never exceeds more than four
options. In almost all cases, the option desired by typical users will
be among these four. (The full menu is presented when users ask for
help by pressing star-H.) Extensive Human Factors testing has verified
that this is a highly usable design; it has been in our voicemail
systems for over 20 years and is being used by millions of people all
over the world.



I suggest rewording this requirement to say something like, "Unless the
user requests to hear more options, a telephone user interface shall
present no more than four menu options at a time."



(6) provide easy to understand and act upon menu items and other
navigational messages,



Again, I understand and support the objective here, but this requirement
is much too vague. Compliance must be testable.



(7) provide controls that are consistent throughout the application,



I think that we have achieved this to a certain extent with the "global
commands" that I mentioned earlier. Nevertheless, in my opinion, this
requirement is unrealistic in a telephone user interface. Keeping in
mind that dial pads have only twelve buttons, it's unavoidable that the
functions assigned to those buttons will have to change depending on
context.



(8) allow the user to correct any errors or confirm any input that would
lead to permanent changes in their account or profile;



In IVR systems, it is the purchaser's responsibility to ensure that this
capability is implemented. This is not a procurement issue.



(9) Have an "easy out" to reach a live customer service representative.



If the system you're calling into doesn't present this option, it ain't
my fault! "Easy out" has been a supported option on all of our
voicemail, IVR, and automated attendant systems ever since the very
first models. In all cases, the availability of the "easy out" option
is the decision of, and implemented by, the purchaser. The best I can
do as a manufacturer is advise the purchaser how to configure our
systems in order to provide the "easy out" option.



Keeping in mind that the availability of this function is not controlled
by the vendor, I'm not sure that having it as a procurement requirement
makes any sense. Perhaps we can modify the wording to say something
like, "All voicemail, IVR, and automated attendant systems shall allow
the purchasing agency to implement an 'easy out' function that would
allow callers reach a live customer service representative."



Finally, I think it's helpful to be aware of what's referred to as
"dial-through" and "dial-ahead." Support for dial-through means that
users may interrupt a prompt and make a menu selection even while the
prompt is playing. Support for dial-ahead means that users, who already
know what they want, can make menu selections even before the associated
menu has begun to play. As an example of how these features can be
helpful, support for dial-through would allow users with cognitive
impairments to enter a command immediately after the desired option is
presented; support for dial-ahead means that a desired sequence of
commands can be stored in a single memory-dialer location on a phone,
and thereby be accessible with a single button push.



I recommend that support for dial-through and dial-ahead be required in
voicemail, IVR, and automated attendant systems.



Regards,



Paul Michaelis

• Next message in Thread: None
• Previous message in Thread: None