Question: Is it possible to change the length of time a toast is displayed different from the ~7 second default?

Answer: Not programmatically. Toast display time is user-controlled via PC Settings > Ease of Access > Other Options > “Show notifications for” (for Windows 8.1; leave out Other Options on Windows 8). It’s one place where the user is in control, because different users respond at widely different speeds. You cannot assume that 2 seconds, for example, is long enough. A user might have difficulty reading, for example, or might have difficulty placing a mouse cursor or touching the screen fast enough to respond to the toast (think of a paralyzed user who is tapping keys with a mouth rod).

The shortest it can be set is 5 seconds, the longest 5 minutes. If you have some UX requirement that requires a shorter time (e.g. you’re trying to display short transient messages within a running app), then you should think about a different mechanism such as one using in-app flyouts.

For this post, let’s focus on section 3.5 of the requirements:

3.5 Your app must fully support touch input, and fully support keyboard and mouse input

Your app must provide visual feedback when users touch interactive elements.

Your app must not use an interaction gesture in a way that is different from how Windows uses the gesture. The Windows 8 touch language is described in Touch interaction design.

There are a number of things going on here that are worth thinking about more carefully.

The first sentence basically says that the app has to support multiple input modalities. To “fully support touch input” means that the app must be fully usable with only touch, which should be obvious given the increasing number of touch-only devices. This means that an app cannot have UI or features that are only accessible through a mouse or through a special keystroke. Usually this isn’t much of an issue, because using pointer events lets you handle touch and mouse with the same bit of code anyway.

The second half of the scentence is a little sketchy to my mind. Depending on how you read it, it might say “the app must be fully usable with only keyboard, as well as with only mouse,” or it can be read that “the app must be fully usable with keyboard and mouse together.” From what I’ve seen, certification makes the latter interpretation.

At the same time, I strongly encourage developers to provide complete keyboard-only interfaces as well as mouse-only interfaces. In doing so, you make the app much more accessible for people with disabilities. That’s really the reason why the UI guidelines for desktop apps that have been around for many years suggests things like keyboard accelerators for menus that can also be used with a mouse.

In this context I often think of a classmate of mine within the Electrical/Computer Engineering department at the University of Washington when I was an undergraduate there. Sometime in our senior year, he severed his spinal cord in a skiing accident and became a quadraplegic. But he still completed his degree, often using a computer keyboard with a rod that he held in his mouth. To this day I admire his determination to carry on despite his permanent injury, which means making a little extra effort of support full keyboard interactions and not rely on the mouse for some of it.

Anyway, the last two sentences of section 3.5 above apply only to touch interaction, and are pretty clear. The visual feedback requirement is important because it lets the user know that the app has detected the touch–a piece of glass, in other words, doesn’t give the tactile response that a keyboard or mouse does, so the acknwoledgement of input has to be visual. For this, the pointer down and pointer up animations in the animations libraries provide standard visual responses.

As for gestures, the point here is to avoid forcing users to retrain themselves for the sake of your app, which ultimately lowers their efficiency across the rest of the system. It’s a reminder that your app is not the only one running on the device, so be a good, cooperative player and avoid “innovating” in places like input where you’ll just cause confusion.

The last thing I’ll add regarding input is not part of Store ceritification, but also good to think about: sensors. As I wrote in my book, I like to think of sensors as another form of input, one that is a fresh area that’s open to all kinds of innovation. And because there’s nothing in Store certification related to how you use inclinometer, the compass, gyros, etc., you can be very creative here!

When implementing Accessibility support in an app, it's very important to be sensitive to the contrast in images. As I wrote in Chapter 17 of my book:

Technically speaking, high contrast is defined by the W3C as a minimum luminosity ratio of 4.5 to 1. A full explanation including how to measure this ratio can be found on A Contrast Analyzer (from the Paciello Group) is also available to check your images (some of mine in Here My Am! failed the test). Do note, however, that creating high contrast graphics isn’t required for non-informational content such as logos and decorative graphics. At the same time, full-color graphics might look out of place in a high contrast mode, so be sure to evaluate your entire end-to-end user experience under such conditions.

The contrast ratio is what you need when you want to make high-contrast graphics that are still in color–this is what I had to do with the Here My Am! graphics. The original ones I received from Microsoft Press, which I use for "standard" contrast, look like this:


Running the two colors (#FFFFFF and #00B294) here through the contrast analyzer, I'm told that it's ratio is only 2.69:1. So in a graphics editor (I use the free Paint.NET), I tweaked the Value portion of the HSV to proportionally darken the teal color down to #005C36 which gives an 8.13:1 ratio:


This is well beyond the 4.5:1 ratio, and passes all the test of the Contrast Analyzer. (I could have used #00663B which is a touch brighter and passes at 7.09:1). I use this as the high contrast image (color).

Then I needed to make black on white and white on black variants. The easy way to do this in Paint.NET was to first convert to grayscale, then use the Levels adjustment. For black on white, I converted the original (standard contrast) image to grayscale and inverted the colors:


Then I used the Adjustments > Levels command to set the input levels at 0 and 128 with outputs at 0, 1.0, and 255:



This created black on white (light border added):


After this, another Adjustments > Invert Colors command produced the white on black: