[UX-277] Rethink the UX for Holdings record on the Instance detailed view Created: 27/Feb/19  Updated: 16/Jun/20  Resolved: 16/Jun/20

Status: Closed
Project: User Experience Design
Components: None
Affects versions: None
Fix versions: None

Type: Story Priority: P3
Reporter: Charlotte Whitt Assignee: Filip Jakobsen
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: PNG File Screenshot 2019-07-12 at 23.44.34.png     PNG File Skärmavbild 2019-02-27 kl. 13.18.13.png     PNG File Skärmavbild 2019-03-14 kl. 07.18.41.png    
Sprint: stripes-force 68, stripes-force 72, stripes-force 69, stripes-force 70
Development Team: Stripes Force

 Description   

Overview: When testing in the https://bugfest.folio.ebsco.com/ Q1, 2019 environment, then the set up of Chalmers location data, shows that the current display of data looks large and clumsy:

Purpose: So we need to rethink how to present data in the Holdings accordion, with associated Item records



 Comments   
Comment by Charlotte Whitt [ 14/Mar/19 ]

Hi Theodor Tolstoy (One-Group.se) - this might not be an UX issue after all in the general use, but caused by the call numbers used at Chalmers are some pretty long text strings - e.g.: Tp National institute of standards and technology. NIST special publication. 762

CC: Anton Emelianov Hongwei Ji

Comment by Hongwei Ji [ 14/Mar/19 ]

Theodor Tolstoy (One-Group.se) I took a look the data in database, it seems to be the case.

Comment by Lisa Sjögren [ 14/Mar/19 ]

Yes, that is indeed the state of our data.

Comment by Charlotte Whitt [ 14/Mar/19 ]

Hi all, thanks. Then it's not a bug, but it sure does not look nice.

Lisa Sjögren and Theodor Tolstoy (One-Group.se) - what is your thinking?

Comment by Lisa Sjögren [ 15/Mar/19 ]

Hi Charlotte Whitt!

On the one hand, we have ourselves (and current/previous ILS:s) to blame for jamming all that data into one field. On the other hand, since the system obviously allows these long strings, it should definitely have an acceptable way of displaying them. And would the same data be displayed in a better way if it had been split up into several fields, eg call no, call no prefix and call no suffix?

I think this discussion shows that the more options the system provides for communicating the whereabouts of an object (eg holdings and call no in holdings and item level), the more crucial it becomes to have a UX team review the display of these from a broader perspective. Which of the many fields need to be displayed, in which cases, and how? With all these fields, how do we avoid clutter and confusion, and create a display that is predictable and easy to grasp for the user?

Comment by Filip Jakobsen [ 15/Mar/19 ]

Everyone, please be aware that the components used for this currently, were never meant to contain this kind of data; nor were they meant to be used for displaying holdings in Inventory; the "hierarchical list" component is the primary missing piece of the puzzle to make this less cluttered and more useful. We need this for the use case at hand; and also for Orders and for Data Import. The hierarchical list supports the technical use case of wanting to show holdings with a list of items under each holdings record, while maintaining an orderly and easy-to-scan layout that does not get cluttered. The "Accordion" component currently used to show a holding was never meant to be used for anything other than section headlines.

The hierarchical list can be seen on https://ux.folio.org/prototype/en/inventory (this shows what the holdings list was intended to look like) and a prototype of the "New Job" screen in Data Import can be tried out on https://ux.folio.org/testing/data-import/new-job/2.0.0/ — the latter might differ slightly from the need in Inventory, but the concept is the same: nested lists of data.

CC Khalilah Gambrell, Charlotte Whitt, Lisa Sjögren, Rasmus Wølk, John Coburn, Ann-Marie Breaux, Zak Burke

Comment by Lisa Sjögren [ 15/Mar/19 ]

Hear, hear! Filip Jakobsen

Comment by Filip Jakobsen [ 12/Jul/19 ]

This has been assigned to me to provide guidance. As I have stated before, the tree view AKA hierarchical list AKA nested list would solve this, I believe (see attached screenshot from https://ux.folio.org/prototype/en/inventory) In addition, using › instead of > will make it look less clumsy.

If we are not doing a collapsible, flexible, tree view component now, I am sure e.g. Rasmus Wølk could fairly quickly help make a similar-looking, but less versatile, implementation of a sort of nested list for this particular purpose. Which might be better as a short term solution, Charlotte Whitt, Khalilah Gambrell?

Thanks!

Comment by Khalilah Gambrell [ 26/Jul/19 ]

Filip Jakobsen - will this design change with UX-311 Closed ? Can we have two designs 1.) Ideal design and 2.) Design based on the current UI design?

Generated at Fri Feb 09 00:16:24 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.