dspace-angular icon indicating copy to clipboard operation
dspace-angular copied to clipboard

Improve usability of Edit Resource Policy page

Open alawvt opened this issue 3 years ago • 1 comments

Is your feature request related to a problem? Please describe. In DSpace 7, the Edit resource policy page requires scrolling and extra work that is unnecessary in DSpace 6 XMLUI. Please revise this page to be more efficient for the user. DSpace7_edit_resource_policy

DSpace6_XMLUI_edit_resource_policy DSpace6_XMLUI_edit_resource_policy2

Describe the solution you'd like A clear and concise description of what you want to happen.

  • Like DSpace 6 XMLUI, please make the Description box shorter.
  • In DSpace 6 XMLUI, the Group dropdown is before the date, which reduces scrolling since that is the field we most often change.
  • The Group dropdown is much more efficient than the arrangement in DSpace 7. With the dropdown, one just starts typing the name of the Group and it advances to that name in the option list. In most case, this avoids the need to use the search box below.
  • In DSpace 7, one must correctly type in the eperson or group name in the textbox or scroll down to use the search box or the paginated list below that.
  • I think it would be most efficient to replace that plan textbox with the dropdown list, preferably further up the page.

Describe alternatives or workarounds you've considered A clear and concise description of any alternative solutions or features you've considered.

Additional context Add any other context or screenshots about the feature request here.

In the Edit Item page, #1754, the former dropdown for the metadata field has been replaced with a textbox, but at least that one has a search associated with it. This textbox does not. Personally, I would prefer the plain dropdown but the textbox with search would be better than this current arragement.

alawvt avatar Sep 01 '22 21:09 alawvt

This appears to be a general recommendation to improve the usability of the Edit Resource Policy pages. However, I don't think we can revert entirely to a dropdown for all Groups (as we had complaints that was bad usability in 6.x for sites that had many Groups -- e.g. a dropdown doesn't work well with hundreds of groups).

Overall, I do agree that the usability of this page in DSpace 7.x is also not great. I'll pull this ticket over to the board to look for volunteers, but I'm going to modify the ticket to make it clear that this is generally about the usability of the page.

tdonohue avatar Oct 24 '22 15:10 tdonohue

@tdonohue Here's what I propose.

  • The start date and end date fields to be brought down at the last for easier access to the select eperson or group field and it's search results.
  • The height of description box to be set to somewhere around one-third of the current height.
  • The search results table to also include Identity Column which will include Email and NetID which is same as the search results table on the Edit Group Page (image attached below).

Let me know anything else that needs to be changed on this page. You can assign this issue to me. I will be happy to work on this .

Edit Group

amanbudgujar avatar Feb 28 '23 05:02 amanbudgujar

@amanbudgujar : Your design is a good start, but I think the "Identity" column would not be a full solution here. Most Resource Policies involve selecting a Group, not an EPerson, and the "Identity" column only helps for EPerson objects. For a Group, we'd likely want to instead display the "Collection/Community" column like in "Access Control -> Groups": groups

So, if the Resource Type is for an EPerson, it could display that "Identity" column... but if it is for a Group, it likely should display "Collection/Community" instead.

Your other minor changes sound reasonable. Let me know though if you still feel this is a task you are interested in, or if it sounds more complex than you anticipated.

tdonohue avatar Feb 28 '23 19:02 tdonohue

@tdonohue Sure. You can assign this to me. Also, I have a query about json5 files. If I am adding a new key in the en.json5 file, am I also expected to translate and add the same code in all the other language json5 files?

amanbudgujar avatar Mar 01 '23 12:03 amanbudgujar

@amanbudgujar : Sounds good. I'll assign this to you.

To answer your question, no you do not need to update every json5 file when adding a new key. You just need to ensure the new key is added to en.json5. Volunteer translators will ensure that the other json5 files are updated when they next update the translation for their language.

tdonohue avatar Mar 01 '23 15:03 tdonohue