[Dspace-general] Week 5: Submission process

[Dorothea Salo]

Running on 1.4.1, with an upgrade to 1.5.1 in our too-near future...

> This week's question is about the DSpace submission and workflow
> process. What works?

I was able to set up a new community and collection and deposit a
video on the spot with the content-owner watching. There is just no
way this is not cool.

Curiously, I have found that would-be depositors expect the process to
be much more involuted than it actually is. I'm not sure why this is
or what to do about it, but it's so. (One contributor may be the sheer
number of screens indicated across the top, perhaps? A percentage
indicator may be friendlier.)

> What doesn't?

The first screen with ticky-boxes on it. Please can we slay it? With
extreme prejudice? The two-titles question applies in a vanishingly
small (as in, approaching zero) number of cases, the published-before
question creates really nasty externalities, and the multiple-files
question is simply unnecessary. The cognitive load for reading and
then answering these questions is substantial, for a minuscule
benefit. I am *more than pleased* to add title.alternative,
date.issued, and citation fields into input-forms.xml for those
collections that need them, if it gets rid of this infernal screen!

I think Manakin may have fixed this, but the metadata-input screens in
1.4.x JSPUI do not indicate which fields are required. Should be an
easy fix, no? Without this, the depositor leaves something out, gets
slapped for it, and then justifiably feels annoyed that DSpace didn't
tell him he had to put it in in the first place!

In the workflow process, the "Take Task" and then "Accept Task"
interaction is unnecessarily redundant. Epersons who "take task"
should be taken directly to the "perform task" page; if they decide
they don't want to do it, they can "return task to pool." This
refinement would save me personally hundreds of clicks and
page-refreshes a year (and a lot of grumbly annoyance).

Suggestion: The "verify your work" page layout is confusing and (in my
experience with depositors) easy to overlook. I suggest instead that
the depositor be presented with the page as it will appear in DSpace
after deposit, because that they *care about* and will examine
carefully. If development corners need to be cut, just present the
page as a logged-in user would see it, with the "Edit" button and a...
hm, having label aphasia here... let's say a "Continue" button beside
it. It'd be really slick to do corrections with AJAX, but I realize
that presents browser-sniffing and fallback difficulties.

> What do you do at your institution
> that the DSpace workflow doesn't account for?

Third-party deposit is a huge issue here. The big problem is
licensing; DSpace assumes that because I'm pushing the buttons, I own
the content, which I often don't. I'd like to be able to send "please
license this deposit" email to another eperson. Other eperson clicks
link in email, sees license, accepts/rejects license, done. (It's
arguable whether there needs to be an authentication step here. I
incline toward no -- if the eperson clicks on a
link-with-unique-token, that's enough authentication for my purposes.
Others may disagree. Comments?) Bonus points if the eperson can
license multiple deposits at once; the use-case here is me going
through their CV for deposit-able materials which are then
batch-loaded.

Another licensing matter is materials that don't necessarily need
licenses; I've put stuff in that's public-domain, and what about
materials under a blanket SHERPA/RoMEO permission? I'm not sure what
the proper answer is here, honestly; I bring it up for discussion.

There's more, but I have stuff to be getting on with, I'm afraid.

Dorothea

-- 
Dorothea Salo dsalo at library.wisc.edu
Digital Repository Librarian AIM: mindsatuw
University of Wisconsin
Rm 218, Memorial Library
(608) 262-5493