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 coded in Java. It leverages a SQLite database to manage all contact information, messages, etc. It makes use of a data connection in order to communicate with other parties. We chose Android as it's a rapidly growing, already very common platform with good flexibility. (And it's more pleasant to code for than the iPhone!) Mobile platforms offer interesting use cases, due to limited screen size and the use of touch screen interaction.

We used standard toolkit for many of the UI components. This was done for ease of development as well as usability reasons. Using standard components that users are used to seeing will help to decrease the learning curve and help prevent misunderstands, errors, etc.

We created custom colored images to represent different ideas throughout our interface. This was done with freely available images which were then colored, scaled and composed to give the desired resources. Doing this right was very important to our usability. I believe the icons we created and used added a lot the the user interface. They were good at conveying their contained concepts (trust, warnings) in a concise fashion. Also, they gave indications without relying solely on color, so that color blind users would still be able to use the interface effectively.

Individual tabs in the UI were defined as separate Activities, which helped allow the team subdivide tasks across each of screens. This is a robust part of Android and so is very responsive and usable. The icons have large click areas to prevent errors, and their icons are good indicators of their contents.

Open Source packages were found and integrated for the barcode reader and QR code generator. This package also deals with ensuring the user can get access to a barcode reader if they do not already have one. This ensure setup of the additional dependencies is as easy as possible for the user.

The backend server handles all the routing of messages between clients. It is coded in PHP with a MySql database backing it. Android devices will be able to communicate directly with each other without any setup besides adding someone as a contact. This simplifies the setup and use for the end user. This was intentionally designed such that the server could be untrusted. Therefore, there is no authentication; all verification is done through encryption. The underlying protocol is HTTP.

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	Add Contact -Accidentily made new conversation first -Got to barcode fairly quickly -Accidentally made new conversation first -Got to barcode scanner fairly quickly Send to Contact -Quickly created a conversation -Quickly sent message Receive from Unknown -"I have no idea how to add [them] as a contact" -clicked on person to attempt to add (need long click) -tried using add to conversation -went to contact, then identity (basically searched everything) -hard to be told to long click after a few minutes of hopeless searching--"how was I supposed to know that???" Remove Contact and Message -did quickly and efficiently	Add Contact -Seemed fairly clear to user Send to Contact -Seemed very clear to the user Receive from Unknown -This clearly needs to be changed in some way, it was very clear the user was never going to figure it out on their own. -Maybe add a "+" button or other icon on any unknown people, in order to afford adding Remove Contact and Message -Seemed clear to the user
User 3	Add Contact - Immediately knew how to add the contact. - Felt that the QR code was obvious and efficient. - Confused about what a "knowing" a user meant. Thought that this was required. Send to Contact - Clicked on the person trying to start a conversation. - Got it on the second try. Receive from Unknown - Clicked on the conversation to add to contacts. Didn't know that a conversation could include more than one person. Remove Contact and Messages - No problem.	Add Contact - "I know this person." is confusing. We should probably change the wording. Send to Contact - We should add a long-click menu to contacts to make them more consistent with the android contacts application. Receive from unknown - We might want to make the fact that something is a conversation more obvious. However, a single mistake with no side effects is acceptable when learning an application. Remove Contact and Messages - No problems.

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 the 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.

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. It was a bit of a learning process, but it helped us get comfortable with standard design elements in Android, that were most likely created with usability in mind.

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. Given the feedback we have received, we have located areas where we can definitely improve. This definitely highlights how usability design is an iterative process that can go on indefinitely.

Child pages