Related to the Neos Design System, see Design System for the Neos products
The current situation with dropdown, cause some loundness issues. The shadow is not enough to see the limit of the option list, and it’s hard to focus on the content of the dropdown. Also the UI does not really focus on the current selection. When a drop down is open, the user need to select an option or close the dropdown.
A proposal should be to add a colorful border around the dropdown, to define the area, and use this color as the background of the dropdown first element. The color is also use on hover/focus in the option list. (blue is just an example, but feel quiet nice with a shades of grey)
About general Visual Loundness, check this one UI Visual Loudness
I agree with the issue. No opinion about the suggested solution with colour, not a designer. Could also be fixed with more contrast shades of gray, shadows or whatever.
Next UX coffee discussion around DropDown, and yet an other research iteration
The DropDown basically replace the full inspector content, making more options visible, cleanup the UI, focus on the current action and avoid any contrast issue with the editors bellow the drop down.
- A drop down can be big, options must be visible (at least as much as possible)
- Less scrolling
- Solve the issue when the dropdown is in the bottom of the inspector
- Scale in responsive design, works better on small screen
- Can use the same Functional & Perceptional pattern like the Navigation principle (Improving backend navigation)
- Full Inspector Editor, should be a standard pattern, so things like closing must have a consistent pattern between editors (the up caret is OK for a DropDown, but not for something else). The state of the inspector (layered) must be visible, and the way to go back explicit
Like the suggestion as it would certainly help in many cases, but unclear on some of it.
Is the middle example one where there’s only a few options? Or is that one of two suggestion solutions?
In the third example the dropdown fills up all of the inspector, which might not work too well if there’s only two options and it’s being opened near the bottom of the inspector. But this would have to be tried out in practice to determine.
Lastly example three has the label on top, then the selected value with a different label than what’s selected in the options. Is this on purpose, is it needed? It requires defining an additional label for the options and not sure how useful having the selected option twice is.
Awesome work btw.
I think we need consistent pattern, so changing the pattern based on inspector position, number of options, … feels bad from my POV. I agree that the solution is not perfect in all case, the perfect for all case is a bit like unicorn, powerful but hard to get them
The solution in the middle column, is just a small change to improve the visual loundness and constrat issue of our current UI pattern for dropdown.
The right column, is an alternative solution (currently my prefered one). It has some small drawbacks, but also solve a lots of issue (not enough visible options, big dropdown down in the inspector, …) and open new possibilities like more rich options with more content, visual, …
For small dropdown with between two or five options, I will prefere to introduce a new rendering (radio/check box style) and make them visible all the time. A raw version can be something like this:
First draft, need more love
Interesting discussion I personally would thing the variant 2 (with the border) would be a nice, incremental improvement of the current state. For me, 3 is too radical — and it is unclear to me if it will work out in all cases where we use Dropdowns…
Just my two cents,
All the best,
I would also prefer progressive improvement but we need research in more radical change, maybe not enforce them by default. Currently it’s pure research, and I don’t want to close any options currently.
And my first Pull Request around the Dropdown research https://github.com/neos/neos-ui/pull/1517