Scaling to different screens

One of the core promises of the Windows platform has been its support for diverse form factors, allowing Windows to power over a billion PCs in the market today. In Windows 8, we set out to build upon this strength by delivering a great experience regardless of the form factor or screen size. Windows 8 PCs will come in a variety of shapes and sizes, from small tablet screens to laptops and large desktop monitors and multi-monitor setups. They will also scale to different pixel densities; from that of the typical tablet to new high-definition tablets. The following principles guided us in our design process:

1. Offer customers a broad choice of form factors while providing a polished, consistent, and predictable user experience.
2. Enable developers to easily build apps that look great on all form factors in the Windows ecosystem.

With Windows, you can choose a PC that works for you, with a screen that best meets your needs, preferences, or style. For example, a student might buy a touch-enabled laptop with a big screen because they want to be able to write papers but still have fun watching movies or playing games on a touch-screen. Families might opt for an all-in-one desktop with a huge touch screen to view and organize all of the family photos. An accountant with a long commute might pick up a small tablet that easily fits in her bag to surf the web or catch up on her reading during her train ride to and from work. A professional architect or financial trader might have three screens in a mixed portrait and landscape configuration, with one touch screen in the mix.
Windows 8 will power all these PCs and experiences, and as people transition between different sized screens in their day-to-day lives, they will be greeted with a consistent and familiar experience. This breadth of hardware choice is unique to Windows and is central to how we see Windows evolving.
In Windows 8, apps power the user experience, so providing a development platform that makes it easy for developers to create a beautiful user interface that scales to all screens is paramount. For this primary reason, Windows 8 was engineered from the ground up to be a platform for making great apps that work on a variety of screens. 

Device diversity

Looking at the breadth of devices that will run Windows 8, we can classify their screens in several ways.

• Screen size: There will be PCs with different screen sizes, from the smaller screens on tablets, to medium sized laptops, and large desktops and all-in-ones. These screens will also come in different shapes or aspect ratios.
• Screen resolution: Screens will have an increasing number of pixels on screen, or screen resolution. In general, the larger the screen, the higher the screen resolution, but this isn’t always the case.
• Pixel density: Screens will also have different pixel densities, which is the number of pixels within a physical area, or dots per inch (DPI.) The pixel density increases as the screen resolution increases, but the screen size remains constant.

Screen size, resolution, and pixel density were each considered carefully when designing Windows 8 for users and developers. When talking about screens, it is very important to be clear about the variable or dimension being talked about. For example, a 13” screen might be running at any number of resolutions (which means any number of pixel densities) and might have one of several different aspect ratios.
This graphic shows a sample of the diversity of common wide-screen aspect ratios and screen sizes that Windows 8 can run on. Windows will support just about any screen dimension so long as the graphics driver and hardware combination provide the correct information to Windows. In addition, some screens will scale to different aspect ratios via cropping and/or stretching. And although we indicate slate or laptop in the diagram below, please keep in mind that these are “fuzzy” boundaries that are getting more fuzzy all the time.

    

Minimum resolution

I’ve seen a few blog comments that ask specifically about minimum resolution, for example on Designing the Start screen in October 2011, @wolf asked:

“A better idea would force all developers to make sure all Metro app[s] [are designed for] a minimal screen size of 800x600. Limiting Metro apps to only 1024x768 will cut out all netbook users as well as hurt the Windows App Store."

We chose a minimum screen resolution of 1024x768 in order to make it as simple as possible for developers to create great apps that work on all the different screens that are available now and in the future. A minimum resolution provides a necessary starting place for developers, who can use it as a baseline to ensure that all of the navigation, controls, and content fit on screen. As we worked on different design layouts for apps, we found that the higher the minimum resolution, the richer and more tailored the app could be. We wanted developers to be able to tailor and refine their layouts to make use of every available pixel on 1024x768, without having to compromise the layout for a smaller resolution.

Windows 8 has a minimum resolution to allow developers to create rich layouts that make the best use of space at 1024x768

Why choose 1024x768 as a minimum?

We chose 1024x768 as a minimum for Metro style apps for three reasons.

• It is large enough to support the rich and beautiful layouts that we expect to see with Metro style apps. Lower resolutions, like 800x600 for example, require simpler more basic layouts with less content.
• Websites are typically designed for 1024x768 as the minimum (or only) resolution, and web developers are used to targeting this resolution.   
• Looking at the data about devices in the marketplace today, we see that only 1.2% of active Windows 7 users have screens with a resolution of less than 1024x768. When designing a new platform that supports the devices of today and tomorrow (with undoubtedly higher resolutions) we optimized for the majority of today’s screens (i.e. 98.8%) without sacrificing the experience and complicating the developer story for legacy screens. In addition, the runrate of new PCs with screen sizes of 1024x600 and 1280x720 has dramatically fallen and, to the best of our knowledge, almost no new mainstream PCs are being manufactured with this resolution. We are aware of purpose-built machines that run at lower resolutions, which are built for specialized desktop apps as well. While many run virtual machines, VMs can easily support 1024x768 even though many default to lower resolution.

A world without a minimum

Some people have asked why we enforce the minimum resolution instead of just communicating it as a loosely supported recommendation. Enforcing the requirement simplifies the lives of developers as they never have to take these lower screen resolutions into consideration—they can just rule them out. If an app isn’t designed with consideration for lower resolutions, some layouts could truncate, wrap, or break in unpredictable ways. Developers would not be able to confidently build apps to look good on all devices that Windows 8 supports. If we were to have a loose requirement, some developers might build and test for these lower resolutions, while others might not, yielding a fractured ecosystem where developers start targeting specific devices instead of the platform as a whole. Also, developers might target the least common denominator and pick the lowest possible resolution, which in turn would be detrimental to the user experience and quality of the apps.

The layout of this game would be truncated at the bottom if allowed to run on 1024x600

Minimum resolution and snap

The resolution that supports all the features of Windows 8, including multitasking with snap, is 1366x768. We chose this resolution as it has enough horizontal pixels to fit the 320px width of a snapped app, next to a main app with a 1024px width. The specs of the Samsung tablet that we unveiled at the //build/ conference are 11.6-inches with a 1366x768 resolution (the Samsung Series 7 tablet in market today). These specs are the minimum screen resolution that supports all the features of Windows 8 on a useful physical size.
         The snap view is always a fixed 320px wide, which allows developers to refine and create a targeted view for this size. A width of 320px is a common and familiar size that developers are already designing for on various phone platforms.
Some people have asked why we don’t allow for the snap view to be arbitrarily sized, or offer a variety of different multitasking sizes. Supporting arbitrary sizes for this small of a layout can significantly increase the complexity of building an app, and would require a lot of additional work and complexity from the developer.
Although the width of a snapped app remains fixed, the vertical space increases to fit the screen, so on larger screens you won’t have to scroll as much. The //build/ talk 8 traits of great Metro style apps provides many great snapped layout examples. We will discuss snap and multitasking more in a future post.
Below are several examples, with the snapped app layout on the left, and the primary app layout on the right.

Is there a maximum resolution?

You may be wondering why there isn’t a maximum resolution. With higher resolutions there is more space, so the layout is really never broken or truncated on higher resolution screens. You can run Metro style apps on a screen as big as 30” with a resolution of 2560x1600! But although apps aren’t broken when they have more space, developers should give some consideration to these larger resolution screens, so that they make use of the space in a way that keeps their apps looking beautiful.

Larger screen sizes

On larger screens like desktop monitors, people generally expect to fit more content on the screens—as the screen size increases, screens have more pixels. The below diagrams demonstrate how, when the screen size and number of pixels increase, the number of objects of the same size on screen also increases. On the small screen below we can fit about 40 orange squares, and on the larger screen we can fit 84 squares of the same size.

  Larger screens generally have more pixels and can therefore show more content 

But just because more content can fit on screen this doesn’t mean every app will make use of this space. If an app is designed with fixed dimensions or a specific form factor in mind, larger monitors may display a large empty region, as in the example below. This is not a good experience, as some have commented.
Regardless of your large screen resolution, today most websites are not particularly well tailored for large screens and tend to leave lots of space (many users prefer to zoom in on the text using the CTRL key and the mouse wheel on large displays, or the keyboard shortcuts CTRL+, CTRL -, CTRL 0). This is the same on the mobile web, when sites are too big to fit on a mobile display. More and more web developers are adapting their content to different form factors by using a combination of form-factor detection and the use of apps.

Without consideration for different screen sizes, many apps would have large empty regions when shown on larger screens

The Windows 8 platform makes building one app that scales to different screen sizes straightforward for the developer by providing built-in layout controls and techniques. Apps in Windows 8 fill the available space by bringing in more content where possible. A developer can easily build the same app to show more content as the screen size changes from a tablet, to a laptop with a bigger screen, all the way up to a desktop monitor. For example, this news app shows more articles on bigger screens. It should be noted that the underlying platform and tools have been developed to provide support for asynchronous programming which also enables “filling” larger displays, and making them just as fast and fluid as smaller displays—there’s no need to block the user while fetching and filling large amounts of content.

Building apps for larger screen sizes

Windows 8 has been designed to work in a predictable and consistent way for screens of different sizes and shapes across tablets, laptops, and desktop monitors. When a user changes to a different sized screen, it’s important that the system and apps make the best use of the screen space that’s available to provide the most immersive experience.

With adaptive layouts like this sample app created for the Developer Preview
at //build/, users see more content on larger screens

One way that Windows 8 helps app developers to adapt their apps for this variety is through support in the app platform for standards-based adaptive layouts. Building an app layout that looks great on different screens has been a challenge in the past on the web. Rather than inventing a new, proprietary set of layout controls, Windows 8 has built-in support for the familiar adaptive layout techniques from XAML, and for the W3C ratified set of CSS3 features, which were designed specifically to make this easier for web developers.
In HTML, the CSS3 grid, flexible box, and multi-column layouts help developers use screen real estate more effectively across a variety of devices and resolutions.
The CSS3 grid layout allows a developer to specify the rows and columns of their layout; it is similar to using an HTML table but provides much more control and flexibility. A grid is also great for defining a top-level adaptive layout that is similar to the ones that you see in the Windows 8 UI (like the Start screen and the file picker). You define the rows and columns, and then place your content into the cells of the grid. It is simple to define which cells should adapt and reflow to the screen.

CSS3 flexible box layout allows a developer to distribute margins and whitespace equally and predictably. It’s great for laying out individual components and collections like toolbars and image collections.
Finally, CSS3 multi-column layout can be used to arrange content into multiple columns on the page, similar to the layout of a newspaper or magazine. All of the templates provided with Visual Studio 11 use these layout constructs and leverage the ListView and other controls to support different sized screens by default. Developers can use the same standards-based layout techniques and controls that help them accommodate different screen sizes to also help them adapt the layout to different orientations and snapped views. All of the layout constructs available in HTML are available for XAML developers as well.
Some apps, particularly games and game-like rendered UI, do not wish to take advantage of more space with higher screen resolutions. For these apps we provide a way to easily scale an app that was designed for 1366x768 to fit any screen. If the aspect ratio doesn’t match the content, the system provides theme-able letterboxing regions as well. While this isn't ideal for all UI because it may make things appear quite large on desktop monitors, it does work well for many games and game-like UI that is composed mostly of bitmap graphics. This solution also allows apps to remain immersive on a variety of screens without needing significant work from the developer.
        

With fixed layouts like this 5inarow game, users see the game bigger on larger screens

We believe it is important for app developers to be able to choose which layout technique—adaptive or scaled to fit—makes the most sense for them, depending on their content and their workflow. If all apps were adaptive, it would be difficult to build game-like rendered UI that fills a 23” 1920x1080 screen without huge empty margins. On the other hand, if all apps were scaled to fit, users wouldn’t be able to see more email messages on their 23” 1920x1080 screen. We believe that our solution strikes the right balance, and provides developers with the choice and tools to optimize their apps for different screens based on the scenarios that are most important for them.
You might be wondering why we don't just let apps arbitrarily resize and not worry about any of this. That is a reasonable question given the history of resizable windows in Windows. In fact, the first version of Windows supported "tiled" Windows and it was not until Windows 2.0 that overlapping windows were supported. We focused on tailored full-screen layouts for Metro style apps for all of the reasons you have just read, along with the desire to have reliable experiences at many resolutions.
This may seem counter-intuitive given our experience in Windows every day. But as we look across many apps and the ever expanding screen sizes available to us all, it has become clear that developers are no longer optimizing for the diversity of screens available. Though most software lists minimum requirements, in practice, we see many errors—with UI that is clipped, awkwardly placed, or just poorly rendered when windows are resized or maximized. We also see assets (icons and UI elements) that do not properly scale to a variety of pixel densities. Even in the designs of the ribbon in Office 2007, much effort went into scaling the ribbon, as you can see in this series of screen shots.

Image from Scaling up, scaling down on Jensen Harris: An Office User Interface blog

Unfortunately, most applications do not take advantage of controls that are already available (like the Windows ribbon) to successfully scale. As a result, end-users have to learn how big or small to make a window and developers have to deal with bugs and inconsistencies in resolutions that they might not be testing for, since they cannot prepare for all resolutions, aspect ratios, and pixel densities. As developers created their own layouts, controls, and UI metaphors they also built in assumptions about screen resolution and pixel density required for their code, but rarely enforced these (even today, Windows property sheets clip at below 600 pixels as some have seen with early netbooks or on VMs).
In general, while many reading this blog find arbitrary window sizes something they can manage and arrange, data consistently shows two things. First, on laptops (over 75% of PCs purchased by consumers) most applications are run maximized all the time—this makes sense given the real estate available and the design points of most interfaces and web sites. Second, on large screen displays, most windows are sized to a reasonable number of rough dimensions primarily because most programs do not support “infinite” scaling.
We're going to see new user interface approaches and new ways to organize commands. Windows 8 contains a very rich control library and vastly more flexible tools and languages for coding user interface layouts than any previous release. And of course, the Windows desktop is still there (and is improved), where you can continue to work with the capabilities you are used to for the apps you currently use.

Different pixel densities

Pixel density is a new concept to a lot of people but it is closely tied to our discussion here of screen size and screen resolution. Basically, the pixel density is the number of pixels in a physical area. This is commonly described as dots per inch, or DPI. As the pixel density increases, the physical size of fixed pixels decreases. Some of you may have observed how text can be very small on very high-resolution laptops. Historically many are familiar with “large fonts” or “make text bigger” settings on the desktop to compensate for these physics. Windows 8 takes this to a new level of support for WinRT applications.

On higher pixel density screens, without scaling, physical sizes are smaller.

Most of us are used to fairly low-pixel densities in laptop and desktop monitors; for example, a common laptop with a 13” screen size and a resolution of 1280x800 has 116 DPI. Because of the active ecosystem bringing different displays to market we are seeing incredible advances in the pixel densities of screens on the market. Many Windows 8 tablet PCs will have pixel densities of at least 135 DPI - much higher than many of us are used to. Of course we’ve seen the introduction of HD tablets with Full HD 1920x1080 resolution on an 11.6” screen, with a pixel density of 190 DPI or quad-XGA tablets with 2560x1440 on the same 11.6” screen; that’s a pixel density of 253 DPI. Pixel densities can increase even more on lesser aspect ratios and smaller screens as we see in the new iPad. As the pixel density increases, the physical size of objects on screen gets smaller. If Windows wasn’t built to accommodate different pixel densities, objects on screen would be too small to easily tap or read on these tablets.

Without scaling, objects are too small to tap easily on a higher pixel-density screen, like the HD tablet on the right.

For those who buy these higher pixel-density screens, we want to ensure that their apps, text, and images will look both beautiful and usable on these devices. Early on, we explored continuous scaling to the pixel density, which would maintain the size of an object in inches, but we found that most apps use bitmap images, which could look blurry when scaled up or down to an unpredictable size. Instead, Windows 8 uses predictable scale percentages to ensure that Windows will look great on these devices. There are three scale percentages in Windows 8:

• 100% when no scaling is applied
• 140% for HD tablets
• 180% for quad-XGA tablets

With scaling in Windows 8, physical sizes are maintained on high pixel density devices, and text and content on screen is crisper.

The percentages are optimized for real devices in the ecosystem. 140% and 180% may seem like odd scale percentage choices, but they make sense when you think about how this will work on real hardware.
For example, the 140% scale is optimized for 1920x1080 HD tablets, which has 140% of the baseline tablet resolution of 1366x768. These optimized scale factors maintain consistent layouts between the baseline tablet and the HD tablet, because the effective resolution is the same on the two devices. Each scale percentage was chosen to ensure that a layout that was designed for 100% 1366x768 tablets has content that is the same physical size and the same layout on 140% HD tablets or 180% quad-XGA tablets.

The scale percentages in Windows have been designed to maintain touch targets and
layouts, while optimizing for real tablets coming on the market in the near future.

Some might be curious about the new iPad screen. For this screen, Apple has chosen a scale factor of 200%. The new screen has twice the pixel density (132 PPI to 264 PPI)* on the same size screen. Because iOS and developers only need to support the predefined resolutions, they only need to design for this one additional scaling factor. In the case of iPad 2 compared to new iPad the 200% scaling factor means that what you see on 1024x768 is exactly what you see on the new resolution, only sharper because more pixels are used (as in the image of the app above). Additionally, on higher pixel-density screens like the new iPad, developers for games and other performance-critical apps may decide the right balance between letterboxing and running at a lower fidelity to deliver the best experience (frame rate, for example).
Scaling is invisible to the user and Windows implements it automatically based on screen dimensions, without the need for intervention from the user, IT administrator or OEM vendor. Developers just need to make sure images look great on each of the scale percentages. Because these scaling percentages are predictable, developers who provide images for each percentage can easily avoid any blurriness or artifacts due to image stretching.
Pixel density offers another variable where the existing paradigms of toolbars and menus are becoming increasingly burdensome to use. "Hacks" such as large fonts or tricking the system into using a different DPI are just that—hacks. As anyone who has used a high-DPI screen can tell you, existing applications and the UI paradigms simply don't function, and become unusable. A typical example is when a common toolbar button becomes a diminishingly small square, and menu heights and text become too small to read and navigate. Obviously personal preference plays a role, and the ability to tweak the system can help, but neither of these is a reliable way to make sure Windows is usable on a new generation of hardware.
Windows 8 has been designed to provide developers with the easiest way for to reliably build software that works on the widest variety of hardware, and top provide consumers with the most consistently rich experience using that software. It is important not to look at this in isolation as "no more resizable windows," but rather as part of a larger effort to provide a wider choice of screen sizes, resolutions, and densities, where developers can know their apps will work and consumers can be sure that their apps are compatible with their hardware. We do this so you don't have to compromise by using software that isn't fully functional or only getting to choose among a small set of screen sizes (and price points, power consumption, etc.)

Building apps for higher pixel densities

Windows 8 also makes it simple to develop apps that work across different pixel densities. First of all, no manual work needs to be done in order for the app to scale. Unlike previous releases, you won’t need to do any work to make your apps DPI-aware; there are frameworks in place to scale the app for you. Just by using web-standard CSS pixel units or a XAML layout, app layouts will scale proportionally. When an app is scaled up, images are stretched and could get blurry, but Windows 8 makes it easy for developers to keep these images looking crisp and beautiful.

    Windows 8, the platform natively supports vector graphics. Any images exported as SVG (Scalable Vector Graphics) or XAML art will scale without getting blurry. Additionally, Windows 8 introduces automatic resource loading so developers can save three versions of images with a naming convention; images that correspond to each of the current scale percentages (100%, 140%, and 180%) load automatically to keep images crisp on high DPI. Developers can also use the CSS3 resolution media query or the system events to reload images at different scales. Windows 8 scaling to pixel density allows developers to achieve a baseline level of quality with little effort, and then tailor their images to look polished and crisp on high pixel density screens.

Testing apps on different screens

Even though Windows makes it easy to build beautiful apps that work well on different screens, it is still important to test apps on those different screen sizes. We realize that most people don’t have a plethora of devices at their immediate disposal, so we built support for testing apps on different screens into the tools. Visual Studio 11 offers the Windows Simulator, which allows developers to run their apps on a variety of screen sizes, orientations, and pixel densities. Switching to a different screen size is just as easy as choosing an option from a menu.

The Windows Simulator lets you test for different screens

Microsoft Expression Blend 5 offers a platform menu that allows you to design your apps on different screen sizes and pixel densities as you go. The Blend canvas can update dynamically depending on the display dimensions you choose on the platform menu.

Microsoft Expression Blend 5 includes options to design for different screens

Recap

A lot of planning, thinking and development are involved in making sure that Windows 8 scales across different screens and form-factors. For users, Windows 8 offers an experience that is predictable and consistent across devices. On larger screens, they can see more content in each app. On higher pixel-density screens, they get a crisp, premium experience that is easy to read and easy to interact with via touch or keyboard and mouse. For developers, Windows 8 makes it easy to support different screen sizes and pixel densities through standards-based and well known layout techniques, and by automatically scaling to pixel density. All while allowing developers to tailor their experiences to be great on each form factor.
We look forward to you trying Windows 8 on different screens!
Thanks,
David

Learn More :

Share this

Share on FacebookPlus on Google+