Plain Plain Text is a project dedicated to providing modular tutorials for humanists interested in using plain text in their scholarly communication. There are many benefits to moving to plain text, but we also know that it can be intimidating. Change typically is, and getting used to new software is famously tricky; even computer scientists hate upgrading. What follows is a brief description of how the site works, followed by a longer discussion about plain text in general.
These two terms describe the scope of Plain Plain text. By “modular,” we mean that the tutorials are all made up of smaller pieces of increasing specificity and granularity. Pedagogically, the hope is that the learner reaches two goals, components and connections.
First, we hope that modularity demonstrates that every technical challenge is, fundamentally, a question of making a bunch of smaller decisions in an order that achieves the desired effect. “Install a plain text editor” can be seen as one command or as several. We aim to present it as both at once.
Furthermore, modularity reveals the interrelated nature of technical issues. As such, we create one tutorial for “Install a plain text editor,” yet it shows up, as its own self-contained entity, in several. Recognition and familiarity are useful in the pedagogical process, so we hope the learner will see modules and say, “oh, I already know how to do that.” and see how their mastery grows.
By “tutorials,” we mean lessons that achieve specific ends. As such, we aren’t describing “a workflow,” useful and inspirational as those sorts of articles can be. Instead, we are showing a concrete means by which a learner can reach a concrete end. It is our hope that as the learner completes more tutorials, thinking about the subject matter more abstractly (connections and components!) will become easier, thereby letting the learner move on to using the tutorials as foundations for solving problems not covered in them.
Also indicative of the concrete nature of the tutorials is that they all start with the expression “I want to.” This expression, partly inherited from user stories, helps limit the scope of each tutorial while also converting the tutorial into an tractable action. Creation remains always central, then, to the pedagogical process on this site.
Lots of people have tackled this question, and we possibly don’t have much to add. Kieran Healy, for example, wrote “The Plain Person’s Guide to Plain Text Social Science,” and Healy has been a useful starting point for humanists interested in plain text. Healy argues that given the clutter of scholarly work, an “engineering model” relying on plain text is useful. That is, the various components that go into a project all tend to be in plain text, so it makes sense that everything should be. Plain text helps with organization, with keeping a record, with reproducing work through minimizing error, and, finally, with automating repetitive tasks.
Dennis Tenen and Grant Wythoff, on the other hand, writing in “Sustainable Authorship in Plain Text using Pandoc and Markdown,” approach the question from a different angle. They specify five principles that guide them: sustainability, human-readability, separation of form and content, support for academic apparatus (footnotes), and platform independence. A recent convert to plain text, Scott Selisker, in “A Plain Text Workflow for Academic Writing with Atom” explicitly asks the question “why,” answering in ways similar to Healy and Tenen and Wythoff.
Again, we don’t have much to add, except to underscore the limits of purity testing on these issues. Every new cohort of incoming first-years to university is more and more locked into a tight ecosystem ruled by Word and Google Docs, where students rely on the (very good and fast) search functions of their operating systems as a replacement for having a coherent structure to their files. Healy’s “engineer model” seems more and more distant from just asking Siri to find your paper. Similarly, Tenen and Wythoff’s issues regarding sustainability seem quaint in an age of seemingly free cloud backups. If iCloud goes away one day, we now seem to think, far more serious problems will have manifested themselves than that our college papers have disappeared.
The point then becomes, first and foremost, that if you like what you’re using now, good. Stick with it. If, on the other hand, you yet again have Microsoft Word patronizing you in some way that makes you want to throw your computer away and return to longhand, well, we are here to show you a different and probably more satisfying way.
Because, more than anything, plain text rewards its users with control, as Healy points out. Users can take as much or as little control over the plain text as they like, but it’s responsive to it all. It doesn’t patronize. It presents itself as it is and challenges the user to be creative with it. And that creativity comes with satisfaction, a little frustration, and, more than anything, a sense of close engagement with the work.
Plain Plain Text doesn’t, then, make a moral argument for plain text, though that’s a good argument to make. It doesn’t make an abstractly organizational one either, though that’s also a good one. Plain Plain Text simply invites the user to regain control over their work and, in so doing, breathe more life into it.
Well, there’s a Wikipedia page for
that. But for the purposes of Plain
Plain Text, we mean text files (typically, but not necessarily, saved with an
.md extension for Markdown) that use
freely available and nearly universal conventions established a half century
or so ago. These files focus on the content of the work, not on the finished
results. Therefore, they are better thought of as part of a project as
opposed to a specific document. Though they work for that, too.
Plain text remains a convention even in our daily computing lives. Tweets are plain text. Commenting on message boards relies on plain text. Facebook status updates are plain text. The entire web, in fact, is made up of plain text files. We typically use plain text in our emails. When we write Wordpress blog posts, we may select sections and make them bold or change the font. But ultimately Wordpress, too, converts all that to plain text.
Yet in our scholarly lives, we accept being divorced from plain text. It is possible to extract the text out of a Word document, but all the formatting will be lost, not to speak of the footnotes, etc. A pdf is even more opaque, especially since the text embedded in it is often just a computer’s best guess at what the letters it “sees” are.
In other words, plain text is an inscapable part of our everyday, and we hope to make the case for making it part of your scholarly day, too.
That all said, plain text does not require “hacking,” nor does it destine the user to a world without a graphical user interface. Our tutorials keep mouse clicks around.
Some of the impetus for Plain Plain Text may just sound like nostalgia, where a dude in his 40s remembers how things were back before Gmail or even Google. I don’t think that’s right, and that’s because I always return to the issue of control above. We have given away control over our digital lives in so many ways over the past few decades, especially to companies like Google and Facebook that don’t deserve it and don’t bother giving us a percentage of the money they make off us. As such, again, without making a moral argument, Plain Plain Text is interested in propagating the humanistic goals of inquiry and critique, of providing alternatives to hegemony.
As Plain Plain Text grows, I hope more people will volunteer to help write modules. Part of why the first tutorial is on writing a blog post for Jekyll is precisely because it demonstrates, as well, how one can contribute to this project.
So, happy plain texting, and hopefully the materials here are presented appropriately plainly, yet usefully.