Page MenuHomePhabricator

Define a baseline grid and support a responsive grid system
Open, Needs TriagePublic

Assigned To
None
Authored By
Pginer-WMF
Feb 25 2015, 9:19 AM
Referenced Files
None
Tokens
"Love" token, awarded by valerio.bozzolan."Like" token, awarded by Liuxinyu970226."Orange Medal" token, awarded by Krinkle."Like" token, awarded by Moushira."Like" token, awarded by cicalese."Like" token, awarded by RHeigl.

Description

Background

Our current web-based products do not feature a shared baseline grid and responsive layout system. Every Wikimedia team has to solely rely on their experience and judgement. There have been some early design explorations lead by @Pginer-WMF to address this task and in-product context-specific implementations too but we didn't manage to consolidate, establish and document a shared practice around grids and layouts.

Most recently the Readers Web Team has been leading the Desktop Improvements (Vector 2022) initiative where they have been exploring also different layout options and potential grid solutions.

In late November 2021, the designers of the Design-System-Team gathered a first collection of requirements that we surveyed during a Design Review meeting. The session resulted in a set of shared priorities and follow up conversations that we conducted in the following weeks with @RHo, @Pginer-WMF, @alexhollender_WMF, and @KieranMcCann for specific grid-related topics.

The following content outlines the baseline grid requirements necessary to extensively support the design team and the features and products that they build.

User stories

Scenario: designing a component

  1. As a designer, I want to learn about of a shared baseline grid for our products, so that I can use it and apply it to the new components and layouts I design.
  2. As a designer, I want to understand how to space elements inside a component, so that I can set the padding, the dimensions and alignments following the same rules applied to existing components.
  3. As a designer, I want to set the aspect ratio of photos, pictures, and illustrations, so that I can craft assets and layouts that are consistent across features and products.

Scenario: designing a layout

  1. As a designer, I want to have access to a sizing scale, so that I can space, distance and layout components consistently with the rest of the product experience.
  2. As a designer, I want to align components to a responsive column grid, so that I can define how elements move across different viewports. In order to achieve this I need to know how the grid changes across breakpoints, which are those breakpoints, what are the outer margins of this grid, and which gutters are set between columns.
  3. As a designer, I want to layout elements within a page accordingly to existing screen regions, so that end-user will find familiar content in familiar location hence lowering the cognitive load when they one a new page.
  4. As a designer, I want to understand how to expose information through different panels, so that I can reorganize the hierarchy of content when there isn't enough real estate available.
  5. As a designer, I want to visually align element along the edge of a vertical keyline, so that I can place elements outside of the layout grid.
  6. As a designer, I want to space content following an established vertical rhythm, so that I can learn how to leverage white space to convey hierarchy and reading order.

Conditions of Satisfaction

  • Overview presentation during a Design Practice & Systems Meetup.
  • The Codex design system features a new page detailing the baseline grid specs and recommendations.
    • Showcase examples of how the grid is applied to common components, eg. lists.
    • Guides on how to adopt the baseline grid incrementally in design and product.
  • The base unit and the sizing scale are specified as design tokens.
  • The baseline grid specifications are available as (hidden) layout grids in every component featured in the "WikimediaUI – Components Library" Figma file.

Testing Instructions

  • Test the grid on the atomic level components, eg. buttons.
  • Test the grid on common patterns, eg. lists.
  • Test the grid to define the layout of the entire site, eg. Wikipedia main page.
  • Test the grid on the 3 most common page layouts: panel, no panel, full.
  • Test the grid to layout the interior content of pages, eg. article page.
  • Test the grid to retro fits current layouts, eg. newcomer homepage.
  • Test the grid on small devices and viewports, eg. m.wikipedia.org.

Acceptance criteria for Done

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

TemplateStyles does not allow use of LESS right now (just like we have on MediaWiki.css not MediaWiki.less) and I don't think we should go down that route as part of this... that would increase the scope quite dramatically. I also worry about adoption as many wiki editors are not necessarily programmers and learning LESS might be a little bit of a stretch for some (remember many of these editors don't know Git and don't want to learn Git hence why the develop gadgets).

I'd suggest we focus on a class based approach.
1 to using a well known grid.

Volker_E added a subscriber: Qgil.

@Qgil There's no clear consensus on

  • where such grid (helpers) should live (MW core probably, but then again where and as what),
  • what technology to build on top as there has been massive standard support improvement additions in providing more powerful (Flexible Box Layout) or simpler (CSS Grid Layout) solutions in this area
  • and last but not least, who's to implement & maintain it given the multitude of necessities to care about and test against

On this behalf I'm removing OOUI as it's not the place for grid support to live in from current project scope.

I played a bit with bootstrap's grid layout and templatestyles: https://www.mediawiki.org/wiki/User:TheDJ/bootstrap

The UI system of ContentTranslation Vue dashboard implemented a grid based on flexbox. It has been very helpful for layout. See Storybook .

That looks promising, @santhosh. One thing that seems important here, were examples given how it behaves in Internet Explorer 9 (and 8 if T248061 doesn't get accepted). I assume that you're building on autoprefixer for IE 10 support?!

Spacing units are multiples of 4 units. So pa-2 means padding: 8px. The values can be between 1 to 12. pt-12 means padding-top: 48px

It think by providing too many numerical options, you may end up with restricted version of inline styles.

Where possible a framework should be limited to identified use cases to promote consistent design.

Spacing units are multiples of 4 units. So pa-2 means padding: 8px. The values can be between 1 to 12. pt-12 means padding-top: 48px

It think by providing too many numerical options, you may end up with restricted version of inline styles.

Sorry, I did not understand this comment. What do you mean by 'restricted version of inline styles"?

@Pginer-WMF @Volker_E - I cannot find a baseline grid (4px or otherwise) formally documented anywhere (on the Design Style Guide, OOUI, etc). I was going to create a new task for this, but does it make sense instead for this task to be updated to incorporate the need to define and document a baseline grid as well?

In T90687#7246210, @RHo wrote:

@Pginer-WMF @Volker_E - I cannot find a baseline grid (4px or otherwise) formally documented anywhere (on the Design Style Guide, OOUI, etc). I was going to create a new task for this, but does it make sense instead for this task to be updated to incorporate the need to define and document a baseline grid as well?

Sounds good to me. These spacing aspects seem quite relevant to the topic of the ticket.

RHo renamed this task from Support a responsive grid system to Define a baseline grid and support a responsive grid system.Jul 29 2021, 1:53 PM
RHo updated the task description. (Show Details)

Thanks for the update @RHo – that was the reason to have linked this task to the epic questions task, I've had both, the grid and spacing as indivisible parts in mind.
The 4px multiplier spacing was visible in Sketch WikimediaUI Components Overview.

Formal question: Are we doing ourselves more of a favor with 4px, 8px or even 16px equivalent as base spacing? Even in the components collection there are sometimes 2px overrides, but the majority is 8 and 16.

Thanks for the update @RHo – that was the reason to have linked this task to the epic questions task, I've had both, the grid and spacing as indivisible parts in mind.
The 4px multiplier spacing was visible in Sketch WikimediaUI Components Overview.

Right I see. It seems warranted to make it much more 'official' and better documented on the Design Style Guide, something like the following:

Formal question: Are we doing ourselves more of a favor with 4px, 8px or even 16px equivalent as base spacing? Even in the components collection there are sometimes 2px overrides, but the majority is 8 and 16.

IMO as 4px as the smallest unit gives wiggle room, and then moving forward we should ensure components and space adheres to the smallest unit, and no longer have overrides moving forward.

In T90687#7247152, @RHo wrote:

Formal question: Are we doing ourselves more of a favor with 4px, 8px or even 16px equivalent as base spacing? Even in the components collection there are sometimes 2px overrides, but the majority is 8 and 16.

IMO as 4px as the smallest unit gives wiggle room, and then moving forward we should ensure components and space adheres to the smallest unit, and no longer have overrides moving forward.

Not sure I follow the take “follow the smallest unit” here. We have had overrides of 2px, even 3px and 1px in certain interface challenges like in Desktop Improvements in past months. And I think 4px or 2px are also fine contextually to be used and will continuosly needed to be used. The formal question is:

  • “8px equivalent is our base spacing unit, there are cases where you could half (4px) or even a quarter (2px) contextually.“ My recommendation looking through our interface components. Or
  • “16px equivalent is our base spacing unit, there are cases where you could half (8px) or even a quarter (4px) or an eighth (2px) contextually.“ This would have the advantage that we're also aligning to a technical pre-conception, having 1em equivalent to 1 spacing unit. Keep in mind, that ems might loose importance in the mid-future due to approaches like T262928 Or
  • “4px equivalent is our base spacing unit, there are cases where you could multipliers (8px) or a half (2px) contextually.“ Least recommended, simple sentence, but not used widely enough in components, 8px and 16px are much more often used.
In T90687#7247152, @RHo wrote:

Formal question: Are we doing ourselves more of a favor with 4px, 8px or even 16px equivalent as base spacing? Even in the components collection there are sometimes 2px overrides, but the majority is 8 and 16.

IMO as 4px as the smallest unit gives wiggle room, and then moving forward we should ensure components and space adheres to the smallest unit, and no longer have overrides moving forward.

Not sure I follow the take “follow the smallest unit” here. We have had overrides of 2px, even 3px and 1px in certain interface challenges like in Desktop Improvements in past months. And I think 4px or 2px are also fine contextually to be used and will continuosly needed to be used. The formal question is:

  • “8px equivalent is our base spacing unit, there are cases where you could half (4px) or even a quarter (2px) contextually.“ My recommendation looking through our interface components. Or
  • “16px equivalent is our base spacing unit, there are cases where you could half (8px) or even a quarter (4px) or an eighth (2px) contextually.“ This would have the advantage that we're also aligning to a technical pre-conception, having 1em equivalent to 1 spacing unit. Keep in mind, that ems might loose importance in the mid-future due to approaches like T262928 Or
  • “4px equivalent is our base spacing unit, there are cases where you could multipliers (8px) or a half (2px) contextually.“ Least recommended, simple sentence, but not used widely enough in components, 8px and 16px are much more often used.

Right. What I mean is that we should have 4px as the smallest base spacing that is allowed, which would convert to 0.25em equivalent if ems continue to be used.
I am interested in understanding what the cases are for overrides of 1px, 2px, or 3px to be allowed and in what context. I am talking about not having smaller than 4px in the Design Styleguide for spacing and layout.

In T90687#7253301, @RHo wrote:
In T90687#7247152, @RHo wrote:

Formal question: Are we doing ourselves more of a favor with 4px, 8px or even 16px equivalent as base spacing? Even in the components collection there are sometimes 2px overrides, but the majority is 8 and 16.

IMO as 4px as the smallest unit gives wiggle room, and then moving forward we should ensure components and space adheres to the smallest unit, and no longer have overrides moving forward.

Not sure I follow the take “follow the smallest unit” here. We have had overrides of 2px, even 3px and 1px in certain interface challenges like in Desktop Improvements in past months. And I think 4px or 2px are also fine contextually to be used and will continuosly needed to be used. The formal question is:

  • “8px equivalent is our base spacing unit, there are cases where you could half (4px) or even a quarter (2px) contextually.“ My recommendation looking through our interface components. Or
  • “16px equivalent is our base spacing unit, there are cases where you could half (8px) or even a quarter (4px) or an eighth (2px) contextually.“ This would have the advantage that we're also aligning to a technical pre-conception, having 1em equivalent to 1 spacing unit. Keep in mind, that ems might loose importance in the mid-future due to approaches like T262928 Or
  • “4px equivalent is our base spacing unit, there are cases where you could multipliers (8px) or a half (2px) contextually.“ Least recommended, simple sentence, but not used widely enough in components, 8px and 16px are much more often used.

Right. What I mean is that we should have 4px as the smallest base spacing that is allowed, which would convert to 0.25em equivalent if ems continue to be used.
I am interested in understanding what the cases are for overrides of 1px, 2px, or 3px to be allowed and in what context. I am talking about not having smaller than 4px in the Design Styleguide for spacing and layout.

4px sounds good to me.

Examples:

  • Desktop Improvements was the last project where I encounter a few of them. Would 6px be an acceptable value? From a strict formal point I lean towards no. 5px definitely not. Logo margin features one.
  • WVUI TypeaheadSearch Suggestion title features margin-bottom: 2px

I played a bit with bootstrap's grid layout and templatestyles: https://www.mediawiki.org/wiki/User:TheDJ/bootstrap

Whoa. That's cute! Just for fun I've adapted your work here for itwiki:

https://it.wikipedia.org/wiki/Template:Bootstrap

Since this does not seem to create conflicts, maybe the itwiki local community can try it and start killing some layouts made with tables and see if we have further feedback to share here.

BTW the ability to create columns with just a generic class like ".col-md" without saying "col-md-6" etc. is a killer feature and it's definitely one of the things I would recommend having in the MediaWiki core. The .col-md feature is more simple to discuss, before agreeing on the number of columns.

Volker_E updated the task description. (Show Details)
CCiufo-WMF raised the priority of this task from Lowest to Needs Triage.Feb 6 2024, 8:50 PM
CCiufo-WMF moved this task from Inbox to Backlog on the Design-System-Team board.