[Dspace-general] RE: Dspace-general Digest, Vol 3, Issue 6
Strongin-Garry, Ilene (IHG)
Ilene.Strongin-Garry at ichotelsgroup.com
Wed Oct 8 14:09:46 EDT 2003
I agree with the need for integrating epeople with other outside sources
like Microsoft Outlook. We are a work population in the 1000's and once
more people start using DSpace, the Epeople system will become very time
consuming.
-----Original Message-----
From: dspace-general-request at mit.edu
[mailto:dspace-general-request at mit.edu]
Sent: Wednesday, October 08, 2003 12:04 PM
To: dspace-general at mit.edu
Subject: Dspace-general Digest, Vol 3, Issue 6
Send Dspace-general mailing list submissions to
dspace-general at mit.edu
To subscribe or unsubscribe via the World Wide Web, visit
http://mailman.mit.edu/mailman/listinfo/dspace-general
or, via email, send a message with subject or body 'help' to
dspace-general-request at mit.edu
You can reach the person managing the list at
dspace-general-owner at mit.edu
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Dspace-general digest..."
Today's Topics:
1. RE: Improvements to Administrator's User Interface (JQ Johnson)
2. RE: Dspace-general Digest, Vol 3, Issue 5
(Strongin-Garry, Ilene (IHG))
3. RE: Improvements to Administrator's User Interface (Scott Yeadon)
----------------------------------------------------------------------
Date: Tue, 7 Oct 2003 11:28:12 -0700
From: "JQ Johnson" <jqj at darkwing.uoregon.edu>
To: <dspace-general at mit.edu>
Subject: [Dspace-general] RE: Improvements to Administrator's User
Interface
Message-ID: <MMENIDDNIPBIJLHLNFHBEEMKCLAA.jqj at darkwing.uoregon.edu>
In-Reply-To: <5.2.1.1.2.20031007100229.02140cb8 at po10.mit.edu>
Content-Type: text/plain;
charset="iso-8859-1"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: list
Message: 1
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/
------------------------------
Date: Tue, 7 Oct 2003 15:41:12 -0400
From: "Strongin-Garry, Ilene (IHG)"
<Ilene.Strongin-Garry at ichotelsgroup.com>
To: "'dspace-general at mit.edu'" <dspace-general at mit.edu>
Subject: [Dspace-general] RE: Dspace-general Digest, Vol 3, Issue 5
Message-ID: <4201FDFD444BC84190DEF632181EB38F2AB636 at bhratlexg03.hiw.com>
Content-Type: text/plain;
charset="iso-8859-1"
MIME-Version: 1.0
Precedence: list
Message: 2
Other enhancements I'd like to see include:
When submitting an item, you are asked to submit to a collection. However,
once you choose the collection it cannot be changed without having to
re-enter the entire amount of metadata and files. I would like to have the
option to correct my collection choice.
Secondly, it would be great to be able to add additional files to an item
once it's in DSpace. I know you can edit metadata, but it would be great to
be able to add files in case something has been accidentally left off or
found later after an item has been submitted.
-----Original Message-----
From: dspace-general-request at mit.edu
[mailto:dspace-general-request at mit.edu]
Sent: Tuesday, October 07, 2003 12:01 PM
To: dspace-general at mit.edu
Subject: Dspace-general Digest, Vol 3, Issue 5
Send Dspace-general mailing list submissions to
dspace-general at mit.edu
To subscribe or unsubscribe via the World Wide Web, visit
http://mailman.mit.edu/mailman/listinfo/dspace-general
or, via email, send a message with subject or body 'help' to
dspace-general-request at mit.edu
You can reach the person managing the list at
dspace-general-owner at mit.edu
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Dspace-general digest..."
Today's Topics:
1. Fwd: Re: [Dspace-general] Improvements to Administrator's User
Interface (Margret Branschofsky)
----------------------------------------------------------------------
Date: Tue, 07 Oct 2003 10:02:48 -0400
From: Margret Branschofsky <margretb at MIT.EDU>
To: dspace-general at MIT.EDU
Subject: Fwd: Re: [Dspace-general] Improvements to Administrator's User
Interface
Message-ID: <5.2.1.1.2.20031007100229.02140cb8 at po10.mit.edu>
Content-Type: text/plain; charset="us-ascii"; format=flowed
MIME-Version: 1.0
Precedence: list
Message: 1
>Date: Tue, 07 Oct 2003 10:01:45 -0400
>To: Jewel Ward <jewelw at lanl.gov>
>From: Margret Branschofsky <margretb at mit.edu>
>Subject: Re: [Dspace-general] Improvements to Administrator's User
Interface
>
>Have you all seen the Administration User Interface Documentation which
>comes with the system documentation? If so, is this documentation not
>adequate? (http://dspace.org/technology/system-docs/admin-ui.html ).
>
>Margret
>
>At 03:37 PM 10/6/2003 -0600, Jewel Ward wrote:
>>At 11:47 AM 10/3/2003 -0400, you wrote:
>>
>>>Can I assume there will be a help page for the Admin interface similar
>>>to the user's interface that will explain how to create and delete
>>>community, collection and set policies for them, etc. It seems that I
>>>ran into some issues with the order in which you had to do things.
>>
>>Margret,
>>
>>I had the same problem. I'll try to think of things that are more
>>specific and send them to you.
>>
>>Regards,
>>
>>Jewel
>>
>>
>>
>>>***********************************
>>>Laura Tull
>>>Systems Librarian
>>>Ohio State University Libraries
>>>1858 Neil Avenue Mall
>>>Columbus OH 43210-1286
>>>Phone: 614-247-6459
>>>Fax: 614-292-7859
>>>Email: tull.9 at osu.edu
>>>***********************************
>>>_______________________________________________
>>>Dspace-general mailing list
>>>Dspace-general at mit.edu
>>>http://mailman.mit.edu/mailman/listinfo/dspace-general
>>
>>--
>>Jewel H. Ward
>>Graduate Research Assistant, Post-master's
>>Los Alamos National Laboratory
>>Research Library
>>(505) 664-0368
>>jewelw at lanl.gov
------------------------------
_______________________________________________
Dspace-general mailing list
Dspace-general at mit.edu
http://mailman.mit.edu/mailman/listinfo/dspace-general
End of Dspace-general Digest, Vol 3, Issue 5
********************************************
------------------------------
Date: Wed, 8 Oct 2003 17:05:16 +1000
From: Scott Yeadon <scott.yeadon at anu.edu.au>
To: margretb at MIT.EDU
Cc: dspace-general at MIT.EDU
Cc: dspace-tech at sourceforge.lists.net
Subject: [Dspace-general] RE: Improvements to Administrator's User Interface
Message-ID: <200310081705.16171.scott.yeadon at anu.edu.au>
Content-Type: text/plain;
charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: list
Reply-To: scott.yeadon at anu.edu.au
Message: 3
Hi Margaret,
Below are our suggestions that ANU would like to see. They are ordered from
most important to least important.
1. Administration at Community and collection levels
For our implementation we want our users to establish and manage their own
communities and collections without being able to change communities and
collections which they don't have administrator access for. Currently there
is only an overall administrator and we need an additional administrator
layer.
2. Allow searching on items using metadata searches rather than handles
Item handles really don't mean much to users, when looking for an item
metadata such as titles and authors is used.
3. Metadata should be configurable at community, collection and item levels.
Currently only one standard metadata set is available across a single DSpace
instance.
We would like to be able to allow the creation of multiple simultaneous
metadata schemas. These schemas should be able to be attached at a
community,
collection and item level. The submission forms can then generated
dynmically
using the metadata schema.
We would like to also be able to create default metadata schema and forms.
For
example when a user selected a type of "image" then default metadata schema
and forms could be assigned for the submission process rather than the user
having to select or define a schema, or work their way through irrelevant
metadata forms.
4. If clicking on the "Add EPerson" button a person is automatically added.
There is no cancel operation on the Add EPerson screen. The new EPerson
should not be added unless the administrator explicitly clicks on the "Save
Edits" button.
5. Would be good to be able to edit items from the Edit collection screen.
This should allow users to edit items belonging to the collection being
added. Currently you have to go out of the collection to edit items that
belong to it.
6. Navigation within multiscreen operations.
The breadcrumb links do not always represent where you are in the function
hierarchy meaning the back button needs to be used on some occasions. As
there appears to be problems when using the back button, the breadcrumbs
need
to be complete and session state information needs to be maintained so that
the back button can be used.
7. When editing authorisations it would speed things up if you could select
more than one access type. For example if I want a Group to have Read,
Write,
Add access, I should be able to select all thes in one operation rather than
have to perform three separate operations.
8. On the community, collection, item authorisation pages it would be useful
to be able to click on the group and have a popup displaying which EPersons
belonged to the group. Currently you have to go out and back into the Group
maintenance page to see this.
9. Similar to above, when viewing the groups it would be useful to be able
to
see which collections the groups had access to.
10. Look at performance improvements for update/delete queries, for example
by
using threads or asynchronous background transactions while the user moves
to
the next screen. This may also be an issue for drawing of screens for
example
when a repository has a large number of collections, groups, etc rendering
may become slow. This could be improved through filtering what is displayed
by providing search and browse facilities similar to what is currently in
place for collections.
11. Consistent placement and use of buttons would be useful to avoid
confusion. For example, on some screens you need to make a change and also
click an "Update" button whereas on others you only need to make a change
for
it to take effect. On several screens where multiple operations may be
performed (such as metadata, bitstream registries) the "New" button is
placed
at the bottom of the screen, where it may be better to put it at the top
since the page returns to the top once the change has been applied.
12. Would be good to be able to apply advanced wildcard authorisation
policies
to collections, not just items and bitstreams.
13. Many of the tables run off the screen making it impossible to view the
information without scrolling left-to-right. If the table cannot be made to
fit on the screen it would be useful to allow columns to be hidden (similar
to the hide/show functionality of tools like MS Excel/Access)
Hope that helps. If you would like any clarification on these requests,
please
feel free to contact me.
Thanks.
Scott.
------------------------------
_______________________________________________
Dspace-general mailing list
Dspace-general at mit.edu
http://mailman.mit.edu/mailman/listinfo/dspace-general
End of Dspace-general Digest, Vol 3, Issue 6
********************************************
More information about the Dspace-general
mailing list