Windows 10 Continuum Developer Experience
Developing for Continuum means building an adaptive Universal Windows Platform (UWP) app that runs on any screen size, powered by a phone.
There are a handful of considerations for developers as they think about Continuum. Some of these considerations are integral to your success on our platform, and some are more advanced and therefore optional. The following blog take you through the 4 key stages of developing an continuum supported app and looks at factors and constraints you should be aware of when building an experience which goes from a small phone to a large screen.
Required:
1. Adaptive Apps
2. App packaging
Optional:
3. Scaling Assets
4. Multi-screen experiences
1. Adaptive Apps
When a user is interacting with our feature, we generally expect that they should see “phone optimized” UI on the phone, and “big screen optimized UI” on the big screen.
If a user is interacting with a windows app targeting the universal device family, they will see the same UI they would see on a Windows desktop machine on the big screen.
If the user is interacting with a mobile only app, they will see mobile UI reflowed to fit the big screen.
Using Effective Pixel Sizes
You design a UWP app in effective pixels, not physical pixels this enable you to focus on the actual perceived size of a UI element without worrying about pixel density or viewing distance. A 1” x 1” element will appear to be 1” on all devices . This might correlate to 150x150 physical pixels on a phone, or 200x200 on a large screen, but you need only design once in effective pixels
Responsive design is key!
If you app is designed for a phone, it might look sparse on a large screen. A phone might have a camera or GPS. Navigation on bottom of screen is better for phones, while navigation at top is better for mouse.
When you optimize your app's UI for specific screen widths, we say that you're creating a responsive design. Here are six responsive design techniques you can use to customize your app's UI.
1. Resize
Given a windows size change, your app should resize to any screen.
You can optimize the frame size by adjusting the margins and size of UI elements. This could allow you, as the example here shows, to augment the reading experience on a larger screen by simply growing the content frame.
One way to help resize content is to use percentage-based layouts
In this view: three main UI elements
A photo takes up 100% of the screen width along the top
A personal feed takes up 1/3 of the screen width on the bottom left
An info card takes up 2/3 of the screen width on the bottom right
Also note that all text is right or left justified in each UI element. Text has well defined location
2. Reflow
Change the flow of UI elements based on device and orientation for optimal content display
Large screen – makes sense to switch to larger containers, add columns, and generate list items differently
Example – single column of vertically scrolling content on a phone can reflow on a larger screen to two columns
WrapGrid style controls can be used for text, images, and any other grid-like set of assets.
3. Reveal
You can reveal or hide content based on screen real estate, or when a device supports additional functionality (such as new input types), specific situations, or preferred screen orientations.
In this example with tab, the middle tab with the camera icon might be specific to the app on a phone, but not applicable on larger devices.
It is common for PCs to demonstrate more robust controls due to larger screen size and more powerful device capabilities
Phone – show minimal metadata
PC – show more metadata
In an email app, you can display the user's avatar.
In a music app, you can display more info about an album or artist.
In a video app, you can display more info about a film or a show, such as showing cast and crew details.
In any app, you can break apart columns and reveal more details.
In any app, you can take something that's vertically stacked and lay it out horizontally. When going from phone or phablet to larger devices, stacked list items can change to reveal rows of list items and columns of metadata.
4. Replace
This technique lets you switch the user interface for a specific device size-class or orientation.
In this example, the nav pane and its compact, transient UI works well for a smaller device, but on a larger device tabs might be a better choice.
5. Reposition
You can alter location and position of app UI for optimum use of screen space.
In this example, the portrait view on phone or phablet necessitates a scrolling UI because only one full frame is visible at a time.
When the app translates to a device that allows two full on-screen frames, whether in portrait or landscape orientation, frame B can occupy a dedicated space.
If you're using a grid for positioning, you can stick to the same grid when UI elements are repositioned.
6. ReArchitect
You can collapse or fork the architecture of your app to better target specific devices. In this example, going from the left device to the right device demonstrates the joining of pages.
You might also want to tear down and re-architect your apps entire navigation model and layout.
You may even have separate views for different device families or screen sizes. This is a very advanced scenario.
Here you can see that on large screens this UI has two distinct columns. Below a set screen width, the app collapses into a single column view.
You can collapse or fork the architecture of your app to better target specific devices. In this example, going from the left device to the right device demonstrates the joining of pages.
BreakPoints
The number of device targets and screen sizes across the Windows 10 ecosystem is too great to worry about optimizing your UI for each one.
Instead, we recommended designing for a few key widths (also called "breakpoints"): 320, 720, and 1024 epx.
Tip When designing for specific breakpoints, design for the amount of screen space available to your app (the app's window). When the app is running full-screen, the app window is the same size of the screen, but in other cases, it's smaller.
“phone optimized UI” when the screen width is < 800x600, and big screen UI >= 800x600
This is general guidance, and you should feel free to base UI decisions off of other triggers, such as input.
Design adaptive UI in XAML with adaptive panels and controls
StackPanel
StackPanel is a layout panel that arranges child elements into a single line that can be oriented horizontally or vertically.
1: <StackPanel Margin="20">
2: <Rectangle Fill="Red" Width="50" Height="50" Margin="5" />
3: <Rectangle Fill="Blue" Width="50" Height="50" Margin="5" />
4: <Rectangle Fill="Green" Width="50" Height="50" Margin="5" />
5: <Rectangle Fill=“Yellow" Width="50" Height="50" Margin="5" />
6: </StackPanel>
VariableSizedWrapGrid
VariableSizedWrapGrid is layout panel that supports arranging child elements in rows and columns. Each child element can span multiple rows and columns.
The VariableSizedWrapGrid class make it easy to wrap pictures and text in a grid according to window size.
1: <VariableSizedWrapGrid>
2: <Image Name="MyBigImage"
3: VariableSizedWrapGrid.ColumnSpan="2" VariableSizedWrapGrid.RowSpan="2"
4: ...
5: />
6: ...
7: </VariableSizedWrapGrid>
Relative Panel
Use the RelativePanel class to ensure that UI elements are correctly positioned relative to each other and the container across all screen sizes.
Using this class with percentage-based layouts and wrap grid controls will allow you to build an adaptive app that reflows automatically to any screen size
The RelativePanel class allows you to anchor UI elements relative to each other and the container such that they reflow to any screen size.
1: <RelativePanel BorderBrush="Gray" BorderThickness="10">
2: <Rectangle x:Name="RedRect" Fill="Red" MinHeight="100" MinWidth="100"/>
3: <Rectangle x:Name="BlueRect" Fill="Blue" MinHeight="100" MinWidth="100"
4: RelativePanel.RightOf="RedRect" />
5: <!-- Width is not set on the green and yellow rectangles.
6: It's determined by the RelativePanel properties. -->
7: <Rectangle x:Name="GreenRect" Fill="Green" MinHeight="100" Margin="0,5,0,0" RelativePanel.Below="RedRect"
8: RelativePanel.AlignLeftWith="RedRect" RelativePanel.AlignRightWith="BlueRect"/>
9: <Rectangle Fill="Yellow" MinHeight="100"
10: RelativePanel.Below="GreenRect"
11: RelativePanel.AlignLeftWith="BlueRect" RelativePanel.AlignRightWithPanel="True"/>
12: </RelativePanel>
SplitView
Here's a SplitView control with an open Pane appearing inline next to the Content.
The SplitView class can be used to create a top-level navigation experience, adjusted according to window size.
1: <SplitView IsPaneOpen="True"
2: DisplayMode="Inline"
3: OpenPaneLength="296">
4: <SplitView.Pane>
5: <TextBlock Text="Pane"
6: FontSize= "24"
7: VerticalAlignment="Center“
8: HorizontalAlignment="Center"/>
9: </SplitView.Pane>
10:
11: <Grid>
12: <TextBlock Text="Content"
13: FontSize="24"
14: VerticalAlignment="Center"
15: HorizontalAlignment="Center"/>
16: </Grid>
17: </SplitView>
VisualStateManger
The VisualStateManager allows you to adapt the visual state of your app in response to changes in Window size or some other state trigger.
StateTriggers define a threshold at which a visual state is activated, which then sets layout properties as appropriate for the window size that triggered the state change.
Let’s talk about how a few common state triggers might apply to Continuum. You can use adaptive triggers to resize, reveal, hide, or reposition UI at specific snap points.In this example, a developer wants to change the style of button they use above a set screen width. For large screens, with a width greater than 800 effective pixels, the developer will to show a “wide” button.Narrow button is triggered when the wide button trigger (>800) is no longer satisfied
Note, that snap points are not always related to screen width - you could use primary input method, device family, or some custom trigger
Sometimes you don’t want to use screen width as your main trigger.
UserInteractionMode
UserInteractionMode is another option,this API gives you context about the form factor of the display your app is running on.
It returns “mouse” when the device UI is optimized for mouse input, and “touch” when the device UI is optimized for touch input. These returns do not describe the current input method, but rather what input method the shell your app is running in is optimized for.
With Continuum, “touch” will always be returned when your app is on the mobile device, and “mouse” will always be returned when your app is on the connected display.
UserInteractionMode will only change when your app is moved between screens. UserInteractionMode does not send events – you’ll need to query this API upon receiving a SizeChanged event. Note that UserInteractionMode is also used to inform developers when a desktop device is in tablet mode – Continuum is not the only use case.
Here is an example of how you might use UserInteractionMode in C# to switch between a mobile view and a desktop view for Continuum.
point: navigating to specific page based on size rather than device family
DisplayInformation
The DisplayInformation class monitors and controls physical display information. This class provides events to allow clients to monitor changes in the display an app view is running on. You can use DisplayInformation to tailor experiences based on display properties. For example, if you want your app to adapt based on the physical screen size of the device (as an estimate for form factor), you can use the DiagonalSizeInInches property as a trigger.
There are two view states
The first is the “wideView”
Triggered when window wise is 720 pixels or more in width, using AdaptiveTriggers
Arranges best rated games panel to the right of, and aligned with the top of top free games, using relativepanel class
The 2nd view is the “NarrowView”
Triggered when window wide view trigger is not longer satisfied, using AdaptiveTriggers
Arranges best rated games panel below and aligned with the left of top paid games, using relativepanel class
2. App packaging
The best thing you can do is build a windows app and package it in a universal app package.
This means that your app will be packaged and deployed across all windows device families.If you are doing this, we assume that you have used the adaptive principles we discussed to ensure your app dynamically reflows to any screen size. You’re already doing everything you need to do to work on continuum.
A universal app package is a great aspiration, but we understand that a lot of developers are coming from a mobile-only background and intend to stay mobile-only.This is fine! If you build your mobile app with fluid, responsive, and/or tailored UI, you should get some basic reflow and adaption for free.That being said, you may not be happy with the basic reflow that you get for free.
Use adaptive techniques to make app look better
If you have a desktop view available from a separate desktop app, pull it in and trigger the use of it when appropriate. You can use adaptive triggers or UserInteractionMode for this, if you find yourself wanting to do a lot of optimizations for Continuum, we suggest considering converting to a universal windows app.
By building a universal windows app, all of your optimizations will be realized across all Windows platforms including desktop and Xbox. If your mobile app isn’t ready for Continuum right away, no worries. Simply add the following lines to your manifest to block your app on the connected display. Making this change will cause your app tile to be greyed out on the connected display’s Start menu until it is enabled.
Add namespace to package tag
Set “true/false” restriction value in your application
When your app is ready for Continuum, simply set RestrictToInternalScreen to “false” and submit an update!
If your mobile app isn’t ready for Continuum right away, no worries.
Simply add the following lines to your manifest to block your app on the connected display. Making this change will cause your app tile to be greyed out on the connected display’s Start menu until it is enabled.
-Add namespace to package tag
-Set “true/false” restriction value in your application
-When your app is ready for Continuum, simply set RestrictToInternalScreen to “false” and submit an update!
3. Scaling Assets
Reference resources with a URI, leaving out the "scale-xxx".
The platform does the rest for you.
"ms-appx:///Assets/Logo.png"
"ms-appx:///desktop.png"
An image tag in XAML could look like this:
4. Multi-screen experiences
CAST API - Cast media content to the connected display
ProjectionManager API - Create two fully-customizable views, one on each display
i hope this has provide a good introduction to the opportunity of developing Windows UWP apps which support Windows Continuum for Windows Phone.
For more details on window development see https://dev.windows.com
For more technical resources on continuum see https://msdn.microsoft.com/en-us/library/windows/hardware/dn917883(v=vs.85).aspx