In April, I gave an update on our Academic Commons in which I referred coyly to a senior project on which I was a technical consultant, and now that it’s up and live, I can talk about it a bit less obliquely. (Yale tends to interpret FERPA fairly conservatively, and until it was clear that the student, Charlotte Parker, was going to finish the project and make it publicly visible, I wanted to maintain her anonymity.)

Humanities students don’t tend to execute digital projects at Yale, especially not for their senior projects. Certainly, they engage in digital scholarship in a consuming sense by reading primary or secondary sources in technology-mediated ways, engaging in online research, or taking in digital media. In some ways, they are producers as well, but generally only in that baseline way we take for granted, that is by typing their essay on a computer. They may even submit their essays for assessment electronically, but my suspicion is that most will (by requirement or choice) at least backstop that submission with a paper copy.

So it was with real excitement that we accepted a request to work with Charlotte Parker ’13 on her senior project for the American Studies major. Charlotte was strongly influenced in her life by family friends who had connections to the Spanish Civil War and to America writers involved in it, and had been working at the Beinecke Rare Book and Manuscript Library for some time. These factors joined together in an idea for an online exhibit of Beinecke material related to American writers’ search for a way to write the truth(s) that they saw on the ground in Spain as well as related to writing truth in general. As such, Charlotte would have to engage in curation and analysis of a collection of materials and to engage with technological opportunities and restrictions for making her work publicly available.

Our first encounter with Charlotte came as a request for an Academic Commons site and I saw no reason to recapitulate her process of selecting a project environment, so WordPress was our site of investigation. Part of the reason for selecting our Academic Commons as the exhibit tool was that the Beinecke would like to see more student exhibits using their collections (as would many of us), and the existing infrastructure was the easiest slope. As it worked out, it was also a thoroughly appropriate tool, since Charlotte’s focus in her project was going to be less on establishing a metadata-rich repository than on presenting critical writing alongside selected objects. (In the third of this series I’ll relate an investigation into an alternate tool representing the metadata-rich branch of possibility.)

In a couple project meetings, Charlotte and I decided that she would play in an Academic Commons site with the knowledge that I could undo anything she needed undone and that she would do some legwork to figure out how she wanted to theme her site. Fortunately, she was participating in a HackYale course on website UX and bootstrapped her research and learning there. As with Academic Commons for the software, there was an intellectual infrastructure present and growing that meant we could focus in the project work on the questions of scholarship and technological implementation. Naturally, this meant also that we didn’t take the opportunity to walk through a critical examination of the technology qua technology and discuss how the choices being made affected the argument. For this reason alone, the next time we consult on an independent student project I will do my best to have at least one meeting of everyone significantly involved. No Yale student should graduate without critically examining technology at some point.

An interesting aspect of the project was my indirect partnership with Nancy Kuhl (about whom more in a subsequent post) at the Beinecke, who was Charlotte’s work supervisor as well as a mentor for the Beinecke-based research. We never had a team meeting for the project, something that might have been beneficial to Charlotte and something I will agitate for the next time we work similarly with a senior project. At least at some level, I think it would also have benefitted her advisor, me, and Nancy to sit however briefly around a table and have Charlotte walk through the project timeline with us. She was very well organized, as far as I could tell, but even so there was some of the usual flurry of activity hard upon the project submission deadline that would be nice to avoid. (Then again, I tell all students I encounter that a dirty little secret of the work world is that projects are not planned and executed substantially better than college-level projects.)

Or at least that’s the way it felt for me this spring. For one reason or another, my large projects this term ended up being three different forms of gallery and library exhibits, each filled with undergraduate scholarship. I’ll discuss each in turn, just because they were each interesting enough that they deserve proper space for consideration.

One that I knew coming into the term I would have was the second instance of something I first worked on in the spring of 2012. Professor Laura Wexler (American Studies and Women’s, Gender, and Sexuality Studies) is deeply interested in photography and its role in our lives. In particular, she has run since 1999 the Photographic Memory Workshop at Yale and offers a seminar titled “Photography and Memory”. You can read my writeup of last year’s project, but one thing that I neglected to note then was just how excited we were about this: To our knowledge this way of getting student scholarship into the YUAG was entirely novel and this level of public exposure of undergraduate research is rare. Not all the students last year were undergraduates, and possibly even most were not, but even for graduate students at Yale, short-form scholarship for a general audience is uncommon.

Somewhat predictably, this year’s edition was easier in many ways, but because I knew that was likely, I decided to bring things up a bit where I could. Where I noted in last year’s writeup that “This kiosk came together in a flurry of effort and coordination,” I conveniently omitted that the recordings were done very much in a duct-tape-and-gum manner. The recordings were done in a spare room in our offices, in our conference room, and in a spare office at Photo + Design. In each case, I used Audacity, a half-decent microphone we have, and was the sole engineer and producer. There’s a fog of perfection at Yale that makes doing things this way feel illicit, which is of course one of the attractions. But I also didn’t want to bias gallery visitors against the installation just because it wasn’t professionally recorded. Consequently, I skipped all mention of that.

This year, the recording process was also how I wanted to focus on ratcheting up the assignment from our perspective. Surely, Yale of all places has a push-button high-quality recording studio for student work? Alas, no. Some of the residential colleges have studios, and good ones, but they are limited to students in those colleges. Doubtlessly, we could have gotten around that requirement, but I’ve been there and would not have wanted a fellow student using up my college’s resources on the down low. Naturally, the School of Music and the Music Department have their own studios, but there again, they are reserved for students in those units. Enter the Yale Broadcast & Media Center studios. All signs pointed to them as the best place to get this done. The one catch, which wasn’t one, was that the work we were doing there needed to be disseminated in some way, and since we were doing audio work, we needed to make a podcast out of it. I can’t call that a catch, because being pushed to make our work more public is a Good Thing.

This brings me to the major difference from the course side this year, which was that the assignment was baked into the syllabus. Last spring, the assignment was added after the start of the course, and possibly even after registration, which very much threw the students. We can look on the students’ reaction more or less charitably, but possibly the most nearly neutral way to see it is that Yale students are very busy, and bristle when they encounter academic surprises. I mention this change at this point in my recap because I believe it is half of why the recording sessions went so smoothly this year. The other half is that we had a proper studio and a proper engineer in Phil Kearney from Broadcast & Media, and the students knew they needed to perform. (It didn’t hurt that more than one student had some experience with Yale’s student radio outfit, but most did not.) Consequently, most students got their reading done — and done well — in one take. The downside of that was that we spent far too much of the 30-minute slots I had allotted (based on last year’s efforts) with time on our hands. I couldn’t have asked for a better engineer, though, than Phil, as it wasn’t until we had gotten most of the way through the student sessions, with only one reschedule, that he said, “You know, we could just schedule them 5 or 6 at a time and just have the next one go when the previous one is finished.”

So I thank Phil for his skill and his patience, Professor Wexler for doing this assignment again, Davids Odo and Whaples from the YUAG for their work on the image and coordination side, and Thomas Raich of YUAG for going above and beyond in getting this kiosk up and running when driver and OS issues exploded 10 minutes before I was due on a train to Washington, D.C. I look forward to next year and how we can continue to integrate student digital scholarship with cultural institutions on campus.

Postscript

The exhibit is still up in the (gorgeously new) Study Gallery at the YUAG, so if you can, do head over and see it. Neither YUAG IT nor I (nor Professor Wexler) are thrilled with some sloppiness of the touchscreen we needed to use this year, last year’s being already allocated for other needs. But if you do go and find the cursor unresponsive, just touch far away from your target and then try again. We’ve found that tends to be better than repeatedly trying to move the cursor by small increments.

Addendum 1: Almost in a procrustean manner, this theme resizes images on the fly to fit the available screen space. Lovely when you have big chunky images, not so great when you have something small. However, I corresponded with the developer and found out that you can prevent this from happening. It’s a workaround for, at minimum, intermediate users. TO prevent resizing, add “noScale” as a style class to the desired image. You’ll have to go into the HTML tab of the editor interface to make this change, and be sure that a) you add the class name to the existing style attribute of the image and b) you enter the class name exactly as written above, as it is case-sensitive.

I’m not personally directly affected by this change, since I use Vienna as a desktop reader and Pulse on my mobile devices. (I don’t do a lot of RSS reading on mobile, so it doesn’t matter to me that Pulse won’t bulk import my feed list from Vienna.) But by the same token, I am concerned about the future of RSS now that one of the major supporters of it has changed its mind. RSS is one of the high points of open standards online, highlighting what can be done with relatively simple programming. Without denigrating Aaron Swartz, the fact that the RSS 1.0 spec was partly authored by a 15-year-old (albeit a bright and creative 15-year-old) speaks to how elegant it is.

We’re not zealots about Open here at ITG, but it is something we like to choose. Our biggest example is the use on Yale Academic Commons of WordPress and WikiMedia. Both are open-source pieces of software that anyone can install on their own computer and change at will. Both are also open in that anyone can play around with making changes to the code and can even request that the changes get incorporated into the final product. Even without touching the code, there are ways to be involved with the production of these tools that have proven immensely valuable for education. You can review beta versions, contribute documentation, or just tell other people about your experiences with them.

If you would like to try something out, put in a request for a WordPress site or talk to us about wikis. If you want to go beyond what we host here at Yale, we’d love to talk to you about that, too.

I’m here in Providence (can’t you see where I am?) for a three-day workshop at Brown on contextual encoding with TEI, run by the Women Writer’s Project, and led by Julia Flanders and Syd Bauman. One of the first things I did when getting on board with digital humanities was to take part in the first iteration of THATCamp New England in 2010, and I’m glad I didn’t really have any idea who I was there with, or I would have been horribly intimidated instead of just self-conscious. One of the other attendees was Julia Flanders, and among other things she leads the Women Writers Project at Brown. What I learned about the WWP at THATCamp was impressive, but I have since learned (tonight, if you must know) is that it is a self-sustaining project residing at Brown. As I also know more about sustaining university-level projects than I used to, I am even more impressed. However, I have also built up my knowledge of and abilities in digital humanities, so I’m also more ready to approach problems with what I would consider, were I leading a workshop such as this, an appropriate level.

It’s a strange situation for me, as I have worked with text encodings in one way or another since some time in the mid-90s when I was in publishing and worked with Quark XPress, though I didn’t entirely know at that time what I was doing and certainly didn’t know about the global history of text encoding, let alone SGML, TEI, and XML. In my second stab at making it in the publishing world, I learned a bit more about that space. While at HarperCollins in the late 90s, we used an in-house encoding system that we called Text Markup System, though we also were phasing it out when I was laid off. Even so, I never really associated my work in TMS with a larger world of text encoding, not even with the HTML that I was teaching myself on the side. Extend that situation roughly through the next several years, and you’ll see that while I understand a lot of the basics of markup and even have paid attention to some of the questions posed about TEI and to limitations suggested from some critics, I still have a lot to learn during this workshop.

Today was, I expect, the strongest showing for the awkwardness, as there was a good deal of scene-setting. We went through general notions of why we encode research objects and the basics of XML in the morning, then got in to the basics of TEI in the early afternoon, with enough time in the later afternoon to work on our own documents. My attention was frequently consciously divided, as much of the presentation was known material for me. Since I don’t have a research project per se (that is, my text-based research projects are whatever faculty or students bring to me), I needed to choose a work that would be appropriate for a workshop on contextual encoding. With some advice from Yale post-doc Natalia Cecire, I settled on Émile Zola‘s Le Ventre de Paris, and I haven’t regretted it. Among her many other helpful suggestions was Jean Toomer‘s Cane novel with the benefit of having some site-specificity in the good ol’ US of A as well as that of having multiple text formats for juicy encoding goodness. However, what I might call my research interests include continually examining digital humanities tools, practices, and constructions from a multilingual or plurilingual point of view, so I went with the Zola and grabbed the textfile from Project Gutenberg. My recollection is of having read it years and years ago, but I can’t recall with any further precision, so this process is also about getting reacquainted with this story.

After discovering and then applying Matthew Jockers’ Python text-to-TEI formatter for Gutenberg content (I knew learning some Python would come in handy one day!), I dumped our friend Émile into le ventre de oXygen and spent some time figuring out what I care about in this text and how to encode it. Since we are dealing in context, I decided to start with marking up all specified locations and all people. So far, I’ve been able to geocode everything I’ve found, but I’m still at a fairly generic and introductory point in the text. Even so, while I say I’ve been able to geocode what I’ve found, it hasn’t been entirely straightforward how to then encode it. For instance, there’s an early mention of the Pont de Neuilly. Reading a little too closely, which is not to say doing a close reading of course, I wasn’t sure whether it was the bridge of the same name currently located in Neuilly-sur-Seine or some other one that may have been eliminated. Even so, it wasn’t so simple to reference with a GeoNames page as was Paris. The latter got a placeName element and a ref attribute with a GeoNames page URI, but for the former I had to bludgeon GeoNames into giving me an OpenStreetMap page based on the lat-long. I played around with using something different for the rue de Longchamp, ending up with a nesting of place, location, and geo with location having a sibling of placeName that contained “rue de Longchamp.” In a very small way, it’s an editorial decision to assert that Zola meant the intersection of rue de Longchamp and Avenue Charles de Gaulle, not least because Zola never met Charles de Gaulle. But that’s what I’m hoping to get deeper with over these three days — these editorial decisions, how they can be made manifest as a result of the encoding choices, and how they can prove useful in scholarship for Yale researchers and student-researchers.

Robin, thank you for your years of service and we wish you all the best on your return engagement at HGS. On a personal level we will miss you but we’ll see you around campus and, as you’ve assured us, when Peeps Fest rolls around.

Since the close of classes in May, I’ve found more time to work on getting into the weeds with my 絵巻物 project and have made some forward motion.

One of my best discoveries has been that Adobe Photoshop CS 5.1 will execute the image tiling needed to allow zooming as happens in most of the typical large image presentations that I’ve found online. (For some scroll examples, see my post at Digital Humanities Questions and Answers.) Though I’ve only done it with my proof of concept section of the scroll, it was not a horribly intensive or time-consuming procedure. Strictly speaking, what Adobe has done is to bundle Zoomify capabilities into Photoshop. Using the steps described by Adobe’s help documentation, the output is not only the image tiles for my TIFF, but also an instance of the Zoomify interface for navigating around the image. My goal on this project is to come up with something that does not require that Zoomify interface, because it requires Adobe Flash Player and (two sides of the same coin) is proprietary software.

A related approach, discovered by getting a recommendation from colleague Michael Friscia, was IIPImage, an open source image server for large (as large as multiple gigapixel) images that similarly uses tiles to zoom in and out of an image. Besides not relying on proprietary technology, one big win of IIPImage is to allow for the creation of a single TIFF file with multiple resolution tiled images inside it and for the server to handle those tiles rather than needing to generate a folder structure. There’s also an Adobe help doc that helped me decide on the right settings for saving my POC TIFF in the best way. However, any way I sliced it, I couldn’t manage to save it so that IIPImage could handle it directly and still needed to install VIPS and massage the image one more time to get something that IIPImage could handle.

It was also no piece of cake getting IIPImage to work in the first place. As I mentioned on my own blog, I was running MAMP on my primary computer, and MAMP wasn’t having any part of FastCGI. Consequently, I started the work on a virtual machine of Ubuntu version 12.04 (Precise Pangolin*). I’d installed this VM for another project a while back, so some of the problems I encountered (too little storage allocated, 32-bit instead of 64-bit, etc.) were my own darn fault. But like much of the FOSS world, in my opinion, the ethos of modularity didn’t play out as well as it should have in principle. Most notably, I kept having errors that were not clearly the fault of FastCGI (required for IIPImage) or IIPImage itself. The solution, broadly speaking, was to destroy known non-working parts and build back up with tests along the way. Credit is due in part to the responsiveness of Ruven on the @iipimage Twitter account and in his forums, and in part to the many individuals who took their time to post tutorials or answer Stack Exchange questions relating to my problems.

However, hooray!, I’ve got two basic interfaces for my POC scroll image working! More exclamation points!!!

The next problems I’m going to need to work on are annotating the image in a complex manner and interconnecting overlays or transparency with the annotations. There’s already a promising model for annotations from Le Centre national de la recherche scientifique that I’d like to refine in a couple different ways, and a possible model for overlays from the e-Mouse Atlas Project in Edinburgh. What I think will be a smaller problem is what to do with something of significant (in an image sense, at least) horizontal scale like this emakimono I’m working on. At nearly six feet long, it’s not clear yet whether it will be preferable to break it up into sections or to just jam the whole thing onto the screen and rely on the zooming and panning. Solving that problem will go hand-in-glove with my expectations of making this whole kit and kaboodle work on mobile devices, with some focus on tablet-size devices.

* Side note about version names. Just as Apple is running out of room with its feline monikers, what will Ubuntu do for the version after Zesty Zebra?

Please consider submitting a proposal to use the iPads in your course this fall! For more information, please see: iPad Course Loans.

Emmanuel Quartey, Architecture ’12, set the tone of the panel when, while clutching his iPad, he said “I shudder to think what I would have accomplished at Yale if I had owned this device my freshman year.”  While some of the students felt more strongly about the importance of mobile technology, all of them agreed that the iPads and smartphones they were issued through the internship had dramatic effects on their studies.

So what is Wires Crossed? Originally “my mobile year,” this internship program initially sought to peer into the life of mobile technology use by students, but quickly morphed into a report on the pulse of technology on campus. Behind the scenes, 5 students, Austin Berhadt, ’12; Salvador Fernandez, ’13; Henry Furman, ’14; Emmanuel Quartey, ’12; and Sara Stalla, ’13, were issued iPads and smartphones and asked to report back regularly on when they were using the devices and how. This report came in the form of a Tumblr based blog and a Twitter feed, both of which picked up more interest from undergraduates than had been expected.

At the onset, the project was new and students were unsure of how to present their findings and whether to keep the name “my mobile year.” Though they settled on a blog, choosing a hosting platform was a challenge – different platforms offered different advantages, and a forum on mobile and academic technology had to have excellent ease of use and a high degree of mobile-readiness. Ultimately, a few key features helped the students settle on Tumblr. First, the freshman class was full of Tumblr users, making it easier to connect to students. Second, the platform has an excellent and easy to use mobile interface. Most importantly, Tumblr’s format allows an entire community to be created around an idea – perfectly suited to a project studying academic technology. By tagging all posts “educational technology” readership grew quickly.

With the blog going up, students thought about the nature of the project and quickly realized that it was much more than a documentary of their use of mobile technology. They reasoned that the name should reflect this expanded mission. Thinking not only about the vast scale of academic technology, the challenges they ran into in choosing how to even begin a blog project, and their initial frustration after being immersed in this world, but also the intersections between technology, education and student life that they saw emerging around them, the name “wires crossed” seemed appropriate.

After settling on a name for the project, and a platform for presenting the work, the five students set out on their mission.  At first, the students spent a lot of time thinking about their new learning tools, with the iPad getting the most attention. Early posts included discussions of apps that emerged as particularly useful in the classroom. GoodReader, with its folder structure and excellent annotation features for PDFs and other documents, won approval from all students, with Emmanuel pointing out that reading and annotating became so easy with GoodReader that he actually found himself doing more readings than he had without it. Students also used the iPads to take notes in class, with Henry promoting the features of notability while other students suggested using the iOS version of pages.  Dropbox also earned an honorable mention for the ease it brings to file management without a laptop, and Rebtel made the list as a social app that helps students make free VOIP phone calls to long distance or overseas friends.

Austin points out that the iPad is more than just an academic tool. In his daily use he feels that outstanding twitter and foursquare integration make it primarily a social device, a “practical toy” that can make academics much easier by allowing him to unobtrusively browse current syllabi during shopping period before checking what’s on the dining hall menu. Although he is open to tighter classroom integration, he notes that the lack of uniform pagination poses a serious problem in English classes, and that many free books use uncorrected OCR, resulting in typographical errors, missing words, and broken lines – issues for verse particularly, but literature generally.

While the iPads were a central part of the internships, the whole panel agreed that students recognize the breadth of academic technology. Student run initiatives have really taken off, and some of the most prominent have been featured in the blog and highlighted on the Wires Crossed twitter feed. The quintessential student project is the Yale Bluebook, which adds a user friendly face and social elements to the process of course selection, currently done through the multi-windowed and clunky Yale Online Course Selection system. Alone, Yale Bluebook could be seen as a few clever students going through an unusual amount of work to fill a need, but understood in the broader climate of technology among undergraduates at Yale the project takes on greater significance. Students feel a need for a new technical literacy, one where knowledge of HTML and CSS is a launching point for further innovation. Students have also taken steps to fill this need. The HackYale program brings expert students together with neophytes to learn topics from HTML to iOS development, all on a voluntary basis with no credit awarded. The Yale College Council App Challenge is an initiative that seeks to add compensation for good ideas – and has gotten results with social applications like Rommeo and academic projects like Slidee earning cash awards or campus-wide recognition, or both.

Student led initiatives show that there is certainly a desire among undergraduates to become technically literate, and that student projects will serve not only social but also academic functions. The panel seems to highlight that while students are achieving amazing things on their own, they could be doing even more with greater backing from Yale and better tools to find each other, with Harvard’s “Innovation Incubator” highlighted as a possible model. Students need to be given more access to institutional data and more support for their projects in order to produce academic applications that can have major impact on teaching and learning at Yale.

Although staff and faculty led attempts to integrate social elements into classes are laudable, panelists point out that without the inclusion of students, these attempts can frequently go awry. Adding a discussion forum or making comment posting mandatory usually lead to dry and forced interactions, and fail to really involve students. A forum, where faculty members could connect to undergraduate developers who are more in touch with how their peers approach social learning, would be an example of a support structure that could foster rapid and meaningful innovation.

While starting with mobile technology, the Wires Crossed interns have worked together to produce a blog that measures the pulse of technology on Yale’s campus. From creative iPhone apps, to improvements to the course selection system, students have already made significant contributions to academic technology at Yale.  As the panel points out, with greater university support, even more could be achieved.

For full coverage of this session, please click the video below
(note a slight delay upon initial playback):

The initiative started when the CLC set up a pilot program to loan out 20 iPad2s to a seminar that would integrate them most effectively into its structure. The library would loan the devices, and ITS’s Instructional Technology Group would provide technical and teaching support. After a successful spring 2011 project in the digital humanities, Julie Newman’s class won the fall semester challenge, both for its ambitious goal of eliminating paper use in the classroom and for its use of iPad optimized assignments and projects.

Julie described to the audience how her class goals were uniquely suited to the iPad. First she wanted to go paperless, both to lessen the seminar’s carbon footprint and to enhance text with media integration and instant research. She also wanted to go mobile with the class, leaving the seminar room to visit local sites while students could continue to watch the presentation or take notes. These would be accomplished without the social barrier of a laptop screen. Finally, she asserted that she wanted to start a conversation on not only about technology as a teaching tool but also the role of technology in sustainability.

The environmental impact of the iPad was central, Julie pointed out, since it was being used to replace paper in a class on sustainability. After carefully considering the impact of the device she concluded that it did serve a net positive, and in conjunction with her laptop was able to almost completely eliminate paper use in the class, making it the “most paperless she’d ever been.”  This impact, however, is tied to two conditions. The first, she argues, is that it cannot be constantly replaced every time there is a new version of the same technology. The second is that the device must be used to its fullest capacity – replacing paper in contexts outside the classroom and providing additional functionality that would have required other devices.

Inside the classroom, Julie structured her assignments  to take maximum advantage of the unique features of the iPad. Course texts were acquired as Amazon or Google eBooks, articles were posted on Classes*v2, slide shows were given via Google docs. Although Julie admits that she didn’t have a comprehensive plan when she started the semester, by the end she had found a rhythm of iPad use, reaching an even greater level of integration than even she had expected.

The flexibility in assignments and projects allowed by the iPad was especially remarkable. Although adoption of the iPad was complete in daily assignments, with students pulling up homework on screen at the beginning of the class and PDF readings completed on the popular GoodReader app, it was in special projects that the iPad really showcased its educational potential. An example comes from her assignment of an “ideas forum.” This project involved students identifying a local sustainability challenge and working to develop, propose, and discuss solutions. Despite leaving the submission format open, Julie expected most students to use the iPads to assemble and deliver keynote presentations, which some students did. Others, however, used the iPad’s integrated media tools and software to construct multimedia shows or short films. In this context the combination of iMovie and a camera on a single device  made the iPad an ideal tool for the on-site assembly of a compelling multimedia presentation. Other students used the mind mapping software iDesk, only available on iOS, to diagram their understanding of the problem in a format that is both faster and easier to understand than traditional blocks of text.

With the success of coursework and special projects on the iPad, Julie explains that she will certainly integrate the device into new attempts to reduce paper consumption and to integrate technology more closely with teaching, although if she cannot secure iPads again then she will try to replicate the functions using laptop computers. The iPad does convey a number of distinct advantages over a laptop, however. First, limited multitasking keeps students focused in class, while still having access to internet and processing tools. The extra mobility and integrated cameras allow students to take the device with them to field sites, bringing practice and learning together in a way that is difficult even with portable computers. Finally, Julie felt that after learning about iDesk she had underutilized it in the classroom, something she will remedy in a future class if the devices appear again.

Besides using iDesk more heavily, Julie points out that there are a number of things she would do differently in the future. First, she feels that more training is necessary, and that professors should start using the device at least a semester in advance of teaching with it. She also feels that more training for both students and faculty would be useful, particularly on applications like keynote, iMovie, GoodReader, and Evernote. Finally, a more efficient content transfer system and possibly keyboards for in-class note-taking should be considered in future iPad based classes.

Besides the user challenges associated with teaching with iPads, IT Staff overcame significant challenges to deploy iPads on short notice. It was only two weeks before the devices were to be given out that staff was able to begin the process of deciding how to configure and distribute the devices. Particularly challenging was the process of deciding what applications to pre-load, and how to keep track of all 18 devices and accessories to make sure that nothing could be lost. Despite these challenges, however, the iPads rolled out successfully, and integrated with course materials to a degree nobody had anticipated. While future classes may not encounter some of the initial obstacles associated with a pilot program, it is certain that they will all benefit from the educational potential of the iPad in the classroom.

For full coverage of this session, please click the video below (note a slight delay upon initial playback):