I’ll give a brief overview of the project to add context. The project is essentially creating an interactive React-based UI, using a map with Mapbox GL JS. The users are intended to both engage with and perform coverage analysis of specific data within the maps.

Triumph. My Success.

I have been working mainly on what could be described as a Setup for the main page. Recently, I implemented a feature for the project that allows a user to interact with the UI. The user draws a shape and retrieves the data within it to be included in their tailored data set for analysis.

Initially, what I had available to work with was, the large CSV dataset in the backend, and a component to retrieve this data that had already been completed by another team member. Mapbox also has a built in tool available with the Map component we are working with to perform this action, known as MapboxDraw. The challenge came through adapting it to React-Typescript.

While the tool works visually, it doesn’t automatically generate the data without creating a custom control that connects to actions performed on the map. I was able to get this feature to work, so that the user can draw a shape, get the data within the shape, and remove data from the filtered dataset.

Breakthrough. Tipping point.

Initially I was not sure of the best approach, whether or not to create a new Layer on the map or use a supplementary library to filter the data. I eventually learned that using an analysis tool like turf.js was the better option for this portion of the project due to the dynamic nature of the interactivity and how varied the locations could be. If I were to go the route of creating a new Layer, it would require creating one for every location.

Once I decided on a path, my next step was getting the data from the drawn shape. As mentioned previously, this required modifications made to the custom control I had built. I discovered the reason the tool was not functional was that the “actions” being performed on the map component were not correctly connected through this control. This mattered because even though the Draw tool was creating a visible shape, the points it was making were not referencing the map correctly. This results in a lack of data being generated. Once I figured out how to properly do this, the rest of this feature fell into place.

Reflection.

The Technology.

Up until this point in the project, I had been using the Mapbox technology “out-of-the-box.” As our project is developing an interactive UI, I had been focusing more on the visual aspect. Once I started to get into the functional part, I naturally developed a much more in depth knowledge on how Mapbox works, what its capabilities are, and how to modify these for use with other libraries. This led to a cascade of enhanced understanding of the language being used (Typescript), responsiveness, and performance qualities.

Myself.

I increasingly read through documentation when working on projects, but reading them for problem solving is more enlightening and engaging than reading purely for information. This is an obvious statement, but thinking through how I have approached projects in the past, it hasn’t been an intentional practice for myself. This has led me to some inefficient practices up front, that I would like to adjust going forward. Rather than spend so much time gathering information, I see myself creating a list of problems or unknowns, and setting out to seek definitive answers for these as a way to organize and economize my time.

What is your favorite technology from your project and why?

The capstone project has been an overwhelming abundance of new information, including new libraries with Mapbox GL JS and Chart JS, new languages in Typescript and .NET, and new methods of development with Docker. The standout piece that I have been most excited to delve into has been Mapbox. While it is challenging to learn, the documentation is thorough and well-organized, lending a sense of confidence to a beginner such as myself. The beautiful visuals that are produced are inspiring as well, as I have an appreciation for aesthetics.

What is it used for?

Mapbox technology is used for location and navigation services. It uses vector tiles and style rules in Javascript to render dynamic, highly interactive and customizable maps. Some of these features are 3D points of interests, distance from point to point by driving, walking, or biking, and powerful searching capabilities. It can be utilized by web, mobile, and gaming applications. Essentially, if there is a need to incorporate a map into an application, Mapbox is a provisioner.

How could it be made better?

This is a pretty great technology. Knowing I am not fully adept at everything it has to offer, and speaking as a beginner, take this with a grain of salt. The place where I could see improvement at this stage is with their Mapbox Studio application. This is where a where a user can create their own map, including downloading their own datasets. It’s not entirely intuitive getting started. It’s not necessary as a developer to use the Studio, but it also isn’t entirely clear if this is for developer’s. Meaning, if there are benefits or downsides to using the application versus developing locally.

I highly recommend just even following one of the tutorials on the Mapbox website, it is really fun, and highly satisfying to see your map come together in real time.

3 pieces of advice for better group collaboration

I think about communication a lot, it’s a topic I have always found intriguing. There are layers to it, among some of them – body language, shorthand, slang, context, word-choice, tone, humor, emotion, subtext. Technology has added a virtual medium, which creates another interesting communication dynamic. It can also eliminate some of the aspects that people have been used to and rely on, creating potential challenges. In a remote educational setting, oftentimes with asynchronous availability, this has been evident.  

Approaching the capstone, I thought it would be beneficial to reflect on some of my past experiences working in a group project. There has been what I would call, both high and low collaborative efforts. In all cases, I have taken valuable lessons to carry forward. I have decided on three to share.

1. Be willing to adapt your own communication style and schedule

I like to start early, communicate often, and spend extra time if necessary to produce a quality project. Thinking I could lead the group to adapt to my personal preference led to poor collaboration. People are in different time zones, states or countries, and have varying priorities due to competing schedules. This may mean settling on less communication through the week, but ensuring the quality of communication is clear. It may mean focusing efforts on other projects and regrouping when the whole team has the time. A degree of adaptation is essential. 

2. Be transparent

Being a complete beginner at the start of the program, meant there have been many times I have felt like a fish out of water. It can be intimidating to work with people who are already in the industry, or ask questions in a public forum that reveal your newbie status. But, errors are inevitable. You kind of just have to get over it, say you are lost, state when you mess up, ask the dumb question. I have found that making yourself vulnerable is part of the learning process. People are more often than not, very willing to help or direct toward the right path.

3. Be comfortable with ambiguity

There may be a degree of uncertainty in how people are interpreting your emails/texts. You may consistently wonder if your teammate was joking or not. You may never have a consistent work pattern from week to week. You may frequently question whether or not others are receiving your communications. Ultimately, there is a shared goal of completing a project. At the end of the day the most important factor is moving toward the finish line.