Tablet mode

Article
03/18/2021

Overview

Tablet mode is a new, adaptive user experience offered in Windows 10 that optimizes the look and behavior of apps and the Windows shell for the physical form factor and customer's usage preferences. This document describes how to implement tablet mode on 2-in-1 devices and tablets, specifically how to switch in and out of "tablet mode."

Tablet mode is a feature that switches your device experience from tablet mode to desktop mode and back. The primary way for a user to enter and exit "tablet mode” is manually through the Action Center, by clicking the icon in the lower right on the taskbar. In addition, OEMs can report hardware transitions (for example, transformation of 2-in-1 device from clamshell to tablet and vice versa), enabling automatic switching between the two modes. However, a key promise of tablet mode is that the user remains in control of their experience at all times, so these hardware transitions are surfaced through a toast prompt that must be confirmed by the user. Users also have the option to set the default response.

Target Devices



Tablets	Detachables	Convertibles
Pure tablets and devices that can dock to external monitor + keyboard + mouse.	Tablet-like devices with custom designed detachable keyboards.	Laptop-like devices with keyboards that fold or swivel away.

When the device switches to tablet mode, the following occur:

Start resizes across the entire screen, providing an immersive experience.
The title bars of Microsoft Store apps auto-hide to remove unnecessary chrome and let content shine through.
Microsoft Store apps and Win32 apps can optimize their layout to be touch-first when in tablet mode.
The user can close apps, even Win32 apps, by swiping down from the top edge.
The user can snap up to two apps side-by-side, including Win32 apps, and easily resize them simultaneously with their finger.
Apps can auto-launch side-by-side to create multitasking layouts without much user effort.
The taskbar transforms into a navigation and status bar that’s more appropriate for tablets.
The touch keyboard can be auto-invoked.

Of course, even in “tablet mode”, users can enjoy Windows 10 features such as Snap Assist, Task View and Action Center. On touch-enabled devices, customers have access to touch-friendly invocations for those features: they can swipe in from the left edge to bring up Task View, or swipe in from the right edge to bring up Action Center.

Tablet mode gives customers the flexibility to use their device in a way that is most comfortable for them. For example, a customer might want to use their 8” tablet in “tablet mode” exclusively until they dock it to an external monitor, mouse, and keyboard. At that point the customer will exit “tablet mode” and use all their apps as traditional windows on the desktop—the same way they have in previous versions of Windows. Similarly, a user of a convertible 2-in-1 device might want enter and exit “tablet mode” as they use their device throughout the day (for example, commuting on a bus, sitting at a desk in their office), using signals from the hardware to suggest appropriate transition moments.

Designing your device for tablet mode

If you are designing a 2-in-1 device that is a convertible or detachable, we recommend you go through the following flow chart when designing your product. This will ensure you have the right implementation in place to allow the tablet mode prompt to show when the device’s state changes. Each of the boxes in the flow chart contain an implementation option.

tablet mode flowchart

Method 1 - Implement ACPI description for the GPIO-based indicators

If your system is a 2-in-1 device that uses physical GPIOs to indicate state transitions, you can describe the state transition indicator in ACPI and Windows will automatically forward the GPIO interrupts fired by that indicator up to the operating system.

For more information, review the following resources on MSDN.

Method 2 - Use the injection interface

If your system is a 2-in-1 device that does not use physical GPIOs to indicate state transitions, then you must develop either a user or kernel mode driver that injects the state transition indication into Microsoft’s “GPIO Laptop and Slate indicator driver”.

The injection interface to the “GPIO Laptop and Slate indicator driver” is defined as the following:

/* 317fc439-3f77-41c8-b09e-08ad63272aa3 */ DEFINE_GUID(GUID_GPIOBUTTONS_LAPTOPSLATE_INTERFACE, 0x317fc439, 0x3f77, 0x41c8, 0xb0, 0x9e, 0x08, 0xad, 0x63, 0x27, 0x2a, 0xa3);

Calling WriteFile against the interface allows you to toggle the state of the indicator. A code sample for how a driver would use the injection interface can be found on the MSDN page here: https://msdn.microsoft.com/library/windows/hardware/dn457889.aspx

If you are creating a driver that uses the injection interface, you will still need to declare the ACPI description for the laptop/slate mode indicator to ensure Microsoft’s “GPIO Laptop and Slate indicator driver” loads. However, you will not need to add a GPIO resource to the ACPI declaration for the “laptop and slate indicator”.

Note When the device boots, the “GPIO Laptop and Slate indicator driver” first initializes in “slate” mode. Thus, it’s important for your injection driver to check the operating system state to ensure that it is in sync with the system’s actual state immediately after the device boots.

Your SOC IHV partner may already offer a driver or other solution that injects the state transition into Microsoft’s inbox driver. If that’s the case, you can save time and effort by leveraging your IHV’s solution according to their particular guidelines.

Method 3 - Use unattend setting to declare the permanent device state

If your device is not a 2-in-1 device, for example a regular laptop or desktop, you can disable prompting using the ConvertibleSlateModePromptPreference setting in your answer file. Set the value to 0 and the prompt will not show up and the UI will not switch. If no value is specified, the default value is 1, where the system will be prompted to switch modes.

Note It is also recommended that you specify the type of form factor you are building using the DeviceForm setting in your answer file.

Test your device

Verify your device implements ConvertibleSlateMode

If you are unsure if your device correctly implements ConvertibleSlateMode, check if the “GPIO Laptop or Slate Indicator Driver” exists in the Device Manager.

gpio driver properties

Make sure to enable the “Show hidden devices” from the Device Manager to confirm the presence of this driver:

device manager view options

There are two main ways to enter/exit “tablet mode”:

Manually - The user can enter/exit “tablet mode” manually by pressing the “tablet mode” button located in Action Center.
Hardware action triggered - The OS can ask the user if they would like to enter/exit “tablet mode” if the hardware has indicated the form factor has changed through ConvertibleSlateMode.

Using the presence of a Bluetooth keyboard as a tablet mode trigger is not supported. The primary issue with using Bluetooth as a trigger is that the Bluetooth events correlate to device pairing and proximity and those events do not reliably signal whether the keyboard is in use (for example, it may not even be near the customer) and thus do not reliably signal customer intent to enter or exit “tablet mode”.

If you are interested in making sure that a device that ships with a Bluetooth-enabled keyboard provides hardware-based hinting for the customer to change modes, we recommend implementing a sensor that would understand the current form factor and then signal to the OS through ConvertibleSlateMode.

Because the Windows prompt to enter/exit “tablet mode” is dependent on the implementation of ConvertibleSlateMode, it is important to ensure the firmware that toggles ConvertibleSlateMode is tested thoroughly. ConvertibleSlateMode implementations of lower quality can lead to a poor end user experience, such as asking the user to “enter ‘tablet mode’” multiple times.

In addition, when a 2-in-1 device changes from clamshell to tablet, the keyboard and touchpad can receive accidental presses from the user holding the tablet. Windows does not support ignoring input from the built-in keyboard and touchpad when a convertible changes into a tablet. We expect that device manufacturers do work in their hardware or software to avoid unintentional input during the form factor change, and test it thoroughly. The following table shows a few of the common errors that can occur, along with use cases that could cause them. These use cases should be tested to prevent the user from having a poor switching experience:

Error	Use cases that can cause the error
ConvertibleSlateMode switches even though there is no customer-observable reason (for example, a false firing).	Mechanical/electrical issues Technical reasons causing the switch to occur (for example, having to power down a component early as the system goes to sleep, causing a spurious transition)
ConvertibleSlateMode thinks that the system is currently a slate form factor, when it’s actually a laptop form factor (or vice versa).	Changing the device’s form factor while the device is in a power state transition (for example, powering up/down, going to sleep, etc). Changing the system’s form factor very slowly Changing the system’s form factor very quickly
ConvertibleSlateMode switches multiple times in rapid succession, causing the OS to repeatedly prompt the user to enter/exit “tablet mode”.	Changing the system’s form factor very slowly Changing the system’s form factor very quickly

Unattend Settings

The following unattend settings are useful if you are designing for a tablet mode-capable device:

Unattend Setting	Description	Value
ConvertibleSlateMode	With the ConvertibleSlateMode setting, you specify the physical ability of the device, which impacts physical behaviors of the device (such as rotation and onscreen keyboard), and you help define the appropriate first use experience that will be presented to an end user. If you specify laptop mode, an end user can type on a physical keyboard. If you specify tablet mode, an end user cannot type on a physical keyboard, because the keyboard is removed or the keyboard is flipped back so that it is inaccessible.	0 – Tablet, convertible, or detachable (default) 1 – Laptop
ConvertibleSlateModePromptPreference	With the ConvertibleSlateModePromptPreference setting, you can specify whether to prompt the user to enter or exit tablet mode. The device form factor or product design will influence whether you choose to show the prompt. If you choose to hide the prompt, the mode is not switched. (That is, if tablet mode is on, it stays on, and if tablet mode is off, it stays off.) If you want the prompt to appear when the hardware event occurs, you need to implement a hardware or software solution to toggle this setting.	0 – Disabled; the prompt does not appear, and the UI does not switch modes 1 – Enabled (default); the prompt appears, and the UI switches modes if the user consents
SignInMode	You use the SignInMode setting to specify whether to set the display to tablet mode or to desktop mode after a user logs on. If you do not explicitly set this value, the default is tablet if the screen size is less than 10 inches and your preferred power management profile (power platform role) is slate (that is, a tablet form factor). Otherwise, the default is the last setting used. If there is no previous setting, the last setting used is considered to be desktop.	0 – Tablet (default if the screen size is less than 10 inches and the power platform role is slate) 1 – Desktop 2 – Last setting used (default if the tablet default requirements are not met); if there is no actual last setting, desktop is considered the last setting
DeviceForm	You specify the DeviceForm setting so that a variety of apps (for example, Bing and Cortana) can determine the correct content for the specified device form factor. You also use this setting for features such as retail demo mode to specify the most suitable demo content for the device type.	There are 30 possible values. The primary values are listed below: 0 – Unknown (default) 2 – Tablet 4 – Laptop 5 – Convertible 6 – Detachable

Behavior of "tablet mode"

To achieve a great tablet experience in Windows, the following desktop aspects of the taskbar are optimized for tablet mode:

Showing running apps - this suggests to people that they need to manage their running apps' life cycle.
Several entry points to the Desktop - a tablet user does not need easy access to the desktop in "tablet mode."
A dense layout in the taskbar - this can fit more items but in "tablet mode," touch is likely the primary input, and requires a less dense layout.
Showing Deskbands and Win32 notification icons at the top level and the overflow level - the majority of these are not intentionally placed there by the user and are not commonly used.

Rotation lock

Rotation lock is set to enabled (or locked) by default. Unless OEMs set the rotation lock to unlocked, customers unboxing new tablets might be frustrated by OOBE not rotating to landscape or portrait according to how they hold their new devices. By disabling rotation lock, OEMs can make sure customers are delighted with the responsiveness of their new devices, even before they explore the ease of managing the rotation lock setting in the Quick Actions area of the Action Center.

To set rotation lock to disabled and enable rotation by default:

In Audit mode, set HKLM\Software\Microsoft\Windows\CurrentVersion\AutoRotation\Enable to 1, where 1 means rotation is enabled.
Use Sysprep to prepare the machine for the customer as you would normally.

Notification area icons

When entering tablet mode, the notification area will go through several changes. The following icons will be shown:

Battery
Network
Volume
Action Center

More specifically, if the user has demoted any of these four icons into the overflow, it will be brought back to the top level, or if the OEM has demoted the battery icon into the overflow, it will be brought back to the top level.

However, if the customer has disabled one of these in Settings under Turn system icons on or off (shown below), Windows will follow the customer's manual setting and not enable the icon.

Turn system icons on or off

OEM-pinned notification icons will be hidden, user-pinned notification icons will be hidden, and the overflow chevron will be hidden, effectively hiding the overflow window.

Auto-promotion of notification icons to the top level will be blocked, but apps should continue to be able to fire a toast notification, even if the icon cannot come to the top level. The one exception to this is the location services icon. When it is enabled under Turn system icons on or off, it will be able to promote itself to the top level, to the left of the battery icon. However, if the user has manually chosen to disable the location services icon using the Turn system icons on or off setting, Windows will not force the icon to promote.

If customers select the Always show all icons in the notification area setting, the above behavior will turn off, and the notification area will revert to the same contents and behavior as if tablet mode were not being used.

Touch keyboard button

When entering tablet mode, the Touch Keyboard button will be hidden. Its visibility can be controlled via the Show touch keyboard button setting in the tablet mode taskbar context menu.

App icons

By default, app icons will be hidden on the taskbar in Tablet Mode. This is controlled by the Hide app icons on the taskbar in tablet mode setting:

Tablet Mode system settings

Creating an app that interacts with tablet mode APIs

You can take advantage of tablet mode by using Universal Windows Platform (UWP) and Classic Windows APIs in your apps. Using these APIs, you can tailor the user experience of your app to be touch-first for tablet mode or mouse-first for desktop usage. This section describes how to use both the UWP and Classic Windows APIs in your applications to detect and react to tablet mode.

The APIs allows both Windows desktop applications and Universal Windows apps to query for the current interaction mode and respond to changes to the mode, as described here.

Classic Windows apps APIs


UIViewSettings	Allows apps to query the current pointer device preference state of the system for a particular application. It is a non-activatable class that you get from GetForCurrentView.
UserInteractionMode	Property of GetForWindow that takes a value in the Windows.UI.ViewManagement.UserInteractionMode enum, the allowed values of which are Touch and Mouse.
WM_SETTINGSCHANGE	Apps are notified when the current input state changes by broadcasting WM_SETTINGSCHANGE with “UserInteractionMode”.

Universal Windows apps APIs


UIViewSettings	Allows apps to query the current pointer device preference state of the system for a particular application. It is a non-activatable class that you get from GetForCurrentView.
UserInteractionMode	Property of UIViewSettings that takes a value in the Windows.UI.ViewManagement.UserInteractionMode enum, the allowed values of which are Touch and Mouse.
SizeChanged	Event is triggered when the current input state changes. Apps should query for this event.

Example 1: Optimize layout on app launch

When an app launches it can query for the current state of the system and optimize its layout for the current interaction mode, as in the following example.

Universal Windows App (C#) Sample

using Windows.UI.Xaml;
using Windows.UI.ViewManagement;
 
    public sealed partial class MainPage : Page
    {
        public MainPage()
        {
            InitializeComponent();
            // Every view gets an initial SizeChanged, so we will do all our 
            // work there. This means that our view also responds to dynamic
            // changes in user interaction mode.
            Window.Current.SizeChanged += SizeChanged;
        }
 
        private void SizeChanged(object sender, RoutedEventArgs e)
        {
            switch(UIViewSettings.GetForCurrentView().UserInteractionMode)
            {
                case UserInteractionMode.Mouse:
                    VisualStateManager.GoToState(this, "MouseLayout", true);
                    break;
 
                case UserInteractionMode.Touch:
                default:
                    VisualStateManager.GoToState(this, "TouchLayout", true);
                    break;
            }
        }
     }

Classic Windows App (C++) Sample

using namespace Microsoft::WRL::Wrappers;
using namespace Microsoft::WRL;
HRESULT OnLayout()
{
    ComPtr<IUIViewSettingsInterop> uiViewSettingsInterop;
    HRESULT hr = GetActivationFactory(
        HStringReference(RuntimeClass_Windows_UI_ViewManagement_UIViewSettings).Get(), 
        &uiViewSettingsInterop);
    if (SUCCEEDED(hr))
    {
        ComPtr<IUIViewSettings> uiViewSettings; 
        hr = uiViewSettingsInterop->GetForWindow(hwndApp, IID_PPV_ARGS(&uiViewSettings)); 
        if (SUCCEEDED(hr))
        {
            Windows::UI::ViewManagement::UserInteractionMode mode;
            hr = uiViewSettings->get_UserInteractionMode(&mode);
            if (SUCCEEDED(hr))
            {
                switch (mode)
                {
                case UserInteractionMode_Mouse:
                    hr = LayoutForMouse(); 
                    break;
 
                case UserInteractionMode_Touch:
                default:
                    hr = LayoutForTouch();
                    break;
                }
            }
        }
    }
    return hr;
}

Example 2: React to tablet mode entry/exit

When your device enters or exits tablet mode, the shell prompts the user to switch modes. You can use this as a trigger to optimize your app for the current interaction mode. You must query for the current state of the system, as in the following examples.