The Experience of Development
By: Kevin Lam
Tags: Frontend Development, Learning To Code, Coding, Programming, Backend

One of the main features we wanted to rebuild was the user flow in which a user can select multiple cities in which to compare with another. I wanted to build it in a way that a user knew exactly what they were capable of doing without having to test for themselves how many cities they could compare at any given point, whether or not they were still able to add more cities to compare, or if they had already reached the limit, as well as making a quick and accessible way to add cities to the list at any given point in the process of the application.

The simple ternary statement used to render the city card or a placeholder in the footer bar.

The way I went about solving this user flow was by creating a collapsible footer. I wanted it to be collapsible so that users could minimize it at any time if they felt like it was intruding on their screen space. However the footer bar acts as a reference in which users can see the cards of their city populate the footer as reassurance that they had selected the one they intended to do so, or remove that card if it was not. Another feature I thought was important are the placeholders that take up space in the footer when there is a possibility of selecting another city in which to compare. The placeholder can be clicked on at any point within the application as a quick access point to get back to the search component, in which they can find another city to compare with the rest if they so do choose to do. The footer I think is a clear and definitive representation of what the user is intended and allowed/able to do. It implicitly shows them that this is an application built to help users compare cities with one another, and that a user can compare up to 3 cities at a time. The simplicity of the footer is enough to display the capabilities and limitations of the application to the user, so that they do not have to wonder and test for themselves, which I found to be something that was lacking in the previous build, as there was nothing guiding the user towards what they are able/suppose to do.

SQL queries used to insert the scraped data from old database into new database.

One of the biggest challenges of this project was that we did not have access to the previous backend API repository for the previous build in order to build on and edit the tables to our new needs. This wasn’t as big of a problem as it was not hard for us to start the Java Spring backend from scratch, building it specifically to our own specification. The biggest problem however is that the data science API that the first team used to populate their backend database with, was down and also unavailable for us to redeploy. So the greatest dilemma was trying to figure out how we would get all of the statistical city data into our own, new database. There was another data science API that was later made available to use, which would include having to completely disregard all of our architectural plans for the application as this new API did not have capabilities of returning a complete city object with all statistical fields, rather it only had a bunch of different endpoints which allowed for very specific comparisons between 2 cities. Luckily, before it was too late, I had the idea to scrape all the the data from the old backend API, as the old backend was still deployed, and with a combination of 2 of the endpoints they made available, we were able to pull a complete list of all of the IDs for each city, then loop through the list of IDs to pull the complete city object from the old database and save it into our own.

The future of the project:

The current state of the application as it stands right now is a fully functional application that meets our MVP specs when we set out to rebuild it. It includes a complete list of features that we initially intended on building. Some of the features of this application as it is right now include:

Pulling all cities from the backend to render on the home screen/search component.

A live search bar that will filter through the cities as a user types.

Live filtering of cities using the filter options available in the search component

A live filter component that will filter through the cities as users enter the preferences related to population, population density, average cost of rent, and average cost of homes.

A collapsible footer bar that holds three placeholder cards that link directly to the search component from any screen, as well as the ability to move cards from the search component to the footer as users select cities.

Using the Plotly framework to render data visualizations of average and historical values.

A comparison component that displays visualized data in both average values on a bar graph, as well as historical values on a line graph to allow uses to compare statistical points.

A user profile that allows users to log in if they are interested in the benefits of having an account, such as saving their favorite cities.

The future of the application is still in progress. There is definitely more styling to do on all the components, but we were mostly aiming on getting the core functionality and user flow working as something to show the stakeholder of the project. We hope to be able to scale the application better, including refining the filtering process for rendering all the cities on the search component to make loading such a large amount of cities quicker. We also hope to build onto the use profile functionality of the application but opening up possibilities of allowing users to leave their own ratings and reviews of different cities and grow the application in to a Yelp like social media application, built around cities rather than food, where people can not only learn from the statistics of the cities, but also from what other users might have to say upon visiting or once/currently residing in the city. We also have more statistical information within our database that is not currently being put to use, which we plan on incorporating into the comparison view page, so users can learn even more about the cities they are interested in.

A game of teams:

Working on a team is always something to be valued. There is simply just so much one can learn when working with others, especially working on new teams with others whom you have yet to meet. Everyone you work with is another chance to add something new to your arsenal of skills. All the new view points you take away from the way they work really adds a new perspective to how you might solve problems in the future. This group in particular taught me a lot about taking initiative and facilitating discussions and problem solving as a group. In most cases in the past, there had always been someone who prominently stood out or even was assigned to be a team lead that would lead the group and split up the tasks. This group however, did not have a predominant leader from the start, and so it taught me to take initiative and do the necessary steps to make sure everyone is on the same page and knows exactly what the next steps are. This team gave me a lot of experience with working with others. It was not the first group project I had worked on, but it was the first group project in which the entirety of the application, aside from certain MVP specs, were set and decided on by every individual of the team.

As a developer and software engineer, working on a team is the norm, and learning how to work on a team well is just as important as knowing how to code well. There are so many benefits to working on a team, most of them go without having to say, and in order to achieve and make use of all those benefits, I think it is really important to focus on learning how to contribute to the team, which is something I will always carry with me in my future endeavors, and always work to be better at.