No Land for the Nomad: A Solution to finding your new home

Follow along with us on our journey! → GitHub Repo | Deployed App

About a month ago, a client came to our team with a vision to have a city metrics app for users looking for new homes. Our client is a nomad himself and has lived in about a dozen cities in the last four years. Researching where to live can be a hassle! You need to look at the city’s population, rental prices, and if that city will occupy your needs (I myself can NOT survive in humid climates). Many tabs are going to be open to housing sites, such as Zillow, along with Indeed or LinkedIn to find job industries in the city you are researching for. However, everything can be clean and simple with Citrics: A city metrics app, where you get all your statistics on one platform. In four weeks, our team has accomplished our first release where you can search for a city by name and see all the data for these main categories: population, rental prices, job industry, and weather.

“The journey of a thousand miles begins with a single step.” — Lao Tzu

What is the first step to creating this app? Planning, planning, planning! I feel this is the most crucial step in any project. An architect doesn’t start building, he/she begins with creating blueprints of the idea. The blueprints for software developers include user flows, wireframes, styling, and an engineering architecture model. These are all puzzle pieces that help us see the big picture, but also see the small details that need to be incorporated. Our team wasn’t sure how this app would turn out, but after a week of communicating and planning, we created that vision. The closer we got to see what our app would function and look, the more excited I was to start coding it out!

The user flow is to go through the app like a user — what would be the first thing they see? What can they click? Where does it take them? This helps find gaps in what can be accessed.
A wireframe consists of the bare bones of what the layout of the app will be. A visual representation that can easily be changed if we need to. We use this wireframe to show users and receive feedback.
Everything behind the curtain that the user doesn’t see (besides the UI) is what we draw out in the engineering architecture. This helps us determine what tools to use and dividing tasks. For this specific project, we decided not to use a login component for our first release to have simplicity.

Amping out the App 💪

The main contributions to this project were definitely working with the Data Science team to connect the live data with the app. However, it takes time to gather data and organize — or ‘clean’ — it into what our team wants. But there can still be work done while waiting. Our Web team got busy with setting up Redux for state management, laying out the app components such as the navigation bar, comparison page, and the modal for city details, and using ‘dummy data’ as a placeholder to test the functionality. By our second week of coding, we were able to connect our live data from Data Science and still have a working app.

My task that first week was pair programming with a team member to create the navigation and get the search bar up and running. Learning how to code in the same file and branch proved to need creative solutions. While using the LiveShare plugin from VSCode, my teammate and I were able to work on the same local branch and do our individual and collaborative tasks. I created the navigation bar and the drawer effect, the HTML layout of what would be seen (including the search bar input), and built an autocomplete feature using a React library called Ant Design. This was happening while my partner worked on dummy data for cities to search, and the logic used to run the search function

Citrics Landing page with the drawer navigation bar and search functionality with autocomplete feature.

A specific problem that my team and I had was with testing. As a developer, it is important to write tests inside your app to make sure everything is running properly. The human eye is imperfect and will glimpse over mistakes. Unit testing doesn’t miss anything and when we deploy, everything should run smoothly. Although we have experience testing in Jest, Cypress, and React Testing Library, we decided to use the latter. The logic of writing tests is the same on any platform, the difference is learning the syntax and its quirks. One ‘quirk’ that we discovered is having this warning pop up:

“When testing, code that causes React state updates should be wrapped into act(…)”.

The warning when we run the tests — tests pass but a huge warning arises!

Our developers spent a minimum of three days working on this bug and we still haven’t managed to get the right fix. One solution that we stumbled upon was converting the Functional Component that we were testing into a Class Component (this is like writing in cursive versus print — it has the same meaning and functionality, it’s just written a bit differently). This was a simple fix that wasn’t clear. However, when we applied the same solution to a different component, the warning still pops up.

Testing definitely has its own kinks and it can be frustrating to work with when you don’t know the dynamics. What I’ve learned is that you need more practice and new ideas. We may not have completely solved the problem, but as we continually work on it, we are gaining those experience points that will help us learn the next time we go about creating a test. Teamwork contributes well to this factor: When a team member was caught up after losing power, her experience and perspective created new ideas. For Release 2, we’ll try implementing snapshot testing or using Cypress.io since Cypress ‘sees’ the app as we do and can test those components.

The Cycle of Production:

What we’ve Done and Where we’re Going

Today we have officially shipped our first release to this app. For the environment and styling choices, we wanted users to feel excited about finding new places to live and keeping it as simple as possible since it is still a LOT of information to process. Our site includes:

  • A landing page explaining the purpose of our app
  • A left-aligned navigation bar that toggles open and close
  • Search bar to search for cities with a population of 50,000 or more
  • Autocomplete function in the search bar for easy use
  • Section to keep track of selected cities: you can either search for one city or compare up to three cities
  • Comparison page to show basic statistics for the two cities, with the option for details in a modal
  • A chart where you can choose the specific metric to compare
  • A graph to visually represent that comparison
  • A detailed page for when searching for one city including graphs

We built these tools using Reactjs, Redux, Ant Design (a React styling library) to implement the autocomplete function and our navigation bar. We used Plotly to render the graphs connected with our data and manipulated that graph to show the comparing statistics between different cities. While functionality is key, so is testing! We managed testing with Kent C. Dodd’s React Testing Library. Organization is HUGE as we handled through several components, testing files, and styles within our code.

Since we are working with an external stakeholder, his feedback and opinions are a top priority. Although we had chosen a theme to be fun and exciting, our client felt that some styling options needed to be more simple. When consulting with a specialized UI/UX Designer, we received lots of constructive feedback. The biggest advice we received was to look at other cites that have the same purpose as us and to implement that into our app.

So what comes next? Although we have created a functional app, we return to step one — the drawing board. We are in the process of brainstorming ideas and planning what we need to do for Release 2. Our goal is to make the search bar have a filter, so users can choose specific criteria and be returned a list of cities. Our Data Science team will be using the data that they’ve collected this past month to create a predictive model — what will the city’s population or job industry be like in the next 5 years? We have our own ideas that aren’t part of the Minimum Viable Product (MVP), like using Local Storage so users can keep track of favorite cities. And if there is a city that users like, there will be an option to see similar cities. Or having a more user-friendly search bar if the spelling is wrong or the search is unsuccessful, we provide a list of suggestions. There are countless ideas to make this product better. Many ideas and such little time! Stay up to date on the Citrics city metrics app and see where it ends up.

Full Stack Web Developer excited and engaged to learn!