Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC][Joy][Tabs] The default design of tabs is not the common we could expect #36782

Closed
marcpachecog opened this issue Apr 5, 2023 · 9 comments Β· Fixed by #36843
Closed

[RFC][Joy][Tabs] The default design of tabs is not the common we could expect #36782

marcpachecog opened this issue Apr 5, 2023 · 9 comments Β· Fixed by #36843
Assignees
Labels
component: tabs This is the name of the generic UI component, not the React module! design: joy This is about Joy Design, please involve a visual or UX designer in the process discussion RFC Request For Comments

Comments

@marcpachecog
Copy link

What's the problem? πŸ€”

When you think of a Tab component, your head will bring to you something like this:

Captura de Pantalla 2023-04-05 a las 11 47 35

But instead, the default design looks more like a ToggleButtonGroup component:

Captura de Pantalla 2023-04-05 a las 11 50 18

What are the requirements? ❓

No response

What are our options? πŸ’‘

No response

Proposed solution 🟒

Add a prop to select if you want the classic tab design or the toggle button group and let the classic one as the default.

Resources and benchmarks πŸ”—

No response

@marcpachecog marcpachecog added RFC Request For Comments status: waiting for maintainer These issues haven't been looked at yet by a maintainer labels Apr 5, 2023
@marcpachecog marcpachecog changed the title [RFC][Joy][Tabs] The default design of tabs is not the common we expect [RFC][Joy][Tabs] The default design of tabs is not the common we could expect Apr 5, 2023
@zannager zannager added component: tabs This is the name of the generic UI component, not the React module! design: joy This is about Joy Design, please involve a visual or UX designer in the process labels Apr 6, 2023
@mnajdova mnajdova assigned siriwatknp and danilo-leal and unassigned mnajdova Apr 6, 2023
@siriwatknp
Copy link
Member

Appreciate for the feedback! One of the core principle of Joy UI is unopionated in terms of design. We try to ship as less CSS as possible and leverage the global variant concept.

I believe that Joy UI will bring great experience for customization, that's why I spend so much time adding common examples to ensure that customization is straightforward and I feel that the Tabs with an indicator should be a customized version of the current Tabs.

Talking about the default design, I found a lot of popular examples that looks like toggle button group:

@siriwatknp siriwatknp added discussion and removed status: waiting for maintainer These issues haven't been looked at yet by a maintainer labels Apr 7, 2023
@Studio384
Copy link
Contributor

I agree with @marcpachecog here. This is a component where Joy feels weirdly opinionated, and before the example was there it was honestly a pain in the a-- to overwrite the styling without breaking anything, especially for someone who wasn't yet familiar with Joy at the time. A tab design that has its own container will rarely work when someone wants to implement their own design language.

The component also just looks... off(?), maybe because of the shadow of the individual tabs.

Anyways, iOS's tabs don't look anything like this?

The closest thing Apple's design guidelines have are Segmented Controls but they explicitly call that a button, not a tab. macOS does have this kind of design as its Tab View component, but that's not supported on iOS

@siriwatknp
Copy link
Member

@Studio384 this is the iOS design (Tab views) I mentioned.

This is a component where Joy feels weirdly opinionated, and before the example was there it was honestly a pain in the a-- to overwrite the styling without breaking anything, especially for someone who wasn't yet familiar with Joy at the time

Really appreciate your feedback and it is true for me as well when I need Tabs that looks like the default of Material Design. I am afraid that if we change the default design of Tabs to look like Material, we will have the same issue when someone wants to customize the Tabs to look like iOS Segmented controls (that's the pain I have when I used Material UI).

What we can do now is to remove the shadow from the Tab, then the customization should be easier by changing variants:

<Tabs>
  <TabList variant="plain">
    <Tab variant="plain">

In the future, Joy UI will provide TabIndicator to create the underline that match the selected tab's width.

cc @danilo-leal

@Studio384
Copy link
Contributor

@Studio384 this is the iOS design (Tab views) I mentioned.

I'd just like to point out that that control is very specifically not supposed to be used on iOS or any of its variants (as noted on that page). It's a macOS-only thing (and something Apple has been (slowly) moving away from). πŸ˜‰

Really appreciate your feedback and it is true for me as well when I need Tabs that looks like the default of Material Design. I am afraid that if we change the default design of Tabs to look like Material, we will have the same issue when someone wants to customize the Tabs to look like iOS Segmented controls (that's the pain I have when I used Material UI).

I see where this comes from, but I don't feel like just because it would have an underline would make it Material Design-ish. Fluent Design and various other design systems also use underlines for their tab controls and are in my opinion very distinct. I feel like these design systems differentiate more in how it animates and interacts (e.g. if MDs ripple effect is disabled, MUIs Tabs already feel like a very different design to me).

Going with the current tab design just for the sake of "it shouldn't look to similar to Material's design" doesn't seem like a good argument to me. I'd say how a control looks should be decided in function of the components it appears next to, not in function of the components of another system. Not that that means underline-style tabs are the right decision or this segmented-style design is the wrong option to go with, just saying that it shouldn't be an argument for or against either.

In the end, I don't really care what they look like and either style could look great. I just saw this issue and wanted to chime in to say that this current control indeed isn't that common and it felt a bit off compared to the rest of Joy, and that overwriting the styling of this component was a bit of a pain (for beginners), maybe it can be made a bit less complex/easier to customize without having to resort to throwing it all out and going with the unstyled variant. :)

@siriwatknp
Copy link
Member

In the end, I don't really care what they look like and either style could look great. I just saw this issue and wanted to chime in to say that this current control indeed isn't that common and it felt a bit off compared to the rest of Joy, and that overwriting the styling of this component was a bit of a pain (for beginners), maybe it can be made a bit less complex/easier to customize without having to resort to throwing it all out and going with the unstyled variant. :)

Thanks for the detailed feedback. I will take it into account on how to make it easy and flexible for customization.

@danilo-leal
Copy link
Contributor

This is such an exciting issue ⎯ thanks to both @marcpachecog & @Studio384 for chiming in and discussing it! I feel like, at the end of the day, Joy should optimize for what's most common out there, and the Tab look y'all have been suggesting is definitely, at least as far as I can see, the most common design there is. Even if you look outside of the realm of extensively documented design systems and start looking into tab usage across products, you'll see that's indeed the design:

Stripe

Screen Shot 2023-04-10 at 08 31 25

Vercel

Screen Shot 2023-04-10 at 08 32 02

Twitter

Screen Shot 2023-04-10 at 08 32 22

Notion

Screen Shot 2023-04-10 at 08 31 48

@siriwatknp I feel like when it comes to the opinionated discussion we were having, this issue sheds light on it: the design tokens should be flexible but "avoiding to look like Material" is also not necessarily the end goal. Even with the same layout, different tokens can convey a different look and feel, and that can be good enough!

So, in conclusion, I'd definitely make the default tabs, the ones you'd get out of the box, to be similar to the designs above. And every other component, too, as a principle: follow the most common layout out there and have other specific visuals as customization options (e.g. iOS tab views/group). 😬

@siriwatknp
Copy link
Member

@danilo-leal Alright, I have included this issue for the stable release!

@siriwatknp
Copy link
Member

@marcpachecog Here is the preview of the revised Tabs https://deploy-preview-36843--material-ui.netlify.app/joy-ui/react-tabs/. in #36843

@marcpachecog
Copy link
Author

@siriwatknp Wow, it looks good! Great work :)

I have some observations:

  • When the selected tab is set to inset, the underline disappears, looks a bit strange.
Captura de Pantalla 2023-07-04 a las 14 16 02
  • We could maybe add some radius to the borders? That way the component will look more consistent with the library.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: tabs This is the name of the generic UI component, not the React module! design: joy This is about Joy Design, please involve a visual or UX designer in the process discussion RFC Request For Comments
Projects
None yet
6 participants