“GOREMIND” WEB APP 2018

COGS120 HTML/CSS web development project. Completed with my fabulous teammates Liuyi Chen, Francisco Ochoa, and Yujie Wang.


Role: web developer + UX/UI designer + user researcher

Accomplished: web app + user testing + documenting decision making process

Tools: HTML + CSS + Express + Node.js + Google Analytics


The idea

Do you find reminder apps helpful? When chatting to users, many talked about how they often ignore reminder notifications as they aren’t sent at hte right place. When walking, people easily ignore cell phone reminders and thus forgets to do tasks. Thus, we decided to explore the idea of sending sound feedback to users at the proper location and time.


Ideation & prototyping

Storyboard1.png

Storyboard 1

Reminding users of a specific task at a specific location

Shown above: Emily gets reminded to purchase textbooks whenever she walks near the UCSD bookstore.

Storyboard2.png

Storyboard 2

Reminding users of a specific task at a location that fits the designated category.

Shown above: Gabriel sets a reminder to purchase paper towels whenever he is near a grocery store. Gabriel gets reminded when he passes by Whole Foods La Jolla, which is categorized as a grocery store.

Storyboard3.png

Storyboard 3

Reminding users repeatedly of a specific task whenever he/she enters a specific radius of a set location.

Shown above: Andrew gets reminded to do homework whenever he enters a 50m radius of his house.


Prototype1.png

Prototype 1

The homepage of this prototype is a map. On the map, there will be pins wherever a reminder is set up. Users can add a reminder by first looking up the location, adjusting the radius to set up the reminder area, and input details such as title, time, sound options. The reminders will be displayed in a list form.

Prototype2.png

Prototype 2

The homepage of this prototype is a reminder list. By clicking on “Add New“, users will be led to a page with 2 buttons: “Add a New Need“ and “Add a New Reminder“. Both options will prompt users to input details such as title, time, sound options. The difference lies in location setting. The “need“ option will lead users to select a location category (e.g. grocery, gas, clothing); all locations under the category will trigger a reminder. The “reminder“ option will lead users to select one specific location.


Heuristic evaluation on our prototypes

We invited 3 students in the class to complete a heuristic evaluation on our prototypes. The evaluation process was based on the 10 heuristics identified by the Nielson Norman Group. We dropped down a list of potential improvements to both prototypes. Some major points included adding instructions, error prevention, and showing progress. Based on the results, we decided to create a web app based on Prototype 2.


WebPro.png

Digital prototype

Utilizing Sketch, we created two screens as our digital non-functioning prototype. The design was based on Prototype 2 and took into account the list of improvements as identified by our heuristic evaluations.

Development.png

Development Plan

Upon completing prototyping, we moved on to prepare for coding the web application (web app). Following class guidelines, we created a development plan listing all actionable steps to ensure our development is on-time and meets all requirements.


Webapp.png

Coding the app

Over a period of 5 weeks, we coded our idea with HTML, CSS, and Handlebars. We also used Google Maps API for the map feature and Facebook API for login. Although CSS was used, we initially focused little on UI as we spent most of our time coding the functionalities; none of us had background in HTML/CSS coding. Per class requirements, the site was dynamic serving yet optimized for mobile platforms. We were also required to have a login page. After pushing our code to Github, we used hosting platform Heroku to deploy the files.

As the class mainly taught front-end coding, we had various restrictions while coding the app. One of these cases was the notification feature; we were unable to code our original idea of sending location-based reminders. As a result, we used the “Wizard of Oz“ method various times. “Wizard of Oz“ meant hard-coding certain parts of the app to create the illusion of a feature being functional. For location-based reminders, we hard coded to have the app send out a reminder the moment the user opened the app. The reminder was meant to go off at Price Center. As the final presentation was planned to be near Price Center, we decided to use “Wizard of Oz“ to give users that day a feel of how our location-based reminder would work.

There were various other examples of “Wizard of Oz“. We envisioned the voice reminder to remind the user what the task was. However, this obviously involved voiceover skills. Hence, we recorded voice reminders for three default tasks. Another major example was voice notification. We envisioned providing the feature to control notification type, such as speaker mode, vibration only, or headphones only. As the app was HTML-based, we were unable to code something that involved cellphone integration. Also, for users to specify a location for reminder, we coded a dropdown list instead of a allowing the user to select on Google Maps. This was due to the lack of database (not yet taught). We were also not advanced enough to manipulate Google Maps to that level.


usertest.png

User testing

We asked 2 friends of mine to help user test. The user test involved having users complete a list of tasks before being interviewed on their thoughts. We started testing while not disclosing the purpose of the app, the reason being we later had two questions asking: “What do you think that app is about” and “Who do you think the main audiences are”. We would like to know whether there are UI elements we need to change to make the purpose of the app clear.

Both users were able to quickly complete the tasks without any difficulties. This showcased how the app was successful in easiness to use. However, breakdowns were identified during the interview session afterwards. First of all, it became obvious how the purpose of the app was not that clear. This meant that the “How to?“ page we provided was not sufficient; something had to be done upfront (on the login/ home page). Regarding the overall design, general feedback was how the design was straightforward and simple, if not too simple. This showcased how crucial it was for us to focus on UI designing. Moreover, one user had a lot of confusion regarding the sound feedback. However, this was out of our control as much of the problem was due to us deploying a “Wizard of Oz“ method. Other suggestions included improving alignment, 24-hour system being confusing, and changing abbreviation of Thursday and Tuesday (both being T).


GA.png

A/B Testing with Google Analytics

A new task arrived, we were asked to think of a change to our site and use A/B testing to see whether the change should be implemented. We decided to test whether an “add form” built into the list page, instead of opening a separate “add form“ HTML page, would help optimize the user experience. We predicted that a form built in to the list page would give users a more stress-free experience and shorten the overall operation time.

We added Google Analytics code to our page to collect the duration of time users spend on each page. We targeted our student friends to help with the data collection. A total of 93 students explored one of the two versions. Google Analytics then produced a list of durations upon terminating the experiment. We analyzed the figures using a t-test to see whether or not we could reject the null hypothesis that the merged design would be the same as the separate design for users.

After completing the t-test, we failed to reject the null hypothesis. While this should be a sign for us to continue experimenting, as the project was nearing an end, we concluded by assuming that users didn’t prefer one prototype over the other. We viewed this as a green light for us to go ahead with merging the “add new“ form with the home page and hence decreasing the number of pages.


Designing UI and finalizing the app

As we gradually completed the functionalities of the app, we started turning our focus to interface design. We figured that, due to the day-to-day nature of reminder apps, a more subtle background color should be appropriate; hence, dark blue was selected. As for the highlight color, we chose orange, the complementary color of blue. The brightness of orange would direct users’ attention to what they should do next, such as clicking “Log In“ or completing the “Add New“ form. We also had to settle on app name. We brainstormed various options. Bearing in mind the core functionality of our app, we eventually agreed on the name “GoRemind“. We hoped that this name would show users the purpose of the app at first glance.

After a few more tweaks and debugging, we finally completed our first-ever web app. For app users, after logging in, they will able to see all of their tasks either in a listed format or mapped on Google Maps. The “Add New“ feature will allow users to add a new task when they desire. A simple welcome message invites the user to look through the FAQ should they run into any problems.

banner.png

Check out the webapp here.

(Please keep in mind that this is a digital prototype optimized for mobile with many features hard-coded for presentation purposes.)

This project marked my first cooperation with Liuyi Chen and Yujie Wang. We went on to continue partnering in COGS121. Check out our data visualization project.