Make It ’til You Make It
Glossary:
- TPL: Technical Project Lead
- AWS: Amazon Web Services
- UX: User Experience
- UI: User Interface
- API: Application Programming Interface
- CRUD: Create, Read, Update, Delete
Introducing Family Promise
Attending Lambda School has been a great experience for me. I’ve learned more than I could have imagined going into the course. For those unfamiliar, the course ends with something called “Labs”. Labs is a month long project where a randomly assembled team works on creating or iterating upon a real life application. The project has stakeholders, and eventually — end users. The application that my team and I worked on for Labs was for an organization called Family Promise. Family Promise taps into existing local resources to empower families towards economic stability. They help families rebuild their lives with new skills and ongoing support. They do a great job, but were looking to implement a monitoring and evaluation platform geared towards data collection, monitoring, and viewing metrics — that’s where we come in!
This application is important to Family Promise for many reasons. One of the main reasons is funding. Family Promise is a non-profit and as such, they rely heavily on grants and funding from the state. The caveat is that they need to provide data showing that the money they receive is actually being used to help out the community. This application will help immensely in that regard. With custom metrics, Family Promise will be able to show how many families are receiving services, how much value there is in those services (represented by a dollar amount and/or “units” where applicable), geographic location of services, logs of all of the services provided over a given time frame, and much more. This data is incredibly useful when applying for funding and provides measurable results demonstrating the impact of the organization.
Another benefit of this application for Family Promise is that it can be used to track services provided in a certain geographical area. This is valuable information for a number of reasons. Family Promise can track which locations may need more or less funding, more or less staff, or adjust advertising in a certain area all based off of the location data from our application. Our stakeholder had mentioned specifically how valuable the information would be for tracking advertising efforts. Family Promise would be able to track how effective a given advertising campaign was in a certain location, making sure they were allocating resources efficiently based upon the data provided.
I worked on a fantastic team to contribute to this application. The team was made up of other Lambda students, some of whom were dedicated to back end development, some who were focused on front end development, and some did a bit of both. We also had a TPL assigned to our team who did a great job keeping us up to date and on target. I was one of the team members who helped out with both front and back end, although most of my focus was on front end. I was one of the design leads on the team, and was in charge of directing the application towards ease of use, and being visually pleasing in order to create a great user experience. To that end, I created user flow charts, wireframes, and Trello cards to not only demonstrate proof of concept of how the application would function, but also as a sort of “roadmap” for task completion. Being organized (and a bit of a minimalist) is something that I am good at and I feel like a big part of my role on the team was keeping things organized. By communicating with team members, hopping into lots of Zoom calls each day, and following the charts I created I was able to make sure each team member was working on something meaningful and more importantly UNIQUE! Having team members not work on overlapping features was huge and I did a good job in helping to avoid that scenario.
Discovering and Solving the Problem
Being one of the design leads and having a big focus on UX/UI, most of the code that I wrote focused on achieving a great, seamless user flow that made sense and was pleasing to look at. When I first interacted with the application, I noticed right away a major flaw in the user experience. Upon logging in, the application would route the user to their own profile so that they could edit it. So what right? Well in terms of efficiency this stuck out to me as a BIG problem. I thought about that user flow in terms of a Family Promise employee who may be actually using this application. The employee would probably be busy, probably be pressed for time, maybe not have the best connection (when using an iPad out in the field working off data, hotspot, etc.), and possibly dealing with more than one person. When just one of those factors is at play, and potentially all of them at the same time, each screen tap or mouse click is valuable. Imagine every employee, every time they log in, having to click two extra times or tap the screen two extra times in order to get to a page with relevant information for them. Over the course of a day, a week, a month, a year — that’s thousands and thousands of clicks/taps that don’t need to happen (not to mention the profile page makes API calls, so that’s data usage and slow load times if the connection is not good).
My first step in solving this problem was to get feedback from the team. During one of the team meetings I brought up this inefficient user flow and asked the team if the problem I was seeing made sense to them as well. They agreed with my assessment and that is when I started to officially get to work on some solutions to the problem. First, I broke down the problem by creating a detailed user flow in a program called Whimsical, which is just an online diagramming tool. I knew the user would need a type of dashboard in order to view the most relevant information in one place, so I diagrammed everything from the login, all the way to each individual dashboard and what kinds of functionality would be available. I used React to create the dashboard components (which did not even previously exist), and made use of Redux in order to manage state within those components. One of my favorite libraries is Styled Components and I made use of that as well. My second step was to create a dashboard for each user type (an administrator, a program manager, and a service worker). Each of these dashboards would need different functionality of course, for both security and efficiency purposes. One challenge I faced when creating these dashboards was that the backend was being completely overhauled. There were two tables made, and none of them were capable of CRUD operations, so much of the design that I implemented had to be placeholder tables, buttons, forms, etc.
This is where collaboration with my team was key. Not only would I relay to the team the progress being made on the dashboards, but I would also get updates from the back end team on how CRUD functionality was coming along and when it would be up and running. Teammates also helped with the creation of many of the forms needed to add data which was a big help. Collaboration was done mainly through Zoom meetings and through our Slack channel. One thing our team did incredibly well was pair program — if there was a bug that someone was stuck on, or even if there was one I was stuck on, team members were more than happy to hop into a Zoom meeting and work on fixing the bug together.
I ran into one other major problem when creating the dashboard functionality. The problem didn’t even have anything to do with the dashboard itself, but with routing to it after a user logged in. The way the application was originally developed, the user was routed to their own profile edit page after logging in, which the team and I knew was not an effective user flow. The challenge was getting the application to know the role of the user logging in, and use that to dynamically render the correct component dashboard. Okta was being used for authentication, and never having worked with Okta before, I was not sure how (or if I even could) grab the “role” of the user after Okta authenticated the credentials, but before rendering a new component.
My solution to this problem was simple — I created a routing page component. If the users’ login credentials were correct, the user would be brought to the routing page. The routing page would then check the information sent back by Okta, and store the users’ role in state using Redux. I then had the correct dashboard component render depending upon the role stored within the Redux store. Simple, and very effective for what we needed the application to do. There may very well be a more elegant solution to this problem, and if I had more time to work on the project I may have tried to implement some conditional logic directly in the login component, but again I wasn’t sure how to deal with the asynchronous nature of Okta authentication. Another solution I thought of implementing but did not have enough time (and the way it should have probably have been built from the beginning), would be to have only one “Dashboard” component and simply have the appropriate content render conditionally based upon the users’ role. Without having actually coded it, my assumption is that single dashboard solution would probably be the most intuitive given enough time to program it.
Once the application was able to dynamically route to the correct dashboard, there was only one more piece to add before it would be fully functional and that was the addition of two more options in the NavBar component. A teammate of mine named Alex actually took care of this part and did a great job. With the user being taken to the dashboard, we needed a “My Profile” option in the NavBar in order for the user to edit their profile information if they wished (since they were not longer being automatically routed there). We also needed a “Dashboard” option so that the user could navigate back to their dashboard if they clicked away from it at any point.
With those changes in place, the application user flow which I had diagrammed at the beginning of the project was now complete. A user would log in, be dynamically routed to the correct dashboard complete with the correct information, and still have the option to navigate away from it and back to it. Here’s an example of what the administrator dashboard looks like now:
Potential Challenges Ahead
My team and I made great progress on this application, but I do foresee some challenges in the future iterations of it. One of the big features our stakeholder wants is the ability for the application to automatically know where a user is geographically, and to pull up services/recipients in a given geographical radius based on some metrics in real time on a map. While this has been done before, and from the little I was able to look into it, it does seem like Google offers some pretty intuitive tools to add maps and some functionality to webpages. The challenge for this particular feature will come mainly from the fact that this will be a brand new API, with brand new features and code, and the functionality the stakeholder wants will probably have to be custom made (I did not see the exact functionality available from Google right out of the box, however there may be features that are close, docs, etc.). The unfamiliarity of the code and how to work with it may prove to be a big hurdle for future cohorts when working on this feature, but I’m confident they will be able to implement it.
Feedback and Growth Through Lambda Labs
Overall, my Labs experience was hectic but incredibly rewarding. I say hectic because there was A LOT going on in addition to the work being done on the application. Lots of assignments due, meetings to attend, concepts to learn, schedules to keep track of, and more going on while working on creating features for this app. However, the point of the entire course and Labs in particular is to prepare us students for the real world of development so some semblance of “trial by fire” is to be expected. But as I mentioned, the experience was very rewarding. Working on a living, breathing, real world application for actual stakeholders was great. It gave weight to what we were doing and working on a team mimicked what we may experience in a real dev job. Avoiding working on the same thing as someone else, coordinating efforts so that they come together in a way that makes sense (not to mention being free of merge conflicts), pair programming, managing sometimes conflicting schedules and personalities — all of these things are great learning experiences that can only be truly had working on a real team.
As an example, I received feedback early on in my Lambda career that I really took to heart. An instructor told me I should ask for help more quickly. I had expressed to him that I worked on something until super late at night because I just couldn’t get it. He relayed to me the importance of not struggling in vain when programming and he was right. So through Lambda, being better at asking for help even when I’m inclined to power through and finish something on my own has been a big focus for me. During Labs I really wanted to treat it like a real life dev position and so when I got really stuck on a Redux issue that had popped up, I reached out for help after struggling for about an hour. I hopped into a Zoom call with a teammate and the fix was actually something super simple. All it took was a fresh pair of eyes and they were able to spot the issue in no time. I’m glad that I reached out because I know previously I would have spent all day beating myself up over that problem and then found the answer way too late. In this way, the Labs environment was a proof of concept that I could take feedback, utilize it, and improve because of it.
So despite the difficulty of Labs at some points, I am grateful that I got to experience it and make through to the other side, and am even more excited to work on a development team now than I was prior to Labs.