upLift - Interactive Prototype #2 Daniel Kitt (Project Manager) Alisa Yamanaka (Documentation) Haochen Wei (Usability) Yuna Shim (Design) Jared Jones (Development)

1. Problem description

People are generally good, but sometimes it is difficult to express kindness towards other. Barriers such as too little time or money can make someone feel like they are incapable of helping others, and social anxiety can make it difficult to reach out to a complete stranger. What we propose is creating a service to make intelligent suggestions of random acts of kindness and volunteer events based on what an individual can actually donate, whether that’s time or money or neither.

2. Solution Overview

Our plan is to create a virtual application that will help anyone who is looking for a way to help others. The focus will be on providing support for this individual, whether it’s suggestions on what to do or connecting them with someone else who has ideas for a service event. These suggestions will be tailored to each individual based on location, time available, budget and interests. This way everyone will have an opportunity to reach out as little or as they like, to uplift someone’s life.

3. Tasks

Simple - Kimberly is a UW student. Growing up she volunteered with a school group, and really enjoyed helping others, but now she doesn’t feel capable because of her limited schedule and budget. While out and about during the day she wants to do something nice for a complete stranger, without it interrupting her normal patterns. She would like suggestions on to what to do to help, which take into account her location, time availability and budget, so as to limit the requirements on her as much as possible. Medium - Zachary is at home on a Sunday and finds he does not have anything planned for the afternoon. He would like to use this unexpected free time to do something charitable. He decides to go looking for a possible activity that he could participate in without any previous planning, and that would fit within his window of free time. In addition to these limitations he would like to be able to choose from a list to make sure that he can choose something that would be easy for him to participate in as well as pique his interest.

Complex - Nicole is the president of a school volunteer service organization. She has been planning a service event for the members of her club, but would like to advertise the opportunity so that they could have even more volunteers. She already has the time / place and other such logistics decided upon, and would like to broadcast these to a pool of interested parties beyond her normal group of friends and acquaintances. We chose these three tasks since they provide good coverage of our app’s intended features. They cover the random acts of kindness portion which is central to our app. They also cover both the creation and joining of volunteer events, which are the other key part of our app as a whole. If someone wants to find a way to help others using our app, their actions will fit into one of these three tasks; as a result, these tasks are very representative of our interface.

4. Scenarios

Simple Task Task 1.1 - Kimberly chooses “Act Now” from the main menu.

Task 1.2 - A list of random acts of kindness is displayed. Kimberly chooses “Buy coffee for a stranger”.

Task 1.3 - Kimberly now sees the instructions for this random act along with the average rating and comments it received from other users. Once she has performed the act, she chooses “I’m finished.”

Task 1.4 - Kimberly may choose to rate the activity and provide feedback about the experience.

Task 1.5 - Once she’s completely finished, Kimberly is returned to the main menu and cordially thanked for her participation.

Medium Task Task 2.1 - Zachary chooses “Find Events” from the main menu.

Task 2.2 - Zachary can browse for events happening near him.

Task 2.3 - Zachary may decide to search for an event instead based of the criteria shown below. The results display a list similar to the Browse tab.

Task 2.4 - Then, Zachary chooses “Bake Sale” and is brought to the event info screen where details about the event, including time and location, are displayed.

2.5 - Zachary chooses “Join” and sees a confirmation popup.

Complex Task Task 3.1 - Nicole chooses “Organize Others” from the main menu.

Task 3.2 - Nicole enters the information about her event into the form provided and then clicks “Preview.”

Task 3.3 - The event is shown as it will be displayed to other users for Nicole to review. She then clicks submit.

Task 3.4 - Nicole sees a confirmation popup now that her event was submitted.

5. Design Evolution

Our design began with a simple idea: a proposal for an app called Secret Agent Nice Guy. The idea behind this app was to promote random acts of kindness for strangers and help others who seem to be in need. During the early stages of design, we found that this would synergize well with promoting volunteer events, so we added that to our proposed app. Around this time, we rebranded the app to upLift, which came with the idea of the sky-blue background and red balloon that we still see in our most recent prototype. Our early sketches were varied in terms of target platform and overall organization. Some had ideas for scanning in an event’s flyer and automatically generating an upLift event, some were for tablet computers, and a few had surprisingly similar designs to our current prototype.

Early sketches

After exploring the design space through sketches, we created a low-fidelity prototype on paper and performed our first usability study. This interface was fairly similar in nature to our current prototype, but even our first usability study helped us refine our interface in a number of ways. Our original design had two separate pages for My Events, one within Act Later and one within Organize Others. The results of our study indicated that we should merge these two into one page and link it from the home page of the app. We also learned that we needed to help the user navigate through the app a little more by adding home and back buttons to every page, allowing users to get back to some kind of central location at any time. Finally, our original prototype would suggest a single random act of kindness with the ability to “refresh” the suggestion to get a new one. Our users found this frustrating if they wanted to refresh multiple times and requested a list of suggestions instead, so we added this in the next iteration of our prototype: our medium-fidelity prototype.

Low-fidelity (paper) prototype

Our medium-fidelity prototype was made using Justinmind Prototyper, software which allows designers to create interfaces and export them in HTML form. This prototype was made to mimic the style of an iPhone app, using the general styles associated with iOS. We fixed the issues found with our previous prototype and also added new features: users could rate their experience with random acts of kindness and also preview events that they were creating. We thought these added features would make users enjoy using our app more and give them greater control over creating events.

Medium-fidelity prototype (ran in browser)

Based upon this medium-fidelity prototype, our classmates performed a heuristic evaluation of the interface which led us to make several changes. First of all, we decided to change the platform to Android instead of iOS, since we felt that this would simplify future stages when it came time to make a prototype that would run on the target device. (Two of our group members were familiar with Android programming; none had experience working with iOS.) We added a

few new features to the app at this point: the ability to browse through events without searching through them, fields for both start time and end time of the event (instead of just start time), and the ability to delete events that the user had created. We also marked which fields were required on the Organize Others screen. These were all based upon criticism or feature requests from the heuristic evaluation that was performed on our app, and our team agreed that all of them would improve the overall usability of the app. This new version of our prototype was our high-fidelity prototype, also created using Justinmind Prototyper. We performed an online usability study using the website Userzoom to test our HTML prototype on the web with a group of 20 participants. We gained a great deal of useful feedback from this testing. The most commonly mentioned problem users had was related to the labels on the buttons of the home screen, so we changed Act Later to Find Event and added short descriptions to each button to alleviate this. We also received feedback to improve our action bar along the top of the screen to align more with Android 4.0 standards. We also revamped the My Events portion of our interface by changing it to a tabbed view rather than one list on top of another. We received feedback that the My Events screen felt useless if the user had not signed up for any events, so we added buttons to allow them to either find events or create events when they had no events in their list.

High-fidelity prototype (ran in browser)

This led us to our Interactive Prototype v1, which was built from the feedback received from our usability study and was able to run on Android 4.0 enabled devices. We made the changes referenced previously and also added a few new things, like a link to My Events from the action bar at the top of each page. Additionally we included user comments on the pages for random acts of kindness as a way for users to see how others felt about them, hoping that positive feedback would encourage users to break through the barriers to them performing a kind deed for others. (This was a change we had thrown around since the medium-fidelity prototype, and

it was nice to see it finally implemented in this iteration!) We also unified the style of our app to be a little more congruent by using the Holo Light style throughout our app.

Interactive Prototype v1 (on Android 4.0 phone)

Using this interactive prototype, we ran a pilot usability study using five participants to both get feedback on our interface as well as refine our study so that it could be performed on a larger audience for better results. The feedback we received led us to change a number of things for our Interactive Prototype v2. We noticed that users often had difficulties deciding which button to click on our home screen for some of the tasks, so we decided to change the wording on the home screen to clarify the names and descriptions of the buttons. We also added icons to make the buttons more visually distinct and give further hints as to what the button would take them to. The other major change was to improve the visual style of our lists of events, since many users commented that more information on the list items would be helpful in deciding which event to click on. We changed the logos on the event list to be color coded according to how the events were classified, with categories such as “Nature” and “Animals”, for users who wanted a specific type of event. We also changed the layout of the page for a random act of kindness to make it more clear that the rating and comments on that page were from other users and not meant for the user to interact with, only to observe. One user from the study tried for a long time to rate an event from this screen, so we thought it would be best to make it more clear that that was not intended on this page. Finally, we changed our confirmation windows to popup windows, as we received feedback that this was more in line with mobile app styles.

Interactive Prototype v2 (on Android 4.0 phone)

Of all the rounds of testing we performed, the most helpful study was probably our pilot usability study using our first interactive prototype. Since the design was fairly refined and running on the target device, it was easy to interpret the feedback appropriately: there was no need to wonder if the limitations of the device were limiting users as they had been in previous studies. It was also more useful than our online usability study because it was possible to know what users were thinking while performing our tasks, and we could really see first-hand what users tried to do when presented with each task. Since it was easier to get the feedback we needed and easier to interpret this feedback, this last round of testing we performed was likely the most helpful in terms of improving the overall usability of the app.

6. Final Interface

Functionality The final upLift UI allows for 4 (four) basic operations: Act Now - Perform a random act of kindness Users view a list of acts of kindness that can be done with little or no preparation on the spur of the moment. Once completed, the user may choose to rate the successfulness of the activity and/or make a comment to inform other users about how it went. Find Events - Browse events that others have organized UpLift also provides a list of activities that take place in a specific location at a specific date and time. Users can browse through the list or search specifically within a time frame, at a location, or by category. Users join events that fit their interests and availability. Create Event - Organize an event for other users to attend Users may also add events for other upLift users to attend. Once the basic information about the event is provided, the user can preview or create the event. My Events - See events that you’ve joined or created All events that a user joins or creates are available for review. A user may cancel an event he creates or unregister from an event he has joined.

User Interface Design The final upLift UI starts users at the home screen. At the top of the home page is the upLift logo and the upLift value statement “upLift helps you help others”). Also visible to users, but useless on this page, is the action bar along the top edge of the app. This bar will be available to users throughout the app, providing consistent, basic functionality like returning to the home screen. Below the logo and the value statement are displayed 4 basic options. These four choices split the functionality of the app into four main areas: ● Act Now ● Find Events ● Create Event ● My Events Following is a screen by screen explanation of the final upLift UI. Act Now - Perform a random act of kindness

After choosing “Act Now - Perform a random act of kindness now” from the home screen, a list of random acts of kindness is displayed to users. All of the acts have a graphic displayed next to a self-explanatory title denoting what the act of kindness entails. This list scrolls with a finger swipe or drag. Once a specific act of kindness is chosen, a more detailed description of the act is displayed. Below the description is the average rating that this act received from other upLift users who performed it. Also included on this page are comments from other upLift users to inform a user’s decison about whether to perform this act.

Find Events - Browse events that others have organized

After choosing “Find Events - Browse events that others have organized” from the home screen, a list of events are displayed to users. Each list item contains a colored balloon graphic, an event title, and event details. The event details provide for users to identify at a glance in what events they may have an interest. New to the final UI are the colored balloon graphics. These provide an extra level of at-a-glance information for more experienced users of upLift, as the color of the balloon denotes the category of the event. The categories and colors are matched as follows: ● Red - Food ● Green - Nature ● Yellow - Animals ● White - Elderly ● Blue - Miscellaneous This page is also tabbed. The default option is browse, but it is also possible to search for events according to the various event details. Once an event is chosen, the event details page is displayed. Details from the list view are again shown along with a more detailed description of the event. Users can then click the “Join” button to indicate that they will participate in this event. Once the event has been joined, a confirmation dialogue pops up to verify that that the user has signed up to attend this event.

Create Event - Organize an event for other users to attend

After a user chooses “Create Event - Organize an event for other users to attend”, she is brought to this screen. The user then needs to specify the details of an event that she would like other upLift users to attend. The name, location, and description are just text values specified by the event creator. The category must be chosen from the list of available categories. The date, start time, and end time are chosen using Android spinner widgets. Only the description is optional. All other fields must be supplied with a value to avoid an error message. The preview button shows the user how the event details page will look for her event once it is created. The submit button will create the event. Once the event is created (after the submit button is pushed by user while all of the fields hold valid informaton), a confirmation dialogue appears to verify that the user has actually created an event.

My Events - See events that you’ve joined or created

All events that a user joins or creates are available for review. This is a tabbed view that separates events that a user created from the events that the user is attending. If a list is empty, a button leading to event browsing or creation is displayed.

What was left unimplemented

In terms of our core features, we were able to implement all of them. Those core features allow for an incredibly functional application, but there are still some features left to be desired that, if implemented, would make our application even better. One big feature we would have liked to have implemented was the ability to use the phone’s GPS coordinates to make finding events easier. This would have made browsing events easier for users, and more convenient in that it would show the closest events at the top of the list. We also thought about using Google Maps with it so that users could browse events by looking at a map and seeing nearby events. We left this feature out because we wanted to implement our core features, and implement them as well as possible. The GPS feature would be a nice feature to have, but it was not necessary to our prototypes or usability testing. This also would have been one of the more difficult features to implement, due to the fact that we would have to keep track of GPS coordinates for events, and we would have to get it to work with Google Maps. Another feature that many users requested, but we didn’t implement, was the ability to sort events in the browse and search results lists. Users wanted the ability to sort events by location, date, times, and categories. Despite this being a relatively easy request, we were pressed for time and wanted to get other more core features implemented first. Adding the ability to sort would have required us to not only programmatically implement this sorting, but we would have also had to design a way for the user to choose their sorting method. With all of the other designing and programming we were doing, this feature was consistently given a low priority. Through each iteration of the prototype, we made a note that we would implement it if we had time. Unfortunately, we never got around to doing it because of other features or bugs needing to be fixed. Even though there is no formal sorting method, users can filter results using our search function, which was refined in our final iteration of the prototype. This way, users can narrow their search for events and only see events that fit their criteria. Due to the overall desire for this sorting feature, we would probably escalate the priority of it and get it done in the next iteration of the prototype. When users perform random acts of kindness, we don’t actually save their ratings or reviews. We don’t even incorporate them into the overall ratings or reviews for the acts they perform.

This was a decision made early on in our application’s development. Adding functionality to the ratings system that would take into account the user’s feedback was a little more work than what time was going to allow, and we had other core features needing to be implemented. Also, incorporating their feedback was not necessary to the functionality of our prototype or usability testing. In future iterations, this feature would of course be implemented. However, we felt that it had a low priority during our development time. This feature would obviously be important in the event we were to deploy this application and it would be used by actual users. A last minute feature that was requested and that we felt would be a great addition to our application was different colored balloons to indicate different categories of events. For the most part, we were able to implement this feature. However, when a user views an event’s page, they only see the category of the event and don’t see the associated colored balloon. They see the colored balloons when the events are listed, but there is no place in our application that explicitly says what each colored balloon means. We would have liked to incorporate the colored balloon on the event details page to make this more explicit. However, we couldn’t find a good place where the balloon could be displayed. Due to time constraints, we left this feature out, but would definitely implement it in a future iteration. A feature that we thought about early on but decided wouldn’t be implemented until much later was the ability to add suggestions to the list of random acts of kindness. Since we only made a small list of suggestions, it would have been good for users to be able to make their own suggestions and deploy them to the rest of the upLift user base. However, we decided that initially, this would not be an available feature due to the overhead involved with monitoring it (even though there is similar overhead with adding volunteer events). We just felt that adding suggestions was not a core feature to our application, whereas adding volunteer events was. Because it was not a core feature and did not affect our usability testing, we left it out of our application. Overall, we were able to implement all of our core features. The only one that we really regret leaving out is the sorting feature. We felt that of the feature we were able to implement, they were implemented very well and that it sort of makes up for our missing features. We also know that if we were to make future iterations, we would get to our desired, but missing, features, and would make our application even better than what it is now.

Tools

Justinmind Prototyper The medium and high-fidelity prototypes were created using Justinmind prototyper. It helped us to layout the screen elements and simulate interaction. Justinmind provides basic wireframe elements and allows Android widgets to be imported. We were able to layout the elements by simply drag-and-drop the Android widgets and also able to align them into the pixel level by using Justinmind’s grid and style. We made the screens interactive by using “Events”, “Forms”, and “Master Fields” that Justinmind provides for interactive prototype. There was a learning curve to make the most out of Justinmind’s feature; however, using JustInMind prototyper turned out to be successful for the simulation of upLift before writing actual code to build the app.

UserZoom Before building the interactive prototype, we conducted an online usability study with UserZoom. UserZoom allowed us to design our usability study by designing tasks and creating surveys with UserZoom’s survey builder. Although UserZoom only worked on Internet Explorer and limited us to recruit participants using Windows OS and IE, the measures it provided and its user interface that is tailored to the usability study was really useful to conduct the usability study without bringing participants into the lab. Also, UserZoom provided detailed statistics about the survey and users’ performance on the tasks for further analysis. Eclipse For the interactive prototype, all of the team members used Eclipse to write code and run it. It helped us a lot to make the process of run the code easier. The application also helped us in programming. Its GUI gave us a nice visual structure of our project. Also, it could give us notifications if we typed anything wrong. This feature saved a lot of time checking errors in our code. Eclipse can install some plug-ins that can be helpful in programming. In this project, we used Mercurial for Eclipse for version control and the ADT plug-in, for Android development. Google code Using Google code (https://code.google.com/), we can have our project repository online, so that all of our members can easily access to the master repository as long as they have internet. Google code also supports some version control systems so that users can easily see our project’s revision history. In this project we used Mercurial Version Control System to keep the history of our changes. Dropbox Dropbox is a file hosting service where people can save files and share them with other users. As long as users open this tool in their own computer, it will automatically synchronize the date in local repository and the repository in Dropbox server. By using this tool, each of our members can have their own local copy of the project and every other team member can share other members’ repository. In this way, we can see if other members have made any changes in the project. We were trying to use Google code, Dropbox and Mercurial for this project, but since setting those tools together is complicated and Eclipse with Mercurial is much easier to use, we decided not to use dropbox. Mercurial Eclipse (plug-in for eclipse) This plugin made it easy for us to deal with version control. By using this tool, we could do all command by clicking on the buttons. Also, it provided well-formatted revision history GUI so that we could easily check the difference between each version and deal with it. But, in merging two different versions with conflicts, it didn’t work well. It sometimes showed conflicts even if we only had one empty line added. And even after our changing our code to remove conflicts, we still needed to manually mark it as “resolved” to remove the conflict. Google Doc We basically used this before we started implementing the application. Google Doc allows us to write on the same document at the same time, so it made us easier to list up all of our ideas and our plans about implementing the prototype.

Android phone We used an Android phone to test our application several times. It helped us to get to know how our implemented application will look like on the real device. Using our application through the device, we found some problems that we cannot see in implementing on computer. We found what font size will look better for users, and how big our buttons needed to be. However, since the Android phone that we had only supported Android 2.0, we could not use that when we were implementing prototype for Android 4.0. Android Virtual Device Manager / ADT plugin We used this tool to help us make our Android application and run our code on our computers. It was able to give us a good approximation of how users will use our application. It also helps us to find errors in our implementation. Even though our code can “run” without errors, there might be some errors in functionality. For these errors, we can only find them by trying that function on our ADT. But since the ADT for Android 4.0 was very slow, especially when booting up, it took us a lot of time to test our implementation Android Design web page (http://developer.android.com/design/index.html) This is the official web page for the android design. In discussing the new design of our application, we used this web page to check and adhere to the design principles of Android 4.0.