Root + STEM: Data Design
Prior to developing Root + STEM, only a PDF documented the STEM programs that were available in the state of Hawai’i. Our task was to turn the static resource into a living web app that had the potential to be expanded through community contributions.
In addition to our primary ojective, I made it a personal goal to architect the data to be an example of an optimized content infrastructure for both developers and content managers.
Kelli Borgonia, Project Lead, UI Designer
Jon Borgonia, Senior Software Architect
Te Vallee, Full-Stack Developer
I designed the data infrastructure and worked with the developer to ensure that it was implemented to spec. I designed all layouts and hand-coded all CSS.
People would typically interact with the website in one of four ways:
- Community Contributors would submit STEM programs to the database.
- Students and Teachers would search for STEM programs.
- Website Administrators would approve and publish or request changes to submitted STEM programs.
- Casual Users (potentially policy makers and program funders) would search for insights and information.
Data & Infrastructure
After examining the team’s original database and reading the initial PDF report on STEM programs, I worked with the research team to define the properties that we would want to start collecting once users had the ability to contribute STEM programs to the web app.
Since the web application would house a combination of informational and community-contributed content, I planned to separate all editable content from the web app infrastructure.
Whenever possible, I design infrastructures to be sustainable. I have witnessed so many projects where content change requests end up wasting 80% of a developer's time. To mitigate this inefficieny, I always work with a CMS to ensure that content can be updated independently by content creators and managers, so that developer resources can be reserved for functional code changes.
I discussed my plan with Jon Borgonia and he translated my sketch to a real infrastructure map:
The Programs section pulled all STEM programs data from Firebase and rendered it as a searchable, filterable list. I studied several similar websites and noticed that they all had overly complex filtering and search capabilities. Since this was the site’s first iteration and there were less than 200 initial programs, I limited the filters to properties that would return the most general results: Program Type, Target Age Group, Industry, and Region.
I structured the Contributors interface to be simple and straightforward. Users could sign up, add information about their organization, then fill out a 3-step form to submit a STEM Program. Once submitted, the program was set to a “Pending” status to be reviewed by a site administrator.
Despite its simple appearance, the Contributors UI was robust under the hood. All form questions in the program submission flow mapped to data fields in Airship CMS. Utilizing a CMS gave me the ability to update the text for the rest of the website as well as the fields and options for all the forms and search functionailty while the developer continued to work on critical web application infrastructure.
Here is an example of form field data and a list of options that can be configured by a technical manager independently from the development cycle:
The Programs Admin interface allowed admins to log in and review pending STEM programs. After review, admins could then approve and publish, or reject a program with notes for revision.
These interfaces were kept intentionally simple. Instead of building a single large app that could do everything, we intentionally built a minimal interface that could allow admins to perform a single function—approve or reject STEM programs.
The Map was a representation of all Hawai’i STEM Programs plotted on a roadmap that extended from Pre-K to adulthood. Building it was a collaborative effort between Te Vallee and I. Te translated my very detailed notes on data structure into logic for filters, dynamic captions, sequentially loaded data, and loading animations. I built the CSS Grid structure, custom CSS charts, and designed custom graphics.
Each STEM Program in the database was visualized on the map with a shape and color that correlated to specific criteria. In a separate case study (coming soon), I explain the specifics of this data visualization.
View the live map here.
I spent a lot of time planning how to display and mange categorical information that contained dynamic options. For example, industry categories are broken down into categories and sub-categories.
I set up categories and sub-categories in the CMS so they could be managed and edited as needed without the content changes affecting the development timeline. Jon suggested using a "/" notation to indicate drill-down subcategories.
In the Contributors form, industry categories display as a multiselect field. All options entered in the CMS are pulled into the form as options in the multiselect.
In the Programs list, the same industry categories list is pulled in from the API.
In the Map, we filtered out any categories and subcategories that would return a search result of 0.
The system was also designed to be extendible, so any type of categorical data could be easily organized. The same system logic was automatically implemented for the STEM program properties for "Target Age Group" and "Region."
Why does this matter?
It may all be behind the scenes, though I enjoy designing systems that are maintainable for both managers and developers. As a product owner myself, I don't like to spend maintenance resources paying developers to implement text changes. Similarly, developers don't want to be doing the equivalent of data entry. I believe that any infrastructure that allows content to be decoupled from code streamlines processes, keeps things sustainable, and most importantly, ensures that everyone on a project team is utilized in the areas of their expertise.
A Typical Project Plan
With a typical web app development, initial programming is fast, but there is a long cycle of content revisions prior to launch and incremental revisions post-launch. This plan is perfectly fine, and possibly preferable, for a product that is likely to evolve rapidly, post-launch.
This Project Plan
When utilizing a CMS in development, initial programming takes longer and may be more costly, but resources are used more efficiently. 100% of developer time is used for developing features. Content is decoupled from code. Maintenance costs are reduced. This structure makes sense for a product that doesn't have plans to undergo systemic changes in the short to medium term (1 - 2 years), yet needs the flexibility to be extend and configure data within the constraints of the system architecture.