UX Features in Windows 8 WinRT

Windows 8 has two faces: the traditional desktop, which works similarly to Windows 7 and earlier Windows versions, and Windows Runtime (WinRT, aka Metro). WinRT is a subsystem of Windows 8 that Microsoft designed specifically with touch and mobility in mind. WinRT incorporates a greatly unified, condensed, and streamlined user experience (UX) compared to that in previous Windows versions. In this article, I will discuss some key parts of the WinRT UX—the Charms bar, Live Tiles, and Near Field Communication (NFC)—with an eye toward helping developers coming from a .NET background understand and appreciate these new UX features.

The Charms Bar

Central to the WinRT subsystem is the Charms bar, always found at the right side of the screen, as shown in Figure 1. Users can activate charms by swiping a finger from outside the right side of the screen toward the screen's center. You can also access charms by dragging the mouse into either the top right or bottom right corner of the screen.

Figure 1: Charms Bar Displayed on the Right After Being Activated

When the Charms bar is activated, the user can see the current time as well as five selectable options: Search, Share, Start, Devices, and Settings. Start lets you view the Start screen and offers no added functionality to individual apps. The other four charms let you perform interoperability actions, such as searching installed apps, files, folders, and other items or sharing certain types of data between applications. (See the companion article to this piece, "WinRT vs. .NET Application Development," for more information.)

You can access charms and any of their related options from within any WinRT app at any time. For example, if a user is reading a news article and suddenly wants to make some notes about the article, the user can simply activate Charms, select Share, and then select the note-taking app to use. A few days later, when the user wants to find the notes, she activates Charms, selects search, selects her note-taking app, and then types a search query. As you can see from this example, WinRT gives users the tools to access their data in flexible, efficient ways.

Search charm. Users may access Search at any time and from any place in the OS or in an application. If the current app in use supports Search, that app is by default selected as the search target. Any query typed will immediately run within the current app; Figure 2 shows an example query performed from within the Windows Store app. The user may at any time select a different app to search without having to retype the query.

Figure 2: Searching Within the Windows Store App

Although an app may handle search in its own unique way, there are some general guidelines that can help developers ensure that their apps provide a consistent UX. First, make sure the search suggestions and early search results that the app provides while the user is typing in a query are highly relevant (only five search suggestions can be displayed). Note that if the user selects a search suggestion, it is submitted as the query text. Your app should also take the user directly to the app search results page after the user submits the query. No filtering, scoping, or sorting should be triggered by the search query; thus the app should provide the relevant filters, scopes, and sorting options.

It is also highly recommended that results on the page highlight text matching the search query. Selecting a search result should take the user to the page corresponding to the user's selection. By the same token, selecting an early search result in the search pane should direct the user to the page for that result. I recommend that you consult Microsoft's complete search guidelines for Windows Store apps for more in-depth information on this topic.

Share charm. There are two important aspects of sharing. The first aspect is the share source. This is any app that handles the share-requested event, when it is the current app and the user selects the Share charm. The second aspect of sharing is the share target. This is any app that has declared itself as supporting certain types of data being passed to it. Any app may be a share source, a share target, or both. Most apps that consume or create data should support the necessary APIs to be a share source (e.g., an app that shares a photo or data on Facebook). Enabling an app to function as a share source takes very little effort and can make an app more valuable for users. Apps such as newsreaders, photo managers, and note-taking apps should be share sources as they have useful data that end users may want to send to others or save in other apps—for example, sharing data between the WinRT Weather app and the OneNote app, as shown in Figure 3.

Figure 3: Sharing from the WinRT Weather App to the OneNote App

You should be selective about which apps you designate as share targets. Share target apps must set a certain declaration stating that they support data being shared with them. The declaration must include the specific types of data the app supports. For example, a social photo app may support only image data, a note-taking app may support photos or text, and an emailing app may support all those types plus other types of content such as documents. Share target apps must display a snapped page on the right of the screen once the user has chosen to share to it. The page displays the data being shared and how it will be shared to the app. A note-taking app may display the title of a new page plus the data as content for the new page. Then, before the share is completed, the user must accept the share—otherwise the share must be cancelled.

Devices charm. The Devices charm is an interesting and diverse charm. As its name suggests, this charm enables interaction with devices that are attached to the computer—for example, to send selected content to a printer for printing, as shown in Figure 4. When viewing a document, photo, or other printable content, the user would select the Devices charm; doing so displays a list of devices that the app can send content to. Once a device (such as a printer) is selected, the user clicks or touches the Print button to display printing options. In addition to printing, the Devices charm lets the user manage multiple monitors without having to enter the desktop Screen Resolution application. Note, however, that under the current version of WinRT, the Devices charm's functionality is still fairly limited.

Figure 4: Printing from the Devices Charm Within the Reader App

Settings charm. One of the main purposes of the Settings charm is to unify and simplify UX across all WinRT apps. In traditional desktop applications, users can specify settings in any location throughout an app. Developers should make sure that settings for all their WinRT apps are added to the Settings charm. By doing so, you'll ensure that the user always knows where settings live. Settings can be system-wide, application-wide, or page specific. A value such as the number of items to show before paging data is an excellent example of data that could live in Settings for a specific page.

The settings pane consists of multiple levels. When the user selects the Settings charm, an initial pane of setting groups is displayed. The user selects the desired group, and at that point the app must provide on the screen's right side a custom settings pane in place of the default settings pane, as shown in Figure 5. This settings pane should be animated and limited to certain width restrictions. The pane should list all the options that the user can change. When the user is done, he can touch or click anywhere outside the settings pane to close it; alternatively, the user may choose to go back to see other settings groups. The custom settings pane must therefore have a back button.

Figure 5: Accessing Settings for the Weather App

As you can see, the Charms bar incorporates powerful functionality. When apps are developed to leverage this functionality, users can accomplish a great deal through the Charms bar.

Live Tiles and Background Tasks

One of the major differences between WinRT apps and applications on any other platform is Live Tiles. Although the Live Tiles feature doesn't make sense for every app, it should be leveraged in your apps as much as possible. Live Tiles allow apps to give information to the user from the Windows 8 Start screen. There are multiple different ways to display data on a live tile. The tiles can include pictures, text, and counts. Figure 6 shows a sample live tile transitioning from displaying an image to displaying text. Microsoft has provided a full list of tile configurations in its tile template catalog.

Figure 6: Bing Live Tile in Three Stages (Picture, Transition, Text)

There are two ways Live Tiles can be used. The first is as the main app tile. This is the most common live tile. Main Live Tiles should display data that is available throughout an application. For example, the main live tile of an email app could display the count of unread emails and some text from the most recent email. The second way to use Live Tiles is as a secondary or deep-link tile. Each app may have any number of secondary tiles. When the app is ready to create a secondary tile, the user is prompted before the tile is added to the user's Start screen. A secondary tile should include only information specific to the level at which it links. In the email app example, a secondary live tile should link to a specific folder and display the number of unread emails in that folder.

Live Tiles are of limited use without a mechanism to update them. The tiles may be updated while the app is running or in a background task. Background tasks run periodically and can update any pinned live tile. These tasks are limited to how long they can run and what they may do. If the task must contact a web service for data, it is recommended that the web service have an optimized API for live tile data retrieval.

Near Field Communication

NFC is a new and growing technology in the mobile space. NFC actually encompasses a number of technologies. NFC leverages radio-frequency identification (RFID), Bluetooth, or a connected Wi-Fi network to communicate with other devices that are nearby. Often NFC is marketed as a way to tap devices in order to share content. Although this is true, not all NFC interaction requires tapping. Apps can either transmit a small amount of data over RFID, or they can use RFID to establish a Bluetooth connection to share a large amount of data. Apps can also use broadcasting APIs to connect via Bluetooth or Wi-Fi without requiring the use of tapping or RFID.

Each of these options should be evaluated on an app-by-app basis. In cases where you want to share a single file, RFID provides an excellent way to ensure that the file makes it to the right device. However, for games, it probably makes more sense to broadcast a request for a challenger, as it may not matter who the challenger is. If it does matter, then the game could also support the use of RFID.

Keep Your Apps Focused

The new WinRT subsystem is chock-full of features and rich APIs that allow each app to function optimally. A single WinRT app need not support every feature available—in fact, doing so would contradict one of Microsoft's design principles. Each app should have a very specific purpose and should fulfill that purpose to the utmost extent possible. It's better to have a suite of apps rather than "one app to rule them all." This allows for greater flexibility and a lower learning curve in each app. Keeping your apps focused in this way will help end users get optimum benefit from the new WinRT UX features.