Caveat Lector

After all the frustration last week, I solved the JScript/JSP problem in ten minutes this morning. Turned out to be a bit more fallout from that HTML-attribute-quoting regex.

How’d I find the problem? Pulled up my version of the Javascript file along with a clean version and ran a diff on them. Badabing-badaboom, there was the problem.

I felt amazingly stupid, but at least the problem got fixed. You see what not quoting your HTML attributes does? You see, now? You mess with the markup wonks’ heads, that’s what you do when you don’t quote your HTML attributes. (Oh, and I discovered that the supposed HTML 4 that DSpace emits… isn’t, in a couple of places. You can imagine how thrilled I am to find that out.)

Anyway, I then ran into another problem associated with this bug. For the record, the listed fix may not work if your first form is in a piece of the page that does appear in the Administer EPeople page but doesn’t appear in the e-person popup. Reason: the form with the buttons is the second form on the Admin EPeeps page, but the first form in the popup, so the JavaScript gets confused either way. (Surely there’s a way to name/address forms in JavaScript so as to avoid this problem?)

In my own case, I had a search form in the location bar, which did (note tense!) appear in the Admin EPeeps page, but didn’t appear in the popup. The fix, of course, is to kill the location bar out of the Admin EPeeps page, which I did. And then everything worked.

I wrote up this fix for the DSpace wiki, but it can’t hurt to post it here too.

My next fix: the abominable buttons on the submit-an-item pages (submit/progressbar.jsp, for those of you who know DSpace). As I explained somewhat incoherently previously, DSpace 1.2 had a series of small colored text-as-graphics that let a submitter know where s/he was in the submission process and which steps could be jumped to at this point in the submission game.

These text-as-graphics disappeared in 1.3, presumably because it’s impossible to internationalize text-as-graphics. (Nota bene, web designers: if you’ll ever have to internationalize anything, hunt down all your text-as-graphics and kill it.) They were replaced with buttons, identical buttons all the way across. No clue which button represented the step the submitter was on. Worse, buttons representing stages that were off-limits at that point in the submission process were not clickable, with no indication what the difficulty was.

Basic, basic usability: if it’s clickable, users will try to click it, ergo it should do something. Unclickable buttons are a wretched, terrible thing to foist on users.

I fixed it. I de-buttonized everything that shouldn’t ever have been a button to begin with. Via CSS, I turned the current step green, and non-reachable steps white with a grey border. I separated all the buttons with pipes, too, because to my admittedly not-brilliant eye for design, the buttons looked horribly crowded. It’s not ideal, but it’s miles and miles better than the default.

Final fix: moving the bitstream (file) listing above the fold on the simple item-display page. Again, basic usability at work: a goodly portion of the time, someone arriving at an item-display page is looking for the bloody files. They’re new information. They should therefore be displayed prominently, below the title (for recognition purposes) but above all the other metadata (which there’s a goodly chance the user has already seen anyway).

While I was at it, I got rid of the filenames from the item listing, because who cares? Nobody’s going to choose a file based on its filename. Moreover, if they can’t see the filename, they’re less likely to try to cite it (instead of using the handle as they ought to). If they’ve just gotta know the filename, they can hover over the link like everybody else who uses a web browser.

So I fixed four things today, and I didn’t break anything that I’m aware. It was a good day.