GR6 Analysis

Design

The following screenshots show our final design of ContactLens. We have retained the grid and detailed views as shown in the paper and computer prototypes, but have removed the approve/reject screen based on responses we received in heuristic evaluations and the feedback of our peers during in class testing. In general users found this screen's purpose confusing. Instead we devoted our time to considering how users would manage and interact with their contacts once added, and used a simple add contact modal.

Here is the general grid screen as the homepage of the application. Each of the contacts is in their maximally expanded state. We made sure to answer concerns in our heuristic evaluation about hooking up all the buttons and history items to the correct interaction view on the details page (see more below). You can also see our modifications to the top navbar, centering the logo and providing ways of accessing settings and add contact, and getting rid of the show page as a link.

Here we can see one of the critical design decisions of this project, the affordance for resizability. Throughout our testing (with paper prototype, heuristic evaluation, and in class user testing), finding the correct affordance for resizability of contacts was difficult because the discrete nature of the resizing made it difficult to use a typical resize affordance. Finally in class we received the suggestion to use overlay gifs to display visually what would happen to the contacts if the image was clicked. Here you can see one snapshot of that gif over jack dorsey.

This screen shows what it looks like when several contacts have been resized. In our heuristic evaluation, there were concerns about the way contacts were sorted and how that interacted with the grid layout and resizing. We decided to answer this by sorting contacts by date of last contact (and including a last contact timestamp on the card). This way cards could break this order in order to tile the space as effectively as possible but the most recent contacts would still be near the top as expected by users. We considered adding more options for sorting as requested by heuristic evaluators, but eventually decided that the tradeoff between absolute sorting and perfect tiling was not worth it, especially because the purpose of the grid page is to show as much information as possible.

This is what is looks like when contacts are filtered based on tags. In our heuristic evaluation users were unclear about the controls we afforded, so we made sure to split those controls into separate boxes at the top to inform users of the difference in function. We also considered merging the two controls into one box, but felt it would be too confusing for users to infer the purpose in this case.

This shows what a live search would display after typing the letters "bra" into the instant search bar. The decision to include this also came directly from heuristic evaluations where users requested the ability to have more control.

Here is the simple add contact modal that can overlay over any page. We decided to go with this route instead of the full approve / reject workflow we previously had because users found it confusing and unintuitive. After discussing the main purpose of our application, we decide the approve / reject workflow was tangential to the greater problem of cross media contact management we wanted to look at, so we focused on that.

Here is the details page for a single contact. Several changes have been made here from the computer prototype. The most obvious one is the changing of the entire top header. We decided that the old top header did not have enough useful information (and recieved similar concerns from evaluators) so we modified it to be the area where users could edit contact information. Here we also had to consider whether or not to make the data live save, or require the use of a save button. We ended up going with the save button, because we figured that users would expect such important information about a contact to be not so easily modifiable. In addition, we added a field for notes to be added upon suggestion from an in class tester.

This view focuses in on the interaction pane and interacting directly with a history item. We were asked to provide some way to navigate the history across information sources (searching or filtering) and to provide some indication of what history items were incoming or outgoing. We decided not to focus on any of these suggestions in this iteration because we felt we had an inadequate ability to design such features when we were only connected to one data-source (because of the limitations of our implementation, described below). We also felt that users could have enough contextual evidence to deduce whether history was incoming or outgoing, and after trying alternatives using arrows or alignment we felt none of our options were better. You can also see the engagement window which has populated with the tweet from the history and provides several options for interaction, nothing important has changed here from the computer prototype except for the styling.

Here we display what it looks like when we have unimplemented one of the contact networks. In addition, you will notice that the bar at the top of the interaction area changes color depending on which interaction method you are using. This color specificity also extents to the shadow around any focused input. This color decision was meant to provide an extra cue to users about when they are adding input that is network specific vs. general to contact lens.

Implementation

Our implementation is a rails app with a backbone.js front-end. All of the dynamic components of the front end, the cards on the grid, the active implementation area, the history items, and the controls are implemented as backbone views and models, to allow our javascript code to be more well organized. This also allows many of the interesting live features of our app to happen on the front end.

In the backend we have a few different models in our database to hold on to things like contacts and their info, and associated history items. More importantly, we integrate with the twitter api on the backend. This is the same place where we would implement with other apis (like gmail, facebook, and linked in) to provide multiple sources of contact for our site. We had to make the important decision to not integrate with any networks other than twitter because doing so would have caused significant increase in the complexity of our database design and backend decisions. Because the focus of this class was not to work on a hard data integration problem, we figured our efforts would be better spent working on the design. One problem this caused was explained above, where the lack of history items from different sources prevented us from investigating interesting ways of sorting and organizing the history items across different networks. It also effected the usability of the interface because users could not actually interact with users across multiple networks, which may or may not have effected their use of the product.

Evaluation

We first found our users by going to the Beehive Cooperative to find people in startups to test our product.  Our user test consisted of several tasks, separated into two sections.  The first section required the user to create and use their own account, while the second section had users test on a sample account of ours.  Testing on a sample account allowed users to experience having many contacts, and not have to create many on their own to save time.  We did not use a demo, but in retrospect, it would have been useful to create a demo video.

We briefed the users by presenting our problem statement from previous GR’s, and presented the users with the following tasks:

• User Account
  • Sign up for a ContactLens account
  • Add 2 or 3 contacts
  • Connect with one of those contacts via twitter and email
  • Edit some contact information and make notes
• Sample account
  • Explore the grid to filter and search for contacts
  • Find “Victor Pontis”
  • Find Beta users
  • Adjust the size of a few contacts

We ran into some of the following usability problems

• Learnability
  • All 3 users weren't able to figure out what to do after the signup page (should’ve authenticated Twitter account, 1 and 3 attempted to change password).  This is a catastrophic error, and we would correct it by directing them directly to a page to only do authorizations, and then direct them to the grid.
  • User 1 attempted to use comma delimited tags, while user 2 tried space delimited tags.  This is a major error, and could be corrected by a demo video.
  • Users 1 and 3 didn’t realize you have to save tags using the “Save contact” button.  This is a major error, and could be corrected with an alert as the user left the page to indicate they needed to save, as well as a demo video
  • User 1 didn’t notice the tag search as separate from the name search.  This is a major error, and could be corrected by a demo video
  • Users 2 and 3 weren't sure what to do about “add contact” or “grid”.  This is a major error, and could be corrected by a demo video
  • User 2 found “add contact” to be out of place next to grid, thought it should be next to filters.  This is a minor error, and could be moved to place it on the same hierarchy as the filters on the grid page.
  • User 3 thought history was tied to interaction medium.  This is a major error, and could also be corrected by a demo video
  • User 3 thought you could drag around contacts on the grid page.  This is a major error, and could be implemented
• Safety
  • User 1 left the details page without saving.  As previously mentioned, this could be corrected with an alert dialog, mentioning they haven't saved
  • Users 1 and 2 needed to authenticate, but didn’t and ran into errors when trying to engage with customers.  This is a catastrophic error, and could be corrected by requiring authorization immediately
• Efficiency
  • User 1 was interested in last contacted date search.  This is a minor error, and could be corrected by being implemented, perhaps as an "advanced search"
  • User 1 wanted resizing in place.  This is an error that is something we will sacrifice, in order to maintain the grid.
  • User 2 wanted to search by content, such as emails.  This is a minor error, and could be corrected by being implemented, perhaps as an "advanced search"
  • User 3 wanted to read whole tweets in the history.  This is a minor error, and could be corrected by using appropriate resizing, or perhaps by allowing overflow.
  • User 3 expressed concerns that tweets were not automatically linked.  This is a major error, and could be implemented.
  • User 3 wanted to relate size of card on grid to priority, as well as metadata (ie tags).  This is a minor error, and could be corrected by being implemented, perhaps as an "advanced search"

For the most part, the users were able to very easily pick up the features of the application, once they actually saw an action happen once.  For example, once the user found the resizing affordance, they were easily able to understand how to resize contacts.  Thus, we feel like a demo video, as mentioned previously, would be extremely useful to helping the user overcome these issues.

Reflection

One of the major lessons learned through implementing ContactLens was the balance of breadth and depth. Because of the vast number of APIs we were accessing, we quickly realized that we would not be able to implement a fully functional product in the timeline given. One of the difficult design decisions was to leave several of the APIs unimplemented. However, there was a large sunk engineering cost in the first week of the project setting up the product to be ready for use with all of the APIs.

One of the things we would have done differently would have been to decide earlier on to implement a single API fully, rather than trying to implement integration with 6 APIs at once. This design decision boiled down to the fact that we did not spec out the engineering guidelines of the project, or estimate the amount of time it would take to build the product, before jumping in heads-first and beginning to code.

We also should have gotten user feedback on the live site earlier on, since one of the screens which we invested engineering time into ended up getting entirely scrapped from the entire product. The team should have kept in mind KISS (Keep It Simple Stupid), and implemented the Minimum Viable Feature Set to test the product with potential users, rather than adding on bells and whistles before putting the product out in the wild.