Goal-laborator: A Socially Collaborative Wellness Platform

Wellington Leewtnlee@seas

Nishita Jainnisjain@seas

Pranjal Goelgpranjal@seas

Shirali Shahshirali@seas

Abstract

Goal-laborator is a web-application designedto motivate people to achieve their own goalsas well as goals they choose to collaborate onwith their friends by using social accountabil-ity as a motivational tool. The app focuseson college students to help students managetheir time, achieve the goals they set for them-selves and find new interests. The applica-tion improves the overall wellness and men-tal health of students, a well-documented is-sue across college campuses across the nation.The application was carefully analyzed to ex-plore and mitigate potential negative social im-pact. The quantitative performance of the ap-plication in both the back-end and front-endwas empirically analyzed to optimize the userexperience while qualitative feedback was di-rectly obtained from the users.

1 Introduction

1.1 Product Motivation and ValueProposition

The main motivation for creating Goal-laboratorwas derived from a clear need here at Pennwhere many students including ourselves havea large variety of goals they hope to achieve,ranging from academic, social, professional andto creative. We observed that these goals wereoften ignored or discarded due to fundamen-tal issues such as over-packed schedules or awork-hard school culture. We hoped to cre-ate a product that would allow high-functioningand busy individuals to carve out time to focuson creating and maintaining their own formsof wellness. A link to the deployed Goal-laborator application can be found at https://goal-laborator.herokuapp.com. Also, a video demo islinked here too https://youtu.be/CEemC7cZgZg.

1.2 Stakeholders

Our application is primarily meant to be used bycollege students. We chose this group becausewe understand this cohort’s problems and needspersonally. A thorough description of all relevantstakeholders can be found below.

• College-aged Students: The most importantstakeholders of our product are college-agedstudents (the primary users). After analyzingthe impact of a college lifestyle, we realizedthat students often have a tough time remain-ing motivated for their goals due to academic,professional, and social stresses. College stu-dents tend to have goals within the followingareas: fitness, learning, hobbies, and creativ-ity. These are goals that help students focuson their well-being. We think that this appli-cation helps address all these goal categoriesand helps college-students achieve a healthierlife-style by collaborating with their friends.

• University administrators: In the future, weimagine that university administrators shouldbe involved in helping work with their stu-dent bodies. Universities care about the men-tal health of their students; therefore, admincould encourage the use of this applicationbecause it might benefit a large number ofstudents.

• Businesses: Companies and brands on a lo-cal, national, and international scale can in-teract with the Goal-laborator. The businessincentive is that they will be able to sponsorglobal goals. For instance, Nike could spon-sor a global goal of everyone running everyweek. These sorts of goals serve as Corpo-rate Social Responsibility which is importantfor a company’s public image.

1.3 FunctionalityAt a very high level, our app provides the function-ality for users to create goals that can be public orprivate. Users are able to add friends on the plat-form and see their friends’ public goals and col-laborate on them.

A user can create an account and login to theweb-app. After login, there are four main tabs thatthe user interacts with:

1. For You: The landing page of our post-loginapp shows the goals that the user has cre-ated or has chosen to collaborate on. Theycan also see any friend requests they have re-ceived or sent on the same page. They areable to check-in to their goals to signify theyhave performed the action that day and areable to mark goals completed once they arefully achieved. Every check-in in on a goalgives points to the user (2 for collaborations,1 for private).

2. Profile: The user is able to see their basicprofile information on this page along withtheir friend list and goals they have created.There is also a search bar to search for andadd other users as friends. The point systemon this page is used to help users stay moti-vated.

3. Create Goal: This page is a form that al-lows users to input and categorize their goals.The categories available are: Creativity, Diet,General, Hobby, Physical, and Wellness. Theuser is able to customize the privacy set-tings, descriptive information and weekly fre-quency regarding this goal through this inter-face.

4. Explore: This page displays a user’s poten-tial collaborations. On this interface, friends’public goals are displayed by category. Userschoose the goals they wish to collaborate onand this page is designed to be the safe spacewhere people broaden their horizons.

2 Related Work

2.1 Gamification as a MotivatorA 24-week study took 602 overweight adults andused social incentives to encourage activity bygamifying exercise. One group of the participantswere involved in a supportive game where a spon-sor would see if they met their goals each week.

Another group was involved in a collaborativegame where teams were allocated points based onthe performance of a randomly chosen member ofeach team. A third group was involved in a com-petitive game where teams compare performancesweekly through rankings. The last group was acontrol group that did not gamify exercising. Thestudy found that the collaborative group increasedtheir activity by 637 steps per day when com-pared to the control group, the supportive groupincreased by 689 steps per day, and the competi-tive group increased by 920 steps per day (MiteshS. Patel, 2019). The competitive gamification no-tably increased physical activity in the participantscompared to the other forms of gamification. Ad-ditionally, after the researchers ended the gamesbut encouraged continued exercise, only the com-petitive group was able to noticeably maintain animproved level of physical activity over the next12-weeks of monitoring (Mitesh S. Patel, 2019).This study shows that not only did competition re-sult in the highest growth of physical activity, italso had the most effective lasting impact, support-ing how well competition operates as a motivator.Our application is going to create, encourage, andmake permanent habits and goals by developing apoint system to induce competition.

2.2 Accountability Through a Network

A study conducted at the University of Pennsyl-vania tried to evaluate the role social media canplay in motivating people to exercise more. Inthe experiment, a group of students were enrolledin exercise classes. Some of these students re-ceived promotional messages and another groupwas placed in a social network with six other peersthat could track their network’s progress on a web-site. The study found that the promotional mes-sages resulted in a spike of exercise in the begin-ning, but the behavior did not stick throughout the13-week study. The social network participants,on the other hand, showed a substantial increase inenrollment as time passed, showing how networkeffects are able to motivate the students more ef-fectively (Jingwen Zhang, 2015). Social influencehas always had tremendous power over how peo-ple behave, but consistent positive reinforcementis also extremely important for motivation. Sincethe peer networks only shared positive behavioron its social platform, there is a consistent sourceof positive reinforcement, encouraging even more

exercise. Our application will leverage this phe-nomena by creating a network of friends that isinherently positive. Users will be able to see theirfriends’ updates and accomplishments. This is asource of positive reinforcement that will increasethe permanence of their goals and habits.

3 Business Fundamentals

3.1 Competition

Some of the direct competitors that app-users usefor habit-tracking and goal-setting are:HabitShare is a habit-tracking application that in-cludes social features like messaging and sharinggoals within a network of peers, but the social in-terface did not allow users to collaborate on publicgoals in their network. The application also tracksstreaks on goals but in the case where streaks arebroken, all prior progress is lost. (Hab, b)Habitica is an application that gamifies accom-plishing goals through assigning rewards for taskcompletion. Habitica also supports collabora-tive goals, but it forces these goals to have thesame users every time. Progress is nicely trackedthrough an avatar that levels up with more accom-plishments, but there is no centralized news feedto view other users’ progress. (Hab, a).Streaks: is a task-list application that helps usersform good habits. This application tracks personaluser progress very well using streaks as motiva-tion, but it does not quantify a user’s overall per-formance across all goals. This application com-pletely lacks a social element; there is no networkof peers or public goals, forcing users to only holdthemselves accountable. (Str).Goal-laborator aims to take all the effective fea-tures of each of these applications and add missingfeatures to create a consolidated application thatmeets the functional needs of all users. This appli-cation will have social features like a network ofpeers and publicly view-able goals, but it will alsoallow peers to collaborate on goals within theirnetworks. Instead of tracking progress throughstreaks, Goal-laborator uses a point system so thatprevious progress remains view-able and to gam-ify the application, providing incentives to usersto compete and collaborate. This application alsoincludes an ‘Explore’ page that provides a central-ized feed of friends’ goals in order to stay updatedand to encourage more collaboration.

3.2 Market Sizing and Growth

The specific market for social goal tracking islargely uncharted, but we can evaluate adjacentmarkets to provide important insights about whatthe relative size of this market might be. Thetwo markets to consider are habit-tracking/self-care and fitness-tracking. MarketWatch (Pesce)found that in 2018 the largest growing categoriesin iOS was that of self-care. This included medi-tation and habit-tracking apps such as Fabulous -Motivate Me. More and more consumers are tak-ing charge of their self-care and we can see thisreflected in growth trends across the market.

Younger groups are notably more involved withself-care than older generations. NPR found thatmillennial generations and those that followed aretwice as likely to be focused on self-care and well-ness such as dieting and working out. Given thepush that younger generations have in this seg-ment, we can see the revenue growth of self-careapps, which is potentially as high as 170% Year-over-Year (Silva).

We also think that the fitness tracking industryis relevant, which has exhibited a CAGR growthof almost 17% (Intelligence). Most importantly,this market has seen a rapid growth of socialized-fitness primarily because it has recognized the net-work effect benefits of motivation. These sort ofapplications allow for a safe space where social-ized goals can live separate from the fakeness andtoxicity of existing social media sites such as Face-book or Instagram.

3.3 Consumer-Side Costs

This will be a completely free application forusers. We stand by this decision because the appli-cation is meant for social wellness. We don’t be-lieve that anyone should be stopped from becom-ing mentally healthier because of cost-constraints.Therefore, there will only be one free-tier versionof this application; everyone should have an equalright to fulfilling their goals!

3.4 Businesses and the Revenue Model

As we have mentioned before, our primary sourceof revenue in the future will be businesses post-ing public goals that all users can see. For ex-ample, Nike might have a goal related to runningor Sweetgreen might have one for eating salads.Businesses will only be allowed to post positivegoals; these will be thoroughly vetted before be-

coming publicly available. All users will be ableto see immediately that these explore-page goalsare Sponsored for full transparency.

In terms of the revenue model, we have de-cided to follow the gold-standard for social-mediabased advertisements by using an approach sim-ilar to Facebook. We’ll employ an algorithmicad-auction that allows a competitive rate for busi-nesses to interact with the application. This auc-tion will be based on factors such as geographicreach of the goal, wellness potential with the goal,and target customer segment. We believe this ad-auction method is important because as our prod-uct scales, we can’t have a static price per impres-sion. This auction should be implemented usingan automated algorithmic and all details should beaccessible through a businesses portal on our ap-plication. We do want to set a general range forimpressions. We will on average hope for a costper thousand impressions of $15. Additionally, wewill also charge based on every engagement (col-laboration) on the goal at an average of $1.

Of course, this has the potential to detractfrom the application’s primary purpose. However,we’re going to do everything in our control to limitany negative consequences of including businessinteractions. Specifically, these goals will only beshown on the Explore page which is not the first(default) page available to users. Additionally, atany given time, we’ll show a maximum of 3 spon-sored goals on the page. Lastly, by thoroughly vet-ting every single business goal, we hope that we’llbetter user mental health by providing new optionsto engage with CSR-motivated goals.

4 Technical approach

4.1 Technical Stack

During the beginning of the academic year, wehad decided to pursue an iOS application builtfor iPhone and iPad. However, we got a signif-icant amount of feedback that a mobile applica-tion would encourage people to spend more timeon their phones and mobile notifications could beintimidating (or even distracting). So, in late Jan-uary, we actually decided to pivot and build a webapplication; this primarily required changing thefront-end with limited structural changes to theback-end.

After our pivot, we chose to use a MERN+Garchitecture, using MongoDB, Express, React,NodeJS, and GraphQL. Each decision had pros

and cons that we outline below. For the code base,please reference https://github.com/wtnlee/goal-laborator-deploy.

4.2 Express and NodeJSFor most modern web applications, NodeJS is theweb-framework of choice primarily because it al-lows event-driven I/O connections that are alsosingle-threaded. This allows for increased effi-ciency and scalability. Additionally, the packagemanager that supports NodeJS development (npm)has many developer tools that made it easier for usto leverage the power of well-tested and optimizedlibraries. Express is the standard server librarythat most developers prefer to use with NodeJS.Finally, we also decided to use Express given ourteam’s existing familiarity with Express features.

4.3 MongoDBFor the database, we considered multiple options,including DynamoDB and MongoDB. After look-ing into the features of both databases, we de-cided to go with MongoDB. DynamoDB is a de-ployed database, which would have made local-and unit-testing extremely difficult. Addition-ally, DynamoDB’s primary querying mechanismis through simple key-value searches; however,given our GraphQL structure (described later), thisis extremely cumbersome and we needed the abil-ity to query based on a complex host of parame-ters. Additionally, given how interrelated our datais, DynamoDB’s lack of foreign keys and links be-tween tables was a clear disadvantage.

Given all of these problems with DynamoDB,we found that MongoDB addressed man of theseconcerns. MongoDB’s collection and documentstructure is extremely flexible; documents canhave different fields and attributes present with-out causing consistency issues because they areretrievable in a JSON format. Additionally, Mon-goDB allows for querying input parameters whichwould enable our application to search for veryspecific documents. Given that this is an applica-tion that could quickly grow to many users givennetwork effects, it is also important that MongoDBis very scalable.

After deciding on MongoDB, we created 3 mainmodels: User, Goal, and CheckIn. The Usermodel keeps track of all of an individual user pro-file details, a user’s friends, user created goals,and any collaborated goals. This structure allowsfor an almost relational structure where documents

point to other documents using an ObjectID. TheMongoDB schemas are included in the Appendix.

4.4 GraphQL

The past 10 years have brought new changes torouting APIs and as such, we wanted to makethe best decision about how we would set up ourclient-server routes. The two options we con-sidered were REST and GraphQL. While RESTis still far more popular in most applications,GraphQL has gained popularity because it pro-vides a well-defined interface between the clientand server. A GraphQL server is extremely trans-parent and implements exact formatting whensending back responses to the client, allowing theclient to predict nested JSON structures. Thiswas an important factor for us to consider becausewe query deeply nested and related data from theserver on almost every client interaction.

The main performance indicators that we eval-uated GraphQL on were the following:

• Request Round-trips: GraphQL allows forjust one single request on page load by lever-aging nested responses. For example, to loadthe public goals of a specific user’s friends,REST would require that we implement andadd individual routes for each part of that re-quest.

• Overquerying: GraphQL lets clients specifyexactly what information is needed from thedatabase. For example, to load the titles ofpublic goals of a specific user’s friends, wedon’t need to grab the entire user object orgoal object (only the relevant parameters).

We defined our GraphQL Schema early on, anditerating on it throughout. This Schema is avail-able on exactly one endpoint, the GraphQL end-point; we use the express-graphql library to assistin setting up this endpoint.

Clients are able to issue two types of requests,Query and Mutation (Appendix A1), through aJSON string in the request body. A Query consistsof all possible requests that do not write or updateany document in the database; for example, whenthe client requests for Dashboard goals, this is aQuery. On the other hand, when the client wantsto write or update data, they issue a Mutation re-quest; for example, when the user wants to createa goal, the request would be a Mutation instance.

One major issue with GraphQL is that it po-tentially overextends the database. GraphQL re-solvers execute independently; in other words, thenested structure means that a resolver executes forevery single field in the query. This can oftenmean that a resolver runs duplicate queries to thedatabase. Because we run our MongoDB instanceon the cloud, every request to the database can in-crease latency. We utilized caching to help reducethis problem as much as possible (more on this inthe Evaluation section)

4.5 React.js

For the front-end, we decided to use Facebook’sopen source library React. One of the major bene-fits of React is the JSX language. This made man-aging the top level code simpler without havingto worry about deeply nested components. More-over, React also promotes re-usability. A lot ofour applications relies on the repeated renderingof certain components such as a Goal-Card usedin different contexts. The JSX language and thesystem of creating a bunch of components thathave implicitly individually managed states anduser defined event handlers made our front-end de-velopment experience more painless.

React also increases the speed of rendering ofthe web-page, one of the critical measures of suc-cess for a web-based application. The open-sourcelibrary essentially optimizes the rendering of theDOM and makes it so that the client browser mini-mizes un-necessary re-computations upon any up-dates.

5 Evaluation

5.1 Quantitative Evaluation

Note that for the following section, there is a widedistribution of times solely because networking re-lies on a lot of different components in the In-ternet. There are a lot of moving parts in eachAPI call, from hitting our Heroku server to hit-ting an Azure MongoDB deployment. Any jittersin network connection, packets being dropped orTCP connection status will lead to natural varia-tion which is what is shown in the Appendixes.

Throughout the development process, we havebeen focused on evaluating our technical decisionsto make sure that we have an efficient applica-tion. There were two main areas we focused on:1. Server-side caching and 2. Asynchronous fron-tend requests.

5.1.1 BackendAs mentioned previously, with GraphQL, therewas a fear of overextending the database by is-suing too many requests. This increases the timethat it takes for the server to send a response backto the client after a request. So, we discussedthe possible solutions for this and decided to usecaching/batching to limit database over-extension.The main caching that we used using the Facebookopen source Dataloader library. This library givesa simplistic approach to caching that reduces thetime is takes for resolvers to execute. We decidedto measure the time it takes for a GraphQL queryrequest to complete and how long it takes withand without caching. We used the Apollo Tracinglibrary to track the performance of our improve-ments.

We found that caching improves the averagequery time from 347.2 ms to 172.6 ms, a 50.2%speed up. A visualization of the distribution of runtime pre- and post-caching can be found at A2 inthe Appendix.

5.1.2 Front-endOn the front-end, we noticed that we were issu-ing large queries to the back-end on content-heavypages such as the dashboard and the explore page.We specifically evaluated the front-end on the keymetrics of full-render time and load-balancing.We measured load-balancing by calculating thetime difference between the route that took thelongest to return and the route that took the leasttime to return. The underlying theory behind thisis that parts of the page loading quickly while oth-ers load slowly results in a displeasing and unevenuser experience. Load-balancing also reduces theamount of time it takes for the web-page to fullypopulate. It has been shown that long render timesnegatively impacts a company’s bottom line aswell as consumer engagement.

To collect our data, we experimented with abunch of different payloads (various sizes) that areused to populate our explore page. We created abaseline where we requested and received all ofthe necessary data in one API call. We then cre-ated a set of variations where we broke up the re-quests into several API calls. We empirically mea-sured how long the application took to render us-ing the Network waterfall graph that is built intoinspect element.

The results of this experimentation are shownin Appendix A3. The end-result is that we man-

aged to deconstruct the explore page into 4 load-balanced queries that balance the trade-off be-tween too many sequential data-base queries in aroute and routes that are too slow to return. Em-pirically, we found that this breakdown resultedin a 45.6% improvement over the baseline, from400.78 ms 217.9 ms with an average load-balancespread of 47.8 ms.

We show a plot of the render time and load-balancing metric in Appendix A4. for the baselineof acquiring all the information in a single routeand our best-effort optimized version of splittingthe render into 4 concurrent queries.

5.2 Qualitative Evaluation

5.2.1 Beta Rollout Evaluation

Because of the COVID-19 situation, it was diffi-cult to on-board a large number of users for testingand feedback, so we rolled out the Beta version toa limited group of people which included familymembers and Team 11: Spry. We surveyed theseusers for feedback on the user interface and expe-rience of the web application. We also used thesurvey to get a self-assessment of how effectiveGoal-laborator was in motivating them to set andcomplete goals while keeping the focus aroundwellness. Of the users that tested our application,91.7% collaborated on goals (Appendix A5) and66.7% found that the collaboration increased theirmotivation, while the remaining felt neutral (Ap-pendix A6). Every single one of these users sawan increase in their goal achievement since join-ing the application (Appendix A7). The social as-pect of the application motivated about 66.7% ofthe users, while the remaining were either neu-tral or only slightly intimidated (Appendix A8).Of the users that did take advantage of the col-laborative abilities of the goals, all of them ex-pressed an improvement on their general well-ness (Appendix A9). A majority of the feed-back we received was to further expand the ca-pabilities of the application by facilitating morecollaboration through the user interface and vali-dating collaboration by tracking friends’ progress,but overall the survey indicates that Goal-laboratorwas able to improve user wellness and motivateusers through collaboration and competition ratherthan intimidate. The user survey can be found athttps://forms.gle/JzLnaPPpJJRpChMP6.

5.2.2 Detailed User Studies

Below is our plan for a detailed user study thatwould have run for about 2 months. We wouldhave chosen a pool of around 100 volunteersacross all schools here at Penn. We would havethen randomized them across two groups. For onegroup, we will ask them to write down a few goalsthey want to accomplish at the beginning of theexperimental period and send them periodic re-minders to record down in a Google form howmany times they accomplished the goal and whenthey did so. For the other group, we would havegiven them full access to Goal-laborator and havethem use the features as intended.

The user study will likely allow us to get valu-able feedback on the improvements offered byour application. The initial step of randomizationacross two experimental groups will help controlfor any heterogeneity or idiosyncratic differencesbetween the two experimental groups.

After collecting the data, we can calculate sam-ple averages on how frequently people are check-ing into their goals under a Poisson count model.We will calculate for each group, what the propen-sity and count is of a user accomplishing theirgoals on a weekly basis. We can then perform ahypothesis test under the null hypothesis that ourapplication does not offer any significant benefitsover a self-managed goal-tracking system. Thiswill let us get potentially statistically significantresults (at a 0.05 or lower confidence level).

Moreover, by collecting data on when peopleare checking into their goals, we will be able toglean on an individual level what drives peopleto complete or fail to complete their goals. Wecan analyze this data to make decisions on howwe want to improve our application from a UI/UXperspective (eg. notification timing, layout). Wealready have this data collected in our applicationdue to check ins being assigned time stamps. Wecan also collect data on engagement levels (bothfrequency and recency are interesting) to modelthe stickiness of our app and see how much peopleare actually using it.

We also planned on supplementing the efficacymeasures with a more qualitative survey (similarto the one described in the previous section) sentout four or five times during the duration of the pe-riod. This feedback will give us valuable insightsinto what is working and what is not working forour application and let us iteratively perform up-

dates to the feature set and user interface to makethe application more acceptable to our target audi-ence.

6 Societal impact

6.1 Positive Social ImpactAs alluded to in the previous section on moti-vation,we realized that a major problem amongour peers is that they do not have much time forthemselves. Due to a myriad of reasons includingPenn’s culture, general workload and social expec-tations a lot of people are unable to enjoy theirhobbies, achieve wellness goals and maintain theirhealth.

By creating a safe-space where friends are ableto collectively work on achieving goals, we hopeto act as a major driver of improvement on studentwellness and mental health. By creating a systemthat induces friendly competition and promotessocial accountability we hope to ensure people cancreate, achieve and maintain both physically andmentally healthier and productive lifestyles.

We hope the design of our application will helpcreate additional benefits of deepening friend-ships and allowing students to become more well-rounded as they explore the goals and interests ofthose around them. However, we truly believe thestructure of our application with the closed net-works, opt-in only goal collaboration and the bi-furcated news feed with the user’s first touch pointbeing their own goals will truly allow people to fo-cus on improving and de-stressing themselves pri-marily with a healthy supplement of other people’sgoals if they so choose.

6.2 Negative Social Impact and MitigationStrategies

6.2.1 Privacy ConcernsWith any social media-like application there areinherent risks of privacy. The data that users inputinto the goal creation forms on our application ispotentially extremely personal and private. Whilemany goals are innocuous such as playing an in-strument or going on a run every day, there aremore sensitive personal goals that are potentiallyentered on our website regarding important sub-jects such as mental and health conditions.

While our team has tried to mitigate this by col-lecting minimal amounts of personal information,the stark reality is that in order to identify indi-vidual users and allow their friends to find them,

names and emails are needed. As evidenced bynumerous privacy case studies (Netflix leak) a lit-tle bit of self-identifying information can allowan intelligent adversary to link sensitive informa-tion to individuals in real-life. The informationcan also allow for the inference of factors thatmake up an individual’s identity such as politi-cal stances or sexual orientation. It must be notedhowever,that because our system operates on thepublic and private goal system, an adversary willnot be able to view the more sensitive goals a userhas created, unless they manage to break encryp-tion or gain unauthorized access to the database.This dichotomy of the two types of goals serves asanother way for our application to help maintainuser-level privacy.

There are also potential concerns regarding thenext steps of our application, especially the rev-enue model. The most pressing concern is thatif companies are choosing to sponsor our appli-cation, these companies will want metrics suchas user demographics, interaction data and loca-tion data regarding engagement with their adver-tisements or sponsored goals. It will be hard tocompete with other platforms that willingly col-lect and monetize such sensitive data. As a result,we are planning to be firm in our negotiations withpotential partner companies in the interest with re-maining compliant with consumer data protectionlaws as well as re-doubling on our commitment toprotect the privacy of our users.

6.2.2 Vulnerable GroupsWe believe that there are not any targeted groupsthat will be marginalized by our application. Theunderlying premise behind the application is anetwork of mutual support. However, we haveidentified certain groups of individuals that mightbe particularly affected by the potential stressesof a social network. Individuals with low self-esteem may feel slighted or helpless if they seea lot of seemingly confident peers accomplishingamazing goals. This could result in processes ofself-destruction and a further loss of self-esteem.Moreover, socio-economic status could also playa role in this. Some users may create goals suchas going to expensive tennis lessons that could re-highlight the drawbacks associated with an indi-vidual’s status quo. Ultimately, these are concernsthat will occur in any sort of social network. Wespecifically did not include large social networksinto the mix (such as a Facebook or Instagram in-

tegration for friends); this means that users can de-liberately become friends with people they thinkwill motivate them. The audience and groups weenvision targeting are likely to create a supportiveas opposed to toxic environment, which will likelyhelp mitigate this risk.

Moreover, another concern is that we may beexcluding people who do not have access to the In-ternet or technology. We believe, however, is thatthe modern college student spends most of theirtime on their laptops and their phones and collegesprovide financial support to those that cannot af-ford it. It is simply the reality that technology is abig part of our lives. Simply put, people who insiston not using any technology are definitely not partof our target audience.

6.2.3 CybersecurityWe see the potential of certain cybersecurityrisks. Any web-hosted application has the poten-tial to be afflicted by risks such as the databasebeing hacked, user-information being leaked,cloud-abuse (spamming the server and denial-of-service), data loss due to hardware failure andform-jacking. While many of these things arevalid concerns, we do not see them as particu-larly large issues especially as we are in the test-ing stage of development. Deploying onto AWSor Azure, with native cloud security and load-balancing built in will help mitigate these issuesnaturally.

In addition, we plan on taking a few other nec-essary precautions. For instance, we made surethat the passwords are encrypted and salted onboth client and server side to ensure security. Thisposes a widely known risk of crackers being ableto use the same passwords for different user ac-counts as people tend to re-use passwords. Wefurther made sure that when our site is hosted,it has an appropriate SSL certificate and that allcommunication between client and server is end-to-end encrypted. Moreover, the session manage-ment that is done on the server side as opposedto the client side will help with not allowing usersto impersonate each other’s logins- the tokens andcertificates generated are not easily spoofed.

6.2.4 Deception and ManipulationWe see the possibility of manipulation and decep-tion from legitimate users of the applications. Theapplication we built does not have an actual wayof verifying users actually completed a goal to its

entirety or that the check-ins and updates are le-gitimate. A truly airtight system could necessitatemutual verification systems between friends withpictures serving as proof or geo-location data asproof of an action being accomplished. However,this raises a myriad of other concerns both froma technical and privacy perspective. More impor-tantly, such a system adds a large degree of com-plexity from the end user’s perspective and createsadditional barriers to usage that will negatively im-pact the stickiness of our app. As a result, we de-cided to rely on the fact that our social account-ability from a close friend group will ensure usersstay honest and that the target audience of the ap-plication is unlikely to engage in subterfuge.

Another source of potential manipulation is thatpeople may make unwholesome goals on the ap-plication. We implemented a feature that bucketsgoals into categories such as Hobbies or Wellnessto serve as a reminder to the user that the goals onthe platform should be inherently positive. This,however, does not prevent or disallow for toxicand negative descriptions of the goals. A naturalsolution to this that we discuss in the next sectionis using Natural Language Processing to tag anddisallow goals that do not fulfill a set of positivitycriteria that we laid out.

6.2.5 Unintended ConsequencesOne of the long-term unintended consequenceswe envision could stem from Goal-laborator mir-rors the fate of popular social media platformstoday such as Instagram and TikTok. Theseplatforms suffer from the creation and idoliza-tion of influencers (such as Charli D’Amelio onTikTok and Kendall Jenner of Instagram) whichleads to a community based on a culture of tox-icity and a never-ending goal of achieving a sortof “perfect life.” While the core functionalitiesof Goal-laborator focus on the interaction be-tween close friends, our planned features regard-ing more global penetration and sponsorship couldinevitably lead to fan-out that could spiral into aculture of toxicity.

We have attempted to mitigate this issuethrough a number of features. Specifically, by us-ing bi-directional friendships, we make it muchmore difficult for influencers to rise. A collab-oration requires both individuals to press acceptor add friend. Apps that have created culturesof idolization (TikTok and Instagram) use a uni-directional follow feature and we hope the bi-

directional feature will help prevent this. Anotherfeature that speaks to this problem is the creationof private goals. Theoretically, an individual coulduse the application to solely keep track of his orher own goals without worrying about people orviewing other people’s global goals. This featurewill also help slow down the proliferation of idol-ization.

Another unintended consequence we envisioncould occur is that Goal-laborator uses gamifi-cation and competition between friends to helpachieve social accountability. This raises the po-tential problem competition could work in directopposition of Goal-laborator’s fundamental goalof wellness. Competition can brood ill-will andcan induce significant amounts of stress in users.We mitigated this risk by minimizing the amountof notifications (as evidenced by our pivot to a webapp as opposed to mobile app) to reduce stress andtry to encourage users to only use this app withtheir close friends. The hope is that anyone usingour app has wholesome motivations to empowertheir friend group to do more.

Third, another unintended consequence thatcould occur is that we could see goal homogeneitywithin friend groups. This could potentially be anissue as friends converge and collaborate on verysimilar goals which could work directly in contrastto our goal of helping people become more well-rounded. To help mitigate this potential pitfall, wehave ensured that the landing point of the applica-tion is always the ”For You” page. A user alwayssees his or her goals first before seeing any friendsgoals. This will force the user to focus on his orher existing commitments first and put their owninterests and goals first.

To further mitigate this issue of homogeneity,our ”Explore” page requires a physical opt-in inorder for the goal to show up on the ”For You”page. Pressing the button requires a sort of com-mitment, and by displaying all potential collabo-rations, we allow users to have an unbiased andholistic view of what is out there.

7 Final Thoughts

7.1 Discussion and Lessons Learned7.1.1 Story-boarding and UX DesignThis project helped us appreciate the importanceof story-boarding in the process of UX design.Story-boarding allowed us to quickly narrow downthe needs and use cases of our intended users and

figure out what was the overall objective of theapp. Story-boarding is a cheap and easy way ofeliciting requirements from the end users as wellas establishing a general direction for developmentwithout requiting too much code overhead. Westarted out on paper and then moved towards pro-totyping in Figma. As a result, we believe wesaved a massive amount of time and effort lateron by going through the entire story-boarding anditeration cycle before finalizing and then creatinga finalized user experience.

7.1.2 Database Design and RefinementOne of the biggest lessons we learned as a resultof this project is the importance of good databaseschema planning and management. One of theissues we ran into early on was that we did nothave good communication between the back-endand front-end in terms of what queries and infor-mation we need to extract and display as well aswhat frequency. This led to a constant reworkingof schemas which would hinder our progress as wewould have to go back and add things or changequeries around. Additionally, a poor initial designof the schema also resulted in our having to imple-ment joins in MongoDB when we needed to getthe information out of multiple datastores whichincreased the computational complexity and in-creased the response time of our backend. A betterschema, which we moved towards the end, helpedreduce these overhead costs and resulted in a moreseamless application.

7.1.3 Cross-Origin Resource Managementand Session Management

Another issue we had was the interaction betweenCross-Origin Resource Management and SessionManagement. With improper management, ses-sions would not take hold- a new session would es-sentially be created on every single API call whichmade server state impossible to maintain.

This issue was tricky to debug as it made usdo a deep-dive into how different web browserswork. For instance, Firefox and Chrome have alaxer security policy- they let cookies be set fromcross-origin sources. That means, if you make anapi call to sampleclient.com and sampleclient.comre-routes you to sampleserver.com which sendsa packet telling the browser to set a cookie, thetwo browsers will accept the cookie. As it turnsout, this leaves the user open to a cybersecurityissue- cross-site scripting. Browsers such as Sa-

fari prevent that from happening. The original is-sue stemmed from the separation of the client andserver on two separate Heroku deployments cou-ple with HTTP header issues. Getting around thisissue required a deep dive into managing HTTPheaders on each API call we made, as well asthe eventual decision to make static React filesstatically delivered from the same server as thedatabase.

7.2 Moving Forwards

Our vision for the application was unfortunatelycut short by the onset of the global COVID-19Pandemic with everyone being sent home and un-able to work together in person. As a result, therewere a couple of features that we hoped to imple-ment that are the logical next steps of the applica-tion we deployed.

7.2.1 CompetitionIn future iterations of this application, we wouldhave liked to improve the competition aspects ofGoal-laborator (according to user feedback) to in-crease the odds users complete their goals. It isimportant to note that we need to find the strictbalance between friendly competition and causingundue stress on our users.

Specifically, we are hoping to implement aprogress bar on collaborated goals that displaysthe progress of all of a user’s friends on a goal.This progress bar would require a user-click to be-come visible as opposed to an immediate render,which should reduce the stress on the user.

We also plan on implementing badges that showup on a user’s profile from a both a personal andpublic view. These badges can be broken intotiers and act as rewards for people checking inand earning points. By using badges as opposedto an explicit leader board, we are hoping to cre-ate a sense of competition and reward without ex-plicitly ranking users in a stack ranking system.Such stack ranking systems used in workplaceshave been shown to cause undue stress and reduceperformance.

7.2.2 Natural Language ProcessingAnother issue that we were thinking about is whathappens if an adversary decides to make negativegoals on their profile. To help solve this issue, wewere considering implementing a hybrid of rule-based and automatic sentiment analysis to flag ad-versarial goals.

The approach we first considered was training aneural net on open-source data-sets to build a Nat-ural Language Classifier. In its most basic form,basic sentiment analysis (Stanford has an opensource pre-tagged database) could give us a proba-bilistic measure on how negative or positive a goalis. Note that this could produce some false posi-tives as some perfectly acceptable and wholesomegoals geared towards self-improvement may havenegative language or sentiment. To rectify thiswould require us to make our own labeled data.However, for a proof of concept, the pre-labeleddata is sufficient.

We can couple this Neural Net with a rule-basedsystem that flags some inherently negative senti-ments and words. Goals that display a high pro-portion of negative words can be flagged and cancatch any errors the neural net makes. A problemwith this rule-based system is that it is likely tobe incomplete. Constant fine-tuning and updatesto the list of negative words or diction/syntax thatdefine negative concepts is expensive.

7.2.3 Lightweight NotificationsWe also hope to implement a lightweight notifi-cations feature that will occasionally nudge usersto complete goals if they are falling behind sched-ule. These nudges are psychologically importantto help people stay on track of their goals. How-ever, we want to minimize the presence notifica-tions as to not cause stress. A good way to achievethis would be sending digests or goal-progresssummaries every other day to keep users updatedon their progress and remind them to check-in.

Referencesa. Habitica.

b. Habitshare.

Streaks.

Prescient Strategic Intelligence. Wearable fitnesstrackers market overview.

Sijia Yang Damon Centola Jingwen Zhang, De-von Brackbill. 2015. Efficacy and causal mechanismof an online social media intervention to increasephysical activity: Results of a randomized controlledtrial. Preventive Medicine Reports, 2:651–657.

Joseph D. Harrison Mitesh S. Patel, Dylan S. Small.2019. Effectiveness of behaviorally designed gami-fication interventions with social incentives for in-creasing physical activity among overweight and

obese adults across the united states. JAMA Inter-nal Medicine, 179(12):1624–1632.

Nicole L. Pesce. This was the hottest app trend of theyear.

Chrstianna Silva. The millennial obsession with self-care.

A Appendices

A.1 GraphQL Schema

A.2 Quantitative Evaluation: Graph 1

A.3 Quantitative Evaluation: Graph 2

A.4 Quantitative Evaluation: Graph 3

A.5 User Survey Results: Chart 1

A.6 User Survey Results: Chart 2

A.7 User Survey Results: Chart 3

A.8 User Survey Results: Chart 4

A.9 User Survey Results: Chart 5