googleinterns / trace

5 stars 2 forks source link

logo-1-named (1)

Project TRACE

Google STEP 2020 Intern Capstone
dterr@ ccjeane@ erickez@ - Travel Planning

Objective

Our goal is to build a product that provides users with information to make educated decisions about when and where to conduct their daily tasks in light of the COVID-19 pandemic. We believe that individuals do not know to what extent their local businesses follow social-distancing and other safety guidelines and, therefore, cannot accurately manage their risk as they accomplish their daily tasks. This product aims to ensure the safety of our users and the mitigation of COVID spread. We are committed to following HIPAA guidelines without compromising the integrity of our product. This website does not aim to serve as a contact tracing or coronavirus tracking database, but rather a tool for users to measure their own risk by identifying and understanding other relevant metrics such as a location’s precautions and localized coronavirus prevalence. This allows our users to complete errands while better understanding the precautions being taken within their communities.

Background

Background As the COVID-19 crisis evolves, users continuously face the problem of completing essential tasks in their daily lives but expose themselves to the risk of contracting the novel coronavirus as a result. We have designed a web app that our target users can use to plan out their daily trips, guided by the knowledge of a particular location’s willingness and ability to carry out and enforce social distancing and other safety guidelines to prevent the spread of the novel coronavirus in their establishments. Our site was motivated by the need for accessibility, since those who may be at risk since these individuals will need to be more careful about exposure to large crowds to mitigate exposure to the virus. We believe that individuals do not know to that extent their local businesses are following social-distancing and other safety guidelines and, therefore, cannot accurately manage their risk as they accomplish their daily tasks, we hope that implementing this project, can help ensure our users’ safety and the informed and increased mitigation of COVID spread.

Requirements and Scale

Our target user will have some familiarity with web apps and will be capable of navigating such sites as Google Search and Google Maps at basic levels, since these will compose the majority of our user interface. Our users will be searching for ways to monitor the risk of coronavirus exposure in their community. They may already watch the news for daily changes in new cases in their region and invariably wear a mask when leaving their home, but would be interested in further minimizing their risk of exposure when accomplishing daily tasks. Using existing APIs, we hope to find ways to inform users of nearby social behaviors and adherence to safety guidelines by organizing relevant information and data on our site. By displaying this data in an easily digestible format, we enable the user to make informed decisions about when, where, and, potentially, if they should seek to accomplish particular tasks throughout the day, according to their needs. Our project’s MVP will not depend on either reviews from Google Maps (as originally intended) or on COVID statistics, though we included the latter as part of our final product as an extension rather than as a core feature. As it stands, COVID cases are reported on a per-county basis, so while we cannot fulfill one of our original goals of assigning each location with a COVID risk factor, we have incorporated a heatmap that allows users to get a general idea for how their region is doing based on these higher level reports. This being said, even this data is in jeopardy given the recent redirect of COVID reports to the Trump Administration which we fear may create a gap in the data pipeline and render existing COVID metrics inaccurate. We have chosen to move ahead with our project and use prior data as a proof of concept, but will not be able to guarantee data accuracy ourselves. As for the key stakeholders of our product, these will be individuals of the public, the essential businesses that are included, and workers at COVID testing locations.

Back-End

The datastore consists of Entities of three types: Places, Comments, and Votes. Places and Comments are virtually represented as custom Java objects. As shown above, the Places Entities mimic the PlaceReviews.java object, while the Comment entities mimic the Comment.java objects. Individual votes on comments are hosted only in the datastore. Each entry in the datastore is an internal id used for querying and storing the objects. The Google Places/Maps API provides each Place object with an ID, which we use as the both datastore ID and PlaceReviews.place_id. This PlaceReviews.place_id corresponds to the id listed within the Comment.java, as it tethers the object to a certain place. See datastore design doc for more details. Datastore overall design (1)

Front-End

We took as much of a what-you-see-is-what-you-get philosophy as possible when it came to designing our front-end. As a result, we optimized our front-end to bring forward as many features as possible for users to easily navigate the site. We moved our search results to the side-bar rather than our original overlay of the screen so that users can explore results on the map while seeing more thorough details just beside it. We have also moved our search bar to the top navigation bar so that it doesn’t cover any portion of the map. These changes allow the users to see as many features as possible side-by-side to avoid the need for exploring, thus increasing our site’s discoverability. Furthermore, our site also includes the option to display or hide, as well as adjust our covid heatmap, in conjunction with a light/dark mode option to maximize the user’s ability to customize the dashboard to their liking. new-ui

Searching For Locations

Users can either enter a query into the search bar or click on the map to retrieve search results for places they would like to look at reviews for. It automatically searches around their location for the query. If a user would like to look at businesses in a specific place, they can use the “Located by..” bar and put in a city, address, or zipcode to search near. If a user has a preference for how far they would like to travel, they can type in how many miles to limit the search radius to. Once the search results have appeared, users can decide to sort them based on the distance from the result to their desired location or the overall safety rating of the business. For example, a user wants to look at food options in their area to see the safest place to eat dinner later that day. They aren’t currently at home, but they know they want to stay within 5 miles from their house, so they type in “Food” in the search bar, their zipcode in the “Located by” bar, and “5” in the “Miles Away” bar. The site then looks within that radius and gives them several options for where to eat. They decide it’s more important for them to choose a safe location, so they sort the results by rating. Then, they make their decision! Interacting_objects (1)

Voting on Reviews

Once a user has decided on a business, they can look at all of the reviews for that location. Reviews can be sorted by relevance, recency, and rating. If they are logged in, they can vote on a review (and unvote/switch their vote). Within the datastore, each vote is stored as a comment id - user pair, and contains the value of their current vote (either positive, negative, or null). When users change their vote, the datastore value is modified as well.

HeatMap

The site’s heatmap displays a metric that sums up 3 primary metrics: how many new cases a particular county has per day, how recently the cases were reported, how dense a given population is. For a more thorough discussion of the design and development of this metric, see our heatmap design doc. Furthermore, we have also afforded the user the ability to toggle the data shading between two gradient options, the ability to toggle the map background between light/dark color-scheme, and the ability for users to adjust the density and opacity of data that appears on the dashboard so that users can customize the map to their liking.

Alternatives Considered

Alternatives Considered Why We Leaned Away
Focus primarily on showing users the
distribution of other users at a
given location and incorporate COVID
stats for area or location to determine
risk factor for a given errand.
Wanted to reduce dependence on COVID data
and did not feel comfortable creating our own
“risk factor” metric. We also found that the
existing Places API visitor customer density
information was identical to the feature we
hoped to implement so we were not adding value.
Provide recommendations as to when users
should do their errands based on a
predetermined risk factor.
We decided not to go this route because of
difficulties finding accurate data,
potential bias / trust issues.
Focus on helping users compare COVID stats
across regions to plan larger trips rather
than local trips.
Again, we wanted to reduce our dependence on
inconsistent COVID data and want to focus our
attention on helping users improve their daily
lives and risk management rather than only
infrequent trips.
Provide users ‘Popular times’ information
on our core reviews page for a given location.
This information is easily accessible to users on
the Google Maps core site and was not readily
available to us, so we decided the extra efforts
to find and import this data would not be worth
having data that users already have easy access to.