Page MenuHomePhabricator

Define a baseline grid and support a responsive grid system
Open, LowestPublic

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-Systems-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 Wikimedia Design Style Guide 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.

Done

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
In T90687#3028603, @Tgr wrote:

This was the second (slash third, in a tie) most popular item in the Developer Wishlist results. @Pginer-WMF could you summarize what's the current status and what help would be needed to move this forward?

The status is that:

  1. I made a proposal as an RFC to identify the aspects that we would like to have in a grid system.
  2. I created a reference implementation to illustrate those aspects.
  3. The Language team used the grid in Content Translation to check how that worked in a real project.
  4. A patchset was created to get the system merged into core but several technical issues were identified such as the internal names of the Less mixins not being intuitive.

I cannot add much more technically. So someone with more technology knowledge can either improve the proposed implementation or propose a better one for this, probably taking advantage of the flexbox and CSS-grid specifications that have evolved since I created the proposal in 2013.

I'm sure that I don't know everything there is to know in this space, but a clone of the Bootstrap 12-column grid seems technically simple and generally well documented. There are a lot of good docs on using 12-column grids and Bootstrap has become widespread enough that a fair number of casual web developers are familiar with it. The big need in my mind is for a responsive grid that can be easily used for article content as well as special page layout and skins themselves. In my mind this points to a solution that reinvents as few things as possible so that it is easy to document and promote widely to on-wiki content curators as well as developers.

@Catrope @Krinkle @Volker_E @Nirzar do you think the Architecture committee or the Front-end-Standards-Group or the Design team at the WMF can help evaluating this proposal (#2 in the Developer Wishlist) and see whether it can make it to any team goals or annual plans?

@Qgil I've thought about putting this on the Front-end-Standards-Group topic for next meeting last night. We definitely need to talk about this there in order to make progress. It also resembles as part of UI-Standardization efforts and we need to have opinions and needs of WMF-Design folks captured. CCing @Pginer-WMF again, as he did a lot of work on the original attempts to resolve this.
Now we've hopefully tagged every project/group related ;)

I agree with @bd808 about using a well known grid. Bootstrap's is very widely used and would be fine, something like a flexbox grid http://flexboxgrid.com/ would be awesome.

Seems like a good discussion for the Front-end-Standards-Group as @Volker_E said.

As first step, we should gather and clearly define needs, on the RFC discussion page there hasn't been a lot of inputs, if so, the last one dates back to June 2014. I don't know if there were any other findings or documentation… @Pginer-WMF?

A recurring issue with various of the grids (and their implementation) out there, is the sentiment of them being bloated (prob over-engineered): They provide so many layout options (nesting, responsive layout) so that devs need a lot of time to wrap their head around and don't use it for the main use cases. Bloated output code comes in as hurdle as well. From my reading this problem was parts being captured under “Optional”.

CSS Flexbox based grids seem, given that it needs all kinds of browser hacks and/or polyfills, to share the same issues.
CSS Grids, as mentioned above, will be a complete replacement for any effort we take at some point in the future. The main advantage seems to be two-dimensional grids. We should weigh in future-proofness/compatibility in our attempts here.

I agree with @bd808 about using a well known grid. Bootstrap's is very widely used and would be fine, something like a flexbox grid http://flexboxgrid.com/ would be awesome.

Seems like a good discussion for the Front-end-Standards-Group as @Volker_E said.

At the time the proposal was created, Bootstrap was very different. Now it incorporates many of the principles proposed. The only differences seem to be that Bootstrap assumes a 12-column grid by default, and uses different names (of the breakpoints and the size specifications). So I think it could be a good candidate to support the grid ideas.

In terms of responsiveness it seems that Bootstrap supports adjusting grid columns and visibility of elements, but it would be useful to have ways to adjust any CSS aspect (such as font size) as illustrated in the experimental implementation of the proposal. This can be considered related to the grid discussion, or considered separately.

As first step, we should gather and clearly define needs, on the RFC discussion page there hasn't been a lot of inputs, if so, the last one dates back to June 2014. I don't know if there were any other findings or documentation… @Pginer-WMF?

In the proposal I capture the main needs I identified:

  • Optional because we cannot change the whole UI at once.
  • Nestable because we want to use the grid in components that will appear inside pages or other components based on the same grid system.
  • Responsive because we want to make the best use of the available space in a world with a big diversity of devices.
  • Semantic because we don't want to clutter the HTML and be heavily affected by changes in the grid system internals in the future.
  • I also included proportional because I found that "one-half" the available space was easier to understand that col-6 (which requires you to know it means 6/12), But I'm ok to live without this one since I'm not the one going to implement software using this, I just want the designs to be easy to transfer accurately into the final solutions.

@Volker_E The backing CSS of the abstraction we choose to expose should be an implementation detail, in my opinion.


@Pginer-WMF The proposal is great, and I very much agree with those points.

From what I see, the implementation is not mobile-first, which is something I think is very important (some reasons in How To Write Mobile-first CSS).

Would it be worth modifying that behavior so that the targets apply upwards? (using only min-width on the media queries) That is how mobile-first grids work, like bootstrap or skeleton for example.

@Tgr Does TemplateStyles allow developers to use LESS in the templates or only CSS? Asking because if it is only CSS we would need to expose classes instead of using the semantic approach and only exposing mixins.

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)