As an anthropologist enmeshed in the digital humanities and digitally based rights advocacy, I am committed to exploring research on how we make claims to seeing toxicity writ large, both externally and internally. As a researcher who runs the technical infrastructure for a large ditial collaborative ethnographic network, much of which tends to questions about visualizing asthma and disaster, I remain fascinated as to the decisions made by ethnographers in selecting which toxicities to render visible and which continue to remain unseen. I am therefore interested in developing collaborations with others to develop best practices for the selection, curation, and long-term maintenance of visualizing toxic subjects, including the visual artifacts themselves, hermeneutics, and engagement with broader political communities, that further our own reflexive praxis and develop deeper connections with our toxic subjects. My goals are two-fold: first, to broaden what can be considered a viable visualization, particularly within the digital realm, and; second, to query what our responsibilities are as researchers developing best practices for the digital humanities to anticipate and limit the abilities of others to produce toxic interpretations of our data, conclusions, and experiments in the digital humanities.
This is a photo still from a 35-second video posted to YouTube at https://www.youtube.com/watch?v=3E0a_60PMR8 by C-SPAN. The still features Senator James Inhofe, Republican from Oklahoma, holding a snowball in the Senate chambers. Behind him is a poster-sized photo of people standing next to a small snow mountain. Inhofe spends the 35 seconds railing against the scientific claim that the year 2014 was (at the time) the hottest year on record, personally incredulous of those findings because it is currently snowing outside. His poster photo and snowball are meant to "prove" that global warming is a hoax. After all, if there is snow, how could the Earth be warming?
Taking seriously the Derridean idea that we are always embroiled in interpretation, and that there is no escaping it, this photo for me paints a representational photo for why I believe we need to continually reevaluate how and where PECE is situated in its role of using hermeneutics and interpretation in making ethnographic claims. I view Inhofe's interpretation of climate science as wading directly into the "anything goes" realm.
Leveraging the design logics of the platform, and even the more focused individualized logics of any particular instance or group within an intance, what responsibilities do we have to each other as researchers, to our audiences (imagined and not), and our disciplines to garner critical interpretation and reduce "anything goes" as much as possible (if that is indeed a worthy goal, the elimination of toxic interpretation)? While I know the futility of the idea up-front (s you can't eliminate it all), for me it serves as a starting point for (re-)evaluating PECE's design logics, and physical logics (and for me speicifically, taking these lessons back with me to the backend of PECE in order to produce best practices on that side of things), as we look towards developing best practices in the practice of the digital humanities. In short, how can we best live with the realities of the meta-visualizations of toxic subjects? That is to say, best live with the uncertainties of others' interpretations of our data, conclusions, and experiements here on PECE?
This is a self-taken screenshot of the homepage of The Asthma Files, located at http://theasthmafiles.org/.
On this homepage, we see a number of design decisions that encapsulate many years of collaborative design practices, responses to needs, and the realities of our technological choices (web content management system, browsers, servers, etc.).
As I navigate freely between the tripartate design of PECE (Fortun et al. 2018) but predominatly occupying and making decisions in the backend, when I look at this homepage, I am struck by what toxic visualizations we have chosen to privilege and which ones we have chosen to hide. Why privilege essays over artifacts? Why privilege linear time closest to the now over any other organizational method? Why privilege groups over people? Where are the annotations? We could do the work to generate a list of all the ways we privilege certain forms of toxic visualization in PECE over others. But what I am interested in is how my knowledge of the backend--the actual code that makes of PECE as well as the physical/virtual structure of the servers I maintain upon which PECE runs--translates into what I see on screen. What we've decided as a PECE Design Team to visualize is as interesting a question to me as how do I and our developers, who may not work at the mid-level and stage-level of PECE on any routine basis, collaborate "off-stage" to make those visualizations happen. Where do I see our influence shine through to the stage-level? What comes next? I look at the search bar on the top right of the screen, and begin to think again of the code that will one day permit cross-instance searching of artifacts.
I become excited over the possibilities these collaborations have produce and will continue to produce. I am excited to see how we can broaden what can be considered a viable visualization within PECE, even if those visualizations ultimately go unused.
And it comes with a little bit of humor. Before settling on Drupal as our content management system. PECE used Plone. One of the primary reasons for leaving Plone was because Plone enforced a rigid organizational hierarchy, whereas Drupal allows for free-form organization through tags. But yet, the physical structure of the backend is nothing but rigid organizational hierarchies--and thus through no fault of PECE's own, I can still see the warts of decisions past. And I can see them on the hompage too.
And it also comes with a need to be attentive to care. Because how we visualize (toxic) subjects can themselves be a visualized (toxic) subject. And so this image reminds me both of the care that we have taken to produce what is visualized and the care that we will continue to value as we further refine PECE, whether that's as a researcher working solely at the frontend or a developer working solely in the backend, or someone who can navigate the many interlocked scales of PECE.