Caveat Lector

Every time I think “I can do this! And it won’t be hard!” about the DSpace redesign, something else hits.

We’ll leave out the 1995-era markup. I’ve dealt with that. (Mostly. I haven’t touched the admin pages yet, though I can tell I’ll have to.) Dealt with it: capitalized markup, unquoted attribute values, grotty tables and all.

(The unquoted attribute values really chap my hide, though. There are general markup best practices, even if you’re not chasing XHTML. Quoting your attribute values is one of ’em. I shouldn’t have to fix that kind of stuff, not in this day and age.)

We’ll also leave out the browser-sniffing hacks. (They’re still trying to code to Netscape 4. Watch me toss that requirement right out the window. It really is 2005, folks. Honest.)

I was hoping I could just overlay a new stylesheet on theirs. Yesterday I looked at theirs.

THEY DID FONT SIZES IN POINTS. In POINTS!

Hell with it. I’m redoing the whole thing, no matter how much cussing it takes me. There is a level of CSS badness up with which I shall not put.

I’ve seen some uneasy awareness in the DSpace roadmaps that there’s too much Java code in the pages. Well, there is, no question of that. What interests me is why there is. My somewhat-uneducated opinion is that they thought about DSpace in terms of pages, and the page was too big a unit for an ideal design to come out the back end.

“We need a page for X. What goes on it?” they asked, and merrily did they code away until the page did what they wanted it to. Thing is, that led to them coding the same stuff on several pages, differently on each page, and it also blinkered them a bit, in that they didn’t necessarily see how one gizmo could have been useful on several different pages.

Compare this to how blog software is developed—first you figure out the tags, then you build pages from the tags; if you need new functionality, you create a new tag. Some tags permit context-sensitivity, even, behaving slightly differently depending on what page they’re on. That’s how it should have been done. It’s harder to code at first, but it’s easier to document, more flexible to work with, and less crufty in the long run.

(Documentation? Hoo, boy. Paraphrased: “You can customize the look of DSpace by messing with the JSPs or the CSS.” Plus a cursory description of the most commonly-used tags—if you scroll down a lot—sans examples. End documentation. For real documentation of the tags, you’re supposed to go into the .tld file and read the comments. Yeah, that’s friendly. Mm-hm. I haven’t done it yet, so I don’t know if the comments are any good.)

They tried to go tag-based, I think; they just didn’t commit to being draconian about it the way the MovableType or WordPress people did. They are realizing their mistake now, as they consider how hard it’s going to be for people like me (who are doing some fairly hefty customizations—with DSpace architected and UI-designed the way it is, just cleaning up the markup or shifting the layout is a hefty customization!) to update their work when new DSpace versions come out.

I’ve heard Fedora people laughing up their sleeves at issues like this. I don’t know Fedora well enough to judge whether these particular issues were handled any better, frankly. (I suspect not, though. I don’t think any of these systems involved info-architects, HCI people, or markup experts from the get-go. Ronco Spray-on Usability, indeed.)

To some extent, this is life on the bleeding edge. I expect DSpace to follow the fabled software pattern of being really pretty decent by the 2.1 release. (It’s on 1.2 at the moment; 1.3 is around the corner, and 2.0 is being roadmapped.) Right now, though, it’s pretty frustrating.