The Probable Need for Additional Mobile Web Scaling Standards

Ever so often I receive emails from various tech hardware and software houses about web standards, coding and the like. One such is from Intel Software Adrenaline, which is from their developer zone, where I’d signed up for and now come to learn a bunch of useful stuff from their YouTube channel about HTML scaling and responsive web design. As I thought about it one morning though, the burst of modern enhancements to screen resolutions in mobile devices, like the recently released Nokia Lumia 1520 smartphone with the 1920×1080 pixels screen resolution (vertically and horizontal pixel numbers, respectively), started to make me think about what that would mean for mobile web viewing experiences on a whole (there are other devices with similar screen sizes and high/er resolutions just to be clear). Certainly I thought, these new technology added a few issues that we’re bound to hit upon unless addressed in some fashion or the sort, and possibly too at perhaps the standards level.

The iPhone on the left shows the whole New York Times website fit into the dimensions of the device. The right iPhone in the image shows the same page zoomed into the middle column information area.

Do you remember just before responsive web design became a new norm, how sites would render mostly just ok enough on a smartphone screen since the debut of the original iPhone? Indeed during Steve Jobs’ demo of that ‘starter’ device back then he showed, if I can remember correctly, the New York Times, and how the site would display in the portrait view on the phone (which is how typically someone holding the phone may be naturally inclined to look at it). The Times looked exactly how it appeared on your desktop-bound web browser, only sharper and more beautiful, mostly because all the website content had to fit itself onto the small screen on an elegantly sexy device. Never even mind the fact that when he double-tapped on a particular section of the website the device would properly zoom in to scale to just that section appropriately, filling the screen’s width. Looking back at it the world was awed, and so was I.

The Nokia Lumia 1520. A 6-inch, 1920×1080 resolution phone with a hand in the picture to show scale. Image courtesy of fonearena.com.

I still am by the way, but 2012 and beyond started to bring in not only a foray of new mobile devices of every sort, with screen types and variant resolutions, but also a more normalness to the websites being cranked out which should now be designed to enable better rendering on these many variant form factors, and taking into account the different use case implementations that they each come with. Like for example, some mobile devices are pocketable and come with expected pocketable resolutions, some are more computer-based with larger screens, like today’s tablets for example, and thus carry with them appropriately larger resolutions for this kind of viewing, and then there are some that come with a seemingly odd mis-match of both size and resolution – a large device with a smaller-type resolution and a small device with a large screen resolution! To date, there are affordable tablet and PC devices that marry a decent 1 Megapixel resolution to a screen that’s about 7 inches – 15.4 inches or so. Otherwise read: a traditional laptop or a base-class tablet that has a 13×7 res or similar screen (1366x768, 1280×800, 1280x720 – otherwise all simply called 720p-type). Multiplying those two numbers together gets you the amount of total megapixels offered, by the way. And let’s face it, most people in the world today have these kinds of screens and they’re not really complaining – they display ok enough and look good for the most part (it’s just that now we have much higher resolution displays with brighter and newer tech in the market to show comparisons with). For modern smartphones like the first few generations of iPhone; that thing came with a screen res of 320×480, which again, is/was ok enough, especially when first demoed on stage, and then later used by the millions who’d go on to pick up that bit of hardware after its availability. Looking now at the software implementation side of things I kinda realize that it makes sense to not only design for screen resolutions, but also for physical screen sizes as well. That is, taking into consideration how big or small the actual screen is that the viewer is looking at. This is important because we have to consider that the amount of text data for example that your eyes can pick up has to be readable for it to be discernible by the eye and hence also, make legible sense to the person who’s reading. Small text info can be rather a frustration to read even when you can make it out, though for some it may prove impossible to make legibility of at all. Equally, overly large text may be a chore to look at as you’d have to scroll the text too often for that to be a good enough experience, not to mention the fact that the text will just be too eye-opening to take it all in – a middle ground that’s comfortable for most users is what’s needed, across a variant swath of device screen types and screen resolutions. I’m not exactly sure how this software implementation thing is technically defined should you go and dig down right into the plumbing of it, but still, wouldn’t it be cool if to tackle the resolution versus physical size issue, that the web app is fundamentally designed to take into consideration the screen size irrespective of the screen resolution is some cases? Like, if I had a phone, something pocketable, that even if the screen res is high on that thing, that I still get a web UI that’s fit for small devices? In other words, not because I have a 5 inch phone that has a 1080p display, means that the website that I’m viewing should display at the ‘full desktop’ resolution – it should be intelligent to scale down to the fact that I’m looking at the website in this example, on a small screen (small now meaning, relative to a typical tablet’s/Laptop’s display).

The HTC One oriented in the ‘landscape’ wide view. The website knowyourmobile.com is captured fully on this ‘1080p’ resolution 4.7-inch phone.

So then, on a device whose screen is 6″ and under, websites may be better shown in the mobile (small) form, irrespective of the screen resolution while in portrait mode. In landscape orientation, it can show in full (desktop) mode if the screen is say, 720p res or higher. Or even display a more mobile optimized but with more-on-screen-info-than-in-portrait view, better suited for touch input (by a user’s finger). Quite a few websites I think, show this ‘tablet’ view nowadays where the site’s layout is almost full-desktop-like having a lot of info shown on-screen, but with more appropriate touch controls, rather than for precise controls via a mouse/keyboard, or other technical input equipment or input methods.

From left, a Sony Experia, Nokia Lumia 1520, and an iPad Mini: two phones and a tablet display the website “The Verge”, from which this image is taken. Notice how all these mobile devices are oriented in a portrait style view with the length from top to bottom, but the exact same web page is shown in mobile form on the phones, but in full form on the larger-screened tablet.

For tablets whose screens usually start from 7″ on up it may be good to show the full desktop mode in landscape (or wide) view, for a minimum of a 720p screened device, but in portrait view, which is where the device sits long top-to-bottom, only after the device’s pixel resolution (from left to right) goes beyond 1280 pixels or so. Anything under 1280 pixels in portrait view can show a mobile optimized mode better suited for touch input. What about viewing websites on a TV? Shouldn’t the fact that you are seated farther away from that screen in a typical scenario, mean that it should show the more ‘legible’ small-screened website experience versus the full-desktop display-type, even on that 4k (or higher) display? Shouldn’t you be able to toggle the entire web experience to show in full-desktop mode, in the case that you’ve immediately transitioned from using the large screen as a TV (or far-off viewing device) for watching a movie, to begin using it as a desktop computer monitor because you’ve simply gotten out of the sofa and pulled up a chair right in front of the TV to do some detailed CAD work of a floor plan you’re thinking of showing to a client? And if so, should each website offer that? Or is it the browser that should enable that setting? Or the HTML coding that underlies everything? Heck, does it all even matter now really? I mean, right now in 2013 already, the capabilities of our devices and screens are so varied that it may not be too hard to look at all the different options that are currently available on each device and toggle the experience enough to fit the requirements of all the different scenarios that we may find ourselves in. Now to put into a tailspin all of what I’d said earlier, if later on we begin to use very large screened TV-type formats to be an additional front-end utility for compute tasks, then it may make sense to tailor the web experience to factor for those kinds of display scenarios too. Whether it will be seen that mobile UIs (user interfaces) work better from afar off viewing, or maybe the ‘desktop’-type, full experience may still be operable in that case, or perhaps even it will be down to the dictates of the (quite possibly) smaller human-interface device that’s directing and interacting with the larger display, via a wired or wireless connection, that determines the experience shown. But whatever the case is then, all device screen types, sizes and experiences ought to be covered for from maybe the coding/software standards side of things, given the vast variance of equipment that’ll exist over time to consume HTML-based content.

A point to note is that the manufacturers of equipment also probably have a role to play because they create each device, and should therefore have a handle on the usage scenarios for them, to ensure that the software that ships with the product enables target scenarios, whether in-built by its operating system, or by adding on top, additional (manufacturer-created) software to compensate.