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 [EMAIL PROTECTED] Digital Repository Librarian AIM: mindsatuw University of Wisconsin Rm 218, Memorial Library (608) 262-5493 _______________________________________________ Dspace-general mailing list [email protected] http://mailman.mit.edu/mailman/listinfo/dspace-general
