Jordan’s War photo gallery (a critique)

This is the first in a series of posts I will make about Jordan’s War, an excellent multimedia package produced by Seth Gitner at The Roanoke (Va.) Times. The package made its debut in March 2006, which is when I first saw it.

I wanted to use this package as an example because it’s produced by a smaller news organization than the ones that get all the attention in multimedia, and Seth has been increasing his online staff (and his own skill sets) for a couple of years already. So what we see in Jordan’s War is a large, sophisticated work with many great features. Yet, like every multimedia package, it’s not perfect. So I’d like to write about what works well, what could be improved, and why.

(I know Seth has a thick skin, and he won’t hate me if I say something could be improved a bit.)

The story is about a young Marine cameraman who has served two tours of duty in Iraq. He got wounded and was sent home to Roanoke.

The photo gallery I’m looking at in this critique is separate from the main package. The photos (by Times staf photog Sam Dean) are great, and the captions are very good. Even with 18 photos in the story, it’s not too long; the editing is first-rate.

This is not a slideshow; it does not autoplay, which is okay. There is no audio either. You must go and click each photo thumbnail (10 above the display area and eight below) to change the image. This is a little tedious. It’s always nice to have Next and Back buttons (this gallery does not).

This made me think about “gallery” vs. “slideshow.” The random access via thumbnail images is nice, but since this set of photos works very well as a linear story, random access seems unnecessary. So I asked myself, “When does the user really want random access to a photo collection?” Maybe if the images aren’t closely connected to one another (examples: pictures of scenery, pictures of pets, “singles”). A photo story, however, is linear. If it’s well edited, it’s great to view it from beginning to end, without skipping around.

Lesson 1: Decide whether thumbnails really fit with the content. If viewing stuff in order makes good sense, do not provide thumbnails.

Next, I looked at the credits. It’s important always to have credits for every multimedia piece, and to have them inside the piece (not outside, in the HTML, where they might get detached from the SWF). This gallery has a prominent link to Credits (good), and when you click it, the credits open in the main image area. The trouble is, there’s no Close button. When you try to close the credits by clicking on them, an e-mail window pops up (which I didn’t want). The only way to close the credits is to open a new photo by clicking on it.

Have a look at how the credits work in another slideshow. You open them with the little question mark button (lower right). When they have opened, all other buttons and functionality are disabled. It’s easy to see how to close the credits. As soon as they have been closed, everything else functions normally again.

Lesson 2: Handle package credits in a manner that makes them easy to open and close at any time, without any confusion.

I had one other suggestion for the gallery page: In the lower right corner, there are two links. One goes to the home page of the newspaper site. The other goes to the main Jordan’s War package. Considering that someone might come upon this photo gallery without first having seen the Jordan’s War page (that’s the trouble with external pieces that open independently), it would be great to have a better connection than this to the main story. But at least there IS a connection — that’s essential.

The trouble is, there’s a small interface issue with these links. Because the two links are together on what looks like a single torn scrap of paper — and there is no rollover visual on either link — I thought it was just one link. So I clicked, assuming that I would go back to Jordan’s War — but instead, I found myself on the newspaper’s home page. Users don’t like that kind of surprise.

Lesson 3: When links do not give the user a clear message about where they will lead, the user may end up in the wrong place.

At 1000 pixels wide and 675 pixels tall, this SWF is really too tall for 1024 x 768 resolution. After I manually disabled my browser toolbars AND my status bar, I was finally able to see the whole thing without scrolling. But the user should not need to reconfigure her browser to enjoy your content. This is a common problem, but I was a little surprised to find it here.

In my browser, opened full size at 1024 x 768, I have exactly 590 pixels of height available for content. Other people (using different browsers, or just with different toolbars set up) may have even less space.

Lesson 4: To avoid making the majority of users scroll up and down in what was designed to be a single-screen experience, limit the height of your SWF to 500 pixels.

Technorati tags: Flash journalism | photojournalism | multimedia | online journalism | critique