|
|
 |
summary |
|
 Readers' free use of the Back button (and other key browser controls) is a serious menace to many forms of eliterature. |
|
Possible solution: launch your work in a window without browser controls - if that's possible. |
|
Readers routinely confuse content and navigation. |
|
Solution: Use iterative design (review, revise, review, repeat - as with shampoo) to make the two work together coherently and congruently. |
|
How-to-read-it information is a generous thing for a writer to provide, but its presence may completely blunt the mystery or drama of your work, plus studies show the majority of readers will pay it no attention. |
|
 Not a solution for eliterature: the currently faddish "transforming and transcending documentation" approach is called EPSS, which is so task-focused I refuse to describe it here. Reading / experiencing a work of art is a very special task, darn it. |
|
what I've learned: the full rant |
|
As of this writing (and things change fast so I have no title on my business card) I'm a product designer with Trellix Corporation, working on a new web application - what we used to call "software" except now users access it through their web browsers. |
|
Because of my current role, I've become obsessed with the usability problems people have with complicated-things-in-browsers, like much of the advanced eliterature being created today. |
|
David Reid, currently the design director at Lycos Williamstown (covering Tripod, Angelfire, and HTMLGear), says that the number one problem he sees is competitive UI. I asked him to explain this term to me; I'll modify his explanation for eliterature. David believes the browser controls themselves are very seductive to your readers and cause major problems. |
|
• |
They'll press "Back" often, as the fit takes them, whether or not you tell them they can or should. |
|
• |
They'll click "Home" in the browser toolbar when they want to return to the main page in the current work or site. |
|
• |
They'll click "Search" in the browser toolbar and assume the resulting search will find something in the current work or site. |
|
Maybe the term dueling user interfaces is better. Anyway, I've found this in my own studies too: the Back button is just terribly seductive. I bet your own usability experiments will find your readers using it a lot. |
|
To use examples from the work of my teacher Robert Kendall: the custom programming of A Life Set For Two was doubtless a lot of work. But the resulting work had the guarantee that, no matter where the reader clicked, something Rob had planned and could control would happen. |
|
Many of Rob's most recent works show off The Word Circuits Connection System. They can be richly experienced in a browser...but it has that darned Back button. If you plan to use the Connection System scripts and really don't want your readers to go Back, launching your art in a browser window with no toolbar seems well worth the work, based on my experiences so far. (Of course your own private usability reviews will confirm whether your work is being experienced as you intend.) |
|
You can also include how-to and documentary information that tells readers, "Don't go back or you'll blunt the full impact of what is to come and you'll be sorrrrry." But studies show that there are many profiles of readers who just don't read instructions, ever. Each of us learns differently and some of us (especially those of us who write it) just love documentation...but based on a pretty solid body of evidence, the majority of people just want to "dive in" and "see what happens." You need to see that too. |
|
Ooops, preaching again. |
|
I thought I had the "most typical problem" but David recently convinced me that this "dueling with the browser UI" issue was a more difficult and fundamental problem than the one I've been describing. |
|
Before he convinced me of that, I'd decided that the #1 usability issue for eliterature is that readers can't tell the difference between content (in a wide variety of media) and mechanisms such as navigation. |
|
I've seen this a lot. There's no quick fix. Iterative cycles of design (review, revise, review, repeat - as with shampoo) can help improve things. In my own work, after the first review I polish off the rough edges of mechanisms, the stupid things that I just forgot to fix, that either lead the reader waaay far afield or just knock her completely out of the work, like a thumb poked in his eye. |
|
Over the long term, within a cycle of multiple reviews and deepenings and intensifyings of a work, my goal is to make content and mechanisms hang together coherently and congruently. Or as Deena Larsen would argue, in a good hypertext, "structure = content = " (probably mechanisms too). How to do this is the art that I'm still developing (and interested in learning from others). |
|
For example, navigation and content have been elegantly fused in Janet Holmes' and Stephanie Strickland's design and implementation for Stephanie's poem The Ballad of Sand and Harry Soot. I believe Janet reported at DAC99 that she and Stephanie benefited from usability feedback, gathered under the auspices of trAce? - my notes on this are fuzzy. (Stephanie or Janet, feel free to write with corrections.) |
|
Anyway, I thought I heard that it was a usability review that helped this team decide to add the elegant row of 1's and 0's -- complementary to the poem's themes -- that run along the base of the reading window -- and that turn bright white once each page is visited. This mechanism is a good example of the benefits of refinement (vis-a-vis this problem of content vs. mechanism and can something usefully contribute on both levels - eeek!) through study of readers. |
|
Now, if you haven't yet, go experience the poem! |
|
Beyond the two "#1" problems I've described here, I am unable to generalize about problems you might find. Other "findings" (you can use this term if you're so inclined, it sounds so medical though) from reviews I've helped with have either been communication-related issues that are not particularly or uniquely electronic, or problems that are highly specific to the work being reviewed. |
|
I'm not sharing stories from reviews I myself have helped with, partly because the findings were private and partly because I fell in love with much of the work in the process and would just sound ridiculously biased. I'll save my paeans for a page that I would like to create soon: you must read the work of my friends, and tell everyone you know about it. (If you want to be advised when it's posted, send me email at home...also check the forthcoming ELO directory...) |
|
when are you done with a usability review? |
|
To quote another of my friends, Jared Spool, it's just like shampoo: lather, rinse, repeat. You know when your hair is clean; you know when you've learned all you can, or are so tired that your usability exertions are providing diminishing returns. |
|
And I expect that experienced artists, like my mother the sculptor who works with nine foot sheets of cast paper, has a sense of "when the piece has been worked over enough, or more than enough," that can serve as a guide also. Acquiring this is something I look forward to. |
|
Career update, Fall 2000: Our team has now shipped the product I was working on; it's available from a number of different communities. The Lycos Williamstown office has been absorbed into Lycos headquarters; rather than uproot themselves, David Reid and several members of his design team took their stompin' portfolios elsewhere...(if you're David reading this, drop me a line!). |
|
