- Joined
- Jun 27, 2006
- Location
- Chicago, IL
With the Universal Windows Platform in Windows 10, your apps will now run on a number of device families and automatically scale across the different screen and window sizes, supported by the platform controls. In the next three weeks of the Windows 10 by 10 development series, we’re going to cover how these device families support user interaction with your app, how your app can respond and adapt to the device its being used on, and what we’re providing in the platform so you don’t have to write complex code.
Today’s post dives into the responsive techniques you can use to optimize your user interface for different device families. Next week we’ll cover different types of natural input your app can support, and we’ll go deeper on how your app can adapt to specific device capabilities after that.
Device families, you say?
Before we go into controls, APIs and code, I’d like to take a moment to explain the device families we’re talking about. For the full description, check out the Guide to Universal Windows Platform (UWP) apps on MSDN, but simply put: a device family is a group of devices in a specific form factor, as shown above. When designing your app, it’s important to consider the device families it could be used on.
As we bring Windows 10 to new types of devices, it’s a good idea to revisit your app and think about the new experiences it can enable. While we’re not covering all of the possible device families here, you can extend these ideas and concepts when determining how your app should respond when used on additional device families.
Welcome back, windows
One of the biggest changes in how apps are used in Windows, is something you’re already very familiar with: running apps in a window. While Windows 8 and Windows 8.1 allowed you to run apps full screen or up to 4 apps side by side, Windows 10 allows users to arrange, resize and position apps in any way they want. This gives users the flexibility to use your app the way they want, but may also require some work on your end to support them in doing so. The improvements in XAML on Windows 10 introduce a number of ways to implement responsive techniques in your app, so it looks great no matter the screen or window size. Three are discussed below.
1. VisualStateManager
The VisualStateManager class in Windows 10 has been expanded with two mechanisms to implement a responsive design in your XAML-based apps. The new VisualState.StateTriggers and VisualState.Setters APIs allow you to define visual states that correspond to certain conditions. Using the built-in AdaptiveTrigger as the VisualState’s StateTrigger with a MinWindowHeight and/or MinWindowWidth property, visual states can change based on app window height/width. You can also extend Windows.UI.Xaml.StateTriggerBase to create your own triggers, for instance triggering on device family or input type. Take a look at the following example:
<Page>
<Grid Background="{ThemeResource ApplicationPageBackgroundThemeBrush}">
<VisualStateManager.VisualStateGroups>
<VisualStateGroup>
<VisualState>
<VisualState.StateTriggers>
<!-- VisualState to be triggered when window
width is >=720 effective pixels. -->
<AdaptiveTrigger MinWindowWidth="720" />
</VisualState.StateTriggers>
<VisualState.Setters>
<Setter Target="myPanel.Orientation"
Value="Horizontal" />
</VisualState.Setters>
</VisualState>
</VisualStateGroup>
</VisualStateManager.VisualStateGroups>
<StackPanel x:Name="myPanel" Orientation="Vertical">
<TextBlock Text="This is a block of text. It is text block 1. "
Style="{ThemeResource BodyTextBlockStyle}"/>
<TextBlock Text="This is a block of text. It is text block 2. "
Style="{ThemeResource BodyTextBlockStyle}"/>
<TextBlock Text="This is a block of text. It is text block 3. "
Style="{ThemeResource BodyTextBlockStyle}"/>
</StackPanel>
</Grid>
</Page>
In this example, the page displays three TextBlock elements stacked on top of each other in its default state. Due to the VisualStateManager, which has an AdaptiveTrigger defined at a MinWindowWidth of 720, the orientation of the StackPanel will change to Horizontal when the window is at least 720 effective pixels wide. This allows you to easily make use of the extra horizontal screen real estate you get, when users resize the window or go from portrait to landscape on a phone/tablet device, for example. Keep in mind that defining both the width and height property will only fire your trigger if the app meets both conditions simultaneously. Feel free to explore the State triggers sample on GitHub to view more scenarios using triggers, including a number of custom triggers.
2. RelativePanel
In the above example, a StateTrigger is used to change the Orientation property of a StackPanel. While the many container elements in XAML allow you to use StateTriggers to manipulate your user interface in a large number of ways, they don’t offer a way to easily create complex responsive UI where elements are laid out relative to each other. That’s where the new RelativePanel comes in. You can use a RelativePanel to lay out your elements by expressing spatial relationships between elements. Here’s an example:
<RelativePanel BorderBrush="Gray" BorderThickness="10">
<Rectangle x:Name="RedRect" Fill="Red" MinHeight="100" MinWidth="100"/>
<Rectangle x:Name="BlueRect" Fill="Blue" MinHeight="100" MinWidth="100"
RelativePanel.RightOf="RedRect" />
<!-- Width is not set on the green and yellow rectangles.
It's determined by the RelativePanel properties. -->
<Rectangle x:Name="GreenRect" Fill="Green"
MinHeight="100" Margin="0,5,0,0"
RelativePanel.Below="RedRect"
RelativePanel.AlignLeftWith="RedRect"
RelativePanel.AlignRightWith="BlueRect"/>
<Rectangle Fill="Yellow" MinHeight="100"
RelativePanel.Below="GreenRect"
RelativePanel.AlignLeftWith="BlueRect"
RelativePanel.AlignRightWithPanel="True"/>
</RelativePanel>
The above XAML would render as follows:
As you can see, the blue, green and yellow are rendered in relation to the other rectangles by using the RelativePanel attached properties. This means that you can easily use the RelativePanel together with AdaptiveTriggers to create a responsive user interface where you move elements based on available screen space. Remember, the syntax you use with attached properties involves extra parentheses:
<VisualStateManager.VisualStateGroups>
<VisualStateGroup>
<VisualState>
<VisualState.StateTriggers>
<AdaptiveTrigger MinWindowWidth="720" />
</VisualState.StateTriggers>
<VisualState.Setters>
<Setter Target="GreenRect.(RelativePanel.RightOf)"
Value="BlueRect" />
</VisualState.Setters>
</VisualState>
...
Additional scenarios using RelativePanel can be explored in the Responsiveness techniques sample on GitHub.
3. SplitView
Aside from the content of your app’s pages, its navigation elements may need to respond to changes in the app’s window size. The new SplitView control introduced in Windows 10 is typically used to create a top-level navigation experience that can be adjusted to behave differently according to the app’s window size. Keep in mind that this is one of the common use cases for the SplitView, but it’s not strictly limited to this use. The SplitView is divided into two distinct areas: Pane and Content.
A number of properties on the control can be used to manipulate its rendering:
The DisplayMode (Overlay, Inline, CompactOverlay, CompactInlinespecifies how the Pane is rendered in relation to the Content area. The following example illustrates how each DisplayMode affects the rendering in the app:
The PanePlacement property displays the Pane on either the Left (default) or Right side of the Content area. The OpenPaneLength property specifies the width of the Pane when it’s fully expanded (default 320 effective pixels).
The SplitView control does not include a built-in user interface element for users to toggle the state of the Pane, like the common “hamburger” menu you often find in apps. You must define this user interface element in your app and provide code to toggle the IsPaneOpen property of the SplitView to get the desired behavior.
Be sure to check out the XAML navigation menu sample on GitHub to explore the full set of features the SplitView offers.
Press back to go… back
If you have previously developed for Windows Phone, you’ve become accustomed to every device having either a hardware or software back button available for users to navigate their way back through your app. Building apps for Windows 8 and 8.1, however, had you creating your own UI for back-navigation. To make things easier when targeting multiple device families in your Windows 10 app, we’ve provided a way to ensure a consistent back-navigation mechanism for all users. This lets you clear up some user interface space you may have previously dedicated in your app.
Using the SystemNavigationManager’s AppViewBackButtonVisibility property, you can opt in to showing a system back button on device families that don’t have a hardware or software back button, such as PCs. To display the back button, simply get the SystemNavigationManager for the current view and set the back button visibility:
SystemNavigationManager.GetForCurrentView().AppViewBackButtonVisibility = AppViewBackButtonVisibility.Visible;
The SystemNavigationManager also exposes a BackRequested event, which fires when the user invokes the system-provided button, gesture, or voice command for back navigation. This means you can handle this single event to consistently handle back navigation in your app across all device families.
Is it a tablet? Is it a PC?
Last, but not least, I’d like to mention one of my personal favorites: Continuum on Windows 10. With Continuum, Windows 10 adjusts your experience for what you want to do and how you want to do it. If your users have one of the 2-in-1 Windows PCs out there, implementing Continuum in your app empowers them to use touch or a mouse and keyboard to optimize productivity. Using the UIViewSettings’ UserInteractionMode property, you can determine whether the user is interacting with the view using touch or a mouse and keyboard:
UIViewSettings.GetForCurrentView().UserInteractionMode;
// returns UserInteractionMode.Mouse or UserInteractionMode.Touch
After detecting the mode of interaction, you can do various things to optimize the user interface of your app, like increase/decrease margins, show/hide complex features, etc. Check out this great article on TechNet by Lee McPherson that shows how you can combine the new StateTriggers and the UserInteractionMode to build your own custom Continuum StateTrigger.
This week: make your app respond to users across device families
We hope this review of responsive techniques that Windows 10 offers has given you some inspiration to think about how your app can use these new features to delight users on any device they’re using to engage with your app. Here are some final tips on what you can do to make your app responsive:
After that, visit the “Adaptive and Responsive UI” DVLUP challenge to get rewarded with points and XP for your hard work. To check out more of the Windows 10 by 10 development series, head on over to the initial blog post that holds the full schedule of content.
As always, here are some additional resources you can use to learn more on the topic of building responsive Windows 10 apps and let us know how you plan on using this new functionality via @WindowsDev and #Win10x10.
Continue reading...
Today’s post dives into the responsive techniques you can use to optimize your user interface for different device families. Next week we’ll cover different types of natural input your app can support, and we’ll go deeper on how your app can adapt to specific device capabilities after that.
Device families, you say?
Before we go into controls, APIs and code, I’d like to take a moment to explain the device families we’re talking about. For the full description, check out the Guide to Universal Windows Platform (UWP) apps on MSDN, but simply put: a device family is a group of devices in a specific form factor, as shown above. When designing your app, it’s important to consider the device families it could be used on.
As we bring Windows 10 to new types of devices, it’s a good idea to revisit your app and think about the new experiences it can enable. While we’re not covering all of the possible device families here, you can extend these ideas and concepts when determining how your app should respond when used on additional device families.
Welcome back, windows
One of the biggest changes in how apps are used in Windows, is something you’re already very familiar with: running apps in a window. While Windows 8 and Windows 8.1 allowed you to run apps full screen or up to 4 apps side by side, Windows 10 allows users to arrange, resize and position apps in any way they want. This gives users the flexibility to use your app the way they want, but may also require some work on your end to support them in doing so. The improvements in XAML on Windows 10 introduce a number of ways to implement responsive techniques in your app, so it looks great no matter the screen or window size. Three are discussed below.
1. VisualStateManager
The VisualStateManager class in Windows 10 has been expanded with two mechanisms to implement a responsive design in your XAML-based apps. The new VisualState.StateTriggers and VisualState.Setters APIs allow you to define visual states that correspond to certain conditions. Using the built-in AdaptiveTrigger as the VisualState’s StateTrigger with a MinWindowHeight and/or MinWindowWidth property, visual states can change based on app window height/width. You can also extend Windows.UI.Xaml.StateTriggerBase to create your own triggers, for instance triggering on device family or input type. Take a look at the following example:
<Page>
<Grid Background="{ThemeResource ApplicationPageBackgroundThemeBrush}">
<VisualStateManager.VisualStateGroups>
<VisualStateGroup>
<VisualState>
<VisualState.StateTriggers>
<!-- VisualState to be triggered when window
width is >=720 effective pixels. -->
<AdaptiveTrigger MinWindowWidth="720" />
</VisualState.StateTriggers>
<VisualState.Setters>
<Setter Target="myPanel.Orientation"
Value="Horizontal" />
</VisualState.Setters>
</VisualState>
</VisualStateGroup>
</VisualStateManager.VisualStateGroups>
<StackPanel x:Name="myPanel" Orientation="Vertical">
<TextBlock Text="This is a block of text. It is text block 1. "
Style="{ThemeResource BodyTextBlockStyle}"/>
<TextBlock Text="This is a block of text. It is text block 2. "
Style="{ThemeResource BodyTextBlockStyle}"/>
<TextBlock Text="This is a block of text. It is text block 3. "
Style="{ThemeResource BodyTextBlockStyle}"/>
</StackPanel>
</Grid>
</Page>
In this example, the page displays three TextBlock elements stacked on top of each other in its default state. Due to the VisualStateManager, which has an AdaptiveTrigger defined at a MinWindowWidth of 720, the orientation of the StackPanel will change to Horizontal when the window is at least 720 effective pixels wide. This allows you to easily make use of the extra horizontal screen real estate you get, when users resize the window or go from portrait to landscape on a phone/tablet device, for example. Keep in mind that defining both the width and height property will only fire your trigger if the app meets both conditions simultaneously. Feel free to explore the State triggers sample on GitHub to view more scenarios using triggers, including a number of custom triggers.
2. RelativePanel
In the above example, a StateTrigger is used to change the Orientation property of a StackPanel. While the many container elements in XAML allow you to use StateTriggers to manipulate your user interface in a large number of ways, they don’t offer a way to easily create complex responsive UI where elements are laid out relative to each other. That’s where the new RelativePanel comes in. You can use a RelativePanel to lay out your elements by expressing spatial relationships between elements. Here’s an example:
<RelativePanel BorderBrush="Gray" BorderThickness="10">
<Rectangle x:Name="RedRect" Fill="Red" MinHeight="100" MinWidth="100"/>
<Rectangle x:Name="BlueRect" Fill="Blue" MinHeight="100" MinWidth="100"
RelativePanel.RightOf="RedRect" />
<!-- Width is not set on the green and yellow rectangles.
It's determined by the RelativePanel properties. -->
<Rectangle x:Name="GreenRect" Fill="Green"
MinHeight="100" Margin="0,5,0,0"
RelativePanel.Below="RedRect"
RelativePanel.AlignLeftWith="RedRect"
RelativePanel.AlignRightWith="BlueRect"/>
<Rectangle Fill="Yellow" MinHeight="100"
RelativePanel.Below="GreenRect"
RelativePanel.AlignLeftWith="BlueRect"
RelativePanel.AlignRightWithPanel="True"/>
</RelativePanel>
The above XAML would render as follows:
As you can see, the blue, green and yellow are rendered in relation to the other rectangles by using the RelativePanel attached properties. This means that you can easily use the RelativePanel together with AdaptiveTriggers to create a responsive user interface where you move elements based on available screen space. Remember, the syntax you use with attached properties involves extra parentheses:
<VisualStateManager.VisualStateGroups>
<VisualStateGroup>
<VisualState>
<VisualState.StateTriggers>
<AdaptiveTrigger MinWindowWidth="720" />
</VisualState.StateTriggers>
<VisualState.Setters>
<Setter Target="GreenRect.(RelativePanel.RightOf)"
Value="BlueRect" />
</VisualState.Setters>
</VisualState>
...
Additional scenarios using RelativePanel can be explored in the Responsiveness techniques sample on GitHub.
3. SplitView
Aside from the content of your app’s pages, its navigation elements may need to respond to changes in the app’s window size. The new SplitView control introduced in Windows 10 is typically used to create a top-level navigation experience that can be adjusted to behave differently according to the app’s window size. Keep in mind that this is one of the common use cases for the SplitView, but it’s not strictly limited to this use. The SplitView is divided into two distinct areas: Pane and Content.
A number of properties on the control can be used to manipulate its rendering:
The DisplayMode (Overlay, Inline, CompactOverlay, CompactInlinespecifies how the Pane is rendered in relation to the Content area. The following example illustrates how each DisplayMode affects the rendering in the app:
The PanePlacement property displays the Pane on either the Left (default) or Right side of the Content area. The OpenPaneLength property specifies the width of the Pane when it’s fully expanded (default 320 effective pixels).
The SplitView control does not include a built-in user interface element for users to toggle the state of the Pane, like the common “hamburger” menu you often find in apps. You must define this user interface element in your app and provide code to toggle the IsPaneOpen property of the SplitView to get the desired behavior.
Be sure to check out the XAML navigation menu sample on GitHub to explore the full set of features the SplitView offers.
Press back to go… back
If you have previously developed for Windows Phone, you’ve become accustomed to every device having either a hardware or software back button available for users to navigate their way back through your app. Building apps for Windows 8 and 8.1, however, had you creating your own UI for back-navigation. To make things easier when targeting multiple device families in your Windows 10 app, we’ve provided a way to ensure a consistent back-navigation mechanism for all users. This lets you clear up some user interface space you may have previously dedicated in your app.
Using the SystemNavigationManager’s AppViewBackButtonVisibility property, you can opt in to showing a system back button on device families that don’t have a hardware or software back button, such as PCs. To display the back button, simply get the SystemNavigationManager for the current view and set the back button visibility:
SystemNavigationManager.GetForCurrentView().AppViewBackButtonVisibility = AppViewBackButtonVisibility.Visible;
The SystemNavigationManager also exposes a BackRequested event, which fires when the user invokes the system-provided button, gesture, or voice command for back navigation. This means you can handle this single event to consistently handle back navigation in your app across all device families.
Is it a tablet? Is it a PC?
Last, but not least, I’d like to mention one of my personal favorites: Continuum on Windows 10. With Continuum, Windows 10 adjusts your experience for what you want to do and how you want to do it. If your users have one of the 2-in-1 Windows PCs out there, implementing Continuum in your app empowers them to use touch or a mouse and keyboard to optimize productivity. Using the UIViewSettings’ UserInteractionMode property, you can determine whether the user is interacting with the view using touch or a mouse and keyboard:
UIViewSettings.GetForCurrentView().UserInteractionMode;
// returns UserInteractionMode.Mouse or UserInteractionMode.Touch
After detecting the mode of interaction, you can do various things to optimize the user interface of your app, like increase/decrease margins, show/hide complex features, etc. Check out this great article on TechNet by Lee McPherson that shows how you can combine the new StateTriggers and the UserInteractionMode to build your own custom Continuum StateTrigger.
This week: make your app respond to users across device families
We hope this review of responsive techniques that Windows 10 offers has given you some inspiration to think about how your app can use these new features to delight users on any device they’re using to engage with your app. Here are some final tips on what you can do to make your app responsive:
- Implement the AppViewBackButtonVisibility property and BackRequested event in your app to provide consistent back-navigation behavior across device families
- Think about how StateTriggers can help you respond to users resizing your app’s window and optimize their app experience
- Use the new SplitView and RelativePanel controls to provide a consistent user experience
After that, visit the “Adaptive and Responsive UI” DVLUP challenge to get rewarded with points and XP for your hard work. To check out more of the Windows 10 by 10 development series, head on over to the initial blog post that holds the full schedule of content.
As always, here are some additional resources you can use to learn more on the topic of building responsive Windows 10 apps and let us know how you plan on using this new functionality via @WindowsDev and #Win10x10.
- Build 2015: From the Small Screen to the Big Screen: Building Universal Windows App Experiences with XAML
- Developer’s Guide to Windows 10: Adaptive UI
Continue reading...
