Caveat Lector

Look, I am not a professional HCI or interface-design person, let’s just take that as read. If you want to watch the real experts go at it, I recommend Boxes and Arrows. I’m as much a design guru as I am a programmer, and I’m not a programmer. (Though our godly sysadmin has agreed to take on a small pair-programming project with me; if this keeps up I may actually start to suck less at programming.)

That said, let’s talk a little bit about what persona development like yesterday’s is intended to accomplish, and how that relates to where we are vis-a-vis design in repositoryland.

It’s really hard to put yourself in the mindset of “the user” when you’re trying to put a piece of software together. Working from standards or other specifications, that’s easy; the worst you’ll run into is linguistic ambiguity. But “the user”? Who the heck is “the user”? And that’s the point. There’s no such animal as “the user.” There’s various sorts of people who will be using your software. Persona development is an attempt to ditch “the user” in favor of a portrait that actually resonates, a concrete mental image that one can build a product or service design around.

Many design processes attempt to circumvent the “the user” problem with focus groups and survey research. This produces useful information—but with serious caveats. One, you can’t design for a statistic any more than you can design for “the user.” Two, you cannot rely on people to reliably introspect about (or even tell the truth about) their current or future desires. You just can’t. If you could, we’d all be designers! What you can, if you’re careful, get a sense of is what their current behaviors are and what their needs (expressed or un-, and they’re mostly un-) might be, and that information can and should fuel persona development.

We know a fair bit about researcher behavior vis-a-vis their research products; we really do. We also understand the landscape researchers operate in. This is all good, and I used my personal understanding of this realm to create Dr. Troia. But understanding is not quite enough; there’s one more small trick to persona development that I think illustrates where the repositoryland train jumps the tracks. Videlicet and to wit: a good persona is, insofar achievable, the typical case, as unextraordinary for the represented population as possible. The thinking is that if you design really well for a few mostly-typical cases (and yes, you’re allowed to throw more than one persona at a design problem, though you want to stop at five or so), what you come up with will more often than not handle your edge people too!

We have not been designing repositories for a typical, representative faculty member. We have been looking at physicists and computer scientists because they are self-archiving in huge numbers, and we have tried to imitate what worked for them. The catch, of course, is that most faculty aren’t physicists and computer scientists. They aren’t even like them; if they were, we wouldn’t have this self-archiving problem, would we? Physicists and computer scientists are an edge case. If we design for them, we lose everybody else.

So Dr. Troia isn’t a physicist or a computer scientist. Mutatis mutandis, she isn’t a flaky technophobe from comparative literature, either. (Everybody knows that potshot was at me myself, right? I have a BA in comp lit.) As best I could, I tried to make her what I normally run into, what I generally expect to see when I meet a new faculty member.

What does Dr. Troia need? Well, first, let’s look at what she doesn’t need. She doesn’t need increased citations. Sure, they’d be nice, but she doesn’t need them. She needs to get her work in the right journals with as little pain as possible. Similarly, she doesn’t need someplace to put her preprints and postprints; these are of so little value to her that she essentially throws them away. If we as repository designers and managers want those preprints and postprints, we’re going to have to get them as a byproduct of a system that does something Dr. Troia does need.

Worse yet, she doesn’t need to manage her copyrights; see above about the right journals. If we want her to (and we want to know when she’s done it), we’d better change her motivations or make copyright management an inescapable part of our systems. She doesn’t need a self-archiving mandate, either. We might like her to have one, but that’s not the same thing. She would comply with one if it existed (because she complies with everything she’s required to comply with; like most faculty, she is a pretty compliant creature where money and career prospects are concerned), but she would never suggest one, never fight for one, never even vote for one, because she does not need it and it represents additional work for her.

(I am reminded of the standard template for software-development projects: “1 Build code. 2 ???? 3 Profit!” Except here it’s more like “1 Say the word ‘mandate.’ 2 ???? 3 100% self-archiving rates!” The reason I fell in love with Minho’s solution is that they sensibly put “Bribe faculty” in slot 2.)

What Dr. Troia does need, and would immediately admit that she needs, is secure, networked, backed-up, maybe even version-controlled storage with access controls. Not (I cannot say this strongly enough) archival storage, because she needs to use it for in-progress work. But storage that had archival bolted onto the side with nice pointers about what to archive and when and how, that she might well use. Goes double if the system makes it easier for her to send her work to journals, or comply with data-retention or funder open-access requirements.

Do our repositories make any of that easier? Do they hell. They make it harder, and they don’t sweeten the pot by solving Dr. Troia’s other problems. No wonder all the Dr. Troias out there don’t use them.

I hope to write up a few more repository-related personas in the next week or so, and then (hello, Les) I can start talking turkey about repository system and service design.

So after my initial howl of horror at seeing what my nice new Manakin design looked like in Internet Explorer, I put the project away for a while. Okay, okay, I procrastinated, because I hate fixing browser bugs worse than you can possibly imagine.

Today I got back to it, and I discovered that I had inadvertently copied over all of the Manakin default design’s IE fixes into my new theme. Oh, well, don’t need those, I said, and got rid of them.

And all the display problems on the front page but one magically resolved themselves in IE7.

I feel ever so much better now. Still not looking forward to IE6, but at least I don’t feel quite so much a duffer.

The title of this post refers to the horrible noise emitted by a web designer on her first glimpse of the havoc wreaked by Internet Explorer on a design that works beautifully in real browsers.

(Though honestly, it could have been worse. I’m scared of what I’ll see in IE6, and as for IE5…)

The sad thing is, I’ve never installed a Firefox plugin for web developers before. Yes, I know, I know. I’m kicking myself, believe you me.

I installed Firebug the other day, because my Firefox profile managed to hose itself (grrrr) and I had to reinstall a bunch of plugins anyhow, so why not pick up a few new ones?

This morning, I had one of those horrible moments when you click on a perfectly innocent link in your new design and the resulting page is oh-noes b0rked.

Firebug found the problem within thirty seconds of my figuring out how to use it (which itself took less than five minutes). Isolating it on my own would have taken me hours of cussing and fiddling.

I have extolled xkcd’s feminist sensibilities before. I must say that today’s strip is both far subtler and far more refreshing.

(And funny. I cringed and laughed at once! As usual, don’t miss the tooltip.)

See, what happens (mild spoilers, so click over now if you’re going) is that a woman goes and does something highly technical as well as highly ironic.

And it’s not pointed out as unusual.

And she isn’t portrayed as unusual. Or undesirable. Or pure T&A. Or brainless. Or the butt of the joke. (If anything, the joke is purely linguistic/social, playing on specialized meanings of “write” and on the sillier things that women are “supposed” to commit to paper.)

More like this, please! And once again, a loud shout out to the extreme awesomeness that is xkcd.

So since I haven’t mentioned it yet, I’ll mention that I’m part of this NISO/PALINET day workshop on institutional repositories. (In my humble repo-rattish opinion, it’s a bit misnamed. I don’t know any rats who care nearly as much about getting something out of IRs as getting stuff into them! Anyway.)

My slides are due the 21st, so I have been getting my rear in gear to work on them today. And in so doing, I discovered a Keynote trick I probably should have discovered long ago but didn’t.

Sometimes it’s nice to replace one thing on a slide with another thing. You can do that by duplicating the slide except for the one thing that changes, but that’s sort of obnoxious. Keynote has a better way.

Put both things on the slide; it’s completely okay if they overlap. Then hit the Inspector button, and go to the Build tab (which is the yellow diamond with the speed-marks to the right). Pick the thing you want to go away, then do a Build Out with it. Pick the thing you want to replace it with, do a Build In with it, then make sure that the build-in starts either on click or after (but not with) the build-out. Sounds complicated, but do it once or twice and you’ll get the idea.

I’ve now got a slide of blue-sky myths about IRs, each one of which is blasted to smithereens and replaced by a reality check. I had much too much fun putting it together, which probably says things about my sanity that are best not examined too closely.

I’d dearly love to know just what the heck I was on when I wrote the code following. It must have been potent stuff.

			if file[0] == “.”: continue #no .DS_Store
			elif file[0] == “.”: continue #no .DS_Store

(This is in answer to the blogging prompt I gave my class this week, in case anyone is wondering why it seems out of left field.)

My dad, like most dads, took me to the office every once in a while, with all due stern caution about Sitting Quietly and Being Good. I believe it was on one of those visits that I saw my first acoustic coupler. Handset modem. You know what I mean (or maybe you don’t). Stick the telephone handset in the vinyl sockets. Earsplitting screeches ensue.

I may be one of the last people on this earth to have learned to type on a manual typewriter.

That was in the eighth grade, in Mexico. I didn’t actually type on a computer until a few months later, when our martinet history teacher back in the States demanded a letter-perfect typewritten double-spaced final paper. My dad sighed and took me to the office, where he introduced me to a Commodore 64 and something that might or might not have been WordStar.

Honestly, I can’t say I liked the thing very much. It wanted me to type weird two-letter commands starting with colons. Instead of black ink on white paper, I had to learn to get used to green phosphors on black. And it’s hard to get anything done when you’ve been adjured time and time again Not To Break The Expensive Equipment.

Times do indeed change. I make my living working with the equipment. I’m not afraid of it any more (… usually; kernel panics are legitimately scary). And I’ve become dependent on it to a substantial degree.

Dependent? But we’re not supposed to be dependent on technology!

Please. Go find a cave and live in it. If you can’t live without books, you’re dependent on technology. Can we get over the mistaken notion that technology is novelty and move on? Thanks.

Most of what I read these days, and nearly everything profession-related that I read, I read from a screen. Honestly, if ebooks weren’t DRMed up the wazoo, I’d read my pleasure reading that way too. With two cross-country moves in three years, never mind the trail of broken bookcases I’ve left in my wake over the years, I’m coming to the conclusion that the boxes of paper are more ruddy trouble than they’re worth. (But DRM is worse, so this is me not taking the plunge. Yet.)

Quite a few of my friends live online. My old college buddies. My roleplaying buddies. Friends I haven’t met yet. Just a moment ago a friend I haven’t met yet IMed to cheer me up because I have had a remarkably pointless and frustrating day. You know what? It worked.

Want a cliché? Here’s a cliché. I met my husband online. It’s the honest truth.

I keep coming back to Andy Clark. Buffle the MacBook, Nova the PowerBook G4, the Silver Surfer, they’re part of my brain. Without them, I am not whole; I could learn to live without them, but I would have to learn. Retrain my thought processes. Remember how to remember. Reclaim my handwriting, even. It’s a scary prospect.

That eighth-grader? She could never have imagined.

Woke up this morning, ate me some breakfast, and settled down on the couch with Buffle to get some work done. Fantasy read-alikes, this week’s class lecture, more on the ASIST poster…

Kernel panic.

Reboot. Kernel panic. Reboot again. Kernel panic. Try to reboot from the install DVD. Kernel panic. In desperation, hit up Google (from husband’s machine) and learn how to reboot into single-user mode. Do so. Run fsck, which comes up clean. Reboot. Kernel panic.

A very patient friend to whom I now owe substantial quantities of good booze reminded me about target disk mode and walked me through backing up my home directory to my husband’s machine. Crisis demoted to emergency, I tried the next trick: reinstalling OS X to Buffle in target mode from my husband’s machine.

In one of those brainstorms that always happens ten seconds too late, I realized five seconds after I booted my husband’s machine from Buffle’s install DVD that Buffle is an Intel Mac and my husband’s machine is a G5, and never the twain shall use the same install DVD. My husband’s machine promptly kernel-panicked, and wouldn’t restart from disk instead of DVD, either. Nor could I eject the DVD.

Just then, Buffle the Wonder-Duck earned its sobriquet. In desperation, I tried one more time to boot it, and it booted, and I slammed my husband’s machine into target disk mode and ejected the DVD. Husband’s machine fixed, I turned my attention back to Buffle the Wonder-Duck—

—which promptly kernel-panicked.

I hopped on the crosstown bus to Madison’s Apple Store and bellied up to the Genius Bar. The Genius on duty tried not to wince at the words “kernel panic,” tried a few diagnostics that didn’t work, and popped the case on hearing that I had third-party RAM installed. “Oh,” he said. “These aren’t even installed right.” He shoved them in, and lo and behold, Buffle was fine.

My weekend’s work is shot to hell, of course, so I’m taking the day off work tomorrow to get caught up. But three cheers for smart friends, the Genius Bar, and Buffle the Wonder-Duck!

I owe Dr. Peter Sefton an apology for not addressing him as Dr. Sefton here. Mea culpa, and I’m sorry; the error was inadvertent and no disrespect was intended.

I should also make clear that I’m rooting for ICE-RS and Lemon8, and that my still-significant reservations about their prospects have nothing whatever to do with the people building them or the quality of their work (which I have no grounds to evaluate—save past experience with similar tools—as I haven’t tested either package yet).

No, this is a problem that lives at the intersection between people and computers. I don’t believe that authors will always not use styles; I know better. But that, to me, is not the question. The question is “will enough authors use these tools (whether based on styles or not), and will they use them adequately enough, to base an efficient publishing workflow on their work?”

I ain’t seen it happen yet, is all I’m sayin’. My jaundiced soul believes right to the bottom of its toes that markup is an editor’s tool, not an author’s, not to mention that a lot of players have different text-structure needs.

But that doesn’t mean that ICE-RS and Lemon8 are useless. It’s not as though editorial tools are perfect! (Back in the day I made a suggestion or two about how to get these tools right for authoring. I don’t think anybody listened to me then, and I doubt anyone will now. The point is, there are advances to be made, if anyone is willing to think hard enough about them and able to implement them.)

I find myself in an odd rhetorical position here. Under most circumstances, head-shakers with their eternal “Tried that. Didn’t work. Won’t work this time either,” bug the living you-know-what out of me. And here I am being one, and I don’t like it. Sometimes things happen when it’s their time to happen. Maybe now is the time for word-processing–based authoring tools for markup. Who am I to say it’s not?

Except…

The head-shakers are often wrong because something’s changed in their environment that makes the New Thing feasible where it wasn’t before. Roy Tennant made this point the other day in a different context. I guess where I go off the rails on author markup tools is that I don’t see what’s changed in author brains or in the value proposition for these tools such that authors are going to climb onboard en masse.

Maybe I’m wrong. I’d love to be.