Porting Windows Phone Silverlight to Windows Runtime 8 for form factor and UX

  • [アーティクル]

[This article is for Windows 8.x and Windows Phone 8.x developers writing Windows Runtime apps. If you’re developing for Windows 10, see the latest documentation]

Note  For info about porting to a Universal Windows Platform (UWP) app for Windows 10, see Porting for form factor and UX.

 

The previous topic was Porting business and data layers.

Windows apps share a common look-and-feel across PCs, tablets, and phones. The user interface, input, and interaction patterns are very similar, and a user moving between devices will welcome the familiar experience. But practical differences between devices such as physical size, default orientation, and effective pixel resolution factor into the design of a Universal Windows app.

Different form factors and user experience

PCs, tablets, and phones have multiple possible portrait and landscape resolutions, in a variety of aspect ratios. If you choose to build a Universal Windows app, how will the visual aspects of its interface, text, and assets scale? How can you support touch as well as mouse and keyboard input? And with an app that supports touch on different-sized devices with different viewing distances, how can a control both be a right-sized touch target at different pixel densities and have its content readable at different distances? The following sections address the things you need to know.

What is the size of a screen, really?

The short answer is that it's subjective, because it depends not only on the objective size of the display but also on how far away from it you are. The subjectivity means that we have to put ourselves in the shoes of the user, and that's something that developers of good apps do in any case.

Inches, and pixel count, are ways to measure a screen objectively. If you know both those metrics then you can calculate how many pixels fit into an inch. That's the pixel density, also known as DPI (dots per inch), also known as PPI (pixels per inch). And the reciprocal of the DPI is the physical size of the pixels as a fraction of an inch. Pixel density is also known as resolution, although that term is often used loosely to mean pixel count.

As viewing distance increases, all those objective metrics seem smaller, and they resolve into the screen's effective size, and its effective resolution. Your phone is usually held closest to your eye; your tablet then your PC monitor are next, and furthest away are Surface Hub devices and TVs. To compensate, devices tend to get objectively larger with viewing distance.

Touch resolution and viewing resolution

Affordances need to be the right size to touch. So a touch target needs to more-or-less retain its physical size across different devices that might have different pixel densities. Measurements set in XAML markup are not in units of physical pixels, but rather view pixels (see View pixels, and scaling to pixel density). View pixels are scaled on different devices—taking pixel density into account—in order to achieve a more-or-less constant physical size that's ideal for touch targets.

Text needs to be the right size to read (12 point text at a 20 inch viewing distance is a good rule of thumb), and an image needs to be the right size and effective resolution, for the viewing distance. On PCs, tablets, and phones, that same view pixel scaling keeps UI elements right-sized and readable. Text and other vector-based graphics scale automatically, and very well. Raster (bitmap)-based graphics are also scaled automatically if the developer provides an asset in a single, large size. But it's preferable for the developer to provide each asset in a range of sizes so that the appropriate one for a target device's scaling factor can be automatically loaded. For more info on that, see Guidelines for scaling to pixel density.

Remember that the focus of view pixels is to maintain physical size rather than effective resolution. In practice, though, viewing distance doesn't vary dramatically between PCs, tablets, and phones, and the scaling plateaus work to preserve effective resolution rather nicely. Should you wish to support devices at far greater viewing distances, where effective resolution can vary noticeably, you can add logic to your app to detect when it's running on such a device and use viewing distance to pre-scale your UI.

Layout

We've said that a meaningful understanding of screen size involves factoring in objective size, effective size, touch-target size and readability size. Let's think about the layout of your app, and how to make use of extra screen real-estate when it's available. Consider this page from a very simple app that was designed to run on a phone. What should this page look like on a larger screen?

The phone version is constrained to portrait-only orientation because that's the best aspect ratio for the book list; and we'd do the same for a page of text, which is best kept to a single column on phones. But PC and tablet screens are large in either orientation, so the phone's constraint seems like an unnecessary limitation.

Optically zooming the app to look like the phone version, just bigger, doesn't take advantage of the device and its additional space, and that doesn't serve the user well. We should be thinking of showing more content, rather than the same content bigger. Even on a phablet, we could show some more rows of content. We could use extra space to display different content, such as ads, or we could change the list box into a list view and have it wrap items into multiple columns, when it can, to use the space that way. See Guidelines for list and grid view controls.

In addition to new controls such as list view and grid view, most of the established layout types from Windows Phone Silverlight have equivalents in the Windows Runtime. For example, Canvas, Grid, and StackPanel. Porting much of the UI that uses these types should be straightforward, but always look for ways to leverage the dynamic layout capabilities of these layout panels to automatically resize and re-lay out on devices of different sizes.

Input modalities

A Windows Phone Silverlight interface is touch-specific. And your ported app's interface should of course also support touch, but you can choose to support other input modalities in addition, such as mouse and keyboard. In the Windows Runtime, mouse, pen, and touch input are unified as pointer input. For more info, see Quickstart: Pointers, and Responding to keyboard interactions.

Maximizing markup and code re-use

Refer back to the maximizing markup and code reuse list for techniques on sharing your UI to target PCs, tablets, and phones.

More info and design guidelines

Windows Phone Silverlight to Windows Runtime namespace and class mappings