HCI Group 4 Final Project: Campus Pool

Introduction

Commuters make up a large portion of the average college student body, and they face their own unique set of challenges compared to students living within walking distance of campus. Commuters wake up earlier, leave later, and spend more time and money on driving than other college students. We understand that these are all experiences that can make the college experience more difficult, which is why we decided to create Campus Pool. Campus Pool is a free web app that commuters can use to connect and plan out trips, allowing them to schedule carpools with ease. By using Campus Pool, students can save on time, gas / parking money, and help reduce traffic by lowering the number of cars on the road!

Campus Pool logo

Summary

At its core, Campus Pool is a platform for commuting college students to connect with other commuters, allowing them to plan and schedule carpooling sessions. We landed on this idea after a group brainstorming session, in which members pitched various user groups and ideas corresponding to these groups. We knew we wanted to work on an issue where we could reliably contact people affected, and commuting students was an excellent group for us to work with.

One of the first ideas we came up with was to provide a platform to match commuters with one another, allowing them to crowdsource carpooling groups. The concept shares a basic inspiration with well-known apps like Uber, but our solution quickly diverged from a generic ridesharing application. After multiple sessions of needfinding and group discussions, we decided that it was both unnecessary and unfeasible for us to try to build payments into our app; we also learned that many users were not comfortable ridesharing with potential strangers, so we needed to cater to that desire for comfort and safety. In the end, our application became a platform where people can join carpool groups, public and private, and work within those groups to schedule their carpools.

During the design process, we utilized a number of skills obtained from the course; the first round of needfinding involved multiple interviews with potential users of the application. From there, we reflected on how some of our initial assumptions were incorrect, reevaluated our idea, and began designing low-fidelity prototypes. From there, we utilized both internal and external feedback to settle on a basic layout for a final design. Throughout the design and implementation of our final prototype, we regularly reflected on our progress as a group, and sought feedback from others as to how our design could be improved.

Once we had settled on a final design, we created https://campuspool.xyz. This website hosts our final prototype, where you can create an account, and then create/join groups and find trips with others! Once our prototype was finished, we ran our final user evaluation study to see what we did right, and what could still be improved.

Design: Ideation

The very first step in the design process was actually brainstorming an idea for the application. Our brainstorming process was relatively straightforward: group members contributed to a master list of user groups, and came up with basic app ideas based on these groups. One major restriction on our user group ideas was that we needed to be sure we could all reliably contact people from this user group. This led to most of our ideas being centered around groups associated with the university. For the actual ideas, the main limiting factor was ensuring that an implementation would be feasible given the time constraints.

Ideas for user groups during the brainstorming process

We then had to pick three groups and ideas to create a pitch presentation for; this was a very useful exercise, since we had to organize our thoughts in a way that made sense to an outside audience. When thinking about how to explain your idea to someone outside of the group, you’re forced to deeply consider why you made certain choices and how they will be perceived. After feedback from the instructors, we ultimately settled on creating an app to facilitate carpooling for student commuters.

Design: Needfinding

After settling on an idea, we created a hierarchical task analysis diagram centered on the task of carpooling to campus. Our motivation for engaging in this activity was so we could clearly define what the issue we wanted to address was. As it turns out, from the perspective of application design there are a lot of diverse tasks associated with carpooling. When carpooling, you need to plan the overall trip, including your destination and time; you need to select modes of transportation, and then you need to actually navigate and pick up the other carpoolers. Each stage of this process could be its own app, although one limiting factor was that we were not sure how much work we could get done with navigation considering our lack of experience and the relatively short time frame. We ultimately decided that we were less interested in the navigation/route finding aspect of the process, and were instead interested in helping users connect with others and plan their rides.

Our task analysis diagram

With this new insight in mind, we were ready to start the process of interviewing and engaging with potential users. The only way to know what our users need was to go out and better understand them. Each of our five group members would find a UT student who actively commutes to campus and conduct a brief interview. It was important to find participants who are active commuters to campus, since they would be able to speak to the problems and concerns associated with carpooling as a commuter. In our original interview plan, we decided to try to find random students on campus at the SAC, GDC, or other parts of campus. It is important to find random people as this varies the responses and reduces the likelihood of people behaving differently around their friends/acquaintances. If one of us could not find anyone after asking around, or were unable to make it on campus by the time we needed the interviews completed, we resorted to interviewing friends or acquaintances. The questions we asked targeted their commuting habits, their carpooling experiences, and willingness to carpool with other UT students. These were the most important questions to ask as we learned about our users’ commuting preferences, concerns, and needs.

Across our interviews, one concern was the idea of carpooling with strangers even if he or she is also from UT. If our users are not comfortable carpooling with other UT students, then people will not use the app. For example, one participant remarked, “personally, I would not be comfortable with carpooling with a person I don’t know.” There is a definite privacy and safety concern that comes with sharing a car with someone you do not know, and it was clear that some of our participants had concerns about carpooling with someone that they do not know.

Another finding that our interviewees voiced was that having to pick up other people should not increase the travel time by too much. We must find a balance between helping our users save costs while also not increasing burden. For example, one interviewee stated that a reason they might not want to carpool is because they like to be able to stick to their own schedule. If carpooling is going to add too much extra time onto their commute, the convenience of controlling their own schedule could outweigh the benefit of carpooling with another person.

Overall, we gained a lot of important insight from the interview process. First off, many of our interviewees expressed potential interest in carpooling to campus. One interviewee said, “carpooling right now is definitely a very viable option, especially in today’s climate environment.” There are also plenty of concerns associated with creating this kind of application, and so this interview left us with a better idea of the kind of app we want to create. We decided we would definitely restrict the app to UT students, and that students should have a way to only interact with people they choose to interact with. Since there were concerns about the added time of carpooling, we also wanted our app to tackle the issue of efficiently scheduling a carpool group without adding too much time to the overall commute.

Design: Low Fidelity Prototyping

Low Fidelity Ideation

After synthesizing our interview feedback and discussing our findings with in class studios, we were able to begin creating low fidelity prototypes. These low fidelity prototypes would be cheap ways for us to put our ideas onto paper and get quick feedback. We created a few wireframe prototypes that demonstrated how the app would be used by a typical user and a useful scenario for being able to see and invite past carpools. These wireframes were useful in setting a basic implementation of how our app would look like, and allowing us to focus on basic functionality without worrying too much about aesthetic design choices.

Low Fidelity Feedback

For evaluations of our low fidelity prototypes, we had two main sources. First, within the group we met and discussed what worked and what did not work about our designs. We agreed that we all liked the idea of creating groups for different students, and that it was important to be able to specify basic info about a trip such as date, location, and available spots in the car.

The second source of feedback on our prototypes was the in-class check in with the instructors. In this meeting, we received feedback on what was working with our design, and what needed to be fleshed out more. The major point of feedback here was that while the basic framework looked good, we were missing specifics on some key interactions. This made us deeply consider what specifically it would look like when a user created/joined a group, and when they created/joined a trip. These considerations would actually remain important all the way to the final implementation prototype.

Wireframe 1

Wireframe 2

Wireframe 3

Design: High Fidelity Prototyping

High Fidelity Ideation

We once again spent time during the studio sessions discussing which elements of the low fidelity we liked best and wanted to implement in the high fidelity prototype. The consensus was we wanted to include the following pages:

1. A home page that contained frequently asked questions and captures the user with some nice aesthetics
2. A trips page where users can create groups, join existing trips, and search for public trips
3. A history page that shows a user a log of their past trips with information about the start location, the destination, and the cost associated with the trip
4. An about page with some basic information about the goal of the web application and the developers who created it

We also wanted to be sure to maintain a bright color palette with cartoonish images for a playful aesthetic.

Once we had outlined these pages, we thought about the interactions that the user would have with each of them and the value they would derive from the various functionalities afforded on each page. The core features we thought would be the most helpful for our user based on our collective reflections on the feedback received were the following:

1. The ability for users to create private groups that consists of their friends and friends of friends so they aren’t carpooling with complete strangers.
2. To address the population that is more okay with people who they may not know well (or if they can’t coordinate a sustainable schedule with their peers), a public group with many trips available for users to join. A majority of the interactions associated with this feature and the feature above this one would be on the trips page.
3. The ability for users to actively join and leave groups and upon a modification to the groups and trips they are a part of, there is an instant change (or refresh) of the application to reflect these changes.
4. The ability for drivers to add a fuel cost for the trip which would show up in the trip information section

High Fidelity Feedback

The high fidelity prototype did not implement all of the features that we initially planned. This was pointed out to us when showing our prototype to others, who were unsure of where and how interactions like joining a group would take place. However, it did have a higher emphasis on the overall aesthetic of the web application which would was important for the final implementation prototype.

For instance, in once image it can be seen that a user has the ability to enter a pickup destination and a dropoff destination; this has more of an Uber or Lyft feel, which did not exactly fit the overall goal of our app. Users would be matched to groups based on the trips they needed; while this was an interesting concept, it sounded like it would be outside of the realm of what was feasible for a project with our levels of experience and time constraints.

After meeting as a group, we decided to go with a simpler group finding method using a group join code. This made it simple for users to join groups with their friends, and made the implementation easier on our end. We also wanted to introduce the idea of a public group for students who were comfortable commuting with strangers, although this idea did not end up making it to the final version.

Implementation

With a final design in hand, our first step was determining what technologies we would use to implement our application. From the beginning, the group leaned towards using a Javascript framework over pure Javascript, and ultimately landed on using React. On the backend, pretty much everything was handled by Firebase, which provided hosting, authentication, and a database. With the tech stack figured out, it was time for us to tackle the implementation.

Our simple tech stack

The first step was handling all of the boilerplate steps associated with collaborating on a web app; the most basic step was running create-react-app to generate a basic React project. Firebase CLI made it very simple for us to integrate Firebase into our React app and our Git repository. With this tool, every commit on GitHub would trigger an action, leading to the website being deployed.

From here, we set up basic routing, and laid out a skeleton of our website, with no dynamic functionality. Once the high fidelity prototype had been implemented practically exactly (minus dynamic data), we sat down as a group and looked at what was not feasible, and what was not working. Ultimately, we decided to simplify the app by focusing entirely on the interaction of creating/joining groups and trips. The primary implementation tasks from that point were supporting authentication/user accounts, allowing users to create and join groups, and allowing the creation of trips within groups. One notable feature that we had planned/discussed in our presentation but were not able to implement was a public group; in theory, this would be a simple extension of the implementation that we already have built, but we decided to focus more of our time and effort on polishing the private groups and the rest of the website.

There are also a few notable features in our design that work, but could be better. For selecting a group’s image, users are required to provide the exact URL of an existing image. We did not have time to implement storing and retrieving images on Firebase, since this uses a different database with a higher chance of having our access frozen due to billing issues. Additionally, group IDs are assigned sequentially, meaning anyone can easily join any group by selecting an ID from 0 to the most recent ID. Ideally, this group IDs would be random strings, but for the purposes of demonstrating our idea they are sequential.

Overall, the implementation of our design was a very rewarding experience. Many of us gained experience working with JavaScript on a deeper level before, and we also gained exposure to the various backend tools facilitated by Firebase. Our design did change from the high-fidelity prototype, due to limitations in our capabilities and realizations on what works and what doesn’t work.

User Evaluation

The main goal of our user evaluation was to find areas where our design fell short, especially in terms of intuitiveness and ease of access. To best judge these aspects of our app, we decided it was important for users to go into the evaluation blind. That is, we were not going to train or explain the flow of the app at all prior to the evaluation. Instead, we covered preliminary questions about their background, gave them the URL, and asked them to complete various tasks on our website. If they got stuck doing something, we would offer help and make note of this, as it indicates a potential place where our design fell short.

Our evaluation tasks were as follows:

1. Register for an account
2. Create a group, find the invite code
3. We join the group with that invite code & create a trip, they join the trip
4. They create a trip
5. They join an example group
6. Join a trip to a specific location/time
7. Review their trips in the history tab

One of our subjects was a commuter at UT, who had not organized a carpool in the past. They stated that they had some degree of familiarity with web apps, but primarily used mobile apps. This was beneficial to the study because they represent an increasingly popular user group, as more people have experience with their phone than with a desktop or laptop. The general synthesis of their feedback was that it was fairly easy to find where to do things, but there was a lack of emphasis on some important features. For instance, whenever a trip in a group is full, the only way to know this is by reading that there are 0 seats remaining at the bottom of the trip; it can be very easy for a user to click “join trip” on such a trip, and then have no idea why they are unable to join. Two potential fixes include separating the remaining seats and making the text larger/brighter colors, so it’s the first thing users see. We can also grey out the join trip button on full trips. Their other main point of feedback is that while the site does not look bad, the design can be a bit boring at times. I think this works since our main goal is intuitiveness, but it might be worthwhile to experiment with a more unique yet simple design.

Another one of our subjects was a student who went to a boarding school and commuted to that boarding school for a period of two years. They frequently carpooled with neighbors and sometimes ran into the issue of not being able to coordinate a carpool ride to their school. It semed like this subject was able to navigate our web application pretty easily and stated it it was intuitive for them. Most of the changes they recommended revolved around aesthetics. For instance, they said we could increase the amount of branding through the web application and put a logo in the navbar. They also liked the potential feature of adding gas cost information to each trip.

Our third subject was someone who temporarily lived with a friend who lives 20 minutes away. Many of his friends would also stay at this house to work on group projects. Amongst these several individuals, only the owner of the house owned a car. As a result, the others would only be able to get to campus when the owner’s schedule worked with theirs. In all other cases, the individuals would Uber which was not cost effective. This subject made some really good points about the logic of our application. Specifically, they asked why users were always that were a part of an existing group were always added to trips. They also asked how the gas cost for each trip was being calculated (which is currently just based on the distance between the start location and the destination and the cost of regular gas and the average vehicle’s fuel economy). These questions will definitely serve as important considerations for future iterations of this application.

Conclusion

https://campuspool.xyz, our final implementation prototype

Campus Pool is intended to be the one stop shop for all of your campus carpool needs. Whether you are someone who drives and is looking to split the cost of gas and parking with other friends, or simply someone who wants to get to campus quicker, Campus Pool is the web app for you.

The experience of building this website has been enriching and meaningful to all of us. It gave us the chance to think about real life problems that we as UT students face on a daily basis. We were able to think about how to develop solutions to these problems based on our knowledge from this class, engaging with the design cycle over a multi-week long endeavor. We also utilized knowledge from our past experiences from other classes, internships, and technical endeavors. From collaborating and learning new tech skills alongside people we have never worked with to applying all of the design principles we have learned over the course of this past semester to software product, I think each of us has taken something away from this project — something that we can carry through the rest of our academic and professional careers.

Links

GitHub Repository: https://github.com/trumanbyrd/hci-final

Slides: https://docs.google.com/presentation/d/1AOFeB7ejg7lrQ7ok_n8K-2s-zN5ZLCGmfvDd3Q_xRB0/edit#slide=id.p1

Video: https://www.youtube.com/watch?v=7c5j7HGV464

Poster: https://drive.google.com/file/d/1KcmiTwwFfHZgxIq9rHiR6mIvXwiM6AS0/view?usp=sharing