| Things I like about this article: + A focus on viewport size instead of screen size. Few people browse websites in full screen in fact "Full Screen" browsing is used almost entirely for people using a web browser for presentations or physical kiosks. A completely different use-case than regular desktop browseing. I loathe the fact that when I tile my windows to half my screen size the website "helpfully" switches into a tablet/mobile layout. Incidentally WCAG (which I consider a well-meaning but ultimately largely useless set of guidelines) can be blamed for a lot of this nonsense. Things that I hate about this article: - Like many "analysis" articles they start with a misleading validation of their sample size. 120,000 datapoints is not terribly big. - Implying that these screensizes can't be grouped together. Resolutions #3 and #4 are practically identical 393x660 vs 390x664 is essentially a rounding error. - Implying that any sane person should be considering how their desktop/mobile website should be displaying on a smart watch. This is totally different use case and (admittedly having never built anything for a smartwatch) I assume (hope?) that unless you've somehow identified your design as being smart watch compatible the browser is very liberally going to strip most of your layout and styling anyway to just text and headings. - Implying that anyone should care about the minor differences in screen sizes.
As a veterean of the Flip-phone days when the scourge of "form over function" phones (think Beyonce clamshell phone) was at its previous highest. There is no solving this problem. Apple swooped in an took a strong-armed approach to screen sizes that made developing on iOS EXPONENTIALLY EASIER than supporting MIDP or Android. - A useless masonry visualization of viewports in a garish orange/purple contrast that is impossible to read. Thanks for nothing. |
I feel like I must be a minority, My workflow is almost entirely switch desktop+ switch tab.