Constraint-storming, Not Brainstorming

Recently, we published a new JSTOR Labs report, Building JSTOR's Offline Solution for Prison Education, documenting our work, supported by the Mellon Foundation and beginning in 2018, to develop and pilot an improved, offline version of JSTOR for use in prisons and jails.  One of the themes that emerges in that paper is how the constraints under which incarcerated students and prison education programs operate would affect the intervention we were trying to make.  Constraints are always a consideration when developing software, but on this project, the number and the variety of constraints were daunting. The most significant constraint, of course, was lack of internet access, but many, many others, from unclear or inconsistent media review rules to exceptionally low-powered or archaic hardware, had to be dealt with.  Quoting from the paper:

We realized that the real work on this project was not imagining new systems but instead exploring ways to work within the set of constraints programs and students operate under. This wasn’t brainstorming as we knew it—it was constraint-storming.

In this blog post, which I see as companion piece to the full report, I’d like to explore the constraints informing what we ended up building.  To do that, we’ll walk through the specific set of activities we conducted with our six pilot HEP programs during an in-person workshop we held in our Ann Arbor offices in the early days of the project in October 2019.  

Each program sent representatives who could speak both to the program administration and to their particular technical constraints.  After sharing background information on the project and the recommendations and thoughts that came out of the advisory meeting, we led the cohort representatives through three exploratory discussions.  Each of the three discussions addressed a key question we had to solve in order to deliver a solution to participating programs:

1. How will we provide access to JSTOR for students without internet access?
2. How will we ensure that articles and chapters students request meet program and facility standards?
3. How will students consume, or read, the full-length articles and chapters?

During each discussion, we agreed on the primary goal, reviewed possible solutions to problems associated with each topic, assessed the desirability and feasibility of those solutions, identified programs’ related constraints, and then, finally, assessed each solution against those constraints.  All work was conducted on the walls of the room we worked in, with each program having its own color of sticky notes and dots, so as to better visualize each program’s unique needs (see image, below).

Below, we address each discussion in turn, accounting for the ways in which constraint-storming shaped these conversations and what would be possible for the offline solution.

1. How will we provide access to JSTOR for students without internet access?

With our test cohort representatives, we evaluated different approaches to provisioning resources to incarcerated students without internet access, including:

• providing the offline solution on a thumb drive to be installed on a local computer (as we did with the previous version of the solution);
• providing the ability to create or curate content on thumb drives that could fit on smaller, more resource-constrained computers;
• providing a preconfigured server or “search appliance” to be installed locally at the facility;
• adding content to this preconfigured server so that access could be granted immediately;
• providing a JSTOR-dedicated personal device or tablet; and
• creating a version of JSTOR that programs could provide direct, “white-listed” internet access to.

Once we understood these options, we evaluated each by two criteria. First, how easy is this for JSTOR to build, on a scale from impossible to already achieved?  And, how does the research experience for students on the inside supported by this approach compare to the experience of students on the outside?

Then, looking at these solutions, having charted suggested solutions for feasibility and quality, we constraint-stormed.  Each pilot program wrote down on stickies all the soft and hard constraints that would affect which of these solutions could work with their own program’s available facilities and infrastructure. A hard constraint could be the lack of a particular hardware, for instance, whereas a soft constraint could be limited support. These constraints were then shared and “affinity diagrammed” (in which similar items are clustered together), as seen in the image below.  

Notably, this exercise uncovered that while each program operated under a large number of constraints, these were not all the same constraints.  To pick just one example, some programs were forbidden to use thumb drives to bring materials into the facility, while other programs worked at facilities where thumb drives were the only permissible technology.

Finally, programs assessed each of the seven solutions for whether each would work given their specific constraints specific to their facilities, and which they preferred.  This was captured using different size stickers on the already-created desirability vs feasibility diagram: a large sticker indicated that the solution was a good fit for the program; a smaller sticker meant that it might work, or might work eventually.  No sticker meant that it would not work at all. Participants indicated their preferred solution with a star-shaped sticker.  

A few collective conclusions emerged from this analysis. First, while simply providing “whitelisted” direct access to JSTOR was the easiest to develop and provided the best student experience, not one participating program could actually implement it, effectively taking that approach off the table.  Second, while only one solution – making small, configurable thumbdrives – fully met the constraints of each program, this approach was no programs’ preferred solution.  Last, there was little agreement as to programs’ preferred solutions. This meant that either we would  have to choose an approach that did not meet the needs of every program, or we would have to offer multiple solutions in order to reach as many students as possible.

2. How will we ensure that articles and chapters students request meet program and facility standards?

Our discussions about media review and content delivery followed a similar trajectory.  We assessed six media review approaches, including; printing all requested materials offsite and using the facilities’ existing media review process; the creation of a universal “whitelist,” or approved subset of materials from JSTOR; offering programs the ability to configure their own access levels; the implementation of a digital request queue; and aggregating all approvals from across facilities to create a media review clearinghouse.  

Again, the constraints under which HEP programs operated were anything but consistent.  All programs had to deal with unclear standards and sometimes arbitrary media review decisions.  However, it was the level of trust that the program had been able to build with their DOC that drove how programs would approach media review. Where trust was strong between the two parties, programs were comfortable making decisions regarding what students could read; elsewhere, programs anticipated having to review all decisions with their counterparts in Corrections. The best system, we decided, was one that helped programs build this trust over time.

3. How will students consume, or read, full-length articles and chapters?

Questions of content delivery, however, proved to be much more straightforward to approach to discuss. Programs planned to print materials requested using the offline index on in-facility printers, or to provide digital access to article and chapter PDFs on shared or personal devices. So long as programs could gain access to these full-length articles, our participants assured, they would be able to ensure that students could read the documents they had requested.  

Our final activity took the form of a paper prototyping effort. We asked each program to think about all three design questions together and then to draw the solution that would work best for them (a representative example is below).  Participants presented their solution to the group, which we then recorded for reference as we began the process of designing and building the next generation of JSTOR’s offline solution.

The full paper describes what JSTOR Labs built informed by this workshop and all that we learned as we piloted that solution.  A *second* theme within that paper (I know! I should warn about spoilers! ;) ) involves how greatly the context within which our prison education solutions were to be implemented changed during this project, due to COVID, Pell Restoration and a changing prison technology landscape.  One positive outcome of that dynamism is that some of the constraints identified in October of 2019 are beginning to be removed in some facilities: not only is internet access to a customized version of JSTOR now more possible, but we are even beginning to see willingness to provide access to the same full JSTOR available on campuses everywhere.  It is our hope that this trend continues and that eventually, software teams developing solutions for incarcerated learners can focus much less on the constraints and much more on the opportunities.

If you are interested in staying informed about JSTOR Labs’ work to provide access inside of prisons and jails, please consider subscribing to our HEP listserv.