Renaming some breakpoints

[SiAdcock]

Why?

Breakpoint names follow expected screen sizes and make assumptions about the number of CSS pixels that would be available on, say, a desktop monitor.

On top of this, there's the awakward leftCol breakpoint that doesn't map to a device size. Instead it's simply a good breakpoint at which to introduce a left column on fronts and articles.

Alternative naming 1

Our breakpoints could be named more semantically and using a scale that is easier to reason about:

• tablet -> small (740px)
• desktop -> medium (980px)
• leftCol -> large (1140px)
• wide -> xlarge (1300px)

This follows the semantic naming conventions used elsewhere for size units and typography

For fluid grid tweakpoints on mobile, we could use a fluid_ or mob_ prefix:

• mobile -> mobile_small (320px)
• mobileMedium -> mobile_medium (375px)
• mobileLandscape -> mobile_large (480px)
• phablet -> mobile_xlarge (660px)

Alternative naming 2

This is laser-focussed to sort out leftCol. Device-targetted breakpoint naming has served us well for the last 6 years, so it must be doing something right! But leftCol is confusing and people forget whether it's bigger or smaller than desktop.

With this proposal, we keep nearly everything the way it currently is, but with a tweak around the desktop range:

• mobile -> mobile (320px)
• mobileMedium -> mobileMedium (375px)
• mobileLandscape -> mobileLandscape (480px)
• phablet -> phablet (660px)
• tablet -> tablet (740px)
• desktop -> tabletLandscape (980px)
• leftCol -> desktop (1140px)
• wide -> wide (1300px)

This change will be less jarring than the first alternative. However it will be an immediate breaking change with no deprecation period.

I'm interested to know your thoughts:

1. Is this a useful problem to solve?
2. If so, what are your opinions on the above alternatives in particular?
3. Do you have any other suggestions?

[gtrufitt]

I think I have a preference for Alt 1 - not tying to 'screen widths' seems to have longevity over things like 'phablet' or 'tablet' that are fairly meaningless in today's device landscape.

It means that we focus on building against relative widths rather than devices and those widths can evolve directly as pixel values.

On that point, I think the fluid_ prefix is more meaningful than mobile_. But maybe something like alpha_small and beta_small denotes the 'groups' in a way that is understandable i.e small obv before medium but mobile_large is not immediately obvious as smaller than small whereas alpha_large might be more obviously smaller than beta_small..? I'm not sure...

[SiAdcock]

Thanks @gtrufitt. Your second point is a good one that I hadn't thought of. It reminds me a bit of a Luke Wroblewski suggestion that human erognomics don't change much. I wonder if we could tap into that?

• palm_small
• palm_medium
• palm_large
• palm_xlarge
• desk_small
• desk_medium
• desk_large
• desk_xlarge

[gtrufitt]

Ah that's interesting!

[blongden73]

I spoke to Akemi at length about this the other day. What I like about our breakpoints currently or at least what I like about leftCol (I know you hate this one). But what I think it useful is that it very practically describes what the design does at that breakpoint across the majority of platforms. This is a nice way to look at things - I think you are right to try and make this human readable! But maybe thinking about practically what it is doing would help to make these things more usable.

What I think could be a problem is having so many like - large, xlarge, medium, small and then it having no correlation to what you are thinking about in terms of device but also what it is doing design wise. I have found with this type of thing no matter how long you use them it always requires a certain amount of referring back to find out what size they actually represent.

I'm just putting these thoughts out into the world to see if it helps bring a slightly different perspective - as I don't have a better suggestion at the moment.

[nicl]

Re @blongden73 I agree with a lot of what you say - tying names to our design approach is helpful to remember things. Another reason it's so hard to remember things is that we have so many breakpoints(!). Is there any thinking still ongoing about removing some? Some of the breakpoints presumably add very little value to users.

Edit, I do like @SiAdcock suggestion of clearly separating the main breakpoints from the mobile fluid grid ones - i.e. the mobile_ prefix or equivalent - as it makes things easier to reason about and maps onto the design approach as @blongden73 mentioned, so perhaps easier to remember. It might also provide a pathway to removing some of the mobile tweak points as/when they become less relevant to our users?

[SiAdcock]

@blongden73

But what I think it useful is that it very practically describes what the design does at that breakpoint across the majority of platforms.

This is a great point and helps to clarify what's happening here. Our grid and layout are foundational, and essential to the visual coherence of our different platforms. If most of our platforms have the concept of a left column, and there's a change to the grid above this breakpoint for this reason, then the name does make a lot of sense. It doesn't align so well with the other names which is a shame, but we all know naming things, especially in a consistent and scalable way, is hard™️.

@nicl

You provide a very helpful perspective here. I've often looked at our 8 break- and tweakpoints and thought there's a lot here, adding complexity to our code and a potential source of layout issues. But there's actually only 5 breakpoints that affect the grid. The other three are for smaller tweaks to provide designers with more flexibility on smaller devices where a few pixels can make a big difference.

Is it helpful to frame things in this way? Maybe we can make this more explicit with naming. Or maybe we can improve the intention of each break and tweakpoint with better documentation and tooling. The Guardian Grid Chrome extension is no longer available on the Chrome Web Store, but we still have the code so we can republish it if people find it useful.

[nicl]

@SiAdcock I definitely agree that separating out the breakpoints and tweakpoints in the code will help here. So 👍 to that!

It's also worth noting of course that even if the grid doesn't change, there's still a lot that can change across the mobile tweakpoints - the power of CSS basically - so the cost of these additional breakpoints is still high. (Too high for some I would argue.)

The other important consideration is that our design tends to be much more complex than some of our competitors - for example see the core article design for the NYT and WashPo - so the cost of breakpoints for us is that much higher.

[SiAdcock]

@nicl I take your concerns on board, I'm familiar with the complexity introduced by having a lot of available breakpoints. I've had similar discussions with @blongden73 in the past, and he is aware and sympathetic to the point of complexity. It is design flexibility that helps us stand out against our competitors and enables us to experiment quickly with new formats.

Removing a breakpoint can be tricky with some upfront cost we'll need to bear. To take an example, let's say we have identified that only a trickle of visitors view the site at themobileLandscape viewport size. There are around 80 occurrences of styles that use it in Frontend, a couple of dozen more in dotcom-rendering and a couple of dozen in support-frontend. Slowly removing it over time will require identifying each case in which it's used, some design reconsideration for each case and, following its removal from the CSS, some visual regression testing too. This is the tangible cost of removing that we'd need to balance against the as-yet unquantified cost of continuing to maintain it.

It would be useful to collect instances in which the cost of maintaining a breakpoint like mobileLandscape could be quantified so we can make a more informed decision.

Please do let me know if you have any further thoughts on this, or other costs / benefits I might have missed.

[duarte]

I'd suggest phablet as a candidate for removal instead of mobileLandscape, which is quite useful at least from a design perspective, as the layouts that work at 375px tend to 'break' around the 480 mark. On the other hand, nothing very useful needs to happen in the 80px between phablet and tablet, in my experience.

[SiAdcock]

Interesting, thanks @duarte! phablet is used a lot less frequently in Frontend.

If we were to consider smooshing mobileLandscape and phablet together, we need to be mindful that a whopping 20% of page views are on phablet-sized devices. Therefore I still think it would be worth assessing, from a design point of view, the benefit to these users of the tweaks we're applying in the 660-740px range. If the benefit is minimal, then I agree it's a better candidate for removal than mobileLandscape. What do you think @duarte, @blongden73?