Figure 2.1. Viewing updates on what friends are accomplishing motivates the user.

Size: px

Start display at page:

Download "Figure 2.1. Viewing updates on what friends are accomplishing motivates the user."

Aileen Park
5 years ago
Views:

1. Introduction Project name: Let s Do This Team: Divya Konda Developer. Eric Thong Developer, Manager. Juan Marroquin Design. Sami Ramly User testing, Documentation.

1 1. Introduction Project name: Let s Do This Team: Divya Konda Developer. Eric Thong Developer, Manager. Juan Marroquin Design. Sami Ramly User testing, Documentation. Value Proposition: Achieve your goals with friends. 2. Problem and Solution Overview : Mission: Motivating friends to achieve shared goals. Basic approach: Working on goals, especially long term goals, is difficult. When people are alone, they tend to be less motivated. Also, people tend to lose interest and procrastinate on their tasks when there are no immediate consequences. Let s Do This aims to motivate people to work towards their goals using a system of friendly competition and cooperation among friends. Figure 2.1. Viewing updates on what friends are accomplishing motivates the user. Through our app, once users form pacts and schedule activities with each other, they will be socially bound to their goal. Users motivate each other via updates and good jobs that show

2 up in the newsfeed (Figure 2.1). Positive reinforcement motivates people to keep up with their tasks in order to achieve their long term goals. 3. Tasks and Final Interface Scenarios : Our three representative tasks remain the same as in our previous prototypes. 1. Viewing progress (Simple task) (Figure 3.2) : The task is to view how well the user has been doing with his pacts. One of the most important features of our app is that it incorporates positive reinforcement in various ways by awarding badges and letting users get good jobs. We want our users to be motivated by the progress that they have made in their tasks over time and also by the progress that they have to make to earn rewards. 2. Motivating others (Moderate task) (Figure 3.1) : Another important feature in our app is the ability to encourage others. Two of these ways of doing this is by giving good jobs and compliments. A compliment says specifically what the user felt was good about the update and good job is similar to a Facebook like. 3. Finding buddies within a pact (Difficult task) (Figure 3.4) : The task is to schedule an appointment with a friend to work on a pact together, according to the common free time. This task was very important to us because our whole app is about making pacts with friends. It s important to quickly find common time and schedule pact activities with friends. In our Calendar screen, we provide the ability of finding common time via filters and the ability to schedule activities. UI Storyboards : Figure 3.1. Storyboard for motivating friends by giving good jobs, showing the concept of limited good jobs.

3 Figure 3.2. Storyboard for viewing achievements/progress. Figure 3.3. Storyboard for viewing daily view

Figure 6.4. Storyboard for scheduling an event. 4. Major Usability Problems Addressed : 1. [H2 1: Visibility of system status] [Severity 2] (Figure 4.1) Problem: On the home screen, i.e. the Newsfeed, the user has no indicator that they are, indeed, on the News Feed page.

4 Figure 6.4. Storyboard for scheduling an event. 4. Major Usability Problems Addressed : 1. [H2 1: Visibility of system status] [Severity 2] (Figure 4.1) Problem: On the home screen, i.e. the Newsfeed, the user has no indicator that they are, indeed, on the News Feed page. The navigation menu at the bottom of the screen doesn t indicate which of these four places, News Feed, Pacts, Achievements, or Calendar, that the user currently is in. Fix: Highlight the relevant icon on the bottom static navigation bar. Rationale: This is a change that will keep our app consistent with many other apps that have a static navigation bar, like Instagram. Highlighting the icon will clearly show the user where he is in the app. 2. [H2 8: Aesthetic and minimalist design] [Severity 3] (Figure 4.1) Problem: It is unclear why there is a good job number on the user profile picture on the achievements page. This is additional information that is confusing and contradicting to the good job total number next to the profile, and the good job total number on each update in the updates section. Fix: We removed the number of good jobs on the profile picture. Rationale: The initial idea of including good jobs on the profile picture is that the profile picture of the user is dynamic. It was supposed to be the picture of the update that the user has most good jobs for. However, we agree that it is confusing to have too many features in the app. 3. [H2 7: Flexibility and efficiency of use] [Severity 3] (Figure 4.1) Problem: The swipe to show more functionality on the achievement page is cool, but it seems like a feature for experts. I wouldn t have initially known that I should swipe to reveal more items. The scroll bar below isn t very clear and doesn t get across the message that the user needs to scroll to the right. Fix: Showing a little of the next view in the scroll view and adding arrows on either side of the horizontal scroll view.

Rationale: Showing a little of the next view in the scroll view, would indicate that there s more, and would be consistent with how many apps do it (Facebook).

5 Rationale: Showing a little of the next view in the scroll view, would indicate that there s more, and would be consistent with how many apps do it (Facebook). Also, we added the arrows, as a reinforcement to the first fix. 4. [H2 1: Visibility of system status] [Severity 3] (Figure 4.1) Problem: On the achievement page under the Updates, Badges, and Pacts section, (in addition to the scroll bar not being evidently a scroll bar), the user is sort of lost as to how many updates, badges, and pacts there are. Fix: Added See all above each horizontal scroll view. Rationale: We reduced the number of items on the scroll view to the 3 most recent updates, since a scrollview may not be appropriate for a large number of elements. The user can view everything by tapping on see all. Figure 4.1. Screenshots showing fixes for violations 1, 2, 3, 4, 9 and [H2 7: Flexibility and efficiency of use] [Severity 4] (Figure 4.2) Problem: On the pacts page, the user (like myself) may think they should be able to create a pact directly from the pact page. Fix: Add a add a pact button on the pacts page. Rationale: In the initial design, the ability to add a pact was accessed through the explore pacts button. However, we feel it is more clear to provide the ability of adding a pact without going through an extra step.

6. [H2 2: Match between system and the real world] [Severity 2] (Figure 4.2) Problem : On the pact page, the updates and people icons look like they should be different, pressable buttons.

6 6. [H2 2: Match between system and the real world] [Severity 2] (Figure 4.2) Problem : On the pact page, the updates and people icons look like they should be different, pressable buttons. However, they are just more detailed information about that specific pact. Fix: Separate pact information by horizontal lines, reduce the size of the icon, and include words to reinforce their meaning. Rationale: We added a separating horizontal line to separate different pacts to better group information for each pact. Decreasing the size of the icons and including words make them seem less like buttons. Figure 4.2. Screenshots showing fixes for violations 5, 6, 12 and [H2 6 Recognition rather than recall] [Severity 3] (Figure 4.3, 4.7) Problem: On the calendar page, it is not noticeable or intuitive how to access the day/month different views. This option isn t clearly laid out for the user and the option to switch between views isn t visible. Fix: Change the drop down to say monthly view instead than the date. Rationale: We agree that a drop down on the date would be less obvious, even though Google Calendar uses the same metaphor. We changed the wording to monthly view

on the drop down, to make it more obvious that the drop down would allow the user to choose the views. Figure 4.7. Redesigned timescale dropdown menu 8.

7 on the drop down, to make it more obvious that the drop down would allow the user to choose the views. Figure 4.7. Redesigned timescale dropdown menu 8. [H2 6 Recognition rather than recall][severity 2] (Figure 4.3) Problem: The colors for the pact types on the calendar page should be made explicit as to what pacts they represent. Fix: Remove the feature of indicating pacts by color. Rationale: We used colors on the calendar to show that a specific pact is scheduled on a specific day. But, remembering pacts by colors may be difficult for the user. Also, we felt that just showing the user that some pact had been scheduled on a day and letting him view the details in the daily view would make things simpler. So, in the monthly view, we only use a red dot to indicate that a pact has been scheduled on a day, and the calendar doesn t give more details.

8 Figure 4.3. Screenshots showing fixes for violations 7 and 8 9. [H2 6 Recognition rather than recall][severity 4] (Figure 4.1) Problem: The various types of icons on the app are not immediately clear to the user, and there are many different types that the user has to remember. Fix: Reduce the size of the icons and use words to reinforce what the icon is. Rationale: We felt that this fix could make it easier for the user to identify the information better. 10. [H2 5: Error prevention] [Severity 3] Problem: On the pact creation page, it is unclear to the user that they are actually creating a pact. They go to calendar, click the X, then write out these details and click done. It never explicitly states create a new pact anywhere, so a not so intelligent user might accidentally create a pact without meaning too. Fix: None. Rational: The evaluator misunderstood scheduling within a pact with creating a pact. We believe that choosing a pact for scheduling is easily understandable, since none of our users in user testing seemed to be confused about this. 11. [H2 4: Consistency and Standards] [Severity 3] (Figure 4.4, 4.11) Problem: Pressing on a star gives a good job to a notification, but there are two stars

Rationale: We agree that two good jobs may be too crowded and confusing.

9 displayed per notification and only the large one works as a button. Fix: Have only one star to give a good job and indicate the number of good jobs on the post via words. Rationale: We agree that two good jobs may be too crowded and confusing. We initially used the smaller star for indicating the number of good jobs, replacing that will words will make the view better and also reduce the confusion. Figure 4.4. Screenshots showing fixes for violation 11 Figure Redesigned prototype: One clear pressable star that turns red when pressed. Cumulative total shown as a text right next to it 3 good jobs

10 12. [H2 3: User control and freedom] [Severity 4] (Figure 4.2) Problem: If a user accidentally presses the + Compliment button, no immediately obvious way to navigate back to where the user was previously. Fix: No fix. Rationale: There is a back button in Android itself. So, the app doesn t require another special back button, if implemented in Android. Furthermore, we took away the feature of compliments, to avoid overwhelming the user with too many features. 13.[H2 3: User control and freedom] [Severity 3] (Figure 4.2, 4.13) Problem: If a user accidentally presses on a specific Pact, no immediately obvious way to navigate back to where the user was previously. Fix : No fix. Rationale: There is a back button in the Android UI. So, the app doesn t require another special back button. Figure Android s built in navigation 14. [H2 2: Match between system and the real world] [Severity 4] (Figure 4.1) Problem: Search toolbar at top of Pact Marathon view would serve no obvious purpose as there is no information needing searching within a Pact. Also appears in Achievements view. Fix: Removed search bar and added search action icon in the action bar. Rationale: We did not agree with the reasoning given for the problem. We believe that searching in the app should be available on all the pages and this search is searching anything in the app. However, we thought that the search bar consumes space that could be utilised in a different way. So, we got rid of the bar and added a search icon on the main action bar itself. 5. Design Evolution: Project Proposal: Let s Do This started out with the idea of grouping friends together into pacts, similar to those made typically during the New Year, in order to ensure no individual trails behind. Initially this would be motivated by a pot of money everyone would pay into and which would be distributed amongst those who stayed in the pact. However, after realizing that this would be difficult to implement with issues like people wanting their money back and people lying about their work, we decided to focus instead on how we could use someone s social network to validate their hard work.

11 Paper Prototypes and Low Fi Prototype: We started off our design process by writing out a list of things we might want in our pact app. After narrowing down this list into what seemed most feasible we began thinking of possible implementations with sketches drawn on the whiteboards in Lathrop and a few drawn on paper (Figures 5.1, 5.2, 5.3, 5.4). These initial designs looked at different ways we could structure our motivational app. One design explored centering the app on your social network, where the home page would be a Facebook style news feed of your friends with a very large UPDATE button present. Another design focused on the user and gave visual priority to their current pacts, and only demonstrated the social aspect of the pacts when the user was not updating their progress within the pact for a long time. This design included the guilt trip snooze function(figure 5.6) that was seen in our concept video. Yet another explored the idea of awarding users with badges for their progress, and yet another proposed the idea of using Google Glass to compare how productive friends were doing in real time (Figure 5.5). When advancing into our Low Fi prototype we decided to go with a simple navigation home screen which would be comparatively easy to implement in the Prototype on Paper platform while keeping the very large UPDATE button as well as the concept of leveraging peer pressure through the previously mentioned Guilt Trip Snooze function. Figure 5.1. Initial App Brainstorm

12 Figure 5.2. Friend Centric Design Figure 5.3. User goal centric design

13 Figure 5.4. Introduction of badges Figure 5.5 Google Glass Design

14 Figure 5.6. Low Fi home screen and Guilt Trip feature User Testing and Medium Fi Prototype: Our user testing yielded many design changes. The most significant criticism we received was that our homescreen was simply too static. Users did not want to open up their app to see links to other more interesting places. This lead us to pursue one of our other initial designs that made a news feed into the home screen. In order to do this, we also needed to rethink the organization of our app, our initial design contained about eight links to different places in the home screen, this was to allow fast access to anywhere from the home screen, however, in order to reduce this to a navigation bar so that the news feed could be displayed, we needed to reduce these buttons to at most We decided to combine the Calendar and Reminders buttons as well as the Pacts and Friends buttons, and reduced the messages button to a notification tab in the upper right corner. We also noted that there was no reason to dedicate so much of the space to a picture of the user, especially on a mobile app. Another notable design change came about after a studio activity in which we were to quickly sketch out 10 different motivational app designs. One idea was to limit the amount of good jobs you could give to people within your social network, this limit was intended to add value to the kudos unlike the unlimited like s one can give on Facebook. We implemented this into our Good Job system allowing users to only give

In order to display this information in an attractive manner we decided to use horizontally scrolling blocks of information that included badge status, recent updates, and recent pacts. Figure 5.7.

15 out 3 good jobs a day to different updates. The final design change that came out of a desire to reduce the number of screens our users would have to remember was the combination of the Achievements page and profile page. In order to display this information in an attractive manner we decided to use horizontally scrolling blocks of information that included badge status, recent updates, and recent pacts. Figure 5.7. News Feed Homescreen Figure 5.8. Profile/Achievements page Heuristic Evaluations and Hi Fi Prototype: The Heuristic Evaluation of our app led to us streamlining our app and making a few things more explicit. Our evaluators found the horizontal scrolling to not be obvious and so we added arrows to the sides of each row and provided a preview of the next item to make this function more obvious (Figure 5.10). Our evaluators also wanted us to make it clear how to add a new pact and were unsure of the functionality of the Explore Pacts button. Our solution was to simply add a New Pact button alongside the Explore Pacts button(figure 5.11) where before we simply had unnecessary white space. We reduced the number of icons in our app in response to our Evaluators stating that there were simply too many to remember. We got rid of the Complement feature in our app altogether (Figure 5.9) because it seemed like the least essential feature, served an unneeded middle ground between the Good Job and a simple comment on an update, and required an extra icon. We also finalized our icons for a pact and badge, which were previously placeholder Paw Print and Trophy icons.

16 Figure 5.9. Final Home Screen Figure 5.10 Added Arrow Indicators

Figure 5.11 Final Pact View Figure 5.12 Final Calendar View 6. Prototype Implementation: Tools: 1. Eclipse: Eclipse was an easy platform to get familiar with.

Log cat provides an easy way of debugging exceptions and errors. Different perspectives of Eclipse also make it convenient to use in both debug mode and java mode.

17 Figure 5.11 Final Pact View Figure 5.12 Final Calendar View 6. Prototype Implementation: Tools: 1. Eclipse: Eclipse was an easy platform to get familiar with. It offers an easy to use interface to make Android apps. The storyboard screen is convenient to visualize the screen layout of the xml file. Log cat provides an easy way of debugging exceptions and errors. Different perspectives of Eclipse also make it convenient to use in both debug mode and java mode. However, Eclipse also crashes a lot. Divya s Eclipse crashed two days before the project was due and we lost some minor changes. We had to redo the changes. Also, if the screens have a considerable number of elements and a combination of views, such as our achievements page, eclipse becomes extremely slow in processing changes.

18 2. Parse: Parse is probably the most comfortable and easiest to use cloud backend database that s free. It s very easy to learn how to use the database from their documentation. They also provide a starter project with their library with starter code integrated. It s also very easy to add database tables and new columns and rows in Parse. However, Parse sometimes becomes too heavy on the system. This causes the application to slow down. 3. Gimp: Gimp is a very good free tool for editing icons. It s easy for small edits like color inversions. However, a first attempt to making icons can be tedious when using Gimp. 4. Photoshop: Photoshop is a powerful tool for design, editing, but it requires some time to learn how to use it. However, there are many more online tutorials for photoshop as compared to Gimp. 5. Git/Github: We used git for source version control and Github for team collaboration. Git s branch functionality allows multiple developers to work on the same project at once and allow merging later. However, since git is a command line program, it can be difficult to learn. Additionally, merges can be tricky, especially without a graphical merge tool. Wizard of Oz techniques: We took advantage of Wizard of Oz techniques in some of our tasks to make our users have a good experience. For example, in our scheduling task, after the user schedules a task with a friend and clicks done, the app displays a message saying that an event has been created. But in reality, there is no internal mechanism to actually schedule a custom event and integrate the friend s calendar to do this. We did this to provide the user an idea of how the application should work, as if it had a backend. Hardcoded data: The lack of a backend database and server made us choose hard coding most of the information in the application. In our newsfeed screen, all the post information is hard coded. Also, though we used parse database as a backend for the task of giving good jobs, we hard coded the ids of the images into parse to save the state of good jobs between sessions. In our achievements page, we used hard coded data for all the information. The total number of good jobs and name of the user are the only elements that can change according to the user who is logged in. All the other data, in and out of the horizontal scroll views are hard coded. In the calendar, the dots that appear on the calendar that indicate presence of events, are hard coded. Also, all the events in the daily view are also hard coded. In the scheduling page, the drop down menus and any information that is displayed is something we manually put in there. Future:

19 A backend server and database, which will enable us to implement actions without using hard coding and wizard of oz techniques. Due to time constraints, we were also not able to implement advanced functionality like Google Calendar syncing. Reminders that take the user through a guilt trip, and motivate the user to get out of bed. Make all the screens of the app, which will give a more complete user experience. Social network integration with Facebook and Twitter

Team : Let s Do This CS147 Assignment 7 (Low-fi Prototype) Report

Team : Let s Do This CS147 Assignment 7 (Low-fi Prototype) Report 1. Title, each team member s name & role Title: Let s Do This Roles: Divya - Developer. Eric - Developer, manager. Sami - User testing,