Modification - Mobile Breakpoint

[james-hayden-ellis]

Type of request
Modification

Component, pattern or foundation?
Foundation

Nature of request
Enquiring to see whether we should use the recoding of the DOTCOM front end as a way to update our mobile breakpoint (currently 320px) and what that breakpoint should be.

General UK stats for the past 12 months : https://gs.statcounter.com/screen-resolution-stats/mobile/united-kingdom

L&G stats are a bit skewed as according to Mike Tomsett: "There is a know issue with iPhones where they don't properly report the user agent and therefore we don't get completely accurate device information beyond "it's an iPhone"! and there's a default setting in Adobe for that viewport. Matt's (Blake) recommendation was to exclude iPhones from the results and see what they look like after that. They could look at a better solution for getting that information into Adobe, but it won't be quick enough for us to make the decisions we need."

But here are the Adobe Analytics for mobile screens for the last 12 months (though I can't figure out how to exclude the 320x480px)...

[alexcanning]

Have we landed on a safe / most commonly used minimum width?

[owensgit]

I think it's worth revisiting the sm breakpoint (320px), in some ways it's not that helpful for us, because when styling something at min-width: 320px, we're essentially saying that this is the base style for lowest screenwidth possible, so no need to use a breakpoint at all. The same goes for max-width: 320px, the user would never see the styles because they will never view it on a device less than 320px.

I would sugest that the sm breakpoint could be updated to we can add modifications for users with large mobiles, which aren't quite tablets - small enough to need a mobile layout, but large enough to do more with the available space than a smaller phone.

If so it would need to sit somewhere between 0 and 768px (md breakpoint).

For reference, here are our current breakpoints:

$breakpoints: (
  // 320px
  'sm': 20rem,
  // 768px
  'md': 48rem,
  // 1024px
  'lg': 64rem,
  // 1280px
  'xl': 80rem,
  // 1440px
  'xxl': 90rem
) !default;

[elenagarrone]

@owensgit I agree with you 👍

[alexcanning]

Could we introduce a new XS breakpoint which has a max-width of less than SM, and make a SM min-width slightly more useful?

[elenagarrone]

Yes, that would be possible but is it really needed? Who is doing this investigation? will it be dotocom?

[james-hayden-ellis]

Here's the original JIRA ticket request...

Description

Currently the responsive image block automatically creates 3 smaller versions of an original uploaded image as below.
These are also set as the breakpoints for viewport sizes of each image.

Name	Image width (px)	breakpoints (px)
Original (large desktop)	1400 - 2000	>=1013
Desktop	1012	769=<=1012
Tablet	768	321=<=768
Mobile	320	<=320

Should we continue to use these image sizes / breakpoints?
If new image sizes / breakpoints are needed, what should they be?

Particular attention should be paid to mobile. Most mobile viewports these days appear to be around 414px wide meaning most devices load the tablet image version.

[owensgit]

Having a look at Bootstrap's most recent breakpoint values, they have a xs which is actually just 0 - essentially not a breakpoint, but just the default mobile-first setting. And then they have a sm which is 576px. This is similar to @alexcanning 's suggestion, but I'd recommend not having xs, as @elenagarrone also suggested, as it seems kind of pointless - why would we do min-width: 0 or max-width: 0? 😄

Tailwind CSS does this, it has a sm breakpoint of 640px, but no xs.

My favoured approach would be to increase our sm breakpoint to either 576px or 640px - whichever one starts to look a bit stretched on larger mobiles/small tablets, therefore opening the door ot creating some nicer layouts/optimisations in that region. It will need thorough testing of existing components and features that work with responsive styles such as showAt, and the responsive margin/padding directives. I guess would also be breaking change. Worth it though :)

@james-hayden-ellis I think that might work well with the image size issue you meantioned, because the mobile size image could be displayed for devices below 576px or 640px, which should be fine - although the image files themselves may need to be optimised for those sizes.

[james-hayden-ellis]

Okay, so after reviewing the stats @alexcanning and I settled on suggesting a new 400px viewport size, so that'd roll into and readjust the current system like so...

Name	Image width (px)	breakpoints (px)
XS (Small Mobile)	400px	<=399
SM (Mobile)	768px	400 - 767
MD (Tablet)	1024px	768 - 1023
LG (Small Desktop)	1280px	1024 - 1279
XL (Desktop)	1440px	1280 - 1439
XXL (Large Desktop)	2000px	1440+

Anyone (particularly from Dev) see any issues..?

[elenagarrone]

From @owensgit on slack:

I’d still question if 400px is useful from a mobile-first layout point of view. I can’t see us needing to made any changes at the 400px breakpoint, but I could at 576px for example

[elenagarrone]

@elenagarrone the XS breakpoint in your table has a very small window of use - propose we lose the XS breakpoint and set default to 0 to 399px, and set SM to 400px to 767px

Yes, I agree with you - XS is probably unnecessary. What do we think about what @owensgit has proposed?

[alexcanning]

It has merit - allows us to design any small mobile size we like, while giving us provision for larger mobile devices. Could be a good thing. @james-hayden-ellis ?

[owensgit]

Don't forget it's the way other frameworks such as Bootstrap and Tailwind have also gone :)

[elenagarrone]

@james-hayden-ellis @alexcanning any update on this? I'm currently working on v8.0.0 of Canopy and it would be good to know if we want to include the changes to the grid. I'm referring in particular to @owensgit's point of the breakpoint at 576px instead of 400px.

[elenagarrone]

@alexcanning and I had a chat about modifying the current breakpoints and decided it's not something we want to do for the moment as it needs more investigation.

I'm marking this as resolved and we can pick it up again if an update is needed.