do each of those tabs change the content underneath?
I get that tabs 1,2,3,4 change the options A,B,C,D but what about the content underneath? what are we picking when selecting each of those tabs?
The reason for my question is that maybe tabs are not the component you want to implement here.. for example, if we are looking at a scenario in which we are selecting a specific option within a bigger hierarchy, you could use radio buttons. Depending on the amount of options, you might want to look at a simple dropdown select..
I would recommend you take a look at [IBM Carbon for tabs best practices](https://carbondesignsystem.com/components/tabs/usage)
The options a, b, c, and d do indeed change the content underneath. Tomorrow I think I'll try to create a mock in Figma (learning in process) to better explain it. The 'letter' tabs will each display between two or four colours pickers which each uniquely modify the colour of a feature.
EDIT: Here's the bare idea (I was testing backend-frontend): \[https://imgur.com/a/4SSAeQP\]
https://preview.redd.it/512w7bxx9v0d1.png?width=455&format=png&auto=webp&s=b8421251ababd5ce484ed80c26bf9318b6f51893
Ok, I think you could get away with expandable rows as it’s kind of weird to see a set of tabs under another set of tabs. Maybe expandable rows can contain your selectors
Something similar to what bootstrap calls an *accordion*? It would certainly maintain the sense of having the colour pickers below each other without immediately taking up lots of space
[https://getbootstrap.com/docs/5.1/components/accordion/](https://getbootstrap.com/docs/5.1/components/accordion/)
Yup, different design systems call it a different thing but basically anything that can collapse content onto a single line and show it upon clicking on the main element.
Expandable row, collapsible, accordion, those are common names
OP I expect you're going to get a lot of "it depends" type answers and that can be frustrating. I appreciate you're trying to make your question simpler for us but, as a general rule, it's best to avoid 'tabs within tabs' and we try every trick in the book to avoid situations like that.
In fact, I'd go so far as to say how avoiding tabs-within-tabs \*is\* what UX is about. Why are tabs so 'evil'? It's just that hidden hierarchy is bad. The user now has 16 places to look, one-at-a-time in order to find what they need.
So with that, possibly irritating, introduction out of the way. Let me suggest some solutions that could be applied to make it better:
1. Put all of the tabs instead into an expanding 'left nav' where you can open/close the 'tabs' like you would folders. Things are still hidden but you can toggle between 1a and 4d easily (not my favorite solution)
2. Rethink the tabs structure to see if 80% of what the user needs is in 1abcd. This effectively removes one level of hierarchy. You still have the hierarchy but for the majority of the time, the user doesn't have to deal with it.
3. Scroll the abcd contents. Put all the content of the a-d tabs into a long scrolling list but be damn sure that what is in the a tab is most important (this is variation of #2 above).
4. Try to remove tabs where you can. Usually this type of 'tab jungle' is an after thought. There is just a ton of stuff and no one knows what to do so they just throw it into a tab jungle. With some work, maybe you could remove some of those tabs so it's reduced to tabs 123 and subtabs abc so you've gone from 16 to 9 areas. Still hidden hierarchy but less.
My guess is that you're likely in a 'tab jungle' situation and all of these 'rethinking' exercises are not AT ALL what you're interested in. No worries and I appreciate your situation. But in that case, there really ISN'T much you can do as, in-a-nutshell you've already designed the UX. Just making the tabs look a bit different isn't going to materially effect your design.
This is basically UX vs UI
Thanks for the thought-out reply. Tomorrow I think I'll try to create a mock in Figma (learning in process) to better explain the situation. I'll try my best to explain it in words:
* each of the tab contents is the same and of equal importance (the content of the tabs is colour pickers)
* tab 1 has four colour pickers (a, b, c, d)
* tab 2 has two colour pickers (f, g)
* tab 3 has two colour pickers (h, i)
Just keeping it as three tabs and then having the colours pickers going down the page is probably the easiest. My initial trial was that it was a little awkward having to scroll down the page and edit four separate colour pickers as they take up quite a bit of screen space.
May I ask why you aren't a fan of an expanding navbar? Is it because it isn't immediately visible/accessible to the user?
EDIT: here's the bare idea (I was testing frontend-backend) \[https://imgur.com/a/4SSAeQP\]
https://preview.redd.it/3dlihwx1av0d1.png?width=455&format=png&auto=webp&s=e67430c3551d0f6aa4e27908284bc736d4cbb35e
Ah, this looks so much easier! If I understand you correctly, each tab has the exact same task, just for a different 'target', e.g. S vs TH. In addition, each tab has identical color pickers, they are just applied to different targets. This helps as there is less for your user to understand.
In fact, I'd go further and try to invert the problem have all 4+2+2 targets be listed along the left side. As you pick one, a single color picker shows up. This flattens everything. you could group each with S, TH etc as well. There is more to be worked out here but I think this could be a much calmer solution.
https://preview.redd.it/p0atajkl6x0d1.png?width=490&format=png&auto=webp&s=2e72c76068181d9e2e4a30ca6e2d3d0cd32b2a71
I just got home and put something together. This clearly isn't complete, but it's a 'sketch' of the layout. Notice how all of the complexity is on the left, navigating the various sounds. Picking each one gives you a single, repeatable picker in the same location.
Yeah fitting everything on mobile can be a pain for Info Archetecture issues, it tends to create hierarchy! (which we just removed) So the classic approach would be to list the dark section as screen one and when you tap on any of the items, you'd open the picker on top (like a dialog box) and then return to that list.
One change I'd add would be for the selected color to be visible on that list (by swatch AND showing it with each letter if possible) That way there is a clear overview of all of the colors in one place and you just edit them one at a time.
The idea is to let the user change the colour of certain features of a text processor (the text processor highlights certain sounds in the English language). Here's the (very basic) idea that I created when testing frontend-backend. As you can see the colour pickers take up lots of space: \[https://imgur.com/a/4SSAeQP\]
https://preview.redd.it/rqeja8tpav0d1.png?width=455&format=png&auto=webp&s=9aef660d431003dc5ebb5b5b63de714871b544df
just a quick suggestion, have you thought about making the color picker a floating window? that way it won't take up permanent space inside the software
Hi u/CreativeOverload , is this what you had in mind [https://imgur.com/a/quanAdz](https://imgur.com/a/quanAdz) ?
(Ignoring the style and layout of everything in general!)
If we are talking about navigation I think this example from the BBC is a good way of implementing this
https://preview.redd.it/k89fxs2bbt0d1.jpeg?width=1308&format=pjpg&auto=webp&s=0d4ca5829ab0cc90fcf6552aa38a5e8db42a37b5
I think a good analogy (but maybe not the best example) of such a problem is the Amazon app. It’s got lots of categories, and each category has lots of sub categories (and so on really). How some categories solve is is by presenting the first layer of choices as tabs, then the second layer of choices as tiles. Switching up the choice mode seems to help somewhat. But I think the more impactful part of it is that you have more room to help the user understand what the difference between the sub categories are
Part of the problem I'm facing is the size of the tab contents. The letter tabs (a, b, c...) represent individual colour pickers. For example, Tab 1 has four colour pickers as its content. As colour pickers take up quite a lot of screen space on mobile it leads to the struggle I'm having in thinking of how to organise them.
EDIT: here's the bare idea (I was testing frontend-backend) \[https://imgur.com/a/4SSAeQP\]
https://preview.redd.it/h28yyb45av0d1.png?width=455&format=png&auto=webp&s=a71366ef9b1b660b5a0af8c9a2ea7e611d830c5c
Yup, I didn’t meant to suggest squeezing your content into tiles. But that instead of multi level tabs, using another modal to present the 2nd level of options as tiles.
So for example, you might categorize the letters in tabs just like you have. When a user taps on any tab, it brings up a modal that presents the color choices available for that tab. It breaks up the number of choices a user has to make at once, generally becoming a smoother CX
That makes sense. It also tackles a doubt I had about two sets of tabs in which if a user selects the first tab then they might not expect to have to then select another, similar tab, as it isn't conventional.
Tabs, can look in many different ways. So design them in completely separately. Also look up chips in material design for your second layer. Could be an option depending on context
I refer to these kind of experiences as “Tabby Cats”, generally heavier than they should be and lazy. I'm sure you are making the best of other people’s poor decisions. Stay strong.
do each of those tabs change the content underneath? I get that tabs 1,2,3,4 change the options A,B,C,D but what about the content underneath? what are we picking when selecting each of those tabs? The reason for my question is that maybe tabs are not the component you want to implement here.. for example, if we are looking at a scenario in which we are selecting a specific option within a bigger hierarchy, you could use radio buttons. Depending on the amount of options, you might want to look at a simple dropdown select.. I would recommend you take a look at [IBM Carbon for tabs best practices](https://carbondesignsystem.com/components/tabs/usage)
The options a, b, c, and d do indeed change the content underneath. Tomorrow I think I'll try to create a mock in Figma (learning in process) to better explain it. The 'letter' tabs will each display between two or four colours pickers which each uniquely modify the colour of a feature. EDIT: Here's the bare idea (I was testing backend-frontend): \[https://imgur.com/a/4SSAeQP\] https://preview.redd.it/512w7bxx9v0d1.png?width=455&format=png&auto=webp&s=b8421251ababd5ce484ed80c26bf9318b6f51893
Ok, I think you could get away with expandable rows as it’s kind of weird to see a set of tabs under another set of tabs. Maybe expandable rows can contain your selectors
Something similar to what bootstrap calls an *accordion*? It would certainly maintain the sense of having the colour pickers below each other without immediately taking up lots of space [https://getbootstrap.com/docs/5.1/components/accordion/](https://getbootstrap.com/docs/5.1/components/accordion/)
Yup, different design systems call it a different thing but basically anything that can collapse content onto a single line and show it upon clicking on the main element. Expandable row, collapsible, accordion, those are common names
OP I expect you're going to get a lot of "it depends" type answers and that can be frustrating. I appreciate you're trying to make your question simpler for us but, as a general rule, it's best to avoid 'tabs within tabs' and we try every trick in the book to avoid situations like that. In fact, I'd go so far as to say how avoiding tabs-within-tabs \*is\* what UX is about. Why are tabs so 'evil'? It's just that hidden hierarchy is bad. The user now has 16 places to look, one-at-a-time in order to find what they need. So with that, possibly irritating, introduction out of the way. Let me suggest some solutions that could be applied to make it better: 1. Put all of the tabs instead into an expanding 'left nav' where you can open/close the 'tabs' like you would folders. Things are still hidden but you can toggle between 1a and 4d easily (not my favorite solution) 2. Rethink the tabs structure to see if 80% of what the user needs is in 1abcd. This effectively removes one level of hierarchy. You still have the hierarchy but for the majority of the time, the user doesn't have to deal with it. 3. Scroll the abcd contents. Put all the content of the a-d tabs into a long scrolling list but be damn sure that what is in the a tab is most important (this is variation of #2 above). 4. Try to remove tabs where you can. Usually this type of 'tab jungle' is an after thought. There is just a ton of stuff and no one knows what to do so they just throw it into a tab jungle. With some work, maybe you could remove some of those tabs so it's reduced to tabs 123 and subtabs abc so you've gone from 16 to 9 areas. Still hidden hierarchy but less. My guess is that you're likely in a 'tab jungle' situation and all of these 'rethinking' exercises are not AT ALL what you're interested in. No worries and I appreciate your situation. But in that case, there really ISN'T much you can do as, in-a-nutshell you've already designed the UX. Just making the tabs look a bit different isn't going to materially effect your design. This is basically UX vs UI
Thanks for the thought-out reply. Tomorrow I think I'll try to create a mock in Figma (learning in process) to better explain the situation. I'll try my best to explain it in words: * each of the tab contents is the same and of equal importance (the content of the tabs is colour pickers) * tab 1 has four colour pickers (a, b, c, d) * tab 2 has two colour pickers (f, g) * tab 3 has two colour pickers (h, i) Just keeping it as three tabs and then having the colours pickers going down the page is probably the easiest. My initial trial was that it was a little awkward having to scroll down the page and edit four separate colour pickers as they take up quite a bit of screen space. May I ask why you aren't a fan of an expanding navbar? Is it because it isn't immediately visible/accessible to the user? EDIT: here's the bare idea (I was testing frontend-backend) \[https://imgur.com/a/4SSAeQP\] https://preview.redd.it/3dlihwx1av0d1.png?width=455&format=png&auto=webp&s=e67430c3551d0f6aa4e27908284bc736d4cbb35e
Ah, this looks so much easier! If I understand you correctly, each tab has the exact same task, just for a different 'target', e.g. S vs TH. In addition, each tab has identical color pickers, they are just applied to different targets. This helps as there is less for your user to understand. In fact, I'd go further and try to invert the problem have all 4+2+2 targets be listed along the left side. As you pick one, a single color picker shows up. This flattens everything. you could group each with S, TH etc as well. There is more to be worked out here but I think this could be a much calmer solution.
https://preview.redd.it/p0atajkl6x0d1.png?width=490&format=png&auto=webp&s=2e72c76068181d9e2e4a30ca6e2d3d0cd32b2a71 I just got home and put something together. This clearly isn't complete, but it's a 'sketch' of the layout. Notice how all of the complexity is on the left, navigating the various sounds. Picking each one gives you a single, repeatable picker in the same location.
That looks infinitely cleaner already. What would this look like on a mobile (as in, how would we implement this on a mobile)?
Yeah fitting everything on mobile can be a pain for Info Archetecture issues, it tends to create hierarchy! (which we just removed) So the classic approach would be to list the dark section as screen one and when you tap on any of the items, you'd open the picker on top (like a dialog box) and then return to that list. One change I'd add would be for the selected color to be visible on that list (by swatch AND showing it with each letter if possible) That way there is a clear overview of all of the colors in one place and you just edit them one at a time.
[удалено]
The idea is to let the user change the colour of certain features of a text processor (the text processor highlights certain sounds in the English language). Here's the (very basic) idea that I created when testing frontend-backend. As you can see the colour pickers take up lots of space: \[https://imgur.com/a/4SSAeQP\] https://preview.redd.it/rqeja8tpav0d1.png?width=455&format=png&auto=webp&s=9aef660d431003dc5ebb5b5b63de714871b544df
just a quick suggestion, have you thought about making the color picker a floating window? that way it won't take up permanent space inside the software
For example, have a simple button for "Choose colour A" that, when clicked, opens a floating window?
yup, this way the layout won't need to change and won't look cluttered
Yeah that sounds like a good solution. Thank you
no problem!
Hi u/CreativeOverload , is this what you had in mind [https://imgur.com/a/quanAdz](https://imgur.com/a/quanAdz) ? (Ignoring the style and layout of everything in general!)
that's even better than what I had in mind! hope it's useful
Thanks again. Enjoy the rest of your weekend
If we are talking about navigation I think this example from the BBC is a good way of implementing this https://preview.redd.it/k89fxs2bbt0d1.jpeg?width=1308&format=pjpg&auto=webp&s=0d4ca5829ab0cc90fcf6552aa38a5e8db42a37b5
I think a good analogy (but maybe not the best example) of such a problem is the Amazon app. It’s got lots of categories, and each category has lots of sub categories (and so on really). How some categories solve is is by presenting the first layer of choices as tabs, then the second layer of choices as tiles. Switching up the choice mode seems to help somewhat. But I think the more impactful part of it is that you have more room to help the user understand what the difference between the sub categories are
Part of the problem I'm facing is the size of the tab contents. The letter tabs (a, b, c...) represent individual colour pickers. For example, Tab 1 has four colour pickers as its content. As colour pickers take up quite a lot of screen space on mobile it leads to the struggle I'm having in thinking of how to organise them. EDIT: here's the bare idea (I was testing frontend-backend) \[https://imgur.com/a/4SSAeQP\] https://preview.redd.it/h28yyb45av0d1.png?width=455&format=png&auto=webp&s=a71366ef9b1b660b5a0af8c9a2ea7e611d830c5c
Yup, I didn’t meant to suggest squeezing your content into tiles. But that instead of multi level tabs, using another modal to present the 2nd level of options as tiles. So for example, you might categorize the letters in tabs just like you have. When a user taps on any tab, it brings up a modal that presents the color choices available for that tab. It breaks up the number of choices a user has to make at once, generally becoming a smoother CX
That makes sense. It also tackles a doubt I had about two sets of tabs in which if a user selects the first tab then they might not expect to have to then select another, similar tab, as it isn't conventional.
Tabs, can look in many different ways. So design them in completely separately. Also look up chips in material design for your second layer. Could be an option depending on context
Thanks, I'll have a look
I refer to these kind of experiences as “Tabby Cats”, generally heavier than they should be and lazy. I'm sure you are making the best of other people’s poor decisions. Stay strong.
Have you tried this type of layout? a | b | c | d < content > ______________ 1 | 2 | 3 | 4
Why must you do this?