Caveat Lector

A lot of library-school students ask me wide-eyed how I learn what I know about computers and programming and miscellaneous stuff. When I tell them “Accidentally, sometimes because I had to, sometimes because I was just curious,” they look disappointed.

What? Do they think I can show them the Yellow Brick Road to library geekdom, like some kind of fat hippie Glinda? I can’t. There ain’t no such thing.

There are, however, six magic words. Be very careful with them; they are extraordinarily powerful.

You will be careful, right?

Okay, then. The six magic words are, “Hmmm. I wonder how that works?”

If you’re not sure how to get started with technology, use the six magic words on something you use, see used, or are interested in using. Blogs. Wikis. Databases. Regular expressions. OPACs. The Internet. A scanner. Your iPod. Whatever. “Hmmm. I wonder how that works.”

Magic. Seriously. Try it.

Just to add my voice to the chorus, Buffle the Wonder Duck has one of these cracks, too.

Two, in fact: there’s another one along the left-hand side about two-thirds of the way up.

As far as I can tell it’s a purely cosmetic problem, but I do think Apple should ’fess up.

Cassandra’s second problem that she thought Ulysses might help solve was the sad state of so many Basketology faculty’s home pages. Out-of-date, incomplete bibliographies (or none at all) litter her landscape, often on static pages designed sometime in the late ’90s, with all the design sense that implies.

The less work Cassandra and individual faculty have to put into keeping those pages up, the better. Cassandra doesn’t have time, and faculty don’t have inclination—faculty agree that their public face is very important, but that doesn’t mean they’ll do anything about it!

It’s no coincidence that “file-less items” are the most common newbie request to the DSpace technical lists. It’s no coincidence that Les Carr has got tens of thousands of records but only a few thousand actual files. People are trying to solve this problem, for any number of reasons!

So what to do?

There’s a pretty good argument that this is not a repository function. A repository archives documents, QED. Fine, but that doesn’t get the repository off the hook; the repository should be providing data for these pages and reports at the very least. RSS feeds are nice for updating this sort of information, and a lot of repositories offer feeds already, so that’s a start.

But one more time, RSS is not enough. For Cassandra and the Basketology faculty, it’s too hard and it doesn’t do enough. Cassandra and Dr. Troia want an up-to-date list generated on-the-fly whenever somebody hits one of the faculty websites. And they want that list to live in their webspace, not Ulysses’s. Dr. Troia would be thrilled to pieces if she could also come by a neatly-formatted word-processed list for her annual activity report.

In Achaea’s ideal world, I think, the repository (or, for repository purists, a service overlaid on it) would track faculty publication activity, including materials not deposited in the repository. If this service were BibApp-y, it would be able to derive at least some of this information from RSS search feeds from appropriate electronic article databases. There would then be a Javascript include gizmo (not unlike Feed2JS) that would kick back a nicely-formatted HTML listing, based on a RESTful API that more ambitious programmers could do more ambitious things with.

The respectful repository or overlay service also offers COinS to play nice with Zotero. (I’m working on this for Manakin; haven’t gotten it quite together yet. I still hate OpenURL with an all-consuming passion.) I don’t know offhand what is needed for repositories to play nicely with (*spit*) RefWorks, but whatever it is, it’s worth doing. Both of these are steps on the way to Dr. Troia’s nicely-formatted annual activity report, although the adventurous Achaean programmer should learn to write out RTF and ODF—yes, unfortunately both.

Most of this isn’t hard. Why haven’t we done it yet?

Just about a decade ago now, I read my very first markup book. Fortunately, it was a good markup book, lucid and understandable. At that point in my orbit, I could have been scared off. I wasn’t. In large part thanks to that book, I became a tolerable designer of DTDs.

That book is now online, and by gosh, it’s still lucid and understandable. Even if you don’t write DTDs any more (and how many of us do?), it’s a fine, fine resource for how to think about text modeling.

I’m happy to see it again.

Now that I have personas, I can actually talk about repository design.

Well, sort of. I do want to talk out-of-band about a couple of the personas first. Les Carr pointed out to me in email that Ulysses is a bit of a luxury item; a lot of libraries combine him with Menelaus. This is absolutely true, and I was considering building a persona on a satellite campus to reflect that reality. However, the “maverick manager” model exists too (I’m one, and the model applies broadly to consortial repositories), and my suspicion is that the more complex solutions that work for the Ulysses/Menelaus division will also work for institutions where Ulysses and Menelaus are the same person. So for now I’m going to stick with what I’ve got, reserving the right to revisit that decision later.

Something else to notice about Ulysses is that he is also a stand-in for libraries that outsource the repository IT to vendors. They’ll face many of the same functionality and responsiveness problems that poor Ulysses does.

If you’ll recall, Cassandra Athens wants to use Achaea’s repository for two things: to export the problem of potentially-copyright-violating faculty postings to Ulysses, and to form automatically-generated CVs for faculty websites. Let’s talk about the former problem first.

Since Cassandra isn’t stupid, she has probably set up her CMS to have an upload area, disallowing any other way for faculty to put random files up on the Basketology website. (And Dr. Troia and others probably howled about it, but so it goes.) Faculty have two options: they can use Cassandra’s uploader, which Cassandra would vastly prefer they do, or they can put their files someplace else and link to them from the Basketology pages they control, which lands Cassandra right back in the quagmire she’s trying to escape from.

Some social engineering will be required here; Cassandra may well have to go to the chair of Basketology and make a stink about copyright liability. She’ll be much happier about doing that, though, and the chair much happier about dealing with the problem, if Cassandra has a workable alternative to propose.

The design goal, therefore, is to have Cassandra’s CMS talk to Ulysses’s repository such that faculty find it easier and safer to use Cassandra’s upload mechanism than to bypass it—without adding significantly to Cassandra’s ongoing workload. (Ulysses has time to throw at this; except for a few up-front development and testing cycles, Cassandra doesn’t.)

“SWORD!” you may be yelling at me at this point. No. SWORD won’t work, because SWORD more or less assumes you have a nice tidy well-described object to swap around. At most, Cassandra can squeeze a file and a (badly-formatted unpredictable text) citation out of faculty; sometimes they won’t even bother pasting in the citation. Moreover, SWORD is a difficult target for Cassandra to program against, and her CMS doesn’t natively deal with it.

She needs to be able to tell her CMS to email or FTP the file, the CMS’s identifier for the file, and what little information it has about the file somewhere; her CMS needs to receive the item’s handle or other permanent identifying URL in return along with the CMS’s identifier, so that she and/or faculty can link to the item in the repository easily.

This problem can be solved in several ways. Many people reading this will doubtless come up with better solutions than I could. If you do—no fair changing the design constraints, do you understand me? The design constraints are the whole point of this exercise. If your solution doesn’t work for Cassandra, it doesn’t work at all. (You think I’m draconian about this? Read Alan Cooper.)

Ulysses needs the repository to receive the CMS’s email or watch the FTP folder it has been told to watch, and to notify him that Cassandra’s CMS has fired a file at him. He then rights-checks the submission, applies metadata liberally, arranges for licensing, and (assuming that all checks out) sends the item live, whereupon the repository knows to notify Cassandra’s CMS. Ideally, the repository would even construct and shoot back a pretty, properly-formatted HTML citation! None of this can involve Ulysses interacting directly with the repository server, because Ulysses isn’t allowed to do that.

I repeat: This problem can be solved in several ways. Many people reading this will doubtless come up with better solutions than I could. If you do—no fair changing the design constraints, do you understand me? The design constraints are the whole point of this exercise. If your solution doesn’t work for Ulysses, it doesn’t work at all. (Seriously. The Inmates are Running the Asylum. He means you, software developers.)

A few DSpace-specific notes. DSpace’s per-item licensing paradigm is all wrong, and I suspect it shares this problem with EPrints, because the root of the difficulty is the OAIS model, in which rights information must be tightly associated with the object to which the rights pertain. This is great for the OAIS model, in which happy little computers talk to other happy little computers, but it’s a disaster for any kind of ongoing interaction between actual people and the repository, as Ulysses’s paper-license insanity illustrates. (That, by the way, was drawn directly from a real-world situation. I refuse to point fingers; you’ll have to take my word for it.)

A Terms of Service agreement is a much human-friendlier solution; Dr. Troia can be told to go click through it, and after she does, neither she nor Ulysses has to be bothered with licensing, and the repository can be smart enough to put the correct rights information in each item. For third-party deposit, Ulysses might have to indicate which author is to be considered the licensing author—but honestly, the repository ought to be smart enough to check the author list against ToS signatories, and let the deposit go through if even one author has signed.

(The repository must also allow for un-signing of the ToS; the obvious use-case is a faculty member leaving the institution. This cannot be allowed to affect previously-deposited items, but it should halt deposit of future items that depend on that faculty member’s consent.)

DSpace’s other major problem is its unwieldy workflow system, which doesn’t really cover the use-case just expressed. DSpace doesn’t even kick an item into the workflow system until it’s been uploaded and all the metadata is complete, which is exactly bass-ackwards from what Cassandra and Ulysses need it to do. Ulysses needs a staging area where Cassandra’s CMS can dump stuff until he can get to it. DSpace doesn’t have that.

There are other minor nits. The reject notice for an item that doesn’t pass a rights check needs to go to the corresponding author(s), not to Ulysses. DSpace needs an external-facing notification mechanism more sophisticated than email. Ulysses needs to be able to shove Basketology off on Menelaus, once everything is running right and Menelaus has learned how to check rights—Ulysses can’t possibly handle the entire campus doing as Cassandra has done, because there aren’t enough hours in the day. All of this is solvable, some of it trivially.

So. Let’s get to work? I hear there’s a repository-programming event coming up…

This is another in my series of personae related to institutional-repository development. Previous personae include Menelaus Fox, Cassandra Athens, and Dr. Helen Troia.

This entry requires a somewhat stronger disclaimer than the last few. Ulysses Acqua is not me, not even a thinly-disguised me. (For one thing, I’m not typical, and Ulysses is as typical of what I call the “maverick manager” class as I can make him. For another, Ulysses is a lot more sympathetic a character than I am.) Achaea University is neither the University of Wisconsin nor George Mason University. (For one thing, Achaea’s librarians are tenure-track, and I’ve never been.) I’ve been a repository-rat for two and a half years; I’ve heard a lot of stories, talked to a lot of repository managers, read a lot of books and articles and pondered their subtext. All of that, in addition to my personal experience, informs the portrait of Ulysses Acqua.

One more note: This portrait is limited to aspects of the repository-manager’s job relevant to repository software design. Ulysses also faces serious institutional and social barriers that I’m not talking about, because they can’t be developed away. For those, read Roach Motel.

Ulysses Acqua was hired six months ago to take the reins of Achaea University’s new institutional repository. The planning process for the repository had gone completely by-the-book; his job description reads as though it came straight from SPARC. Unfortunately, the book Achaea University was reading from didn’t say anything about pilot projects or signing up participants before the repository opens. Ulysses walked in the door to an empty repository, no plan for filling it, and no further contact with the repository-planning working group, whose charge was fulfilled when the repository-librarian job ad went out.

Ulysses doesn’t have to do the systems-administration work involved in running the repository; that’s handled by campus IT. At first, Ulysses was relieved by this, because he isn’t fluent in Unix or SQL or Java. A few months into the job, though, he discovered a great many things that he simply can’t do because he doesn’t have server access, from batch ingest to metadata quick-fixes to doing something about the repository’s hideous sore-thumb visual design and confusing interaction patterns. When he talked to campus IT about this, he got a runaround; the library is only paying campus IT to install and maintain the repository, not customize it or develop for it, and librarians are never given command-line server access because of security concerns. When he brought this barrier up with his supervisor, he was told that he’d have to live with it, because the library can’t afford to jeopardize its good relationship with IT, and certainly can’t afford to divert funds into repository development. Maybe next fiscal year, if the repository deserves the expenditure. Ulysses walked out of that meeting muttering something about chickens and eggs under his breath. Why hadn’t the planning committee foreseen this need?

He is frankly embarrassed by how ugly the system is, and how little it does; he finds himself apologizing for it constantly. Can he show statistics by author and item? No. Can faculty edit items they’ve ingested? Um, no. Ulysses explains that the repository is an archival system. Faculty shrug. They don’t need an archival system; they need somewhere to stash their stuff, including stuff they’re still working on. Does the repository take learning objects? Not really; it’s not set up for the right kind of metadata. Can it preserve the dynamic, database-backed website one faculty member’s image collection lives in? No. What about a straightforward image collection? Sure, but the browse process is painful and can’t be tweaked. What about TIFF page images from a scanned book or article? Yes, but again, there’s no good browse interface for them, never mind OCR. What about a CGI calendar application? No. What about a journal run? Sure—but it can’t easily display articles by journal issue without the overhead-heavy process of creating a new collection for each issue. Can it connect items with other items? No. Can it connect material ancillary to a published article with the article it pertains to? No.

Deep breath. Onward.

Can it produce CVs or departmental-activity reports automatically? No. Can it be tweaked so that the Basketology collection looks like the Basketology website? No. (The software can do that, in fact, but Ulysses can’t.) Can it talk to campus IT’s file-storage-cum-website servers? No. Can it harvest faculty articles from disciplinary repositories? No. Can it deliver records straight to Achaea Library’s catalogue? No. Can it have access controls per item, such that items are shared with specific people only, with the list controlled by the depositor? No. Can it embargo items, for a certain length of time or indefinitely? No. Can it read a citation, check rights on the journal, and go fetch the paper if rights are cleared? Dream on. Can it restrict items for campus-only access by IP address? No. Does it talk to RefWorks and Zotero and similar bibliographic managers? No. Does it do version control? No.

In short, there are quite a few campus functions that Ulysses and his repository can almost help with—he’s talked with endless faculty, and lots of academic staff like Cassandra Athens—but “almost” isn’t good enough for anybody, and the repository (he is told by campus IT) isn’t easy to mash up with other services, or develop on top of. He wishes he could do better; Ulysses sees real needs going begging, and he likes to be useful. With no developer talent available to him, shackled to a hopelessly inadequate tool, he doesn’t know how he can.

In the early days of his job, Ulysses brought up his use-cases on the mailing list for the software his repository runs on. Mostly he was ignored; once one of the developers insulted him for his lack of technical expertise, since what Ulysses wanted was apparently possible if he had server access to tweak some settings. Ulysses doesn’t bother writing to that mailing list any more, and his email client filters its messages to their own folder and automatically marks them read—there’s nothing there that can help him.

The licensing process is another major headache for Ulysses. He went down to University Legal shortly after he started his job, since the planning committee hadn’t done this part of the planning for him. He was told that any license had to have two signatures on it: that of the person licensing their content, and that of someone with signature authority for the university. Who has that? Achaea’s dean of libraries. In practice, this means that Ulysses has to get a license signed on paper for any item that Ulysses ingests on behalf of a faculty member—and frankly, that’s almost all of them! The irony of paper licensing for a digital repository isn’t lost on him, you’d better believe! He keeps a file of these paper licenses, since there’s no way to make the repository cognizant of them. If the library building he works in burns down, oh well.

The overhead involved in getting faculty ready to deposit is another stumbling-block. A faculty member told that he can put stuff in a digital archive signs up to put stuff in a digital archive! He doesn’t sign up to create “communities” and “collections,” whatever those are, and he’s certainly not going to wait (not even ten minutes!) while Ulysses scurries around behind the scenes getting him deposit privileges. Ulysses reads Jakob Nielsen, so he knows to say that his “conversion rate” is completely dismal. Not that there’s anything he can do about it.

Although he believes strongly in the open-access movement and is convinced that over the long term it will change the way researchers and libraries do business, Ulysses has to face facts: Achaea’s repository isn’t going anywhere and isn’t likely to, and that has serious repercussions for his still-young career. He is scrabbling together articles and conference presentations at a great rate (in areas of librarianship having nothing to do with his actual job) in hopes that notoriety will placate the tenure gods. He is also looking seriously at jobs in library website management, instructional technology, and grantwriting, as well as considering further training in scientific data curation.

Placed as he is, what else can he do?

This is another in my series of personae related to institutional-repository development. Previous personae include Cassandra Athens and Dr. Helen Troia. Menelaus is a fabrication based on experiences I have had and people I have talked to.

Menelaus Fox is a collection-development librarian at Achaea University; Basketology is one of the several departments whose library collection he is responsible for. Every semester, Menelaus canvasses those departments’ faculty asking what books he should acquire and what journals he should consider subscribing to. Response is at best mixed; many faculty never answer at all, though Menelaus values the easy, collaborative relationships he has developed with a few, such as Dr. Helen Troia of Basketology. Menelaus spends a lot of time skimming publisher catalogues, book reviews, local faculty CVs, and other sources of information to make the Basketology collection the most useful it can be; he also reviews books in his area that come in via publisher approval plans, to make the final acquisition decision.

Menelaus also handles specialized and in-depth reference questions for the departments he serves; he has even been listed as coauthor on one or two Basketology publications by grateful faculty. When Basketology comes up for reaccreditation, Menelaus will write the report section on the library’s Basketology holdings and Basketology-related services.

Achaea University librarians are on the tenure track, and Menelaus is not yet tenured, so he somewhat reluctantly spends some of his time researching and writing articles for publication, as well as serving on two library-association committees, one for the state library association and one for ALA. Add to that all the usual library group work—search committees, Librarians’ Assembly, outreach committees, monitoring the Faculty Senate on behalf of the library, et cetera—and the occasional reference-desk shift or instruction session, and there just aren’t enough hours in Menelaus’s day.

Menelaus’s time crunch became all the more acute when a collection-development colleague retired and her budget line was removed from the collection development department to allow for the hiring of something called a “Repository Librarian.” Menelaus has nothing against the man they hired, Ulysses Acqua, but the loss of a position hurt his department badly; several of his colleagues are even more hurt and resentful than he. He won’t say so, but the shift in hiring priorities worries him. Is what he does still valued by the library and by Achaea University? Or has everyone gone off the digital deep end?

It’s not that Menelaus is technophobic. He adapts; he has to. When ordering went electronic, when book reviews went online, when he had to learn to evaluate online databases for quality, he adapted alongside his colleagues. He even likes instant-messaging, as it saves him a lot of pointless phone-tag. But librarianship began with the book, and it’ll live and die by the book—all this digital stuff won’t last past the next natural disaster, and then we’ll all value the printed word as it deserves.

Menelaus isn’t quite sure what to make of Ulysses and the service he runs. He isn’t even sure what Ulysses does all day; they didn’t have digital repositories when Menelaus was learning his profession. He understands all too well that journal prices have gone completely beyond insane (when Elseviley bought the American Journal of Basketology its price doubled almost instantly, and hasn’t stopped rising since), but he doesn’t see how a website is going to make a difference.

He’s looked at the site. It’s ugly; the mid-1990s want their web design back! It doesn’t look anything like the library’s regular website, either—what, does Ulysses have some kind of problem with the library? There isn’t much in it: some technical reports, a podcast or two, one or two retiring faculty putting their entire CV’s worth of publications in. A few hundred items, no more. Menelaus isn’t impressed, and that’s before one mentions the unbelievably pathetic cataloguing. He heard somebody in Tech Services sneer about that the other day, but he didn’t mention anything to Ulysses, because Ulysses is a decent enough fellow, earnest and very much invested in what he does. Whatever that is.

At Ulysses’s polite urging, Menelaus tried bringing up “open access” at a Basketology faculty meeting. It went over like a lead balloon, and Menelaus hasn’t made another attempt. Ulysses asked him about putting his own publications in the repository too, but Menelaus courteously put him off. It’s not like Menelaus doesn’t have plenty of other things to do, and he sure isn’t hearing any urgency from library management or faculty outside the library on this score.

He’s just going to wait and see.

This is another in my series of personae related to institutional-repository development. The first persona is Dr. Helen Troia. Cassandra is a fabrication based on people I have met and problems I have tried to help solve.

Cassandra Athens is the webmaster for the Department of Basketology at Achaea University. She isn’t only the webmaster, though that is her title because it sounds good; she also does some hardware and software purchasing for the department as well as a lot of highly-unofficial technical support that eats up much too much of her time. Since she does a little bit of everything, Cassandra’s technical skills are broad and shallow rather than narrow and deep; she has to jockey Apache as well as Dreamweaver, MySQL as well as Photoshop, elementary Javascript as well as elementary CSS.

After months of meetings and private cajoling, Cassandra succeeded in convincing Basketology to move from their existing set of haphazard unmanaged web pages to an open-source content-management system. Cassandra hopes this will empower faculty to do some of the website-maintenance work themselves, instead of emailing her whenever they see something wrong. She’s not entirely sanguine about this—in her experience faculty don’t take ownership of the departmental web presence no matter how easy she’s tried to make it—but lowering the barrier can’t hurt, and the new CMS should make Cassandra’s job easier too.

While Cassandra was migrating existing faculty websites to the new CMS, she noticed something troubling: several tech-savvy Basketology faculty have been posting their research papers to their part of the departmental website. Cassandra isn’t at all sure that’s legal, and she worries that if there is a copyright-related incident or lawsuit, either the department or (scarily) the legal system itself will make her the scapegoat, since she runs the server. When she asked about this on the Achaea University general-technology mailing list, a librarian named Ulysses Acqua (yes, upcoming persona) told her that most (though not all) of the faculty postings were actually legal, though she didn’t entirely understand his explanation.

That was the best Cassandra could do, so she let it go. If she took down the papers unilaterally, Basketology faculty would be furious, and she isn’t sure she could explain the problem well enough (especially given Acqua’s contention that what faculty were doing was mostly legal) to content them. She knows she doesn’t have sufficient understanding to tell which postings are legal and which aren’t—and anyway, “copyright cop” is not in her job description.

Mr. Acqua offered to help her move those papers that could legally be posted into a service that he runs, but that represented a lot of work for Cassandra, who knows that faculty won’t redo their links so she’d get stuck with the job. Anyway, Basketology faculty would just keep posting new papers to the department’s webspace instead of Mr. Acqua’s service, so Mr. Acqua’s kind offer won’t actually make the problem go away. If Mr. Acqua’s service could somehow be integrated into her CMS, that might be something, but Mr. Acqua told her sadly that the software his service runs on isn’t set up to do that, and he doesn’t have a software-development budget to make it do that.

What Basketology faculty really want for their individual web pages is a comprehensive, current listing of their publications and professional activities. At first, Cassandra thought Mr. Acqua might have a solution to that. Unfortunately, Mr. Acqua’s service can only make records when it is actually taking in files, so faculty listings based on it wouldn’t be comprehensive. Worse still from Cassandra’s perspective, the service’s listings reside outside the Basketology webspace and just don’t look like part of Basketology’s carefully-designed web presence, so Cassandra can’t outsource listing creation to it. It’d be great if she could, because the chair of Basketology is making loud noises about raising Basketology’s profile on the wider web, and a big part of that is keeping faculty-activity listings current. Faculty nod their heads when the chair expresses this need to them—but they won’t lift a finger to do it, in Cassandra’s experience. Cassandra herself simply doesn’t have time; faculty submit their yearly activity reports in word-processed files, the conversion or cut-and-pasting of which would be a nightmare.

Now and then the copyright problem keeps Cassandra awake at night. She doesn’t see a viable way out, however, so she waits and watches and hopes nobody decides to try to make an example of Basketology.

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.