With this style of apps there is a clear platform diagram:
but there is no similar kind of diagram for the structure of the applications themselves, although that structure is absolutely different from the ones we are familiar with in the existing Windows applications of different kind.
First I will present the current confusion in that regard and then SOME answers to that from current MSDN documentation. Some because an equally important part, the contract mechanism is not described in the “answer excerpts” that will follow after the “introductory confusion part”. For the contract mechanism I will include here just this simple paragraph from the Fact Sheet:
Apps are part of a web of apps, not a silo of unrelated apps. Apps can communicate with one another in Windows 8. Rather than switching apps to share information, you stay immersed in your app and share the information to another app right in that context, never losing your place. So if you want to share a photo from a social network app, you just swipe the share charm and share to the app. No burdensome and baroque cut and paste.
Other missing information in brief from the published short guide:
Adding Metro style to your apps
Your apps get a predictable, Metro style UI that’s tailored to the device by using Windows 8 controls. The controls are designed for both touch devices and for mouse and keyboard. By default, your apps convey the Windows personality, which is a familiar user experience that customers understand. Here are the three kinds of controls that you can use.
Standard controls: these include everything you need to display, enter, and manipulate data and content. Control families include view, text, pattern, overlay, media (audio and video), content, collection, and basic.
Collection controls: These help designers to create rich content experiences in consistent, touch-friendly ways. They include built-in support for drag-and-drop operations, and they let you customize display modes by using styling and templates. Examples are the simple list, grid view, grouped grid view, flip view, and semantic zoom.
Creating immersive user interfaces with adaptive layout
Windows 8 gives you creative options for adapting an app experience dynamically to the size of the screen area, changes in orientation, and different display capabilities using CSS3. These features enable you to give your customers a fluid, natural-feeling experience in your Metro style apps. Here are some examples.
Animation: Create smooth, animated experiences and elements with HTML5 and CSS3 that embody the Metro style. Take advantage of a comprehensive set of pre-defined animations that are lively and unique, yet familiar to users.
3-D transformations: Add smooth, fluid visual experiences, such as perspective transforms and flipping elements on and off the screen. In the past, you’d have to create these effects using native code, but now you can create them with HTML5 and CSS3.
Flexible box layout: Create flexible containers that expand proportionally to fill any remaining space in an HTML5 layout. This is great for designers to use to create key components of apps, such as toolbars or navigational elements.
Grid layout: Position and size content elements into cells on a grid structure that you define with fixed, fractional, or automatic units.
Multi-column layout: Mimic newspaper and magazine layouts by creating a single column of HTML5 content in multiple parallel columns with equal width and height.
A typical confusion about Windows 8 Metro style apps:
Re: Windows 8 apps going html5, wtf – part 2 [Sept 15, 2011]
I just watched this BUILD speech by Jensen Harris: http://channel9.msdn.com/Events/BUILD/BUILD2011/BPS-1004 [although it is the most detailed video “answer”, [1:33:05] long, HIGHLY RECOMMENDED BTW]
I must admit that all those concepts regarding the metro touch UI appear to be really thought through. They actually looked at how people hold und use tablets, and the optimization to the “two hands, use thumbs”-method seems quite sensible (the split up touch keyboard was a little odd though … c’mon! … typing with your thumbs?).
Next I browsed the Windows Runtime Reference, http://msdn.microsoft.com/en-us/library/windows/apps/br211377(v=VS.85).aspx(thx to jackbond for the link), and I was relieved to find lots of familiar stuff in there like XAML of course, Dependency Properties, Control Templates etc.
So I’d be willing to change my former “do not want!” attitude to a more excited “Lots of work coming up, but it’ll pay off” one if … well, if all of this was covered by “BUILD – the conference solely for handheld device developers”. As I said before: I might be too stubborn to grasp all this visionary stuff (I guess there’s a reason it’s not me working at the top of win dev😉, but I simply cannot seeANYof this apply to the desktop environment.
I absolutly disagree for example with Harris’ statement that in the near future we will all unbelievingly remember that there once were screens without touch. I still don’t see me working (yes, Mr Harris, I actuallyWORKwith my Computer rather than spend my whole time looking at beautiful RSS-Feeds, weather forecasts, tweet@rama and stuff like that) here at my desk by pawing my monitor.
And when he showed how to operate Metro UI with a mouse I ultimately thought “Hey, you cannot be serious about that”. So instead of having a context specific pop up menu at the very position of my mouse pointer when I righclick I now get the ususal app bars at the top and bottom of the screen which forces me to move my mouse pointer a much greater distance to achieve the wanted result. This is not “fast and fluid”, but its sheer opposite.
So I’ll try a new evaluation of where this leaves me as a developer. We now have a new UI that (in my opinion) is awesome for handhelds, but doesn’t make any sense on the desktop. We finally(!) have a true replacement for the WIN32-API (“YES!!”) that unfortunatly only works with Metro UI (“D’oh!”). We still have the traditional desktop, but it is clearly labeled as “NOT modern, NOT immersive, NO WinRT” (I still don’t understand why). We have Silverlight that doesn’t run in the Metro UI Browser because its own creator(!) thinks that this plugin only disturbs the indeedily-doodily HTML5 experience.
I stand here scratching my head in disbelief, and I cannot resist the impression that this whole show is about “Heeeyyyy, we developed an AWESOME solution! Wait, it gets better: for a problem that didn’t even exist!”. I think it’s hilarious to read posts like this http://dougseven.com/2011/09/14/i-know-what-youre-thinking-and-youre-wrong/ (thx to jrboddie for the link). So while Mr Sinofsky is still on stage at BUILD trying to sell Metro to the crowd as the next big thing, developers are wiping the sweat off their foreheads in relief to hear people like Doug Seven say “My advice…keep doing what you are doing [with WPF and Silverlight], and invest 20% of your time in learning about Windows 8 and the Metro style app models“. There’s something going very wrong here, and I wonder if anyone at the top of Microsoft does take notice.
Windows 8 Previewed Today at BUILD [Sept 13, 2011]
Build: More Details On Building Windows 8 Metro Apps [Sept 14, 2011]
Jensen Harris Walks Us Through the Windows 8 UI [only 10 minutes long Channel 9 video, Sept 14, 2011]
A great example: Metro style browsing: one engine, two experiences, no compromises[Sept 14, 2011]
A great number of Metro style app samples
Answers from Metro style app development:
Touch is an important part of many Metro style app [they are touch first!] using C++, C#, or Visual Basic apps. But the mouse remains a primary means of interacting with these apps on some devices. Learn how to make your apps work with both means of input.
>> Quickstart: Touch input
With the Windows desktop, the shell is static. Icons can be colorful and pretty, sure, but they really just sit there. A running app is also often surrounded by visual noise that has little to do with the app itself—noise that comes from other apps and from Windows itself. Even an app’s own menus, ribbons, and other command structures often consume a noticeable portion of screen space and can distract the user.
In contrast, Windows Developer Preview is designed to help Metro style apps engage and re-engage the user much more deeply:
- Apps typically run full-screen and the Start screen disappears after an app is launched. System UI also appears only as needed in response to specific user interactions. As a result, users are completely immersed in the foreground app by default, and you don’t need to implement a special full-screen mode.
- The exception to this is that two apps (and only two) can run side-by-side. One occupies the majority of the screen and the other, a smaller portion to the side. This keeps multi-tasking focused on the user’s most important apps.
- For all but its most essential UI, apps can use the app bar and flyouts to reveal secondary operations when needed, in response to specific interactions.
- Live tileshelp apps dynamically display their most important content on the Start page, providing users with essential info at a glance. This way, users don’t have to open the full app to engage with it.
- Users can create content tiles [secondary tiles] that link directly into specific parts of an app. This makes the interaction with an app both highly efficient and meaningful, in contrast to the user wasting their time simply navigating the app structure.
- Apps can use notifications to surface events to the Start page in a way that feels natural to Windows. Such consistency increases the likelihood that a user will take notice of the event and re-engage with the app.
In addition to having two side-by-side apps, Windows Developer Preview introduces a new means of multitasking— apps can now work together to perform common tasks such as searching, sharing, and managing contacts:
- Instead of having the user switch between apps, as in the classic Windows shell, portions of other apps that help fulfill a task, like sharing, appear directly in the foreground app.
- In the classic shell users often must switch between apps because the data they want is accessible only within a particular app. In Windows Developer Preview, such apps can act as sources for searchable data, sharing services, contacts, and files. This means that selecting and sharing a picture that’s managed in an online service like Flickr is as easy as picking a file that’s on the local hard drive.
With all this aliveness and active integration, it is also important to optimize battery life and maximize the responsiveness of the foreground app. Here is what’s new:
- Windows Developer Preview automatically suspends background apps once those apps have an opportunity to save their state and finish long-running tasks.
- Suspended apps remain in memory and can be quickly resumed if the user switches back to them, they’re needed to fulfill a task (like providing search results or a sharing service), or they’ve asked to be awakened in response certain events like a timer or network activity.
- If the system needs to free memory, it can unload suspended apps, knowing that the app can reload its saved state when it starts up again to bring the user right back to where they left off.
- Selective app features, such as music, voice-over-IP, and data transfer, can continue running in background mode (subject to user approval).
Finally, because many users spend the majority of their computing time in a web browser, with Windows Developer Preview an app can specify itself as the primary handler for certain internet domains. This means that navigating to those domains takes the user to a typically richer app experience rather than a generic browser experience. Developers can also use header markup in web pages to identify a handler app, which improves app discovery both through the browser and through Bing search.
Your Metro style apps engage users with the info they are interested in and the people they care about. Live tilesupdate users at a glance and draw them into your app.
The Start screen is about showing off what apps are great at. App tiles are alive with status and activity updates, encouraging your users to dive into your app. When designing your tile, you need to:
- Highlight your brand. Your app tileis a chance to visually define your brand for your users. It should be attractive and distinct.
- Showcase the info and activities your users are most interested in. You want your users to keep returning to your tile, looking for updates, checking in. You want those updates to pull your users back into the app itself. The more thoughtful you are about the kinds of info and activities you showcase, the more likely users are to engage.
In the new Windows Developer Preview Start screen, tiles are the primary representation of an app. Users launch their apps through those tiles and tiles can display new, relevant, and tailored content to the user through [tile] notifications. This makes the Start screen feel vibrant and allows the user to see at a glance what’s new in their world.
An app can also communicate time-critical events to the user through toast notificationswhether the user is in another app, in the Start screen, or on the desktop. The methodology to design and deliver toast closely parallels that of tiles, lowering the learning curve.
Tile notifications, toast notifications, and badge updates [or notification badge] can all originate either from a local API call or from the cloud.
Tiles and tile notifications
Tiles represent your app in the Start screen. They are the primary method for the user to launch your app, but can also surface information and notifications directly through tile itself, making it a dynamic representation of your app even when your app is not running. This contributes to making Windows feel alive and connected. An interesting and useful tile can give a user incentive to launch your app and this aspect of your app development should not be slighted.
Tiles are available in two sizes. Which of the two sizes is displayed is entirely controlled by the user.
- Square: This tile size can contain application branding—either an application icon or name—as well as potential notification badges. Because a square tile contains only basic information, only one template is available to create them.
- Wide: This tile size can contain any of the content of a square tile plus richer, more detailed, and more visually compelling content as well. A broad choice of layout templates is available at this size to allow the additional content. Any app that uses a wide tile must also provide a corresponding square tile because the user can choose to shrink the tile at any time as they personalize their Start screen.
The content of a tile is defined in XML, based on a set of templates provided by Windows. To define a tile’s contents, the developer simply retrieves one of the templates and provides their own text and images.
A tile can contain text and images, depending on the template selected, and can also display a badge and either a logo or short name. The badge is displayed in the lower right cornerand the logo or short name in the lower left. The choice of whether to show the logo or the short name is declared in the app manifest.
Up to five update notifications can cycle repeatedly through the tile if the developer declares the tile to have the cycling capability. Notifications can be given a tag to use as a replacement ID. Windows examines the tag on a new notification and replaces any saved notification with the same tag. Notifications cycle until they expire, are pushed out of the queue by newer updates, or are replaced in the queue with an updated version of themselves.
When your app is first installed, it is represented by a default tile. This is a simple, static tile defined in your app manifest; generally just a representation of your logo or brand. This tile is replaced only when you send your first tile notification. It’s a significant concept to grasp that the only time you technically “create” a tile is when you define it in your app manifest. All further changes are tile notifications.
Your tile can revert to the default when there are no notifications to be displayed on the tile; for example, when the user is offline or all tile notifications have expired.
As with any tile, if you supply a wide tile, you must also supply a square tile.
Default tiles are rendered on top of the app color, so if there is any transparency in the default tile image, the app background shows through.
Secondary tiles provide the ability to create tiles pinned to the Start screen that launch directly to a specific location or subexperience in a parent app. The app decides which content to offer as a pin option, but the user has the final say in whether the secondary tile will be created or deleted. This allows users to personalize their Start screen with the experiences they use the most.
This tile is independent of the main app tile and can receive tile notifications independently. When the secondary tile is activated, an activation context is presented to the parent app so that it can launch in the context of the secondary tile.
A toast notification is a transient message to the user that contains relevant, time-sensitive information and provides quick access the subject of that content in an app. It can appear whether you are in another app, the Start screen, or on the desktop. Toasts are an optional part of the app experience and are intended to be used only when your app is not the active foreground app.
For your app to be able to receive a toast notification, you must declare that it can do so in your app’s manifest file.
A toast notification can contain text and images but secondary actions such as buttons are not supported. Think of toast as similar to a Windows balloon notification arising from the taskbar’s notification area. Like those notifications, a toast appears in the lower-right corner of the screen. When a user taps or clicks on the toast, the associated app is launched in a view related to the notification. It is the only mechanism by which one app can interrupt a user in another app. Toasts can be activated, dismissed, or ignored by the user. The user can also choose to disable all toasts for an app.
A toast notification should only be used for information considered of high interest to the user, typically involving some form of user opt-in, therefore it is a good choice for incoming e-mail alerts, IM chat requests, and breaking news. However, it is extremely important that when you consider using a toast notification, you realize that, due to its transient nature, the user might never see it.
Raising a toast notification is very similar to sending a tile notifications: a developer creates an XML payload based on a provided template and passes that payload to a manager object to display. Toast is visually distinct from a tile but the markup structure is nearly identical.
There are two types of toast notification:
- Standard toast: Most developers will use the standard toast. This toast remains on the screen for 7 seconds, playing a brief sound to alert the user when it appears. This toast is best for notifications such as a new e-mail, an IM contact sign-in, or a new social media update.
- Long-duration toast: This toast looks the same as a standard toast but stays on the screen for 30 seconds and can play longer, looping audio. This is used in situations where developers want to grab the user’s attention because there is a human waiting on the other end of the connection. This type of toast is appropriate for person-to-person communication like instant messages and VOIP calls.
Scheduled and recurring toast
A toast notification can also be scheduled to appear at a specific time. Use this feature for alarms, calendar reminders and notifications that depend on precise timing. These notifications do not depend on the app’s state or the computer’s network connection.
A scheduled toast notification can also display multiple times within a short period to increase the user’s chance of seeing it. For instance, you might want to show important meeting reminders three times, five minutes apart.
Scheduled toast notifications specify the date and time when Windows should raise that toast notification. In the case of a recurring scheduled toast it is the first time that the OS will display the notification.
A tile can display a notification badgewhich conveys summary or status information concerning and specific to the app. Badges can be displayed on either the square or wide tile. They can be numeric (0-99) or one of a set of Windows-provided glyphs. Examples of information best conveyed through a badge include network connectivity in an online game, user status in a messaging app, number of unread mails in a mail app, or number of new posts in a social media app.
The system provides a set of glyphs for use with a badge. These glyph values are available:
- Use what you know about the user to send personalized, tailored notifications to them through the tile. Tile notifications should be relevant to the user. The available information about a user on which this relevance is based is largely internal to the individual appand may be limited by a user’s privacy choices.For example, a television streaming service can show the user updates about their most-watched show or a traffic condition app can use the user’s current location to show the most relevant map.
- Send updates to the tile frequently so the user feels that the app is connected and receiving fresh, live content. The cadence of tile notifications will depend on the specific app scenario. For instance, a busy social media app could update every 15 minutes, weather every two hours, news a few times a day, daily offers once a day, and a magazine app monthly. If your app would update less than once a week, consider simply using a square tile with a badge.
- Provide fun and engaging tile notifications to help users make an informed decision about when to launch your app. For instance, if you provide a shopping app, tell the user when a sale is going on.
- If your app is not connected to cloud updates, use the tile to display local content or recent activity, updated each time the user launches or exits the app. For instance, a photo viewer tile could display photos from a recently added album. A video streaming service could show a static image to represent a video the user recently watched but didn’t finish.
- Don’t use relative time stamps or dates (for instance, “two hours ago”) on tile notifications because those can become out of date. Use an absolute date and time (for instance, “11:00 A.M.”).
[How to Create the Best User Experience for Your Application [April, 2006]]
Figure 10. Custom toast window with graphics and multiple controls
“Toast” windows (see Figure 10), made famous by instant messaging clients like MSN Messenger, are a great solution for informing the user of something without annoying or disrupting his or her work flow. There is a great article by Bill Wagner on creating Toast windows. It is good policy (and manners) to not disturb any other application’s toasts. Obstruction of such windows can be annoying and unproductive. One solution is to use the ToastSemaphore Mutex provided by the OS to avoid toast collision.
Sometimes you may need to show multiple items by the toast. Popping up 3 or more toasts would not really be advisable. Instead, cycling through each by popping/fading one toast after the other would be better. Microsoft Outlook implements a similar solution when notifying the user of incoming e-mails.
- Consider that the user might not see the toast. If the information is important, you may want to retain related information on your tile or within your app views.
- Notify the user of something personally relevant and time sensitive. Examples include:
- new e-mails in a mail app
- an incoming VOIP call
- a new instant message
- a new text message
- a calendar appointment or other reminder
- notifications that the user has explicitly opted-in for
- A running app can hide a toast notification if it is no longer valid, such as an incoming call where the other party has hung up or the user has already answered on another device.
- Do not include text telling the user to “click here to…” It is assumed that all toasts have a click/tap action with a result made clear in the context of the notification.
- Combine multiple related updates that occur within a short period of time into a single toast. For instance, if you have 3 new e-mails that arrive at the same time, the app or app server should raise a coalesced notification.
- Don’tuse toast to notify the user of something that must be seen, such as a critical alert. To ensure the user has seen your message, notify them in the context of your app with a flyout, dialog, app bar or other inline element.
- Don’t use toast to notify the user of transient failures or network events, such as a dropped connection.
- Don’t notify the user of something they didn’t ask to be notified about. For instance, don’t assume that all users want to be notified each time one of their contacts appears online.
- Don’t use toast for anything with a high volume of notifications, such as stock price information.
- Don’t notify the user of something that is not user-initiated, peer-to-peer, or explicitly enabled by the user.
- Don’t use toast notifications for non-real time information, such as a picture of the day.
- Don’t use toast to notify the user of routine maintenance happenings, such as the completion of an anti-virus scan.
- Don’t raise a toast when your application is in the foreground. Use PushNotificationReceivedEventHandler to intercept push notifications when your application is running.
A badge is used to provide status on a tile, such as the number of new e-mails received or the status of a network connection. There are two variations: a number and a glyph. Badges are also defined as an XML document and its elements are defined in the badge schema.
- Tile designers should attempt to create an appealing tile for their app that presents new, tailored, and engaging content that the user will want to check in the Start screen and that invites them to launch the app.
- For a suite of apps, create one tile for each unique app in the suite.
- Don’t create multiple tiles that open subexperiences in the same app. There should only be one tile for each unique app. Instead, consider whether secondary tiles [content tiles] would be a better option for those scenarios.
- Don’t clutter the user’s Start screen with tiles for extras or accessories along with the app’s main tile. Only create multiple tiles when the product is truly a suite and each tile represents a separate core app in that suite.
- Don’t create a tile for a configuration or troubleshooting experience within the app. That functionality should be provided to the user through the app’s Setting charm.
- Don’t use tiles for advertisements.
- Avoid the overuse of loud colors in tiles; simple, clean, elegantly designed tiles will be more successful than those that scream for attention.
- Don’t use images with text on them; use a template with text fields for any text content needs.
- Don’t rely on tiles to send urgent real-time information to the user. For instance, a tile is not the right medium for a news app to communicate an immediate earthquake evacuation message. Toast is a better medium for messages of an urgent nature.
- Avoid image content that looks like a hyperlink, button, or other control. Tiles do not support those elements and the entire tile is a single click target.
Secondary tiles [content tiles] enable users to promote interesting content and deep links—a reference to a specific location inside of the pinning app—from Metro style apps onto the Start screen. Secondary tiles enable users to personalize their Start screen experience with playlists, photo albums, friends, and other items important to them.
The option to create a secondary tile is seen most often in UI as the Pin to startoption. To pin content is to create a secondary tile for it. This option is often presented as a glyph on the app bar.
Selecting the secondary tile through a touch or a click launches into the parent app to reveal a focused experience centered on the pinned content or contact.
Only users can create a secondary tile; apps cannot create secondary tiles programmatically.Users also have explicit control over secondary tile removal, either through the Start screen or through the parent app.
Secondary tilesare associated with a single parent app. They are pinned to the Start screen to provide a user with a consistent and efficient way to launch directly into a frequently used area of the parent app. This can be either a general subsection of the parent app that contains frequently updated content or a deep link to a specific area in the app.
Examples of secondary tile scenarios include:
- Weather updates for a specific city in a weather app
- A summary of upcoming events in a calendar app
- Status and updates from an important contact in a social app
- Specific feeds in an RSS reader
Any frequently changing content that a user wants to monitor is a good candidate for a secondary tile. Once the secondary tile is pinned, users can receive at-a-glance updates through the tile and use it to launch directly into the parent app to reveal a focused experience centered on the pinned content or contact.
A splash screen is requiredfor all Metro style apps.
Your default splash screen displays when users launch your app, providing immediate feedback to users while your app initialized its resources. When your app’s first view is ready for interaction, the splash screen is dismissed. Good use of a splash screen can improve how the user perceives the performance of your application.
You can customize your application’s loading display by specifying the splash screen image and background color, and by using the Splash Screen API to display your splash screen for longer, and/or to notify your app when your splash screen is dismissed.
Extending the length of time that your splash screen is displayed enables your application to complete additional startup tasks and display additional loading information. For example, your app might need to load resources from the network. You would extend your splash screen by retrieving the coordinates of the splash image in order to construct your own splash screen (which is the first view in your app) that mimics the default splash screen, but can also provide the user with additional loading information. Mimicking the default splash screen in this way ensures that your app is in full control of its loading process while also maintaining a clean, consistent, loading experience for users.
If you have entrance animations, detecting when the splash screen is dismissed lets you know when to begin your app’s entrance animations.
You have a number of surfaces you can use in your Metro style app, like the app window, pop-ups, dialogs, and bars. Choosing the right surface at the right time can mean the difference between an app that is a breeze to use or a burden.
The app window, or canvas
The app window, sometimes called the canvas, is the base of your UI. The canvas holds all of your content and controls. Whenever possible, you should integrate your UI elements into this base surface. For example, instead of using a pop-up to display an error, you can smoothly show, hide, or shift the error message on the window with the built-in animations. Presenting your UI inline lets users fully immerse themselves in your app and stay in context.
The app bar
Outside of the app window, the app bar is the primary command interface for your app. Use the app bar to present navigation, commands, and tools to users. The app bar is hidden by default and appears when users swipe a finger from the top or bottom edge of the screen. It covers the content of the app and can be dismissed by the user with an edge swipe, or by interacting with the app.
The charms bar
The charms bar presents a specific and consistent set of buttons to users in every app: search, share, connect, settings, and start. We believe these are core scenarios that every user wants to do in almost every app they use.
- SearchUsers can search for content located your app or in another app, and they can search your app’s content from another app.
- ShareUsers can share content from your app with people or services.
- ConnectUsers can connect to devices and send content, stream media, and print.
- SettingsUsers can configure your app to their preferences.
- Start Users can go directly to the Start screen.
The context menu, sometimes called a popup menu, shows actions that users can perform on text or UI elements in an app. You can use up to five commands on each content menu, like cut, copy, or open with. This limit keeps the context menu uncluttered, easy-to-read, and directly relevant to the text or object that the commands act on.
Don’t use context menus as the primary command interface for an app. That’s what the app bar is for.
Message dialogs are dialogs that require explicit user interaction. They dim the app window and demand a user response before continuing. Use message dialogs only when you intend to stop the user and to demand response.
In the example above, the app window is dimmed, and the user must tap one of the two buttons to dismiss the dialog. That is, the message in the dialog cannot be ignored.
Flyouts show temporary, dismissable UI related to what the user is currently doing. For example, you can use flyouts to ask the user to confirm an action, to show a drop-down menu from a button the app bar, or to show more details about an item. Flyouts are different from message dialogs in that you should show a flyout only in response to a user tap or click, and you should always dismiss the flyout when the user taps outside of it; you should show a message dialog only when you need to interrupt the user and demand some kind of interaction.
In the example above, the app stays active, and the user can tap the button or tap outside the flyout to dismiss it. That is, the message in the flyout can be ignored.
Toasts are notifications that you show to users when your app is in the background. Toasts are great at updating users with information they want to know in real-time, but it’s ok if they miss. Users tap on the toast to switch to your app and learn more.
Errors within an app can be communicated to the user through three main surfaces. The right surface for an error is chosen by the app developer based on the content and consequences of the error. See also Guidelines and checklist for error messaging.
To show: Use this surface: A non-critical error specific to an element in the app. Your app cannot fix the problem, but users can.User interaction: Users can continue to interact with the app, system components, and other apps without dismissing the error.
Example: The user enters an invalid string in a text box and then retypes it.
Text inline on the canvas· Text only
· Dismissed by app
· Appears inline near the source of the error
A non-critical error that applies to the whole app. Your app cannot fix the problem, but users can.User interaction: Users can continue to interact with the app, system components, and other apps without dismissing the error.
Example: Mail cannot sync at the moment.
Text at the top of the page· Text only
· Dismissed by app
· Appears at the top of the page
A significant but non-critical error that applies to the whole app and your app can suggest a solution.User interaction: Users can respond to your prompt or continue to interact with the app, system components, and other apps without dismissing the error. Error and warning bar· Text, two buttons
· Dismissed by user
· Appears near the top of the page
A critical error that applies to the whole app and prevents the user from using the app.User interaction: Users cannot continue interacting with the app unless they dismiss the error. Users can still interact with system components and use other apps. Message dialog· Text, 1 to 3 buttons, title (optional)
· Dismissed by user
· Appears centered across the app
Do not use flyouts, toasts, or custom UI surfacesto display errors.
Errors: Inline text
In general, the inline error is the first choice of surface. An inline text error delivers messages in the context of the user’s current actions or the current app page itself. An inline error does not require an explicit user action to dismiss the message. The message goes away automatically when it no longer applies.
Align the message with the control or element that the message relates to.
Lay out the message with ample surround space to increase its focal strength.
The following example shows an inline error message associated with a specific text box.
Include actions or commands in the message.
In the following example, an Error and Warning bar would be a better choice.
Errors: Error or warning bar
Use a Error or Warning bar to notify users of important errors and warnings and to encourage the user to take action. Error messages inform users that a problem occurred, explain why it happened, and provide a solution so users can fix the problem. Warning messages alert a user of a condition that might cause a problem in the future.
Position the bar at the top of the screen, encouraging the user to notice and take action.
Color the bar with a color from the app’s palette.
Use the same color and layout for all your error and warning bars.
Display bars with different colors or glyphs (such as a shield or exclamation point) based on perceived severity.
Use an ‘X’ glyph to close the bar; instead, use a labeled Close button.
Use an error and warning bar for information-only message.
The message in the example below is purely informational and no action is required. In this case, an inline message at the top of the screen should have been used.
Errors: Message dialogs
Use a message dialog only if a modal message is required, blocking the user from interacting with the app.
Use a message dialog if the user must take action before using the app any further.
The following example is an appropriate use of an error message dialog because users cannot use the app unless they have an active account.
Use a dialog if the user can ignore the message.
In the following example, there is nothing about the error that would require you to block users until they address it. An error or warning bar would have been a better choice.