“Women in Tech” organizations

The other day I watched “Adriana Gascoigne @ Big Omaha 2009.” While I agree with much of what she said, I had a vague sense of unease with the whole idea of “women in tech” organizations. Today, while reading Hillary Mason’s post Stop talking, start coding I started to get an idea of why I have a problem with them:

Many groups have popped up that support women in technology, like Girls in Tech, She’s Geeky, and many others (enumerated in Digiphile’s thoughtful post Why Including women matters for the future of technology and society). More often than not, these groups are the canned food drives of the women in technology movement. They make you feel better, they might do a little good, but they offer no fundamental change to the system that created the problem in the first place.

The NY Times article Mason was responding to, Out of the Loop in Silicon Valley, contained this choice quote:

“Women tend to network with women, and men tend to network with men,” says Sharon Vosmek, C.E.O. of Astia. “It plays out on the golf course, in the boardroom and it’s certainly playing out in high-growth entrepreneurship.”

I then looked at the organizations mentioned in the previously mentioned blog post Why including women matters for the future of technology and society by Alexander B Howard. Some seemed to do serious good – providing grants for startups led by women. Some were a roundup of links and news about women in tech. But I noticed a prevailing theme in many of the about pages. See if you can pick it out:

… As young women with the capacity to inspire, we made it our personal desire and passion to create and sustain an organization that focuses on the collaboration, promotion, growth and success of women in the technology sector. … (Girls in Tech)

… As young women with world-changing aspirations, we recognize entrepreneurship as the means to fulfill our life goals. After attending numerous local networking events for entrepreneurs in the Silicon Valley, we asked “Where are all the women in the Silicon Valley?” … (Women 2.0)

… We’re young women with the power and passion to make a difference. We believe in the potential of computing to build a better world. (dot diva)

OK, I realize tech, as a field, belongs to the young. But maybe that is part of the problem. Maybe if we stopped focusing on age and more on experience and desire to learn, we can reach more people. Maybe women, especially – who may have a late start after having a family – could use help no matter what their age. And maybe we can get rid of that damn “so simple your mom can use it” stereotype while we’re at it.

Maybe if we stopped focusing on age and more on experience and desire to learn, we can reach more people. Maybe women, especially – who may have a late start after having a family – could use help no matter what their age.

On genderized assumptions:

We are socialized our entire lives to live up to predetermined roles. These have to do with gender, but also race, age, how we dress, what color our hair is, who we are with. This isn’t surprising – humans interact with tons of people, and to simplify things, we start to group them. Fair enough. Trouble is that we don’t realize we’re doing it, and that many of the stereotypes we base our assumptions on are misleading (movies, TV, other popular entertainment), or are outdated. Example:

Today I got an estimate for an addition we’d like to make on our house. I contacted the contractor, yet he spent most of the time talking to my husband, asking him things like “can you lay tile” (n.b., I’m the one that bought or registered for every power tool we own) and, after I told him our budget, said “tell your husband to make more.” None of this is that bad, but it’s also not unique. It’s pervasive, the sort of thing that women hear every single day our entire lives. I don’t think it’s stretching to guess that many women have experienced this in tech careers, math and science classes, etc.

Things like these couldn’t possibly be the reason that women don’t put themselves out there and take chances, right? Subtle indications that women are less capable than men at some things are lifelong and pervasive.

To go back to the New York Times article mentioned above:

But when she was raising money for Crimson Hexagon, a start-up company she co-founded in 2007, she recalls one venture capitalist telling her that it didn’t matter that she didn’t have business cards, because all they would say was “Mom.”

Another potential backer invited her for a weekend yachting excursion by showing her a picture of himself on the boat — without clothes. When a third financier discovered that her husband was also a biking enthusiast, she says, he spent more time asking if riding affected her husband’s reproductive capabilities than he did focusing on her business plan.

So despite many comments about how there is no problem, there IS overt sexism and subtle signals throughout our lives telling us what we are and are not good at.

On Self Confidence:

Finally, I read this bit on self confidence on the Geek Feminism Blog and I TOTALLY related to it:

It seems like a certain amount of “irrational” self-confidence is necessary for success in geeky fields. STEM work usually involves a lot of failure before you figure something out. While you’re failing repeatedly, you have to keep believing you can do it and you’re smart enough to figure it out. But the repeated failures, to me, always seem like evidence that I’m not smart enough. From a scientific perspective, I demand proof: what evidence is there I can do this? And there seems like a lot of evidence that I can’t.

Thing is, when I shared it, I got many men saying they could identify too. So it isn’t a uniquly woman trait after all.

The point

OK, remember that story I told above about the contractor and the estimate? Let’s pretend a different scenario – say, one where a couple is planning a wedding and consult a wedding planner. Obviously a good wedding planner would involve both parties equally, but in practice, he or she might address the woman more even if the man is the one that’s most interested in the details. Or imagine a guy dragging his girlfriend to a cooking class. Or a couple choosing a day care. In all of these situations, there is a good chance that the woman would be addressed more than the man. And that gets to the heart of the problem. We can’t assume that women are into family and men their careers, that women need confidence boosting and men don’t.

Maybe the problem is more like this: some people aren’t very good at promoting themselves. Maybe more of those people tend to be women, but the problem exists for those that aren’t women as well. Maybe some of us humans tend to downplay our accomplishments and let others take the spotlight. Maybe some of us humans don’t want to let work dominate our lives, want to spend time on other pursuits (like, *gasp* our families, or our communities).

Maybe we can figure out how to make the workplace work for lots of differnt types of people. In the process, we’ll probably draw in more women and minorities – because who wouldn’t want to work in a field where their accomplishments are valued and their opinions respected, and employers realize that yes, there is life outside work?

This is not to say we can’t recognize the disparity of women in tech. But we might want to take it in context of a larger problem – our inability to see each other as humans fist, and gender, race, whatever else – second.

(title is a nod to Clay Shirky’s “A Rant About Women“)

Let me know what you think!

Christmas at parent's house: an OLPC on top of another laptop.

I know this is late. I started it yesterday but did not quite finish.

March 24th is Ada Lovelace day, “an international day of blogging to celebrate the achievements of women in technology and science.” (http://findingada.com/about/) There are a lot of women in technology I could write about, but I am going to start with my first influence, my mom.

I first learned HTML because my mom learned it and encouraged me to do the same- and I got my first HTML coding job after she left it. She’s held several jobs involving programming and computers, but more than the jobs she’s always had a fascination with computers that she passed on to me.

Whenever a new technology comes out – most recently the iPad – people talk about subjecting it to the “mom test.” I laugh, because my mom is one of the most tech savvy people I know.

I can’t remember a time in our house when we didn’t have some kind of computer. I don’t remember all the different kinds we had, but I know my mom was the driving force in acquiring most of them. We had one that used an audio tape as its storage media- which enabled my mom to write a program that quizzed me on my spelling words using the tape to record her voice saying the words.

Today, mom always has the latest gadget- slingbox, android phone, netbook, and she hacks these devices to her liking. She listens to all the techie podcasts and uses open source apps. Most of all, she maintains an unrelenting excitement about the future of technology that I can’t match- but I know I can always check in with her if I want to know what hot new device is next on the horizon.

Whenever a new technology comes out – most recently the iPad – people talk about subjecting it to the “mom test.” I laugh, because my mom is one of the most tech savvy people I know. The test will probably change soon to the grandma test, and I’ll still laugh – my grandma’s a gamer.

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!

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

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.

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.

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.

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.