Final Functionality Documentation

Team Members: Drew Blaisdell (10 points), Jace Morrison (10 points), Kassia Wilhelm (5 points), and Nathaniel Williams (5 points)
Task: The team will make changes to the documentation of application functionality, based on team member and example interested person feedback.
Deliverable: A final documentation of functionality.
Milestone dates: 5/22/2014 – 5/30/2014

Android

One part of the application is a documentation showing how the product functions. This functionality documentation describes what the application does, including the service overview, the functions of the web application, and the functions of the Android application. The documentation also shows sample images of the application during use.

People interested in the application can read the functionality documentation to learn more about it, and to preferably be more interested in using it. The documentation provides a more detailed overview of the application compared to other promotional material such as the application poster.

During this time, the group (Drew Blaisdell, Jace Morrison, Kassia Wilhelm, Nathaniel Williams) is also working on product branding, which involves how the product is seen by and promoted to the user.

Below is the introduction portion of the documentation:

Logo

“Whitelist is a service which allows users to handle incoming phone calls in different ways depending on if the caller is known or unknown. People today should not have to be bothered by calls from solicitors and other unwanted calls. This is especially important to high-profile individuals, who are often forced to change phone numbers if theirs is disclosed. While most smartphones today allow users to block – also known as blacklisting – specific numbers, this solution is clearly inconvenient, suboptimal, and, as a result, rarely used by users.

Instead of blacklisting, Whitelist utilizes the opposite strategy. The service allows specific – or whitelisted – numbers to go straight through to the user’s phone and handle unknown numbers in a matter specified by the user. The Whitelist team, along with the users who have tested our service, believe it is a superior solution to blacklisting and can be very valuable to users who are sick of being disturbed by unwanted calls.”

The whitelist documentation can be found here:  WhitelistDocumentation

Product Branding

Team Members: Drew Blaisdell (5 points), Jace Morrison (5 points), Kassia Wilhelm (10 points), and Nathaniel Williams (10 points)
Task: Team members will determine the final branding of the whitelist application, including the use of the determined product name, and any themes present in the application, documentations, and presentations.
Deliverable: An overall guide to how the product will be branded for internal and external viewing.
Milestone dates: 5/22/2014 – 5/30/2014

1

One of the major aspects about an application is how the application is presented to potential users and other interested people. Our group has kept this in mind as the whitelist application was developed.

Previously, we chose the name “Whitelist” as our final product name, which was the same as the working  name. The application name is important because it can help convey what a product does to the user, and the name can serve as a type of branding.

The branding and theme found throughout the application and its related documents should be of a relatively consistent nature, and be an expression of the nature of the application and its name. With final work on the application occurring during this time, we have concluded how our product should be branded.

Given that the application would be significantly used on mobile devices, a more simple branding is the preferred option, due to the requirement of having the application be succinct in understanding when it is being used by users on mobile devices.

2

Our product would have a more simple & clean branding, which would work well with the constraints of a mobile application, and would allow for more focus on the content and function of the application. This branding style would be found on both the application and on the presentation poster and other related documents.

This branding style can be found on the poster, with a clean and “minimal” format which allows it to focus more on the content and text, instead of relying on additions which do not necessarily add to the content. The poster makes use of sans-serif font and “light” title text, as well as a limited use of color outside of images. This branding style and variants would be found throughout the rest of the application.

During this time, the group is also working on a functionality documentation, which explains the functions and operations of the product.

Choosing an App Name

Team Members: Drew Blaisdell (5 points), Jace Morrison (5 points), Kassia Wilhelm (10 points), and Nathaniel Williams (10 points)
Task: Determining a name for the whitelist application, replacing the working name previously used.
Deliverable: An application name to replace the working name.
Milestone dates: 5/2/2014 – 5/21/2014

During the course of application development, we have used the name ”Whitelist” as the working name of the application, on the basis that a final application name would be chosen toward the end of development. With final publications of application information occurring during this time, we have concluded choosing of the application name.

Final application names our group considered were:

  • Whitelist
  • WhiteList
  • WhiteLister
  • ClearList
  • GlassList

The names were narrowed down to Whitelist/WhiteList and ClearList, with Whitelist being the name chosen. We chose this name due to being the same as the generic term whitelist, which is not a well-known term according to people who have questioned about and tested the product in the past.

ClearList was the second choice for naming the application, since it avoided using the generic term by being more of a brand name. However, it is not immediately apparent to interested users on what the application does with that name.

The application name is important to determine because the name can help convey what a product does to the user, and the name can serve as a type of branding. Additionally, the name can distinguish different apps from each other when necessary, which was not a major issue in this case.

Pronunciation of the application name is also a factor in a name, and names with less syllables is more widely preferred. Most names considered had two syllables, and one had three syllables.

During this time, the group members (Drew, Jace, Kassia, and Nathaniel) are working on a draft functionality documentation, which explains the functions and operations of the product. This document would use the application name chosen from the process described above.

Afterwards, the name will be used in future works such as the final functionality documentation, to be done by the group members (Drew, Jace, Kassia, and Nathaniel) after the draft is completed.

Product Demo Testing

Team Members: Drew Blaisdell (5 points), Jace Morrison (5 points), Kassia Wilhelm (10 points), and Nathaniel Williams (10 points)
Task: Testing of the product demo for bugs and other issues, before showcasing of the demo. Any issues would be fixed.
Deliverable: A tested product demo with information about the testing.
Milestone dates: 5/2/2014 – 5/15/2014

Previously, a demo was created for pitching our product to people who may be interested in using it. To demonstrate the utility of Whitelist, we modified our application and determined a user flow for potential users. The demo shows off Whitelist’s UI as well as what a person calling a Whitelist user might hear on the other line.

To ensure the functionality and reliability of the whitelist application, we tested the product demonstration for bugs and other issues, and kept track of what worked and what didn’t work.

We put our demo through various tests to make sure that all of its features are functioning properly. The results of the test are detailed below:

Test

Expected Behavior

Observed Behavior

Test Result

Logging in with correct credentials

Grants access

Grants access

Pass

Logging in with incorrect credentials

Denies access

Denies access

Pass

Adding number to whitelist

Number appears in whitelist and calls are accepted

Number appears in whitelist and calls are accepted

Pass

Adding number to whitelist via Android post-call dialog

Number appears in whitelist and calls are accepted

Number does not appear in whitelist and calls are not accepted

Fail

Deleting number from whitelist

Number is removed from whitelist and calls are handled appropriately

Number is removed from whitelist and calls are handled appropriately

Pass

Logging call history

Log is added

Log is added

Pass

Rejecting unknown calls

Calls are rejected

Calls are rejected

Pass

Rejecting unknown calls with message

Calls are read the specified message and rejected

Calls are read the specified message and rejected

Pass

Forwarding unknown calls

Calls are forwarded to the specified number

Calls are forwarded to the specified number

Pass

Accepting unknown calls

Calls go through to the linked phone number

Calls go through to the linked phone number

Pass

Accepting known calls

Calls go through to the linked phone number

Calls go through to the linked phone number

Pass

Known call Android post-call dialog

Dialog does not appear

Dialog does not appear

Pass

Unknown call Android post-call dialog

Dialog appears

Dialog appears

Pass

As the table shows, all of the tests were successful with the exception of adding numbers to the whitelist via the Android application’s post-call dialog. This is a feature that we have yet to successfully implement. However, we plan to have it functioning properly within the next few days.

Overall, our demo is functioning at a high level and does not have any major bugs.  What we have built is thus far will be able to provide a high-quality demonstration and proof-of-concept of our service to the capstone audience.

After this, all team members (Drew, Jace, Kassia, Nathaniel) will be working together on the Draft Functionality Documentation, which would involve creating a documentation of application functionality, explaining how the product works. This is planned to be finished on May 21.

Presentation Product Demo

Team Members: Drew Blaisdell (10 points) and Jace Morrison (10 points)
Task: Reference and clarify key user flow and create a demo for Capstone presentation to demonstrate it.
Deliverable: A demo for presentation of the product.
Milestone dates: 4/25/2014 – 5/8/2014

When pitching our product to people who may be interested in using it, we will their attention for very long. In order to demonstrate the utility of Whitelist to attendees of the Capstone event, we have modified our application and determined a user flow that will serve as a demonstration of Whitelist that we can show to potential users. This demo shows off Whitelist’s UI as well as what a person calling a Whitelist user might hear on the other line.

Imagine you approach our table at the Capstone event. After giving you a short pitch about Whitelist, we ask if you would like to see a demo of the product. You agree, and we show you our test phone with the following screens.

First, we take you to a (a) log in screen where we log in with a new test user.

1

We enter a username and password for a preexisting account so as not to waste time showing you how to register. You now see the (b) options for handling rejected calls.

2

We ask you which message you would like rejected calls to hear, and you reply “I’m testing Whitelist at the Capstone event!”. We save the settings, and ask you to call our phone number. However, because you are not on our whitelist, you hear your message read in a robotic voice.

Finally, we want to show how seamless the experience is for a user who is on another user’s whitelist. We proceed to the (c) Add phone number screen.

3

After adding your phone number, your number appears on (d) the whitelist below.

4

We ask you to call our phone number one more time, and you no longer hear the rejection message. Instead, our calls are connected, and you understand how to use Whitelist.

Determining this user flow was easy after talking to users. We decided that we wanted our demo to show what happens to both accepted and rejected callers, because this is a concern people we tested Whitelist with had in the past. Creating this demo helped us understand what we and our users thought the main features in Whitelist are.

This milestone helped advance our capstone project because we made improvements to the user flow of our application that will make it easier for new users to set up their whitelist. While our priority with this milestone was to create a user flow to demo our product, a lot of the changes that we made to our application to accomplish this priority ended up as changes to our application itself. For instance, we have a user accounts system now. We also understand our users’ needs more after creating this demo, because the nature of this milestone forced us to prioritize them.

For this milestone, Drew worked on modifications to the web application, including the creation of a user accounts system and a refactoring of the key user flow. Jace worked on modifications to the Android application that frames this web application, including changing the User-Agent information sent to the web application and the viewport size.

User Testing of VoIP

Team Members: Kassia Wilhelm (5 points) & Nathaniel Williams (5 points)
Task: Conduct user testing of the VoIP feature in the web application, and find inefficiencies and gather feedback from user tests.
Deliverable: A report of the user’s experience as well as an interview.
Milestone Dates: 4/25/2014-5/1/2014

Our whitelist application includes a VoIP (Voice over Internet Protocol) feature in the web application. Voice over IP involves the transmission of voice communications over internet infrastructure, instead of telephone and other telecommunications infrastructure. In many cases, internet and telephone infrastructure are one and the same, but Voice over IP uses internet protocols. Our whitelist application relies on the internet for proper function, while having to work with telecommunications in regards to calls and text messages.

Since development of the whitelist application involves testing of the portions and sections of the application, testing of the Voice over IP function is one of the necessary portions of the project. Tests would be done on the function by way of user tests, in a similar manner to user tests done previously in this project.

First, the Voice over IP function was tested by Kassia and Nathaniel, the people who are facilitating the Voice over IP testing. Later, the function was tested by Drew and Jace, the people who worked on developing the function. Tests from both two groups were considered to be successful, with the Voice over IP function working as intended with no apparent issues.

This project allows us to move toward making finalizations on our whitelist application, and helps test portions of the “back-end” of the application. Nevertheless, tests will continue to occur throughout the rest of the project. This is because our application requires multiple tests due to the environments it would be used in, the information being handled, and the infrastructure used to support it.

After the testing results are applied to the Voice over IP feature, current plans are for Drew to help create a presentation product demo, which would provide a user flow for uses of the application, and help provide a demo application for presentations. Jace would work on the same tasks as Drew and help create a demo.

Afterwards, Drew and Jace will help do further work on the demo and help test it before being presented to others. Kassia will also work on finalizing the demo with testing. Additionally, Nathaniel will help work on the demo and with testing. These demo tasks are planned to be completed within the next few weeks.

Call History

Team Members: Drew Blaisdell (5 points) & Jace Morrison (5 points)
Task: Implement a “call history” in the web application that records all activity over the secondary number.
Deliverable: The source code of a working application that implements this feature.
Milestone Dates: 4/11/2014-4/24/2014

In order to give users a fallback system in case our whitelist blocks wanted numbers, we needed to implement a “Call History” feature that keeps track of the phone numbers that attempted to contact them and the result of the phone call. We created a table in our database that associates with the whitelist table and represents all calls that were made to that whitelist’s phone number.

CallHistory

This feature helps our users see phone numbers that attempted to contact them when it is convenient for them (rather than distracting them with unwanted phone calls). Without this feature, users would be unaware of whether or not they missed important phone calls. While being distracted is bad, users would find our product to have a net-negative effect if our whitelist blocked important calls without telling them. The Call History feature fills the same role as a Spam folder, and is a failsafe against missing important calls.  
 
Our user testing has revealed that users are more comfortable with interfaces that mimic designs with which they are already familiar, and the Call History feature is another attempt to mirror popular designs. The call history list automatically paginates when it becomes long and is sorted just like iOS or Android sorts phone calls, reverse-chronologically. By showing just the phone number, whitelist result, and date/time, we keep the interface simple enough for users to understand even if they have never used our whitelist before.
 
The development of Call History also helps us with our Android integration. In order to determine whether or not to add a phone number to the whitelist, we needed to keep track of all phone calls and create an API endpoint for adding these phone calls to the whitelist. While we are still working on Android integration and creating this endpoint, the Call History feature has code that can be reused when we integrate Android functionality into our application.
Drew worked on the portion of the app that affects the front-end of the web application and Jace worked on the part that will be used in Android integration. Both worked in the Ruby on Rails codebase.

User Feedback

Team Members: Kassia Wilhelm (5 points) & Nathaniel Williams (5 points)
Task: Conduct user feedback surveys/interviews.
Deliverable: Information about user feedback.
Milestone Dates: 4/1/2014 – 4/17/2014

Twilio

Since the previous user testing, the application had slight modifications done to it based in initial user feedback, and had planned improvements from development. Due to these changes, we have considered it necessary to have additional testing done on the application, using informal methods which are flexible for testers using the product.

Building on the user testing previously done on the application, we conducted further tests on the application with further input from others. The web application was previously tested by all four team members, and the team members tested the app again, as well as tested them with others.

Similar to last time, the people conducting the user tests (Kassia & Nathaniel) tested the revised application first, and the main application developers (Drew Blaisdell & Jace Morrison) did further tests on the application. This allows for preliminary application testing before sample user testing, ensures reliable application functions, and encourages better user feedback.

Additionally, we conducted informal user testing with other potential anonymous users. These users interacted with our current iteration of the application, and we worked with the users in finding out the strengths and weaknesses of the current application.

Based on the additional tests done by the group members, the current web application for the whitelist app remains adequate based on current progress and design & development goals. Users were approving of how unknown phone numbers automatically led to a prompt by the application, and added that an option should be made more available that would bypass the prompt screen, or could be toggled on/off.

Testing has highlighted other minor areas of improvement in regards to the user interface, and will be taken account of in future development. From the results of this testing, we plan on making further adjustments on the application on top of the planned development being done.

Testing of the web application during the design phase is necessary for an effective product, and our whitelist application requires multiple tests due to the environments the application would be used in, the infrastructure used to support it, and the information being handled. With the results from the testing phases, the application and its parts can be improved further so the product can be more effective at its goals.

Current plans are to have the developers (Drew & Jace) further refine and work on the application, with an associated milestone related to the whitelist functionality being finished in one week. The product testers (Kassia & Nathaniel) will facilitate further tests on the Voice-over-IP feature in the web application, with an associated milestone being finished in two weeks. Further tests by group members and others will be ongoing until the finish of the project.

Web Application Changes

Team Members: Drew Blaisdell (5 points) & Jace Morrison (5 points)
Task: Make changes to web application based on feedback, to improve usability.
Deliverable: The improved source code of the web application.

The most common feature that has been requested for our web application during user testing has been to give more control over what happens to rejected phone calls. Some want the ability to give a message that lets their callers know why they are being rejected; others want the opposite and want the call immediately rejected. We created a menu to allow users to update these settings and determine how the application handles calls not on the whitelist.

Screen Shot

Users can now reject calls immediately, forward then to another phone number, or have our application read a message to the user before hanging up. There were users that wanted their callers to know they were using a whitelist and users that did not want their callers to know they were using a whitelist, and this implementation will accommodate both cases. Further user-testing will reveal more about how users use these options, which will in turn reveal more about why users would use a whitelist.

Internally, our Ruby on Rails application is using the user’s input in the settings menu to generate TwiML, the Twilio Markup Language. TwiML is a simple XML scripting language. When Twilio sends a request to our server with the caller’s phone information, our application responds with TwiML that is generated based on the settings the user determined in the settings menu.

Also, we have been able to use ngrok (https://ngrok.com/) to expose our local server to Twilio on the internet. This has allowed us to test Twilio without deploying our application to Heroku, which has made our workflow easier.

(The source code is attached here)

Web Application Testing

Team Members: Kassia Wilhelm & Nathaniel Williams
Task: Conduct user testing with the web application
Deliverable: A report on the experience with the application.
URL for this deliverable: http://frozen-taiga-3927.herokuapp.com/

Twilio

Testing of the web application is necessary for an effective finished product, and our whitelist application requires multiple tests due to the environments the application would be used in, the infrastructure used to support it, and the information being handled (phone numbers, text messages, voice messages, etc.).

The first people to interact with the web application for testing purposes were the people conducting the user tests (Kassia & Nathaniel). This allows for preliminary testing of the web application before testing by sample users. Additionally, having the test conductors test the application shortly before sample user testing ensures the questions are relevant, and the questions would best collect information from sample users.

The next people to test the web application are the other group members (Drew Blaisdell & Jace Morrison). While the applications and interfaces have been created and developed these other group members, having additional tests done shortly before sample user testing ensures reliable application functions and better user feedback.

Test results from all group members are compared and contrasted with each other to find similarities and differences. The different backgrounds and skills of each group member allow for different perspectives and information. Any needed changes to the web application and to sample user tests are done afterwards.

Based on tests done by the group members, the current web applcation for the whitelist app appears to be adequate based on current progress and design & development goals. Testing has also highlighted some areas of improvement, which would be done as development progresses. Future tests conducted on other parts of the application will be useful for improving those other parts.

Current plans are to conduct tests and collect information from other sample users. These tests by group members and others are planned to be ongoing until development of the whitelist app finishes, and results from these tests would be evaluated at a later date(s).