Annoying window

Device manufacturers tend to choose to increase the screen's pixels in order to have a clearer screen on their device, but in some cases the increase in pixels does not give the user a good reading experience. Taking Apple's mobile device as an example, this article shows us why "high-resolution" screens bring "annoyance" to users' reading.

Every week, new devices come in a variety of screen sizes, pixel densities, and input types. As developers and designers, we all agree to mark, design, and write what we create by standards. Browser makers also agree to support these standards and set appropriate defaults for this, so we can achieve win-win results.

The agreement between developers and browser vendors has become more important than ever.

This is why when a device or browser vendor has violated the agreement, it will always do harm to everyone. If the other party is a very influential company (such as Apple), then the damage will be even greater.

Apple's newest tablet PC, the iPad Mini, suffers from a paradoxical situation: its device width viewport tag has the same default values ​​as the first-generation iPad (1024 × 768 pixels), but the iPad Mini's physical screen size is small 40%. This means that every button, graphic, link, and text line on the page is tiny on the iPad Mini - even if we try to get everything working and build a flexible, multi-device experience, we can not improve that.

But Apple is not the only culprit. This is a problem that has been around since we started using windows, not only with pixels but also with our own practices. Let us go back and re-examine the real causes of the current dilemma and see what we need to do to get out of the woods.

Pixel trouble

Yes, today's window dilemma can be traced back to pixels - tiny elements that we use every day. The first challenge with pixels is quantity. The more pixels on the display, the more information you can display. But since these pixels are physical pixels, the number can not be changed, so there is a second factor at work: the physical size of the screen.

Assuming there are two 2-inch wide displays (as shown in Figure 1), the right-hand display has a resolution of 640 × 960 and the left-hand resolution is 320 × 480, then in the same physical space, the right The number of pixels that the screen can hold is four times that of the left screen, the smaller pixel size results in less content and a brighter screen, posing a significant hurdle to reading.

This is exactly what happened with the Nokia E60. In 2005, most cellphone displays were 1.25 inches wide, averaging 176 pixels in width. But the E60 is equipped with a "huge" display with a resolution of 352 × 416, squeezing double the number of pixels into a similar space. The result is that the phone's screen looks gorgeous bright, but difficult to read.

The E60 also introduces a familiar issue that has long been familiar to users: how users access "big" websites on small devices. Nokia's solution is through a new browser, the Mini Map. This browser works similar to today's smartphone browser: first render the entire page and then scale it to fit the screen size you are using. Superimposed on this layer of rendering is a transparent red box that can be repositioned by the device's buttons and pressed to magnify what is displayed in the box.

Enter the window

The Mini Map may be one of the first commercial users of a dynamic viewport (a construct that is designed to enhance the user experience by dynamically changing the size or proportion of the area of ​​the viewable screen), but it is far from the last one.

In 2007, Apple released the iPhone, its volume much larger than the E60, but it also faces similar problems. Using a iPhone to access "true web" on a "huge" 2-inch display means loading a large page onto a small device. Apple solved this problem with a series of carefully crafted improvements.

First create a virtual window, similar to the one Nokia designed for Mini Map. When a user browses a desktop website, the browser first renders the entire page (the default canvas width is 960 pixels), and then shrinks the page until it fits into a 2-inch display. This allows users to interact with the page and scroll or enlarge the area of ​​their choice.

Apple did not stop there, it also developed a new viewport meta tag. Sites that do not use this tag will be rendered using the default 980-pixel traditional web window, but developers using this tag can declare windows for their own site, including "device-width values" that set the width to significant Tell the browser "Please choose the most suitable width for this device screen").

Soon, other mobile browser vendors began to follow Apple's practice. Until now, almost all mobile browsers support the viewport meta tag and "device-width value." This gives us a level playing field that respects the developers who spend a lot of time and effort adapting the site modifications to the multi-device network, and those that have not yet transitioned will still get a "good" default experience.

Mini problem

The value assigned to device-width by mobile devices and browser vendors is directly related to the physical size of the device. Devices with smaller physical sizes require smaller device-width values ​​(which can lead to excessive content). If this value is set too large, most of the content will be lost, the user can not comfortably read.

This is why the screen of the iPad Mini is flattered. Its "device-width value" is the same as regular iPad (768 pixels), but its physical size is much smaller. Because of this, the page size on the iPad Mini screen is 27% smaller (based on the relative size of the device pixels) than on Google Nexus 7, largely because Apple decided to define the device's window as 768 pixels.

According to the size of the content analysis

The first issue that results from parsing content is text. There are more pixels in the smaller space, which means that fonts defined in pixels will look small.

Of course, many people no longer use pixels to define size - we use relative size elements (such as ems), but this method does not solve the problem very well.

When using ems, we believe that the size of the fiducial font at the browser's default zoom level, in terms of 1em or 100%, is legible.

But that's not always the case, and the browser's benchmark font-size value (1em) is roughly equivalent to a 16-pixel square. The ratio serves as a link between absolute units and relative units, but different browsers may introduce some differences.

On the iPad Mini, the font size is 16 pixels. There may be no problem when the screen holds fewer pixels, but the fonts may be too small to read on high-density displays with less well-defined windows.

Of course, not all browsers support an em pixel ratio of 1:16. For example, the Kindle Touch browser has a high density of windows, but by using a 1:20 ratio, the default font size is increased by a few Pixel, you can get a better reading experience. Although this does not completely solve the problems encountered in the iPad Mini, at least the content displayed on the screen is clearly visible (as shown in Figure 2).

Figure 2 Rendering differences on 3 7-inch tablets

Why should Apple do this?

To understand why Apple Inc. will release a product that is not perfect on the Windows experience, we can tell by looking at how we use it.

After the release of the iPad, Internet practitioners around the world scrambling to adjust their own sites in order to be able to better adapt to the Tablet PC. Along the way, many of us have embraced the concept of pixel-based flat paneling that tends to target pixel-sized fixtures at 1024 x 768 devices.

If Apple lowered its "device-width value" based on the physical size of the iPad Mini, it would undoubtedly lead to a second confusion as those sites that were adjusted to the screen size of the tablet (assumed to be 1024 × 768) The device seems suddenly unacceptable.

The responsibility here is on both sides. Browser vendors need to provide a solid baseline of window and text size, and as implementers, we also need to stop controlling the layout at pixel level ("control" is just an illusion).

Way forward

The only way to move us forward is to work together. As developers and designers, we need to stick to those long-standing goals and focus on how we can do our job better, which means we're completely free from the concept of pixel precision. We need to win the trust of browser vendors so that they can listen to us when something bad happens.

Hopefully this essay will make it clear that what we're working on is right, and we want the approval and emulation of browser vendors as well.

Now, standards and consistency are more important than ever. We want the browser vendors and device manufacturers (such as Apple Inc.) to clearly recognize: we want to agree on the default window and its zoom, we are willing to adhere to the agreement, and we need these companies to join hands together to put this Part of the agreement to fulfill in the end.

Let us work together to march toward the future.