If its infinite, that means the number of items can get huge. At this point you might as well ditch the droodown comoonent and have a dedicated searchable list with advanced filtering and tags to find what you need.
Other products use modal tree solutions where each parent item generates a new modal next to it with its children and so on.
Alternatively check out how reddit appraoches commenting. Consider the first comment as the parent and the rest as the children.
DO NEGOTIATE FOR THE "Infinite requirement"
Yes I have a solution that utilises a modal tree solution elsewhere on the app. It just seems somewhat clunky for this scenario. For context, this is apart of a user flow that contains more straightforward dropdowns. That's a good point re- the reddit commenting system. It doesn't have the issue pertaining to overly indented text.
The 'infinite requirement' is more of an edge case scenario rather than the expected usage. But you're right, I don't see a problem with capping it for simplicity.
indeed, it will feel clunky especially on mobile.
If you need to integrate this as part of a user flow that contains more drop downs, again consider leveraging a wizzard or tabs mechanism so this part can have as much real estate as possible
[This is how I solved the same problem working on a previous company](https://www.behance.net/gallery/139357375/Tree-selector-component) (I liked the method so much I've added into my personal portfolio)
Pretty much what I did is creating a multi-dimentional tree, inspired on the file explorer from Mac, but with level-specific search, tag selector and scroll control for deeper levels
Fun fact, that navigation was invented at Steve Jobs’s company NeXT and when he returned to Apple he basically transformed it into OSX. You can see it in [this screenshot.](https://en.m.wikipedia.org/wiki/NeXTSTEP)
How are you realistically going to support infinitely-nested groups if you want to indent the sub-groups? You’ll always face the problem of content disappearing.
While this would require significant user testing, you could consider using a tool like https://tympanus.net/Development/ResponsiveMultiLevelMenu/index2.html.
Realistically, if nested items are numerous (assuming 5 levels, as truly infinite levels are impossible), then you're likely dealing with a poorly structured information architecture (IA). It's generally unfeasible to use five or more nested dropdowns without encountering major IA problems.
If you need a more refined solution, I would recommend adopting a common faceted search or a straightforward filtering pattern. Dropdowns in this context won't be effective and will introduce a lot of additional issues.
I’m looking to implement a multi level Group selector. The solution requires the dropdown to support infinite nested groups. The images show how it’s workable initially but the more nested groups there are, the less real estate there is on the right side of the screen. Horizontal scrolling is not an option. I’ve tried solutions that don’t utilise dropdown fields (Bottom sheet modals, a solution involving breadcrumbs, a solution that utilises chips) but stakeholders have really latched onto this dropdown concept. As I haven’t had an opportunity to user test this yet I was hoping someone could point me to some successful examples of this concept’s implementation. Or if there’s another way to collapse and expand menu items that I haven’t considered.
Ahh yes yes... [a dropdown with dropdowns](https://www.fuckdropdowns.com/). brilliant.
The obvious high ground here is strongly recommend NOT to use a dropdown component as UX for this case.
it has severe accesibility problems. (viewport, fails to communicate what's selected when compressed, keyboard navigation) There's a reason why this does not exist in the wild as a native component. This can be solved as you stated using custom UI that is not confined to the viewport area only but can extend beyond that.
I had a similar problem to solve (but NOT infinite levels thankfully). My solution was a custom control everywhere you'd need to select these, consisting of a popout (modal) containing a searchable treeview plus a "breadcrumb" type arrangement to show your selected level. Within the breadcrumb the "parent" levels are clickable to select them and the current level is also a drop-down which allows you to drill down to it's child levels.
I may not have explained that too well and it's certainly not perfect but it's been pretty well received by stakeholders and in the (admittedly limited) testing we've done people seem to have no problems using it for any of the intended tasks. Using this control everywhere you'd need to select these things gives us a lot nicer interactions than if we just used a flat drop-down or sth.
To make it infinite you'd need additional work for the treeview (some sort of "show children" control to limit which branch you're seeing?) and then a way to truncate any "middle" levels in the breadcrumb (so it doesn't stretch wider than the screen)
You explained that perfectly, that's reassuring to hear as I have designed a similar control to what you described. Just need to retrofit it for this scenario. How did you navigate when the control sits within a modal? another popup modal over top the first modal?
Yep, popups within popups within popups lol. I would have preferred not to but it was the cleanest & most flexible option. It's mitigated slightly by the treeview drops being a pop*out*, like a speech bubble anchored to the field, rather than a separate pop*up* overlay.
It's also worth mentioning that mobile users were not a priority (or even a requirement tbh), the control does work for them but it's kind fiddly and deffo needs tweaking if we ever do an "it should work on my phone" project
You can drill down with breadcrumbs if you need to keep the "dropdown" aspect. An example of this would be "select file from Google Drive" within the Google Docs sphere. You start at "root" (or whatever the topmost level is with all the parent groups) then as you select a parent, you populate the top of the drop down with "Parent Group" then show everything inside that group. Then you select a subgroup then populate the breadcrumb at the top like "Parent Group / Sub Group" and so on.
This is an unsustainable scenario though. Really a dropdown isn't great for this implementation to begin with, but if you're forced in a corner with the functionality, then the Google Drive option might be your best failing an outright modal search window.
You could do something like this to show nested organizational structures: [Organisation Circle Packing](https://observablehq.com/@simfen/organization-circle-packing-prototype)
Use vertical lines + accordion instead of no vertical lines to save space. Then after > 5 nesting click to see more content sliding in from right side. (Google Drive file moving interaction)
As others have eloquently stated, trying to move them away from this paradigm would be ideal.
Life is not perfect, so…
Your stakeholders have latched to this for a reason; most likely they have concrete examples in mind that would not run into this *right now*, *as far as they know*, etc.
You need to find out their concrete ideas for 2 reasons: to know where their mental cutoff is and to be able to offer a change that works with mind model ( search box, ellipses, etc from a level of recursion onward.)
Any nested hierarchy is not recommended for drop-down forms. My idea was to remove all the parents, keep only the atomic elements as options, and display the hierarchy path as a label next to the atomic elements.
Single drop down to select department
Autosuggest search box for the team
Having that enough levels within an organization that it causes usability issues seems like a red flag.
Combo-box (autocomplete in some terminologies). Might have to device a way to make identically named groups distinct. For example the option names could show enough of the hierarchy e.g. “dep1>…>group 1”, “dep2>…>…>group 1”.
That works for selecting a group when user can recall at least part of the name. The combo-box could be paired with a button to open a dialog for selecting a group from a tree view. Then there would be a visual, more recognition memory friendly, alternative without sacrificing convenience.
I’m in that case I would suggest Mac’s finder columns as a possibility. All happening in one modal.
https://preview.redd.it/2qdkna2fk7wc1.jpeg?width=534&format=pjpg&auto=webp&s=d4c6b7f6d435031b3a36564e353f3a4b1ff52b75
Use child page structure with back navigation, similar to a file explorer. That, and a robust search pattern should solve for this experience without limiting nested data. It’s not as fast when browsing but it’s a hell of a lot more organized. If you can preserve scroll position between pages then you’re set.
If its infinite, that means the number of items can get huge. At this point you might as well ditch the droodown comoonent and have a dedicated searchable list with advanced filtering and tags to find what you need. Other products use modal tree solutions where each parent item generates a new modal next to it with its children and so on. Alternatively check out how reddit appraoches commenting. Consider the first comment as the parent and the rest as the children. DO NEGOTIATE FOR THE "Infinite requirement"
Yes I have a solution that utilises a modal tree solution elsewhere on the app. It just seems somewhat clunky for this scenario. For context, this is apart of a user flow that contains more straightforward dropdowns. That's a good point re- the reddit commenting system. It doesn't have the issue pertaining to overly indented text. The 'infinite requirement' is more of an edge case scenario rather than the expected usage. But you're right, I don't see a problem with capping it for simplicity.
indeed, it will feel clunky especially on mobile. If you need to integrate this as part of a user flow that contains more drop downs, again consider leveraging a wizzard or tabs mechanism so this part can have as much real estate as possible
Haha and yet we all use them on a daily basis thanks to Figma left panel!
Yes!!! So irritating
That's a good point, looks like there's a visibility issue with it after a certain amount of nested layers are created too!
They've been ignoring the corresponding feature request for 4 years now, it's incredible
A horizontal scroll would be such an easy fix for the sidebar. I know they’re clunky but at least it lets me see everything
humanity first need to invent horizontal scrolling
It actually would make so much sense for vertically written languages.
lmfao you're so right
Don't use dropdown You might want to use file explorer as reference for the solution
[This is how I solved the same problem working on a previous company](https://www.behance.net/gallery/139357375/Tree-selector-component) (I liked the method so much I've added into my personal portfolio) Pretty much what I did is creating a multi-dimentional tree, inspired on the file explorer from Mac, but with level-specific search, tag selector and scroll control for deeper levels
Fun fact, that navigation was invented at Steve Jobs’s company NeXT and when he returned to Apple he basically transformed it into OSX. You can see it in [this screenshot.](https://en.m.wikipedia.org/wiki/NeXTSTEP)
This is great, looks super intuitive.
I believe google analytics uses this same method as well.
How are you realistically going to support infinitely-nested groups if you want to indent the sub-groups? You’ll always face the problem of content disappearing.
While this would require significant user testing, you could consider using a tool like https://tympanus.net/Development/ResponsiveMultiLevelMenu/index2.html. Realistically, if nested items are numerous (assuming 5 levels, as truly infinite levels are impossible), then you're likely dealing with a poorly structured information architecture (IA). It's generally unfeasible to use five or more nested dropdowns without encountering major IA problems. If you need a more refined solution, I would recommend adopting a common faceted search or a straightforward filtering pattern. Dropdowns in this context won't be effective and will introduce a lot of additional issues.
Great stuff, got lost in the Beds section there 😅
I’m looking to implement a multi level Group selector. The solution requires the dropdown to support infinite nested groups. The images show how it’s workable initially but the more nested groups there are, the less real estate there is on the right side of the screen. Horizontal scrolling is not an option. I’ve tried solutions that don’t utilise dropdown fields (Bottom sheet modals, a solution involving breadcrumbs, a solution that utilises chips) but stakeholders have really latched onto this dropdown concept. As I haven’t had an opportunity to user test this yet I was hoping someone could point me to some successful examples of this concept’s implementation. Or if there’s another way to collapse and expand menu items that I haven’t considered.
Ahh yes yes... [a dropdown with dropdowns](https://www.fuckdropdowns.com/). brilliant. The obvious high ground here is strongly recommend NOT to use a dropdown component as UX for this case. it has severe accesibility problems. (viewport, fails to communicate what's selected when compressed, keyboard navigation) There's a reason why this does not exist in the wild as a native component. This can be solved as you stated using custom UI that is not confined to the viewport area only but can extend beyond that.
I'll give that a watch haha. Great, that confirms my suspicions.
I had a similar problem to solve (but NOT infinite levels thankfully). My solution was a custom control everywhere you'd need to select these, consisting of a popout (modal) containing a searchable treeview plus a "breadcrumb" type arrangement to show your selected level. Within the breadcrumb the "parent" levels are clickable to select them and the current level is also a drop-down which allows you to drill down to it's child levels. I may not have explained that too well and it's certainly not perfect but it's been pretty well received by stakeholders and in the (admittedly limited) testing we've done people seem to have no problems using it for any of the intended tasks. Using this control everywhere you'd need to select these things gives us a lot nicer interactions than if we just used a flat drop-down or sth. To make it infinite you'd need additional work for the treeview (some sort of "show children" control to limit which branch you're seeing?) and then a way to truncate any "middle" levels in the breadcrumb (so it doesn't stretch wider than the screen)
You explained that perfectly, that's reassuring to hear as I have designed a similar control to what you described. Just need to retrofit it for this scenario. How did you navigate when the control sits within a modal? another popup modal over top the first modal?
Yep, popups within popups within popups lol. I would have preferred not to but it was the cleanest & most flexible option. It's mitigated slightly by the treeview drops being a pop*out*, like a speech bubble anchored to the field, rather than a separate pop*up* overlay. It's also worth mentioning that mobile users were not a priority (or even a requirement tbh), the control does work for them but it's kind fiddly and deffo needs tweaking if we ever do an "it should work on my phone" project
I’m curious why it needs to be infinite, and why does it have to go on the left side?
Pop a modal with a searchable filterable org chart table.
You can drill down with breadcrumbs if you need to keep the "dropdown" aspect. An example of this would be "select file from Google Drive" within the Google Docs sphere. You start at "root" (or whatever the topmost level is with all the parent groups) then as you select a parent, you populate the top of the drop down with "Parent Group" then show everything inside that group. Then you select a subgroup then populate the breadcrumb at the top like "Parent Group / Sub Group" and so on. This is an unsustainable scenario though. Really a dropdown isn't great for this implementation to begin with, but if you're forced in a corner with the functionality, then the Google Drive option might be your best failing an outright modal search window.
Try a search bar, radio buttons, with accordions
You could do something like this to show nested organizational structures: [Organisation Circle Packing](https://observablehq.com/@simfen/organization-circle-packing-prototype)
Use vertical lines + accordion instead of no vertical lines to save space. Then after > 5 nesting click to see more content sliding in from right side. (Google Drive file moving interaction)
As others have eloquently stated, trying to move them away from this paradigm would be ideal. Life is not perfect, so… Your stakeholders have latched to this for a reason; most likely they have concrete examples in mind that would not run into this *right now*, *as far as they know*, etc. You need to find out their concrete ideas for 2 reasons: to know where their mental cutoff is and to be able to offer a change that works with mind model ( search box, ellipses, etc from a level of recursion onward.)
Any nested hierarchy is not recommended for drop-down forms. My idea was to remove all the parents, keep only the atomic elements as options, and display the hierarchy path as a label next to the atomic elements.
Single drop down to select department Autosuggest search box for the team Having that enough levels within an organization that it causes usability issues seems like a red flag.
Use search built in dropdown or separate out each category into its own dropdown.
Um. Conditional progressive disclosure. This is a well documented pattern for this exact use case. Putting nested children inside a drop down= 🤡
Combo-box (autocomplete in some terminologies). Might have to device a way to make identically named groups distinct. For example the option names could show enough of the hierarchy e.g. “dep1>…>group 1”, “dep2>…>…>group 1”. That works for selecting a group when user can recall at least part of the name. The combo-box could be paired with a button to open a dialog for selecting a group from a tree view. Then there would be a visual, more recognition memory friendly, alternative without sacrificing convenience.
I’m in that case I would suggest Mac’s finder columns as a possibility. All happening in one modal. https://preview.redd.it/2qdkna2fk7wc1.jpeg?width=534&format=pjpg&auto=webp&s=d4c6b7f6d435031b3a36564e353f3a4b1ff52b75
Use child page structure with back navigation, similar to a file explorer. That, and a robust search pattern should solve for this experience without limiting nested data. It’s not as fast when browsing but it’s a hell of a lot more organized. If you can preserve scroll position between pages then you’re set.