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.