[Design system V2] Content Tabs

[nloureiro]

Intro

This issue is a part of the Design System V2 Epic and can be assigned to anyone who wants to collaborate.
You can use the comments to sign that you want to work on this, and this issue can be assigned to you.
If you have any questions about it, please don't hesitate to reach out on the comments or on our discord

Description

There are different methods of displaying tabular content in production, and this aims to unify how to use tabs in different situations for a more consistent user experience.

[Ethereum.org](http://ethereum.org/) tabs can range from "simple/classic tabs" to “stablecoins” page tabs that feature more diverse content.

Tabs are a great tool for creating a more consistent user experience, and it is important to understand the different options available in order to make the most out of their use.

For example, tabs can be used to organize large amounts of information in a more organized, intuitive way, or to make it easier for users to navigate.

• Type: unification design
• Difficulty: 8 out of 10

Link to the Figma file to be worked on

workflow

These are the main steps for each task.

1. Use a separate Figma file.

   • made by the team and liked here should be

2. Identify on which pages the component is used.

   • This can be made collaboratively and consists of screenshots/links to the pages where these components are already in use. Note that we can propose the unification of similar components in one if we find that the UX/UI justifies that’s the core unification goal of the Design system V2.

3. Identify the chakra component to be used as a base (if any)

   • We use chakra UI as a base framework, and if we can match the new design with an existing UI component in chakra, it’s a good call. If not, we can build one, but this should be something to identify now that will ease the implementation.

4. Work on the design.

   • This is where we build the new proposal that will be a new component in the design system, never forgetting the different screen sizes, behavior states, and themes.

5. Test and validate the new component on Figma.

   • Before closing the design, we need to test some real use cases. I suggested having some production screenshot as the base and building it on a Figma page with real content to test the live application of the new design.

6. Validation and feedback.

   • At this point, we are ready to validate and collect feedback. We should act upon this and have the best proposal possible.

7. Spec to handover to code.

   • This will be the final step, where we review the file from the perspective of a handover to the design system master file and to the code or storybook for code development.

8. Merge with the master Figma file of the Design system.

   • This step will be made by someone from the core team because there are some things that could be improved in how we can onboard external contributors to the Figma team. It’s a Figma thing that we can’t change for now.

9. Close the issue and publish the Design system update on the Figma community**.

   • For the last action, we need to close the issue and update the Design system on the Figam community file. At this point, another issue might need to be created to update the storybook and the code to reflect this new design.

[github-actions]

This issue is stale because it has been open 45 days with no activity.

[ddannehh]

Picked this one up, will report back soon. ✌️

[ddannehh]

I've been digging around the website a bit to find the examples and saw an additional case where tabs were used.
Screenshot below as a reminder for the cases :)

I'll go over each case with some feedback and the proposed designs to provide some additional context for the final components.

A more easy to digest version of the result can be found on the Final Proposal page in Figma :)

Case 1

While the key blue fill is a real eyecatcher, I personally think it's a bit too much for a tab since it's not a real Call-to-Action, like a primary button, and shouldn't require that much attention.
The blue bottom border of the tab container together with the rounded border around the content looks a bit unharmonious to me.
Additionally in terms of placement, it sticks a bit to the previous section and looking somewhat out of place. Adding a bit more whitespace and/or a title would probably do it more justice.

So with the above considered, and fiddling around with some alternatives, I'd suggest going with the most basic solution.

Mobile behaviour

Currently, the words just break into multiple lines and after that the whole tab-bar will render out of the viewport. For this specific case it will display fine on most devices but will have problems on smaller ones or when more tabs are added.

In terms of making it scalable, I guess this one depends on how far we want to go with this but I guess horizontal scroll functionality would be preferred when there are more items. Ideally with an indication that more tabs are available. This can be achieved by making sure part of an exit tab is visible, suggesting there is more. It will often be the case by default but there's always a chance a tab starts outside the viewport. This could be countered by dynamically adjusting the whitespace a bit between tabs or using a fade technique.

Tightening the page outer margins on the sides on the mobile breakpoint would also be a great addition imo (The navigation bar does this). It's currently 32px on each side, perhaps could be reduced to let's say 16px?

That being said, I'm personally not convinced the tab component is the right choice for this specific section. Tab labels are preferably short and shouldn't contain any questions. The FAQ component or something similar is maybe a better fit? Not sure.. In telling the "What is Ethereum" story it could even be reformatted into regular paragraphs since it's such key knowledge? Anyway, this is besides the point of the actual assignment and more of a content thing.

Case 2

Vertical layout variant of tabs in case 1.

I've also added a tab variant which enables a coloured background to the active tab.

Mobile behaviour

Fallback to menu button to switch tabs.

Perhaps there's something to be said to swap out the hamburger into a select icon for this usecase. Hamburger feels more top level navigation like, and could feel like you'll navigate away from current context, which isn't the case.

Case 3

This is quite an expressive visualisation! I don't think this should be formalised as a component in the design system but can easily be aligned with case 2.
However, depending on how case 2 is built it shouldn't be too much of a problem to theme it ad-hoc for some more "expressive" use-cases where necessary. For this case it could be done by using the "Coloured background" + "XLarge" variant of the tab component and go from there by applying the necessary to other elements.

Vanilla styled component use

A more expressive modded version (not 100% sure it's possible for contributing devs to overwrite component code)

As a side note: There's also a bit of a UX issue in the current implementation when clicking the tabs on desktop. The order of the tabs gets repositioned, potentially leaving the user confused on where they are and what to click next. Also, the tabs are not accessible through keyboard (no tab-index).
This issue is also visible on a similar component at the bottom on the dApps page: https://ethereum.org/en/dapps/?category=finance
No problem on mobile.

Case 4

Basically an additional visualisation of the tab component, which isn't included in the DS but could be definitely added for some visual diversification. This one made me add an XLarge size for all tabs. The dropshadow on the active variant isn't currently included in the component style and would rather be an ad-hoc implementation choice.

To round up and support the above usecases the following components have been designed:
Tab & Tab Bar Component:
• 2 Tab types (Default & Pill)
• 2 Sizes (Regular & XLarge), skipped Large since there's currently no such case but could be added ofc.
• Optional Active Color Background (Blue scheme by default, could add predefined colours or to be modded by devs)
• Optional Icon property
• Horizontal & Vertical direction property
• Light- & Dark-Mode

Tab

Tab Bar

The actual use could vary and ideally would allow for some customisation together with the tab-content to fit the needs:
• Boxed/Unboxed (borders) or section fill color
• Background colors & widths of tab bar or content container
• Perhaps mobile behaviour, keep showing tabs vs dropdown select since the UX heavily depends on the amount of tabs, length of labels etc.
• ...

Some examples of these can be found on the Design Work page in Figma.
I guess all those variations should not be formalised as components but rather given as guidelines in the DS to inspire contributors.

Feedback welcome! Cheers guys! ✌️✌️

[nloureiro]

oh my!! this is awesome!

Thank you!!! I need to set some time to review and merge it o the main file!!!

but at a glance, it looks awesome!!

[ddannehh]

You're welcome!
They definitely need to be looked at when considered for the main DS file since the disconnect between the two and not being able to use the main files' components/vars/styles in this.

[nloureiro]

You're welcome! They definitely need to be looked at when considered for the main DS file since the disconnect between the two and not being able to use the main files' components/vars/styles in this.

@ddannehh, let me know if there is anything else you want to work on to complete the DS. I'm open to ideas or components that I might have missed or created an issue for.

[ddannehh]

@ddannehh, let me know if there is anything else you want to work on to complete the DS. I'm open to ideas or components that I might have missed or created an issue for.

Coincidently I've just shared some thoughts on another ticket! :D #9436

[ddannehh]

@nloureiro I've added these in the main DS file and relinked all styles/vars, should be working :)

[github-actions]

This issue is stale because it has been open 30 days with no activity.

[wackerow]

Hey folks! Circling through; @nloureiro are we waiting on a review from you for any of this? What are next steps here?