NextGen Innovation in Scholarly Communications: An Exemplary Collaboration between a Research Library and a Technology Partner

Often, "big idea" academic projects create high expectations for major change, generate enthusiasm and funding, and yet ultimately fail to deliver on their promised benefits. I recently stumbled on a case where that didn't happen: the JSTOR Labs and Columbia University Libraries collaboration on the Reimagining the Monograph (RTM) project, which led to the relatively rapid creation of the TopicGraph prototype tool. As figure 1 shows, TopicGraph's interface has monograph topics arranged in order of importance on the left (for quick scrolling), with key phrases and words highlighted in the text on the right. The interface, even in beta form, simply looks obvious. It looks almost ridiculously obvious — like iPhone-swipe-gesture obvious or peanut-butter-and-chocolate obvious — raising the question: Why hasn't this been done before?

The e-book has been around for decades now and, in that time, the standards and tools for text enrichment and scanning have become more sophisticated; the number of vendors operating in the space, more plentiful; and the funding community's attention on the monograph and its e-variants, more intense. Indeed, many initiatives have explored ways to make scholars' lives easier and their research richer and more fecund by helping them locate, search, scan, share, and annotate monographs. The problem has been and continues to be looked at from many angles, but few innovations have made it to implementation.

When I saw JSTOR's release of TopicGraph and heard that the team produced this working technology in just a few months, I knew there was something special going on — a good backstory for sure, and maybe some secret sauce. So, I called and asked the team if I could take a look in the kitchen and, thankfully, they obliged.

Key RTM Project Takeaways

JSTOR and Columbia Libraries demonstrated a reasonably priced approach for doing fun, engaging, fast-paced discovery. And they did it by leveraging ideas from the wider design world (design thinking), the agile software world (lean startup), and the powerful latent potential of commercial and academic partnerships — in this case, JSTOR and a forward-thinking library.

The RTM approach offers many key takeaways for libraries, professional associations, learned societies, tech vendors, consultants, and funders. Following are what I found to be essential elements of the project's success.

Timing

The project emerged from a series of JSTOR-initiated conversations around its 20th anniversary. The conversations, with various partner libraries, reflected on where the digital scholarly ecosystem started, how much it had evolved over the past 20 years, and where it might head over the next two decades.

One of JSTOR's partner libraries was at Columbia University. At that time, Barbara Rockenbach, Columbia's associate university librarian for research and learning, had recently finished an analysis of the library's scholarly e-book usage. The JSTOR team was eager to see what could be learned from that data, as well as which scholarly monograph reading norms might be ready to change or evolve.

Partnership

A library is an ideal setting for a project looking to explore innovation in scholarly communications because it provides the critical input for design and ideation — that is, access to users (in this case, scholarly readers). As the e-books epicenter in academe, libraries have valuable data and anecdotal insights from their patrons, including professors, students, and casual users. For the JSTOR team, finding a library partner like Columbia made eminent sense.

The project was also an important opportunity for Columbia Library. As Rockenbach observed, libraries have traditionally been on the outside of technology and innovation conversations; they simply inherit systems, such as online public access catalogs (OPACs), and view them as black boxes.

In this case, the library's team was approached by JSTOR's savvy tech folks and invited into a design conversation from the beginning. It was an arrangement that suited Rockenbach, who is "a proponent of librarians becoming active in the creation and design of their own solutions."

Narrow Focus

As I noted earlier, researchers have paid ample attention to the monograph's vital and challenged role in scholarly communications. The Andrew W. Mellon Foundation seeded at least 20 such projects (at more than $10 million USD) in its 2014–15 grant cycle alone. In a terrific survey of these grants and their results,¹ John Maxwell and his team in the Simon Fraser University Master of Publishing program aptly observed that there are many ways to approach "saving the monograph." The challenge with solutioning is not a lack of technical prowess, they noted, but rather the complex nature of the problem space itself. As Maxwell puts it, the hard thing to realize is "that any solution must fit itself into a network with many parts in mutual tension… any movement on one part causes movement in other parts, too."

JSTOR Labs did its own review of the prior monographic research landscape² and, cognizant of the potential unintended network effects of big-bang solutions, spent ample time with Columbia Library narrowing the project's inquiry scope. The goal was to focus on an issue that was interesting enough for a group to study and develop ideas around but small enough that potential solutions would be unlikely to touch or disrupt workflows and other existing relationships.

Ultimately, the teams decided to focus on the scholarly monograph reading experience itself in its current most common form: online PDFs accessed through library discovery services. New, fancier whiz-bang e-formats were not a consideration. The goal was to do more and get more value from the existing monographic infrastructure. Through this focus, the team landed on a particular research question or, in the parlance of design thinking, a testable hypothesis: In the transition to digital, what print-specific benefits might have been lost for readers of scholarly monographs? The team also pondered a companion question: What digital affordances might not yet have been tapped to enhance the use of digital monographs?

The Art of the Borrow

Another of this project's standout elements is the thoughtful borrowing of approaches from the design thinking and lean startup communities. Higher education is no stranger to these tools, but efforts to incorporate them into existing administrations and departments have met with mixed results at best.³ Both the design thinking and lean startup approaches are popularly associated with small software startups and entrepreneurial ventures, where speed to market is prioritized in the hope of disrupting incumbents. In scholarly projects, however, first-to-market isn't the driving or overriding concern. The RTM project therefore balanced the element of speed (lean process) with rich customer insight (design thinking) and lightweight iterative software development processes (agile), which all worked together to mutual advantage.

As figure 2's timeline shows, projects such as these benefit from ample preparation, including nurturing partners and stakeholders and fully exploring the wide scope of the problem space. Indeed, as JSTOR Labs director and RTM project lead Alex Humphreys pointed out, "We opened a longer and more generative exploration window to anchor our partners and ultimately narrow our focus to a compelling investigation area." A stellar example here is their work in the area of understanding the target audience of scholarly monograph readers. In the design thinking community, a standard best practice is to use observations of or conversations with users to develop rich characterizations of the audience, and then develop user personas that act as generalized stand-ins for various observed users.

A nice twist in this case was the team's decision to focus on an artifact called a user profile. Rather than representing the generalized case, the profile is a distilled version of a single user. Christina Spencer, who manages user research for JSTOR and Ithaka, described the decision to create profiles rather than personas this way: "Personas are great, but at the end of the day you can object to them or argue about whether they truly represent the full swath of cases. But you can't do that with a profile. It's truly a single user observation, fact-based and honestly reported."

As Spencer points out and figure 3 shows, that quality of authenticity is furthered by photos of users in their context, which typically include the tools they use and actual moments in their day. All such details provide a potent context to discuss unmet user needs.

Project Pacing

Design thinking is more than generating hundreds of ideas and then failing fast. As figure 2 shows, the project required a generous gestation; the teams spent nearly eight months positioning the work, narrowing the focus, and lining up partners. The next key milestone was two months worth of ethnographic work — that is, one-on-one observations of scholars at work — and resulted in six scholarly profiles. That process and workshop planning took a total of approximately four months. The next milestone, an all-day ideation workshop at Columbia Library, generated the wireframe that the teams used for quick on-location feedback. They then honed the final concept to prototype and test.

Two months later, the team presented the first working prototype of TopicGraph at the Coalition for Networked Information (CNI) Fall 2016 membership meeting. So, within just eight weeks — or, in agile terms, a few sprints — the teams were able to create working software. Each of the key milestones included outputs (learning) and decisions (do we press forward or try something else?). What's impressive is how, at each stage of this lean approach, the teams got just enough information and input to proceed to the next stage. No analysis paralysis here.

Participant Engagement

In my interviews with project participants, two words that came up often were "fun" and "engaging." The all-day workshop at Columbia was not a nail-biting exercise in torturous brainstorming or belabored, politically laden "this won't work because…" conversations (although skeptics were definitely on hand). Humphreys and the team kept the conversation light and always focused on their core subject: the scholarly reader. Indeed, the morning began with an icebreaker question: What are you reading right now?

As JSTOR Managing Director Laura Brown describes it, that intro question immediately engaged folks and made the challenges scholars face in plumbing the monograph depths very real and concrete. The intro then led immediately to the first group exercise: drawing an "empathy map" to focus on the typical research and teaching prep tasks of various types of scholars, along with their associated pain points in both the print and digital contexts. Participants then shared the resulting user profiles and used those profiles to further flesh out the empathy map. "The tone in the room changed at that point," said Humphreys. "You could feel the skeptics start to say to themselves 'Oh, I might learn something today.'"

What also made the difference was JSTOR Labs' approach to playful inquiry, which offered ample room for mistakes, misses, silly points, and looking dumb. Not an easy feat among professionals who stake their livelihoods and viability on credible data and thorough analysis. On this day, however, all participants got a free pass to fail, as well as a free pass to draw. In fact, ideas for the "nextgen monographic experience" were solely communicated visually with pencil and paper.

In this exercise, fidelity took a back seat to creativity. Using a visual ideation process called 8 x 8, participants each sketched eight designs in eight minutes, generating hundreds of ideas. In the afternoon, the focus shifted to narrowing down the ideas and finding the most clear and compelling ones for the JSTOR technical team to take on as a possible prototype. To pare down their ideas, they created a dotacracy — a simple method in which everyone gets colored dots and votes on their favorite ideas by sticking their dots to the 8 x 8 sheets.

Participant diversity was another key element. Again, leveraging the library's native environment, both JSTOR and Columbia were able to bring the best mix of scholars, librarians, technologists, and administrators to the conversation. The workshop itself drew in 13 scholarly stakeholders representing various parts of the ecosystem, including learned societies (such as the American Historical Society and the Modern Language Association); scholars, students, and librarians from Columbia; and university publishers. All of those viewpoints — which were given voice through innovation games — made the empathy maps come alive and the 8 x 8 ideas more generative and creative.

What Can We Learn

The RTM project shows what's possible when entities within an ecosystem partner to mutual advantage and leverage each other's strengths. Choosing a partner in close proximity (JSTOR and Columbia are both based in New York City) also immediately reduces logistical issues and associated costs for flights, accommodations, and meeting centers. Further, to facilitate rapid development, the partners shared costs; this let the Columbia team forego outside funding and the lengthy submissions process tied to annual grant cycles. Both sides worked collaboratively to articulate shared discovery goals and adjusted their plans as they went.

Further, both teams welcomed play-based discovery without hard, predetermined outcomes. That's not to say that traditional funded models are not needed; rather that early exploratory discovery benefits from ad-hoc or opportunistic partnerships such as this, whereas product ideas with clear direction certainly require funder seeding (see Table 1 for distinctions between the two approaches).

Table 1. Key characteristics of traditional and ad hoc discovery approaches

	Traditional (planned, monitored)	Ad hoc (opportunistic)
Funding	Larger budgets from foundations such as Mellon, Sloan, Knight, and require strong grant-writing skills and demonstrated project worthiness.	Entities cooperate for public purpose; typically the scope is smaller and partners share costs.
Governance	Nonprofit funders have oversight constraints and even specify roles such as primary investigator as well as what is being investigated (and by whom).	The terms and constraints are cocreated and roles are established upfront, but can be flexibly adapted. Transparency is maximized across participants.
Project timeline	The timeline is based on annual grant cycles and includes longer lead times, as well as thorough administrative reporting.	The timeline might be short or long, depending on the nature of the agreement.
Discovery approach	Even for planning grants, funders expect a detailed plan showing all expected milestones. The project's end goal is predetermined.	Participants expect deviation from upfront plans and build it into the process. They set rough timelines and update them as needed throughout.
Best uses	This approach is best when the problem space is well articulated and the solution is well scoped and validated through prior discovery work.	In this approach, the problem-space itself is fuzzy, there are many potential solutions, and a flexible space is required to explore the options.

It's also worth noting that play discovery doesn't mean zero constraints. In fact, some of this initiative's inherent constraints were the labs' own monographic collection (only those books in the open domain); the delivery requirements (two months from workshop to prototype delivery); and JSTOR's own technology resources. As the technical architect Ron Snyder describes it, his development team members had skin in the game, too. They were interested in leveraging their recent advances in semantic technology, which had been cooking in their labs for a while. "We didn't come in presupposing we would use any one technology in our cabinet or have any idea what a prototype would look like, but we were energized by the opportunity to bring the best of our current work to the table." Constraints such as these are the bounds in which creativity blooms.

JSTOR Labs' final project page for TopicGraph is a great example of how to socialize and share the learning. The white paper itself is a powerful piece for others to learn from, while the videos help show the excitement participants felt and the fun they had. The ethnographic profiles can (and I'm sure will) be used as model starting points for other people's future discovery work. And, most importantly, the TopicGraph prototype and its open-source code release stands as the crowning achievement: a powerful, tangible result that none of the participants could have foreseen at the start. In contrast, prior to awarding grants, traditional funders often want clear and known endpoints up front.

How to Try This at Home

When I spoke with other librarians for this article, many emphasized that not all libraries have the built-in advantages of a large doctoral university such as Columbia. Indeed, smaller colleges and universities have time and resource constraints that might seem to mitigate against a technology discovery project like RTM. However, what RTM demonstrated is repeatable at various scales and scopes.

Let's imagine, for example, that you are on staff at a smaller library at a small, four-year, primarily nonresidential institution with, say, 1,400 FTEs. What's possible in this scenario? Quite a lot, as the following steps show.

Step 1: Begin a Conversation

Your work begins with intentional dialog around key questions, such as

• What if…?
• How might we improve ….?
• What areas are we interested in improving?

The spark can come from many sources. For example, conversation can be spurred by white papers or scholarly articles. The American Library Association (ALA) Library of the Future site would be an excellent starting point; any of the emerging trends it tracks in tech, politics, education, or demographics are fodder for discovery.

Direct customer feedback from your own patrons can also launch discussion. What issues negatively affect them? Another option: initiate a little "mystery shopping," acting as a scholar or a student for a day with an imaginary assignment and taking copious notes on your experience for later debriefing. You can also reach out to colleagues at similar-sized libraries or scholarly orgs and ask them what they're seeing lately or how key conference topics are impacting their work. Although the dialog can start from just about anywhere, it should always be launched in a spirit of humility and curiosity.

Step 2: Generate a Hypothesis

For the conversation to advance into a discovery project, you have to hone in on an interesting question or two to study. Taking the ALA's Future Trends site as a starting point, for example, you might focus on the Flipped Learning trend. You then learn that, for flipped learning to be useful, students must be exposed to material ahead of their actual class sessions. So, you might use this seed as a hypothesis for a "what if" question: What if our library could be a test bed for flipped learning? You now have a more specific end point and focus for discovery.

Step 3: Find Diverse Partners

Using our example from step 2, think of a few willing professors and students who might be interested in exploring flipped learning. Perhaps you can even dedicate a section of your library as a flipped learning zone for a semester. Next, consider who might have a stake in the experiment's outcomes; this can lead you to deans or other administrations, or perhaps you call the ALA itself or scholars and librarians on a sister campus.

The next question is: Who can provide salient expertise? That should lead you to subject matter experts — probably within your own education department. You can then ask who might help you design and configure the space, both physically and digitally; this will likely lead to other campus resources, such as your art, architecture, engineering, and design schools, as well as your information and computer sciences department.

Step 4: Explore, Test, Learn

Discussions with your partners and stakeholders will lead to the next step: experimentation. If it's flipped learning, the constraints around your tests are likely created by participating professors who are looking for creative ways to engage students ahead of each week's class lecture.

One option here is to take a gamification approach in which students do a treasure hunt for library resources, followed by a Kahoot! game in the lab space with a prize for the winning team. During these activities, your role is to be the social scientist, observing behavior, taking notes, and debriefing participants after each weekly session. Most people find this work really fun compared to, say, editing PDD buying plans in the library acquisitions system.

Step 5: Repeat

Any and all of the above steps can be repeated as needed. Some hypotheses might be dead ends, while others are rich propositions that generate deep insights and lead to more discovery work. As you build this institutional muscle, you can begin planning a yearly catalog or pipeline of hypotheses and exploration areas.

The partnerships, the conversations, and the work itself become mutually reinforcing. These experiences have no discrete, predictable ROI, because the discoveries and relationships created lead to emergent new behaviors and outcomes. But, even though the process is stochastic, the fruits can be measured in human terms, which is probably the best way to measure these projects. Example measures here include engagement levels, library usage, and new collaborations.

Finally, if funding is an obstacle, simply do Step 1 and leverage its outputs to make a case for a funded project in which a partner — a JSTOR Labs or a tech vendor or even a for-profit institution — picks up part of the bill. Steps 2–4 have longer lead times, but don't let that deter you from trying. In discovery and growth work, the journey is the reward.

Own Your Future

Within the scholarly ecosystem, libraries have a vital opportunity to act as hubs for discovering future value for scholars, students, and the wider community. To start, they simply need to open a dialog within their existing network. It might be a publishing partner such as a JSTOR or a technology vendor or a learned society publisher. Societies in particular should take note: like libraries, they act as natural research beehives (albeit, around specific disciplines) through their annual meetings and conferences. Similar to the RTM project, a society and a library might partner and find complementary strengths to build upon.

Regardless of how they are organized, these initiatives give libraries and other scholarly entities the opportunity to take ownership of their technology futures. As Rockenbach put it: "Going forward, we must own our own tech, understand it, open the box, get in and tinker with it. Be agile, experimental, user focused." I couldn't have said it any better.

Notes

1. John W. Maxwell, Alessandra Bordini, and Katie Shamash, "Reassembling Scholarly Communications: An Evaluation of the Andrew W. Mellon Foundation's Monograph Initiative," Journal of Electronic Publishing, Vol. 20, No. 1, May 2016. ↩
2. Alex Humphreys, Christina Spencer, Laura Brown, Matthew Loy, and Ronald Snyder, Reimagining the Monograph White Paper, report, JSTOR Labs, June 2017, Appendix B. ↩
3. Lee Gardner, "How Design Thinking Can Be Applied Across the Campus," The Chronicle of Higher Education, September 2017. ↩

---

Curtis Michelson is founder of Minds Alert, LLC, a creative studio based in Orlando, Florida.