As you might have noticed, the access to the Windows Store is granted after a complete check of your application(s). As the user experience is completely merged within the validation process, let’s have a look to the points you must take into account before reaching the shelves of the Windows Store :

 

Avoid the “Must Fix” lines in the submission report in 15 lessons.

1/ Your app must offers a specific and valuable experience, something unique. As itself, and with the new capabilities of the Windows operating systems, you can leverage new opportunities. And you cannot simply deal with an I pad conversion to do it the right way. Try to embrace the Modern UI guidelines to break in for a special added value. Planning Windows Store apps

 2/ In the same way, your app must not be a copy of the existing website. If you have a website, this is fine. But try to figure out all of the added value of a Windows App, using specific scenarios ! Planning Windows Store apps.

3/ After installation, your app must have a tile, displayed on the Start Menu. The icon or the image of the tile must be directly related to the content of the app itself. No adds in there. You should not use more than five messages in case of a dynamic tile set. And the best use of an image Inside a tile is to refer directly to the first item of your application. JavaScript and HTML or C#/VB/C++ and XAML.

4/ The tile must use a standard Template. And you have plenty of these, especially when you want a complete tile set for you app (dynamic-large, small dynamic, small still one, etc.). JavaScript and HTML or C#/VB/C++ and XAML.

5/ No advertisement in the controls (tile, app bar, navbar, settings bar, …nor into controls affected by the sweep-from-the-edge scenario. To avoid the audience to mismatch the system part and the content part of your app. All that can be related to the OS must not be used as a support for adds. only your content. Advertising Guidelines.

6/ No compromise! You app must be usable with the touch input or with the mouse/keyboard classic set of controllers. Because a touch experience is fine and modern, and because most of your users do not have a touch screen yet. JavaScript and HTML or C#/VB/C++ and XAML.

7/ Do not try to re-invent everything. Your app must use the Windows touch gesture defined here. This way, you know that people already comfortable with the Windows standards will use with the same ease your application. Touch patterns.

8/ Same thing for the use of the mouse. Nothing special here. See that topic for more : Responding to mouse interactions (JavaScript and HTML or C#/VB/C++ and XAML).

9/ All the interactive elements of your app must provide visual feedbacks. The complete set. On the opposite, the non-interactive things must not provide feedbacks to provide a strong and clear interaction scheme. Touch patterns.

10/ The app must support the snap view mode. Even if there is no specific scenario bound to that layout. You surely don 't want the user to get into a crash while he is trying to snap its app, don’t you ? And are you sure that there is not a valuable scenario for the snap mode? Guidelines for snapped and fill views

11/ In landscape mode, you have to take care of the usability of the app. Il must be fully accessible in this mode. Guidelines for scaling to screens.

12/ Your app must not close itself programmatically or propose a specific button or action to close itself. First of all, the app are not supposed to be closed no more in Windows 8. On a second hand, the system proposes a specific gesture if the user choose to kill your app. Guidelines for app suspend and resume.

13/ Speaking about task switching, your app must “wake up” or resume in a appropriate state (not crashed, of course, or with a comprehensive message if the  data bound to the screen are no more accessible – with the ability to get back to a safe state by pressing the back button).

14/ If your app uses a app or a nav bar, you must implement a “swipe-form-the-edge” (bottom up or top down) scenario. For convenience and discoverability, you can show the app bar when a page load, but you can then hide it on a touch gesture an turn it back on using a bottom up gesture.

15/ Your app can take great advantages of the notifications, badges, and specific system settings, but you have to make it perfectly usable when working without all of those options. Remember, it is the user’s choice to enable/disable the notifications.

 

 

   

How to avoid a “Shall fix” statement in…well…15 bullet points too…

There are so much guidelines for this section that I could write here for hours. I will try to stay close to the major lines and avoid all the unnecessary stuff.

1/ Your app should be more than a website in a web view. Create original content for an original experience that will let your user feels unique. Planning Windows Store apps, Navigation patterns

2/ The hub page (if you use one, obviously) must convey something more than just a navigation trick, with only links to other pages. Design that hub to bring original, refreshed and useful content. Navigation patterns.

3/ The grid is the law. Create your own grid to convey relative importance to the items you are displaying. Align that grid to the identity and the look and feel of your app. But do use a grid ! Moreover, use a consistent scheme to allow a continuous experience throughout the entire set of pages of your app. Laying out an app page.

4/ Avoid freeform panning and always prefer a “one-way-scroll” control for your content. Your user will have a consistent rail to read the content of the app. JavaScript and HTML or C#/VB/C++ and XAML).

5/ If you have to embed in your app a i-frame (web content) containing stuff that do not directly refers to the app goals, you should rather use a link to an external web browser. Quickstart: Using single-page navigation.

6/ And if you must, after all, place web contents in your layout, create a custom CSS so that the i-frame will look like the rest of your application. Laying out an app page

7/ Your application should have a splashscreen, and eventually a animated one (see Skype). The splashscreen is not a tile. It should not show refreshed content. It’s only here for branding. Guidelines and checklist for splash screens.

8/ If your app uses an App bar, that control must not contains navigation actions. Only page actions or contextual purposes. By the way, this bar must close when the user tap into the layout, and be recalled by a” swipe from the edge” action.(JavaScript and HTML or C#/VB/C++ and XAML).

9/ No modal dialog boxes for contextual usages. You should rather use a contextual flyout (from the Appbar) or a context menu (from the navigation bar). (JavaScript and HTML or C#/VB/C++ and XAML).

10/ Error messages should be displayed inline (near the error location). If you’re using a message box to show a error message, it means that this error is for the entire application. No stack trace or debug informations here. Users simply don’t care.Guidelines and checklist for message dialogs.

11/ Sorting and filtering content are actions. They must open from an app bar button, and open close to that button. Sorting and filetring are not a navigation gimmick. Navigation creates an history within the app, with specific paths (and specific back button actions). Filtering is an action. Navigation patterns, Guidelines and checklist for flyouts.

12/ If your app requires commands to navigate into, like a specific “call-to- action” button, or a “step-by-step” procedure, then the “call-to –action” button should be placed into the canvas. (JavaScript and HTML or C#/VB/C++ and XAML).

13/ Touch target must be at least 5 mm large. Remember that the finger is a 40x40 pixels wide area. Always try to overestimate the size of touchable items and leave enough surrounding place to avoid missed-touch-frustrating-state (10 or more pixels). Guidelines for targeting.

14/ The layout of your app should have a flexible layout. With that approach, the content of your app should reflow when you switch to a bigger or a smaller display. Use smart controls to wrap the content to the Y dimension of the screen. This way, it will take less swipe actions to reach far content, as the display will drop to higher resolutions. Guidelines for scaling to screens.

15/ The snap view is an user scenario. The app must not snap nor unsnap programmatically, or without the user allowance. If your app can not displays its content in snap mode, you should indicate the option to get back to full screen with a button. Guidelines for snapped and fill views.

16/ Not enough room, and so much more things to say, so, let’s break the 15 rules canvas : You should not duplicate buttons or actions that are laid down elsewhere. For example, do not try to mimic the search contract by placing an search icon in the layout. Otherwise, you can take advantage of a auto-type scenario: when the user start typing something, open the search contract. Commanding patterns.

17/ Search is not the same action as find. Search means looking out for something in the application. Find means searching inside a page. If you need to embed a “find” action, then place it in the App bar. (JavaScript and HTML or C#/VB/C++ and XAML).

18/ If your app can share it’s content only from a specific spot, you should avoid the “This app can’t share” message in the other pages. Try to re-think the message (this app has nothing to share in this page). Guidelines for sharing content.

19/ The secondary tile scenario must provide only dynamic content and must not be used to interact within the app. This kind of tile is only designed to get quickly to a specific content within your app. Of course, that tile should lead to its related content and not to the hub or to a section page.Guidelines and checklist for secondary tiles.

20/ Toast notifications are there for important messages, not for adds, not for minor messages, not for errors. The notifications are a usable way to go directly to the breaking news… Guidelines and checklist for toast notifications.

21/ If your app requires a web authentication (especially for on-line sellers), well, use a web authentication. Pretty straightforward, isn’t it? Web authentication broker.

22/ I should consider to end this blog post. For silhouette matters, there are two ways to think your design. On one hand, you design with the standard design guidelines. Fine. So play the entire game and follow all the rules. On the other hand, you want to define a specific design on your own. Fine too. But be consistent to provide a strong experience to your users. Laying out an app page.

23/  Whatever the font you are using for your app, try to ramp it to only five size. Guidelines for typography.

24/ The semantic zoom is a fantastic option. Try to leverage the app scenario so that the SZ conveys a terrific user experience. Bring something more than just replicate the native view with another Template.

25/ It’s not a nasty stuff to allow the user to use its keyboard to navigate through the app, even if the core experience is touch-oriented. And it’s a great idea to support the roll-over animations for the mouse .

26/ Your app should support the portrait mode. it is a very good way to read books or news feeds, for instance.Guidelines for layouts.

 

And we’re done here with, hum, 26+15 rules. If all those rules are checked prior to send your app for submission, then you should relax, have a beer and wait to see your logo in the Windows Store !