Interactive 2

Farmers' Exchange Interactive Prototype #2 Team: Matt Gedigian, Jessica Santana, Joyce Tsai

Project: Farmers' Exchange

Sessions: 4/7 11:00-12:00 • The Berkeley team went over changes to the "ask a question" phone tree per feedback from the first round of user testing, Neil's input, and the heuristic evaluation. 4/9 2:00-3:30 • The Berkeley team discussed implementation of the "browse" function for the phone tree. 4/12 7:00-9:45 • The Berkeley team further discussed implementation and brainstormed experiment design. 4/13 3:00-3:30 • Matt, Joyce, and Neil discussed the experiment design and the interactive prototype over the phone.

Contributions: All: Brainstormed outline of the "browse" phone tree. Determined what to change in the "ask a question" phone tree. Matt: Voxeo, VXML Jessica: Testing and refining interface. Joyce: Diagramming specific flow of interface. Testing and refining interface.

Changes Made The group that evaluated our project did not provide severity and fixability ratings, but they highlighted three major issues. Logged heuristic: Heuristic

Location

Error prevention

When recording new question

Description Have to remember to press # after recording a question, or else system will replay prompt and when # is pressed after the replay the system assumes no question was recorded.

Severity

3

Fixability

2

Sum

5

Fix

Have system recognize when user has been speaking but might have forgotten to press #

Original quote: The most important issue we identified causes the system to lose a message that the farmer has been actively recording. Before leaving a message, the system informs the farmer that he or she must press the pound key to complete their message. In the event that the farmer then records their message and forgets to press the pound key, the system will replay the reminder to press the pound key after leaving their message after a certain amount of time passes. The farmer then would probably press the pound key expecting the message they just left to be saved. Unbeknownst to the farmer, when the system replays the message, it also resets anything that has been recorded and starts recording a new message. So when the farmer presses the pound key just after hearing the reminder, the system will store a blank message. This is an important issue to fix in order to prevent errors on the part of the user. Sufficient technology exists to perhaps have the system recognize when the user has been silent for some time and make the prompt a real prompt rather than a reset indicator.

The first issue is the system losing a message the user has been recording. In our first interactive prototype, if the user did not provide a valid response or if the user simply provided no response, the system would automatically repeat the prompt without saving any data. When the user recorded a question, the system prompted them to press the pound key at the end. If the user did not press the pound key, the system would automatically repeat the prompt without saving the user's

question. Then, the user either pressed the pound key without leaving any question, or the user had to repeat the entire question. We changed the system so that if the user forgot to press the pound key, the system would simply wait for a pause of a certain length, and then repeat the question back for confirmation. This way, the user would not have to go through extra effort if they forgot to press the pound key. Since nearly all our users did not press the pound key during testing, this is a more optimal solution that lessens user error and does not prompt the user for more information. Logged heuristics: Heuristic

Location

Description

Error Prevention

When first calling system

Called into system and had to key in phone number number

Help and Documentation

When first calling system

New user calling system for the first time, or after some time and needing more information

Error Prevention

Called into system and had to key in phone number number

Severity

3

4

3

Fixability

2

2

1

Sum

Fix

5

User caller ID to repeat number and give user a yes/no option to accept as their number.

6

Minor issue, but system could user caller ID to indicate user is using system for the first time and walk them through more of an explanation

4

User caller ID to repeat number and give user a yes/no option to accept as their number.

Original quote: In addition, other prompts for information could be simplified by using Caller ID to allow the user to authenticate from the number they are calling from. In the case of initial mailbox setup, if most users will probably be using the phone they use for setup for receiving notifications, adding caller ID to detect the phone number the user is calling from would greatly simplify the setup process.

The second issue identified in the heuristic evaluation was that the system could not recognize a user's phone number. In addition, comments from the project lead in Stanford (Neil) emphasized designing for the majority of scenarios, as opposed to edge cases, such as one person using several phone numbers, or several people using a single phone number. Because of this,

we decided that assuming a one-to-one person-to-phone relationship was reasonable. As such, the second interactive prototype stores the user's phone number in the database when the user asks a question. The phone number is automatically tied to a voicemail box, allowing the user to call back from the same phone and retrieve any messages without having to log in or confirm their phone number. This may need to be changed once the system is more robust and has more users. Logged heuristic: Heuristic

Location

Description

Flexibility and efficiency of use

While notifying user of answered question

Have to call the system back after it calls to notify you about a new answer; seems awkward to have to remember number for mailbox

Severity

Fixability

Sum

2

1

3

Fix Perhaps have the answer play when the system calls and store it in the mailbox for later, or explore the ability to prompt the user to play the message during the notification call

Original quote: Also, the notification of a message requires them to hang up and then call back instead of just giving the user the option to hear the message immediately. It would be reasonable to have the system play the new answer when it makes the notification call to the farmer; those users who would be frustrated by having to call back would remain happy and those who didn't have time to listen to the message could call back to the system any time.

The third issue identified in the heuristic evaluation was associated with how the user accessed the answer to their question. In the first prototype, the system would call the user when their question had been answered. The user would then have to hang up and call the system back to retrieve her message. This was also identified as an issue in our user testing. A future prototype will change the system so that the user can press a key when they receive a call from the system and directly access their answer. However, if the user does not wish to hear their answer at that moment, they also have the option of calling the system back and retrieving the answer from their voicemail. This feature will not be implemented in the current prototype, although it is planned for future prototypes. Further changes we made include adding the "browse" section,

streamlining the voicemail system, and taking out the global help system. The browse system will be the most unfamiliar part of the system to most users, as it differs most from a normal phone tree. As such, we will have two separate versions for testing. However, only one version will be complete for this assignment. The version for this assignment searches for questions and answers based on audio tags. The user can say several singleword tags, such as "organic," "heirloom," and "tomatoes," and the system will "AND" the tags and use it to find related questions and answers. The user can then listen to the first five seconds of each question, along with the associated audio tags. If the user decides that the question is helpful, they can "click" on the question by pressing a key and listen to the entire question and answer. The second browse system, to be developed later for the experiment, will be a hierarchical browsing system, in which the user will listen to a tree of tags. If a tag seems helpful, the user can press a key and browse down a level until they reach questions and answers. We also streamlined the voicemail system, taking out options for archiving and deleting. Although more robust voicemail functions will be useful in the final product, we decided not to code them into the interactive prototype because of the time involved. Similarly, we removed the global help system, as the system is not yet final enough to determine what exactly the users will need help with.

Tools Used The system is implemented in VoiceXML 2.1 and is hosted by Voxeo (http://voxeo.com). The final version of our system will be largely database-driven. We were faced with a decision as to how much of that engineering work to incorporate into this second Interactive Prototype. Some of the prototype's functionality can be achieved perfectly well by hard-coding values. For interactions in which the caller is only accessing existing information, it is possible to bake in sample data by hand writing VoiceXML files. We implemented database driven behavior only when necessary to create the interactions we needed to test with users.

We implemented the backend of the system in PHP. This serverside application accesses a SQL database to dynamically generate VXML. Although not all pieces of the front-end interface are driven by the database, we did design a complete database schema in order to make progress towards our overall goal. We adopted a partial implementation from Stanford folks who used MySQL. For convenience during testing we have transitioned to SQLite3. This is a file-based database which doesn't require a server. SQLite3 supports a subset of SQL that is adequate for our purposes. We intend to transition back to MySQL for production use.

Instructions for Prototype The prototype hosted by Voxeo and can be reached by regular phone (or Skype or SIP). Number Type Direct Local # Skype VoIP SIP VoIP

Number (650) 273-5551 +99000936 9991428574 sip:[email protected]

1. The system's behavior depends on whether the caller has previously left a message. 2. If so, they are prompted to check their voice mail. The voice mail menu allows them to listen to their questions and answers. 3. All users are given the option to ask new questions and to search or browse for existing questions and answers. 4. Asking a question allows the user to record a spoken question. 5. Search allows the user to speak a keyword to obtain a list of matching questions. 6. Browse presents a fixed list of topics and allows the user to select among them using their keypad.