Schedule Map
Fall 21 Spark Project
Introduction
Schedule Map is a Google extension that helps students visualize the location of classes on a map with traveling time between classes. It warns students from registering for classes that have a limited travel time frame and help students optimize their exploration and experience at UC Davis. Without a doubt, Schedule Map would be a nice addition to Schedule Builder, helping students familiarize and visualize themselves within a huge campus ground.
The Team
Minh-Tu Nguyen — Project Manager
Bianca Law — Designer
Jessica Hua — Designer
Arthur Gan — Developer
Kalyan Survana — Developer
Eugenia Zhang — Developer
Ethan He — Developer
Ethan Luu — Developer
Timeframe
Oct–Nov 2021 | 6 weeks
Tools
ReactJS
Google Map API
Distance Matrix API
Geolocation API
Figma
Project
View a demo of our project below!
Design
Users
UC Davis students who want to enhance and find balance in their courses and experience on the UC Davis campus by making informed decisions during course registration and scheduling.
Process
Our design process was split into: empathizing with the users, research, ideating, prototyping, usability testing, and revising. Due to the iterative nature of design, we moved between the processes throughout the length of the project.
We began our research with user interviews, surveys, and comparative analysis. In our user interviews, we asked open-ended questions related to students’ transportation around campus, class schedules, and their important factors for an efficient and enjoyable experience on campus. We then created a survey with similar questions but with options to collect a more precise dataset. The interviews conducted allowed us to collect qualitative data and the survey gave us quantitative data. The comparative analysis for map applications helped inform our map design.
We were able to conclude two pain points through the user interviews and surveys. The first pain point is that students struggle to get to class on time for back-to-back classes and the inefficiency when using multiple tools to consolidate information about their courses, location, and time.
We synthesized our research using affinity mapping and found three main insights from the interview and survey. The insights were that there are time constraints for traveling between consecutive classes, students have to use multiple tools and apps to do simple tasks, and students struggle to find new locations on campus without seeing a map beforehand.
Using this information, we created a user flow and persona to assess ways in which ScheduleMap would be used and who would use it in the context.
Our design began with the consolidation of the sketches, then we created iterations in multiple rounds of mid-fi design. Some issues we encountered during the design process was the balancing between conveying the optimal amount of information versus cognitive overload.
After completing and prototyping the design, we conducted moderated and unmoderated usability testing with 4 UC Davis students. For unmoderated testing the users explored Schedule Map freely, but they were given tasks to do for moderated testing. We asked them to do the following:
- How long would it take you to go from Silo to Wellman
- Do you have overlapping courses?
- What do you think about the bus system and how intuitive is the extension overall?
The goal was for students to figure out how long it would take to get from one class to the next on their schedule and to see if there was any conflict between their courses. After we received feedback from testers and developers, we had several more rounds of iteration and usability testing.
We found that users were confused about the bus system because due to lack of spacing so we separated the terminals. A toggle system was implemented for users to switch between the different modes of transportation (bike and walk) and how long it would take to go from an on-campus building to the terminals. The colors in the extension are the same colors on Schedule Builder to make the extension more cohesive with Schedule Builder. Additionally, since Schedule Map is a new extension, users would have to go through an onboarding process to have a better understanding of the extension.
Development
Stage 1: Backend
Web Scraping
The extension map popup requires course information, including (for each saved course) the meetings(lab, discussion, lecture, etc.), the locations of the meetings, the times, and the days of the week that they occurred on. In addition, the markers need to match the colors that the Schedule Builder website uses to display each course in the calendar, so that data has to be retrieved as well.
The first issue was that any scripts that were part of the extension popup would run on the separate webpage that the popup displayed. The web scraping script needed to run on the website that was open in the browser. This was solved by having the web scraping be done on a content script, which runs in the context of the web page and not the extension popup.
The actual scraping is fairly simple, and is done through querySelectors. Manually looking through the schedule builder website’s html elements helped to identify certain CSS classes and id’s that were used on the elements that displayed the needed information. The script would then use querySelector to look for html elements with those particular CSS classes and id’s and retrieve the data from the found elements, usually through the inner text.
The information is then shared between the web scraping content script and the extension popup through a JS messaging function provided by chrome that allows data objects to be sent from one tab to another, extension popup included.
Distance Matrix
In order to get relevant up-to-date information regarding the distances and walking and biking times between classes, we needed to utilize some sort of distance matrix service. Initially, we went with the standard Google Distance Matrix API to make a call using Axios from the Google Map’s API, however, we ran into issues with this as we ended up having to use Heroku in order to implement this method. We ended finding a workaround to this and ended up using Google’s alternate distance matrix service specifically directed towards javascript projects that are less database-driven such as this one. This method didn’t require the use of Axios and we ended up writing two javascript files: fetchwalking.js and fetchbiking.js. These two react components utilized Google’s Distance Matrix Service to get the walking and biking duration between classes respectively. In this way, we could call the react components from anywhere within the app and use the relevant information where necessary.
Geolocation API
One of the functionalities of the extension map is displaying dynamic markers for the course meetings each day. However, the Map API requires latitude and longitude coordinates in order to place down markers while the web scraper can only retrieve the location as a partial address.
The Geocoding API, which is part of the Maps API, takes a request in the form of an address and finds the corresponding latitude and longitude coordinates. After the web scraper retrieves the course data, the Geocoding API script takes the partial address for each course and uses it to request the latitude and longitude. The response is then stored inside an object array, which is passed to the Map display.
An issue that occurred was that the partial address provided by the web scraper (e.g Walker Hall 21) would sometimes be ambiguous, and the Geocoding API would match that to the wrong location. This was fixed by adding ‘UCD CA’ to the end of the request address.
Cookies
As we wanted an onboarding process, or tutorial to go with the extension that explains how to navigate through the extension, cookies were required to ensure that the tutorial is only issued once. In order to do this and make sure it does not keep bugging the user every time they open the extension, we decided to place cookies in the user’s browser so the program is able to determine whether or not the user has already seen it. So at the end of the tutorial code, it stores cookies within the user’s browser and it checks for the cookie every time the extension is opened.
Stage 2: Frontend
Google Maps API
One of the first stages of development was displaying a custom UC Davis styled map. We utilized the Google Maps API for the actual display, but ran into some issues when attempting to use Cloud-based styling for the customization. After spending a lot of time researching and asking for help, we decided switched over to the more familiar JSON styling. This took more time and effort individually, but ended up being even better suited for the customization we were aiming for. The end result is a version of the official UC Davis campus map with a semi-static border to prevent users from scrolling too far from the campus.
Markers
After getting the map to display, we worked on getting the markers to show up. The two static markers that indicated bus stops were pretty simple to implement. The more time-consuming portion was creating the dynamic markers. These had to inherit not only a class location, but also the color used on Schedule Builder for the corresponding class. First, the address was scraped from the website and the latitude and longitude were produced by the Geolocation API to position the marker. The corresponding color was scrapped and matched to preloaded png images. For a final touch, the text color was also scraped from Schedule Builder for better readability on markers with a darker color.
Class Displays
In terms of displaying the user’s courses in a readable and interactive way, we created react components called courseBlocks which acted as each of the user’s individual classes. These courseBlock components are color coded to reflect the coordinating color shown in the schedule-builder’s calendar feature. The information used to fill these courseBlocks majorly came from the web scraping script which got the useful information such as the course name, course id, course times, and course location. These courseBlocks are also reactive as they change depending on both the current day and transportation-mode tab the user has selected. This was implemented by giving each of the tabs a certain index which would then relay the change of that index to the react component that displayed all of the different courseBlock components. As such, navigating through the extension was simple and readable as the user could look at each day and transportation method separately at their own leisure. These courseBlock components are styled with flexbox to create a visually appealing UI.
Distance Displays
To display the relevant information attained from the Google’s Distance Matrix Service as well as the web scraping script we implemented a drop down that indicated walking and biking times between classes and UC Davis’ bus stations. This drop down was implemented within each of the courseBlock react components so that if a user were to click on courseBlock it would display relevant information regarding travel times depending on the selected transportation method. In order to make these drop downs reactive to the different transportation methods we utilized a similar tab index system that we used in the days of the week tabs. In this way, users could easily click on each of the different transportation methods and the drop downs would instantly change and display updated information retrieved from the distance matrix service. Since the courseBlock components themselves are reactive to the days of the week tabs, the distance display drop downs worked reactively as well and changed along with the days of the week tabs. As a result, we simply had to fetch the current course location and the next course location and the distance matrix service would automatically fetch the correct travel time between the classes.
Switching Day Tabs
Whenever the user switches between tabs that represent the days Monday-Friday, a day index that correlates to a specific day gets updated through a callback function. The day index is then passed down to React class components that display the map and list of classes on the extension pop-up. Then, the class components utilize the day index to access an object within an array that has objects for each day M-F. This object is another array that contains objects that represent the classes for that specific day and each class object comes with information (location, start time, end time, name, etc.). By getting the array with class objects for the day tab the user is on, the class components can attain details about the classes and the locations and re-render the map accordingly with new class location markers and update the list of classes for that day with accurate information.
Warning Display
Along with re-rendering the map and list of classes for that specific tab, each time the user switches between the days, a React class component that displays warnings is called. In this class component, the day index which is passed down is utilized to access the array of classes for the specific day tab the user is on. A loop is run through the class objects for that day to check if any class overlaps another. A warning sign is rendered on the top left corner of the certain blocks that overlap with another class. Additionally, a message stating that there is an overlap is displayed when hovering over the warning sign.
Tutorial
The designers designed a thorough tutorial that is straight forward in terms of how to navigate throughout the extension and how the UI works. This required a few components with the main functionality revolving around a button to take the user to the next page of the tutorial. Thus, a function for our buttons was created that would immediately switch what screen the user was on depending on which part of the tutorial they were at. This would only prompt what needs to be seen and hide any useless information. Using the initial designs and adding the buttons on top of them we made it extremely easy for the user to navigate through the one-time tutorial without any bugs or errors.
Takeaways & Challenges
Challenge: Time
As the fall cohort is limited to only six weeks total for design and development, the project must be completed in a timely manner. This limited the number of features that could be implemented. During our original discussion of the project, many ideas and features were brought to our attention that had great potential in being implemented. Due to our restricted time limit we had to restrict ourselves to only a few key components.
Takeaway: Cross-functional Team Environment
This cohort emphasized the importance of having a cross-functional team environment between both designers and developers. This produced quality discussion and planning of the product, joining together ideas of what was possible and what was a good idea. Team members were able to consult one another with their specialties while also experiencing how a real industry team works together.
Closing
Schedule Map will be up on the Google Chrome extension store at the beginning of 2022. We hope our fellow Davis students find use in our product and find it useful in planning and visualizing their future classes. Thank you to CodeLab for allowing us this opportunity to build Schedule Map and further our software development skills this cohort.
