GR6 -- User Testing

Design

Our application is designed to look like a familiar mobile chat application, with the pertinent details about secure communication highlighted and most of the technical details abstracted away. We felt that most of the existing solutions available were not usable by the vast majority of the population, and wanted to design something that would be secure while making encrypted communication more accessible. Thematically, we went for a very minimalist UI to further emphasize our goal to simplify encrypted communication. At a high level, the application is broken into 4 tabs, each of which provides essential functionality to the application.

GUI Section	Screenshot	Design Commentary
Login		The login screen was designed to ensure the application preserves security. It appears any time the application loses focus, to ensure that anytime the phone changes state, turns off, or otherwise may potentially enter an unsecure state, a password must be entered. The screen was kept simple with just the essential fields and allows the user to quickly enter their password to get into the application. On the user's first run of the application, they are prompted for a name and password. These primitives are common across all kinds of modern interfaces and tools people are familiar with using. This hopefully makes it clear what is needed without having to explicitly explain or direct.

Inbox		The Inbox screen is where the user can view and send messages from other users. The inbox is designed to look and feel like a traditional text message/chat mobile application so that learnability is made easier. We designed a number of visual cues to help the user quickly assess the security level of particular conversations and messages -- the icon suggests the number of participants and whether the users are verified by color. Individual messages and also marked in the appropriate color, and an icon further reinforces whether the person who they are communicating with has been verified. We decided to leave multiple indicators in after noticing numerous mentions in the heuristic evaluation about how different users may not be able to perceive some of these essential security indicators (such as colorblind people). Efficiency was also considered to streamline some of the verification process when having conversations. Unknown users can directly be added to the contacts list and their verification process updates all existing messages.
Contacts		The Contacts screen is where users can browse and edit the users to whom they expect to communicate securely with. This screen is designed to look and feel much like existing contacts applications to enhance learnability. A sorted list of known users is displayed, and can be paged through and data modified. What is unique is that the data stored includes a secure key which identifies that person (required for secure communication), and a flag to denote whether that person is known to the user. These data elements simplify the transactional needs of encrypted communication, the first of which can also be passed physically with a barcode (see My Identity below). There were debates on how much data to allow the user to see/mess around with in terms of contact data, and we settled on trying to keep things simple and uncluttered with lots of contact data. Efficiency was taken into account when creating the delete contact feature, which can optionally also automatically remove past messages from that user so that the user doesn't have to delete them manually. In addition, we allow the user to add new contacts in two ways -- one is manually entering in their secure key, while the second uses the built in camera on the phone to take a photo of a 2d barcode. This is a vast improvement in efficiency for passing secure keys in person. Security is also emphasized as any non-reversible tasks require a confirmation before they will execute.
My Identity		'My Identity' is a simple screen that shows the user's profile data, and a large 2d barcode that can be used to physically share their encryption key with another user of the application. Heuristic feedback suggested that users were not entirely who's identity this page was meant for, so we added a new title to signify that it was their personal identity. With QR codes becoming more ubiquitous, they afford being scanned by many people who are familiar with them.
Settings		This is a basic settings screen with gives a place for the user to modify application settings. This is designed much like any typical settings screen, and as of now only allows the user to edit their password.

Implementation

Our application was built as an Android application.........

The backend server.......

We used standard toolkit for much of the UI components, such as.....

Individual tabs in the UI were defined as separate Activities, which helped allow the team subdivide tasks across each of screens.

Open Source packages were found and integrated for the barcode reader, numerous icons....

Evaluation

Three user tests were performed in order to investigate the effectiveness of our interface. One developer acted as both facilitator and observer for each test. We located users who we thought we be good targets for the application -- users who were interested in securely communicating with others, but not necessarily those who understood the technicalities of encrypted communication. One user test was performed using the application running on an Android phone, while the others we performed using the Android emulator.

We introduced our application briefly by discussing our intent with an easy to use but secure communicator. We did not perform a demo hoping that the similarity to existing applications would be enough for them to get around. We asked each user to perform the following tasks:

Log into the Application
Add the Facilitator as a new Contact via Barcode
Initiate a Conversation with the Facilitator
Receive a Message from an Unknown Contact and Add that person as a new Contact
Remove the newly added contact and all messages they sent

User Test	Critical Incidents/Quotes	Design Learnings/Possible Fixes
User 1	Add Contact "Why is there a Barcode on my Identity?" -Appreciated not having to physically type anything to trade contact info "What does Verified mean" -"Looks like my iPhone Contacts app" Send to Contact -"I like the icons" -Felt slow to send a message -- Have to click through three screens before you can type -Easily able to send messages and receive them Receive from Unknown "It's Red. That's bad Right?" -Did not realize long press opens menu of options, had to coach user to find it Remove Contact and Message -Went to contacts app directly to delete user -Surprised that messages were deleted also -- different from iPhone standard which leave messages behind	Add Contact -Since the 'Barcode as my Identity' Concept is not that common, some guidance in the form of help or a tutorial animation could ease learnability. -Linkage between 'Verfied' on Contacts screen and 'I know this person' on Contacts Editor is maybe not clear. Potential rewording for consistency. Send to Contact -Consistency to existing chat applications was successful -Efficiency can be improved, on new messages we can directly go to the contacts list instead of the blank new message screen. Receive from Unknown -User was familiar with iPhone, not Android, so standard UI mechanism like Long Press were not as easily discoverable. Perhaps a button or alternate mechanism to display an additional function is possible would help learnability. -Color coding was obvious and well received. Remove Contact and Message -Might want to further emphasize non-reversible behaviors, especially when they deviate from existing applications. This user removed message, even with the additional prompt, and didn't realize until late what it actually meant.
User 2
User 3

Reflection

Going through the design process in a methodical way was very educational, and we could see the design evolving throughout. We reflect on the evolution of this design through each stage.

GR1 - Analysis

During the initial Analysis, it was instructive to think concretely about the tasks we wanted users to be able to complete. We ended up going back to you task list multiple times for updates because the actual tasks necessary to achieve a users goals were simplified over time. We did a good job targeting specific user needs, but perhaps took on too much total scope for the purpose of this class looking back on it.

Also looking back, remembering to focus on very specific user problems and ensuring that our application addresses those is key. We ended up moving the application into different directions and we could have benefited from a simplification effort during implementation to ensure our final application met all of the basic user needs.

GR2 - Design

The design phase went well and we have each member design their own version of the major tasks to be handled. This gave us multiple potential ways to implement the same tasks, and then we were able to directly compare them and discuss which methods would work best in our next prototypes.

At this stage we focused on high level tasks, instead of low level methods to achieve those. f

GR3 - Paper Prototype

The paper prototypes were both fun and informative, as we had not gone through such an exercise before. We learned a lot from having users physically attempt to use the paper version, and vocalizing their thoughts.

GR4 - Computer Prototype

For the computer prototype we were attempting to get the barebones functionality working, as this was the first Android application any of us had worked on.

GR5 - Implementation

Architecting the application such that multiple people can work independently on certain sections is a huge help. Separating the UI from the backend allows both to be developed in parallel, and dividing the application into distinct section allows each one to be created independently.

GR6 - User Testing

Even with all the upfront work, user testing still yields new insights.

Child pages