The new markup of the version dropdown menu (since support for scheduled list versions) introduces some UI-issues that needs to be considered.
Since the select-input has been replaced with a ul-element it does no longer benefit from the native browser rendering which places any currently open select list on top of everything else.
The ul-element on the other hand is limited to the boundaries of it's wrapping block element and any overflowing parts will be hidden.
Perhaps we can discuss what solutions we could use to solve this?
Suggestion 1: add css rule "bottom:0;" on
element.
This would make the list toggle upwards instead of downwards, placing itself on top of the actual list instead of below it.
Quick fix. Could work in most cases, does not look too good.
Suggestion 2: Somehow temporarily dislocate the version dropdown on top of all elements, while interacted with, so that it's overflow is not cropped by any wrapper.
Not sure how to approach this best.
Suggestion 3: Buy bigger screens to editors so that they don't have to place their lists at the bottom of the column wrapper. :wink:
This is indeed tricky.... I actually believe that we need to re-think how versions is managed in the ui.
Think of an image editor or a text editor. The context is somewhat different compared to when your'e working with Arlima but there are some similarities also. You're working with one or more objects (lists/documents/images) simultaneously, you have all these object visible on your screen. You can move stuff between these objects, the objects gets altered and you can decide to save them in their current state or revert your alterations. Looking at your common text/image editor: where have they put controls for managing versions of the objects in view? They're probably lacking the feature entirely, if not they probably haven't given it too much focus.
My point is that we have given the "versions" too much focus in the ui. I believe that managing of versions is something that is seldom done by the authors. Another downside with the current ux-strategy (or what to call it) is that the editor has to understand that the lists has more than two states. In your common text/image editor you only have two states, the image/document is either saved or unsaved. In arlima we have three different states and the author could actually be fooled into thinking that old versions can be edited and re-saved (which would be a fourth state), this is not supported but the author won't be aware of this until he/she saves the list and realize that a new published version have been created.
Sorry for the OT but I really think that we need to improve the managing of versions in the UI, the controls should not be present on the list object and the third state should be removed. We can discuss this later on....
On topic:
Let's go with suggestion nr 1 but only when needed. When the drop-down get displayed we look at the offsets of the element to determine if the drop-dow should be displayed upwards or downwards.
I see your point. Complexity should be always be avoided, simplicity is a goal in itself. And I figure It's difficult to keep track of where any project is heading when there's "a lot of cooks" and new requests and features that changes the appearance and complexity of the tool.
The new markup of the version dropdown menu (since support for scheduled list versions) introduces some UI-issues that needs to be considered. Since the select-input has been replaced with a ul-element it does no longer benefit from the native browser rendering which places any currently open select list on top of everything else.
The ul-element on the other hand is limited to the boundaries of it's wrapping block element and any overflowing parts will be hidden. Perhaps we can discuss what solutions we could use to solve this?
Suggestion 1: add css rule "bottom:0;" on
Suggestion 2: Somehow temporarily dislocate the version dropdown on top of all elements, while interacted with, so that it's overflow is not cropped by any wrapper.
Suggestion 3: Buy bigger screens to editors so that they don't have to place their lists at the bottom of the column wrapper. :wink:
This is indeed tricky.... I actually believe that we need to re-think how versions is managed in the ui.
Think of an image editor or a text editor. The context is somewhat different compared to when your'e working with Arlima but there are some similarities also. You're working with one or more objects (lists/documents/images) simultaneously, you have all these object visible on your screen. You can move stuff between these objects, the objects gets altered and you can decide to save them in their current state or revert your alterations. Looking at your common text/image editor: where have they put controls for managing versions of the objects in view? They're probably lacking the feature entirely, if not they probably haven't given it too much focus.
My point is that we have given the "versions" too much focus in the ui. I believe that managing of versions is something that is seldom done by the authors. Another downside with the current ux-strategy (or what to call it) is that the editor has to understand that the lists has more than two states. In your common text/image editor you only have two states, the image/document is either saved or unsaved. In arlima we have three different states and the author could actually be fooled into thinking that old versions can be edited and re-saved (which would be a fourth state), this is not supported but the author won't be aware of this until he/she saves the list and realize that a new published version have been created.
Sorry for the OT but I really think that we need to improve the managing of versions in the UI, the controls should not be present on the list object and the third state should be removed. We can discuss this later on....
On topic: Let's go with suggestion nr 1 but only when needed. When the drop-down get displayed we look at the offsets of the element to determine if the drop-dow should be displayed upwards or downwards.
Good suggestion! +1.
I see your point. Complexity should be always be avoided, simplicity is a goal in itself. And I figure It's difficult to keep track of where any project is heading when there's "a lot of cooks" and new requests and features that changes the appearance and complexity of the tool.