Congratulations! It’s a Tool!

Congratulations! It’s a Tool!

Stéfan, Geoffrey and Mark are delighted
to announce a new arrival to the Voyant Family

Termometer

Born April 8, 2013
1,891 lines of code

Have I taken the whole baby announcement metaphor a bit far? And how do I now indicate that this is really a preview release of a new tool (alpha or beta just doesn’t work so well as a middle names:)).

The text in the tool on the right are tweets that have been archived by Lee. The page only shows the most recent tweets, but she shared with me the full document and said she’d be very happy to share it with others as well. I reversed the order of the tweets (oldest first) and added a few stopwords (like #dayofdh).

Termometer was designed in the same spirit as TermsRadio, to help view a stream of data (like at Twitter feed). The difference is that Termometer is also (somewhat) optimized to be displayed in a narrow sidebar. We still have a lot of work to do in refining the tool, including making it easier to select, add and remove terms, but I thought it would be fun to launch the tool on DayOfDH!

Studio DH: Mixing Classroom Time and Meetings

Schedule Most of my DayOfDH has been devoted to meeting with student groups for their final projects due next week.

The course is entitled Digital Studies / Citizenry, but this year’s edition is really a course on data visualization in the humanities. I’ve always wanted to teach a course in Processing as a way to have students create interactive digital works and learn some programming basics (most students in the course have done little or no coding). Learning to code in Processing could be a course on its own, but there’s also a whole set of parallel conceptual topics that I wanted to visit (ethics, aesthetics, legal issues, etc.). I often seem to be overly optimistic about how much we can cover in one term, and this course has been no exception.

I find teaching programming to be a real challenge because I think it’s difficult to strike a good balance between reusable coding concepts (data types, functions, classes, etc.) and a more pragmatic perspective of just getting something rewarding done. Moreover, students certainly want to learn programming, but they’re not always prepared for the time and perseverance required (no matter how often I repeat it in the first weeks). My core objective in recent years has been to do everything I can to help students learn strategies for figuring things out on their own (though I can’t claim to always succeed at this). In any case, it seems to me that technical pedagogy in DH merits a lot more attention.

As often happens in my courses, I’ve had to revise the structure as we’ve been going along. I’d originally planned to continue with parallel streams of Processing and conceptual issues and have students start group projects in the second half of term. In practice, we’ve dropped the Processing units (conducted as a workshop where I would introduce new programming material and we’d work through some examples and exercises together) and instead I have student groups (typically 3-4 students) book 30 minute meetings with me where they come to work on coding problems that are specific to their projects.

One of the things I love about the project meetings is the just-in-time nature of the material: students are keenly interested in what they’re learning because it’s immediately relevant to their project. I tell them that I’m there to help them tear down obstacles to realizing their vision of the project, and that’s generally what happens. Sometimes I ask them questions that help them figure things out on their own, sometimes I show them strategies for finding techniques and tricks of the trade, sometimes I code for them and ask them to add comments to what I’ve done – I take this to be a variety of forms of apprenticeship. (And very often they show me new stuff as well.) The projects are diverse enough that there’s rarely duplication between meetings in a given week. We all tend to find the meetings immensely rewarding because we get real things done. (Having said that, they also very much value our discussions about conceptual issues on Wednesdays – it’s the mix that works well.)

One of the disadvantages of the meetings format is that it’s time-consuming for me: instead of a 1.5 hour block of teaching Monday mornings, I have at least 4 hours of meetings. This might be closer to what happens in studio art. In any case, I recognize that it’s not especially scalable for larger classes.

Students will be presenting their projects next week during the final class – I can’t wait to see the final product.

BTW, next time I run this course I probably won’t use Processing, but instead focus on existing GUIs for producing data visualizations. While I remain convinced that programming should be more widely integrated into teaching in all disciplines (and all levels, including K-12), I think a more practical introduction to available tools for producing data visualizations would probably be more useful for the kinds of students who register for this course.

As an appendix, in case anyone’s interested, here’s a tentative description of the project submission:

The final project is the culmination of this course. It is intended as an opportunity to apply and develop the concepts and technical skills that you have acquired throughout the term (through readings, discussion, presentations, and mini-assignments, etc.). The final project is composed of an interactive digital work (or works) and of accompanying documentation, including a project write-up. Both the digital work and the documentation are subject to the same high academic standards as what you may be more accustomed to with term papers. Your work should demonstrate a critical understanding of concepts, a mastery of relevant technical skills, a self-aware thoughtfulness, and creativity.

The emphasis of the project is on producing a coherent and compelling data visualization, an expression of what has been explored in class (it may be worth revisiting the course outline and some of the readings as you’re refining your project before submission).

Project submissions should include the following:

  1. A fairly brief (300-500 words) project profile, that includes at least one image that somehow represents the project, a brief introduction, and some highlights of the work (the profile should be autonomous and written for a large audience – the kind of thing that could be included in an electronic portfolio). This document may contain segments that are repeated in the next section.
  2. A PDF document that includes the following sections:
    • Introduction. A paragraph or two introducing the project (what is it? what are the motivations? what were the objectives? what are the arguments?). In this section make it very clear where the project is located and how to launch it.
    • Statement of Collaboration. A paragraph introducing the team members and describing the roles and responsibilities of each team member. You can also use this section to summarize any additional help you received, including online tutorials, discussion groups, manuals, blog posts, articles, etc.
    • Mini-Essay. This is the closest section to a conventional essay, but it’s not an essay. You should narrate your project by intertwining motivations, methodologies, observations, and interpretations. As I read this section I should have a very clear idea of what you did and why (including what you didn’t do and why). You may want to use appendices (in section 3: additional materials) for longer code snippets or procedural explanations. Remember that visuals can be very effective in helping to explain your work. You should take all the normal care you would in writing clearly and smoothly (especially for stitching together parts of your work) while also recognizing the unusual nature of this mini-essay (that has a strong technical component). Be sure to showcase any insights you may have had.
    • Reflections. A final paragraph summarizing the student’s reflections on the project. For instance, what worked well? what was frustrating? what wasn’t anticipated? what would you do differently next time? what potential (if any) does the project have to contribute to society?
  3. Electronic versions of your individual task sheets (that should follow the same template I provide in class). These can take the form of a word processing or spreadsheet document or they can be a scan of a piece of paper. Either combine all task sheets into a single document or use indicative file names like TaskSheet-Sinclair
  4. a list of additional materials appended to the project, as applicable (source documents, executable files, raw data, etc.)

The full project should be uploaded as a zip file to this assignment page. The zip file should include all of the sections above (including the one-page profile).

Projects will be assessed primarily on the quality of the write-up, and particularly the clarity, usefulness and appropriateness of the mini-essay section as well as the interest of the apparent effort put into the project. A portion of the grade will also come from the in-class electronic poster session on April 15th.

 

The Human in the Digital Humanist

SongzaNot that you care, dear reader, but I woke up this morning feeling awful. I’ll spare you the details, but suffice it to say that I probably shouldn’t have come into work this morning. The major factor motivating me was that I had scheduled a sequence of meetings with students who are working on their final projects. It was too close to call between my discomfort and the additional anxiety that it would cause students, so I decided to suck it up.

Morning at our house is the usual chaos of a place where parents and kids are rushing to get ready: reminding, cajoling, coercing, and so on (if you’re from a perfect household where everyone always does everything smoothly and with a sweet smile, I don’t want to hear about it). My illness was a further complication, requiring regular pauses to sit or lie down. But breakfasts were eaten, kids dressed, teeth brushed, lunches made, dog walked, and no one got hurt.

One of the biggest departures from my typical day as a DHer was that I wasn’t able to muster the appetite for my morning espresso. I’ve participated in DayOfDH for five years now, and this will be the first year where I don’t post a picture of my machine. It’s ok, that’s what archives are for, right?

My morning ritual includes a ride on public transit into downtown Montreal where McGill is situated. I’ll occasionally read a print article or something on the iPad, but the thing I enjoy most now is listening to an Audiobook. Most of my colleagues say they find it very challenging to keep up with literature in their field and find time to enjoy fiction for pleasure – audiobooks are my main source for English fiction now. The selection of French audiobooks is terrible, so I tend to have a French book on my night table. Anyway, I can put on my headphones while commuting, fire up the book, look in front of me and immerse myself fully without constantly looking up from a book or ereader, or worrying about elbow space (the metro can get awfully cramped). I recently splurged on a pair of noise-cancelling headphones from Sennheiser – the noise-cancelling is very good (though not the best), but I love not having wires and the sound is phenomenal (not that it makes as much difference when listening to voices on an audiobook). I have to confess that they’re absurdly expensive, but I have a little side business that helps me with treats like these :).

The last step when arriving to my office is to fire up some music. These days I spend the most time in the “Working (No Lyrics)” section of Songza – for instance I’m listening to Instrumental Hip Hop right now.

Embedding Voyant in your DayOfDH Post


DayOfDH Now with IFrame
It was a very last-minute request, but the fine folks at Matrix were able to accomodate my last-minute request to add IFrame embedding support to the DayOfDH network blog (by default iframe tags are stripped out of WordPress posts). And they did it remarkably quickly – thanks! We won’t think too much about the security implications, m’kay? 🙂

I’m sure my motivations for requesting this won’t be a mystery for most of you – I wanted to have the possibility of embedding Voyant Tools into my posts. Voyant supports the ability to embed interactive tools into remote sites, much like you would embed a YouTube clip.

I thought it might be useful to provide a very quick tutorial for how to embed Voyant tools into your DayOfDH blog post.

The easiest form is to just add a line like this to your blog post (this can be done in the visual or text editor, it doesn’t matter):

[iframe src='http://voyant-tools.org/tool/Cirrus/?useReferer=true&stopList=stop.en.taporware.txt' style="width: 400px; height: 400px"]

Note that when you preview your post (before publishing it), the tool may not show proper content because the content won’t yet be accessible to Voyant before you publish it. Once you publish your post you should be able to double-check that the content looks plausible.

The iframe plugin works by identifying the pattern [iframe src="…" …] and expanding it to a proper HTML form like <iframe src="…" …></iframe>.

You can specify the dimensions of the embedded tool using the style attribute, as well as specifying that the tool should appear floating relative to the rest of the content.

[iframe src='http://voyant-tools.org/tool/Links/?useReferer=true&stopList=stop.en.taporware.txt' style="width: 350px; height: 350px; float: right"]

Easy, right?

The ?useReferer=true part of the src attribute tells Voyant to fetch the contents of the page where the tool is embedded – that avoids the need to specify a full URL. This is very convenient, but it should be noted that the contents of the URL are only fetched once, the underlying corpus won’t change even if the original contents of the embedding web page change. If it’s important to have content updated, you can specify an input URL (note that this is very inefficient for everyone involved since the URL contents are fetched every time someone visits your page – but sometimes ya gotta do what ya gotta do):

[iframe src='http://voyant-tools.org/tool/Cirrus/input=http://dayofdh2013.matrix.msu.edu/sgsinclair/2013/04/07/embedding-voyant&stopList=stop.en.taporware.txt/' style="width: 350px; height: 350px;"]

Similarly, you’re not limited to just embedding at tool about the current contents, you might also want to show all of the posts in an RSS feed. Note the inputFormat=RSS2 and splitDocuments=true parameters here that tell Voyant to build a corpus of individual documents based on each post in a standard RSS fee.

[iframe src='http://voyant-tools.org/tool/Cirrus/?input=http://dayofdh2013.matrix.msu.edu/sgsinclair/feed/&inputFormat=RSS2&splitDocuments=true&stopList=stop.en.taporware.txt' style="width: 350px; height: 350px;"]

But Sinclair, you say to me, don’t you know that word-clouds are nefarious – don’t you have something else to offer? Why sure, you might be interested in replacing the Cirrus part of the URLs above with one of the following:

  • TypeFrequenciesChart for graphing distribution top terms
  • Bubblelines for graphing overlap of top terms
  • Links for graphing collocates (words in proximity) for top terms
  • Knots for graphing repetition of top terms

Some of the other tools are documented here.

Oh, and DayOfDH might be a good day to launch a new tool, don’t you think? Stay tuned :).