If you have other thoughts, please add them in the comments!
First are those requirements that come from the Store policies themselves. All of the requirements are important, of course, but the following are those that apply especially to converted web apps:
- Section 2 is a key consideration: “Windows Store apps can display ads but are more than just ads or websites.” This means, especially section 2.4, that you can’t be a link farm that opens the browser all the time, and that you can’t just repackage a website wholesale into an app and expect it to pass certification. However, pulling web content into the context of the app, where the user can see that they’re in the app, is just fine.
- Also skip down to section 5 of the requirements that deal with content (as well as age ratings). Some content will not be accepted into the Store at all, so if your web app deals with such, it’s not a good app candidate.
- The app must support touch input (section 3.5 of Store policy). Much of this comes for free, as touch events are automatically translated to legacy mouse events as web apps typically listen for. Nevertheless, you have to make sure the app is fully functional on a touch-only device. Note that requirement 3.5 also says “Your app must not use an interaction gesture in a way that’s different from how Windows uses the gesture.” Make sure to revisit any custom gesture work.
- Note that this requirement also says “Your app must provide visual feedback when user touch interactive elements.”
- Typically, web apps being converted to Store apps also need a little work to make links and other clickable content large enough to work with touch. This often just means increasing the spacing around multiple interactive elements that are otherwise too close together.
- View states: the app needs to handle snapped, filled, landscape, and portrait modes (requirement 3.6). Technically, the policy only speaks to snapped view (as a specific point of rejection), but really, aim to make an app that looks good in any view state.
- Honor process lifetime states of suspend and resume, and have no close affordances in the app (requirement 3.6–typically not something a web app ever has anyway). It’s important for apps that use online content to refresh that content if necessary when the app is resumed, as it may have been suspended for a long time.
- Requirement 3.9 says, “All app logic must originate from, and reside in, your app package.” Specifically, any code that interacts with the WinRT APIs has to be in the package and cannot be downloaded from a remote source. This means any libraries you use in the main app (the local context) must be bundled in the package (along with whatever those libraries depend upon). Parts of the app that use the web context are allowed to access remote script, as the web context cannot access WinRT. Avoid downloading such script and passing it between contexts to execute/eval it in the local context. This opens security holes and is a basis for rejection.
- Related to this is the fact that the local context also disallows script injection, e.g. via innerHTML attributes, and imposes other security constraints within the app container. This can affect third party libraries.
- The underlying purpose of this requirement is security more than anything, that is, to avoid having potentially untrusted code execute in the local context where it could possibly do some damage. Admittedly, this is a gray area. Clearly, something like a magazine, book, or other multimedia content is not “app logic” and can certainly be downloaded, processed, and displayed in an app. Definitions for new levels of a game fall into that same bucket, even though such configurations might ultimately drive how the app code executes. Downloading a program or script in some other language, on the other hand, that then runs as an app inside your app, will cause rejection. In the end, I think this is primarily about the difference between data that’s rendered visually and instructional code or script that drives execution. Still, it’s a gray area to me, so I think we’ll see further refinements of this policy as new kinds of apps are developed.
- Protect against large transfers on a metered network (requirement 4.5)
- Be mindful of age ratings (requirement 5.1 and 6.2). This isn’t something you deal with on the web, but is required when submitting an app to the Store.
Store requirements are, of course, the min-bar for Store submission and certification. To be a good app on the platform, however–which means creating an app that Windows users will actually want to install!–you’ll need to go beyond those basics. The following, then, represents the core of platform integration:
- Horizontal orientation: although web apps are typically designed for a vertically-scrolling experience, the design of Windows Store apps are primarily horizontal (except in snapped view). This may affect your app’s interaction model significantly, but is what users will expect.
- View states: again, support all the view states, not just landscape and snapped as required by policy.
- Handle resolution scales well, both varying display sizes (what we call responsive design in the web world) and different pixel densities. The latter means having raster graphics that work well on 100%, 140%, and 180% scaled devices.
- Beyond suspend/resume (as required by policy), the app should be able to be terminated while suspended and then restart where it left off. This means saving transient session state and being able to rehydrate the app from that state.
- For any commands that are not essential to completing a workflow, move those commands/controls off the app canvas and into flyout controls like the app bar, settings panels, and the Search and Share charms. There are many guidelines for this found on Commanding design.
- Note that it’s OK to leave some search and sharing functions directly in the app; just think about how to also integrate with the charms.
- Move app settings into Settings charm along with logins and profile management. You can have some on-canvas login/user controls, of course, but use Settings for additional features rather than separate app pages.
- Minimize chrome (non-functional UI elements), which happens automatically when you move commands off-canvas, but also means using layout and typography to group functionality rather than lines, boxes, and so forth.
- Migrate from <a href> navigation to a single-page model with DOM replacement. This will greatly simplify managing state in the app, although you can transfer state in other existing ways. It’s just much easier to not have a new script context with every page.
- Have great branding graphics including tiles, splash screen, Store logo, etc.
Beyond that, some additional considerations will take the app to the next level:
- Handle variations in network connectivity or lack thereof. On the web, you assume connectivity because the app has to be loaded into a browser from the web. An app exists on the client, however, and can be run without connectivity. So think about your offline behavior and caching strategies.
- Live tiles: what can you surface on the tile more than your logo?
- Roaming experience—what settings transfer to the user’s other devices when they have the same app installed?
- Localization (depending on your target markets)
- Good use of progress indicators when transitioning pages. In browsers, users come to depend on the browser’s indicators about page loading. In a Store app, you need to indicate such states yourself, and implement strategies to minimize wait times and increase responsiveness.
- Honing performance especially if using collection controls.
Your thoughts and/or experiences?