Category Archives: Incubator

Spring 2019 Incubator

In the spring of 2019, the Boston College Libraries’ Digital Scholarship Group will host a Digital Scholarship Incubator, a seven-week series that aims to introduce major tools, methodologies, and questions in digital scholarship, while also empowering participants to develop a digital scholarship or pedagogy project. We’ll focus on participants’ needs and desired areas of growth in digital scholarship.

What is an incubator? An opportunity to develop a digital research or pedagogy project within a cohort of digital scholarship practitioners. Each week we will focus on a different topic. The curriculum includes sessions on user-centered design, digital exhibits, geospatial visualizations, and textual analysis.
- You’ll refine project ideas through planning & peer review.
- You’ll provide the idea(s), and we’ll provide resources to help develop your idea in a safe space.

What’s the time frame? We’ll begin meeting the week of January 28 and wrap up in April.

What are the expectations for participants? We ask that participants commit to seven two-hour meetings, plus some additional work outside of the meeting sessions.

We invite applicants who are interested in joining a cohort of digital scholarship practitioners. No prior experience or knowledge is necessary. Applications are due December 3, 2018.

Loading…

Final Digital Scholarship Incubator Reflections: Rachel Ernst

This post is part of a series of final reflections from 2017 Digital Scholarship Incubator participants.

Rachel Ernst: Designing a digital humanities project is a much more collaborative undertaking than I was aware of when I first applied to join this digital incubator. While my more traditional humanities scholarship is created with the help of advisors and committees, much of the work is solitary. I am engaging with the work of other scholars and thinkers, but this engagement is done through the pages of their writing, rather than face to face. While working on my digital humanities project I realized the need this project had for more involvement with other people: the incubator, digital librarians, my eventual audience, other faculty and graduate students, and, someday, archivists, curators, and special collections librarians. Working digitally, especially for me as a material culturist who is increasingly spending time with the concrete and the material, also has more flexibility or fluidity than working with more traditional materials: gloves are not necessary, the pieces of the project are always just a click of a mouse away, and there is no need for a specialized, climate-controlled environment. But even as these characteristics make working on the project simpler in some ways, I do still feel frustrated by the inability to physically manipulate the data I am working with in tangible ways.

Working on this project has helped me to see how the database I am building may be of use to other nineteenth-century scholars; this idea of “use value” has been a helpful rubric for making decisions about content and where to focus my attention to best serve the needs of the community of Victorian scholars. At the same time, the lack of the type of work that I am proposing in this project has made the need for it that much more imperative. My interest in the objects of the nineteenth century, specifically women’s clothing, provides a unique lens through which to examine literature while forging relationships with museums and archives.

I think digital humanities projects need to be critiqued or evaluated at several different levels: the personal, the communal, and the professional. One of the questions we considered during the incubator was what could be considered a successful project? I think the first parameter for success is whether the project ultimately did what the author wanted. Whether or not the project succeeds with the public or with a professional community is also important but, fundamentally, the first critique should be at the level of the personal goal for the project. The next two levels of evaluation should examine how the project works within the community it was designed to reach. Is it accessible? Is it effective? Does it further work in its particular field? I think the last piece is what I am calling, for lack of a better term, the “professional” level; by this I mean not the field in which the project engages but the field of digital studies. Is this project a successful use of digital tools? Could it be structured differently or more effectively through other digital means? How does it expand the field of digital humanities? While it may be difficult to build a systematic approach to critique or evaluation of digital projects given the diversity of the work being done and the range of platforms being used, I believe having certain standards or areas of questions may be a useful way to critique digital humanities projects.

Final Digital Scholarship Incubator Reflections: Lauren Wilwerding

This post is part of a series of final reflections from 2017 Digital Scholarship Incubator participants.

Lauren Wilwerding: When I completed my application for the Digital Scholarship Incubator, I had a seemingly simple goal – to create a digital close reading assignment for students in my literature core. The pay-off would be designing an assignment that could be improved upon and repeated, in my own classes as well as by other teachers. I hoped the methodology would be a way for me to bridge the intimate, tactile experience of close reading so central to English literature and the linked and richly networked world of the digital humanities.

Since beginning I have learned that a platform already exists to do the sort of digital close reading I had in mind. More importantly, I have learned that the existence of this platform (hypothes.is) does not mean that the “designing” work is done for me. While previously I would have thought of designing a DH project as a technical venture, I have come to see it more holistically. In my case, in order to develop an assignment that achieves all of my classroom goals, the platform is merely a tool in for which I need to design a series of activities to make the most of it.

Prior to starting the Incubator, my understanding of digital humanities was very focused on the digital aspect – coding, programming, technical skills. Now, I have come to focus more on the humanities aspect. How can we use digital platforms and tools to serve humanities inquiries? I have been pleasantly surprised that the questions we have asked in the Incubator are familiar to me as a humanist. The Incubator has done the work of bridging my own experiences with the world of DH.

During the course of the Incubator, I have come to be more focused on my future students, as both collaborators and evaluators. By completing the assignment, my students will provide content for the project and also help me discover the ways that it can be improved. In other words, the “designing” of my DH project will be on-going each time I use it to teach. By responding to the assignment, my students will also become my audience. Is it truly interactive? Which prompts generate discussion and which don’t? How does the digital platform enhance the classroom experience?

What initially seemed like a very contained project, now seems iterative. I look forward to incorporating student feedback into successive versions.

Final Digital Scholarship Incubator Reflections: Anna Assogba

This post is part of a series of final reflections from 2017 Digital Scholarship Incubator participants.

Anna Assogba: To me, a digital humanities project might be very similar to a non-digital humanities project, but the essential difference is the fact of being digital enhancing the project in some way, perhaps enabling a form of analysis, or presenting a mode of reading a text, or connecting various elements of a project that was not possible solely through print or analog form. I have found the process of designing a digital humanities project to be somewhat similar to the process of a librarian conducting a reference interview. Reference interviews are basically a short conversation, a dialogue of refinement, that the librarian uses to get at the heart of a person’s request for research help. Reference interviews help to strip away vague ideas and focus in on what exactly is needed. I see the design process acting in the same way, forcing the creators to define the project in manageable, realistic terms. I think I’m pretty good at conducting reference interviews, but I still had a difficult time designing my project and needed to pare down my project over and over. My mind often preferred to linger over tantalizing, amorphous possibilities rather than focus on concrete realities.

There was a kind of push and pull for me in designing this project – the push to refine my project through writing the proposal, and the pull to create and try things out without a clear idea of where I was going. I think there can be a danger in not thinking through the project enough so that the work you do is not really productive – you end up wasting your time. However, the other side of things is thinking too much without taking any steps towards exploring platforms, tools, processes, etc. In that case, if you do not test anything or make any prototypes, you may end up with a plan that is not realistic once you try to implement it.

I have pared down my original project idea of combining literary and historical primary documents of land enclosure together in one collection into an anthology of just the literary documents instead. There are a couple of reasons for this; the historical documents are more difficult to obtain, and I am more interested in the literary documents. What was of interest to me in creating a digital anthology of land enclosure literature was to have these works (mostly poems) in one place, to be able to read them in relationship to each other. However, I think the reader would probably gain most from the experience (and be better prepared to analyze the works) by also being able to know a bit about the author of each of the works as well – where they lived, what land around them was enclosed, at what stage in their life they encountered enclosure, etc. I plan to add these parts in, plus a short introduction to the anthology giving the reader a short introduction to enclosure.

English land enclosure is a highly studied topic, but it has mostly been studied from an economic and historic viewpoint. I am interested in studying the more literary historic side of enclosure. I am hoping that the creation of a digital anthology of land enclosure literature would make scholars more aware of land enclosure as a literary topic to be studied. I think the digital form of the anthology makes it easier to advertise the presence of the anthology and should make it more accessible to people (it would be freely available online rather than something that needs to be bought or ordered). I see a kind of poetic justice in this resource being made available publically and freely for people to use, since the literature produced around enclosure often laments the changes that occurred in how people were able to use the land after enclosure were more restrictive.

Final Digital Scholarship Incubator Reflections: Laurie Shepard

This post is part of a series of final reflections from 2017 Digital Scholarship Incubator participants.

Laurie Shepard: The three prompts all point to the same problem of designing a site that takes full potential of the digital platform. How do we fully problematize our data? How do we design a site around the data, which is transparent and easy to use, but at the same time a site that will produce more understanding, that will move forward our knowledge of the questions we are asking? I think that success in this last point is the way I would judge a site.

Starting with traditional data, in my case literary texts, how do I refocus on them in the ways that the digital platform offers? My questions concern the communities of production of comedies in the first half of the sixteenth century in seven Italian cities. Keeping the texts at the center of the project, how do I effectively integrate them with the different producers, consumers, and propagators i.e. printers, the places where they were produced and consumed, the circumstances of performances?

I have learned in this seminar that when it comes to digital sites, less complexity is usually better than more. My organization principals are time and place – I suppose that the vertical axis will list the 7 cities where comedy played a role in the cultural politics, the horizontal bar will provide a timeline. Various kinds of information can be attached to the timeline, texts to both axes. The site will include a personography, and potentially some graphs showing the intersection of persons in cities, and the role of printers, especially in Venice and Florence, in the propagation of comedies. It will include images of persons as well as some performance spaces. The only additional extensive written texts that I foresee, at least at this point, are letters pertaining to the early productions of the comedies. Most of this material is prepared or in some phase of preparation.

I do not imagine that this site will produce new knowledge. I hope that the comedies will cease to be perceived in isolation and instead be read as integral to a confluence/conflict of different artistic and political interests, technical capabilities, trends and tastes. Ideally the comedies will be understood not only as highly choreographed set pieces, but also as reflections of a rapidly evolving society. Removing the comedies from the isolation of bound books should enrich our reading of them. Key players who were not writers, and have for the most part been forgotten can be recuperated and reintegrated into the production of the comedies.

Final Digital Scholarship Incubator Reflections: Abbie Levesque

This post is part of a series of final reflections from 2017 Digital Scholarship Incubator participants.

Abbie Levesque: As a qualitative researcher in rhetoric and composition, I have a distinct experience with the project building experience in digital humanities work. Ridolfo and Hart-Davidson have begun inquiring into the intersections of the field, both of which are interested in tool use, but have different investments therein. Computers and writing in the field of rhetoric is invested in use of tools for qualitative data analysis as well as the practices used when composing digitally. DH, I find, is invested in theories around data (a la Drucker’s work) and in project building as opposed to research projects. The building of a DH project has always been distinct for me from the building of my qualitative research projects. First and foremost, my DH work often but not always demanded situating myself in two fields – my “main field” as well as DH, as far as making critical interventions. Qualitative work, while still interdisciplinary, never required situating myself outside of Rhet/Comp, though I often did due to my own interests. For qualitative work, I had a different research environment, as well. I worked mostly on my own, with a mentor overseeing my work, presenting a fully formed thesis only at the end. With DH there is a “lab” type culture – there was no mentor, per se, but a series of work-in-progress talks were given, and feedback received outside of the advisor relationship, and from outside the project. Neither way was better or worse, since they both had their frustrations and chances for serendipity. I would say the process models of project building are distinct in DH from most other disciplines in the humanities.

Though I have had different experiences in my two research fields, I also want to point out where things were similar or where they meshed. XML encoding is a hop and a skip away from traditional qualitative coding – both fields could gain a lot from seeing the other’s practices of codebook and schema building, as well as their documentation practices. I think both fields also are beginning more and more to value inquiry into the tools and methods being used – that is, the methods are being rigorously examined to see if they are effectively working within the methodological framework of a project.

All this to say that I think one of the most valuable things about developing a digital project is learning a new process for building and situating research. DH has given me the tools to situate myself in a plurality of fields, and gave me a more open set of opportunities for doing research, which allowed my project room to grow in more interesting and innovative ways than it would have otherwise.

Final Digital Scholarship Incubator Reflections: L. Kelly Fitzpatrick

This post is part of a series of final reflections from 2017 Digital Scholarship Incubator participants.

L. Kelly Fitzpatrick: In digital scholarship, we use technology to support our work – from the creation and process to the systems that share and disseminate it. My proposed project for this incubator focused on how we can adapt Twine, an open source game engine, as a tool to support institutional repositories.

As an method to approach this question, two tangible end goals were identified at the start of the incubator. First, a working model of an author-side deposit workflow built in Twine based on an existing institutional deposit workflow to examine Twine’s viability as a tool. And second, supporting documentation for the project as a touchstone for future work.

Timeline
The timeline for completing this was broken into four milestones. The first was dedicated to the drafting process early in the incubator; supported by tools including Google Drawing, paper, and jelly roll pens.

The second milestone would include building the model in Twine, and the third would include adding any custom HTML and CSS as needed. While initially planned as separate processes, these two steps ran concurrently. Outside of Twine as the project’s foundation, the second and third milestones included SublimeText and Google Fonts as tools to support this process.

The last of four milestones of the project aimed to manage project documentation, and make elements of that documentation publicly available for future work. While the last stretch of the project timeline did include time dedicated to outlining the information needed to reproduce this project, creating and managing documentation was present through the larger process of building this project. While all materials generated across the project timeline were not made publicly available, documentation including written guidelines, HTML, CSS and images were shared in a project GitHub repository.

In reflecting on project timelines, each step did not happen in isolated spaces, and self-imposed deadlines functioned more as a guide than law. In application, this process was most functional as method to stay mindful of time restraints and map tangible project milestones to gauge progress.

Challenges
In reflecting on challenges encountered on this project, the first was defining scope for tasks across the project timeline. This manifested in identifying what the outcomes of the incubator would be, and what work could be addressed more fully at a later date. This obstacle pinpointed documentation as a key outcome so that the process and technical details behind the project could be used as a reference point in future work. This challenge would be revisited in the last stage of the project in defining the depth of documentation to both create and share.

The second obstacle was how to best translate the purpose of the project into a final product. For this project, I wanted to base the model on an active repository deposit workflow versus a theoretical workflow for two reasons – to explore Twine’s functionality against real world institutional practices – and on a practical level, because outside author deposit workflows are hidden behind university login. That said, a working prototype created to better parse Twine’s general viability as a tool isn’t best served with institutionally specific proper nouns or branding. To make this change, I made the decision to omit institutionally identifiable information so that the model could be more easily distributed and adapted for use by outside institutions. While this stage of the project presented a fork in the road around what the final product would look like, I believe that this option will best serve the original goal of the project and support future work in this area.

Outcomes
In wrapping up this incubator, I have a strong foundation to examine Twine as a tool to support author-side institutional repository deposit workflows at the next stage. In pulling together a working model of the concept and supporting documentation, the incubator created a dedicated space to facilitate this work. While the last session of the incubator will close the lid on this stage of the project, I plan to revisit this project to more fully explore how Twine can be adapted as a tool to make research sharing easier for authors and institutions.

Final Digital Scholarship Incubator Reflections: Katherine Kim

This post is part of a series of final reflections from 2017 Digital Scholarship Incubator participants.

Katherine Kim: To be honest, this incubator has given me quite a few things to think about regarding digital humanities projects (especially related to their creation and use). Just like other types of projects, there are so many more things to think about and decisions to be made “behind the scenes” than may be anticipated. Perhaps because of integration in higher education practices, people like me are very used to the “state, cite, interpret, incorporate” type of work that happens in most academic essays/projects. However, many digital humanities projects can provide a lot more flexibility than traditional academic essays because of the multiple ways in which the audience can approach as well as interpret presented information. For example, reading an essay is more of a linear process for which there is one specific way to progress through the information provided. However, for many digital humanities projects, people can determine the order in which they explore different parts of pages and pages themselves. Thus, many projects require a more detailed, multi-dimensional approach to thinking about the organization and presentation of material. The “front end” of things definitely seems heavily loaded for digital humanities projects even if they include community participation aspects.

Through this incubator, I have found that such a factor actually can have more of an influence of audience understanding and reaction than I previously thought, and so there is more to consider when creating a digital humanities project. Consequently, one thing that I am really thinking about now is the speed at which creating even a relatively simple project like mine could actually be. From what I have learned this semester, I feel that my project will take an incredible amount of time if I try to do it all myself, and so I might have to “cut corners” a bit by having someone who is knowledgeable about websites help me actually create the site that I hope to have. It is somewhat disheartening but also necessary to think about such issues!

Digital Scholarship Open House

You’re invited to the Digital Scholarship Group’s annual Open House, Thursday, November 16, from 3:00 to 5:00 pm, in O’Neill Library’s Digital Studio (room 205). Please join us for food and refreshments, updates on digital initiatives at Boston College, and short talks from participants in the Digital Scholarship Incubator we’ve been conducting this fall, who will discuss the projects they’re developing and their experiences in our program. We hope to see you there! Have a look at more details and please RSVP by November 10.

Digital Scholarship Incubator Reflections: L. Kelly Fitzpatrick

This post is part of a series of reflections from 2017 Digital Scholarship Incubator participants.

L. Kelly Fitzpatrick: A Starting Point in Twine for Institutional Repositories

Graphic of a document icon over a digitized game board.

A graphic for the project using a digitized game board from the Met’s collections.

Research sharing is supported by actions moved forward by authors, institutions, and scholarly infrastructures. In the context of university libraries, these actions are centered around the institutional repository – a central location where authors affiliated with the university can share their scholarship – created with the goal of sharing, preserving, and supporting research produced by the university. For this incubator I’m going to look at how an open source game engine may be adapted to support the institutional repository deposit process.

In looking at the author facing tasks that surround the institutional repository deposit process, there’s the actual point of deposit, but there are also secondary actions that may accompany it. Examples of these tasks may include registering for an ORCID identifier, or outlining how authors may find metrics for the work they’ve shared. How can we take these author-facing tasks into a process built on existing library infrastructure? Furthermore, how can we create a solution that is, in itself, open, and can be adopted across institutional settings? Through the duration of this incubator, I’m going to explore Twine as tool to unify institutional repository deposit workflows for authors.

Twine is an open source game engine, publishing works in HTML format on both in-browser and desktop platforms. In the games space, Twine has been used to create popular works of interactive fiction and digital storytelling which use the modular structure of Twine to guide their players through paths of playable content. Adapting Twine for use outside of gaming isn’t a new idea, with notable uses including the Smith College Twine Tour, “a historical mobile tour of the Smith College campus, featuring photos and other primary sources from Smith College Archives.” While options for adapting Twine as a tool for digital scholarship are as flexible as a platform itself, we can begin to extend these possibilities to the infrastructures that support that scholarship.

At this stage I’m working on defining what a tangible end product of incubator should look like for this project. This is largely a scope question of what can realistically be addressed within the set duration of the incubator, and what can be reserved for a later point. In recognizing obstacles of scope present in all projects, setting occasions to reflect on what those goals are, and where a project is going will help prevent moving targets in the future.

In looking at Twine as a tool to support institutional repository deposits, the current goal of the project is to build an author-facing deposit path using Twine, and document each stage of the process. Following the incubator, the tentative next stage will be compiling this information as an detailed outline for institutional adoption.