You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the feature you'd like
This is an idea for a feature and not an urgent request. I’ve heard from many Sinopia users and experienced frustration myself with some forms being very long and difficult to navigate. While the new “top” button and retaining position on the page after saving helps immensely, and has been well received by the user community, I hope to offer another solution though I'm not sure it is possible or if there is a better way to address these concerns.
The left-hand menu is a wonderful resource for those who use it. When a user clicks on a menu label, they are brought to the property they wish to edit. My thought is to introduce collapsible portions of the property templates.
Give an example
If a user clicks on a property in the left-hand side menu the screen rapidly scrolls to the property. This can be hard on the eyes, and adds wait time for the page to find the property in complex templates. It seems unnecessary to have this scrolling if properties can be tucked away while they aren’t being worked on.
One way this could work is to have properties collapsed by default and add a button or symbol to expand the property to fill in values or select lookups. Another way this could work would be to have all properties collapsed by default and use the left-hand side menu to expand an area you’d like to work on. When clicking on another property, the previous property would collapse and the selected property would expand. This suggests a smaller font size for the left-hand side menu so that the page doesn’t need to go beyond the fold for most browser windows very often. The main idea would be to hide properties while they aren't being worked on. It would be even better if users could navigate between properties not only by clicking to expand or collapse, or clicking on a property, but also by tabbing, or using a keyboard shortcut to navigate between properties.
I’ve attached some mock ups to help explain. Apologies for their crudeness!
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
I would continue using the current design. I have seen other editors simply reduce the entire size of fonts and frames but I’m not sure that’s necessary, though it may also help. I would not want the overall size to be so small that it resembles a MARC editing environment.
The text was updated successfully, but these errors were encountered:
For what it's worth, we ran into this at Cornell when working on "Vitrolib" experimentations for an ontology agnostic" cataloging tool. One of the things we attempted was to create field groupings in SHACL, not dissimilar to MARC field "blocks" (1XX, 3XX, 5XX, 6XX) in our template creation. I don't know that the tabs we implemented in the UI are the answer to long forms, but I remember catalogers responding well to like fields organized together. See: https://wiki.lyrasis.org/display/ld4lLABS/Lessons+learned%3A+VitroLib+and+SHACL.
This is so close to what I was looking for, @sfolsom - I was trying to think of ways to group properties but wasn't sure if it was desirable or easy to do with customizable forms, and I also wasn't sure what those groups would be. The tabs are an interesting approach, and one that is used in the Alma UI frequently. It would be interesting to see if the tab concept could be turned on its side, utilizing the existing Sinopia property menu. The only downside I have for tabs is the amount of clicks, but that might happen either way. Very exciting to see that this has been done before.
Describe the feature you'd like
This is an idea for a feature and not an urgent request. I’ve heard from many Sinopia users and experienced frustration myself with some forms being very long and difficult to navigate. While the new “top” button and retaining position on the page after saving helps immensely, and has been well received by the user community, I hope to offer another solution though I'm not sure it is possible or if there is a better way to address these concerns.
The left-hand menu is a wonderful resource for those who use it. When a user clicks on a menu label, they are brought to the property they wish to edit. My thought is to introduce collapsible portions of the property templates.
Give an example
If a user clicks on a property in the left-hand side menu the screen rapidly scrolls to the property. This can be hard on the eyes, and adds wait time for the page to find the property in complex templates. It seems unnecessary to have this scrolling if properties can be tucked away while they aren’t being worked on.
One way this could work is to have properties collapsed by default and add a button or symbol to expand the property to fill in values or select lookups. Another way this could work would be to have all properties collapsed by default and use the left-hand side menu to expand an area you’d like to work on. When clicking on another property, the previous property would collapse and the selected property would expand. This suggests a smaller font size for the left-hand side menu so that the page doesn’t need to go beyond the fold for most browser windows very often. The main idea would be to hide properties while they aren't being worked on. It would be even better if users could navigate between properties not only by clicking to expand or collapse, or clicking on a property, but also by tabbing, or using a keyboard shortcut to navigate between properties.
I’ve attached some mock ups to help explain. Apologies for their crudeness!
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
I would continue using the current design. I have seen other editors simply reduce the entire size of fonts and frames but I’m not sure that’s necessary, though it may also help. I would not want the overall size to be so small that it resembles a MARC editing environment.
The text was updated successfully, but these errors were encountered: