[Dspace-general] Week 5: Submission process

Mon Sep 15 11:50:59 EDT 2008

Dorothea et al.

Concerning this topic of submission, at Cornell University, we are 
running DSpace 1.4.2...

What works?

In general the submission process works fine, but we have had to make 
some local changes.

The first local change was a new function called "Quick Submit".  We 
have a "Quick Submit" button along side the regular submit.  The 
Quick Submit is a rewrite of the original Submit.  It starts with 
"Choose a Collection", then jumps to the License Agreement and then 
jumps to a one page Description Page which has a button to allow to 
add more files if needed.  The idea was to make things easier for 
people to add records and if more metadata was needed, it could be 
added later.  This was originally created for DSpace 1.2 by a Java 
Programmer (not me), but I have had to migrate it with each upgrade 
and make changes to it so that it would work.  I am assuming this 
process will die with DSpace 1.5.1.

The other change we made wasn't in DSpace, but more of a process.  We 
have people wanting to add videos to the Physics arXiv [which my 
Department manages] (but the arXiv doesn't allow videos).  So I set 
up a generic account in DSpace and then a HTML page that logs a 
person into DSpace (under that generic account) so they can submit 
their videos.  Once they have a handle, they can submit a paper to 
the arXiv with the link to their video.  The idea was to allow people 
to submit without having each user get a DSpace account.

What doesn't work?

Well, we really need a more flexible submit process per 
collection.  I don't know how that could be programmed, but our users 
definitely want their own "personalized" submission process.  Maybe, 
1.5.1 will help here. We handle a lot of questions about what things 
mean on the submit pages.  A lot of times, I tell people if they 
don't know what I field means, ignore it.  All we want is Author, 
Title, Abstract, Keyword(s) and the item, itself.

Another problem is videos.  We had a user who wanted to submit flash 
videos.  We came up a process for them which was bit complicated (and 
involved with us creating the auxiliary files and a viewer).  In the 
end, the user decided not to use our process or repository.

We, also, looked at providing a template for users and then using the 
batch process as a background job for uploading files.  This really 
didn't go anywhere, but we have had people who would like to batch 
load stuff.  Right now, I do most of the batch loads.

At 10:03 AM 9/15/2008, Dorothea Salo wrote:
>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
>_______________________________________________
>Dspace-general mailing list
>Dspace-general at mit.edu
>http://mailman.mit.edu/mailman/listinfo/dspace-general

***************************
George Kozak
Coordinator
Web Development and Management
Digital Media Group
501 Olin Library
Cornell University
607-255-8924
***************************
gsk5 at cornell.edu 