Citrics a city metrics app
Planning
For the last handful of weeks during the “Labs” program at Lambda School, I’ve been working with five other full-stack developers and four data scientists in order to create a city data visualization app called “Citrics”. Citrics was created to give users who are looking to make a move in the future but aren’t quite sure where they want to go. The app’s main goal was to give the user the ability to search for Cities and compare their characteristics side-by-side in an intuitive yet informative fashion.
From a distance this user story is a very simple yet broad experience. User’s must be able to search cities and receive data following that search. The first task was deciding what relevant data the viewer should be returned. Our data science team decided on a few simple characteristics like ‘population’, ‘cost of living’, and ‘weather’. Once this decision was made they began to search the web for reliable data sources and access methods. For this project they mostly did web scraping and used a few open source api’s. Once the data was decided upon we were informed that our data science team would also be servicing another web development team leaving their work cut out for them.
With this in mind we decided to build a middleman java back-end with the spring framework to not only handle user data but also store and serve city data from the data science teams database to our front end. This seemed a bit redundant from a distance at first. Why pass the city data through the backend if the front end can just access the data science teams database directly from the frontend via get requests? Well, two main reasons really, the first being that it would reduce the workload on the data science teams’ backs leaving them to worry more about gathering and cleaning data instead of how the front-end will access it and two scalability. If for whatever reason this app grew in the feature we might want to store the city data behind some sort of authentication barrier. Let’s say some specific characteristics can only be seen by premium users who are paying a monthly membership premium. We could easily assign roles to those users in the back-end and handle access permissions on a case by case basis.
All that being said we were only sitting at a very basic user story that needed to be broken down into much more digestible and specific steps in order to be handled by multiple team members. This was one of my biggest concerns with the project as a whole. This was going to be my largest collaborative development process and while having so many developers in the codebase sounds powerful it also sounded like it could be chaotic without making sure everyone was moving in the same direction at all times. We decided to use a dynamic list management app called trello to visualize our each task in our products user stories paired with an app called whimsical to draw out our architecture plans flowcharts, and then used a combination of figma and whimsical for our front-end wireframes.
Here are some of the diagrams we used when setting things up.
Flowchart
Technical Research
Architecture
Rough Mobile Wireframe
Figma Detailed Mobile Wire Frame
I’m specifically proud of the Figma wireframing because I did most of the work on it. This was my first time using figma and all though it took me a bit of time to get to know how the application works I really felt like it was necessary to have a very detailed wireframe reference with so many developers working in the front-end codebase from the get go. Like I said before, keeping everyone on the same page is essential when you’re working together in the same codebase and deciding the styling as a team from the start enables us to all know where we are going.
Development
I mostly worked on the front-end of the app and with the wireframe being so detailed it really made progression fairly linear. We would reference a few components in the wireframe each day and build them on a day to day basis splitting each component into multiple tasks. One of the technical challenges we faced was when data science informed us they would also be collecting historical data over time. Previously we were only expecting single values for things like weather and population then displaying them on a bar graph component. Now we would be receiving a whole array of objects, each with a time metric and an associated value. We had to adapt the functionality of our data results on the front end to incorporate this new data. We decided to add a toggle to each city characteristic giving the user the ability to view the data as an average value (bar graph) or view it historically over-time (line graph). Because I had already set up the search results with redux global state management it actually made the process fairly simple on the front end and on the backend if we didn’t have an average value we decided to just take all the historical values and average them together to create one.
Conclusion
In the end we managed to hit our mvp without too many problems as well as adding a few stretch features like user login and favorites. Searching cities and comparing data is really intuitive and informative and the styling turned out very close to what we originally wireframed.
Some gifs of the project!
Something I really would have liked to have gotten done was the ability to search by city characteristics opposed to searching by city name. The historical data kind of threw us of course from achieving that one. Doing it would be very simple on the front end seeing as how we would just be reusing components we have already developed but we would need to write a filtering algorithm in the backend that accepts a get request with user selected parameters from the front end. Lets say you wanted to view cities with a population of 100k-200k. After selecting those input fields on the front-end a get request would need to go to the back-end that iterates over the database returning cities in that range. It might get a bit more complicated if you wanted to service multiple city attributes selected by the user but it would be best to start with one attribute and build up from there. Overall I really enjoyed working on this project and learned a lot about leadership and teamwork. I received some feedback along the way from team members who let me know that I could try to distribute the workload a bit more evenly in the future in which I definitely agree. Sometimes I tend to do a bit more than my fair share of work and need to do better to trust that my team members will contribute just as much as I will. After I received the feedback I made sure to be more attentive in making sure each bit of progress was much more inclusive and to keep everyone equally involved. I feel like this project has given me a better idea of what it’s like to work with multiple concurrent developers as well as team management skills. I feel pretty lucky to have gotten such a great set of team memes while working on it.
