[Design system V2] Full width Sections

[nloureiro]

Intro

Full-width sections are a simple way to call out some information to take action in the middle of a content page or a visually rich callout to another page.

They can be used to break the page flow in a more prominent way by disrupting the content and breaking the user flow positively.

Description

Full-width sections are a way to draw the user's attention to a specific callout or piece of information, be it to take action on the page or to be directed to another page.

By breaking up the page flow and disrupting the content, these sections stand out as prominent visual elements that can be used to emphasize and guide to other pages. This technique can be especially useful when it comes to showcasing important pieces of content or drawing attention to one particular element within a page.

• Type: unification design
• Difficulty: 2 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[bot]]

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

[ddannehh]

I'll take a look at this @nloureiro

[ddannehh]

I'll take a look at this @nloureiro

Oh, someone has already been working on this and the file is locked it seems. Do we need more flexible components to support current usecases or is the provided solution by Brett sufficient?

[nloureiro]

I'll take a look at this @nloureiro

Oh, someone has already been working on this and the file is locked it seems. Do we need more flexible components to support current usecases or is the provided solution by Brett sufficient?

hey, I've started but haven't finish. https://www.figma.com/file/WdzAgxXjUV1fBRvYANoMxH/V2%2FFull-width-Sections?type=design&node-id=1%3A134&mode=design&t=70o8o5p9ixwyXQbJ-1

can you take a look and see where you can help? thank you!!

[ddannehh]

Oh @nloureiro , I see you've updated the file with the latest version for this now, must have missed this in the general DS file. Been looking at the way it is set up and have some input. Let me try to explain! :))

The name of component and ticket is currently named "Full width sections". I'm guessing it's more than that or the ticket maybe evolved over time? It seems like and effort to consolidate some of these:

• Single Call out/CTA banner (e.g. banner at bottom of homepage: Contribute to ethereum.org)
• Cards (Or at least some type of cards. There's a lot of these.)
• Single Note (Bitcoin Pizza on stablecoins page)
• More creative bullet points or features visualisation
• Entry points to other content pages
• Grid Guidelines?

When taking a step back, there's one thing they all have in common: they are all boxed content. Hear me out:

The "Box" (or tile/panel/...) could almost be like a component on itself which doesn't hold any content. However it can be used as a "background" for a section or a card. This component could have certain predefined style- or even layout-prop combinations, like bg-color, stroke, padding, interactivity (clickable as a whole or not -> could trigger animation on hover) and so on. The most common styles could be integrated in that component for consistency. But yeah, in the end it is basically just a styled <div> but an easy to understand component.

That being said, inside these boxes there could be 100's of different layout setups. Most often containing at least two of the elements below:

• Image
• Wemoji
• Icon
• Titles, subtitles, paragraphs
• Buttons
• Tags
• Links
• Lists
• ...

Each of them also could have different ordering, sizing, alignment or more complex layouts depending on the case or placement. It would be crazy to offer all these options inside a single component.

I guess the point I'm trying to make here is that perhaps it's worth considering to not try and bootstrap all this into a single component with a couple of variants but rather provide this Box component with a limited set of styles. Perhaps illustrating the use of each style depending on the context. Like: use gray variant on white background, white variant on coloured background, with dropshadow if whole box is clickable, and so on. This box can be used at full width, 50% width, in a grid following the grid guidelines. The content is free to choose as long as it follows the guidelines of each inserted component.

This doesn't mean there can't be other components that make use of this "box" component, even more so if they are used commonly and have a rather fixed inside layout but I guess I'd name them more specifically and let them have their own page in Figma with examples. For instance:

• Call to action Banner
• Note
• Content Entry Point
• ... In addition to this there could be general Grid guidelines page that covers the grid for all viewports perhaps with some examples on most common page-layouts or pointers on how to place certain components inside the grid.

So in summary, on the one hand I get that there are a lot of box-like elements that look similar and perhaps can be visualised in the same way. On the other hand, by doing that, it could force sub-optimal layouts for certain content. Pages could end up looking too much alike or even a bit boring since the DS dictates and provides "limited" options. This would not promote creative thinking to display the content at hand in the best way possible, while -as a creator- just offering the Box and seeing some -non componentized- examples next to it would probably let me think a bit more about this, or start from an example and go from there.

Note that I'm not too familiar yet with how the DS is implemented or how content creators or devs are using the DS, but I thought I'd share these thoughts to spark some discussion and better understand the needs here.

Cheers!

Quick edit: FYI, it seems like Chakra has a "Card" component that shares some of the features mentioned above, however it seems like it has a fixed structure on the elements inside a card (header, body, footer).

[nloureiro]

Thank you for your valuable insights; I truly appreciate the time and effort you've put into helping me with this.

If I understand, you are advocating not making a component out of this because all things can be "boxed" on "fullwidth sections." Did I get it right?

with this in mind, what do you think of diving this into more down the level type of components > components that have a specific set of rules on how and when should be used:

1- "banners or call to action" > sections that serve the purpose of calling attention to other content pages and can be placed in the missed of any page

2- "Attention banner" > focuses the user's attention on a point and breaks the page's flow. It can be used only in the middle of the page and between content sections.

2.1 - on the text side, we can only accept paragraphs and lists (no cards, no tabs, no graphics)

From a design system perspective, the goal is to have a ready-to-use UI that anyone can use to create new pages. All will maintain visual consistency, helping the overall experience.

From the work I had done before, it might be to simplify all the variations I did and add the banner ones.

simplify > maybe do this

does it make sense?

[ddannehh]

If I understand, you are advocating not making a component out of this because all things can be "boxed" on "fullwidth sections." Did I get it right? with this in mind, what do you think of diving this into more down the level type of components > components that have a specific set of rules on how and when should be used

Yes, somewhat, I don't think a "full width section" isn't a thing that should be a component. You can have a section on a page but it can contain basically anything. Regular text with titles and paragraphs, an image, 2x2 cards, a carousel, a quiz, images, lists, a call to action banner, or combinations of those. It's just a wrapper (see screenshot below) It seems odd there would be a full width section component that can switch between different setups and combo's of these elements. However, this wrapper could ofcourse also have a background color.

The reason that the colored sections on the homepage (on the right) would not be components is b/c they have abnormal big images/paddings, which is more like a custom implementation. And that is perfectly fine, for a homepage, you want to catch some attention that can display things in way that are not straight from the design system. It's the first page a visitor gets to see it very well can be a bit special. Yes the layout looks a lot like a CTA banner, but it's not 100% the same.

In my previous comment I was talking about the elements inside a section. More specifically elements that in general have a more boxed like look and feel and stand out from the regular content. Which I thought this ticket was about. And try for unification of all these boxed components, which there are many of (See screenshot below). There are probably more... Note that some of these boxes all have a similar but not identical inner layouts. So after seeing all these different types of boxes I had doubts to try and fit them all into single component. Sure, there are things that can be aligned but nearly impossible to cover all those cases.

So my suggestion was to:

1. Have an all-purpose Box component, much like the Chakra card component that allows a number of preset styles (bg-color, border-color, shadow,.. combinations) but the content inside this box would be up to the designer
2. Define which boxed visualisations are often used across the site and make components of them. These can be used as-is or be used as a starting point. (These components also use 1)

This way if a contributor wants to create a page they have access to the most used boxed visualisations by dragging and dropping the component onto their page (like a simple CTA banner, a feature card, a "was this page helpfull" banner) but if they need something out-of-the-ordinary they can start by creating a rectangle/frame and apply one of the "box presets" but insert the content to their liking. This does not mean that there shouldn't be an example of let's say a "2x2 card like entry point" like at the top of the homepage. I just think the whole section shouldn't be a component in itself but rather an easy to copy paste Figma auto-layout frame where there are 4 "entry point" components used in it. It can be an additional artboard on the DS Figma pages for each component named "How can I use this component" with a couple of examples. This way, it's easy for a designer to make it a 3x3 frame or replace one entry point component with just a title + paragraph or something.

I still could be wrong here and maybe I'm trying to leave the door open a bit too much for contributor creativity that ends up looking bad but I hope this details further what I was thinking about. 😅

[nloureiro]

@ddannehh ok, I like your approach, let's go for it

Next, DS components are to be made:

• Box / all-purpose section

---

• CTA Banner component
• Cards (I've started and havens finish - https://www.figma.com/file/LUIL2TBuRnUuy4OcB1057F/V2%2FCards-unification?type=design&node-id=0%3A1&mode=design&t=QoRRKSb9CuEt8BAS-1)
• Content entry point > I am not entirely sure what this is, but we can deal with it later
• Callouts (your notes) > https://github.com/ethereum/ethereum-org-website/issues/9430
• [more to follow]

---

Important point:
I want to simplify and unify some of the styles in production, such as removing shadows and unifying corner radius. Another example is the colors; I haven't expanded from the blue/orange scheme because I wasn´t sure how to incorporate the other colors. Gut feeling: removes the yellows and adds the purple, but they need adjustments for both themes.

@ddannehh, can I make you an editor on the main file? It would be more straightforward to keep this going on the main file, and with the process, you can merge the forms and tabs 🙌

[ddannehh]

Next, DS components are to be made: Box / all-purpose section

Great! Need to try some stuff on how to make it work best in Figma. Currently thinking about creating these Box style treatments as components with a "placeholder" inside it. This placeholder could be replaced with actual content. This way we still have control over padding. I'll try something in tandem with the CTA Banners.

Important point: I want to simplify and unify some of the styles in production, such as removing shadows and unifying corner radius. Another example is the colors; I haven't expanded from the blue/orange scheme because I wasn´t sure how to incorporate the other colors. Gut feeling: removes the yellows and adds the purple, but they need adjustments for both themes.

Sounds like a good thing to review. The more consistency the better! Perhaps defining corner radius and dropshadow primitives (if still needed) as sm-m-l-xl styles would be a good idea. These things and adding the purple are more of a branding and general look-n-feel type of thing I guess. Not sure about how everyone feels about the current design? I'm sure its a hard thing to align on 😅

In designing the last few tickets I didn't look too critically into the color system and just adapted the current styles. Some things crossed my mind though:

• Limited base color palette. In general I'm personally used to creating a "full palette" for each color ranging from ~100-900. Doesn't mean each color should be used as a token in the UI. But could come in handy for Illustrations and more graphical material, these often require a bit more color fidelity. Also, when working with light-/darkmode there's currently enough range for blue & orange, but red, yellow, green only have 2. As a result the semantic colored components like system banners(error, success,..) and probably others don't really have a (good) darkmode variant, it's just the same as in lightmode.
• No use of transparency. Not saying this is a must, but could be beneficial sometimes since it can increase contrast for free or blend in better with a chosen background, instead of re-assigning a different color. Example: If you have tertiary text or disabled text that is #000 with .4 opacity on a reddish background it will most certainly work better than a fixed grey color.
• No use of component level tokens (except for the new menu). So currently it's pretty hard to do isolated tweaks without affecting anything else.

@ddannehh, can I make you an editor on the main file? It would be more straightforward to keep this going on the main file, and with the process, you can merge the forms and tabs

Sure, I'll see what I can do!

[nloureiro]

Next, DS components are to be made: Box / all-purpose section

Great! Need to try some stuff on how to make it work best in Figma. Currently thinking about creating these Box style treatments as components with a "placeholder" inside it. This placeholder could be replaced with actual content. This way we still have control over padding. I'll try something in tandem with the CTA Banners.

Important point: I want to simplify and unify some of the styles in production, such as removing shadows and unifying corner radius. Another example is the colors; I haven't expanded from the blue/orange scheme because I wasn´t sure how to incorporate the other colors. Gut feeling: removes the yellows and adds the purple, but they need adjustments for both themes.

Sounds like a good thing to review. The more consistency the better! Perhaps defining corner radius and dropshadow primitives (if still needed) as sm-m-l-xl styles would be a good idea. These things and adding the purple are more of a branding and general look-n-feel type of thing I guess. Not sure about how everyone feels about the current design? I'm sure its a hard thing to align on 😅

In designing the last few tickets I didn't look too critically into the color system and just adapted the current styles. Some things crossed my mind though:

• Limited base color palette. In general I'm personally used to creating a "full palette" for each color ranging from ~100-900. Doesn't mean each color should be used as a token in the UI. But could come in handy for Illustrations and more graphical material, these often require a bit more color fidelity. Also, when working with light-/darkmode there's currently enough range for blue & orange, but red, yellow, green only have 2. As a result the semantic colored components like system banners(error, success,..) and probably others don't really have a (good) darkmode variant, it's just the same as in lightmode.
• No use of transparency. Not saying this is a must, but could be beneficial sometimes since it can increase contrast for free or blend in better with a chosen background, instead of re-assigning a different color. Example: If you have tertiary text or disabled text that is #000 with .4 opacity on a reddish background it will most certainly work better than a fixed grey color.
• No use of component level tokens (except for the new menu). So currently it's pretty hard to do isolated tweaks without affecting anything else.

@ddannehh, can I make you an editor on the main file? It would be more straightforward to keep this going on the main file, and with the process, you can merge the forms and tabs

Sure, I'll see what I can do!

can you go to the main file and make a comment? To confirm your Figma account https://github.com/ethereum/ethereum-org-website/issues/9436#issuecomment-2090773018

Thank you!!!

[ddannehh]

I've added some things in the main file:

• Base Components / Box
• Composed Components / CTA Banner

So as discussed above, the Box component is somewhat all-purpose that can be used for any boxed content. This is where you control the styles and perhaps define the default padding values. Both have been added as props:

I added some styles I've seen across the website but as you mentioned before feel free to add/remove any styles you deem necessary to unify the many variations. Currently I've only used the Gradient style for the CTA Banner component, as this is the only component currently using the Box.

The CTA Banner component currently has only one variation: "Full width" width the text on the left and image on the right, however there's a property to toggle between 3 breakpoints, these adjust the max-width and spacing/padding. The "Box" component is part of this layout so should you change the gradient style on the Box page, the banner will update as well.

As mentioned earlier, I guess a similar setup could be used for all other common boxed components that can be pre-composed.

One additional adjustment I've made for light/dark mode to work is adding the gradient steps to the local variables:

This way, when the gradient is used in a component with the layer mode set to "Dark" the proper values for that mode get used.

Any feedback or questions, let me know! ✌️✌️

[ddannehh]

As a sidenote, I fiddled around with a variant for oversized artwork as an image, but would require refactoring the Image placeholder quite a bit and restrict it to certain image aspect ratios (1:1, 4:3, 16:9,..). The layer structure is also quite complex to keep the height dynamic so I figured I'd keep it simple for now and just add the most basic version.

Screencap anyway 🤩 https://github.com/ethereum/ethereum-org-website/assets/109203827/a9fbeca5-6fba-42ee-9cd1-fe43803d17e9

[nloureiro]

@ddannehh, this is fantastic work! Thank you!!!!

Sorry, I haven't had time to review it properly... I need to do it!!!

Let me know if I'm blocking you somehow