Below, I have detailed my process of execution for one of the many tasks I have worked on during my time at Civilience. It demonstrates a learning curve I underwent and details the process from being stumped to arriving at a solution.

‍

Problem

In one task I was assigned, I needed to find a way to amend issues we were facing with the existing implementation of Chart.js, the data visualization library. The problem we faced was with the line chart displaying the datasets. In the case where the data were too close to each other, which was often the case, they would overlap and be indistinguishable. While changing the color of the different lines is a viable option, in our case, the color was reserved to showcase the severity of the risk factor for the given zip code and could not be changed. Additionally, even with different color datasets, it does not do much to differentiate the values when they score too close to each other. 

‍

Phase 1

Primarily, a lot of questions needed to be tackled in theory. I produced several notes for the product managers to review. In the first set of notes, I compiled information as to what alternatives we can look into including alternative chart types like a multi-series column chart, how can we accentuate the axes by dynamically or manually altering their step size, changing the line type (dotted, dashed etc), and a few other solutions. The solutions I suggested partly came from online research but otherwise, from meetings with the design team to review aesthetics and usability while I can speak to functionality. 

‍

Phase 2 

As a way to build a metric of viability for the solutions proposed, I placed myself in the eyes of the end user and asked questions about what the intended purpose of the line chart is and in what manner it aids the mission of the organization. This along with input from the design team meant for dynamically altering the y-axis to create a zoomed-in effect.

‍

An issue with this solution all along was that by altering the y-axis range to accommodate the results for the inputted zip-code, we might accidentally dramatize the charting of the data and give a skewed understanding to the reader. To amend this, we decided to use the up and down chevron arrows placed at the top and bottom of the y-axis as well as a 0 and 100 at either extremities to indicate they extend further as is visible in the image to the left.

‍

‍

‍

Execution

These amendments would need to be drawn on and as per Chart.js documentation, the technology does not support CSS alterations because it works with an HTML5 canvas element. The usage and alteration of a canvas element was quite novel to me but following the extensive Chart.js documentation and numerous tests allowed me to execute it well. I used the useEffect Hook in order to first ensure the chart has been rendered and then, place upon it an image of up and down chevron arrows, add labels on the right, and 0 and 100 markations on the y-axis. 

‍

Reflections

At the onset of taking up the task, React hooks were still elusive to me and while I had taken courses to understand the theory, I didn’t have a good grasp of them. This proved a problem because there was extensive documentation on Chart.js for its implementation in vanilla JS but the documentation for its React implementation assumes a good foundation in translating vanilla Js to React code- which typically involves React Hooks. For this reason, It took hours of reading documentations, testing code, asking for tips from fellow developers on the team, and more theory-based learning of React Hook to fully grasp it. At this point in time, I am quite confident in my understanding of the useEffect hook and its use cases and while I still have several hooks to learn, this experience now serves as a good reminder of what it takes to fully grasp technical concepts.

‍

Overall, the extensive back and forth between myself, the design team and the product managers, the process reminds me that in the real world, an all encompassing solution is rarely available and accounting for limited resources and time, conversations and meetings mostly strive to find a viable solution over a perfect solution. This is done by prioritizing what challenges need to be addressed . 

‍

Teamwork

At Civilience, I was able to experience teamwork in a workplace setting in the most robust manner. I directly communicate with my supervisor on the front end team and the founder of the organization. After spending a lot of time with Civilience and becoming one of the more knowledgeable people on the team as it pertains to what Civilience worked on previously and the goals moving forward, I began to regularly help new team members with onboarding. Additionally, after noticing the front-end team’s communication and teamwork could be improved, I gradually picked up a managerial role. This means making sure to schedule internal meetings to review progress on tasks, ask for help, and assign tasks to people. I also continued to aid with onboarding and act as a point of contact for any questions and concerns about the task at hand. This managerial role has allowed me to gain a better understanding of the bigger picture regarding the decisions behind new technologies being introduced and timelines for projects. It has also allowed me the confidence to be critical of decisions and act as a liaison for the frontend team communicating with the wider technology team.

‍