@bmartinezcalvo @KieranMcCann I apologize for the delay here. I've lost context on what our next steps were, can one of you remind me? Currently the grid in the prototype (and in the Figma file) doesn't work well between ~1300px and 1000px, as the TOC becomes too narrow, for example:

1355px browser	1108px browser

I've updated the prototype to include a toggle for @KieranMcCann's idea, where below ~1280px the TOC spans 3 columns instead of 2 (TOC span 3 columns (below 1280px)). however this maybe results in too much space for the TOC, and also complicates the placement of the tools menu (though we could think about that a bit more). https://dsg-grid.web.app/Cher. curious what you both think.

what else did we want to try in order to make the TOC work?

@alexhollender_WMF this grid proposal was updated with the breakpoints defined in T303522 (new breakpoints were defined based in the most used screens). As we defined new breakpoints (old breakpoints will be defined as legacy) now the 1280px and 1024px screens use different breakpoints, so the ToC behavior will be different for them: ToC in 1280px screens will use 2 grid columns while in 1024px screens will be hidden.

We shouldn't use 3 column grids for the ToC in 1280px screens because if we do this we should use 3 grid columns on 1366px screens too (since both 1280px and 1366px screens use now the same breakpoint).

As next steps, I think we should update the prototype in T309336 with this new grid proposal to test if it really works well with real content. I was waiting to receive more feedback about this grid proposal to update the prototype, but if you want we can start now.

In T298198#8116478, @alexhollender_WMF wrote:

Currently the grid in the prototype (and in the Figma file) doesn't work well between ~1300px and 1000px, as the TOC becomes too narrow, for example:

@alexhollender_WMF regarding the ToC width, the most extreme case with a narrowest ToC would be on 1280px screens where the ToC would be 183px wide. In the case of 1366px screens (the 2nd most used desktop screens according to this web) the ToC width would be 197px wide that I think it would be enough. What do you think?

You can check the ToC on these screens here.

@bmartinezcalvo, ok so given the new breakpoints:

• are you thinking the sidebars will collapse at 1120px now (instead of 1000px, which is when they currently collapse)?
• I think we will still have the issue with the TOC being too narrow between ~1300px and 1120px. Is there something I'm missing here?

In T298198#8128518, @alexhollender_WMF wrote:

@bmartinezcalvo, ok so given the new breakpoints:

• are you thinking the sidebars will collapse at 1120px now (instead of 1000px, which is when they currently collapse)?

@alexhollender_WMF right, left sidebar would collapse from 1119px, at 1120px it would be visible and the breakpoint would jump to the next one in 1119px (hiding the ToC from this 1119px). You can check how the ToC works with the left panel layout here.

• I think we will still have the issue with the TOC being too narrow between ~1300px and 1120px. Is there something I'm missing here?

The ToC would be narrow between 1300-1120px but we need to keep in mind that the real screens affected for this breakpoint and grid would be:

• 1280px screens with a 183px wide ToC
• 1366px screens with a 197px wide ToC

If you need me to explain you the proposal in deep we can schedule a meeting. Also, I think when we hace the prototype updated in T309336 we'll be able to test better the ToC in the different breakpoints.

@bmartinezcalvo @KieranMcCann I've updated the prototype and have included some screenshots below of the 1150–1350 range. It's difficult to figure out what an appropriate minimum width is for the TOC. The Cher article has very long section titles, which don't even look great when the ToC is 192px (some are wrapping to 4 lines).

1150px
1200px
1250px
1300px
1350px

Also I was looking at some other reading experiences and notice that the width of the text column, and the width of the TOC for the sites that have them, remains more fixed (often with the center column being flexible). There are breakpoints & responsiveness, but it doesn't seem like they use the same kind of grid system. And the breakpoints seem to be based on the content layout, and accommodate when it needs to shift (rather than being based on popular screen sizes):

I think there is value in having a grid, but we also might want to do some additional explorations with our 3 column approach where the center column is flexible, but the side columns have a more fixed-width approach, for example:

1680px
1400px
1120px
900px
320px

@alexhollender_WMF the ToC with long text makes me thing in some improvements we could do in the ToC (apart from defining the right ToC minimum width):

1. Should we define a maximum number of visible characters for the ToC options and display ellipsis once this maximum exceeds?
2. Should we define a maximum number of text lines for the ToC options and display ellipsis once this maximum text lines exceeds? I mean, in this Cheer article the ToC options with more than 2 text lines (when the ToC is too narrow) could appear with ellipsis so the menu options are not excessively long.
3. In case we use ellipsis to shorten title length we could use a tooltip when hover to show the user the full long title.

@alexhollender_WMF thank you for collecting all these examples of other products with side panels, they are so useful to study how the side panel works in other cases.

I have to point out that some of them don't really have a fixed width panel:

• The Nielsen Norma Group uses a non fixed left panel. If you open the inspection you will view that the left panel width changes in the different screen sizes, being 303px width in a 1440px screen and 273px width in a 1280px screen:

1440px screen (303px left panel)	1280px screen (273px left panel)

• Same for The Lancet where the left panel is not fixed either:

1440px screen (198px left panel)	1280px screen (165px left panel)

Although some other products use fixed side panels, I think that due to the large number of use cases and layouts that we have in all our Wikimedia projects and trying to unify our projects in a single grid, it would be better if we don't use fixed width elements and we use instead elements adapted to the grid columns , so that our layouts work much more fluidly and avoiding to define a different fixed width for each case.

Imagine how many cases there will be in which the designer wants to add a fixed width for a specific case of the project. If we do this in each project we will have different content widths in each page or project and a grid that is not being used. For this reason we are defining a grid trying to unify all our layouts and projects.

As the ToC was too narrow in some screen sizes with the 12col grid proposal, we decided to test other grid proposals in the prototype created by @alexhollender_WMF in T309336

The options we tested in this prototype were:

• 24 column grid for desktop [NEW]
• 12 column grid for desktop [Previous proposal]
• 12 column grid with a new breakpoint where the ToC expands to 3col in 1299px)

After testing this prototype with the design team, we decided to move forward with the 24col grid proposal for desktop devices (check the Figma proposal here)

Reasons why we aim for this 24col grid proposal:

• 24col is just the double of 12col, so visually the design of the content in almost all the cases will be the same. Only in the case of the left panel for the ToC it will be 5col grid instead of 4.

• 24col grid is more flexible to find current and future layout solutions, since the grid columns are narrower and they allow us to create non-exaggerated solutions for our proposals (e.g. for the ToC we can use 5col instead of 4col and the ToC width changes in a subtle way and it's perfect, while with the 12-column grid if we used 3col instead of 2col the ToC was too wide).
  

• If we hide the grid (that users will never visualize) we can view how both 12col and 24col grid proposals are visually the same. Simply the 24col uses twice as many columns for the content as the 12col grid, and it allows us to make small adjustments to the layout without making these adjustments extremely large.
  

Then grids will be the following:

• Desktop Wide: 24 grid columns, 24px gutter, margins scale according to the width of the screen (max content width 1514px)
• Desktop: 24 grid columns, 24px gutter, 32px margins to max content width and then they scale (max content width 1514px)
• Tablet: 8 grid columns, 24px gutter and 24px margins
• Mobile: 4 grid columns, 16px gutter and 16px margins

Now that the grid proposal has been defined we should discuss about the implementation of the grids in Codex. cc: @Volker_E @AnneT @Catrope @egardner

needs refinement as we head into implementation

latest prototype: https://vector-2022.web.app/Moth

In T298198#8486041, @alexhollender_WMF wrote:

latest prototype: https://vector-2022.web.app/Moth

@alexhollender_WMF the use of the grid in that prototype is wrong. You are using the column gutters (separation between columns) to place the content but you should use the columns instead. This is what you should do:

In this way, the separation between ToC - Content - Tools wouldn't be 32px but would be 24px instead.

In T298198#8486978, @bmartinezcalvo wrote:

@alexhollender_WMF the use of the grid in that prototype is wrong. You are using the column gutters (separation between columns) to place the content but you should use the columns instead. This is what you should do:

I can't see the image you posted. To clarify: the dark red is the gutters, and the light red is the columns. As we discussed, in this version of the prototype the gutters are generally wider than the columns.

In T298198#8499531, @alexhollender_WMF wrote:

In T298198#8486978, @bmartinezcalvo wrote:

@alexhollender_WMF the use of the grid in that prototype is wrong. You are using the column gutters (separation between columns) to place the content but you should use the columns instead. This is what you should do:

I can't see the image you posted.

@alexhollender_WMF sorry, my image was not public. Now you should view it. What I was explaining in the image is that, as documented in the Grid design proposal, you should use the following sizes in the desktop grid (from 1120px to 1679px screens):

• Margins 32px
• Gutters 24px
• Max content width 1514px

In T298198#8499531, @alexhollender_WMF wrote:

To clarify: the dark red is the gutters, and the light red is the columns. As we discussed, in this version of the prototype the gutters are generally wider than the columns.

Ah ok, I misunderstood. Then the content is starting in the first grid column, well. In some cases the gutters could be bigger than the columns (e.g. in 1120px screens) but in all cases gutters should be 24px.

Static grid-areas

@bmartinezcalvo the current grid-area definitions are static, so the content area remains the same (15 columns) regardless of whether or not the tools menu is pinned or hidden:

tools menu hidden	tools menu pinned

On larger screens this doesn't present an issue, however on smaller screens it means that the content gets squished more than it needs to, for example:

tools menu hidden (smaller screen)

Dynamic grid-areas

One way to improve the layout for smaller screens would be for the grid-area definitions to be dynamic, so that the content area can take up more columns when the tools menu is hidden:

tools menu hidden	tools menu pinned

One possible downside with this approach is that on larger screens, when the tools menu is hidden, the content will be wider than what we previously considered ideal (960px).

tools menu hidden

This width of course depends both on the number of columns we allow the content to take up when the tools menu is hidden (16, 17, 18, or 19), as well as the max-width of the entire grid (which is currently set to 1650px in the prototype). This table is not comprehensive, just a start to help frame how we think about this:

In addition to the number of columns the content takes up, and the max-width of the grid, other things could affect this:

• media query so that the content takes up less columns again above a certain width
• add a max-width on content area
• increased font-size (which means the ideal width is then larger)

Prototype with 1650px max-width, and content area taking up 17 columns when tools menu is hidden: https://vector-2022.web.app/Moss

In T298198#8632291, @alexhollender_WMF wrote:

Dynamic grid-areas

One way to improve the layout for smaller screens would be for the grid-area definitions to be dynamic, so that the content area can take up more columns when the tools menu is hidden:

tools menu hidden	tools menu pinned

@alexhollender_WMF I agree with using a dynamic layout to expand the content when the Tools panel is hidden. Also I agree with using 4 columns for the Tools panel since in the previous proposal we were using 3 col. instead, which causes the Tools panel to be too narrow on small desktop screens. So I agree with using a dynamic layout with 4col. Tools panel and expandable content area.

One possible downside with this approach is that on larger screens, when the tools menu is hidden, the content will be wider than what we previously considered ideal (960px).

tools menu hidden

This width of course depends both on the number of columns we allow the content to take up when the tools menu is hidden (16, 17, 18, or 19), as well as the max-width of the entire grid (which is currently set to 1650px in the prototype). This table is not comprehensive, just a start to help frame how we think about this:

	content at 16 columns	content at 17 columns
grid max-width: 1514px	content max-width: 1001px	content max-width: 1065px
grid max-width: 1650px	content max-width: 1092px	content max-width: 1161px

I've explored this dynamic layout proposal testing both 16col. and 17col. for the expandable content area.

I lean towards using the expandable content from 15col (tools displayed) to 16col (tools hidden) since the content area will be more aligned with the 960px ideal width. Since the grid max-width is 1514px, the max-content width will be 1002px which is just 42px more than the ideal content width.

@alexhollender_WMF could you update the prototype with both 17col and 16col to compare both options?

Hi @bmartinezcalvo, is this something pending response from Web team folks? If so, would it make sense for @KieranMcCann to work with you on resolving?

In T298198#8722457, @RHo wrote:

Hi @bmartinezcalvo, is this something pending response from Web team folks? If so, would it make sense for @KieranMcCann to work with you on resolving?

@RHo I need to know if @KieranMcCann agrees with the new proposal of having a dynamic grid where central content will expand if the right panel (tools) is hidden. Please review my last comment above and the one from Alex. If you both agree with this, I will update the grid and layout proposal in this task and the layout documentation in the library.

@RHo @bmartinezcalvo I do agree with having a dynamic grid which allows for the article to expand to the right when the tools panel is hidden. There are, however, a couple things in the way of us moving forward with this at the moment. These being:

• One of the outcomes of the recent Vector 2022 rfc is that there are community members who support a move towards full-width article content. Meaning that the article would just continue grow in width as the browser extends. This approach would have a big impact on how we approach the grid.
• Also, as part of the next set of iterations to Vector 2022 the application of the grid has been descoped due to the technical complexity. That doesn’t block it in the future but something you should be aware of.

Happy to continue working on this but until the first point above is resolved then it we wouldn’t be able to come to a resolution.

Hey @KieranMcCann thank you for sharing this. I've updated the layout proposal applying your feedback related with the content full-width. We could use 4col for the tools panel and then expand the article content when the tools panel is hidden. With this new layout, we would solve the user's full-width request for the article content.

This layout proposal uses the same grid solution we proposed some time ago (24col grid on desktop) so there is no problem with implementing one or another layout using this grid. In any case, I think it's worth implementing a grid so we can unify the margins and visual structure in all our projects.

In T298198#8728592, @bmartinezcalvo wrote:

Hey @KieranMcCann thank you for sharing this. I've updated the layout proposal applying your feedback related with the content full-width. We could use 4col for the tools panel and then expand the article content when the tools panel is hidden. With this new layout, we would solve the user's full-width request for the article content.

This layout proposal uses the same grid solution we proposed some time ago (24col grid on desktop) so there is no problem with implementing one or another layout using this grid. In any case, I think it's worth implementing a grid so we can unify the margins and visual structure in all our projects.

Hi @bmartinezcalvo. Just to clarify that this updated proposal still appears to have a max-width on the content of 1514px. If we end up going with the current suggestion, from some community members, not to have any width limitation, then the grid approach would need to change. Myself and @RHo were discussing this earlier and there may be a few options:

• have a breakpoint at a large width where we switch from the grid to a % based flexible layout that follows the column ratios on the max width
• as above but we have a mix-width on the menus and allow the width of the article content to flex

Either way I think it might be useful to hold off on making any final grid decision this until we have a clearer direction on this. Will keep you posted!

In T298198#8735855, @KieranMcCann wrote:

Hi @bmartinezcalvo. Just to clarify that this updated proposal still appears to have a max-width on the content of 1514px. If we end up going with the current suggestion, from some community members, not to have any width limitation, then the grid approach would need to change.

@KieranMcCann oh yes, sorry, I misunderstood your previous comment. So the right new proposal would be this one instead, with no max-width limitation on big screens:

I would avoid using a no max-width limitation since the reading experience will not be the best and the content would be too wide on some big screens, specially when the tools panel is hidden.

Myself and @RHo were discussing this earlier and there may be a few options:

• have a breakpoint at a large width where we switch from the grid to a % based flexible layout that follows the column ratios on the max width
• as above but we have a mix-width on the menus and allow the width of the article content to flex

Either way I think it might be useful to hold off on making any final grid decision this until we have a clearer direction on this. Will keep you posted!

I agree, let's discuss this when we have a clearer direction.

In T298198#8737660, @bmartinezcalvo wrote:

In T298198#8735855, @KieranMcCann wrote:

Hi @bmartinezcalvo. Just to clarify that this updated proposal still appears to have a max-width on the content of 1514px. If we end up going with the current suggestion, from some community members, not to have any width limitation, then the grid approach would need to change.

@KieranMcCann oh yes, sorry, I misunderstood your previous comment. So the right new proposal would be this one instead, with no max-width limitation on big screens:

Once direction/decision has been made on the full-width issue, I recommend updating this diagram to show how it would work on very wide screens beyond the grid max breakpoint.

I would avoid using a no max-width limitation since the reading experience will not be the best and the content would be too wide on some big screens, specially when the tools panel is hidden.

Agree, this has been the design recommendation throughout, but conversation is ongoing.

Myself and @RHo were discussing this earlier and there may be a few options:

• have a breakpoint at a large width where we switch from the grid to a % based flexible layout that follows the column ratios on the max width
• as above but we have a mix-width on the menus and allow the width of the article content to flex

Either way I think it might be useful to hold off on making any final grid decision this until we have a clearer direction on this. Will keep you posted!

I agree, let's discuss this when we have a clearer direction.

Here is the latest proposal for the grid with particular reference to how it behaves with Vector 2022. This proposal takes into account:

• community feedback requesting a full width option that can be toggled to allow no width restriction
• the likely introduction of the ‘Zebra 9’ design changes which has introduced larger padding on the article and menus and therefore reduced content column widths.

The key changes from the previous proposal include:

• ToC and Tools columns are now the same width to create a symmetrical layout when both menus are pinned. The column distribution is 4/16/4
• In ‘restricted width mode’ the article does not change size or position when menus are hidden.
• In ‘restricted width mode’ the maximum width has been increased to 1618px to compensate for the increased padding introduced by the Zebra design which reduced the article text column width.
• Addition of ‘full width mode’ where the grid has no max-width.
  • In ‘full-width mode’, when menus are hidden the article expands to fill the empty columns. This behaviour is different from ‘restricted width mode’.

{F36992048}
{F36992049}

Figma file

In T298198#8844041, @KieranMcCann wrote:

Here is the latest proposal for the grid with particular reference to how it behaves with Vector 2022. This proposal takes into account:

• community feedback requesting a full width option that can be toggled to allow no width restriction
• the likely introduction of the ‘Zebra 9’ design changes which has introduced larger padding on the article and menus and therefore reduced content column widths.

The key changes from the previous proposal include:

• ToC and Tools columns are now the same width to create a symmetrical layout when both menus are pinned. The column distribution is 4/16/4
• In ‘restricted width mode’ the article does not change size or position when menus are hidden.
• In ‘restricted width mode’ the maximum width has been increased to 1618px to compensate for the increased padding introduced by the Zebra design which reduced the article text column width.
• Addition of ‘full width mode’ where the grid has no max-width.
  • In ‘full-width mode’, when menus are hidden the article expands to fill the empty columns. This behaviour is different from ‘restricted width mode’.

{F36992048}
{F36992049}

Figma file

Adding in non-restricted versions of above images (since KieranMcCann is no longer active)