Evergreen

Bug #1502292
Comment #21

Comment 21 for bug 1502292

Revision history for this message

Grace Dunbar (gdunbar) wrote on 2015-11-18:

#21

To be clear, the description of how volumes are added is written in such a way as to make it seem excessively more complicated than it actually is.

Here is a clear breakdown of how you add volumes in the XUL client:
Step 1 – Perform a search for the record; view results.
Step 2 – Select a specific record. You are brought to the record detail page.
Step 3 – Click on Add Volumes. A separate tab opens where you can add a volume/item.

Here is a clear breakdown of how you add volumes in the web client:
Step 1 – Perform a search for the record; view results.
Step 2 – Select a specific record. You are brought to the record detail page.
(In the web client, you are brought to a record detail page with 7 sub tabs (OPAC view, MARD Edit, MARC View, Monograph Parts, Holdings View, Conjoined Items). You can set (and change) which sub tab is your default. Holdings View is the recommended default for staff who predominantly add copies/volumes.)
Step 3 - Right click on the row you want and select Add Volumes and Copies from the context menu.
A separate tab opens where you can add a volume/item.

Step 3 for the web client does involve "an extra click" from the way the current interface is designed. However there are numerous places in this interfaces where options have been streamlined in a way that will save users clicks and present more useful information. I'd like for the community to consider the overall design rather than narrowing in on specific buttons/displays/actions that we've come to rely on. Feature parity is meant to ensure that no functionality will be lost, not that the workflow won't change.

I would like to point out that the available screen space in the web client is more limited that the XUL client. In asking people to consider overall design I am asking that people realize that there are no UI design guidelines or gurus in the Evergreen community. If every staff member who performs a common action gets enough of their peers to clamor for a link/button to be placed prominently on a screen there is no committee to say "no". And that's, in my opinion, a contributing factor in how the XUL client ended up with it's Frankenstein-ish appearance. I'm just stating for the record that this is a slippery design slope.

There are inherent differences in how software interfaces are designed depending on the platforms and delivery mechanisms they use. There are necessarily going to be design changes as we move from the XUL client to the web client. And just because the mechanism of accessing the tool or action has changed, that doesn't mean that the software is losing functionality... it just means it's different.

To be clear, the description of how volumes are added is written in such a way as to make it seem excessively more complicated than it actually is.

Here is a clear breakdown of how you add volumes in the XUL client:
Step 1 – Perform a search for the record; view results. 
Step 2 – Select a specific record.  You are brought to the record detail page.  
Step 3 – Click on Add Volumes. A separate tab opens where you can add a volume/item.

Here is a clear breakdown of how you add volumes in the web client:
Step 1 – Perform a search for the record; view results. 
Step 2 – Select a specific record. You are brought to the record detail page.  
(In the web client, you are brought to a record detail page with 7 sub tabs (OPAC view, MARD Edit, MARC View, Monograph Parts, Holdings View, Conjoined Items).   You can set (and change) which sub tab is your default.  Holdings View is the recommended default for staff who predominantly add copies/volumes.)
Step 3 - Right click on the row you want and select Add Volumes and Copies from the context menu.
A separate tab opens where you can add a volume/item.

Step 3 for the web client does involve "an extra click" from the way the current interface is designed.  However there are numerous places in this interfaces where options have been streamlined in a way that will save users clicks and present more useful information.  I'd like for the community to consider the overall design rather than narrowing in on specific buttons/displays/actions that we've come to rely on.  Feature parity is meant to ensure that no functionality will be lost, not that the workflow won't change.

I would like to point out that the available screen space in the web client is more limited that the XUL client. In asking people to consider overall design I am asking that people realize that there are no UI design guidelines or gurus in the Evergreen community.  If every staff member who performs a common action gets enough of their peers to clamor for a link/button to be placed prominently on a screen there is no committee to say "no".  And that's, in my opinion, a contributing factor in how the XUL client ended up with it's Frankenstein-ish appearance.  I'm just stating for the record that this is a slippery design slope.

There are inherent differences in how software interfaces are designed depending on the platforms and delivery mechanisms they use. There are necessarily going to be design changes as we move from the XUL client to the web client.  And just because the mechanism of accessing the tool or action has changed, that doesn't mean that the software is losing functionality... it just means it's different.