The Exegetical Thesis as (Digital) Storytelling

The “exegesis project” is a The Big Project for masters students in a biblical studies course. Usually, it’s a paper, of course. This term, I hope to encourage students in my “Book of Daniel” to consider doing the project in the form of “Digital Storytelling.” I realize that this calls for a two-part explanation:

  1. What makes exegesis “storytelling”?
  2. What makes exegesis “digital”?

I am going to take these one at a time. Today, we will stick with the first. In beginning to learn exegesis, one of the big hurdles for students is that they are asked to bracket their spiritual autobiography long enough to attend to the biblical text’s own historical context. That being so, what can I mean when I ask them to accomplish their exegesis as “storytelling”? I’ll break it down:

What makes it “exegetical”?

  • The body of the work asks questions about the meaning of the biblical text for its author, and for the community to whom the author appears to have written, in that author’s own social and historical context.
  • The work’s arguments rely on publicly available evidence and explicit lines of reasoning. They do not depend upon private revelation, confessional dogma, implicit lines of reasoning, or logical fallacies.

What makes it “a thesis”?

  • The work is organized around the defense of a single claim, or thesis. A thesis is NOT, then, an opinion, a narrative, an “exploration,” or a review. A thesis should be defensible, relevant, and manageable. By “defensible,” I mean that it is a proposition that can be established by publicly-available evidence (not private revelation or confessional dogma) and an explicit line of reasoning. By “relevant,” I mean that the thesis forces your reader to re-evaluate the biblical text; the thesis “makes a difference” to how the biblical text is read. By “manageable,” I mean that the thesis can be argued comprehensively within the constraints of the assignment; it is not too big an idea for the word count, and also not so small that the paper falls significantly short or has to be “padded up.”

What makes it “storytelling”?

  • Even when presenting data (as in a lecture, or a thesis paper), there is a “narrative” of sorts: you lead the reader from a starting place, through a terrain known only to you, to a destination. A good presenter “knows her narrative”: you could take away her slides or her paper, and she can still guide you through the “narrative” of her subject matter or thesis (Ask a student about a recently-completed paper; if they can do this, it’s probably a good paper.)
  • We commonly ask our students to “book-end” their thesis with an introduction and a theological/hermeneutical conclusion. The project should begin with a statement of the student’s interest in the biblical passage. It should end with her own assessment of the passage’s theological claims as determined by exegesis. (Are those claims moral? coherent with other biblical passages? intelligible to today’s reading communities?). This conclusion should also include claims about how the text might, or might not, lend itself to preaching and teaching in particular, well-defined communities of hearers. This is to say, the thesis project is a “round trip,” beginning and ending with the student’s own pressing theological and hermeneutical concerns.

So…What makes it “digital,” if it is?

Stay tuned. In a follow-up post, I will look at the phenomenon of “Digital Storytelling” in the digital humanities, and how it might serve as a platform for “exegesis as storytelling.” In the meantime, what do you think of this way of putting things? Does “storytelling” offer a useful lens, or muddy the waters?

[The Exegetical Thesis as (Digital) Storytelling was written by G. Brooke Lester for and was originally posted on 2012/01/30. Except as noted, it is © 2012 G. Brooke Lester and licensed for re-use only under CC BY-NC-ND 3.0.]

Learning to Code the Web with Code Year

On January 9th, I received my first unit of Code Year, a one-year, weekly lesson in Javascript programming offered freely by CodeAcademy. A short time later, the Boy and I were working through it together.

Javascript is the programming language on which most of the Web is built, and is one of the simplest coding languages to learn. And, just as natural human languages share most of their basic features with one another (nouns, verbs, adjectives, &c), the elements of Javascript are also used in other programming languages like Perl or Ruby.

Any of you who know me–or who see how rarely I’ve posted here lately–know that I am pretty extraordinarily busy these days. So why would I take ten minutes, a few evenings per week, to learn something of computer code?

How much of your work is accomplished on the Web or by means of some digital tools or other? Whatever percentage that is, remember that those environments and tools are the way they are because somebody decided that that is how they should be. Learning to code means learning what some alternative possibilities might look like. If we understand something of programming code, we begin to join that community of deciders.

If you are in the Humanities, you may well already be a “Digital Humanist“: do you ever use digital tools to accomplish Humanities research? Or, do you ask Humanities-questions about the growing digitalization of our information and our practices? You don’t have to code to be a digital humanist, but learning something of how the Web is coded may spark ideas for you about tools or processes that could improve your research and writing.

Do you have kids in school? If they even have “computer class,” that’s likely to mean, “Learning to use things made by Microsoft,” rather than “Learning to build cool things that don’t yet exist but could.” The weekly units in CodeYear are broken down into several short lessons, perfect for children’s lower stamina and shorter attention spans. (Okay, by day’s end, my own stamina and attention span are pretty well shot as well.) Sit together on the sofa for ten minutes in the evenings, and learn together the language used to create on the Web.

If you are interested, you can read what others are saying about Code Year, or about Code Academy. But I recommend you just jump right in and sign up for your weekly email lessons. Have fun, and tell me if you decide to get started learning to code.

[Learning to Code the Web with Code Year was written by G. Brooke Lester for and was originally posted on 2012/01/13. Except as noted, it is © 2012 G. Brooke Lester and licensed for re-use only under CC BY-NC-ND 3.0.]

THATCamp Pedagogy This Weekend (Picking My Feet Edition)

Have you ever been to Poughkeepsie?

I’m on my way this morning to THATCamp Pedagogy (ProfHacker post), an unconference on teaching and learning as an aspect of digital humanities (THATCamp home). The unconference is in Poughkeepsie NY, and is sponsored by Vassar College.

Besides the “unconference” sessions, there are planned “boot camps” on:

  • integrating digital projects into undergraduate courses;
  • teaching with Omeka;
  • the undergraduate’s voice in digital humanities;
  • “So Long, Lecture.”

I will plan to live-Tweet as opportunity allows. On Twitter, you can follow me for the weekend at @anummabrooke to see my Tweets alone, or follow the hashtag #THATCampedagogy (note the single “p”) to follow all Tweets on the unconference.

[Addendum: the hashtags actually used at the unconference have been #THATCamp and #pdgy]

Have you ever been to Poughkeepsie? (Not Safe For Work!)

[THATCamp Pedagogy This Weekend was written by G. Brooke Lester for and was originally posted on 2011/10/14. Except as noted, it is © 2011 G. Brooke Lester and licensed for re-use only under CC BY-NC-ND 3.0.]

MultiMarkdown and Me

MultiMarkdown: All I Never Knew I Wanted:

When I write, I want to write text files that are ready to be published either as word processing files or to the Web, with full formatting, while still already human-readable simply as text. And I didn’t even know how badly I wanted that until I discovered that it’s possible with Markdown. This is probably easier to show first, then tell.

As you can see, the *.txt file is human-readable, and I get the same formatting results whether I publish to *.rtf (for word processing) or to HTML (for web publishing as you’re reading it now). This is the point.

Results Explained:

These examples illustrate the gist of it. As a writer, this is what I gain from MultiMarkdown:

I get to create a human-readable document that can nonetheless be exported to the Web as HTML. Have you ever seen a page of text that is marked up for HTML, that is for web viewing? It’s a blizzard of tags that make the actual content unreadable. (You can see an example if you select, in your browser, View: Source or Page Source.) But with MultiMarkdown (or just Markdown: see below), I have a document that is prepared for the web, but which is also totally readable in plain text.

I get to create a human-readable document that can nonetheless be exported to a word processor as *.rtf (RTF). Have you ever seen a page of text that is marked up as *.rtf, for opening in Word or another word processor? It’s even worse than with HTML. (You can see an example if you take the RTF file linked above, change the suffix from *.rtf to *.txt, and open it in Apple’s TextEdit or in Microsoft Notepad.) But again, with MultiMarkdown, I have a document that is prepared for export as *.rtf to almost any word processor, but again which is also totally readable in plain text.

I get to write this file just once, and archive it as a single file, no matter whether I used it for word processing or web publishing. The same file, written in MultiMarkdown, can be exported as an *.rtf document, easily read in almost any word processor, or as HTML, easily read by any browser or pasted into a blog post or web site.

I get to compose this file in plain text, in any application that suits my stage in the writing process (collecting ideas, outlining, drafting, editing, publishing). It doesn’t feel like I am writing “markup,” it feels as much as possible like I am simply writing. The beauty of Markup is that most of it derives from email conventions: a line of white space between paragraphs, or asterisks surrounding a word or phrase to mark emphasis, or two asterisks for strong text. There are multiple ways (see below on Gruber’s Markdown) to write Web links that are wonderfully readable, completely unlike HTML web link markup.

I get to be sure that it will be readable in twenty years, without a word processor or web browser to render the formatting. Do you have any old files that you cannot read anymore because they only exist in an obsolete format like “AppleWorks”? The stuff I wrote during my Masters work can only be opened as plain text, and the text is entirely buried in obsolete markup and code. But the stuff I write today in Markdown is already human-readable in plain text, and will remain human-readable for as long as we have plain text.

This is the beauty of MultiMarkdown: plain text files, easily readable to the human eye, but already marked up for headers, sub-headers, ordered or unordered lists, emphasis, and footnotes…both for word processing via *.rtf or for web publishing via HTML. Yeah, it’s the writer’s holy grail.

What is MultiMarkdown?

John Gruber developed Markdown with the web-publishing end in view. Markdown allows almost any formatting one will need for most purposes: emphasis (usually italics), strong text (usually bold), paragraphing, lists, block quotes, hyperlinks to the web, and more. However, Gruber’s Markdown exporter only exports as HTML, because web-publishing is what Gruber has in mind.

Fletcher Penney developed MultiMarkdown as a supplement to, or extension of, Gruber’s Markdown. It accomplishes two things:

  • It exports Markdown as *.rtf rather than only as HTML. (It also exports to OPML, LaTex, and other formats that you may or may not know about or be interested in.)
  • It adds syntax for things like bibliography, footnotes, tables, and more.

So, MultiMarkdown incorporates all the features of Gruber’s Markdown, and extends the idea beyond web publishing to word processing. Note that you do have to install Fletcher’s MultiMarkdown script and support package in order to export MultiMarkdown plain text files as HTML, *.rtf, or other file formats.

My Workflow

I like this because I often don’t know where doodling, note-taking, and outlining might leave off and “writing” begin. I am learning to write in MultiMarkdown all the time, in every stage, because any of that stuff may, at some point, become part of the written piece. Composed in Markdown, anything I write is legible while I play around with it, and it won’t require additional formatting for word processors or for the Web once that writing sits in the final, published piece.

For example, this blog post was

  • begun as a note in NotationalVelocity,
  • moved into OmniOutliner while I played with structure and began some drafting,
  • imported via OPML into Scrivener for continued drafting and editing. From Scrivener I can compile it as HTML (as for this post in WordPress), or as *.rtf for word processing. I save it in Scrivener, but also compiled as plain text ( *.txt) for archiving.

At any of these stages I can compose freely in MultiMarkdown, working in whatever tools suits my present location and purposes, knowing that the result will be a human-readable plain text file formatted for word processing or for the Web.

What do you think? It can sound complicated, and there is a bit of a front-end learning curve (not much, for anyone who already habitually writes in “email style” paragraphing), but once learned, it is all simplicity itself. Can MultiMarkdown do for you what it does for me?

[MultiMarkdown and Me was written by G. Brooke Lester for and was originally posted on 2011/05/02. Except as noted, it is © 2011 G. Brooke Lester and licensed for re-use only under CC BY-NC-ND 3.0.]

RBoC: Not-Yet-End-of-Term Edition

End of term? Not even Spring Break yet! (Next week, insh’allah and the creek don’t rise).

I have in mind some writing on pseudonymity and nymity in blogging, on a recent Chronicle op piece about keeping quiet in faculty meetings, on ancient language “reading examinations,” and on “feeling like a writer.” This is what I’m doing instead:

  • Facilitating faculty training on our new Moodle learning management system (so long, Blackboard);
  • Arranging to offer similar training to our platoon of TAs;
  • Preparing biblical Greek reading exams for 2nd-year Greek students and Ph.D. candidates;
  • Catching up on a self-paced UWM online certification program in online teaching and learning;
  • Working up a couple of videos for our seminary admissions page;
  • Keeping up on quizzes, exams, and papers for Elementary Hebrew, Elementary Greek, and Intro to OT;
  • Experimenting with a couple of new productivity helps to organize the above and more;
  • Eat, sleep, you know. Maybe try for a haircut.

What do you find this week  among your RBoC?

[RBoC: Not-Yet-End-of-Term Edition was written by G. Brooke Lester for and was originally posted on 2011/04/12. Except as noted, it is © 2011 G. Brooke Lester and licensed for re-use only under CC BY-NC-ND 3.0.]