Background :
The United States is a name that loudly screams the idea of unity and singularity. However living inside the walls of the country, one can be quick to realize that the state next door might as well be its own country. In fact life styles and standards and economies of all the different states can vary drastically, which can make the life of an American nomad a difficult one. A house in one state might cost multiple times more than a similar house in the next state. Same goes for income, weather, job opportunities, and population density, which are all things a person might want to consider before packing their bags and moving where the dart lands on the map.
Citrics is an online free to use web application that allows users to quickly search up their cities of interest, and compare them based on statistical data that might help them decide whether or not a city is a good candidate to become their next. Finding the right city is an important one as this is the place that will surround your life on a day to day basis. It will predict what kind of homes and apartments you can afford, what kind of jobs are available and in demand to help you keep affording your habitat, what kind of weather you will have to be prepared to walk through on your way to work, or even from your front entrance to the door of your car, and will be a deciding factor on whether or not you will be able to feel at home in the place you reside.
The rabbit hole of code:
As a web developer, there is never a shortage of things I can learn. Once I’ve learnt something, the two options before me are always; what should I learn next or, how can I get better at what I just learnt. Citrics is an application that had certain components that I have yet to have a chance to work with. Going into the building of the application was like the calm before the storm of a football game. A slight chill in the air and the curiosity enveloped by the unpredictability of what is to come. In this case, up until this point, I had yet to find the need and chance to learn of all the different ways to visualize data on the front end. Something that I had always been meaning to get around, but was not precedent enough that I thought was necessary of me to draw time away from my other learnings and projects to delve into. Finally it was time, but as with anything code related, there was always a rabbit hole of information to sort through before the learning actually occurs. An array of different frameworks for data plotting was instantly disposable as soon as I searched relevant key terms into google, and then came the question of whether or not to use a framework, or build it from scratch. It was a little frightening, but equally exciting like the climax of a good thriller, I was excited to dive in head first to see the wonders of the ending, but nervous about all the different ways this key decision could play out.
Planning a project:
From the first meeting with the stakeholder, my team and I had quickly built up an army of creative ideas on how we might build and design the application, but before we got ahead of ourselves and think too deeply into features that might not make the cut, it was important for us to plan. Every big thing is composed of smaller components, and when thinking about building a web application, it is very important to break down the entirety of the application into smaller parts that will tread the path towards the end game.
A rather fun phase within the development cycle of the application is planning out all the different features the application will come to adopt by production. My team and I decided on using Trello to help us note down and make decisions on which user stories should be included in the final product. By thinking of user stories, we can quickly decipher what features might add to the overall experience of those who might use the application. We used Trello to brain storm all the different user stories that a user might look for in an application like the one we were planning on building, and by noting down all the different user stories, we could come to understand the different possible user flows of the application, as well as come to terms with all of the different engineering challenges that we would be facing on both the front and backend of the project. Breaking down a project in this fashion makes a large application as simple as building a bunch of little bricks in which we can piece together to produce a complete and fully functional application.
Decisions:
For the development of Citrics, I worked with 3 other developers on the front end. My task for the project dealt with the core functionality of the application, which is to be able to select cities, and to display the data visualization for the cities. When my team and I were tasked with building the application, there was already an application deployed. The stakeholder wanted something different, something that made the user flow of selecting and comparing cities easier and more intuitive than the version before. The greatest challenge of this project for my team and I was to decide whether or not we were going to build off of and change the original repo, or to rebuild from scratch to ensure the code base would be specially tailored to how we envisioned the new application. We chose the latter because after looking over the original code base, it was clear that the team before us built it in a very unforgiving away as the code was entangled in such a way that would ultimately mean completely breaking the application every-time we would want to change any of the existing components, and my team wanted to change a lot, and thus decided it would be easier to start fresh rather than trying to rework their code in such a drastic way that it would be unrecognizable in the end none the less.
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 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.
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.
- 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.
- 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.