Thought this might interest many of you…
A common question I get from clients is about designing a website for devices. I tell my clients it not devices, or even screen width, that really counts, it is browser width. So I regularly poll the the top 10 web analytics software to see what they consider the latest categorization of browser width.
For the most accurate reporting, the companies use window.innerWidth (browser code) to collect the screen size. It measures the width of the browser window where a website is actually rendered by the user, rather than the full screen width (and thus device).
These companies have standardized on four categories - Desktop, Laptop, Tablet, and Mobile. They define these categories by ranges of browser width. The ranges may seem wide, but they take into account portrait and landscape orientation where applicable.
-
Desktop - Above 1440px
-
Laptop - 993px to 1440px
-
Tablet - 577px to 992px
-
Mobile - less than 577px
A couple key points from these stats;
-
The biggest change I’ve noticed recently is the increase of user’s Desktop browser width rendering to over 1440px.
-
Being limited to 1200px in Sparkle doesn’t mean Desktop numbers are underreported. It just means there is value for Sparkle to widen desktop device above 1200px.
5 Likes
@thetravelhikelife, great reporting! 
To me responsive web design is still in murky waters and so what is good for today is not so for tomorrow. Not like print that’s for sure!
But in saying that I do agree that my experience with desktops is always 1200 plus.
Similarly my experience with mobile is more around the 440-480 mark.
Thank you!
I dream about the day we can make text flow on the web as we can with print.
I agree 440-480 is the sweet spot for mobile. I’ve been experimenting with turning off 320 completely and using only 480 in Sparkle. I create a “Safe Zone” for mobile portrait, as we do in print, and I’m getting good results. Helps workflow be more efficient.
2 Likes
@thetravelhikelife, Not as crazy as it sounds!
The day of the 320 (3.5") screen is long gone which Apple made sure of with it latest SE 4.7". Hunting around for mobile screen stats and I haven’t come across anything indicating the 3.5" screen is in use - I take the world stats are so low nowadays it doesn’t get mentioned?
I have also played around just using the 480 device for mobile portrait keeping the text boxes maxed to 310px and the results are good!
All in all a great discussion point!
Even with the diminished 3.5" screen, the 320 lives on in Slide-Over and Split-Screen views on iPadOS. In a few weeks we’ll see if any of this changes with the new iPadOS.
Even though I’d like to see Sparkle give us flexibility in determining break points, the defaults are well thought out by Duncan and team. iPadOS uses all 5 device breakpoints, iOS uses 2, while macOS uses 4 Sparkle device breakpoints.
Yes we’ll see…
The world of breakpoints is not an easy task and you’re right Duncan & Daniele have found the sweet-spots that for the most part works well!
Flexibility of breakpoints I think would be a scary thing. I once sat on a site with 9 responsive breakpoints and was scratching my head why? 3 odd years a go there was a bit of a breakpoint-frenzy where now there are a few platforms that have virtually gone down to two - desktop and mobile, but that is not adaptive web design.
For now all still works well but addressing the 1200 breakpoint wouldn’t be a bad idea as the desktop devices just get bigger and bigger like what the new iMacs have done. The rumour is that the 27" version won’t be 27" anymore but either 30" or 32"!
Grandiosa reflexión y razonamientos.
Yo no utilizo Sparkle de forma profesional, solo para montar mi web y mostrar mi trabajo, no tengo los conocimientos profesionales de un programador web, Aún así, estoy totalmente de acuerdo en solicitar la función de un mayor ancho para la versión de escritorio.
Trabajo en un iMac de 27 desde el 2017, siempre me ha parecido estrecho, y nunca tengo el navegador a pantalla completa, y cada vez veo más webs, diseñadas con un mayor ancho y sin tanto margen en la vertical.
Un saludo al foro!! Leeros me ayuda a aprender siempre algo interesante. Gracias.
Actually, I’d prefer an approach altogether different. Rather than multiple breakpoints, I think it would be better to simply have a Desktop layout and a Mobile layout. The mobile layout would be served automatically on phones but the visitor would have an option to switch to the desktop layout if she chooses. You see that often in the footer of the page (“Switch to desktop”) on some sites.
I’ll bet that the vast majority of Sparkle users design for no more than two layouts anyway.
@habboud, Switching devices with a click instead of it being served up is where Google and the likes get fired up and penalise so I wouldn’t go down that path.
The idea sounds great - desktop and mobile, but let’s have a think about it…
- the desktop has to cover from around 1440 down to 680 which means it has to become responsive in the layout plus fonts/images otherwise 1440 being scaled down to 680 will bring about small fonts, icons, and images - not pretty and not legible on tablet!
- the mobile would need to cover 320 to about 679 and probably could get away with scaling
All in all a lot of brainstorming, maths, and testing goes into making the platforms work and then the constant moving of the goal posts adds to the frustration.
I have noticed that Users are using desktop 960 and mobile 320 like you mentioned, and if they don’t auto scale the 768 device then the tablet takes on the 320 which just looks bad! So the way Sparkle works I would recommend the use of three devices minimum to cover the mobile to tablet to desktop range.
2 Likes
Hello.
I am quite comfortable with the simple design for 960 px and 320 px devices. All others are generated automatically.
The real problem for me is the automatic scaling of the font sizes. These seem to follow the math of the screen resolution, something like this:
1200 px = 1.25 x 960 px (16 pt --> 20 pt).
768 px = 0.80 x 960 px (16 pt --> 13 pt)
480 px = 1.50 x 320 px (12 pt --> 18 pt)
Only the adjustment from 320 px to 480 px is too large.
Here the factor 1.25 would be better: 12 pt --> 15 pt
The pages would have a somewhat more even appearance, I think. Would that be technically doable? What do you think?
Mr. F.
Legible paragraph text font should never be smaller than 15-16pt so 12pt is a big no. This is where the font style comes in handy per device.
For me I totally get the auto scale and how it saves time, but for me it also leads to lazy design! 
1 Like
I agree.
I keep paragraph text on mobile 16-18. I’ve never had a user complain about the extra scrolling that results from legible text, but many, many users complain if the text is too small.
Automatic scaling on devices is not just lazy, but really bad design. I’ve never seen autoscaling produce good results on any device.
Safari on macOS, iPadOS, and iOS automatically renders the device/width layout that best fits the browser width of the user. There is no need to offer the user a “switch” to choose between desktop or mobile.
If you have analytic software on your site, check the “bounce rate” per device. Bounce rate measures how quickly users abandon your site when first entering it. The bounce rate on unused and autoscaled devices can be 20X higher than well-designed device layouts.
I love it when a new client has unused and autoscaled device layouts. I can immediately increase a site’s page views dramatically and if selling something, revenue/profit skyrockets.
As I wrote above, I want more flexibility in choosing breakpoints, not less. The more freedom I have with choosing breakpoints, the higher value I can deliver to more clients.
1 Like
A related question here about device scale-factors. How can one determine the correct ratio between physical device pixels and theoretical CSS display pixels?
Looking at the specs for Apple’s iPhone 12 line, I see the following:
12 Pro Max – 2778 x 1284 pixels at 458 ppi
12 & 12 Pro – 2532 x 1170 pixels at 460 ppi
12 Mini – 2340 x 1080 at 476 ppi
Do these displays have a Device Pixel to CSS Pixel ratio of 2:1, 3:1, or 4:1? How would you determine that?
Further, when specifying point sizes for type, are we speaking of traditional printer’s points (72 points per inch), or are we really talking about CSS Pixels, where 12 point text is really 12 CSS pixel units tall?
The correct ratio between Physical Device Pixels and CSS Display Pixels for a specific device is calculated by running Javascript code in a web browser on that device.
All Apple’s X, 11, and 12 iPhones have a true ratio of 3:1. iPhones before the X line have some variability. You could determine that by cabling an iPhone to a Mac, activating the developer menu, and inserting the appropriate Javascript.
For Type on the web it’s all pixels. Coming from print, 1 point is equivalent to 4/3 (1.3333) physical pixels. Also, 1 Device-Pixel-Ratio translates to a font size of 16px, a ratio of 1.5 is a font of 24px, and a ratio of 2 is 32px.
Developers concentrate on CSS pixels while us designers have to be concerned with not only CSS pixels, but pixel ratio too. The formula we designers use is CSS Pixels = Device Pixels / Device Pixel Ratio.
When using Sparkle, the Image Resolution Meter (slider) is a good implementation of the Device to CSS ratio.
2 Likes
@thetravelhikelife
Thanks for the reply and information.
So, if the 12 Pro has a Device Pixel to CSS Pixel ratio of 3:1, and has a Device Pixel Density of 460 ppi, then the phone would have a CSS Pixel density of about 153 CSS ppi (460 px / 3 = 153.333).
Compare 153 CSS ppi to the printer’s point density of 72 ppi, the iPhone 12 has a CSS Pixel density that is over twice that of the printer’s point (2.12 : 1). You’d expect 12 point type then to appear half it’s nominal size.
Hmmmm.
Returning to your text, you mention that 1 printer’s point = 1.333 physical pixels. So, then this is what I understood you to say:
- On a device with a 1x Device-Pixel-Ratio, 12 pt type will render as 16 device pixels in size (12 pt x 1.333 x 1 = 16 px), which equals 16 CSS pixels.
- On a device with a 1.5x Device-Pixel-Ratio, 12 pt type will render as 24 device pixels in size (12pt x 1.333 x 1.5 = 24 px), which equals 16 CSS pixels.
- On an iPhone 12 with a 3x Device-Pixel-Ratio, 12 pt type will render as 48 device pixels in size (12 pt x 1.333 x 3 = 48 px), which equals 16 CSS pixels.
Is that correct?
But then I guess the apparent size of the type on screen won’t be very close to an actual 12 points.
12 points = 1/6th of an inch.
153 CSS ppi (iPhone 12) / 6 = 25.5 CSS px.
But 25.5 CSS px ≠ 16 CSS px (instead, a ratio of 1.6 : 1)
Also, 16 CSS px / 153 CSS px = 0.1, just as 48 px / 460 px = 0.1
72 points x 0.1 = 7.2 pts.
So does the iPhone 12 render 12 pt type at an apparent size of 7.2 pts. ?
Also, above in the thread, you mention that you have abandoned 320 layouts in favor of 480 for mobile. It appears that the CSS pixel witdth of the iPhone 12 and 12 Pro is just 390 CSS px (1170 / 3 = 390). Do you just accept that your site will scale down in portrait orientation?
I’m loving this!
But seriously in the end the only way to know how the font size will look is testing it on the actual device… Well that is nearly impossible on all devices out there and a very expensive investment to achieve!
For me mobile landscape is not important. Stats shows it isn’t used to view website content, only website media so I don’t go there.
Like @thetravelhikelife said, autoscaling does nothing to improve the user’s experience of your website other than save us time in creating the website.
I agree with “mobile landscape is not important”
But the 480 px device breakpoint comes into play, when you have a tablet in portrait mode. That is not mentioned in the device selection.
And YES, autoscaling makes our work a bit easier 
Mr. F.
@Mr_Fozzie, There is a couple of ways you can go without the 480 device coming into play…
- 1200 (desktop HD and Laptop), 768 (tablet portrait and landscape), 320 (portrait and will also behave on landscape)
- 960 (desktop HD, laptop, and tablet portrait), 768 (tablet portrait), 320 (portrait and will also behave on landscape)
If you use 960 the desktop HD, laptop, and tablet landscape will pick it up. Then by introducing the 320 the mobile portrait, mobile landscape and tablet portrait will pick it up. So now we have the mobile portrait showing up on the tablet portrait which really really looks bad! So by introducing the tablet device it will cover portrait and landscape, not needing the 480 device.
From my point of view the best combination is 1200, 768, and 320 with no auto-scaling of the 960 nor 480. That way i cover the broadest range of devices.
Hi Greenskin.
Thank you. So, you set the 960 and 480 to “not present” - right?
And the browser will do the rest when a visitor shows up with a device that has these resolutions?
I have only a few pages - less than 30 - in my project. Maybe i will do a redesign.
Mr. F.
Yep @Mr_Fozzie, that’s correct!