Experiential learning through climate and collaboration
As part of my Open Science Fellowship with Mozilla Science I’ve been using the web as a tool to enable scientists to do more and better. I’ve discovered over the last year that the web is fundamentally about building new interactions whether it be with news, communities, data, and now more than ever, science. As web technologies have become faster and cleverer there are many new opportunities to build tools that make science more accessible and just more enjoyable to do.
There are a growing number of data visualizations that have helped people - domain experts and the public alike - to explore science, journalism, and others. Many of these tools are excellent examples of how knowledge can be both communicated and generated simultaneously when data can be interfaced through the ecosystem of the web (e.g. interactive graphs). When we use these tools, we often see a polished finished product which only hint at the many months of design and development and perhaps years of data collection, processing, etc.
The BC Climate Explorer is not a polished, finished product, but it is and attempt to show how the web can be used to make science more accessible both to scientists and the public. This post is about how this project unfolded over the last few months and reflections about how effective collaborations might take place when developing web apps for science.
Climate Analogs and Novel Climates
Back in January (2016), I reached out to Colin Mahony - a Phd student at UBC, a forester, fellow TerreWEB scholar, and friend - about collaborating on a data visualization project about his research on climate change. I was keen to work with Colin because he’s driven and motivated to communicate his science and because it was through his research that I came to understand the concept of “climate analogs”.
What makes climate analogs so fascinating is that, given a climate change projection, you might be able map out how the climate of your city or region might change to look like that of another place(s) 20, 30, or 50 years from now. Imagine, depending on how climate change unfolds, that the climate of Vancouver BC in 80 years might look more like San Francisco in the winter and Los Angeles in the summer. Climate change of course isn’t so straightforward and there are even many cases in which “novel climates” (climates without a current analog) appear, but having these visuals in mind are powerful for imagining how climate change may unravel.
For my master’s I worked on measuring CO2 emissions in cities which was one way to quantify impacts of cities on the climate, but my research didn’t get into how those impacts might manifest. Working with Colin was a chance to learn more about and communicate what it might mean as our climate changes.
Starting in January 2016, Colin and I started by exchanging emails and phone calls about how to make the collaboration work. It was clear from the beginning that Colin would provide the scientific direction and I would be designing and developing the web application.
It was up to Colin to provide well documented datasets and clearly communicate his visions and directions for what would make the project a success - e.g. useful for his own research as well as his academic and professional community and the informed public. Very early on, Colin “spec’d” out all of the features of the BC climate data viewer. This included the types of charts, maps, and data he wanted to make accessible via the data viewer. He listed other similar tools that he admired and found useful. He also specified the target audience and which features would be most useful and of interest to the various user groups. Since I’m not a scientist in his domain, it was important for me to know for whom this app was for and why and how this tool would make an impact. What was particularly useful for me was that Colin also determined absolute core features of the proposed web app and non-core features which he called the “Ferrari options” to indicate the functionalities that would be impressive and helpful but not absolutely necessary.
As a designer on the project, it was my task to take his specs and sketch out the types of interactions users might have with the application by using wireframes as well as come up with a visual style of the app. From a development perspective, I had to think about the types of technologies we might use, the potential costs of the types of technology we’d use (e.g. hosting costs), and time investment. I also had to think realistically about my current technical abilities and the time needed to learn new things to build out the necessary complexity with the time constraints of my fellowship allocated to this project (1-2 months).
The Global Sprint
Not much happened between January and June besides a few check-in emails, but it was enough to keep the project from getting bumped off of my priority list. So when it came time for the Mozilla Global Sprint in June, I thought it would finally be our chance to kickstart the development of the project.
For the Sprint, Colin joined me and a handful of others at Mozilla’s Vancouver Office. We were joined by Victor who came to the Sprint in general to help out as a backend web developer and found our project interesting enough to join. This turned out to be a really fortuitous collaboration.
Day 1 of the sprint was dedicated to setting up the project github repository, sketching and wireframing, and getting a better understanding of the data and the main mission of the data viewer. By the end of day 1, we had two main takeaways: First, a basic illustrator sketch of the visual style of the app which we could use as a discussion tool for determining the user interaction with the tool and second, a proof of concept that we could get the large climate data onto the web in a performant way (we deciced to use Carto for their easy to use and powerful Postgis enabled SQL database) and retrieve data and style the map in a simple and fast way. We also had some really nice design contributions and inspirational links from the Mozilla Sprinters from NYC and Chicago, respectively.
Post Sprint Reboot
The sprint put us in a great position to build more complexity into the tool and to rethink the visual style. With the momentum from the Sprint, Colin and I started a stronger communication loop using Github’s Issue Tracker and regular Skype calls. As more features were starting to get built into the app, more issues were flooding in from Colin about how the user interactions should unfold with the data to make the charts effective. Colin’s feedback made it clear that the tool must be something that should be easy to use (without bugs!), but flexible enough to dig into the historical and future climatological datasets for domain experts and public audiences - not a small task.
At this point, I also took a few days to reboot the layout and to setup my own backend framework using NodeJS, MongoDB, and Express. In terms of layout, I decided to drop the Twitter Boostrap Styles and instead use Google’s Material Design framework and take advantage of their user interface interactions and styles which for better or for worse make for distinctively “Google” style. Setting up Node, Mongodb, and Express was more of a way to preempt any future possibilities for doing more complex data processing or data collection (e.g. photo submissions).
The new layout helped bring the app together as a more user-friendly and cohesive structure. It seemed that as the layout improved, Colin’s feedback about the app’s features became much more focused and clear. Colin could now mention specific buttons that needed fixing or bugs that would flare up through his use and exploration of the new and improved scatterplot, time series charts, and map interactions. Colin would call often to discuss the new features that I would add and clarify if things didn’t make sense. If there’s any reason why the BC Climate Explorer is successful (we switched the name to reflect our emphasis on climate and not just BEC), it is in large part because of Colin’s strong sense of direction and eagerness to be involved with the development process in any way.
From the time of the Sprint until now (July 13th 2016), I’ve been working more or less full time on developing the BC Climate Explorer. The last 6 weeks (+/- 1 week) have been as much about building a web app as it has been about creating a thriving designer-scientist collaboration. For me, some of the key takeaways from this experience have been:
A successful project takes both vision and direction: Colin had a vision for the BC Climate Explorer - he knew he wanted a tool to help people work with the climate data for BC. Colin also had a strong ideas for the direction - he knew for example which types of charts would be useful, what types of data needed to be exposed, and what linkages needed to exist between the maps and between charts. He was clear about what kinds of knowledge people should walk away with after using the tool and was well aware of existing or similar projects and their strengths and weaknesses. It was all of these aspects together that helped drive the project forward rather than in an infinite loop of “what ifs” and “could be’s”. Most of all, Colin’s strong vision and direction made it clear for me how I could effectively use my time to think through designs and the technical challenges rather than also define the conceptual foundations of the project.
Dedicate 2-3 days to prototyping early on: I’ve been involved with projects that simply never start because there’s no strong vision, direction, or idea about how the project is going to look or feel. The Global Sprint was the perfect way to dedicate 2 full days to develop the early concepts of the BC Climate Explorer and to build a prototype with which we could discuss how to move the project forward. I’m a believer of the saying that “code is a material” with which you can sketch out your ideas and build things piece-by-piece (like legos!). As you saw above, the early versions of the BC Climate Explorer weren’t pretty, but they helped everyone involved in the project to better understand the nuts and bolts of the project (e.g. the various types of data and mapping technology).
Design and Development are different things: Design is about the process of developing solutions to aspects of a project like layout, the visual styles, the “identity” of the project, the interactions, and the experience. In the process of developing these solutions, you might create sketches, build wireframes, define styleguides and/or write code or set up databases. In this way development can inform the designs and vice versa. This isn’t however to say that all designers are developers or that all developers are also designers. In fact, most of the time, people who call themselves “designers” might have a specific set of tools that help define things like layout, project identity, and so on, whereas people who call themselves “developers” typically use code as their tool and very often rely on designs made by designers to guide their development process (e.g. building a code base). You might not always need a designer or a developer, but it is important to note that these aren’t often skills that are bundled together. Also, depending on the type of project you’re building, it might be helpful to have designers whose imaginations aren’t limited by their awareness of what is technically feasible in the same way that you might not want developers who aren’t creative enough to come up with solutions to unforseen challenges along the way.
Flexibility is important: there’s always tradeoffs between functionality, usability and complexity. Things won’t always turn out how you imagine sometimes for the better (e.g. rainbow color scales) and sometimes for worse. Keeping an open mind, respecting your collaborators’ perspectives, and reacting appropriately to the needs and wants of your collaborators is key.
- Keep a tight communication feedback loop: Communication, especially if you’re working remotely from your collaborators, will make or break a project. Colin was excellent at commenting on Github Issues and calling me to clarify his comments and feedback on those issues and made it a point to have regular skype calls througout the development process. There was once a time that Colin even called me while he was sailing in the middle of Horshoe Bay to make sure I correctly understood some of the recent changes he wanted to see with respect to the data being represented on some of the charts. Some people like using instant messaging services like Gitter, Slack, or IRC and other prefer to Skype and email. Finding the right tools for you and your team will help keep the feedback loop alive.
Let it settle: There are different philosophies on how to communicate progress. Some people prefer to only share when major milestones have been completed and others prefer to get feedback on even the smallest of updates. I think it is important to communicate how you prefer to work and when you think it is appropriate to share out. During this project, I found myself sharing frequently about very slight changes to the tool even when they were not fully realized. There were a number of times throughout the development of the BC Climate explorer in which I would send Colin screenshots of an early version of a chart just to show that there was progress. For next time, I think I will be much more selective about communicating progress at the major milestones and rather have my collaborators just be able to run the tool at their own accord. With the BC Climate Explorer, I think the style of constantly sharing little updates only worked because Colin knew that the updates weren’t polished and was able to manage his expectations and feedback to reflect those understandings.
Reach out to your target audience/stakeholders: From the very beginning, Colin made it clear that it would be critical that the core community of Foresters, Ecologists, and BEC unit users be able to access and understand the tool. He also emphasized the importance that the people in these communities know that we did our best to maintain the integrity of their science. By reaching out to some of the key members of the organizations that maintain and vet the BEC system before the beta launch, we aimed to acknowledge their work and field feedback about how the ctool might be recieved.
The BC Climate Explorer is just finding its legs (with many more milestones to be made) but we’re excited to release the beta version of the tool. Using the web app you can explore all the unique BEC units, the BEC zones, and the climate data by BEC unit geographically, over time, and between climate variables. You can see where how the climate has changed in the past and what the model projections say about the Province’s future. You can also see how see how the climate of each BEC unit might change relative to another. You can learn more about some of the insights you can draw from the tool in this video.
We hope you will enjoy and learn about the future of BC’s climate by using the BC Climate Explorer!
Many thanks to Carto for supporting our work!