[Dspace-general] RE: Improvements to Administrator's User Interface

[JQ Johnson]

A couple of suggestions, mixing minor UI changes with significant
implementation changes:

1/ the whole ePeople system needs to be rethought and made more modular.
At many institutions we want to tie into our central directory (LDAP,
radius, or whatever) and give all of and only our people ePerson accounts,
or at least to allow such people privileged access (perhaps what's
needed is the notion of named guests, or a set of system-wide roles such
as {guest,normal,communitycreator,superuser}).  We need an easy way to
associate LDAP-derived membership in departments with DSpace-specific
groups that give access to the corresponding communities.

Just looking at the current admin interface (/admin/edit-epeople), We need
better tools for searching the list of ePeople ("Browse ePeople" may work
for a few hundred ePeople, but not if you have 20,000) and modifying their
properties both individually and as groups.

We may need to more clearly separate system-level authorization from
system-level authentication.

2/ We need an easy way to delegate responsibilities for community
management to community-specific gatekeepers who could create
collections, add members to groups specific to that community, etc.

This implies that groups as presently implemented may be too broad.  I think
we need to have an access control mechanism that more directly ties into
communities and collections.  DSpace started this process with the
special-semantics groups like COLLECTION_3_WFSTEP_1.  But this should be
carried much further.  At a minimum, creation of a collection should
automatically create the corresponding COLLECTION_n_ADD and add it to the
ACL for the collection.  Probably such a new group should inherit some
membership from a community-level group.  If groups as presently
conceptualized continue, it should be possible to delegate ability to change
membership in a particular group -- a non-administrator gatekeeper for a
particular collection, for instance, should be able to modify the membership
of COLLECTION_n_* groups.

It's perhaps symptomatic of the problem that the admin documentation
contains language errors.  For instance, in
http://dspace.org/technology/system-docs/admin-ui.html we read that
"Permissions do not 'commute'" when the actual concept is that permissions
do not inherit or are not transitive.  But note that DEFAULT_*_* properties
do sort of inherit!

The "Communities/Collections" admin interface is quite usable as is for
small numbers of collections, but doesn't work well if you have 200
communities and 500 collections.

Creating a collection should automatically create a COLLECTION_n_ADD group
for it.

Probably lots of other changes to the collection creation/editing form would
be useful as well.  E.g. "Item template" seems ill thought out.

3/ items:  we desperately need a way for a site to customize the
submission process and change the metadata collected.  I don't think we
need to change the actual metadata schema; qDC is adequate.

4/ the admin interface for Items needs a better search facility.  I don't
want to have to think in terms of handles or internal IDs.

5/ Multiple versions of an item:  unless a better item versioning system can
be implemented soon, we need a way to allow unprivileged users to add
bitstreams to an existing record (and to record and display timestamps on a
per-bitstream basis).  This might be the owner modifying a record, or might
be people in some collection-specific group.

6/ Item authorizations in the current admin interface (Authorize->Manage An
Item's Policies) are completely obscure.  The notion of "Bundles" isn't
reified anywhere else in the user interface.  The fact that bundles have
numbers and not names is a symptom of the problem.

General observation:  for power users it might be better instead of writing
a bunch of custom UI code to simply expose the database more directly.  If I
could download a .csv file with the metadata for an item or the list of
members in a group, edit it using Excel or whatever, then upload the
resulting file, that would be a lot more flexible than the current approach.
Absent such a feature, I'm tempted to connect to my DSpace database directly
from Access or DBtools or some similar graphical SQL editor, but that is
high-risk.

JQ Johnson                      Office: 115F Knight Library
Academic Education Coordinator  mailto:jqj at darkwing.uoregon.edu
1299 University of Oregon       phone: 1-541-346-1746; -3485 fax
Eugene, OR  97403-1299          http://darkwing.uoregon.edu/~jqj/