The Socio-Technical Sustainability Roadmap

The Socio-Technical Sustainability Roadmap, an online training module presented by the National Endowment for the Humanities, offers a project planning guide for anyone designing a “web-based, user-facing, digital humanities project.” Poking around on the site a bit, I was curious to notice that it was hard to find any explicit mention on the site of who, exactly, the site and training program are intended for – maybe a bit surprising, since one of the key recommendations offered in the modules is that project planners should identify the “designated communities” of users for their products. Nonetheless, it’s pretty clear that the training is designed to be useful for individuals or teams working in a wide range of settings (academia, arts, public service, entrepreneurial, any combination of the above), and is relevant and helpful for us.

A key principle and purpose of the training program, as indicated in the title, is to support project planners in planning for the sustainability of their products. Coming from the world of humanitarian aid, I feel a special appreciation for their emphasis on this principle, as well as admiration for the concrete, clear approaches they offer.* Section A, the Project Survey, begins by recommending that we begin by determining what “sustainability” could and should look mean for our projects, and planning toward that vision from inception. Module 1-A, then, gives us a translation and application of the concept of “sustainability” into even simpler and more specific terms by naming and discussing the phases and sub-phases of the typical arc of the “life” of a digital product or platform. I found the descriptions of what these phases might look like especially useful in imaging concrete possibilities for my own project.

A second principle we have started to discussion, and that I see addressed in the design and purpose of the training program, is “failing well.” The “About” page of the site explains that the concept of the program originates from experiences with MedArt, a digital collection of medieval art and architecture that was a great success in the first phase of its availability and use, but which over time had become less frequently used and updated. The Sustainability Roadmap doesn’t actually use the word “fail,” but I was still impressed that the training program had been developed through a process that began with their team’s recognition and acknowledgment of a project’s flaws and limitations, and then synthesizing and sharing real and applicable lessons from that experience.

Here are a few questions that I hoped we could discuss to compare our experiences as we worked through Module A:

1) What are some of the questions from any of the module that you would have expected, were already thinking about and/or felt well prepared to answer?

2) What are some of the questions, from any module, that you didn’t expect, and/or addressed issues that you had not (yet) been thinking about? Of these, which did you find:

  • Helpful, inspiring or evocative? (I could also say “generative” but am tired of that word at the moment, no offense to anyone who likes it. Include it if it works for you, though.).
  • Overwhelming, discouraging, or confounding?
  • Not relevant or applicable to your project?

3) Our readings on project planning, most of which are addressed to software design projects, give quite a bit of attention to questions around who the end-users of our projects may be, and their experiences in using what we produce. In my post for last week I mentioned that I especially like the idea of thinking about who the users or “designated communities” of research findings might be, especially because with respect to my own work, it seems like a strong way of operationalizing my accountability to the people (youth, communities) that I’m ostensibly working with and for. I’ll add that I was fascinated and inspired to learn more about everyone else’s projects, and especially to see how many of you are working on projects that are very explicitly intended to be practical, useful tools and resources to benefit educators, students and others, within and beyond the academy. (And that’s not meant to imply criticism for anyone who’s projects focus more on studies and uses within the academy). To continue that conversation:

  • Has your thinking about who your users or “designated communities” may be changed or evolved in the past couple of weeks?
  • Are there new potential “unintended” communities that might use or benefit from your work?

Braelyn Hendricks

Braelyn is a 2nd year Ph.D. student in the Sociology Department at the Graduate Center. Her research interests are in science and technology, as well as inequalities, race, gender, sexualities, social change, and much more.

Braelyn works as a research assistant at the Ralph Bunche Institute for International Studies, investigating the political ideologies of the richest people in the technology industry. Simultaneously, she teaches at The City College of the City University of New York as a Graduate Teaching Fellow. Here, she developed two courses that had not previously been offered at this department: Science, Technology, and Identity, as well as Digital Sociology.

Braelyn has a Bachelor of Science in Chemistry with a Biology emphasis from the University at Albany, State University of New York. She has experience working in libraries at SUNY Albany as well as work at the Westchester County Laboratories and Research Environmental Lab. When she finds time, she indulges in too many hobbies including (but certainly not limited to) PC building, 3D modeling, sculpting, and epoxy resin craft. She has recently spent time building an ecommerce store and learning related skills such as search engine optimization (SEO) with a business partner.

Ryan McKinney

Ryan McKinney is a theatre artist, educator and emerging scholar working in theatre arts and performance. As an actor, director & theatre manager, he has worked at Manhattan Theatre Club, The Garden Theatre, Harbor Lights Theatre Company, The Contemporary American Theatre Festival and the touring productions of I Love You, You’re Perfect, Now Change and Forbidden Broadway.

Having taught at several colleges and universities, Ryan currently serves as a Professor of Theatre Arts at Kingsborough Community College where he is also the Director of the Theatre Arts program. He is the recipient of the Kennedy Center Gold Medallion for service to theatre education and the co-recipient of the ATHE/KCACTF Region 1 Prize for Innovative Teaching.  

As an emerging scholar, Ryan’s work explores musical theatre and politics, global theories of actor training, and gay & lesbian representation on stage. A community college educator of twelve years, Ryan is also interested in theatre as social practice and civic engagement. He holds an MFA in Musical Theatre from San Diego State University, an MA in Theatre Studies from Hunter College and is a second-year, Level II student in the PhD Program in Theatre & Performance at The Graduate Center of the City University of New York.

Sandy Mui – Bio

Sandy is the digital communications assistant at PEN America, where she oversees and creates digital/web content across PEN.org.

Sandy’s background is in journalism, having covered a mix of topics in hard news, features, entertainment, opinion, and sports. Her interest in digital media expanded as she branched out in her writing and worked on social media, digital campaigns, websites, layout, podcasting, and e-newsletters. Before joining PEN America, Sandy was the communications associate at WITNESS and digital intern at Everytown for Gun Safety. Her current interests lie in supporting human rights and a free press.

Sandy has a B.S. in journalism and media studies from the Macaulay Honors College at Brooklyn College. In June 2019, Sandy received the Vanguard Prize in Journalism — a prestigious award given to a Brooklyn College journalism student for their commitment to protecting and advancing First Amendment rights. She is currently pursuing her M.A. in liberal studies — with a track in digital humanities — at the CUNY Graduate Center.

Contexts and Practicalities, by Christopher Stein

In his blog post “Context and practicalities,” Christopher Stein offers his students (and us) a clearly structured, easy-to-read overview to approaches to product design, and especially software design. The post provides guidance that I found practical (as promised in the title), relevant and useful in understanding the software and digital platform design process, and thinking ahead to possible and certain future projects. Equally helpful is his historical (or at least narrative and sequential) description of the iterative developments of of the Waterfall Method, Instructional Systems Design, User-Centered Design, “agile,” all terms from the design world that I have heard often, but had not seen defined and explained so clearly. (I believe this post was written before the further development of Human Centered Design that arguably has evolved from User-Centered Design; for anyone interested here’s a quick explanation of the difference and relationship between the two).

Having never designed software, and imagining that the same is true of most of us, I thought it might be useful to relate Stein’s post to at least one areas that is more familiar to all of us, namely, research.

In this regard I was I interested to compare the guiding questions that Stein recommends in the “Five W’s and one H,” as well his description of the Waterfall and User-Centered Design processes, with the questions and steps we each may typically take in initiating and planning a research project. As a thought experiment, I considered how an educational research study might work – and possibly be enriched? –  if it were carried out as if it were a software design project.

Several of the questions and steps Stein describes (“What are the goals of the project? What need or problem Will it satisfy?”; Analysis, Design, and Testing, respectively) seem more or less analogous to those built into a typical research process. The most significant difference in the two types of processes that jumped out at me was the emphasis on purpose and usability (or just usefulness) that is integral to the software design process, and not always given weight or even present in educational research. I find the idea of an educational research project and process that tests whether findings are purposeful, usable and useful (or even used) compelling – especially if that testing process were guided by the perspectives and experiences of people who are meant to benefit from that research. This line of thinking also brought to my mind Leigh Patel’s guidance for researchers to decolonize the research process by beginning with the questions, “Why this? Why me? Why now?” (Patel 2016) – and the hopeful possibility that some of these questions might be answered not only through our own reflection as researchers, but through practical assessment by the people whom we intend to serve through our research.

Could Stein’s “Five W’s and one H,” and/or the Waterfall or User-Centered Design processes be applied and/or adapted to a research project in your respective disciplines? How would those differ from or alter your typical research process? How might applying or adapting these questions or steps to  your research process affect the relative validity and quality of the results and/or product of your research?

If the results of one of your studies were tested by an “end user” of your research – who would you want that end user to be, and how and for what would you want them to test the results and products of your study?

37 Signs You’re Doing Too Much

Getting Real is a “quick and dirty” read on doing things in a “quick and dirty” way. The tenets remind me of Voltaire’s Candide in his advice to tend to one’s own garden rather than fixate on the world at large, and of the seeming tautology: Good judgment comes from experience, and experience comes from bad judgment. Yet works such as this provide a valuable loophole: gaining the vicarious experience of others bad judgment so that we may grow wiser while obviating first-hand failure. With perhaps more don’ts than dos, this book can help all of us emerge a bit from the self-regarding torment the words “new,” “technological,” and “project,” haphazardly strung together like Christmas lights at a frat house, brings to the junior academic soul.

Pick something, is it bigger than a breadbox? Do you even know how to build a breadbox? See, already we’re mired in considering yeast, gluten, temperature, humidity, materials and locations; the trap easily makes itself. While the advice in this book is specifically targeted to tech startups, it has some salient lessons for us (as we further embark on our ITCP projects), a few of which I will paraphrase. 1- Don’t try to “reinvent the wheel;” 2- Focus on a real thing or issue; 3- Don’t invest heavily in niche solutions (don’t learn java for one button;) 4- Don’t try to anticipate all possibilities, just be ready to respond; 5-get something done: ugly, wonky and working is better than a beautiful theory; 6-Don’t add features before you develop function. 7- Try to work in chunks; 8-keep working until you have something for others to test and critique; 9- If you can’t break the concept down to doable tasks, it’s still just a concept; 10-get feedback from those who may actually use your project.

My only issues with this “manifesto” are with points 8 and 10 in the previous paragraph. The truth is that academics work woefully alone. Academia is silos within silos, a nesting doll of departments and offices.  As a rule, academics (emerging or otherwise) do not work in teams, this can make it very difficult to put realistic constraints on projects that often live too long and grow too large in the mind. This isolation has one retreating time and again to the grand recesses of our own overexcited minds. The esoteric nature of most academic content areas means that it is unlikely we will build teams to share in the workload and day-to-day decision making. Yet, I think academics can help each other “get real,” maybe this course will enable some such pairings. Having accountability buddies could help us all get out of our heads and on with our work. How wonderful and refreshing would it be to have someone also engaged in a technology project, though perhaps from another discipline, check in and tell you: “Don’t do that, that’s stupid.” I myself would be infinitely grateful.