The Windows 8 user interface is designed to scale to systems of all sizes. Like Windows versions of old, it will have to scale all the way from 1366×768 10-inch tablets up to 2560×1440 30-inch desktop monitors and beyond. But it's not just different numbers of pixels that Windows 8 will have to cope with: different sizes of pixels matter too. Windows 8 will have to scale from screens with around 96 dots per inch all the way to screens with almost 300 dpi, as system vendors are finally starting to increase pixel densities (no doubt inspired by the launch of a rather successful new tablet). An explanation of how this has been done is the subject of a new post on Microsoft's Building Windows 8 blog.
Windows has long had support for both different resolutions and pixel densities. The former are easy to handle; run Windows on a system with a high screen resolution and you'll fit a lot more stuff on screen. Traditionally, monitors have all offered about 96 dots per inch, so no matter what resolution you used, the objects on screen (buttons, text, images, and so on) have more or less maintained their physical size.
More problematic have been monitors with wildly different pixel densities. If a program draws buttons that are 16 pixels tall, they might be perfectly readable on a 96 dpi screen, but far too small to be easily understood on a 200 dpi one. Windows has a slider to control the number of dots per inch the screen uses, and if you use a screen that's substantially higher than 96 dpi, this slider can be used to restore the physical size of objects on-screen.
However, using this slider has never been a panacea. Most of the time it does work well enough, but some applications break, drawing themselves improperly. Other applications simply don't fit on-screen. For example, the Samsung Slate 7 tablet has an 11.6 inch 1366×768 screen, which is about 135 dpi. With the operating system set to use 96 dpi, everything comes out a little small. Unfortunately, at this resolution, some of the operating system's own dialog boxes no longer fit on-screen, and have their bottom portions placed behind the taskbar, or off the screen entirely.
As a result, most Windows users tend to just leave the operating system at 96 dpi, and accept that things will come out a bit small. And for a mouse-driven operating system, it isn't that big a deal: the mouse is a pixel-perfect pointing device, so the mouse can hit even small targets with relative ease.
But when touch is thrown into the mix, that's no longer the case. For touch, preserving the physical size is essential: if something's too small, you can't touch it. This problem already plagues Web sites, and it makes for a substandard user experience. Everything touchable needs to be about 9mm × 9mm at a minimum.
With Windows 8 being designed for touch apps, and with higher pixel densities starting to become mainstream, clearly the problem needs to be addressed. And for Metro applications, that's exactly what Microsoft is going to do. Metro-style applications will have much stronger support for high-dpi screens, and will preserve their physical dimensions on touch systems, regardless of pixel size.
Creating scalable interfaces for Metro-style apps will be much easier than it is for desktop apps today. Metro apps will have a minimum size of 1024×768, a widescreen minimum of 1366×768, and a snapped view of exactly 320 pixels wide. They're also not infinitely resizeable: in addition to these minimum sizes, they'll always have an aspect ratio of around 16:9 or 4:3. Together, these decisions greatly reduce the number of permutations and complications that developers will have to consider.
Scaling itself has also been standardized. Windows 8 will have two scaling factors for Metro apps, 140 percent and 180 percent. These numbers seem strange, but they are designed to make content on 1920×1080 and 2560×1440 screens appear the same size as 1366×768 screens with the same physical size.
Microsoft explains that it expects 10-inch and 11.6-inch tablets with 1920×1080 and 2560×1440 resolutions to be common for Windows 8. Windows 8 will automatically pick a scaling factor depending on the device's physical size and screen resolution.
The core XAML and HTML development frameworks used for Metro applications will automatically handle the scaling of text and vector images. For bitmaps, developers can either depend on the built-in scaling, or include multiple versions of bitmap resources that have been manually redrawn at the larger sizes so that their images will remain crisp and clean even when used on these high-resolution machines. HTML applications will be able to use CSS media queries to switch out low-resolution graphics with high-resolution equivalents.
For testing applications to ensure that they scale correctly, Visual Studio 11 includes a "Windows simulator" that allows developers to see how their applications will look on a wide range of screen sizes and resolutions.
Microsoft didn't elaborate on whether the desktop would be treated differently. In the current Consumer Preview, the Windows 8 desktop supports the same kind of resolution scaling as Windows 7, and the setting appears to be independent of the scaling applied to Metro applications. The Windows 8 desktop is not touch friendly in any case, so the difference is less important—to work well, it needs a pixel-perfect input device anyway. On the other hand, with Office 15 using the desktop, some improvement in touch friendliness and scaling is highly desirable.
More problematic will be Web sites. Although technically they could include multiple bitmap sizes using CSS, the reality is that there are essentially no sites on earth that actually do this. This means that Internet Explorer 10 on high resolution systems is going to have to scale everything on a Web page by 1.4 or 1.8 times. This is a problem, because these fractional scaling factors will produce fractional results. For example, an image that's 16×16 will be scaled to 22.4×22.4 or 28.8×28.8. Obviously this will have to be rounded down or up, but that rounding will cause a slight change in the proportions of the layout. Lines and boxes that fit exactly on the screen's pixels at 96 dpi will end up being smeared across multiple pixels when scaled.
Ensuring that lines and boxes, as well as bitmaps, look good with these scaling factors may well prove challenging. For Metro applications, Microsoft recommends using a 5-pixel grid; objects whose natural size is a multiple of 5 will scale cleanly with both scaling factors. But the Web is altogether more freeform.
Apple's high resolution displays, the 960×640 screen on the iPhone 4 and iPhone 4S, and the 2048×1536 screen on the 3rd generation iPad, avoid this conundrum by using only integer multiplication—they scale by exactly 2. A straight-up doubling of Microsoft's baseline 1366×768 would be easiest to handle and exhibit the best visual quality, but 2732×1536 might be too high to arrive during Windows 8's lifetime.
