Speaking of experiments, there’s our comments section. Everybody knows inline blog comments are going the way of the BBS and Gopher sites of yore. We’re not ready to say “comments are dead” (we’ll leave that for Wired Magazine’s next cover story) but we have noticed the smell, and we’re doing something about it.

Kids today are more likely to respond to a blog post on Twitter than in the article’s comments section; so we’ve collocated our comments on Twitter. Share a tweet-length response here, and, with your permission, it will go there. If you are moved to respond with more than 140 characters, post the response on your website, and it will show up here. Clever, these Americans.

So, comments are done either via Twitter or through your own blog. Want to comment through Twitter? Compose your tweet on the Cognition post’s page and submit. Want to submit one of your own blog posts as a comment? Go write and publish that post, then come back to the Cognition post’s page and submit your post’s URL.

I have to say, I really like the idea of putting a textarea on the post page so readers can tweet a message. After reading the article, I can tweet a comment immediately, and send it to my Twitter feed, without having to go to Twitter.com, or open TweetDeck, or copy/paste the URL. But looking at the very first post on Cognition, there are over 350 responses, and a cursory glance over all of them indicates they’re all from Twitter. It is a first post, and a pretty big announcement, so this is probably expected. But I agree a lot with Jeff Croft, who in a comment on Airbag argued that this approach possibly adds unnecessary noise to Twitter (already pretty noisy). Croft suggests (and I agree) the tweeted comment should be an @reply (to @happycog perhaps, since @cognition is taken by someone else!) so only your followers who are following that Twitter account see the post. There’s a question of audience here: By posting comments through Twitter, my comment is sent to all my followers. Which raises a question about who I should write the comment for, Cognition’s post author, or my twitter followers?

I also like the idea of providing a spot to input a specific URL to a blog posts I’ve written as a response. It’s a little more deliberate than relying on a linkback system. There only seem to be a handful of these kinds of comments on Cognition’s first post, however, and those do get lost in all the other Twitter comments. I would value these comments much more, since they supposedly took a bit more time and effort to compose, and this is where I think good, meaningful, productive conversation and feedback would take place.

Of course, it seems both of these solutions have been, or can be, implemented on your blog now. There are several plugins for WordPress, for example, to collect “tweetbacks” to your blog posts. And much more established is the concept of linkbacks from one blog post to another. It seems the major difference between these solutions and the implementation on Cognition is that the reader explicitly has to write her/his tweet or add his/her post link through Cognition’s site.

One major problem I see with comments on Congnition, in either tweet or blog form, is the complete lack of a permalink back to the original tweet or blog post. Links to a comment author’s website have become pretty standard in commenting systems. Plus, comments have served to build community and readership. There is almost a gift culture with blog commenting, where regularly commenting on a blog encourages the blog author and other blog readers to check out your own site, and comment on your posts as well. Having no permalinks back to tweets or comment posts effectively negates this culture. Not sure if this is a feature or a bug, but I’m curious to know!

My comments are a sloppy mess, and I am inspired by Cognition’s approach to rethink commenting here, and to reconsider how I comment elsewhere. I’m definitely curious to see how their experiment evolves, and I hope it does evolve, because I think there are plenty of opportunities to improve. The folks at Happy Cog have been very receptive to praise and criticism of their commenting solution, so it’ll be fun to watch.

When a history professor is researching and writing a book, for example, she isn’t necessarily concerned with what her “users” would like to read about. Maybe some are, but most academics are concerned less with meeting audience needs than they are with teaching the audience something new. In fact, they see one of their goals as contributing new knowledge, knowledge those academics think will be useful to their profession as a whole. They don’t necessarily write monographs to make it easier for, say, K-12 teachers to use them in class. In a lot of ways, usability is prescribed in the format of the academic monograph: table of contents, chapter headings, page numbers, paragraphs, footnotes, the occasional figure or appendix. And, if I may speculate, this prescribed format may undermines the need for the creators of academic scholarship to really think about usability.

Most websites, however, are built with user needs primarily in mind, at least most commerce-based websites. Business do focus-group testing, user testing, and marketing to try to meet particular user needs. In that sense, websites try to provide something users want, without uses have to think about how to get what they want. In fact, one of the leading web usability book in print is titled “Don’t Make me Think!” and argues that websites should strive to create interfaces and experience that require little thought to use.

Digital humanities websites, it seems, have to walk a fine line between two very different goals: On the one hand, we do want to provide information and tool that we, as experts, think the audience should use and need. On the other, we can’t simply offer it and expect that our audience will find it valuable. The trick with digital humanities projects, it seems, is to encourage users to think about specific things, think we want them to think about, while providing tools and methods for doing that kind of thinking in an unencumbered, clumsy web interface.

In Train of Thoughts, John Lenker argues there are three parts to providing a effective experience on the Web:

1. Entice – Get the audience interested in your topic
2. Inform – Provide some meaningful information to the audience; Educate audience about a particular topic.
3. Invoke – Encourage a response from the audience, ensure that the information you’ve given them can be put into meaningful action somehow.

Traditional academic scholarship is almost exclusively focused on the second part: Inform. It may dabble in the Entice part, with catchy titles or discussions at book clubs or on the web. And while scholars certainly want to invoke a response from colleagues, the product itself doesn’t encourage a variety of responses. Digital humanities, though, has the means of combining all three into a meaningful, usable experience. In fact, I would argue that any work in the digital humanities needs to accomplish all three to be effective.

Generally, my design process follows this flow: Brainstorm & Research → Concept → Mockups. Of course, the process never goes straight from one to the next, but meanders as ideas develop. That’s OK, so long as you have a process to begin with, and have good, thought-out reasons for going back and forth during the process.

The Process

Brainstorm and Research

The first part of the design process involves something humanists should be quite familiar with: research and brainstorming. Great design solutions take lots of research and lots of thought, and don’t simply appear out of thin air. A significant investment in brainstorming and research during the design process helps produce great results far more often than without.

When I begin a design project, I usually ask the project team or project lead what kind of mood or atmosphere we want the site to set for users. It is important to get feedback from the team at this point. I advise setting aside one or two meetings for this, just to come up with aesthetic concepts and sort through which ones are most useful, before touching Photoshop. When I asked this about Gulag, for instance, the responses were almost always “cold,” “grey,” “dreary,” “worn,” and “sad.” Create mood boards, find other websites that contains elements you like, create color palates, whatever works for you and your team. The point is to get those creative juices flowing, to come up with ideas no matter how crazy. I’ve found that if you get stakeholders involved at this point it helps head off issues when discussing design mockups later on in the process.

I keep an Idea Box in my office, and put things that I think are designed really well, or use design elements that I’d like to emulate in a future project. These things include magazine clippings, keychains, flyers, product boxes, coffee cup sleeves, anything that I think is designed well, has a strong concept, or implements interesting solutions. I also keep a library of website screenshots that I like using iPhoto. I regularly check out CSS showcase sites like CSS Mania, CSS Beauty, and Stylegala, to name a few. Sometimes I’ll take shots of the entire screen, and sometimes I’ll take clips of particular portions of a site I like, such as forms, headings, lists, or navigation. All of these serve to get ideas flowing in my head, figure out how others have solved design solutions, and learn from them.

Screenshot of Gulag: Many Days, Many Lives.

Important for designers in general, but especially important for digital humanists, is researching the materials presented on the site. I look at materials not to engage them as an historian, but as a designer (though I can’t help but look at them as an historian too). I look for the emotions the materials evoke, for ideas to draw from, for inspiration. For Gulag, there were lots of photos, drawings, letters, and posters on the history of the Soviet Gulag prison system that provided a wealth of design inspiration. I was drawn to a particular photo that depicted the remnants of a barren camp, and decided that would serve as the centerpiece for my design.

The Omeka logo had a somewhat similar development. From a design perspective, Omeka has been one of our more difficult projects to design and market, because we want to appeal to so many audiences: We want it to appeal to a general public, but also to have a professional, academic air to it. As it says on the Omeka website, the term “Omeka” is Swahili for “display goods, to unpack,” so we wanted something that embodied that idea too. So, I researched potential sites that could be built with Omeka and looked at sites that our target audience created.

At this stage, I use pencil and paper a lot. Before I touch Photoshop, I sketch ideas, usually thumbnail-sized boxes with layout, color, and graphics ideas. I like to keep a regular notebook for sketching ideas for various projects. I have a box full of crayons and colored pencils. I try out color combinations on paper and quickly draw logo ideas and layout ideas. These help me explore concepts quickly, without the investment of time and energy it takes to sketch ideas on the computer.

Concept

The whole goal of design, for the web or otherwise, is devising and implementing a concept or solution for a specific problem. If you do not have a concept—if you choose images, colors, fonts, et cetera with no reason—you’re decorating, not designing. Designers should have a reason for almost every design decision: fonts, font size, font weight, leading and kerning, margins, padding, layout, colors, widths and heights, images. Design does not implement these things haphazardly.

For Gulag, my concept was simple: a cold, snowy camp, isolated and desolate. I took the photo of the camp I had found and made a Photoshop brush of the building and fence, then created a white silhouette of the camp that blended into the white background of the content area of the site, giving the sense that the camp in the header held or contained the content below. The logo employs a font called P22 Johnston Underground which, besides being similar to the font used for the London Underground, is reminiscent of fonts also used in Soviet propaganda posters. Thus, my design for the site combined a rugged, worn, desolate camp with a bureaucratic, constructivist attitude.

Logo for Omeka.

For the Omeka logo, my concept involved modifications to the “unrolling” or “unraveling” that we initially came up with as a team. I liked the idea of a spiral, but also felt that the spiral should have direction, and not seem like a spiral out of control. One of the strengths of Omeka is its structure and ability to frame and guide the creation of an archive or exhibit. So, instead of a random spiral, I used the Fibonacci spiral to indicate unrolling, but in a systematic, controlled, directed way. The path in the logo represents the seemingly endless and creative ways you can use Omeka, while the ratio of squares and rectangles represents the framework and guidance that Omeka provides.

Humanist scholars should see the utility in having a purpose for doing something; we usually have a purpose all the time, whenever we write a paper, give a lecture, or contribute to a conference. We always have a thesis, an argument that always tries to solve a problem or get a concept across to an audience. Design is no different. Good design always has a problem to solve, a concept to get across to an audience. Choices about color, typography, and layout should be solutions to that problem.

Mockups

Once you have a solid concept in place, now you move to creating substantial color mockups in Photoshop or another graphics editing program of your choice. At CHNM, we generally develop 2-3 different mockups, each with 2-3 levels of page: homepage, a “browse” or secondary page (like browsing the results of a search), and a “content” or tertiary page. Sometimes each mockup has its own concept, and sometimes all are simple variations on a central concept. The wireframes created in the previous phase come into play here. Ideally, the design team has enough information about what content will go on a page and how much to do a quality mockup. If they don’t have this, it is extremely difficult to do mockups. I almost always make a checklist of all the content elements that should appear on a page, and check them off when I have accounted for them. Adding new content elements can and usually does throw off the design.

As a personal rule, I always start with the most “inside-page” first, or the content/tertiary page. The inside page is arguably the most important page on the site, the page that your users are trying to get to and will want to use. The homepage and the browse pages are important, but only in the sense that they’re sole purpose is to help users find that last page of content, the one they’re going to use, for research or educational purposes. Think of a website review, an archive page for a single item in your database, or a blog post with comments. Your approach may be different, depending on the information architecture of your site, or your own personal style.

Screenshot of photoshop mockup I created for a redesign of the Western History Association website that illustrates use of guides for grid layout and typography.

While creating mockups, its good to keep a running list of design specs that you’ll need to translate into CSS when you begin front-end development. I pay particular attention to font sizes, margins, line-heights, and colors for various parts of text (paragraphs, headings 1-6, lists,etc.). I also think about the grid I’ll use for the page design. I use a very handy Photoshop script called GridMaker, that allows you to quickly create a grid of columns and gutters using values you input. I almost always design pages using a 12-column system, which allows for the most flexibility (2 divisions of 6 columns, 3 divisions of 4 columns, 4 divisions of 3 columns).

Photoshop Management

A few tips for doing mockups in Photoshop:

1. When making color mockups in Photoshop, I usually set the resolution to 300dpi, so that they print nicer and can be used in grant applications (which CHNM does a lot). You can bump them down to 72 dpi to use directly on your website if needed.
2. Name your layers. Let me say that again. Name your layers. It is so much easier for someone else on a project team to open your photoshop file and find a particular element on the page if you name your layers meaningfully. Don’t use a name like “layer 1″ because, well, that’s just not meaningful. I don’t have solid naming conventions, but it might be good practice to implement some.
3. Use layer groups. When I do a mockup, I generally have each page level I’m creating in its own folder, so I can work in one file and not three separate files. I also use folders for sections or groups of content.

Presenting and Discussing Design

A few quick tips/observations on some best approaches for presenting and discussing design:

• The design team should prepare a design brief, written or oral, to present to the project team on the design concept implemented for each mockup. Part of a designer’s role is to sell her/his design, to explain why she made certain design decisions and how they successfully apply the overall concept of the site. This helps in a few ways: 1) It allows your thought process concerning design decisions to be more open and available to the project team, and 2) in most cases, it will help you counter unhelpful feedback like “I don’t like orange.” by showing someone giving that kind of feedback how to provide more constructive, nuanced reasons.
• Stress that design isn’t about using favorites: favorite color, font, images, whatever. Design is about finding the right solution for your project. For example, I hate purple. I can’t stand it. But I’ve used in on several sites because I thought it provided the right solution for a concept we were considering. Similarly, Gill Sans is probably my favorite font, but I don’t use it on every site I make (even my own blog) because its not always the best design solution for a particular project.
• Resist design stenography. Design isn’t about simply taking orders or requests from someone and implementing them. “Change this color to red” isn’t design. This requires diligence and respect from all sides: especially the designers and the project managers. Compromises can easily be reached, with patience, respect, and intelligent discussion.
• Avoid “mix-and-match” design, or taking elements from multiple design concepts and combining them. If you’ve done the design carefully, and implemented each concept consistently, mixing design elements from different concepts will be counter-productive.
• Limit the number of feedback rounds and revisions, and avoid design-by-committee. A project can easily spend months on design revisions, and can end up including a dozen different people, each with her/his own opinions on a design. Its very easy for the project team to get bogged down in discussions of “I don’t like this color” or “that font is too big,” especially if this comes from way too many people. Too many cooks in the kitchen is an apt analogy. Set a specific round of revisions (I prefer to limit feedback to 2 rounds), and set the number
• Don’t be defensive. A designer on a team will invariably have to discuss design with people who aren’t designers and who don’t think and speak like designers. Getting defensive about design decisions will only create animosity among the team, and never leads to productive results. As a designer, part of my role is to demystifying the design process, to help non-designers understand how I approach a project as a designer.
• Be positive and diplomatic with feedback, and help other better articulate their reasons for critique There are a few ways to react to feedback. One way to react to someone not liking a particular color or font is to explain why you made that design choice to begin with (“I wanted to make this stand out because in our wireframes we wanted this piece of content to seem more important than the rest.”) and then ask whether they agree with my reasoning. For instance, I chose a font for a logo for a CHNM project, and a few folks on the project team didn’t like the font. I explained that I chose the font because I felt it conveyed a sense of what I called “professional playfulness” and that allowed others to better articulate why they didn’t like the font, in this case because they didn’t want the logo to exhibit playfulness. I was then better able to find out what idea they did want the logo to exhibit, and choose fonts accordingly.

Designer’s Toolkit

Here are a few things I keep in my toolkit and highly recommend:

• Pencil, Pen, Paper!!! – Colored pencils, markers, crayons, lots of scratch paper. Use ‘em, don’t be afraid to draw something stupid. Get ideas on paper, as many as you can. Design concepts evolve with thought and experimentation, so don’t be afraid to go crazy.
• Idea Box – Keep stuff you think is designed well, and think about why you think it is designed well.
• Photo album or collection – For screenshots and other images. I use iPhoto, but you could easily use Flickr or some other online service. I also have albums when doing research for a project, like Gulag. Half of the image catalog we have on the Gulag site is on my laptop, because I looked through them when doing research for the design.
• Photoshop and Illustrator, with a host of brushes, patterns, and plugins. Make brushes and patterns yourself, and export them so other memebers of your team can use them too.

Development Environment

I develop most projects on my local machine, a MacBook Pro running OS X “Leopard.” I have a nice 24″ Apple Cinema display at work that lets me keep a few windows open at once. I actually had a 30″ display, but downgraded because I started feeling like that was too much space (thought it was very handy when working in Illustrator).

I use the Apache server pre-installed with OS X, and enable and modify the PHP 5 package that also comes pre-installed. I also run MySQL 5, so I can work with database-driven software like WordPress and Omeka. Basically, I use my laptop as a web server, and work locally. Its very handy because files load faster, and I don’t need an internet connection to work. In fact, as I’m writing this I’m at work on an Omeka theme, on an airplane 37,000ft in the air (en route to Portland, OR).

Browsers

I usually test a project on the following browsers: Firefox, Safari, and Opera for Macintosh; Firefox, IE7, IE6, and Opera for Windows. We have a Windows machine set up in the office that has both IE7 and IE6 installed.

For initial development, I use Firefox, with a bunch of extensions. My favorite extensions include the Web Developer Toolbar, Firebug, Operator, and of course, Zotero. I use Operator to check for any microformatted goodness on pages (and make sure to use as much microformats code on my web pages as possible). I use Zotero to take extensive notes during meetings with project managers, and take notes on various sites I visit. I have a whole library devoted to “Web Design/Development” and sub-folder for specific projects.

Other Software

For all my coding, I use Textmate. Textmate is quick, straight-forward, and has exactly what I need to code websites. I’ve made a few bundles and snippets for Textmate (that I’ll eventually put on the server somewhere for download) that help me speed up my workflow a little, including personal CSS snippets, WordPress specific snippets, and Omeka snippets. I set up individual projects in Textmate, so I can work with all the files in a given folder I’ve devoted to an individual site, and keep those on my desktop. Additionally, the “Find in Project” feature in Textmate is fantastic, especially if I need to find instances of a specific function or line of code across a site (like a WordPress or Omeka installation).

I use Transmit for all my FTP needs. Its a slick little app, with a nice icon. Furthermore, I followed the instructions given by Muffin Research Labs to set up a Textmate project that will open files on a server in a tabbed interface. Quite handy, especially if you edit files directly on the server frequently.

For image editing and interface design, I use Photoshop and Illustrator, and a slew of brushes, patterns, and scripts. I make my own patterns and brushes frequently, and group brushes into packages to share with other CHNMers working on the same project. That way, we all have the same brushes and patterns to work with, which makes consistency in design a bit easier.

iPhoto—I browse a lot of CSS galleries like CSS Beauty, Stylegala, and CSS Mania. I take screenshots of sites I like, and store those screenshots in albums on iPhoto. In addition to whole webpages, I also take screenshots of specific components or parts of a site I like, such as lists, comments, headings, navigation, etc. We also tend to do a few diagrams at CHNM when discussing a site or application, so I take photos of those whiteboards and keep them in iPhoto to refer to later.

Adium—We frequently use chat clients at CHNM to communicate, so I have a special group for my CHNM buddies. I also have an additional group just for the design/development team.

Miscellaneous Sites and Services

I use Google Reader to aggregate all my feeds and keep them in one nice, tidy location that I can access anywhere with an internet connection. I have a folder just for design gallery sites, a folder for design/development magazines (A List Apart, Digital Web), and a folder for individual design/development bloggers.

I post “what I’m doing” to my Twitter account, and follow a few. Twitter’s great for getting notifications for interesting links, or for near “real-time” discussion among. The tweets published while debating IE8′s use of the meta tag last month was very interesting, and helped keep me informed about what debate issues were important for the web folks I follow. The Omeka team has been using Twitter very effectively to communicate with current and potential users, and post about updates, on Omeka’s Twitter account. CHNM and Zotero also have Twitter accounts.

So, there you have it! A digital humanist’s toolkit, more or less. This leans more towards the development side of my toolkit, but I hope you find it useful. What do you use?