This is part of a series on accessibility and usability. See the contents page for more.

Now that we have talked about Code and Navigation and Design, I’ll talk briefly about a few tools you can use to help you do a mini accessibility study on your website, and briefly point to some resources on doing more complete usability studies.

Web Developer Toolbar

The Web Developer Toolbar add on for Firefox is what I use most often to do a down and dirty accessibility check of webpages. You can download the Web Developer Toolbar from its page at Firefox.

You can use the web developer toolbar in many ways (in fact, I still find more uses for it!) but for the purposes of this discussion I’ll just go over a few simple tests.

You can use the web developer toolbar to disable images, CSS and Javascript on your pages. Doing this will give you a pretty good idea of how accessible your page is – if you can do this and still navigate around and get to content, you are in pretty good shape.

Sometimes the toolbar shows some pretty dramatic problems. Take the following site:

Buy Fresh, Buy Local

The site looks pretty – but when you turn off javascript by choosing Disable > Disable Javascript > All Javascript using the web developer toolbar, you get the following page instead:

Buy Fresh, Buy Local with javascript turned off

Problems are not always that dramatic.

Turning off all javascript (Disable > Disable Javascript > All Javascript) Styles (CSS > Disable Styles > All Styles) and Images (Images > Disable Images > All Images) On aadl.org points to the fact that there is no H1 tag. Inspecting the code with the code inspector turned on (Information > Display Element Information) confirms this.

aadl.org is lacking an H1 tag.

Finally, the Web Developer Toolbar contains a built in validator for your CSS and HTML (actually, it uses the validator at http://w3.org, but offers and easier way to get to it.) You can access the validation tools by navigating to the page you want to check (must be on the web) and choosing Tools > Validate CSS or Tools > Validate HTML.

Firefox Accessibility Extension

One of the more impressive, free tools out there to check your website’s accessibility is called the Firefox Accessibility Extension. With this tool, you can get access to reports on accessibility that will point out missing alt tags, etc. There are 2 high visibility stylesheets that let you see what your site might look like to a low vision user. These can be found under Style > High Contrast View 1 & 2.

There are many more features found in this extension than I can go into here, but you can read the documentation for more.

Greasemonkey, Stylish, and various scripts

Greasemonkey is a Firefox add on that lets you change how a website behaves. Stylish is another firefox add on lets you apply your own stylesheets to websites. Many people with low vision or other special needs use these and other add-ons to alter the look of webpages. It is worth installing these and a few scripts to see how your site looks when altered.

For example, the Readability Interface is a set – a script for greasemonkey, and a style for Stylish – that lets you change the font, font size, background color, and other things about a website so you can see it better.  Likewise, the Night Shift style for Stylish applies a dark gray color scheme to a web page, making it easier to read in the dark.

Usability Tests

Usability tests can range from the simple to the complex (think eye tracking software) but are useful if you can get a group together, no matter how small. In a library setting, you could ask for a few volunteers to come look at your website in various stages of the design. Ask them to complete some tasks, and then observe how easy or hard it is. Encourage them to vocalize their thoughts. Don’t interrupt them or try to direct them, just observe. Afterward, compile what seemed to trip the users up, and fix them for the next iteration. If this seems very simple, that’s because it is. Although usability testing can be very complex and expensive, it can also be cheap and easy.

In addition, there are online tools you can use for usability testing. This article lists many of them. (Thanks to commenter Bret Clement)

Keep in mind that while a usability test may be fairly easy, the problems it turns up are not often easy to fix. Also, keep in mind that what is easy for one person might be hard for another, so don’t be too quick to change something based on one user. A usability test should always be combined with an understanding of usability principles.

This quick overview is no way attempts to dismiss usability testing or make it sound overly simple. One could devote an entire book to it (in fact, there are many). However, watching a user actually interact with your website can be an enlightening experience, even if you don’t have the money for a full fledged usability study.

If you’d like to read more on usability, you can start with usability.gov, which is an excellent resource. You might also want to check out the wikipedia article on usability or Usability Testing Demystified, an article by Dana Chisnell.

Conclusion

It is rare to find a website that follows all the rules for accessibility and usability. If you find your website breaks many of the rules set out here, don’t worry. In fact when I started to run tests on my own site, I’m sorry to say I failed many of the tests.  Usability, especially, is more an art than a science, and incremental changes over time can make a big difference to a website. Just be aware, keep at it, and code carefully!

This is part of a series on accessibility and usability. See the contents page for more.

Design and navigation are important aspects of your site’s accessibility. Clear, concise navigation helps users that must use their keyboard to get around, and a clear, clean design helps users find your content with a minimum of fuss. A good design should also allow the user to change it – for instance, make the font bigger or smaller, or change the colors so they can see it easier.

Navigation

Use words your users will understand. Exactly what words your users will understand is still somewhat of a contested issue, but there are several articles to help. John Kupersmith has put together an excellent site citing 51 usability studies called Library Terms That Users Understand. Among his findings are that users do not understand things like library acronyms, brand names and jargon, and that many terms that are straightforward to a librarian, such as “databases” and “library catalog” may not mean the same to users. In general, try to use natural language phrases such as “find books,” “find articles” and “ask a librarian.”

Label outside links clearly, and never link to an outside site (i.e. one that has a different look or feel or different navigation) from what looks like a navigation area. This area is generally the top bar of the site, and sometimes a side bar as well.

Plan out your navigation carefully, and try not to have too many sections and subsections. There is no perfect number of navigation items, but the more there are, the more likely your user will end up lost and confused. Users won’t want to look over a list of 10 items to find what they are looking for. Plan out the top level and sub navigation so that users are presented with a few choices each time. Try to consolidate pages wherever possible. Write and rewrite your copy so it is clear and concise, and gives users an immediate idea of what to expect on each page.

Build a robust search, as many people will give up on navigation quickly and will jump straight to search to find what they need. If you use a search like Google’s custom site search, the hard work you did in coding will work for you – your titles and headers will lead the user to what they are looking for.

Let the user know where they are by indicating it graphically. You can show a user where they have been by incorporating breadcrumbs into your site, but at the very least the user should know where they are at a glance. This might be accomplished by changing the color of the navigation for the page the user is on, and including a title that lets the user know exactly what they can find on that page. See Derek Powazek’s article “Where am I?” for more.

Carnegie Library of Pittsburgh hightlights the navigation showing the section you are in, and has a "you are here" bar so users can orient themselves.

http://www.carnegielibrary.org/research/art/

Also note that the URL gives users and indications where they are- the main body of the URL is followed by “research” and “art,” which correspond to the section and subsection the user is in.

Use a list to mark up your navigation. After you have marked up your navigation, you can use CSS to make it look like whatever you want. Consider the following example:

On the left is navigation as a list. On the right, the navigation is shown not in a list.

The navigation on the right is hard to understand- but the list on the left gives it structure that will come in handy when a screen reader is trying to navigate your site.

Offer users the option to skip the navigation if at the top, or skip to the navigation if it is at the bottom. In the figure above, there is a “skip navigation” link that allows users with a screen reader to skip the navigation so they don’t have to listen to it over and over.

Design

Designing a website is hard. Trying to keep accessibility and usability in mind while designing a website is even harder. And trying to work with a designer- well, that can sometimes be really hard (I know, I’m a designer). But whether you are designing on your own or working with a designer, following a few ground rules can help immensely.

Set some rules. Before letting a designer loose on your concepts, set some expectations. For instance, if you want to avoid using text in images (as mentioned in the last part of this series), mention that up front. Likewise, if you want to avoid using images for navigation, mention that too. It is much easier to design with accessibility ans usability in mind than to retrofit a design after the fact.

Take advantage of open source design. If you are designing a site yourself, you don’t have to start from scratch. Whether you are using a content management system, or coding from scratch, you can take advantage of open source design to get started. Find a template, theme, or design that is close to what you want and then tweak it ’till you are happy. Just be sure to credit the maker as appropriate if you do go this route! Each design will include specifications on how to credit the maker. Google for open source design to find designs, or look at the templates available for the CMS you have chosen.

Try to avoid making content look like ads. People have been trained over years to avoid clicking on anything that looks like a banner or sidebar ad or text ad. As you look around the internet, think about where ads are placed, and about their side and shape. Then, avoid using these same conventions for your content. (See item number 10 on this article on usability findings for this and more usability tips.)

Simplify, simplify, and simplify again. This applies to the code, the design, the writing and the pages. Really look at each part of your site and think about whether it is needed, or whether it could be combined with another part. Try to eliminate parts of your pages and add whitespace between items. Simplify your writing to use shorter sentences and fewer words. (Think “being concise” rather than “dumbing down.”)

Realize your user will mess with your design. The beauty of the web is that it is malleable, and if you separate your design from your content, the user will be able to change the content so they can read it easier. This is great! This might be something as simple as making the font bigger on the page, or as dramatic as turning off all styles and viewing the page with white text on a black background.

Lincoln City Library website with readability interface user script and style applied.

UNL Libraries Website with styles turned off and Night reading style applied

This is part of a series on accessibility and usability. See the contents page for more.

The first step to creating accessible and usable websites is to create clean, semantically marked and validated up XHTML.

Well formedness, doctype, and validation

First, code should be well formed, and adhere to the doctype declaration at the top of the page

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

The doctype declaration tells the browser what the code should look like. You can read more about doctypes here.

One of the aspects of good XHTML, is well formedness – which basically means that all the elements are nested correctly.

<html><body></body></html>

This is nested correctly

<html><body></html></body>

This is not nested correctly

You can validate your webpage using an HTML authoring tool, or for free online (more on that later). The fewer validation errors you have, the more accessible and usable your website will be.

Semantic Markup

Semantically marked up content refers to content that uses HTML tags as they were intended to mark up the content.

For instance, the <h1>, <h2>, and <h3> tags refer to first, second, and third heading, respectively. they are meant to be used much as one would arrange an outline.

As an example, take this page:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
  <head>
    <title>Main Library, Anywhere USA-Upcoming Events</title>
  </head>
  <body>
    <h1>Main Library, Anywhere USA</h1>
      <h2>Upcoming Events</h2>
        <h3>October</h3>
          <h4>Week one</h4>
          <h4>Week two</h4>
          <h4>Week three</h4>
          <h4>Week four</h4>
        <h3>November</h3>
          <h4>Week one</h4>
          <h4>Week two</h4>
          <h4>Week three</h4>
          <h4>Week four</h4>
  </body>
</html>

So, for every web page, you should have an <h1> tag, which is usually the title of the website, and use <h2> – <h6> tags as needed to separate the content.

The <title> tag in the header of the HTML is important as well – you should have  a title that is unique to each page. Many websites use put the name of the site first, and then the name of the specific page your are on.

fig 1: Page without style

Other information on the page might include lists, tables and paragraphs. For instance, navigational elements are best presented as a list of items. Sub navigation could be represented as a sub list. Blocks of text should be enclosed in <p> paragraph tags. Tabular data should be presented in tables.

There are several old HTML tags that are no longer used because they have no semantic purpose – these include the <font>, <i>, and <center> tags.  The <span> and <div> tags are semantically neutral, and this is how we add style – colors, fonts, sizes, etc., to our webpages.

One way to check the semantic markup of your webpage is to turn the styles off in your browser – while not foolproof, this gives a good indication of how well marked up your document is. You should see a neat page, white background, black text, which is easy to follow and linear – i.e. there shouldn’t be columns.  (fig 1.)

For more information, see this Guide to Semantic Use of HTML Elements.

Images

You cannot avoid using images in your web page, but you can mark them up so users without sight (or users who have images off) can still know what the images are. Alt tags should be used only for images that have presentational meaning on the page. So, for instance, if you use an image for spacing (which should not be necessary anymore) you would use no alt text. An image may also have a title attribute where you can specify additional information about an image. The title tag will show up when a user mouses over an image. The alt tag will show up if the image cannot display (for instance, screen readers).

The title attribute is also useful for links. When it is not clear from linked text what you are linking to, or you are linking using an image, you should give additional information with a title attribute.

In short, the alt tag should be used for images that affect the meaning of the page, and the title tag should be used for additional information about decorative images.

<a href="help.html" title="Link to help page">
  <img src="help_graphic.jpg" alt="Help Page" title="Your helpful librarian" />
</a>

More information on the alt and title tags.

One final note about images- whenever possible, don’t use an image in place of text on your website. Not only does it make the website harder to change, but it makes it harder for the user to do simple things with your content, like print out a nice copy or access the content with a screen reader. Sometimes, this might mean compromising on a design, but in the end, the accessibility boost is usually worth it. For limited amounts of images with text – say, a specific organizational logo, be sure to use alt text as described above.

CSS (Cascading Style Sheets)

I won’t go much into style sheets (you can take a course or read a book if interested), except to say when you use CSS to specify the font size, to use ems instead of font size. If you do this, the font size will be based off what the user has set – so if they have a large or small font size as their default, your page will reflect that. A good article on sizing text with ems can be found on A List Apart, “How to Size Text in CSS.”

Conclusion

The point of having clean, well formed, semantic XHTML is to present your content so that many different devices can access it. the upside to this is that this approach optimizes your site for accessibility (for instance, screen readers) and usability (for instance, you can easily create a version of your site for a mobile device). This also, incidentally, optimizes your site for search engines to find it, since the same principles that allow screen readers to parse your site also work to allow search engines to index your site. Once the code of your page is clean, it will also be easier to apply your design using CSS.

This series of posts is in preparation for a talk I am giving Thursday at the Nebraska Library Association on Accessibility and Usability.

Accessibility and usability are hot keywords right now, and usability testing is a hot new money making venture. What one doesn’t often hear is that much of what makes a website usable and accessible is pretty simple, and easy enough to implement if you know how.

Definitions

Usability refers to how easy (or hard) it is for users to find and retrieve information on your website. Usability is not new – you also have usability concerns in your physical library. For instance, how easy is it to find what you want? Usability on a website might refer to how easy it is for people to find the card catalog or a calendar of coming events. The tricky thing about usability is, there’s no magic bullet. Different people will use things differently, so you have to try to find a happy medium that works for everyone.

Usability also refers to the different ways a person might use your site. For instance, a user might bookmark your site, share it on a social networking site, copy content to paste into an email, print out a page, save information for later, or otherwise manipulate data.

Accessibility refers to how easy your website is to navigate by different groups of people. In the physical library, this might mean providing wheelchair ramps and large print books. On the web, it means making sure your site is easy to navigate by screen readers for the blind or people with low sight. Accessibility on the web also means serving those that come to your site via a mobile device.

Contents

Part 1: Code – The first step to creating accessible and usable websites is to create clean, semantically marked and validated up XHTML.

Part 2: Design & Navigation – Clear, concise navigation helps users that must use their keyboard to get around, and a clear, clean design helps users find your content with a minimum of fuss.

Part 3: Tools – A few tools you can use to help you do a mini accessibility study on your website, and some resources on doing more complete usability studies.

Below are the slides from my presentation:

by flickr user akakumo

This post in in response to Cory Doctorow’s recent column for the Guardian, “Not every cloud has a silver lining.” I think many of his points are well spoken, but I’m playing devils advocate here on a few things.

Here’s something you won’t see mentioned, though: the main attraction of the cloud to investors and entrepreneurs is the idea of making money from you, on a recurring, perpetual basis, for something you currently get for a flat rate or for free without having to give up the money or privacy that cloud companies hope to leverage into fortunes.

I don’t think anyone is surprised to know that companies want to make money, but if they can provide a good value for the money, I’m happy to pay it.

I’d hardly call the money I spend on my computer “free.”  Hardware and maintenance can be a big, expensive headache, and sometimes the idea of ditching all my computers, getting a cheap netbook, and living in the cloud is mighty appealing – and I’m one to build my own computers and install linux on anything with a CPU. Sometimes convenience is worth spending extra. It might cost more to tap into cloud computing resources; it also costs more to rent instead of buying. But for many, there are advantages to renting – you can move easier, you don’t have to pay for maintenance on the property, and it’s generally a little more stress free. As with anything, it’s all about personal preference.

As for privacy- we trust a lot of entities every day with our private information. Our ISP, the government, the makers of our OS (the operating systems are networked, after all). If you really want complete privacy, you’ll have to unplug your computer from the internet and preferably use an open source OS (linux). Barring that, you’ll have to trust companies a little bit. Determining who to trust and when is a continual process, and one that won’t be solved by swearing off cloud computing.

Cory actually gets at why cloud computing can be really great later on:

The first online services charged you for every email you sent or received. The next generation kicked their asses by offering email flat-rate. Bit by bit, the competition killed the meter running on your network session, the meter that turned over every time you clicked the mouse.

Cloud computing fosters intense competition. Unlike an operating system and programs installed locally, which can take significant time and money to switch, switching between web applications is fairly painless- especially if said web applications provide ways to import and export data (which is why we should demand such features of all our applications).  If you are paying month to month and feature to feature, you won’t hesitate to switch over to a competitor when they outstrip your current service in terms of cost or features. However, if you just spent $300 on Microsoft Office, you might be a bit more wary of switching to a competitor. Plus, because of this intense competition, improvements will come incrementally. Instead of waiting 3 years for Microsoft or Apple to fix that thing that’s been bugging you, there’s a good chance it’ll be rolled out next month.

I personally am not ready to trust the cloud with many functions. I don’t even use the cloud for backup storage, as Cory does, because I’ve found it’s cheaper just to buy another hard drive and keep it offsite. I believe the future of cloud computing will continue to be a hybrid of desktop and cloud applications. More and more cloud applications have ways of using the app while offline, and ways to back up data locally (including more robust APIs). As consumers, we need to concern ourselves with privacy policies and open standards, but that’s nothing new- it’s something we should concern ourselves with anyway.

One of the topics that greatly interested me from THATCamp 2009 (which really wasn’t addressed at Digital Humanities 2009) was software development/process of digital humanities projects. I’m interested in questions of workflow and task distribution—what does the team look like, and what does it actually do on a day to day basis? I had a lot of really great conversations with people that helped me clarify my thinking, and a lot of great book recommendations (most of which I can’t seem to find on the shelves, even though they say they are checked in. sigh).

Two sessions in particular at THATCamp were of great interest to me: “Picking a platform(s)” and “Software Development.” I also attended an interesting session on Drupal which, though a bit over my head, intrigued me.

Picking a Platform

A few points jumped out at me in this session. One is that it is possible to over analyze when picking a software solution, and often the best solution is to pick two or three likely candidates (the good ones tend to jump out/get recommended a lot), and work out a rough prototype in each of them. What strikes me about this is that we never work this part of the development of a project into the time estimates for a projects (when we actually manage to estimate time on a project, which is rare). Another point rephrased many different times is to try to avoid building something new whenever possible, and to look for stable, well supported projects to build on.

Another part of the discussion involved frameworks. If no CMS like Wordpress or Drupal exists that fits your project, a framework is the next best choice. Omeka is built on the Zend framework, and CHNM also tried CakePHP and CodeIgniter (and maybe something else, I was having a hard time keeping up at this point). At the CDRH, we recently used CodeIgniter for a project, which I liked because it was lightweight and the documentation seemed friendlier for non programmers (i.e. me) that have to use the framework. It worked pretty well for the project we used it on, and we will likely try out other frameworks in the future. We’re also looking into Drupal and Wordpress to build certain sites, but I am still unclear on how to integrate the large amounts of TEI documents we have into these products (if anyone has any advice, I’d love to hear it).  Many of our past projects have been built using Cocoon, and we will likely keep using this for the straightforward TEI sites.

Near the end of the session, I asked what people use to do the kinds of things I do most frequently—i.e. transform TEI documents into a website. DEAD SILENCE. This was a little surprising, but not completely so since most of the projects talked about were community building apps, not content driven sites. It was recommended I look into code4lib as well as the eXist database. This has led me to question the difference between digital library/etext stuff and digital humanities—is it the focus on content? is it the tools used? Is there even a reason for a distinction? Many of our projects at the Center could be classified more as a digital library, and I am starting to wonder if clarifying the type of project in this manner might be able to help us with our workflow a bit.

CHNM Creative Lead Jeremy Boggs remarked how the hiring of a graphic designer and his own studies in graphic design have changed CHNM’s approach to design dramatically. I found this interesting in light of other conversations I had at THATCamp regarding design—I’ll be talking about this a bit more in future blog posts.

A final point from this session is the sentiment, expressed frequently, that it would be nice to have some central place where we can share this kind of information and ask questions.

Software Development

I was really interested in this session, because at CDRH we are still trying to figure out how to… well, create software. We have very few processes in place, so it’s up to the development “team” (mostly consisting of me, a programmer, and a text encoder) to determine tools, put them into use, and train anyone else that needs to be trained. On the one hand, this is kind of nice—we get to choose what works for us. On the other hand, it is a little overwhelming, especially since none of us really have software development experience to speak of. As a result, I have become really interested in the software development process, especially as it relates to digital humanities.

Several concepts were brought up as essential to any project team of any size: bug tracking software, version control software, and, maybe, communication software. Right now we have a wiki and subversion, and are working on the bug tracking and other communication helpers. Sure, we can yell over the cubicle walls at each other, but at some point, we need a way to track all the broken stuff (especially as we keep finding more each day).

The group also talked about making more of our code open source, even the code we don’t think is very good, because others may be able to improve on it, or at the very least, use it to learn from. We need to get away from the “We’ll release it when it is finished” mentality and just get it out there. Another idea was to stop making one use only tools and to focus on broader things that can be reused. I like this idea in the abstract, but when I really start to think about how it applies to us, I see so many exceptions—little projects that will only happen once, special cases having to so with an esotaric area of inquiry from a scholar. I think part of what makes digital humanities interesting is we take on the stuff that doesn’t have a broader appeal, and therefore in any other context just wouldn’t get done. However, many of these one time projects might be of use to someone else, so the code should still be available.

What I’d like to see is a balance. Every digital humanities center or project is likely to have some code specific to their own project, but there’s also likely to be something which can be given back to enrich the community.  Both are important.

A common complaint in general at THATCamp, and especially in the Software Development session, was that documentation was always lacking. This seems to be a universal truth in software development, not just DH. One idea someone brought up was to pitch the documentation to a technical writing class for a class project. Another was to have a “documentation sprint” in the spirit of the code sprint.

One thing that was not brought up, but I have thought a lot about since reading Joel on Software (in book form), is the idea of the spec. We have never written a spec for any of our projects (that I know of), but I think it would be a useful exersize. You can read Joel’s series on specs here in 4 parts: I II III IV. I especially like the idea that a detailed spec, done right, can serve as a basis both for testing the end product and as a start to the documentation. What we have in place of a spec is a mess of meeting minutes—sometimes a year’s of biweekly meetings—which would be near impossible to go through to nail down all the decisions that have been made. Instead, the idea of a website is in one person’s, or several people’s, heads, which makes it pretty hard to sit down and build.

To be continued

I’ve just scratched the surface on the topic of software development. To an experienced software developer, most of these ideas will be old hat, but to me, most of it is completely new. I think this is one of the sometimes frustrating things abut working in a digital humanities center—we don’t hire with the thought of creating software projects, even though that is much of what we do. And much of the apparatus for website development I am used to from working in an ad agency (such as an art director) isn’t there either. It’s really no one’s job to tell us how to work as a team effectively.

On the other hand, this is what I absolutely love about my job. I get to be the art director, designer, coder, tester and researcher, which I find much more interesting than just design or just coding. For me, it’s really ideal, and I would not change a thing.

So I have an overdue post due from DH09 and THATCamp09. Maybe I should first explain what those are.

Digital Humanities 2009 Conference

Digital Humanities is the web conference for those involved in (wait for it…) digital humanities. This was the first academic conference I’d been to, adhering mostly to 1.5 hour sessions with three papers each, with people generally reading a paper with bullet point slides in the background. This is in contrast to the library conference I’d been to, which generally had less paper reading (though the bullet points, unfortunately, seem to be a staple everywhere).

Many of the sessions I attended had to do with data visualization and tool discussions. In both of these types of presentations, I found myself wishing that the presenters would start with the demo and then go on to talk about it, especially as many weren’t available on the web. Some of the groupings didn’t really make sense – that is, two of the talks would have a lot to do with each other and the other didn’t really.

The first two days I was at DH I felt very out of place- more than I felt at my first ALA, bot in that case I was staying with a close friend who is also a librarian, so that helped. I felt acutely my lack of an overarching “research interest.” Also, I didn’t know anyone in person and though I knew a few people from Twitter, I always saw them while they were talking to someone else so I didn’t introduce myself. In hindsight, this was probably my biggest mistake.

By day three, I felt more at ease, and this was also the most interesting day of presentations for me, so that helped. I was finally starting to get the hang of things when DH ended- but I did introduce myself to several people the last day.

I don’t know for sure if I will attend future DH conferences. My position does not get any travel funding (even if I were to present, and I’m not at all sure what I would present on anyway) and this was the last year I could get student pricing.

THATCamp (The Humanities and Technology Camp)

THATCamp Twitter Word Cloud (photo by ghbrett)

On the opposite end of the cost spectrum, by contrast, was THATCamp which is donation only. I attended THATCamp last year, so I knew a little more what to expect, and I felt more at ease right away. I’m not sure exactly why that is, but I think it has to do with the informality and the mix of people. It’s not that I don’t like hanging out with academics, but my job just doesn’t allow the time to think about the academic-y research questions, and THATCamp addressed some of the more, shall we say, down to earth aspects of digital humanities such as: how can we make this all work? While DH seemed attended by the scholars who told someone what to do, THATCamp seemed to be attended by more of the techies (I don’t consider that term a put down, BTW) themselves, and scholars who took more active roles in the development of their projects. Again, maybe my impressions are completely off, because it has all to do with  the sessions attended.

THATCamp, for those who don’t know, is (mostly) an unconference, though with a little more structure than many unconferences. The structure comes in the form of a blog, where people can post their ideas ahead of time and others can comment. The first day of camp we signed up for sessions, and the organizers grouped these logically.  I like this idea, but in practice a bunch of people posted on the blog the last day, when I didn’t have time to read them all before the camp started, and stuff was grouped together that maybe should have been seperate. I think either a 24 hour suggested deadline for the blog might be good, or some of Daniel Chudnov’s great suggestions for improving on THATCamp.

Oh, that's me on the left (photo by ghbrett)

Last year when I attended THATCamp, I did not know how to program, was still getting my Master’s degree in library science, and was a lowly assistant at the CDRH- so while I found everything very interesting, I had a hard time putting things in context and I really couldn’t implement anything I learned as my job was centered around setting meetings and taking minutes. Still, I felt like a part of the crowd and accepted even then, and this was true even even more (if possible) this year. Now, I am a graduate with a degree in library science, and working as one of the developers (visual resources designer) at the CDRH. I have also started down the programming road thanks to Steve Ramsay’s class taken last school year. This meant that this year’s THATCamp filled me with ideas I could actually implement, which is a Very Good Thing. I hope more of my co-workers can attend in the future.

THATCamp was notable for being my first conference where it seemed like almost everyone was on twitter. Tweets came fast and furious, and at some point I couldn’t keep up anymore. But it was a great way to make connections between sessions. Since THATCamp ended, the “#thatcamp” tag has been used to continue discussions started at camp, and to start discussions about regional THATCamps- an idea that just may be the best thing to come out of THATCamp. Travel money is unlikely to get any looser in the next few years, and regional unconferences are a great way to get together at a minimal cost and share ideas. Hopefully more centers and universities will be able to sent their staff to a regional get togethers if nothing else. (More on that, probably, in a later post.)

Both DH and THATCamp were enormously beneficial, and I am glad I went. I am a little sad to miss out on ALA this year, but buying a new house (before selling the old one) has limited my funds somewhat. Maybe next year. Int he meantime, both conferences have given me a lot to think about and (hopefully) blog about.

In my Electronic Texts class this semester, we have decided on a class project: a poem illustrator.

The idea is simple enough: input a poem and the program will pick a flickr picture as an illustration.

But how to pick the picture? You could analyze the poem, remove stop words, find the most common words, and search on that. But that doesn’t return great results because a) there may be quite a few “most common” words, and b) just because a word is the most common, doesn’t mean it will return a meaningful picture.

So as an alternate method, the class decided to run each of the words in the poem (minus stop words) through the flickr.tags.getRelated Flickr API method, and then again sort the results and find the most common word.

The idea was that if you have words like “flower” “tree” “field” “bird” you might, using this method, hit upon the common word “nature” and thus be able to use that to help pick a picture to illustrate the poem.

Well, I decided I just had to try this out this weekend (I’m impatient). So last night I wrote something in Ruby that would read in the poem, put the words into a list (I chose to ignore duplicates), and then feed those word to the flickr API and get a list of related tags, and then rank the tags. My code is crude and clumsy (for instance, I didn’t even filter out stop words because Flickr does that for me) but I got results.

The first poem I ran through was T.S. Elliot’s “The Waste Land.” Actually, to be more precise, it was the first part of “Wasteland,” because it’s a long poem.

“The Waste Land” by T.S. Elliot

APRIL is the cruellest month, breeding
Lilacs out of the dead land, mixing
Memory and desire, stirring
Dull roots with spring rain.
Winter kept us warm, covering
Earth in forgetful snow, feeding
A little life with dried tubers.
Summer surprised us, coming over the Starnbergersee
With a shower of rain; we stopped in the colonnade,
And went on in sunlight, into the Hofgarten,
And drank coffee, and talked for an hour.
Bin gar keine Russin, stamm’ aus Litauen, echt deutsch.
And when we were children, staying at the archduke’s,
My cousin’s, he took me out on a sled,
And I was frightened. He said, Marie,
Marie, hold on tight. And down we went.
In the mountains, there you feel free.
I read, much of the night, and go south in the winter.

by Jon Bradley Photography

Here’s the top of the sorted returned related tags I got back:

102 – <tag>abandoned</tag>
3 – <tag>wood</tag>
3 – <tag>blossoms</tag>
3 – <tag>window</tag>
3 – <tag>blackandwhite</tag>
3 – <tag>trees</tag>
3 – <tag>river</tag>
3 – <tag>rocks</tag>
3 – <tag>scary</tag>
3 – <tag>purple</tag>

“Wow!” I thought. 102 times I got a related tag “abandoned” for the poem The Waste Land. This returned the Flickr picture on the right, which I consider a great illustration for the poem.

At this point I did a little dance (literally, ask my husband) and congratulated myself on Twitter.

But too soon! Because I had not ran the results on any other poem. As it turns out, “abandoned” is a REALLY common flickr tag (as is “abigfave”).

Take this example:

“Messy Room” by Shel Silverstein

Whosever room this is should be ashamed!
His underwear is hanging on the lamp.
His raincoat is there in the overstuffed chair,
And the chair is becoming quite mucky and damp.
His workbook is wedged in the window,
His sweater’s been thrown on the floor.
His scarf and one ski are beneath the TV,
And his pants have been carelessly hung on the door.
His books are all jammed in the closet,
His vest has been left in the hall.
A lizard named Ed is asleep in his bed,
And his smelly old sock has been stuck to the wall.
Whosever room this is should be ashamed!
Donald or Robert or Willie or–
Huh? You say it’s mine? Oh, dear,
I knew it looked familiar!

by windy234

Here’s the top of the list of returned tags for this one:

86 – <tag>abandoned</tag>
86 – <tag>adorable</tag>
3 – <tag>d200</tag>
3 – <tag>clothes</tag>
3 – <tag>d300</tag>
3 – <tag>christmas</tag>
3 – <tag>cat</tag>
3 – <tag>city</tag>
3 – <tag>clouds</tag>
3 – <tag>d80</tag>

As it turns out, searching for “abandoned” and “adorable” mostly returns pictures of stray cats.

I am not sure why “abandoned” is such a popular related tag, but this means I am back to the drawing board. To be sure, there are a lot more variations the class can try here—we can run all the words, not removing the duplicates. Lots of improvements can be made on my often broken and inconsistent code—I can’t even replicate the results I got the first time for “The Wast Land” already!

The big question on my mind is, how can we get an accurate measure of “relatedness” when it comes to words? Going back to the original example, how can we train a program to derive “nature” from the words “flower” “tree” “field” “bird”? It is possible to use the Flickr tags for this purpose? The idea behind folksonomies let me down here—as it turns out, people add tags for all kinds of reasons other than to describe the picture. I already knew this by my own practice using tags—I often use tags with no semantic purpose, for instance to group a few images together. I guess I thought the most popular use of tagging would be to describe a photo. The tag “abigfave” refers to the flickr group “A Big Fave” which seeks to find and promote good images. The thing is, I shouldn’t feel let down by folksonomies here. The tags are still serving their purpose by helping people find things.

I’ve been trying to think of other ways to get at the related words of a poem. I thought of mining delicious.com tags, but those are used for even more utilitarian purposes—e.g. items tagged with “flowers” are likely also to be tagged with “wedding.”

One other idea I can think of is to create our own related words list by mining, say, a million books. This is one possible answer to Gregory Crane’s question “What Do You Do with a Million Books“? I’m not sure exactly how this would work—it would probably involve analyzing the texts for words that appeared near each other, maybe. Even if we did the analysis, though, we may end up finding the same results as my Flickr search did. The thing is, it’s impossible to know without trying first.

by Voj

This is a sort of follow up to yesterday’s post. Steve posted a nice comment, assuring me that “In the end, you’re better off developing a relaxed attitude toward the fact that you will *always* feel a bit stupid in this business.”

I completely agree, and on some level I know this—at the same time, the anxious nervousness I get from NOT knowing drives me forward. It’s exciting to have a whole topic in front of me I know almost nothing about. Although this comes with frustration, it’s of a limited kind, because I do have faith in myself to learn this stuff. One thing I want to be sure of is that I don’t go too far down the rabbit hole into things I don’t really need to learn—after all, we do have a programmer. And there are other things I really want to delve deeply into, like data visualization.

Anyway, that’s not really what this post is about. What it is really about is my deep indebtedness to all my friends, techie and not, who provide support and words of encouragement.

First and foremost, of course, is my husband, who is always unwavering in his support for me. Ditto for my parents. Then there’s my real life techie friends, who bring me back to earth when I start to get a little TOO overexcited, and provide encouragement, and sometimes let me bitch over lunch/drinks/boardgames. And then there’s all my friends online—commenters on my blog, friends on Twitter and Friendfeed—that provide encouragement and help right when I need it. I can’t begin to describe how lucky I feel. I don’t know how much of this “I can do it!” attitude I would have if I didn’t have people surrounding that echo the sentiment.

That’s it, really. Just wanted to get that out there. thanks everyone.

by Joshua Davis (jdavis.info)

I’ve been busy these last few weeks. Though I dreamed of having lots of free time to read and relax post grad school, free time has been hampered by two things: Geoff and I decided to look for a new house, and I’m having to learn a LOT for the new job. If you want to read about the reasoning behind the house hunt, head over to my other site, OS Agnostic. Here I’m going to talk about steep learning curves and the troubles they present.

My situation is not uncommon- though I knew a lot of what was needed for my new job as Digital Resources Designer, there are a lot of things I need to learn. This is exacerbated by the fact that some of the technology we use/used was only known well by my predecessor.

Some of what I need to learn is pretty straightforward—PHP is an example. I am muddling my way through a few books on PHP, and can puzzle out a lot of stuff. I’m also getting better at XSLT and can do much fancier things with it than before.

The harder things I am learning are tough for a few reasons. One is that there’s no easy learning guide, and another is because the guides that do exist assume Unix/Linux system admin experience, which I don’t have. These technologies include Tomcat, Cocoon, Solr, and XTF. The other problem I have is we use these technologires in a somewhat simplified way, and I don’t need to know how to do everything with them. I really only need to learn to do a small subset of what the program can do, but all that information is bundled in books or websites with a lot MORE information than I need.

by Victor Gregorio

Finally, I feel that, lacking a computer science background, I am missing something vital to the understanding of these technologies. I’m not sure if this is a common feeling or not. I end up feeling lost much of the time.

The learning curve problems are multiplied by two, because the Center hired a programmer who started in January and is also learning these technologies (albeit more quickly than I am.) The person we replaced knew all these technologies, unfortunately, he was the only one who seems to know some of them well. We’re still trying to figure out how he did the work of two, since the programmer and my position are a split of what my former colleague did. I remain in awe of his prolificacy.

So, work is going well, but I can’t help but feel a little lost much of the time. It is really great when things fall into place and I understand something, but sometimes that moment seems all too elusive. And it is hard to balance the learning needed with the other things that need to be done.