The collaboration makes sense on many levels, but here are two that surface readily:

1. These are complex technologies that function in a complex social and cultural system. We can meet the development needs because we represent institutions with different institutional missions, different (though like-minded) communities, with different resources.
2.  Our students, who will seek jobs in which they work collaboratively in different institutional missions, from the perspective of different (though like-minded) communities, with different resources, must be prepared to meet these challenges within a network of a the wider DH community.

If we believe in a basic DH tenet that making is a theoretically framed activity that helps deepen our understanding of our cultural artifacts and our modes of knowledge production, we must instill, as Bethany so aptly articulates, ”a can-do, maker’s ethos” in students who will feel “empowered to build and re-build the systems in which they and future students will operate.” To further this cause, we must also instill a second basic DH tenet in our community of scholars, makers, and teachers: we must pool our resources, both technical and academic, and develop our technologies (such as the TEI and Omeka) and mentor our students, together.

Both Carin and Zane will blog regularly in this space as the project develops. Onward ho, ya’ll.

I love lists almost as much as I love agendas and program management in general. Here is a status update in list form for you, Dear Reader. And Team, please feel free to expand/clarify/correct the following:

1. We have finalized the texts we’re going to be uploading into Prism for first-round users. Today, some of us tested a few of the suggested “highlighting” categories with help from our low-tech friends: transparencies, markers, and photocopies. Ed, Brooke, Annie, and I will be reviewing and revising categories over the next few days, and the entire Praxis team is invited to test our new suggestions this coming week.

2. The development team met their latest milestone goal: authentication and authorization for the Prism site is a go! User accounts! Ding!

3. As Lindsay notes, the wireframes (and thus, for the most part, the user story), are finalized. Design wizzes (plural of wiz?) Ed and Lindsay have been rocking out on the front-end work: Ed continues to wow us with his aesthetic brilliance (see his “striptease” post of Jan 26), while Lindsay works on making the dream a reality via CSS/HTML.

4. We’ve been inspired by the recent trend toward internationalizing Ruby on Rails applications, and have nominated the most Continental of our Fellows, Alex, to the position of Internationalization Expert(-to-be). I’m sure you’ll be hearing more from him about this exciting new development in the near future.

5. Finally, on a more personal note: I continue to enjoy how much time I get to spend with my colleagues while we work toward a common goal. Collaborative ventures certainly pose some challenges that would be non-issues in individual project contexts, but I think we’re all benefiting from learning how to work not only with digital tools but also with one another. The Fellows’ lounge was busy busy busy today–and that’s the way we like it!

Since I’m so new to HTML and CSS, I have no shame about asking for help with the smallest issues (like italicizing text) or with far-reaching errors (the whole page is the body?!), but I also have no shame about celebrating the smallest successes (rounded corners!). In addition to a few meetings with Jeremy, Ed’s great ideas and Illustrator skills and Annie and David’s HTML knowledge have helped me make progress. People are probably going to start sending me “Let me Google that for You” links pretty soon, but at least right now, I’m feeling warm and fuzzy and collaborative. On Monday morning, Brooke, Sarah, Jeremy, Ed, and I worked through the wireframes for Prism one more time. We had some drafts from the end of last semester, but some decisions about how the tool will work have affected how the site will look, so we revisited our wireframes and got them in good enough shape to present to the whole team on Tuesday. This picture shows what we came up with. It doesn’t look like much, but I think we all feel pretty accomplished now that we have a “clean” and simple form to design on.

The above video shows the visual options offered by the model of the deck prism.

While the deck prism is recognizable as an object, its clarity and sharp lines make it a good source of abstract imagery for the site. The model also allowed me to experiment with reflections of the texts we chose as our three highlighting samples. The text was simply applied to a plane directly below the prism in the 3D scene, and the reflections changed on the fly based on the camera position. You can see part of the first line from “The Raven” reflected in one of the images below.



Finally, the last image shows the highlighter “palette” that we used for our wireframe. The boxes are mostly just placeholders, but the colors represent some of the options that came out of the deck prism, and I think the categories we chose for Edgar Allan Poe”s “The Raven” could elicit a thought provoking response from a crowd.

*UPDATE: The position is now open to all qualified candidates.
Please note new URL below!

Senior Research Specialist, SCI

The Scholars’ Lab at the University of Virginia Library seeks a senior research specialist for a full-time, 18-month position with the Scholarly Communication Institute (SCI). The ideal candidate will have: excellent research, writing, and organizational skills; familiarity with humanities scholarship at the graduate level; and an interest in experimental approaches to digital authoring and publication or the education of emerging scholars and knowledge workers. Some travel is required, and there is a possibility of a work-from-home arrangement for a professional and thoroughly reliable candidate.

Reporting to UVa Library’s director of digital research and scholarship, the SCI research specialist will:

• help design, execute, and analyze a broad-based, anonymous survey of humanities professionals (together with the perceptions of their employers) to examine graduate-level preparation for so-called “alternative academic” careers (20%);
• attend and provide research support for three meetings and regular conference calls on new-model publishing and authoring environments, in order to take notes and help compile proceedings and recommendations (15%);
• attend and provide research support for two to three meetings centering on the reform of methodological training in the humanities, involving major humanities consortia, professional associations, and funders, to take notes and help compile proceedings and recommendations (15%);
• assist in research and organizational tasks related to the development and day-to-day operations of the Praxis Program at the University of Virginia Library, including the hosting of a gathering to foster inter-institutional collaboration on similar initiatives (20%);
• and perform other research and writing tasks as needed by SCI principals (10%).

The SCI research specialist will join a vibrant and dedicated community of faculty and staff at the Scholars’ Lab, and as such will be eligible for the self-directed “20% time” that all team members are granted to pursue professional development and their own (often collaborative) R&D projects. This is a grant-funded position with a salary of approximately $50k per annum and full benefits as a member of the managerial and professional staff of the University of Virginia. The position begins no later than March 1st, 2012 and extends no later than August 31st, 2013.

Experience and Education: Master’s degree or higher in fields related to humanities scholarship or information science. Demonstrated ability as a writer and researcher. Project management experience or experience with survey design and analysis desirable.

Please APPLY ONLINE.

Our next programming steps include building a user model and incorporating authentication and authorization (probably using CanCan and Devise ruby gems).  This will be more complicated that what we’ve produced so far, but we think that with the help of lots of screencasts and ruby gem documentation, we will persevere.

On other prism news, we will officially decide on our texts for Prism today in our meeting!  It’s all starting to take shape.

The most important product of our meeting was the project workplan timeline the team collectively created. I know that deadline-lovers Brooke and I feel six hundred times better about how the rest of this semester is going to proceed, but I think everybody is happier knowing exactly what needs to happen and when. I would only be exaggerating slightly to say that it was magical to watch the workplan take shape. Despite the fact that we’ve all been meeting weekly for an entire semester, as the project has progressed and the design team and programming team have been working more independently of one another, it has been difficult to see how everything fits together. But when we had to agree on deadlines for project milestones (when will we be able to display a text? when will user accounts be ready? when should the highlighting tool be functional?), designers and programmers had to engage in a dialogue about what each group would need from the other in order to meet these goals.

The meeting served as yet another reminder of how absolutely, impossibly lucky I am to be part of this program. As project managers, Brooke and I are ideally positioned to understand how the Praxis Program and our project Prism work as collaborative ventures. It is impossible for every member of the team to keep track of what each subgroup is doing at all times, but it is necessary that project managers do just that. I can’t wait to get my hands dirty! I’m sure I speak for both of us when I say that we are thrilled and honored by the trust our team has placed in us. We won’t let you down!

Brooke posted last week about seeking out ways to engage in collaborative work, and I want to point very quickly here to the Digital Humanities Summer Institute. I attended DHSI last summer, and it certainly didn’t disappoint on the collaborative front. Brooke and I are both making the trip to Victoria this summer, and I’m sure she will only find more evidence there of what she’s seen so far as a graduate student in the humanities: seek collaboration, and you shall find it. If you’ve never been but always wondered, I highly recommend that you make this the year you join the (collective) fun!

Saturday evening I had a chance to catch up with one of my early undergraduate mentors. He had questions. He wanted to know what I knew about the DH world. I’m sure half of his curiosity came out of an earnest desire to hear the tale of my travels. The other half was a shrewd (and responsible) move to build a vocabulary for conversations his department will inevitably have this year with the dean, other departments, the library, etc: Can an isolated DHer work well with limited resources? Do you need a center? How do you get graduate students involved? Our conversation went on for a good three hours and it was very rewarding to offer a candid assessment of the field from where I’m standing.

I also realized that where I’m standing is what in battle we would call higher ground. I don’t mean the privilege of hobnobbing with the enormous DH talent we have on grounds. Nothing, of the sort. Although projects are a whole different affair, you could develop decent DH skills and ideas were you connected from Pie Town. I mean the privilege of seeing graduate methods transformation first-hand. I agree with Brooke that there is a continuum that links us to analog models in the department (at least at UVa). But the continuum does eventually lead to new ground.

What I’ve seen, of course, has been well recorded here by all the Praxis bloggers. If this is your first time visiting our site and you are interested in the fresh air blowing our way, I encourage you to read more…

The readings were extremely helpful (see the “Intro to Project Management” section of Praxis topics for our short list of most helpful resources), especially Brian Croxall’s ”12 Basic Principles of Project Management” and Sharon Leon’s “Project Management for Humanists.” Both articles stress the PM’s need to assess the viability/sustainability of a project before it’s begun, the importance of a clear and flexible workplan that is derived collaboratively and realistically, and the PM’s responsibility to manage and encourage frequent communication amongst team members and partners. Both articles also begin with a point that has been made quite frequently, but that has not necessarily been my experience as a graduate student so far: that humanities graduate students are not trained to work collaboratively.

While I wholeheartedly agree with Leon, Croxall, and most of the DH community that graduate education must be transformed to formally, explicitly transmit this kind of training to humanities scholars, for the sake of the individual scholar and the profession as a whole, there are many opportunities to work collaboratively as a graduate student, but they must be sought out and are often extracurricular and small-scale. I recognize that it can be very easy to become the scholar/hermit in a graduate program, especially because programs have not yet adapted to encourage collaborative research in the traditional sense (like a tag-team digital dissertation), but collaboration on the most basic level has been ingrained in my daily experience in UVA’s English department – from discussion in grad seminars that leads to new research, to collaboratively editing papers and personal statements with peers and faculty mentors alike, to extracurricular activities like the Graduate English Students Association and its conference committee (groups that require quite a bit of PM-type skills).

This is not the kind of training Leon and Croxall are calling for, but my graduate education (so far) has trained me to seek out opportunities to collaborate with others within the department and outside of it (in my work with Praxis and IATH, for example). I have to stress that I do not disagree with the inadequacy of graduate methodological training; if I did, I wouldn’t be a Praxis Fellow. But I think we can find the basic principles for collaborative research happening already on a very small scale, and it’s up to graduate students to make collaborative research a priority – that is, to find those opportunities, seize them, and ask their programs to support them. Pardon the lengthy post; I know I’m not saying anything new here and I may be totally off-base, but I thought I’d respond with my experience as a nascent scholar and even-more-nascent member of the DH community.

Book Two of the Iliad notoriously contains a list of nearly 190 place names and includes the 29 contingents and that make up the Greek expedition to Troy.  Before launching into an over 250-line catalogue of the leaders of the Greek forces and the number of their ships, Homer appeals to the Muses to aid him in this tour-de-force of memory.  Without their help, he says:

I could not recount their numbers nor name them,
Not if I had ten tongues and ten mouths,
And an unbreakable voice and a brazen chest within,
If the Olympian Muses, daughters of aegis-bearing
Zeus, would remind me how many came under Ilium.

The Catalogue of Ships that follows this invocation can be mapped as an itinerary, or more precisely, three itineraries that traverse most of Greece.  The theoretical basis for the project I am undertaking with the Scholars’ Lab at the University of Virginia Library is already complete. In my recent book, Homer’s Trojan Theater (Cambridge University Press, 2011), I argue that Homer was able to recite the Catalogue by creating a mental journey that used the mnemonic techniques involving loci or places, well known from ancient rhetorical writers.  By envisioning a series of places, Homer could mentally walk – or sail – through Greece and produce a detailed catalogue. Our project will reproduce that journey by showing that the itinerary described follows the natural contours of Greek geography and the patterns of early Greek urban organization.

Mapping the Catalogue of Ships involves several steps.  “Least-cost path” GIS analysis by the Scholars Lab is revealing the terrain that must naturally be followed when taking a walking tour of the Greek mainland.  We are creating an interactive map that follows that path.  The Barrington Atlas of the Ancient World (2002) as well as the recent Historischer Atlas der antiken Welt (2007), The Homer Encyclopedia (2011) and the Pleiades Project, a collaborative database for ancient sites, have pinpointed locations for which we have evidence.  We will attempt to link the sites mentioned in Homer with archaeological material and useful bibliographies.  Finally, we hope to do in situ investigations by actually traversing the plotted itinerary at ground level to survey the terrain, and create extensive panoramic photography. Our main goal is to demonstrate that the arrangement of the Catalogue, far from a random list of place names, corresponds to the natural geography of Greece.  In cases where the position of a site is unknown or disputed, we hope that our analysis will provide plausible geographical and literary evidence to help identify its location.

Collaborators in this project include Ben Jasnow and Courtney Evans, two of my graduate students who worked with me on the Trojan Theater project and who are assisting with GIS analysis, under the guidance of Chris Gist and Kelly Johnston of the Scholars’ Lab. Wayne Graham and other members of the Scholars’ Lab R&D division are creating a presentational framework for our maps and text, and Jeremy Boggs is our lead designer.

Jenny Strauss Clay
William R. Kenan Jr. Professor of Classics

I think it’s brilliant the way that Praxis has been structured, with one training-intensive semester and the next semester spent – I’m assuming – in executing what we’ve been theorizing. That’s not to say that we haven’t done anything yet; we have produced the programming and design foundations for Prism that we will hammer down and build from in the months to come. There have been days in the grad lounge, though, when I’ve felt anxious about how much work there is left to do and how difficult it seems to reach concrete goals when our discussions usually raise more questions than they answer. But even if we spend our entire Tuesday mornings arguing/theorizing about what we think Prism should accomplish, our time isn’t wasted if it means Prism will be (1) a clearly designed tool (2) with a distinguishable thought process that (3) makes a specific intervention.

All of our discussions have addressed at least one of those three points without fail, so our mission in the months ahead is to channel our humanities-inspired zeal for theorizing into reaching the goals we set for Prism in September – mainly, that we want to produce a working, 1.0 version of Prism by the end of the academic year. To reach that final, rather intimidating endpoint, I’d like to suggest that the Praxis team begins the new semester by establishing (collaboratively, of course) some real, manageable, short-term goals for the coming weeks.

I’m beginning to recover from Winter Break Amnesia (I’m sure our first Praxis meeting tomorrow will quickly bring me back to reality), but I am looking forward to getting back to learning HTML and CSS, to our civilized theoretical arguments in the grad lounge, and to those glorious moments when we (with the help of the gurus) learn how to turn theory into praxis and bring Prism further into the light.

<input class="simple-fixture" type="text" />

This works fine, provided that the HTML your code is working on is relatively simple. In practice, though, most front-end applications that grow beyond a certain critical mass of complexity end up with JavaScript code that makes DOM touches on large, complex markup structures that can’t be so easily replicated independent of the application itself.

This issue started to rear its head as Neatline became more and more complex over the course of the last couple months. The Neatline front-end consists of well over 10,000 lines of JavaScript, which works on markup generated by about 20 templates and partials – it would be a frightful headache to have to manually create a library of testing fixtures for the whole application. And even if I took the time to build them all out by hand, I would be committing myself to a labor-intensive, open-ended maintenance task: Every time you make a change to a template, you have to remember to comb through all the files in the fixtures library and replicate the change. Over time – and especially as new developers start working on the project – there’s a high probability that the “real” HTML generated by the live application will start to diverge from your fixtures.

My search for a solution led me to this fantastic post from JB Steadman at Pivotal Labs. Basically, he describes a clever method for automatically generating a library of HTML fixtures that uses the server-side test suite as a staging environment that prepares, creates, and saves the markup emitted by the application. That way, your fixtures library can only ever be as old as the last time you ran your back-end test suite, which should be a many-times-daily affair. I was able to implement this pattern in the Omeka/Zend + PHPUnit ecosystem with little difficulty. (Details and code after the jump)

Basically, we do this:

1. Create a special controller in your application that exists solely for the purpose of rendering the templates (and combinations of templates) that are required by the JavaScript test suite;
2. Create a series of testing cases that issue requests to each of the actions in the fixtures controller, capture the responses, and write the generated HTML directly into the fixtures library.

How does this work in practice? Imagine you have a template called _records.php that looks like this:

<div id="container">
  <?php foreach $records as $record: ?>
    <h1><?php echo $record->title; ?></h1>
    <div><?php echo $record->description; ?></div>
  <?php endforeach; ?>
</div>

And when it’s rendered in the application, the final markup looks like this:

<div id="container">

    <h1>Record 1 Title</h1>
    <div>Description for record 1.</div>

    <h1>Record 2 Title</h1>
    <div>Description for record 2.</div>

</div>

So, the goal here is to create a controller action that populates the template with mock records objects and renders the markup, which can then be captured and saved by an integration “test” that we’ll write in just a minute (test in quotes, since we’re using PHPUnit not so much as a testing framework, but more just as a mechanism for automating requests). First, add a new controller class called FixturesController, and create an action that mocks any variables that need to get pushed into the template:

class YourPlugin_FixturesController extends Omeka_Controller_Action
{

    /**
     * Generate fixture for _records.php.
     *
     * @return void
     */
    public function recordsAction()
    {

        // Turn off the default Zend layout-discovery functionality.
        $this->_helper->viewRenderer->setNoRender(true);

        $record1 = (object) array(
          'title' => 'Record 1 Title',
          'description' => 'A description for record 1.'
        );

        $record2 = (object) array(
          'title' => 'Record 1 Title',
          'description' => 'A description for record 1.'
        );

        $records = array($record1, $record2);

        // Render.
        echo $this->view->partial('public/_records.php', array(
            'records' =>  $records
        ));

    }

}

Basically, we’re just stubbing out two artificial record objects (for simplicity, we add only the attributes that are used in the template) and directly render the template file as a “partial.” Note the call to setNoRender(true) – by default, Zend will try to automagically discover a template file with the same name as the controller action, but we’re just disabling that functionality since we want direct control over which templates get rendered and in what order.

Next, add a directory called “fixtures” in the /tests directory, and create a file called “FixtureBuilderTest.php” to house the integration test that will do the work of requesting the new controlled action, capturing the generated markup, and saving the result to the fixtures library.

This should look like this:

class YourPlugin_FixtureBuilderTest extends YourPlugin_Test_AppTestCase
{

    private static $path_to_fixtures = '../spec/javascripts/fixtures/';

    /**
     * Instantiate the helper class, install the plugins, get the database.
     *
     * @return void.
     */
    public function setUp()
    {

        // Set up the testing environment and plugin.
        parent::setUp();
        $this->setUpPlugin();

    }

    /**
     * Fixture builder for _records.php.
     *
     * @return void.
     */
    public function testBuildRecordsMarkup()
    {

        $fixture = fopen(self::$path_to_fixtures . '_records.html', 'w');

        $this->dispatch('your-plugin/fixtures/records');
        $response = $this->getResponse()->getBody('default');

        fwrite($fixture, $response);
        fclose($fixture);

    }

}

Note that you need to specify the location in the project directory structure that you want to save the fixtures to. In this case, I’m saving to the default location used by Jasmine, but you could point to anywhere in the filesystem relative to the AllTests.php runner file in /tests.

Make sure that the /fixtures directory is included in the test discoverer in AllTests.php, run phpunit, and your fresh-out-of-the-oven fixture should be saved off and ready for action! All that’s left to do now is load the fixture in your JavaScript test, run your code on the HTML, and start enumerating test cases. We use a testing framework called Jasmine in conjunction with a plugin called jasmine-jquery, which provides an easy way to load fixtures into the tests:

/*
 * Unit tests for the records Javascript.
 */

describe('Records', function() {

    var recordsContainer;

    beforeEach(function() {

        // Get the records markup.
        loadFixtures('_records.html');

        // Select the container div.
        browser = $('#container');

        // Instantiate your code.
        browser.recordsWidget();

    });

    // Now, the tests:

    describe('some class of behavior', function() {

        it('should do X', function() {
            expect(true).toEqual(true);
        });

    });

});

It can be easy to create an over-wrought logo when you devote a long section of time to it. As you push, pull and minutely alter an initial idea to make it different from a previous example, the result is often an amalgamation of too many ideas. Inversely, I have found that a logo I create quickly “works” best because the quickness of the stroke leads to a corresponding quickness of communication.

The group’s decision to pursue a logo that more clearly represented an actual prism gave the logo direction, but it also capped the logo’s level of abstraction. It was my hope however to see how far I could abstract the design without losing its representative quality. At its core, a prism is inherently a narrative object with an implied beginning, a transition, and a result. These three elements had to exist in the logo with a perceivable order. As for most things in a digital medium, the four possible changes could be shape, texture, scale and color. In the end, I could not use all of these elements as part of the transition without the narrative breaking down. The transition was therefore set for scale and color, and the “transition object” was simplified to contrast with the color and scale changes on either side of it.

I admit that logos and font choice do not make for the most entertaining reading, especially without visual examples (You readers will have to wait until we have a prototype of the site to see the logo.) That said, I wanted to note that the representative prism “narrative” option ended up completely changing my approach to the font for the prism logo. Initially, I looked exclusively at more stripped-down, modern, sans-serif fonts with the vaguest hint at a meticulous human hand in order to connote a sense of precision for the web application. However, after selecting the representative design of the prism and its narrow beam motif, the width of the sans-serif fonts seemed to dwarf the rest of the logo. I then began to look at fonts with bracketed serifs and long flat bases that invoked the shape of the thin horizontal lines in the rest of the logo.

Today’s meeting should offer us an opportunity to get all but the last details decided on for the logo. I am looking forward to hearing everyone’s reaction.

On November 11th, the University’s new Institute of the Humanities and Global Cultures hosted a daylong symposium on “The Humanities in a Digital Age.” The symposium included two panels—one on Access & Ownership and the other on Research & Teaching—and two keynote talks.

The first keynote was given by Stephen Ramsay, Associate Professor in the Department of English and Fellow in the Center for Digital Research in the Humanities at the University of Nebraska – Lincoln.

The second keynote was given by Dan Cohen, Associate Professor in the Department of History and Director of the Roy Rosenzweig Center for History in New Media at George Mason University.

Panel 1: Access and Ownership

Jeremy Boggs, Humanities Design Architect, UVa Library Scholars’ Lab
Ann Houston, Director of Humanities and Social Sciences, UVa Library

Keynote: Stephen Ramsay, “Textual Behavior in the Human Male”

Panel 2: Research and Teaching

Alison Booth, Professor, Department of English
Mitch Green, Horace W. Goldsmith Distinguished Teaching Professor of Philosophy, Department of Philosophy

Keynote: Dan Cohen, “Humanities Scholars and the Web: Past, Present, and Future”

As always, you can listen to (or subscribe to) our podcasts on the Scholars’ Lab blog, or on iTunesU.

On November 4th, the UVa Music Library and the Scholars’ Lab welcomed Dr. Johannes Kepper, Entwicklung/Betreuung Kooperationspartner at the Edirom Project, and Mr. Julian Dabbert, Wissenschaftlicher Mitarbeiter on Project TextGrid at the University of Paderborn.

Dr. Kepper and Mr. Debbert discussed the requirements, characteristics and benefits of digital editions based on the Music Encoding Initiative schema, as well as MEI-based applications such as the Edirom toolset and the MerMEId metadata editor. The whole group also discussed the impact of these technologies on scholarly editing in general.

As always, you can listen to (or subscribe to) our podcasts on the Scholars’ Lab blog, or on iTunesU.

First, one of the extremely knowledgeable members of the Praxis team teaches the newbies about something. Here, that something is wireframing.

Next, Praxis Fellows try out their own ideas on the new concept, using each other as sounding boards. We achieve various degrees of success depending on a number of factors, including that day’s caffeine intake level.

At some point, the knowledgeable Praxis team member usually has to avert some kind of impending crisis: “I’m going to make an intervention, because you need one.” But these interventions are always performed in a very kindly fashion. We appreciate them. (This photo actually captures two such interventions occurring simultaneously… wireframing and programming CAN happen in the same room!)

Finally, the focus group (wireframers here again) agrees upon some kind of model to be used for sharing with the larger Praxis team at the weekly Tuesday afternoon meeting. We dissect, discuss, and suggest modifications as a group. Then it’s usually back to the Fellows Office for revisions and a repeat of the process.

Disclaimer: the above images are drafts and first-round workings-out of wireframing problems. They are not necessarily representative of where we are now with our wireframing. I don’t think we’re giving away anything too top-secret, and since one of the goals of this program is to be “live and in public” I thought it was about time you got to see something we’ve actually drawn up ourselves.

As a final touch to this essay on the joys of group work, I’m appending, for your delectation, a sampling of overheard office hour chat:

–Discussing life’s most challenging questions, such as Why We’re Here:

Ed: I’m here to break your application with one capital letter. That’s why *I’m* here.
Wayne: You’re not gonna break MY application with one capital letter.
Ed: You just let me at your application…

–And another vignette from today featuring Ed:

Ed: YESSSSSSSSSSS!!
The rest of us: [quizzical looks]
Ed: I just got Heroku to work on my application. And even better, Wayne was wrong.
[laughter]
Ed: I’m gonna go tell him.

Til next time!

When we had more or less finished, we posted it on the IRC to discuss with whoever was online. We found Bethany, Eric R. and Jeremy. In the discussion, two suggestions came up which I think are important to keep in mind as Prism moves forward. Originally we had the model now named ‘Prism’ named ‘Experiment.’ The concern there was that the word was not catering to a humanist audience, or at least that part of it that understands itself outside the boundaries of science. In the same spirit, the field now named ‘prompt’ was originally named ‘research_question’. The other concern was over the use of the word ‘Tag’. That was the original name of the model now named ‘Facet’. The concern there was that the word brings with it its own semantic baggage, which might confuse the user. The new choices, ‘Facet’ and ‘Prism’, have the added advantage that they bring the color of Prism into the data models.

Something happened in that conversation. I realized that in order to be descriptive with data or objects, I don’t have to be clinical. I had realized the same for prose a while back, but it took this exercise to see what’s good for literature is good for code. Now I am ready to understand the full extent of the claim that code is an expressive language. Even if we will only have a few opportunities to share the language of the model with a general audience (a paper or conference talk here and there), we should code whenever possible with a humanist’s ear.

Before I started coding, I wanted to make sure I knew what I was doing, so I wrote a few user stories and passed them around for comment. Part of the value of user stories is that they are expressed in short, natural language statements, but they can also be transitioned into acceptance tests that everyone has had a voice in.

(I should mention that I’m really just trying out user stories. They seem like a good idea in theory, but we’ll have to see how it works in practice.)

When testing Omeka plugins, I use Omeka’s unit testing framework (PHPUnit). I don’t see a reason to change that. However, unit testing frameworks generally aren’t a good fit for acceptance tests. They are both too focused and low-level and sometimes don’t have a great way of acting like a browser. A bigger problem is that they shut non-coders out of the loop. Having an English-y way of expressing tests helps to involve everyone working on the project, not just the developers.

For the Praxis Program, we’ve been talking about using Cucumber for testing. I thought this would be a good time to try it out.

I expected this would be painful.

Fortunately, I was wrong.

About the System

The tests will be driven by Cucumber. Since this is in Ruby, they won’t interact directly with Omeka (there is cuke4php, but I’m not going there). Instead, everything will take place through the browser. Here’s how the system breaks down:

Cucumber will read in the tests and execute them. It provides the language that we use to write the tests and the code we use to implement them.

Capybara defines a DSL for interacting with the browser. We’ll use this when we define actions or steps for the tests.

selenium-webdriver allows Capybara, Cucumber, or any Ruby code to talk to the browser.

Selenium is a system for writing tests that run in the browser. It has a Firefox plugin, which we’ll use today for actually doing the tests.

Omeka, PHP, and MySQL are all running in a VM, managed by Vagrant. (See this post for how to set up the system.)

Rake is used to control the system.

Adding Ruby

Most of these tools are in Ruby, so the first step is to mix Ruby into the Omeka/PHP plugin project. To manage Ruby, I use RVM, so I added a .rvmrc file to switch to the right version of Ruby and make sure all the right gems are installed:

rvm use 1.9.3
bundle install

The gems are listed in a Gemfile:

source :rubygems
gem 'rake'
gem 'cucumber'
gem 'capybara'
gem 'selenium-webdriver'

That’s it. Now, when I change to the plugin directory, Ruby and the gems I need are available.

Setting up Cucumber

Cucumber expects a specific directory structure. I created that with these Bash commands:

mkdir features
mkdir features/step_definitions
mkdir features/support

Cucumber also needs a configuration file in features/support/env.rb:

require 'selenium-webdriver'
require 'capybara'
require 'capybara/cucumber'
require 'capybara/dsl'
Capybara.app_host = 'http://features.dev'
Capybara.run_server = false
Capybara.default_wait_time = 15
Capybara.default_driver = :selenium

Adding Features

Cucumber groups tests into features. Each feature is in a separate file, and each contains one or more scenarios.

For a contrived example, I tested logging into into the Omeka admin console.

Feature Files

The feature file for this is easy to read and understand, by design. I put this into features/login.feature:

Feature: AdminLogin
  In order to make changes to the site
  As the site administrator
  I want to be able to log into the admin console

  Scenario: Login
    Given I visit the admin page
    And I enter "features" for the "Username"
    And I enter "features" for the "Password"
    When I press "Log In"
    Then I should see a page title of "Omeka Admin:"
    And I should see a header of "Dashboard"

That’s it. I could have added a scenario for not authenticating correctly or other cases, but I won’t worry about that right now.

Step Files

Feature files are great for people, but Cucumber/Ruby still doesn’t know what to do with it. To fill that gap, I defined what to do for each step in the scenario in a step file. I put this into features/step_definitions/login_steps.rb:

Given /^I visit the admin page$/ do
  visit('/admin')
end

Given /^I enter "([^"]*)" for the "([^"]*)"$/ do |value, label|
  fill_in(label, :with => value)
end

When /^I press "([^"]*)"$/ do |button|
  click_on(button)
end

Then /^I should see a page title of "([^"]*)"$/ do |page_title|
  find(:xpath, '//title').has_content?(page_title)
end

Then /^I should see a header of "([^"]*)"$/ do |header|
  find(:xpath, '//h1').has_content?(header)
end

(It would be better to group the step definitions into files by task or domain or some other way than one-step-file-per-feature-file, but for this demonstration, this is fine.)

Step definitions tell Cucumber what to do for each test. Inside each definition, I used Capybara commands that tell the browser what to do or check the page that the browser’s looking at. These commands use Selenium to actually drive the action, but I don’t have to worry about that.

Running Tests

We have a couple of steps left to see actual tests being run. First, we could use the cucumber command, but we’ll probably have other things to automate (PHPUnit tests, I’m looking at you), so we’ll go ahead and create a Rakefile that runs the Cucumber tests. This is easy to do, since Cucumber ships with some rake tasks.

Put this into Rakefile:

require 'cucumber/rake/task'

task :default => :cucumber

Cucumber::Rake::Task.new do |t|
  t.cucumber_opts = %w{--format pretty}
end

Now, as I mentioned before, the Omeka site is running in a Vagrant-managed VM. Start it up:

vagrant up

Once the VM’s up, run the tests by just calling rake. You’ll see Firefox start up and close down, and at the end, you should see something like this (you may want to set the video to full screen):

Cucumber-Omeka from Eric Rochester on Vimeo.

I’m surprised we haven’t considered this question as a group before now. If we remain committed to the pedagogical use of the first version of Prism, I do think we should keep the results hidden from students before they have highlighted a text. But if we want to start thinking more broadly, I’m sure there will be use cases in which collaboration would be favored over the collection and collation of individual interpretations. Perhaps we can have it both ways further down the line, with researchers who upload texts given options about what is visible to which users. Our “original” idea of “crowdsourcing interpretation” seems to emphasize difference, but the collaborative version would seem to move toward a singular or unified or at least somehow standardized interpretation of an object. Wayne also pointed out how this issue has major implications for those writing the code, so here again what we thought might be a simple discussion of wireframing turned into a conversation about the methodological approach or assumptions of the tool we’re building. We still need a stronger foundation to hold up the frame.