Mapbox provides different even listeners that make it easy to react to changes with the map. There are dozens of listeners and provide everything from on load, moveend, mousedown, etc...

In the beginning, I was using the React wrapper that allowed me to add layers and sources using components like I would with anything else in React. However, I ran into a lot of issues with using the listeners provided by Mapbox and I was forced to drop down and use the Mapbox API directly. Once I had done that a few times, I decided I was better off writing the entire feature using their API. 

I've had to do this type of refactor with both D3 and Mapbox and it's forced me to think in terms of JavaScript or TypeScript rather than React. I can see myself moving more in this direction until I've given up frameworks entirely. Then maybe I'll cycle back to frameworks again with a deeper understanding of how everything fits together. Such is the lifecycle of a web developer.

The original goal was to make something generic that I could plug into any site and other hikers could utilize. The idea was to add it to my site as a proof of concept and then utilize what I've learned to make the public version.

I could have started with the generic application though. I'm still planning to make it but I would have been much closer to the end goal than I am now. However, I think building out the MVP on my site has given the boost in motivation and I now know what I will do differently.

I spend a lot of time in the Sierra Nevada and it's extremely difficult to convey just how huge and wild the mountains are. The 3D mapping capabilities offered by Mapbox allow me to convey the immense scale of these places.

3D Map

Because this app is a page on my portfolio site, I can leverage the fact that I've already integrated Sanity as my CMS. Sanity is configured so that adding a new adventure is as easy as doing the write-up and dragging my .gpx file on the document. The route, waypoints, and camera movement are all added automatically.

CMS Integration

Each adventure includes a write-up for each point of interest. Clicking on these headings moves the camera to that point on the map with pitch, zoom, and bearing customized to give the best view.

Interactive Storytelling

When using React, I find that there are many wrappers written by the community to help bridge between a library written for vanilla JS and React. Mapbox has one of these wrappers maintained by developers at Uber to help make mabpx-gl-js easier in React.

I reach for these wrapper libraries when I have to interop with APIs written in a vanilla style but I keep running into cases where I want to use functionality that hasn't been ported to the wrapper. This results in me writing code with React, the React wrapper for the library, and the library directly. 

Although the point of the wrapper is to be able to write code in a consistent style, I end up with even more complexity than if I hadn't used the wrapper. I've encountered this issue with both D3 and Mapbox wrappers. 

For this project, I've removed the wrapper dependencies and used the Mapbox API directly. It felt uncomfortable mixing DOM event listeners with the reactive state management of React, but for a project of this size, it doesn't really matter. On larger projects, I may reach for these wrappers again but for this scale, they are more of a hindrance than a help.

I love adding fun and creative visualizations to my sites but there are issues with different browsers and devices. I run Arch Linux and I've had a difficult time keeping Firefox performant on my own machine due to updates changing WebGl flags in my settings and Nvidia drivers in general. On my development machine, Firefox runs significantly worse than Chrome and it's my main browser. 

I'm going to be taking a more progressive approach to these kinds of features in the future. For example, the bubbles visualization on the other pages isn't performant enough on mobile phones so one of my next tasks is to figure out how to either increase performance or disable it for devices that can't sustain a high enough FPS. It's not as fun, but performance and accessibility should have a higher priority than aesthetics. 

I've always wanted to log my trips and adventures but wanted something that showcased my skills as a developer. Rather than blog posts with a map and some stats from my .gpx files, my trips are plotted on a 3D map where there are stories for each point of interest but also allows the user to explore on their own.

A 3D map detailing the trips I've been on. Everything from hiking, backpacking, rock climbing, and road trip adventures will be posted with a story for each.

Adventures

Some of the visualizations needed to plot a large amount of data. The now deprecated heat map of confirmed COVID cases in the US took many seconds just to fetch the data and the time it took to render the map was unacceptably long. One solution would have been to fetch the data when the user enters the application so it's ready by the time the map components mounts. However, the initial globe visualization was also resource intensive and it would delay the initial loading of the application by too long.

The solution I decided on was to initially load the globe and delay fetching the data for visualizations until a topic drawer was expanded in the navigation bar. When a topic was expanded, the data for the visualizations under that topic would be fetched. I also put the map at the bottom of the topic so by the time it was opened, it would have been ready to go.

The main downside to this was the fact that all drawers initial state was closed. From a UX perspective, it requires that extra bit of awareness to know the navigation headings are expandable. The tradeoff for performance is worth it though.

Speaking of the heat map, a few visualizations relied on a free COVID-19 API. Planet Data construction started in February 2020 and it was not clear to most people just how big COVID would be. Somebody had created an API that served collected data about COVID cases by region and all usage was free. We utilized this API for all of our pandemic visualizations but there were a few times when the API had changed and broken our visualizations.

As changes were made, we were able to alter our code to accomodate but eventually, the route used by the heat map was locked behind a paid tier. The cost of that tier was too expensive so the heat map needed to be scrapped.

Making a site that accomodates all screen sizes is easier now than it has ever been. However, there are many tricks and techniques that are specific to data visualizations and libraries for creating them that must be employed.

When screen sizes shrink, there are clear best practices for font size, paragraph width, contrast, etc... With charts and graphs, it gets a bit more subjective. Unlike text, visualizations can't be easily switched to a column format or just shrunk like an image. Layout is integral to conveying data through a visualization and the text assisting in representing that data can vary in its positioning and direction.

There are also different methods for resizing SVGs, canvases, and objects rendered with WebGL that are not encountered when making a typical text/image based site.

I'm extremely happy with how the visualizations came out and the different methods we used to build them. However, it could have been much easier.

 rather than D3 directly due to its simplicity and the ease of making good looking charts by default. About half of the visualizations were build using this library and it was an easy and enjoyable experience. Had we stuck to that, we could have implemented many more of these.

Any time we wanted interactivity, multiple axes, or a map, we had to reach for D3 directly. Prior to this project, I had no experience with D3 and it was a steep learning curve and made even more so by integrating it into our React app. The visualizations made with D3 were by the far the highlights of the app though. If I were to do this again, I would commit to learning D3 in depth and build less, but higher quality visualizations with it.

The WebGL used is entirely limited to the globe on the landing page. It's eye catching and a great hook for the app, but I believe there is a conflict with the stated goal of the project. Our main target demographic is middle school aged students and they would be presumably be accessing our app from school computers. 

There are performance considerations when using WebGL and it is possible that the devices used to access our app do not have WebGL enabled, do not have hardware acceleration, or their device may not have the performance necessary to use the visualization. I've had my own headaches with rendering WebGL after browser or driver updates on my machine running Arch.

Although the 3D globe may be the hit feature, I believe we do a disservice to many of our users by not offering a comparable fallback.

This project was a clear case in over architecting an application without solid use cases. The only global state is used for the progress bar for quizzes. Even the light/dark mode feature uses local storage. It seems silly now, but why would we need Redux and Redux-Toolkit for that?

I did end up using a lot of Redux-Toolkit's functions for data fetching and tests but we would have been without it. Our app could have been much simpler and much easier to build upon had we not over engineered state management.

Data visualizations and commentary show how pandemics, deforestation, wildlife migration, and climate change all impact the Earth in different but connected ways.

Diverse Topics

Visualizations built using WebGL and D3 can be interacted with by panning, zooming, and dragging elements with mouse or dragging on all screen types.

Interactive

Each topic includes questions based on content and teaches students how to read different types of graphs to uncover new insights.

Quizzes

D3 was very difficult to wrap my head around and the examples that are out there are unlike the JavaScript I typically write. The code is very imperative, pre-ES6, and because so much of the library is geared towards DOM manipulation, it can be difficult integrate with React. Separately, the React and D3 components would be performant, but combined, they were a mess.

 have been indispensable to me when learning D3 and they clear up a lot of the confusing parts of the D3 library and how they should be used with React. I encourage anyone struggling to pick up D3 to browse through her site.

The techniques I learned building Planet Data have been helpful for other projects and I see places to use them where I hadn't before. The bubble visualization serving as the background to this site was made in D3 and the ideas and how-to came from building Planet Data.

Mapbox was easier to pick up than I had anticipated and their API makes adding layers and styling simple. In the future, I plan to do a lot with it and making interactive maps for Planet Data has inspired me to build more apps with it. Although not used for Planet Data, I did prototype a lot of the visualizations and maps using Uber's open source visualization libraries and I look forward to using those in project in the near future.

We had spent a month planning this app out before we had even initialized a repo. All of the features that we initially sketched out from user stories were eventually implemented and almost exactly as we had planned. However, the infrastructure and technologies used were not ideal. We had a bunch of nails so we brought the entire workshop instead of a hammer.

Had we scaled this project to include a greater variety of features, we may have been grateful to have all of our infrastructure in place. But for features we had, it was a bit much. I love new technology and learning new things in development, but I will be more considerate of adding complexity to future projects.

Data visualization is a skill that STEM initiatives and NGSS standards would like teachers to focus on, but teachers are already overworked and many aren't savvy when it comes to the latest and greatest digital tools available.

Our goal was to create an app that lets students view and interact with real-world data about the planet Earth. To connect students and teachers with the world where they live.

A real time dashboard to teach middle school students the fundamentals of data visualization using real world Earth data pulled and refreshed from a variety of sources.
Built by a team of two web developers and three data scientists.

Planet Data

There are certain aspects to creating a spider or radar graph that seem obvious but they may not be totally clear at first. We decided to create a graph creation wizard that would walk a user through process while also ensuring they don't input parameters that would result in an invalid or malformed graph.

Creating a wizards requires a lot of validation logic. There are required fields, limited inputs for fields, rules for when a user can advance to the next step, and logic for how spider graphs work. 

Now that I have more experience with functional programming, I've started to use things like Maybe and Either to help keep my validation logic clear and easy to follow but at the time of building this app, creating the validation rules was tedious for me.

 to build out the spider graphs and it was almost too easy. Building out the graphs with animation and basic interactivity was actually the simplest part of the whole app. I say too easy though, because when I built graphs and charts on future projects, it was a bit of shock to see how much there was to learn about lower level libraries like D3. So much of the work with designing visualizations had been abstracted that it was not as much of a learning as I would have liked.

However, making the graphs was a breeze and I would recommend Chart.js to anyone wanting to put something like this together quickly.

A graph creation wizard walks you through building out your graph. Clear directions and validation ensures the graph looks great instantly.

Graph Builder

Beautiful default styling allows you to focus on the data and the information you want to convey. The editor is designed to make sure your graph is valid and well formed at all times. 

Intuitive Editor

Graphs can be saved for editing for viewing at a later time. They can also be downloaded as a .png straight from the editor.

Save For Later

 is an opinionated toolset for developing applications with Redux. When first learning Redux, I would continually run into areas where I had made things more difficult for myself due to early decisions. I would go through the Redux docs or check out different blog posts for the latest "best practices" and would modify how I used the library for the next project. The continual iterations were rewarding but I would mostly discover the right way by doing it wrong first.

Redux Toolkit is opinionated and simple enough that it allowed me to skip through that iteration cycle and go straight to the end. Redux Toolkit breaks up global state into slices. Rather than organize the app by component or page, features are the base block and each feature has its own slice of state.

When originally designing Spider Graph, we had imagined a Figma like editor for graphs. The graph would be displayed in the middle with a drawer containing ways to manipulate the graph on the side.

This layout is very common with apps utilizing material design guidelines. Due to this, we decided to look into Material-UI as it seemed a natural fit. It was a great decision and our app was very easy to assemble exactly as we had envisioned. The components that ship with the library look great by default and we only needed to tweak the theming a bit to give the app a bit of our personality.

The app looks professional despite our lack of UI/UX experience at the time and if I were to make a dashboard based app again, I would probably reach for Material-UI again.

Chart or graph generators are typically full of options and graph types which make it difficult to create and save charts that look nice. Spider graph specifically focuses on spider or radar graphs and provides an easy to use interface to building charts that look great by default.

Quickly create beautiful spider graphs and save them for future editing or download. 

Spider Graph

The features I had planned for the project initially were not really doable with a shader and I should have re-evaluated the scope of the project at that point. It was frustrating to feel like I was hitting a new wall each time I wanted to do something additional. Originally, I wanted more interactivity with the game. For example, manually adding gliders or other patterns manually.

I managed to make it so pixels could be turned on and off one-by-one with the mouse but I should have re-scoped the project to remove that kind of interactivity once I moved onto the shader idea.

Just using the canvas would have been the easiest to implement if I were looking for good performance without advanced game algorithms. It was a great experience learning something so far outside of what I had done before.

I used Next.js as a way to bootstrap a React project because it's quick but none of its features were used on this project. It added little hiccups to development with no benefit. I love using Next.js but there wasn't any reason for it here. On that note...

This should have been done with vanilla TypeScript. All of the logic for the shader was dumped into a useEffect with a ref to a DOM element. Not a good use of React at all. 

Three.js and GLSL used to write the game in a fragment shader. All of the state for the game is actually stored on textures. The GPU can parallelize shader calculations and provide a smooth animation even at high resolutions.

Performance

Rather than initialize the game board with randomized squares or classic shapes, user entered text can be rendered.

Text Based Game State

For each colored pixel on the canvas, sum its eight neighbors.

If the pixel is alive and does not have exactly 2 or 3 neighbors, then it dies.

If the pixel is dead and has exactly 3 neighbors, then it comes to life.

This simple rule set allows for pixels or squares to animate on their own. There are a vast number of patterns that can appear.

Prior to this project, I had only known shaders in relation to video games and graphics cards marketing material. The main thing I've learned is that there is an endless amount to learn about graphics programming and it's amazing to see what other people come up with.  There was a lot of time spent on 

 checking out the crazy things programmers come up with.

As much as I love functional programming and a higher level of abstraction that languages like TypeScript deliver, it is clear that there huge performance gains to be made by dropping down to a lower level. Writing a shader in GLSL is not easy but it feels like a miracle to watch the shader come to life when it works.

The original idea for this project was to use XState for the actual game implementation. The rules are perfect for implementation with a state machine. As soon as I finished it, I was unhappy with the number of generations I was getting each second. I wanted something that was fast and smooth but I wasn't getting that with what I had implemented. I ended up going as far as I could for performance without changing the actual algorithm, but I still retained XState for managing the state in the rest of my application.

I really like how stable and predictable my application was with using XState and I'll continue using it when I can in the future. The ability to generate a state chart based on my application was really useful for understanding how everything fit together.

Conway's Game of Life is a great exercise to learn about basic techniques for rendering graphics such as double buffering. However, the goal of this version was to implement the Game of Life while exploring more advanced techniques. I originally chose to implement the game using finite state machines with XState but expanded the scope to include writing the game to a fragment shader.

Conway's Game of Life written to a Fragment shader. Surrounding application written in Typescript with the Next.js framework, XState, and three.js. 

Conway's Game of Life

This challenge is back again. It was much easier this time but I ran into a performance issue that took longer than it should have to fix.

I wanted a visualization that was purely decorative, but not distracting. The original idea was bubbles connected to each other by links they move around somehow. They should not leave the boundaries of the page and the simulation should avoid becoming stale.

A number of nodes are generated based on the size of the page (not viewport). A random size and coordinate are assigned to each node. A linking function will then generate a random number of links based on the size of the page. Not every node will be linked and some nodes may have many links. The linking function randomly assigns a node to each end of the link.

There are number of forces at work in the simulation.

The linking force is the pull between nodes connected by a link. Links nodes will either move away or closer to each other until the distance between them matches the links' assigned distance.

The bubbles will not overlap and have an invisible barrier around them that pushes other nodes away.

All nodes will push each other away. Larger bodies of nodes will have more push force.

Nodes will not leave the canvas. There is a barrier just shy of the screen edge that they will not pass.

To avoid nodes wandering their way to edges and laying themselves out in a border along the screen, nodes are randomly re-linked every 7.5 seconds. This keeps them all moving away or towards each other in different directions and keeps everything moving along.

I had pushed the branch to production and showed my wife before I realized that something wasn't right. It worked perfectly when I had been testing it but when I had left the tab open for a few minutes, I found that the site had slowed to a crawl and I was running at about 5fps. I refreshed and it was back to 60fps like it was when I tested it.

I pulled up the performance tab in Firefox and saw predictable drops in performance every 7.5 seconds. This had to be my re-linking function. I pulled up the memory tab in Chrome and took a snapshot of the heap after a while and could see dozens of allocations for timers which must have been due to the D3's simulation. 

Every 7.5 seconds, a reLink flag switched to true and because it was a dependency in my useEffect running the simulation, the simulation would re-run, then set flag back to false. This is exactly what I wanted to happen.

What I did not understand was that every time the simulation ran, it actually created a new instance of the simulation. Those timers were all internal to the force functions it was calling.

The solution to this problem was to clean up the simulation in the useEffect return. I don't use the return in a useEffect often so it wasn't immediately obvious. As soon as it was added, performance shot back up and I felt like I knew what I was doing once again.

I was very close to scrapping the visualization entirely due to performance issues and trying to figure out how to get it be responsive. I'm glad I didn't because I learned a lot and I think it looks cool.

Each project has a full write-up, tags showing technologies used, and screenshots showing off the design.

Projects

The background is actually a D3 force layout simulation. There's a couple different dynamic forces acting on nodes to keep them moving and avoiding a stale state.

Visualization

Using browser dev tools is integral to developing for the web but there's always new things to learn. For this project, I became much more familiar with the performance and memory tools in Firefox and Chrome. Chrome's heap snap shotting tool was especially helpful when searching for a nasty bug on this site.

I've used D3 on a few projects now and it gets easier each time. This was the first time where I spent more time reading docs than examples or tutorials. Like a lot of newbies, my first foray into a technology typically starts with an example and modifying it until I'm happy with it. This time, I actually started from and idea in my head and put it into production without any Stack Overflow copy/paste action.

! This is the UI component library I reach for whenever I can make that choice. It feels like the perfect middle between Tailwind and styled-components. The hardest parts of styling an app are all made so simple. Responsive styling can be done with an object or array syntax:

All components are designed to carefully follow WAI-ARIA requirements and the color modes are designed to automatically meet contrast guidelines.

I had put off making a portfolio for a long time but it felt like a disservice to myself. It's hard to sell oneself as a web developer when there's personal website to point to and pointing to Github profile isn't necessarily what everyone is looking for. This site serves as a place to show my work.

You are here. This is the site for my portfolio where I can showcase my work and provide some information about myself and how to contact me.

Wes Feller

Projects

Adventures

3D Map

CMS Integration

Interactive Storytelling

Planet Data

Diverse Topics

Interactive

Quizzes

Spider Graph

Graph Builder

Intuitive Editor

Save For Later

Contact

Wes Feller

Projects

Adventures

3D Map

CMS Integration

Interactive Storytelling

Planet Data

Diverse Topics

Interactive

Quizzes

Spider Graph

Graph Builder

Intuitive Editor

Save For Later

.css-1hnz6hu{position:static;}.css-1hnz6hu::before{content:'';cursor:inherit;display:block;position:absolute;top:0px;left:0px;z-index:0;width:100%;height:100%;}Conway's Game of Life

Portfolio

Contact

Conway's Game of Life