FinalPrototype-Group:Team Megahard

From Cs160-sp08

Jump to: navigation, search


Team Member's and Their Roles

  • Edward Chen:
    • Prototype: Fixed up the submenu to use the spinner to select phone numbers. Re-implemented left and right to change the spinner when not in focus. Populated the menu items from the database. Minor editing in the other sections of the code.
    • Report: Wrote about the evolution and final interface of the Submenu. Added pictures for the help menu and message. Talked about the difficult implementation details for the submenu. Talked about the different techniques of evaluation.
  • Brian Taylor:
    • Prototype: Figured out how to interact with the android's contact databases to actually fill in the data sent between phones. Helped fix buttons on submenu to interact with the databases.
    • Report: Wrote about the evolution and final removal of the Contacts and Call Histories application and the Send Contact interface. Made minor edits elsewhere.
  • Timothy Edgar:
    • Prototype: Wrote approver activity and implemented Gtalk communication. Modified the automatic contact filling from interactive prototype. Implemented the feature help and menu botton in the address book. Help debug various activity and OS issues with launching new tasks and interaction with services and IntentReceivers.
    • Report: Wrote the sections pertaining to approver activity and automatic contact filling. Wrote the Wizard of Oz section.
  • Gary Miguel:
    • Prototype: Figured out how to launch our application after a call ends with a new number. Helped implement the display of pending info requests inside the Contacts List application. Helped debug submenu.
    • Report: Wrote about the evolution and final interface of the Contacts List application. Wrote about what was left out. Wrote (really revised from previous versions) the problem and solution overview, target user group, and tasks sections.

Problem and Solution Overview

The problem we address is that contact management and manipulation on most phones is slow, tedious, and disorganized. Mobile phones require each contact to be added individually, typically on the phone itself. The tediousness of recording relevant details for contacts on the limited interface of mobile devices was apparent in our contextual inquiries. Some users lacked uniformity in their contacts - some had only first names, some full names, and some just nick names. As phones become capable of ever more functions (for example mapping, emailing, instant messaging), the need to have more complete contact information increases. Additionally, we noticed inefficiencies in the contacts application in both navigation of contacts and selecting functions to be performed on them.

Our application addresses the problems we found by creating an automatic contact filling system. When a new number is encountered, the phone asks if the user wishes to send a request to obtain contact information from the new number. Once the other party agrees to release his information, the information is transmitted and automatically inserted into the user's contacts database. Or, a user can receive contacts from another phone if the third party uses our "Send contact" feature.

We also redesigned the address book application to optimize speed and ease of use. The user is by default presented with their contacts ordered by how frequently they call them, but can easily switch to an alphabetical list or search for a specific name. We make it clear that the user can search for contacts by entering characters with the dedicated search box.

Target user group

Our target users all have cell phones. They range in their level of tech savviness and in the frequency with which they call or text people. Our application targets two main groups of users:

  1. Those who don't spend a lot of time managing their contacts, and thus end up with disorganized and incomplete contact information.
  2. Those who do spend a lot of time managing their contacts, and thus have to enter a lot of information manually using the limited I/O capabilities of a mobile phone.

Because our application targets functions that every cell phone user already does frequently, our target user group is very broad. This really means we need to target people who have no technical understanding of the underlying processes, and little patience to learn about fancy new features if using them takes much learning.


In all of our testing, we asked the user to perform four tasks:

  1. Call a frequently called contact. (easy)
  2. Call an infrequently called contact's alternative number. (medium)
  3. Create a contact from a number acquired through receiving a call from that new number. (hard)
  4. Send one contact another contact's information. (hard)

Through brainstorming and contextual inquiries, we identified several common mobile phone tasks that we thought could be improved. These four are the main tasks that we found were difficult to accomplish with many current phones, and so we chose these tasks to test our progress in making a system that is superior to currently available ones.

In order to give the entire exercise a sense of continuity when doing user tests, we wrapped up the four tasks into a short narrative. The story revolved around a fictitious set of friends that the user needed to call and be called by.

Design Evolution

Contacts List

Initial Design (Low Fidelity Prototype)

In the image below, pink indicates highlighting, and grey indicates the content was off-screen, but reachable by scrolling down.


Our interface consisted of a search bar and 3 tabs, each of which contained a list of contacts, each ordered or filtered differently. Only the currently selected tab would expand to show its text label, while the background tabs only had icons showing. To switch between tabs, the user had to focus on the tabs by moving to select it and then pressing LEFT or RIGHT to cycle through the tabs.

To manipulate contacts, the user would highlight a contact in the list on the left side of the screen. After a short delay, a submenu would appear on the right. The user would press RIGHT to move over to the submenu and then scroll up and down to select options (see the submenu section for the evolution of that part of the interface).

To search, the user could enter characters anywhere. The search bar was there only to indicate that searching was a possibility, but we didn't require users to actually have it focused in order to search. Once users entered search terms, the search tab was brought to the foreground with an alphabetically sorted list of matching names. It was not necessary to hit ENTER to conduct a search, just merely entering characters would start the filtering process on the list of contacts by both first and last names.

Revision 1 (Interactive Prototype)

Image:TMH_frequent.png Image:TMH_submenu.png


The major changes made for this revision were:

  • Hint text for search bar: As can be seen in the first image above, the search bar has hint text that says "Search" until the user enters characters. This was done because in our low-fidelity prototyping test, there was some confusion about what exactly the field's function was. Hint text makes the functionality of the search bar more explicit.
  • Pop-up menu instead of side menu: We moved from having a sub-menu show up on the right side of the screen to having a pop-up menu appear when the user presses SELECT on a contact (the pop-up menu for the contact Zach Arys is visible in the third image above). The previous implementation of the double-sided address book confused users as to which side the focus was on, since both a contact on the left and a menu item on the right were highlighted simultaneously. Allowing for the submenu to float over the contacts list also enables the use of the left and right arrows in the address book to change tabs and in the submenu to change phone numbers. The transparency of the submenu shown in the interactive prototype indicates to the user that they are still in the Contacts List application.
  • Switching between tabs: In this version, the tabs were no longer focusable. To switch between them, the user could press LEFT or RIGHT while focus was anywhere inside the tabs' lists. This was only possible once we changed the submenu to be a pop-up menu rather than on the side as before. In the old version, if the user were at the bottom of a list, he would have had to scroll all the way to the top to focus the tabs in order to switch them.
  • Tab labels: In our lo-fi prototype, only the frontmost tab had a text label, whereas the inactive tabs had only an icon. People were confused about the meaning of the icons, so in our hi-fi prototype, each tab has both an icon and a text label.
  • Search: In our lo-fi prototype, there was a search tab that would show the search results. It was brought to the front when the user entered characters. This was confusing and wasteful of screen space because it was a useless tab until search terms were entered. In our hi-fi prototype, we tried to implement search so that it would filter the contents of the "Frequent" and "Alphabetical" tabs. We didn't get it working in time for our class demonstration, but by the time we did our pilot usability studies, the feature was working. See the third image above for an illustration.

Final Version

Image:TMH_address_book_menu_help.png Image:TMH_address_book_help.png

The only change to the interface was to add a "Help" item to the menu (the one that comes up when the hardware MENU button is pressed). When pressed, the user will be presented with an explanation of the automatic contact filling feature. This was done in response to feedback we got in a Pilot Usability Study. A user said that when she's confused and doesn't see any prompting for what to do, she resorts to pressing the Menu button. This is in accordance with Nielsen's heuristic from his list, "Help and documentation".

Because the Contacts and Call Histories application has been eliminated (see Contacts and Call Histories section), the user needs to use Contacts List application to manage automatically filled contacts. The basic interface for the Contacts List hasn't changed, but the added functionality might not be obvious. The automatic contact filling feature is rather novel, and was very confusing to users in testing, and so we explain it in the help dialog.


Initial Design (Low-Fidelity Prototype)


The submenu would first appear on the right side after pausing on the contact for a second. The submenu was reachable from the left side of the contact list by pressing RIGHT on the D-pad. The split was implemented to take advantage of the available horizontal space due to the landscape format of the phone. It contained various options that would be populated based on the available contact information. For example, if an email was not entered for the contact, the email option would not appear.

In order to select other numbers, an “additional numbers” option was be available in the submenu. After selecting this option, another dialog would appear to allow the user to select between a contact's various numbers. The images above illustrate the process of selecting an alternate number.

During our low-fidelity prototyping process, users ran into the following issues with the submenu:

  • Thought that once the submenu showed up by scrolling to the contact, the focus would shift to the submenu so pressing down would mean that they were changing options in the submenu.
  • It was difficult to see all the options so users were unaware that they could scroll to see all the possible options, making it difficult to find some of the features available.
  • Users tried to press SELECT rather than RIGHT to move into the submenu. Later in the tests, we allowed the select button to work as well.

Revision 1 (Interactive Prototype)

Image:TMH_submenu.png Image:TMH_worknum.png

The major changes made for this revision were:

  • Floating submenu: Instead of having the submenu on the side, we made the submenu floating so that it was obvious you needed to select a contact to move the submenu into focus. This was to reduce the confusion on how to enter the submenu. At the same, it frees up the left and right buttons so that pressing LEFT and RIGHT in the contact list would move between tabs. This change meant that the user is unable to simultaneously see both the list of contacts and the options available for a particular contact. However, the user really doesn't need to see the contacts list once they've selected a contact.
  • Left and right to change numbers: With the left and right buttons freed in the submenu by making it floating, the other number button can be removed to reduce clutter, and instead, implementing number changing with the left and right buttons. Arrows next to the phone number and the number type were added to point out that they were in fact changeable via the left and right arrows (see the images above).

Users had the following issues with this design in the pilot usability study:

  • The arrows were not selectable and highly stylized, and users didn’t understand that they could press LEFT and RIGHT anywhere to switch numbers.
  • Users didn’t notice when the number switched, as there was only a subtle visual change.

Final Version

Image:TMHFP_submenu.png Image:TMHFP_switchnum.png


The major changes made for this revision were:

  • Changing numbers with feedback: Rather than just changing a TextView's contents when pressing left and right to change the number, a spinner was implemented to change it with an animation to provide more feedback. Also the arrows on the spinner make it obvious that they can cycle through different numbers. The first two figures show the change in the number and type when RIGHT is pressed.
  • Populate option based on database: Before the options were fixed such that the options were the same whether or not the contact had all the fields necessary for calling, texting, emailing, or mapping. So as not to confuse the user, options which require a certain field in the database to exist will be visible only if that field exists in the database. The third image shows a list of menu options that differs from the other two images; since Bill Gates has an email address entered, the “Email” option exists for his submenu.
  • Implemented requesting info functionality: The "update" button now flags the contact to be updated. If a contact has been flagged as “Waiting for info”, a "cancel contact info" button appears at the top of the submenu to allow the user to cancel the request for contact info.

Automatic Contact Filling

Automatic Contact Filling was the main motivation behind our application. This would ideally be a one-touch way to add a contact. The user would request information from the unknown number and upon approval would get all the information that the user provided, eliminating the need for data entry. This feature does not have much in terms of interaction as it is mostly back-end; however, we needed to describe the process to the user as it isn't a standard feature.

Initial Design (Low-Fidelity Prototype)


As our feature involves a process, we initially wanted to keep it as a short dialogue. We prompted the user (as shown in the above left image) if they wish to add the contact to their address book. Next, we had a screen that showed the progress of the contact retrieval, while giving them the option to choose the standard way of manually entering the contact info. We incorporated our one-touch aspect to contact addition, while giving them an alternate path. The idea was that the status text on the screen (shown above on the right) would change as the process progressed.

Our implementation created a lot of confusion as users did not know what was going on. It gave them little feedback that their actions were successful in creating the contact. Nearly everyone clicked “Manual entry”. Also, the wording of "Hide" was confusing. Users did not understand that this would simply run the process in the background, and the one test case we had that understood the meaning wanted to have confirmation that the contact was added. The ambiguous wording and lack of feedback made us believe that we should break apart the process and explain the various steps, which we implemented in our Interactive Prototype.

Revision 1 (Interactive Prototype)

Image:TMH_saveunknown.png Image:TMH_requestingcontactinfo.png

Our Interactive Prototype grew from the idea that we needed to explain and walk the user through the process for Automatic Contact Filling because it was a process that they weren't used to. We have the same first screen as we see in the top left with minor wording changes. Many users actually expressed surprise at seeing this screen because it was unexpected and pleasant, and they wished that their phone would do that. We changed the button’s text from "No" to "Ignore" so that it was clearer that you could add the contact later from the recent calls application as most phones enable you to do. In the first prototype, there was confusion that clicking "no" would prevent the user from adding the contact later.

The next three screens (top right, bottom left to bottom right) shows our Automatic Contact Retrieval process. We provided detailed information in the three stages of the process:

  • Requesting Contact Information
  • Sent Request
  • Waiting for Approval (by Recipient)

We added the option to cancel the process and to show more detailed information with more buttons. We learned in our usability study that there was too much information with too many options on that one screen, especially since the screen appeared and went away very quickly. Some users didn’t even understand what the “Info” button was supposed to do, and they didn’t get a chance to explore by clicking on it because the screen with 4 buttons was quickly replaced by the next screen with only the “Continue” button.

Image:TMH_requestsent.png Image:TMH_waitingapproval.png

The Waiting for Approval screen above and to the right received a lot of negative feedback. It gave the user conflicted directions. It told the user to wait and yet the button said "Continue." Our users stayed on that screen because they were bewildered and confused from the prior screens and general lack of understanding of what was going on such that they were reluctant to click "Continue," but did so any way because the screen was basically forcing them to with that as the only option.

The expectation of the user was to get the typical manual entry form. However, we sent them through a series of screens that flashed in front of them based upon the state of the process. Since the process doesn't require interaction, the steps flew past the user and confused them, when they really wanted to see whether the contact has been added to the address book or not. The current state of the application leaves them in a quasi-satisfied setting, where they aren't sure if the contact was added to the phone book, but something was done. Typically, users consider a contact added when they appear in their address book, and hence choose to manually edit even after it has requested information.

Image:TMH_contacthistory.png Image:TMH_notification.png

Lastly, since we wanted a way for the users to view and manage pending contact requests, we added a Contact History application to this. Users were brought here after sending an contact request. More details about this can be found in the Contacts and Call Histories section. We did use notifications to bring to the user attention that a contact was updated and added to their address book. This was relatively clear.


Final Version

Image:TMH_Final_Prompt.png Image:TMH_Final_Info.png

From the Pilot Usability Study, we learned that we should simply leave it as a one-touch approach and give them a response that clearly established they accomplished the task.

On the screen right after a call ends, we give the user the option to use our new feature, or to enter the contact the old fashioned way. This created the expectation that it was not a manual entry activity but rather a new feature. The top left screen shows three options, where the user actively knows they are using the automatic contact feature.

Upon reflection, we realized that much of the information we were giving the user was unnecessary. Thus, we replaced the many screens detailing the progress of sending the request with a short notification that the request was sent (see the below right image). We did implement an information page that is shown on the top right. This is shown automatically the first time the user uses this feature. Once it's viewed the short notification is displayed. To note that the contact information is pending, we show the text “(Waiting for info)” after the contact’s name in the Contacts List. The user can edit the contact if he or she wants to add more information or can wait for the recipient to update information.

We eliminated many of the screens and simplified the process down to our desired one-touch approach. We allow the user to read the information through the help menu and during the first time to understand the pending aspect of the application and that they can leave the contact as pending in their address book for the time being. Our system explains to the user that they don’t need to do anything more. The user can be satisfied with the work done and move on to other tasks.

Image:TMH_Final_AutoFirstList.png Image:TMH_Final_AutoSecond.png

Send Contact Information

One important features is the ability to easily share contact information with others. Instead of calling or text messaging a person the desired number, we have a "send contact" feature that allows one to share a contact in the user's address book with another android phone user. The interface has remained relatively simple from the start, but we have encountered numerous issues with our conceptual model of how the process should work.

Initial Design (Low-Fidelity Prototype)

In the original brainstorm, we thought sending a contact would merely involve formatting a special attachment to a text message. Later, to enhance the simplicity and efficiency of the feature in our lo-fi prototype, the "send contact" button was instead added to the person-specific submenu in the address book. From the submenu, one would scroll down to the "send contact" option, which brought up an interface that closely mimicked the address book so that we provide a familiar interface for the person to select the recipient of the information.

After our first lo-fi prototype interview, however, our test user seemed to have a much different mental model. She believed that we should first select the person to send the contact information to, and then afterwards select the contact whose information the user wishes to send. She reasoned that all of the actions in the submenu involve a "from the user, to the contact" conceptual flow. For example I make a call to the contact, or I send a text message to, or even I send an email to the contact. Although this mental model contradicted our own, her articulate explanation convinced us to reverse the process. See below for images of our lo-fi prototype describing the revised process. The pencil marks the focus.



Revision 1 (Interactive Prototype)

After our lo-fi tests, however, we found that some users performed the steps in the original order. At first, we thought that the problem lied in our lack of feedback, so we added toasts and a visible text view to clearly show the current recipient of the send contact info operation. As shown in the image below, we also edited the title bar instructions to better instruct the user on which contact they were selecting (the contact whose info was to be sent or the recipient).


Final Version

After our pilot studies, we ended up reversing the operations again to our original conceptual model since more users found this order more natural. Starting in the address book, the user first chooses the person to send, and then afterwards selects the person to send information to. One of the users explained the reasoning behind it by using the analogy of giving a pencil to someone else. He would pick up the pencil from the desk first and then give it to the person.


Contacts and Call Histories

This application was created after our lo-fi prototypes to allow the user to view a list of their pending contact requests (i.e. requests they had sent out that had not yet been approved or denied (answered)) and to approve or deny various requests from other people for the user's information. Without lo-fi testing and thoroughly thinking through the application, this application ran into severe problems during the pilot studies, and we soon realized the uselessness of this application. In the end, the minimal functionality that the application provided was merged into the address book.

Initial Design (Interactive Prototype)

The interface for Contacts and Call histories application involves two tabs, one for each history. The Contact history tab is supposed to list all of the contact requests sent to other people and received from other people. It was also to include entries for when contacts were added, updated, et cetera. By pressing the menu button, the user would be able to perform certain actions depending on the specific entry. For example, if the entry in the list was of a pending contact request, the user would be able to manually enter information or cancel the request. If the entry in the list was of a record of when a contact was added, the user would be able to view/edit the contact. The call history tab was a list of all of the calls made to and from the phone, which we originally believed was good service to link with the contact histories. Some basic functionality, such as calling the number shown, was available in this tab. When we presented our interactive prototype, the entire application was filled with hard-coded information. Eventually, we were able to pull information directly from that database to accurately fill both tabs. A screen shot of our interface is provided below.


Final Version

The pilot usability studies blatantly revealed the numerous problems with both the interface and the motivation for the application. For one thing, the Call History tab was completely unnecessary, since this information is accessible via the recent calls application, which can be started by simply pressing the green send button. It's similarity to the address book in UI design was also confusing to users as they wondered if the were still in the address book or not. More confusion occurred because this application requires the user to use the menu button to access submenus, while the address book requires the user to use the select button.

We then came to the conclusion that the user does not need a full history of contact requests, but would rather simply scroll through a short list of the pending ones. Thus, we chose to integrate the small functionality left in this application with the rest of the address book. We agreed that contacts that were waiting to be updated automatically should still be listed in the address book so that the user could call them. To support these special contacts in the address book, we simply have a "(Waiting for info)" string appended to the contact's number or temporary nickname (if manually entered) as shown in the image below. This lets the user know that these contacts are still missing information, and that the phone is still waiting for the person to approve or deny the request. Thus, our poorly thought out phone history application was scrapped altogether, reiterating the importance of iteration and user testing. Essentially, we wrote this application completely in high fidelity with no lo-fi testing. As a result, it's poorly thought-out and completely untested design were probably major causes of its downfall.


Usefulness of User Interface Evaluation Techniques

Low-fidelity Prototyping: This evaluation technique was probably the most useful one, primarily because of its simplicity and short preparation time. It was very easy both to prepare and to make changes to the low-fidelity prototype. When a serious error in the interface was discovered during the first user test, we were able to quickly implement changes before the next test. The simplicity of the low-fidelity prototype ensured that the user focused mainly on the interface issues and not on minor asthetic issues. In contrast, during the pilot usability study, users criticized the visual style of the high fidelity prototype. This kind of feedback is less useful, as it is largely subjective. Furthermore, the low-fidelity prototype was able to identify major interface bugs at a point in the design process when they were still easy to fix, without having to completely change the code and revamp the layout. This meant that many interface problems were eliminated before we developed our interactive prototype.

If we had had more time, we would have done more low fidelity testing. For example, after our low-fidelity test, we decided to implement a way for users to view pending contact information requests. Because our next assignment was an interactive prototype, we had to spend a lot of time implementing the Contacts & Call Histories application to get it ready for a user test. As soon as users tested that application, we found it was seriously flawed, and we ended up scrapping it altogether. It would have saved us a lot of time to implement and test it in low fidelity first.

Pilot Usability Study: Testing our interactive prototype with users uncovered many interface problems. Luckily, many of them were very easy to fix. The study found problems that resulted from users doing things we wouldn't have encountered in using the application ourselves.

The pilot usability study was very important clarifying the problems with the automatic contact filling. Since the interface was fully implemented, including timing and animation, users could provide accurate feedback about what was wrong with the interface. We had assumed that the animation available in an interactive prototype would solve many of our problems, but through our usability study we found out that was not the case. We saw users wait on screens not knowing what to do, and we knew this was due to our bad interface, not to the limitations of the a low fidelity prototype. The pilot usability gave us essential feedback on recurring issues, and led us to eliminate our ill-conceived "Contacts and Call Histories" screen.

Final Interface


Our application's most basic function is to let users find and use contact information. Our Contact List application lets users find contacts, and then perform actions on them. Almost all of the actions that are accessible for a contact are actually not handled by our application. Our applicaiton simply initiates contact-specific actions.

For example, the user can use our application to find his friend Joe's entry in the contacts database. He can find him in one of several ways (see next section). Once he finds Joe's entry, the user can call any of Joe's phone numbers, but our application doesn't actually handle the calling. We simply initiate Android's default (very ugly) calling program. Similarly, the user can edit Joe's contact information, but our application simply calls on Android's built in functionality for that. Once more functionality is added to the system, our application will be able to initate actions that are currently unavailable (for instance sending a text message).

One function that our application does handle directly is sending contact info. The user can send one contact's information to another contact's phone. Because of the limitations of the SDK, however, the underlying functionality for actually sending a contact is currently not implemented (see What was left unimplemented). Another function we handle directly is the automatic filling in of contact information. The user can request contact information to be sent directly from the other person's phone, and therefore avoid typing in any information at all.

Our automatic contact filling feature provides a one-touch method of adding a contact. Users simply need to press "Add automatically", and their address book is populated with that contact. Initially, a contact is created without any information, but it is filled once the recipient of the request approves the request.

User Interface Design

Address Book

Image:TMH_frequent.png Image:TMH_alpha.png


To access a contact, a user uses the Contacts List application. The user can view his contacts sorted by frequency with which he contacts them or alphabetically (see the first two images above). Each of these ordered lists is contained inside a tab that the user can switch between by pressing RIGHT and LEFT. If the user enters search terms, this filters the contents of the two lists, but maintains the order of the remaining items (see the third image above). He can enter search terms whether or not the focus is on the search box.

Once a contact is selected, the user can press the CALL button to initiate a call to the default number (shown to the right of the name), or he can press SELECT to bring up a menu of actions that can be performed on that contact.

Image:TMHFP_submenu.png Image:TMHFP_switchnum.png


When the submenu is first brought up, the first item in the list of options has focus. Pressing LEFT and RIGHT allows the user to scroll through the contact's different numbers, but for a list view of all the numbers, pressing UP to put the spinner in focus and SELECT on the spinner brings up a pop-up list of numbers to pick. With the spinner in focus, pressing LEFT and RIGHT still switches between the numbers.

If you press DOWN repeatedly, you can scroll into the list of options based on the availability of certain information for a contact. For example, in the images above, the Email button appears for Bill Gates but not for Jim Jim, since there is no email address available for Jim Jim. Pressing CALL in any place in the submenu calls the number selected on the spinner.

Automatic Contact Filling


Upon a the end of a call with an number that is not in the address book, the user is prompted to save the contact as shown above. The user gets three options - add automatically, add manually, and ignore. Add manually goes to the default contact addition activity in Android. Ignore simply returns the user to the previous thing they were doing before the call. Add Automatically goes to the next screen shown below.


The screen above shows both the message that is briefly displayed and the contact entry created. Since the person at the other end has not approved the sending of contact data, the new entry is a skeleton contact with a note that there is pending contact information. It contains the number and the user can edit the name temporarily to assign perhaps a nickname to keep track of the number until the full information arrives. The user can add more detail if the skeleton contact is not satisfactory.

We have shortened the lengthy and tedious procedure of adding a new contact to one button press.

Send Contact Information

Starting from the address book, the user first scrolls to the contact whose information the user wishes to send and then presses SELECT to access the submenu. In the submenu, the user will select the SEND CONTACT button, bringing up another screen. In this screen, the user must select the recipient of this contact's information. The interface to choose the recipient mimics the Address Book so that we provide a familiar interface to make it easy for the user to find the intended recipient. At the top of the screen, we also included instructions and feedback in the title bar and a text view as show in the images below. Once the recipient is selected, a notification informs the user that the contact information was sent.



Address Book

The address book is split into two sections via the Linear Layout. On the top, there is an ImageView next to an EditText widget for the search bar. On the bottom is a TabHost widget to support the tabs for an frequently-sorted list of contacts and an alphabetically sorted list of contacts.

Each tab runs a managedQuery to search for all people and display their preferred number in a list driven by a simpleCursorAdapter. By selecting a contact with the SELECT button, it launches the submenu with the personId of that contact passed to the submenu so that the proper information can be shown. On hitting the CALL button, the activity calls the preferred number. On typing any alphanumeric character, the dispatchKeyEvent function passes it to the search bar, which filters the contacts shown on the tabs using a specialized query.


The submenu is split into two parts by a relative layout. The first part is the picture and the corresponding phone number and type contained in a spinner. The bottom part is a ListView.

On the start of the activity, the address book has already passed the id of the person to look up in the database to the submenu so the submenu uses internal functions to create cursors for queries on that personId for several different kinds of information. From that, the necessary data is extracted from the database and used to populate the list items. The list items are driven by an ArrayAdapter. The addition of each list item checks the whether the relevant data is present in the database and if it is, it is added to an ArrayList, which is later converted into the array that the ArrayAdapter is created from. That same array is used to map the position of the ListView to the list items so that onItemClickListener knows what item is being selected and runs the appropriate code to handle that item selection.

Other parts necessary for the proper functionality of this section was properly filling the dispatchKeyEvents function such that pressing LEFT and RIGHT while not focused on the spinner also changes what number and type is shown on the spinner by passing the event to the spinner's onKeyDown function. Furthermore, it also handles the pressing of the CALL button anywhere in the submenu to call the number listed on the spinner. Finally, there is a line to terminate the activity in onFreeze such that the state of the activity is not saved when resumed. This is to get around the bug in which when an activity is launched from the submenu or another activity interrupts the submenu, on restore, the underlying address book activity is no longer present and the submenu is floating over a tiled background.

Automatic Contact Filling

Automatic Contact Filling consists of one main activity. The activity starts with a view consisting of the user prompt to save the contact information. The automatically add button creates an entry in the contact database with basic information and a note that the contact is pending. The manual entry button starts the Android built-in contact adding activity with the number field populated with the unknown number. The ignore button finishes the activity, thus returning the user to the previous activity.

After the contact is created with the automatically add button, it goes to either the information activity or the address book. On either path, a toast appears to tell the user that a contact request was sent. The information activity is launched when the preference for the HelpWizard is not set. If the preference does not exist, which occurs when the phone has never seen the information screen before, the main Automatic Contact Filling activity will launch the information activity. The information activity would simply start the address book activity on Continue.

We passed the personId of the contact along with the intent to highlight the recently added contact by setting focus to it, but set focus does not work currently.

Approver Activity

The approver activity extends from the API GTalk demo. The Gtalk demo sends a static message to another Gtalk user on an Android phone. Our approver interface activity will send a message to the recipient Gtalk user containing the relevant fields stored in the intent as extras. Our approver activity uses a simple interface with contact fields and button to submit. This activity is not something the user should see.


The GTalk receiver will pick up the intent and pull the fields from the intent. We pass the fields and the intent along to another receiver that updates the contact. While we could combine both receivers, this was done for modularity and testing each component.

The Contact Update receiver will pull the data from the intent and add or update the fields. It is assumed that this is the contact add message so fields are overwritten. Once the IntentReceiver successfully updates the contact, it starts the service of the Contact Updated notification on the top bar. The Contact Notification extends from the API demo also as it simply creates a notification manager and very simple notification that lasts for a few sections. This was done since notifications will last until the service stops it. Since we can't clear notifications through the current android interface, we simply had it last for the message prompt (the icon did not remain).

Catching Unknown Call

We wanted to launch our CallEnd activity when a call ended with a number that was not already in the address book. We had to use an IntentReciever that keeps track of phone state changes and checks the phone’s CallLog ContentProvider. When we noticed a new number that was not associated with a contact entered the database, we started our CallEnd activity that prompted the user to save the number. We passed along the number with the intent as this was the major problem with our original implementation in our interactive prototype. The telephone variables do not contain any information about the call, however the Android CallLog stores information about the call, which we could access.

Contact Database

Fortunately, all of the tables for storing contacts and their information was already set up by Android. So instead of creating our own database to interact with, we simply used the one that already existed. Interacting with the database is achieved through various cursors, which are simply iterators or managers over a result set from a query of the database. At various times, we would query a different one of the three contact-related tables: People, Phones, and ContactMethods, depending on the information we wanted. For example, to obtain person-specific information such as company, photo, name, we would query the People Table. To get email and postal address, however, we would query the ContactMethods table. One of the more tricky aspects was that all of the tables inherited many values from the other tables, but one needed to have a cursor to the correct table to update information. One could get a fair amount of information (including phone numbers and email addresses) by querying the People table, but to alter a person's numbers or email, we had to query the Phones table or the ContactMethods table.

Difficult Parts of Implementation

Some very challenging features to implement were:

  • Searching: To make sure that searching terms were sent to both the search box EditText and the lists inside the tabs (not matter which was currently focused), Gary had to dig deep into how Android handles dispatching of key events. Also, tabs are implemented in android in such a way that each tab contains its own activity. Thus, from the enclosing TabActivity, it is difficult to communicate with an enclosed ListActivity. Once he finally figured out how to capture and redistribute keypresses, and then how to pass them to the ListViews, he had to figure out how to filter the lists based on the search terms, which involved learning some SQL commands.
  • Activating an activity after a call ends: The Android OS broadcasts intents that say the current state of the phone, but the intent doesn't contain information about what the previous state was. Also, the background process that listens for these changes (an IntentReceiver) can't keep any internal state, so it couldn't keep track of what the last state was. Thus, when a phone call ends, the phone's state goes from OFF_HOOK to IDLE, but we could not just launch our "after call" activity when the phone went IDLE, because when a new phone call is received, answered, and hung up the phone's state goes from RINGING -> IDLE -> OFFHOOK -> IDLE. Our final solution involves checking the phone's CallLog database every time the phone state goes to IDLE. If there is a recent phone call that doesn't correspond to an entry in the Contacts database, we launch our post-call end activity. This took a lot of work to come up with.
  • Populating submenu items from database: So as to not confuse the users with buttons that did nothing, in the final version, the list of buttons was populated depending on whether certain fields existed in the database. What was difficult to implement was first mapping the text the position because unlike a fixed list, the list of options could vary and the position of them on the list will be different from each user. This was finally implemented properly with a lookup array that mapped position to menu item. The second difficulty with this part was checking the existence of some of the fields as the indication for the lack thereof differed for each field. For instance, the lack of a photo meant that the field was null, but the lack of numbers meant that the cursor was empty. Retrieving a field such as email required a different Content URI and different filtering just to check whether a data field contained an email or not.
  • Providing Dynamic Content to Background Processes: Services do not have the getIntent() method nor have an intent in their constructor. Thus, services are unable to get data that is passed along with an intent that started the service. There are methods to stream information to the service once the service was started, however this was poorly documented and seemed rather complicated. We used IntentReceivers to do as much work as possible for background processes since they could read intents and manipulate the database. However, for notifications which are implemented through services, we were unable to provide dynamic information.
  • Setting up GTalk: The GTalk service has gone changes through each of the SDK revisions and there exists conflicting documentation. The latest version requires users to log in through the XMPP setting in the dev tools. These users must be buddies and real accounts. The API demo was poorly documented in setting up the emulators to support GTalk. There lacked any support for SMS features since the telephony was locked so we were stuck using GTalk. There is a long list of steps to set up the emulators for our program (which took a considerable amount of research due to the lack of documentation):
    • Launch two emulators by setting the Target tab in the Run Dialog (Devices -> Manual , Run Option -wipe-data for the initial run).
    • Once both emulators are running, go to Dev Tools and then XMPP
    • Sign into two gmail accounts that are buddies with each other on the two emulators. Note that the password protection is quite poor.
    • Run GTalkContactSend on the emulator that simulates the approver. Type in the gmail address of the other phone and any relevant data of the contact to be added.

What was left unimplemented

What was left out and why

The main thing that was left out was the approver side of the automatic contact filling procedure. We envisioned that our final application would include an interface for being notified about requests, and then approving or denying them. We would want to support multiple profiles, so that a person could send say only their first name and mobile number to someone they meet at a bar, or all of their contact info, complete with picture, email address, and custom ringtone to their relative or close friend. Handling all of this would have nearly doubled the size of our interface (in terms of screens and tasks), and we just didn't have time to implement it, much less test and revise it.

A few minor things we would have liked to have implemented are:

  • We couldn't figure out an easy way to hand information to the status bar notifications dynamically. We would have liked to say the name of the contact that was updated, but instead we just say "contact updated".

Any Wizard of Oz techniques that are required to make it work

  • Gtalk Communication - We used Gtalk to send our contact information from phone to phone. This is not ideal as you need to log in as two separate gmail accounts that are "buddies." It is very unclear how to add buddies to gmail, where on future use you recognize inviting to chat mean adding to one's buddy list. Since we have to set up both phones and telephony is rather locked (unable to use SMS or other communication methods), our application does not work with two unknown users. We can simulate the effect of communication and do have dynamically driven communication. As the approver, we used a interface that simply had a series of input boxes for the contact fields and transmitted it across the phones through Gtalk. Gtalk can easily simulate the request and sending of the contact as we simply send a different message. However, again we would need to send an unknown user that is somehow one's buddy the request. Given a different communication protocol such as opening up SMS and more telephony options, we could not run into this conflict. Gtalk will work for any testing purposes.
  • Update Contact - Since we have to simulate the other user in our usability studies, we pretended to be the other user and gave ourselves an easily modified profile submission. Instead of having a set of fields to send, we would have a profile and receive notifications to approve.
  • Simulating the other user - We only focus on the tasks we listed above. We provided tools to simulate the user; however, the user needs to know more information of the test phone (such as when a request is made). Only one side of the application is implemented. Since Gtalk requires considerable amount of set up with buddy e-mails, the other user will be someone that has more information than typical in the ideal sense of this application (two unknown users). Thus, we were justified in role-playing the other user.


Source Code


Final Presentation

[add comment]
Personal tools