Underpath

I do not live in a city with extensive subway. I am a native of Georgia, and people basically drive everywhere. However, I have always been intrigued by the mass transportation in large cities, and I have heard those who were my friends, relatives, and strangers talking about how irritating and disorienting it can be in subway stations.

I still recall viewing videos and articles by people in New York, Chicago and other cities discussing their commutes. They would talk about the stations with broken signs, flickering lights, messy curricula design in which you could not know what train was heading where. I remember one of the stories which involved a very old gentleman who jumped on a platform due to the inability to see where the edge was, as it was dark in a station. That really got to me. They are not just inconveniences. These issues are hazardous to certain individuals.

I began pondering over why this information is very difficult to locate. You can check whether there is an elevator or escalator at an outlet, however, you cannot simply check whether the signs are legible and whether the lighting is clear. Such information is present in the minds of people, in their day-to-day life, and it does not get stored at any point. And I wondered, what can be done to crowdsource all of that! Suppose commuters are able to share what they observe, and such information can be useful to other individuals and perhaps even motivate the transit organizations to improve some aspects.

That is what Underpath is all about. Although I am not a subway rider, I thought it would be interesting to create something that would benefit the millions who are.

It was a project that made me go far beyond my comfort zone. I was familiar with React to some extent, but it was the first time I developed an entire application with a connected database. I made a big step towards learning Supabase. I needed to learn how to design database tables, write SQL queries, and configure security policies in such a way that anyone would be able to make any rating without being required to create an account. I had so many instances in which I was staring at the messages of error, attempting to determine what had gone awry.

I also got to know how to use the maps at the first place. The fact that Leaflet has been used to present markers that are interactive, was cool, albeit to a pain. It was harder to get the map to render properly within a React application than I thought. Even small details such as ensuring the markers appeared in the appropriate locations and the popups were functioning correctly took a lot of debugging.

At a larger scale, I got to know a lot about accessibility as such. My prior understanding of accessibility was related to ramps and wheelchairs. However, in the course of research and contemplation on what items to incorporate in the ratings, I understood that there is so much more to it. Lighting, signs, level of noise, easiness of having to be able to determine where to go. Everybody is impacted by these things but those who are either older, those with visual or hearing impairment, or those ignorant to a station are the ones who are affected. I now have a far better understanding of the number of small things that are involved in making a space really accessible.

I began by asking myself what information would be of use to gather. I arrived at six classifications as signage readability, lighting, platform periphery visibility, confusions in route, navigability ease, and comfort such as noise. They can all be rated out of 1 to 5 and an evaluation can be made of a general view of the station accessibility.

On the tech stack, I developed React as the frontend and TypeScript. TypeScript enabled me to uncover most of the bugs at an early stage and this proved to be extremely useful when the project became complicated. I took Vite as my build tool due to its effectiveness and speed. As far as styling is concerned, I chose both Tailwind CSS and shadcn/ui components, which allowed me to create a decent looking interface without spending hours on CSS.

Frontend is powered by Supabase (an essentially hosted PostgreSQL database with an inbuilt API). I established three tables: the table with the names and coordinates of the stations, the table with the single ratings people leave, and the analytics table to monitor the number of the ratings that people leave. I have created a database trigger that automatically computes the average scores of a particular station every time somebody rates a particular station.

The map is made on Leaflet by React Leaflet. The stations appear as coloured dots. Green indicates good scores, yellow means fair and red indicates that the station requires work. On any station, you can also come and get its detailed breakdown or leave your own rating.

I created the entire application to have a transit theme with yellow and black stripes that resembled the warning strips found on edge of platforms. I would have liked it to be more attached to the subway experience despite the fact that I was constructing it on my room in Georgia.

To be beginning with, it was pretty much an uphill task since much of this was new to me.

Probably the most difficult component was the database. I needed to learn SQL immediately not only simple queries but such things as triggers and functions which automatically run when the data is modified. It took a multitude of attempts to get the aggregation of the rating to work. I kept on getting snagged where the averages would not refresh or would burst in with erroneous numbers and I had to go through my code like a detective to isolate the snags.

The map gave me trouble too. React does not necessarily get along with Leaflet as React renders differently. The map would come up blank in some instances or the tiles would not load or the markers would disappear when I left out of the page and returned. I got to know so much about the lifecycle of React and avoidance of such hiccups, but it was a frustrating experience then.

Design was another struggle. I am not a designer, and creating a visual of something that appears professional is not as easy as it seems. I had to go through hundreds of versions before I settled on one that seemed like it was not a simple homework assignment. Even the trifles such as putting the logo to the right or precise placement of the spacing between things cost much more time than I had guessed.

However, the greatest obstacle was simply persevering when things were not going right. And nights when I would like to give up, and one bug would give birth to two others. The reason I continued was due to the fact that I am thinking of the individuals that this app can assist. Although I do not ride on the subway, I am aware that there are millions of people who take the ride, and some of them find it very difficult to cope with the poorly designed stations. When this application can change their lives even slightly, then it is all worth the frustration.

At this moment, Underpath has sample data of several NYC subway stations, but the main one will be actual users reporting actual ratings. I would like to increase to more cities and more transit systems. I would like to include things such as the user account to allow people to keep track of their contributions, filters to seek the stations based on the criteria of accessibility, and perhaps a method enabling transit authorities to see which stations are the most in need.

I also would like to make the app easier to access. The development of an accessibility rating app which, however, would not be accessible would be hypocritical, and thus I would like to include better keyboard navigation, screen reader support and high-contrast, among other features.