I researched different websites that provide carbon footprint estimation services for their users, and took notes on how they presented their data (e.g. charts and figures), what kind of carbon comparisons they make, and how they prompt users for information. This helped me figure out how I wanted my Chrome extension to work and what information would be the most helpful for users to see.

I created an initial prototype that explores different scenarios the user can interact with the extension.

1. Highlight a text

2. Display interactive carbon chart

1. Detect shipping information on Fedex

2. Display carbon emissions for shipping

1. Detect virtual server information on Microsoft Azure

2. Display carbon emissions for hosting virtual servers

I implemented an iterative design-build-test approach for the browser extension by first creating the design, developing the extension, and conducting user testing sessions with the functional product. This allowed users to interact with the extension in a real web environment, which revealed their natural browsing habits and areas of confusion. I then analyzed the testing data to identify the pain points, and implemented the design refinements.

Interactive Chart

Final Design Justification:

• Pie Chart: Changing the data visualization to a pie chart makes it easy for users to identify which raw materials have the largest environmental impact at a glance.
• Total emissions: Include the total emissions with a unit of comparison (e.g. miles driven) to help users see a bigger picture.
• Parameters: Implemented distinct UI patterns to establish a clear visual hierarchy and distinction between dependent materials (e.g. adipic acid, EPON 828, TBD) and standalone materials (e.g. woven glass fibre).

Carbon Emissions of Shipping

Final Design Justification:

• Interactive Geo-Maps: Changing the data visualization to a pie chart makes it easy for users to identify which raw materials have the largest environmental impact at a glance.
• Transportation Method Comparison: Include the total emissions with a unit of comparison (e.g. miles driven) to help users see a bigger picture.

Carbon Emissions of Mobile Devices

Final Design Justification:

• Phone comparison: Removed the “Compare” button as users found manual searching overwhelming. The design now automatically selects two similar phones by price and specs, which reduces cognitive load.
• Data Source and Tooltip: Added “data source” and information tooltip to help users understand how the emissions are calculated and where the data is sourced from.
• Emissions indicator: Clearly indicates which options are more eco-friendly by visually emphasizing the option with lower emissions through color coding.

Below is a diagram that roughly explains how Living Sustainability works under the hood.

Being my first time ever developing a browser extension, I was not familiar with the restrictions placed by Chrome’s Content Security Policy (CSP), which created many limitations not typically encountered in web or app development. This was a great learning opportunity for me as I had to come up with different workarounds and approaches to bypass the CSP.

These are some of the challenges I faced and how I solved them:

Problem: Cannot install 3rd party libraries

There are many 3rd party libraries I wanted to use like Chart.js, which is used to create interactive charts. These libraries are typically installed with npm or CDN scripts. However, CSP restricts the loading of external scripts/sources.

Solution: Using Command Line Interface (CLI)

I did a lot of research online and found Extension CLI. This tool is able to bypass CSP restrictions by bundling libraries like Chart.js directly into the extension's build process, ensuring they are loaded as part of the extension's packaged resources rather than from external sources. With this, I was able to use Chart.js with my extension.

Problem: Backends are not allowed

Chrome extensions cannot have a traditional backend because they are designed to run entirely client-side, with all resources and logic packaged within the extension itself for performance and security.

Solution: Hosting my backend in a remotely hosted server

I deployed my backend on a Node.js server and hosted it remotely with Fly.io. This allows the client-side to communicate with my hosted server through API calls, as the backend is not directly packaged with the client-side.

Problem: Google Maps API is restricted by CSP

Normal API calls that return text data are not restricted by CSP. However, the Google Maps API returns dynamically evaluated scripts to display a live geomap, which is strictly blocked by CSP.

Solution: Hosting geomap on the external server and importing it with iframes

I created a workaround to properly load maps in the extension by hosting external HTML webpages on my server that connect with our backend. When the extension needs to create the geomap, it calls an endpoint on the backend, which retrieves the data and writes it to a hosted .js file. The backend then triggers the client-side of the hosted HTML webpage to generate a geomap using the Google Maps API. Finally, the extension uses an <iframe> to embed the maps from the external HTML webpages.