Windows 8.1 is a great platform for productivity apps. In addition to the traditional desktop environment, which enables existing productivity apps to work well, the new environment for Windows Store apps makes it possible to build new and modern types of productivity apps. Here we show you various ways that productivity apps get better when they take advantage of Microsoft design style and the capabilities of Windows 8.1.
Windows 8.1 provides unparalleled reach across a range of devices, from touch and pen-centered tablets to high-resolution laptop and desktop PCs. For productivity apps, this means a unique opportunity to use different inputs to enable users to be productive across a variety of scenarios and use cases.
The Windows Store also provides opportunities for you to distribute, promote, and sell your apps. Scenarios like in-app purchases and trials are supported with minimal coding, so you start making money quickly.
This topic highlights capabilities in Windows 8.1 that are of particular importance for productivity apps, including:
- Windows Store apps: a new design language for apps, emphasizing full-screen content creation and immersive productivity scenarios. Windows gets out of the way, allowing your content to be king.
- Live tiles: maximize engagement and keep users coming back to your app by creating live tiles that show recent content the user has been working on. Secondary tiles also make it easy to link deeply into content and let users pin frequently used content within your app.
- Share contract: Windows 8.1 facilitates app-to-app sharing and collaboration, so your app can work with other apps to help users do everything they need to do to be productive.
- Search contract: new top-level OS functionality helps users find and organize their content more easily than ever before. Your app is included in search results to raise users' awareness when they search for content.
- Search box: let people search your app's content within your app and provide a custom results view.
- File picker: The file picker makes it easy for users of your productivity app to use files, documents, and photos from the file system and also from other apps and services that participate in the file picker contracts.
- Semantic zoom: This native feature of Windows 8.1 enables users to pinch and zoom out of the detail of an app and see a bird's-eye view of their content and things they are working on. Try using it on the Start screen to see it in action.
- Resizable windows: Users can resize apps so that multiple apps can run simultaneously side by side. Users can truly multitask and stay productive with your app all the time.
One of the most obvious advantages of Windows Store apps for productivity is that they’re not competing for space with other applications or WindowsUI. An app gets to use every single visible pixel on the screen to present its content. All nonessential or distracting UI can be hidden and revealed with a simple gesture, meaning that the app always has ample space to display the most important information for the task at hand. The “content before chrome” design philosophy, which is so refreshing and enjoyable in a magazine or video app, also applies to productivity apps. When the distractions are removed, it’s easy to focus on working with the content that the app presents.
When designing a productivity app, first identify the user’s core task. Then use every pixel of the screen to make your app great at doing exactly that task. Think about how having more room can make that task easier, faster, or more enjoyable. Think about rich visualizations of interesting and actionable information rather than static representations of data. Think about how your app can use space and positioning to convey meaning. Many of the conventions and controls in use today were developed when desktop computer displays had lower resolution than current smart phones. Windows Store apps offer the chance to redefine how users interact, analyze, and manipulate information to get work done.
Productivity apps typically involve an interesting mix of content-creation and content-consumption scenarios. For example, productivity apps can be used for both creating and reading documents, or for both creating and managing to-do lists. Productivity apps also vary widely in complexity in the way they handle navigation and the exposure of commands and experiences—from simple, lightweight to-do apps to richly complex content-creation apps with tiered menus that host myriad options. A great Windows 8.1 productivity app enables navigation among these experiences in a fast, fluid, and delightful way.
The navigation pattern you choose will be informed by the types of scenarios your app supports. If you have multiple rich experiences in your app (presenting multiple documents, for example), with organization and structure between them, a hierarchical pattern can help bring all of your content to the top level instead of burying it behind menus or tabs. However, if your app doesn’t have a lot of information density or scenarios that need hierarchy and structure, consider a flat pattern that lets users swiftly navigate between the experiences in your app. Apps with "master/details" views (for example, email and messaging apps) might use a list view to best showcase their content. For some productivity apps, certain scenarios may require different types of data input, like forms, and these can make use of the form layout suggested later in this article. Pick the pattern that best helps your users quickly and confidently find the content they want.
For information about navigation patterns for your app, see Navigation patterns.
Productivity apps that have a hierarchical structure and a big data set, such as a notes app with a lot of notebooks and notes, can use a hierarchical pattern that showcases all of the user’s content at the top level. This model delights users by putting all of your content right in front of them.
Your hub page consists of various sections, each of which maps to the different sections in your app. Each section can expose content or functionality. The hub should offer a lot of visual variety to engage users and draw them to different parts of the app. For example, the notes app below shows some of the most recent notes for each notebook right at the top level. The following image shows an example hub page.
Tapping each of the notes takes the user directly into that note. Tapping the header ("Travel - NYC", for example) shows the section page for that notebook, if there’s more content associated with the notebook than is showing on the home page.
Consider letting users choose how to sort their content. For example, they can choose to sort it alphabetically, by date, by content type, or by whether it is shared. The right ways to sort depend on the content your app presents and on your users' typical usage pattern. The following image shows an example of sorting notes.
You can use the top app bar to enable users to quickly jump laterally between sections of your app. For example, a user who is reading a note in one notebook can move quickly and easily to a note in a different notebook by using the top app bar. The following image shows a top app bar that is exposed in a notes app when the user swipes from the top or bottom edge.
Semantic zoom enables users to quickly navigate within a single view by visually showing a "zoomed in" or "zoomed out" view of the content. For example, in a notes app, users can quickly pinch and pan to get from one notebook to another. Alternatively, if users choose to display their notes by date, they can quickly get from the most recent notes to the oldest ones.
This image shows content grouping when zoomed out.
You can also use semantic zoom in a specific section page to navigate content in that section or category. For example, in the notes app, users can use semantic zoom to quickly jump among different notes in the same notebook.
For more info about semantic zoom, see Guidelines for semantic zoom.
If your app has most of its content at the same level without a lot of hierarchy, consider using flat navigation. This pattern enables users to move between documents, pages, tabs, or modes that all reside at the same hierarchical level in a fast and fluid way. You can learn more about the flat pattern by reading Navigation design for Windows Store apps.
Also, if your app has scenarios that benefit from a multiple-document interface, the flat pattern is a good one to use. The top app bar is great for switching among multiple contexts. For example, in a spreadsheet-creation app, the flat pattern can provide fast switching between the different spreadsheets that a user is working with.
Some apps may choose to include other functionality within the top app bar, such as adding a plus ("+") button to create a new spreadsheet right in the top app bar. An example of this is seen in the browser (a Windows Store app) shown here.
If your productivity app has scenarios that involve the notion of a "master/details" view, where the selection of an item determines what is displayed in a details pane, consider using a list layout for the master pane. For example, a project management app could show milestones and deadlines in a master pane, and upon selection of an item there, display relevant details in the details section. An email app could place the inbox on the left and the reading pane on the right side of the screen, as shown here.
Scenarios in productivity apps often require a form layout, where users have to enter information about something. For example, when creating a meeting invitation in a calendar app, users must enter the location, start time, end time, date, attendees, and other, similar info. This type of layout typically uses a mix of different control types and works best with a column-based design.
When deciding which form layout to use, consider the flow of the task you want the user to complete and where scrolling will be required in that flow. Scrolling will increase substantially when the touch keyboard is visible, because the keyboard takes up about 50% of available screen space in landscape orientation. Inline error notifications, when they appear, also increase both the length of the content and the need for scrolling.
Instead of trying to fit all controls into one very long form, consider breaking the task into a sequence of several forms.
A single-column layout can work for short or long, vertically scrolling forms. In the following single-column layout example, the reading and tab order are top to bottom and left to right.
A two-column form layout makes the best use of the visible horizontal space in landscape orientation. To minimize the user's need to scroll, have the reading and tab order go from left to right then from top to bottom.
The following image demonstrates a two-column layout.
Don't use a top-to-bottom, left-to-right reading and tab order for a long, scrolling, two-column layout. This is very cumbersome because the user has to scroll to the bottom of the first column, then scroll back to the top of the second column, and then scroll down again to fill out the entire form. Also, a two-column layout doesn't work well in portrait orientation because it forces the columns to be too narrow.
The following examples show what to avoid in a long, scrolling two-column layout.
Productivity apps often involve multitasking, with users switching back and forth between different types of content within your app. For example, a user may switch among multiple documents such as research papers and previous homework sets when doing an assignment. Enabling users to quickly access all this content in a fast and fluid way maximizes their productivity within your app. Consider using the top app bar described in Navigation design for Windows Store apps for most recently used documents, currently opened documents, and any type of content in your app that is relevant to the user’s current working set. Also consider supporting multiple windows so that users can multitask across different parts of your app. For more info, see Guidelines for multiple windows.
Productivity apps tend to have a lot more commands than other types of apps. This fact poses interesting questions about how best to present commands in a way that they’re discoverable but still put the user's content first. Users should be able to complete your app's core scenarios—those scenarios that facilitate your app’s “great at” statement—just by using the app's canvas. Whenever possible, let users directly manipulate the content on the canvas instead of adding commands that act on the content. For example, when users read a document, enable them to pinch and stretch directly on the canvas to increase or decrease the viewing font size instead of putting in a control to do that. To learn more about commanding, see Command patterns.
Some commands and buttons are so integral to your app that it would be ridiculous for them to not be on the screen all the time. The Play button on a paused video app, for example, would likely never be hidden. But most commands don’t need constant screen time. To help users focus on being productive with their content, many distracting commands can be removed from the screen and brought back only as needed by using a common and simple gesture.
The bottom app bar is the common toolbar that can appear at the bottom edge of your application. It is usually off screen and out of the way, but it can be revealed by swiping from the top or bottom edge with a finger, right-clicking with a mouse, or pressing Windows logo key+Z on a keyboard. Additionally, the bottom app bar automatically appears whenever a selection is made within an app’s content. The tools presented on the bottom app bar are contextual, so only the relevant commands are shown at any time. For example, when a word is selected, the bottom app bar automatically appears showing text-formatting commands. If a picture is selected instead, the bottom app bar shows picture-editing commands. The contextual nature of the app bar means that irrelevant commands don’t compete for your attention. The result is that the tools you want are always close, but out of the way until you need them.
The top app bar can also appear when you manually invoke the app bars. It enables the user to jump to various locations within an application. For example, a browser can use this bar to display thumbnails of the currently open tabs. A word-processing app can use this bar for jumping between various open documents. A shopping app can use this space to jump between different departments of the store.
Both the top and bottom app bars can host buttons and menus. If you have many related commands that are all contextually relevant at the same time, it makes sense to place them in a menu that is opened from the bar.
It is important to organize and present commands in a consistent, organized way so users are not overwhelmed by the sheer number of commands. For example, in a notes app, users may want to create new notes or notebooks, sort notebooks alphabetically or by date, change formatting options for note text, insert audio notes, specify location, and add tags and images. The app bar helps place all your app commands on a consistent surface that is predictable for users, so they can depend on finding all their commands under one roof.
For your app, complete an inventory of all the app commands and think through their usage scenarios. One way to reduce commands that appear on the app bar is to organize them into two categories: commands that are global to the app and commands that are useful only on selection. For the latter, don’t always show contextual commands on the app bar; instead show them only when the user has selected something or only in the context of the app where they’re relevant.
Place global commands that show up everywhere in your app, like sync and “create new” operations, on the right side of the app bar. In particular, put the New command—the command that creates new content like a new note or notebook— against the right edge of the bar. This gives every New command, regardless of the specific app or context, consistent placement and makes it easily accessible for touch input using the thumb.
Use the Delete and New commands if your app is about managing individual entities that may persist outside of your particular application—for example, an email app. Delete and New should always appear in the order shown here.
Use Remove and Add commands if your app is about managing a list, such as a to-do list. Remove and Add should always appear in the order shown here.
There are other commands that affect selections. These should always appear on the far left, whether they are contextual commands that appear upon selection or commands that affect an existing selection, such as formatting options, "Select all," and "Clear selection."
Consider which commands are functionally related and should be placed close to each other. Make sure you place commands consistently whenever possible. Also, create command sets to manage the number of commands that appear on the app bar, and consider creating command menus for command sets wherever possible. For example, in a notes app, arranging notes alphabetically or by date could each be accomplished by a single command by using a command menu. Command menus help to organize and greatly reduce the number of commands on the app bar, as shown here. In the first image, each New command is a separate command on the app bar. In the second image, all the New commands are grouped in a menu on the single New command.
Make sure that settings are displayed in the Settings contract and not in the app bar. This lets users configure your app via common mechanisms that they are already familiar with.
Both app bars can host buttons and menus. If you have many related commands that are all contextually relevant at the same time, it makes sense to place them in a menu that is opened from the bar. The app bars are not limited to buttons and menus — both allow you to create your own unique controls. If you do so, think about how touch, mouse, and keyboard users can best interact with the new controls you create.
Apps with a high volume of commands may consider extending the app bar in various ways. To keep as much consistency as possible with the rest of the system, try to follow these guidelines:
- Keep the user focused on content—Assume that most interaction starts with direct manipulation of the canvas. It is expected that most (if not all) commands will normally be located off screen with no visible affordance for bringing them into view. Rely on the system-wide gestures for showing and hiding the app bar to show and hide your UI. Adding you own alternate, hidden UI with different invocation methods leads you to put more buttons, widgets, and arrows on the screen as you attempt to educate the user. Relying on the system gestures helps you avoid adding on screen distractions that steal attention from the user’s content.
- Keep commands on the bottom app bar—In Windows Store apps, the natural and expected location for commands is at the bottom edge of the app (or just above the touch keyboard). This location allows touch users to interact with the commands without blocking their view of the content. This location is also related to the touch gesture that is used to show the commands manually. Having your commands appear in some other location is less predictable, and potentially interferes with content that the user is trying to view or interact with.
- Keep navigation controls on the top app bar— In Windows Store apps, the natural and expected location for navigation is at the top edge of the screen. Because this bar is for jumping away from the content that the user is currently using, it’s okay that the user's hand blocks sight of the screen while he or she uses the bar. The top app bar usually displays thumbnails, rather than buttons, to help distinguish it from the bottom app bar.
- Keep all of your hidden commands in the app bar— All of the commands that are hidden off-screen should be hidden in the same place. The system gesture provides one simple and standardized way to bring the hidden commands on screen. If commands are hidden in multiple locations, you’ll need multiple ways to invoke those hidden surfaces. This quickly creates far too many places that the user must check to find your commands. Even worse, each surface may be hidden behind a different secret gesture or other UI trick and users will have a hard time knowing whether they’ve ever found them all.
Clipboard commands such as Cut, Copy, and Paste for selected text, and commands to copy and open links for URLs, can make use of context menus, which are provided by default by the system. Here are examples of clipboard commands in a context menu.
Productivity apps may involve a lot of data-input scenarios. For example, creating a to-do list or another new document, editing an existing spreadsheet, or creating a calendar invite all require input. Making data entry as fast and fluid as possible helps your users accomplish their work quickly and efficiently.
Think through your scenarios and, wherever possible, reduce the amount of text users have to enter into the system. Strategies for doing this are:
- Common controls—For input that is strongly formatted or needs validation (like date, time, or location), use common controls like the select control, drop-down list boxes, radio buttons, check boxes, and date and time pickers.
- AutoComplete—Use AutoComplete wherever possible to provide instant gratification to users. This make users more efficient with input entry.
The following image illustrates suggestions for a contact picker.
Design your app to work well with keyboards by following the guidelines in Responding to keyboard input. Design your application to work well with the touch keyboard by following these guidelines:
- Place text input controls toward the top of your app’s canvas, if possible, so that the context or viewable region for the user does not change when the touch keyboard comes up.
- If text input is such that it can’t all be placed at the top of the canvas, when the user taps or tabs to the text input control, the app is automatically scrolled up to where the control appears so that the user can see the text as he or she enters it. The window should scroll so that there is a minimum of 30 pixels between the control in focus and both the edge of the screen and the top of the touch keyboard, to leave room for various edge gestures, UI elements, and the text-selection gripper. To read more about text selection, read the Guidelines for selecting text and images.
- Don't keep the keyboard up simply for the sake of keeping the keyboard on the screen. If text entry is not expected to occur, dismiss the keyboard by setting the input field to read-only or by moving focus.
Here's a look at the touch keyboard.
If your app has a form-like screen where there is commonly a mix of edit controls (text boxes) with other controls (like radio buttons and check boxes), it would be a bad user experience to have the touch keyboard keep flashing on and off. Windows 8 addresses this issue by preventing the touch keyboard from being dismissed when a user is in a form and navigating among certain common controls like radio buttons, text boxes, selection controls, and the app bar. Using standard controls gives your app a smooth experience for free. Here's an illustration of how the touch keyboard persists as the user moves from control to control.
Enable spell check for your app. It helps users enter text quickly and confidently. (Spell check can be enabled by means of the RichEdit control). When the user types a word that is not found in the dictionary and then presses the space bar, a wavy red underline appears beneath the misspelled word. Tapping the misspelled word invokes the spell-check menu on which the user can correct the misspelling or ignore it, as shown here.
Because users often tend to use multiple modes of text input for productivity apps, consider supporting alternative ways to enter text, such as pen input. Enabling users to "ink in" text and to doodle in their notes and documents in your app delights them and enables them to enter text quickly and naturally with a pen. See Guidelines for common user interactions for more information on the various input methods.
In many productivity scenarios, including document creation and consumption, users need to select text. Enable selection for text that is typed by users so that they can edit it. Text that comes from other users includes email body text or other text that is likely to be copied. Here's a look at the text-selection experience.
When enabling text selection, allow a margin of one half of the gripper width (4 millimeters) on the sides of the text and one gripper height (8 millimeters) on the bottom of the area if the text isn’t scrollable. This ensures that grippers will be touchable in all cases and won’t interfere with the user experience at the edge of the screen. The following image shows the correct margins to preserve when you enable text selection.
Using the typography grid and size ramp in productivity apps creates a visual hierarchy that enables users to scan and consume a lot of information quickly and easily. Although the use of the Segoe UI font specified in the type ramp is appropriate for content in productivity apps, you might consider using Calibri, the recommended “modern document” font, or Cambria, the recommended “traditional document” font. Calibri is the default sans-serif font in Microsoft Office, and Cambria is the default serif font, so both fonts have a strong association with productivity apps. For more information about typography, see Guidelines for fonts.
If you decide to specify alternate system fonts, be sure to confirm that they are installed with Windows 8 and don’t require the installation of a separate application such as Microsoft Office. If you use your own custom or licensed fonts, make sure you have sufficient legal rights to include them with your app. Regardless of the fonts you choose, the Windows 8 type ramp provides good guidance about the maximum number of sizes and styles you should use.
The Windows 8 UI personality requires the use of sentence-style capitalization in headings, and we recommend this for productivity apps. However, title capitalization may also be appropriate in some cases. Use of all-lowercase text may feel too informal in a productivity app, and text in all capital letters may unintentionally remind people of angry email messages. Be aware that these latter typography treatments will not transfer to many localized languages. Also, be sure to use capitalization styles consistently; use them to differentiate among different pieces of content, not just to add visual interest to your app's typography.
Using a small set of font sizes throughout the app, as recommended in the type ramp guidance, creates a sense of structure and rhythm in the content. If multiple elements in your app use the same font size in the type ramp and yet convey different types of information, consider using color and font weight to establish an information hierarchy.
Contracts are the glue that binds Windows Store apps together and to the system UI. Two apps that have implemented the same contract can work together to complete a broad or complex scenario. For a complete list of app contracts, see App contracts and extensions.
Sharing content is a key component of productivity apps today and there are many compelling scenarios for sharing to and from productivity apps. If you want to enable your users to share content from the app, the app should be a Share source. If you want to enable your app to consume data from other apps, the app should be a Share target.
Because productivity is often about content creation, users typically share content with others and Windows 8.1 enables a seamless experience for sharing between apps. As the user gets more apps, this interoperability increases the reach of your app contents to a wide array of possibilities.
For example, users may want to share to-do lists and grocery lists with their families by using a contacts app, share documents with coworkers by using a collaboration app, or share their creations on blogs by using a blogging app, to name just a few sharing scenarios. These screen shots show ways you can share in productivity apps.
Being a Share source means making the content in your app, be it in the form of URIs, bitmaps, HTML, text, storage items or custom data types, available to other apps that can consume these formats. As a source app, it’s important to support as many data types as are meaningful for the content that you would like your users to share. This makes it possible for your users to share your app’s content with a broad set of Share target apps.
By supporting the Share source contract, you also enable your app to share directly to devices in near field proximity as enabled by Tap and Send.
Productivity apps typically also make a great target for sharing content from other apps because content creation often starts from content consumption. If your app is a share target, your users can import content into your app seamlessly without having to switch context from the activity that they are engaged in. There are many compelling scenarios for using productivity apps as a share target. For example, sharing URLs, text snippets, photos from the browser, and content from a book could target a document-creation app as reference sources for homework. As another example, users may share coupons from a coupon app to the grocery list in your to-do app. These screen shots show examples of an app as a share target. You can also imagine greater interoperability between a suite of productivity applications that rely on sharing data with each other using the Share contract.
Search is an important scenario for productivity apps, and your app may need to display a lot of data as search results. You can use the Windows 8.1 search-box control to provide the search UI on the canvas. The search box integrates with the Search contract to power the experience and enable deep customization, so your app offers experiences that are crafted to user needs.
When you design your app’s search experience, keep the following in mind:
- Provide query suggestions to help users automatically complete their search queries and make it faster for them to search without necessarily typing the whole search string.
- Provide search filters for the results view.
- Show the search query in the results view.
- Show the total number of results found.
- Maintain the state of your app, so users have a way to go back to what they were doing before their search.
- Indicate why a result matched searching.
- Consider showing result suggestions to help users quickly get to the most relevant result. Selecting a result suggestion should take users to the details of the result. Limit the number of suggestions to five; a short list is easier for users to parse.
For more info about the search-box control, see Search updates.
Along with search, " Find in page" is a common scenario in productivity apps. For example, consider finding all the instances of a word in a certain document. Don’t use the Search charm to implement find-in-page functionality for your app; instead, implement it within the app command bar and not in the search pane. Find-in-page helps the user locate all instances in the current view. Highlight the find results in the document, and show "next" and "previous" buttons on the app bar to enable the user to jump quickly between different instances of the found word or a phrase. In productivity apps, find is often used primarily to complement the replace experience. Find is always scoped to the current view, as shown here.
All applicable settings for productivity apps (like privacy settings, notification settings, and view preferences) should live in the Settings charm. The Settings charm provides a single place for users to adjust their settings and also prevents your app's UI from becoming cluttered with different settings. For more info about settings, see Guidelines for app settings.
Printing documents and notes is a common scenario in productivity apps. Provide users with printing functionality via the Devices charms for a seamless printing experience. Here's a look at the devices experience for printing.
Devices can be an interesting contract for your productivity app to plug into. If your app has a lot of media and potential presentation scenarios, your users may want to view it on televisions in shared media experiences. Integrating with the Devices contract enables your users to do that.
Productivity apps can involve a lot of interesting scenarios for using content from other apps. Using the file picker allows your app to gain access to a user’s files and folders located on the local PC, connected storage devices, HomeGroup, and other applications that implement a file picker contract. This lets users insert content from other apps into your app, enriching the experience for your users. For example, in a notes app, the user may want to insert a photo from a photos app or audio notes from a sound recorder app.
Your app can also customize various aspects of the file picker. Specifically:
- File picker mode: You can set the mode of the file picker to match your task. Picking files, saving a file, and picking a folder are all supported in the file picker. Allowing the user to pick a folder, for example, would enable the user to pick an entire folder to upload to a cloud storage location.
- View mode: When having the user choose a photo or video, you can customize the file picker to show files in the thumbnail view mode. For all other file types, use the tile view mode.
Also, the content from your productivity app could be meaningful to users in other contexts, and accessing this content from other apps enables powerful scenarios for your users. Using the file picker contracts provides an opportunity to make the content within your application available to other Windows 8 apps. This enables users to get to their content from your app without having to go through an intermediate process such as saving those files to the local computer first. When apps enable this experience, users can select your app from the list of locations in the file picker. When selected, your app's content becomes accessible to users through a view of the file picker that is specific to your app and that you control.
File picker functionality enables some compelling scenarios. For example, if a user wants to send a note created in your notes app by email to some friends, he or she can attach content from the notes app directly instead of having to save it locally first.
The file picker also enables saving directly to your app. This also enables really interesting scenarios. For example, a user can save an e-mail message or a doodle created in another app directly to your app as a note. Here's a look at how the file picker can be customized.
Apps that run on Windows 8.1 should integrate experiences and personality that make them stand out. By using tiles, notifications, roaming, and contracts, your app will fit smoothly into the Windows 8.1 ecosystem.
Showing fresh and tailored content on the app tile re-engages users and continues to draw them into your app when they happen to notice interesting content on your tile. Compelling scenarios include showing tile notifications when someone has updated a shared document, shared a new note with the user, or edited the grocery list and marked off or added new items. A notification can also show the position of a point of interest, as in this example.
Enabling users to pin secondary tiles for quick access to their favorite notes and content enables them to see tailored notifications for that content and, again, draws them into your app.
For productivity apps with time-sensitive reminder scenarios—for example, a to-do list item to pay a bill at the end of the month—users may want to associate reminders and completion dates with tasks. Consider showing them toast notifications that are scheduled for the time at which the user wants to be reminded. A good practice for missed toast notifications is to show that reminder on the tile as well, as shown here.
Most people have more than one Microsoft Windows PC. Having your app provide a consistent user experience across all of a user's Windows PCs provides the experience he or she expects. You can roam app settings, info about what the user did last in your app, and any other preferences in your app that are useful to users across all their PCs. Guidelines for roaming application data offers more information about best practices for roaming.
Because Windows 8.1 runs on various types of devices and has a new multitasking model, make sure your app supports portrait and landscape orientations and works well at any size, down to the minimum width.
When designing your productivity app for Windows 8.1, consider all views of your app, such as different screen resolutions and device sizes. Windows 8.1 makes it easy to scale the design by including more content in your app for larger devices. Here's an a notes app resized to a tall, narrow layout.
Tall, narrow layouts and portrait orientation are great for reading and consuming large amounts of content. Be sure that your app rearranges your content to fit the window size.
When a user resizes your app do not lose the user’s context and state. This is particularly important in productivity apps where users may have spent a lot of effort producing content. Preserve text input, scroll position and any selection the user has made when the user resizes your app.
When your app is narrower, the app bar control automatically removes labels and decreases padding between commands. If there are a lot of commands, you can be creative with how you display them. For example, use two rows of commands in the app bar or use flyouts on commands. For more information, see Guidelines for app bars.
Additionally, think about how your app adds value and make those scenarios great. Show a user why your app works great alongside other apps. For example, it’s easy to imagine a note-taking or list-making app working along with some other app. When researching or authoring, it will be common to keep a reference or analysis app on the screen next to your main work. Reading and authoring apps are very useful in narrow widths so that you can reference them while you do something else. Think about all the times your app wouldn’t be maximized in the traditional desktop; those are the scenarios your app should support when resized to a narrow width.
Designing your app to work well at narrow widths is a great way to increase your app's time on screen and engage users for longer periods. Here's an example of a notes app side by side with the browser.
Build date: 11/16/2013