[Dspace-general] Week 5: Submission process

[Dorothea Salo]

On Mon, Sep 15, 2008 at 9:39 AM, Graham Triggs <graham at biomedcentral.com> wrote:

> You are right, it is an easy fix - it took me minutes alter the metadata
> entry JSP to add little red stars next to any field marked as <required>
> in input-forms.xml.

Just for clarification: if input-forms.xml changes to make different
fields required or not, your JSP fixes the input screens
automagically? That's obviously the ideal. :)

Manakin folks: how much does DRI know about what's in input-forms.xml?
Is it possible for a theme to do this work, or does an Aspect have to
be rewritten?

> This is a tricky one - the information in the pool listing isn't
> necessarily enough for someone to decide if they are going to do the
> task. So if they take it, they have to return it to the pool or nobody
> else can work on it.

Well, yes, but look at the clickstream here. We have four cases:
eperson does or doesn't want a task, crossed with "accept task" screen
existing or not.

If eperson DOES want task, and "accept task" screen DOES exist:
Eperson takes task, eperson accepts task. Two clicks.

If eperson DOES want task, and "accept task" screen DOES NOT exist:
Eperson takes task. One click.

If eperson DOES NOT want task, and "accept task" screen DOES exist:
Eperson takes task. Eperson rejects task. Two clicks.

If eperson DOES NOT want task, and "accept task" screen DOES NOT
exist: Eperson takes task. Eperson clicks "return task to pool." Two
clicks.

In other words, keeping the "accept task" screen doesn't actually save
any work for the eperson who doesn't want a given task! It also
creates a whole JSP/XMLUI section to maintain for developers (and, if
I understand correctly, a whole state for a task to be in: "taken but
not done yet"). I'm sensitive to the scenario in which an eperson who
doesn't want a task forgets to return it to the pool, but my fix for
it (if possible) would be to return the task to the pool automatically
once the eperson's session ends. If they want the task later, they can
pick it up again from their My DSpace page... and I note that this
solution would help deal with the "marooned task" problem as well.

Ideally, the "return task to pool" button would be relabelled or
eliminated, because the state of a task is really DSpace-internal
housekeeping, not something that's important to the performer of the
task. In this scenario, failure to perform the task, or navigation
away from the task toward something else, would signify "return task
to pool" to DSpace. I don't know how much programming hassle that
would create, I'm afraid; the workflow code has made my head hurt
whenever I've looked at it.

Dorothea

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