the pathetic caverns - books

Jennifer Government starts off as a vicious anti-corporate satire. It's set in a world where people's surnames are those of their employers and where the police charge money to solve crimes (and contract work out to the National Rifle Association). Barry is daring enough to use the names of real entities in his fictional environment (as he did in his first novel, Syrup). In the first few pages a Nike marketer arranges to have several customers murdered to boost the street cred of a new line of athletic shoes.

But Barry doesn't define for the reader the rules under which his brave new world operates (or even make them consistent). As a result, the novel founders somewhat after its snappy opening. It turns out that bumping off your own customers isn't really business as usual, and this revelation has the effect of undermining the book's satirical impact. (After all, bumping off the customers is already business as usual for the tobacco industry in reality — it's not that much of a stretch.)

Barry also doesn't seem quite sure how best to exploit his hypercapitalist setting. He winds up interleaving four rather tired plot threads. It's action-movie sort of strategy -- throw a lot of balls in the air, and hope that the reader spends too much time tracking them to think about plot holes. (Unsurprisingly, Jennifer Government has reportedly already been optioned; I can hear the voiceover already: "If you you liked Fight Club, you'll fall in love with Jennifer Government.) Barry proffers two rather lackluster boy-meets-girl stories, some high tech corporate sabotage, and a manhunt/chase that's hampered both by trite backstory and a reliance on tall coincidences, like mistaken identity between two similarly-named sharpshooters.

Strong characterization can compensate for a predictable plot, but Barry's people are shallow. The boys who meet his girls, Hack Nike and Buy Mitsui, are especially bland, feckless, and nearly interchangeable. The leading women, especially the titular Jennifer, have a little more spark, but are still thinly developed.

Jennifer Government is only Barry's second novel, but its thematic similarities to Syrup are obvious, and it's plagued by some of the same weaknesses. Jennifer Government isn't terrible. It's fast-paced, with servicable prose and dialogue. It's entertaining and mildly suspenseful. But I found the book profoundly unsatisfying; I think with some significant rework it could have been far stronger. It could have stuck to its satiric guns and eschewed pat resolution. It could have been leaner and meaner -- Barry perhaps has too much compassion for his protagonists, and Jennifer Government adheres a little too closely to Hollywood's rules for what befalls characters. I wish Jennifer Government had gone for the jugular, but unfortunately she was defanged.

Background

The Pathetic Caverns started as a personal web site in 1995, and evolved into an entertainment web zine over the next 2-3 years. I'd been a programmer for 10 years (developing what is now known as "e-learning") when I started the site, and during that time I was becoming more seriously interested in usability and interface design issues.

By 2004, I had substantial experience designing and usability testing interfaces for professional clients, but this site was still plagued by issues that most professionally-developed Web sites had solved years before. Perhaps even more seriously, it retained organizational quirks that were holdovers from its metamorphosis from a personal site into a web zine.

On 1 April 2004 I cleaned the slate and relaunched the site with a new design heavily influenced by some of the accessibility consulting work I'd been doing for corporate clients. I'll refer to that launch as "Pathetic Caverns 2.0."

At the same time, I started reading (or re-reading) a number of books on Web design and usability issues. I wanted to formalize my understanding of usability principles I'd learned "under fire" and expose myself to some new concepts. I also wanted to validate the pathetic caverns redesign, and address any new deficiences I identifed.

---

The first book I read as part of this effort was Bob Baxley's Making the Web Work. It deals with "Web applications," not "Web sites." Strictly speaking, Pathetic Caverns doesn't qualify; Baxley defines a web application as a site that has user-specific or user-customizable behaviors (usually requiring some kind of login). At present, Pathetic Caverns has no such features. But it does have a considerable volume of content, and Baxley's book has interesting discussions on how to determine appropriate organizational models for content. (Baxley deliberately avoids the term "information architecture," which he feels has become confused, but it is the term I would apply for much of the book.)

His overall thesis is that a web application can be broken into 3 strata:

• structure, comprising:
  • conceptual model
  • structural model
  • organizational model
• behavior, comprising:
  • viewing and navigation
  • editing and manipulation
  • user assistance
• presentation, comprising:
  • layout
  • style
  • text

Everyone who's developed sites will see where this is going: many teams immediately want to jump into presentation issues, which have the least impact on usability, and are the most easily altered -- but also are perceived much more immediately by users. Baxley's 9-layer cake is redrawn several times throughout the book to demonstrate how different types of Web applications require varying balances of these elements, but throughout he maintains an emphasis on keeping the horse well in front of the cart.

As I was reading Making the Web Work, I realized that I'd made an obvious and serious mistake in laying out the navigation of the site in a way that required rethinking some of my organizational model. I'd already taken the "search" feature I'd hacked up in Perl in 1996 offline, because I was convinced it was worse than useless. I also knew that much of the site's traffic comes directly from search engines. The 2.0 release of the site had alphabetical browse by author/editor, film title, and musical artist, but that was it. There no way to identify content logically related to a given review. Worse, while the alphabetical list was fine when then were 3 or 4 entries on a page, it would become increasingly unwieldy as the amount of content grew.

As a quick fix -- knowing it wasn't ideal -- I added a "Browse by Genre" tab and wrote a script to generate indices from genre tags I added to the files.

Baxley also called into question my structural model -- he specifically cited grouping content by physical media categories like books, CDs, and videos (as I do) as a problematic case. He argues that there is ambiguity as to whether a music video would be best filed under music, or under video. Ultimately, I don't agree. I include crosslinks where I think they're appropriate, but I think of my structure as a bit like a media superstore: when you're in the music department and realize that an artist has a video release as well, you usually need to walk over to the video department to pick it up. I can facilitate that "walking" with an "also see ..." link. I don't think it's a killer issue.

Finally, Baxley's book prompted me to spend time thinking about the two aspects of my site that could turn it into a true "Web application": its search engine, and the question of static vs. dynamic pages.

• I realized quite a while ago that a bad search engine is literally worse than useless. There were a number of strategies I could use to implement search, but I grew concerned that the time (or financial) investment would be prohibitive (and the ROI uncertain). I punted, adopting Google's search-within-site feature to take over the work for me until I could find the time to craft an effective solution.
• The other question was whether I had reached (or would soon reach) the point where an actual content management system made more sense than a toolset for manipulating individual Web pages. This was brought up rather forcibly by the time I had to spend tagging pre-existing reviews with genre codes -- a task in many ways was better suited to a database content repository approach. I decided to stay with the static site for the near-term future. Primarily, I want to make it as easy as possible for search engines to index the site, and for third parties to link individual pages, since I'm aware that a large percentage of my traffic comes from search engines (and deep links from external sites). The static page approach also minimizes the load on my server. But at least I was prompted to think about the issue and actively make a decision, rather than passively continuing with my previous policy. That decision -- "stay the same for now" impacts ongoing decisions for site maintenance, which are now focused to support eventual migration to a content repository approach.

Reading Baxley's book had a clear impact on my site. I like to think I would have recognized those deficiencies on my own, but there's little doubt that Making the Web Work speeded up the process. It's perhaps worth mentioning that Baxley spends considerable time laying groundwork, and the first few chapters may be a little disappointing to those who've already done some reading in the field. My personal recommendation is to stick with the book. My initial impression was that it was a little facile and obvious despite good organization; but as Baxley got deeper into the topic (and particularly into his detailed walkthroughs of what he thinks is right/wrong about several sites), I felt the book had a lot to offer.