Continue reading »]]>

Context: What if we stopped using the terms “diversity” and “accessibility” and started using the term “inclusion” instead? Or what if we started using “inclusion” in addition to the other terms? One reason would be strategic, creating alliance among groups that might otherwise remain disparate. Another reason would be to move our conversations from discussions of abstract qualities (Is your field diverse? Are your resources accessible?) to discussions of concrete actions (What are you doing to include people? And what are you doing to exclude people?)

Environment Scan: I’m not the only one thinking about the importance of inclusion:

• In January of this year, THATCamp SoCal featured a session titled “Towards an Open Digital Humanities” (Some notes from that session are online as a Google Doc)
• The theme for the 2011 Digital Humanities conference is “Big Tent Digital Humanities“
• And for THATCamp CHNM 2011 this weekend, a number of Campers are interested in addressing topics that I would argue are about the issue of inclusion:
  • James Neal would like us to have “an honest and open discussion regarding diversity in the digital humanities“
  • Chad Black is concerned with “ethics, power, advocacy, technique“
  • Cory Bohon suggests a talk about and a workshop addressing accessibility for people with disabilities
  • Sheila Brennan asks us to consider how documentation–or the lack thereof–affects the core audiences for our projects
  • Christina Jenkins turns our attention to the primary and secondary school environment
  • Undergraduate research and the digital humanities is the concern of both Tonya Howe and Sarah Werner
  • There are probably more session proposals that I’ve overlooked. (Please feel free to suggest more connections in the comments below.)

Clearly, it seems to me, there’s something in the water. . .

Proposal: I propose that we approach these issues in two ways.

• First, let’s yack about what the barriers to inclusion are so that we understand more fully what’s at issue. Several of the sessions already proposed are exactly the kind of yacking I’m thinking about.
• Second, let’s hack away at those barriers. And I use the term “hack” to mean “a good workaround” or “a good-enough solution.” Sometimes a “hack” will involve the use of technology, but sometimes it will not. A given hack could be put together during THATCampCHNM 2011 or it could be planned as an ongoing task/project with a life beyond this unconference.

[Creative Commons-licensed flickr photo by Ewan Munro]

Continue reading »]]>

I would like to propose a roundtable web accessibility discussion and workshop that would help accelerate the adoption of accessible design strategies in the Digital Humanities.

Over the past two years at the University of South Carolina Upstate, George Williams and I have been working in conjunction with Tina Herzberg on BrailleSC.org. Through our research, we’ve developed two Omeka plugins and one WordPress plugin that allows an administrator to quickly and easily add accessibility features to their sites powered by these content management systems.

Just over a month ago, this project led to the creation of AccessibleFutures.org — a site designed to be a one-stop shop for sharing tools, plugins, documentation, and other resources for developers and website administrators looking to make their websites more accessible. This website will host open source code and tools for making the web, and computing in general, more accessible to everyone.

What I’m proposing is a brief talk about accessibility in general, followed by an overview of the plugins that we’ve created. Finally, I would like to propose a 30-minute rapid coding session where developers with Omeka or WordPress, PHP, HTML, and CSS skills could work together to tweak our existing plugins or build new accessibility plugins that will be released on AccessibleFutures.org. Authorship credit would be given to developers on our site as well. Unfinished plugins can also be submitted to AccessibleFutures.org for completion later by another plugin author, or the original author can complete it at a later time and submit it to us.

Continue reading »]]>

How does the availability, writing style, and level of completeness of documentation influence our willingness to use a digital tool or to engage in a project? More important, how does it effect the core audiences for our projects?

I use the term “documentation” to refer to any set of instructional writing or media (printed and/or online instructions, user guides, podcasts, screencasts, slideshows/screenshots, et al) produced to support the use of a digital tool, process, or project.

Documentation is challenging, because it is time consuming and requires the creators of a project to share processes and details that often have become naturalized. When working closely with a project, writing clear instructions for users with different intentions, levels of technical knowledge, and commitments to digging through pages to find answers is hard. Even though it is hard, and sometimes we don’t enjoy doing it, providing good documentation is akin to creating an accessible website.

Documentation, similar to code, is a specific type of writing that often is not recognized as scholarly or substantive work. How can we elevate this type of writing to something that can be quantified or “count” for project participants who work in different professional positions?

I would like to spend some time discussing what makes good documentation and exploring the following questions:

• How much time do you spend using any type of documentation?
• How much time have you spent writing or contributing to any documentation/codex?
• If you write it, will they read it?
• Have you ever asked for user feedback about a project’s codex or user guides?
• Have you ever stopped using a tool or a project because there was not sufficient documentation to assist you?
• How does the authorial voice adopted by documentation writers influence how someone uses it? Does this matter?
• Should documentation contain multiple voices, or at least provide the opportunity for many users participate in its creation?
• Are there common elements you find lacking in most codexes?

Perhaps throughout this session, we can collaborate on a document listing suggestions/recommendations for DH project documentation.

______

Thanks everyone for a great session: docs.google.com/document/d/1jjJL75EboctzXbH0wd5sD899xRdT5TDGhx_E9U2wyj4/edit?hl=en_US

Continue reading »]]>

Teacher-scholars unite! I’ve been testing some possible applications of Omeka archives and Zotero as collaborative tools organizing the development of literary research methodologies classes, and I’d like to take the wonderful opportunity of THATcamp to begin developing the structure and content of project I see as The Next Step. I’d like your help to discuss, plan, and/or block out a template for a full-class, full-term student project that works toward researching, annotating, and encoding a small number (perhaps just one per term?) of thematically-selected texts in our shamefully neglected special collections room. Ideally, this project would therefore include study of the texts themselves, research about their material and digital existences (using the ESTC, Google Books, and something like Eighteenth-Century Book Tracker)  a basic practical/theoretical framework for DH, collaboratively writing a useful and accessible overview and producing an XML version of the text. Each term or year, students and faculty would work together to select, create, and grow the entries according to a broader thematic logic that can expand over time, based on the strengths of the collections. I’d like to use this template as a basis for a grant application that would allow the project to grow and, ultimately, link faculty, students, and resources at area institutions.

I think this would be a viable model for an advanced undergraduate seminar, and it has the benefit of drawing together a variety of practical and theoretical facets of the digital humanities. Some questions to consider include how we can best design the arc of the class? What specific parts of the project would have as their goal which practical or conceptual outcomes? What are the technological hurdles to be 1.) aware of, 2.) avoided, or 3.) embraced? What should the Omeka site look like/allow, in order to help the project grow over time? How might faculty help students approach the text encoding portion of the project? What are the most useful introductory text-based sources providing a theoretical framework for such a practical project? And what might steps after The Next Step look like?

Continue reading »]]>

I read with interest James Neal’s post entitled “An honest and open discussion regarding diversity in the digital humanities?” I believe that discussion would be a welcome addition to the unconference schedule. Along these lines, I’d like to help organize a session about disability and accessibility, either as part of James’ session or in addition to it. Having talked about this topic with many people in the DH community over the last couple of years, I’m confident that we can start making some easy-to-use tools that will improve accessibility for endusers and simplify for creators the task(s) of making accessible resources.

Furthermore, my collaborators and I are currently gathering information about issues of disability, accessibility, and digital humanities resources. As part of that effort, we invite you to complete this survey. (It should take less than 5 minutes.) We will use the information we gather to inform our future project plans, and I can also share the results at the upcoming THATCamp. As a survey participant you may remain anonymous, or you may share your name, affiliation, and contact information at the bottom of the form.