Metro Style apps vs desktop applications

At the Build conference in September, Jensen Harris, director of program management for the Windows User Experience team, gave an inspirational talk on the “Eight Traits of Great Metro Style Apps”.

He outlined the way developers should think about the new Metro Style apps and how these differ from traditional desktop apps.

The change is radical: Metro Style apps are designed to do only one task – well. They can interact with other apps without any explicit knowledge about them, and prioritise content before everything else. Although they’re “touch first”, they still work well with mouse and keyboard.

The Metro design rules are still under development, but they’re enshrined in a set of templates for Visual Studio 11, a preview build of which was released at the conference.

Metro Style apps should look so similar to each other, and to Windows 8 itself, that users see no difference in look and feel between the OS and apps

Metro Style design is more than just good typography, although that lies at the heart of it; it’s also about creating a harmonious user experience between different applications. Metro Style apps should look so similar to each other, and to Windows 8 itself, that users see no difference in look and feel between the OS and apps.

The apps should add new functions to Windows, and distinguish themselves by how they work, rather than how they look. Indeed, most of the time the app will be invisible, since all of its “chrome” (buttons, sliders, scroll bars and so on) won’t appear on screen – only the content.

All buttons, widgets, doodads and controls will be relegated to the App Bar (accessed by swiping your finger up from the bottom of the screen) or under the “Charms” for settings, search and so on, which are accessed by a swipe from the right-hand edge of the screen. If an app needs lots of controls then it won’t fit well with Metro, and should be written as a standard desktop application.

You’re unlikely to see Metro Style versions of Visual Studio, Photoshop or Word since they’re too complex, although you may well see a Metro Style “word reader” without editing abilities.

App bar

The App Bar contains most of the commands for an app, and remains hidden most of the time, although if a command is central to operating the app – such as the Play button for a media player – then Microsoft says it’s okay to keep it onscreen all the time.

Apps settings live under the Settings Charm, but most of its other commands would live on the App Bar. Windows Phone 7 employs an App Bar with room for only five buttons, but Windows 8 will provide more room. However, you’ll still be hard-pushed to fit in more than about 12 buttons.

You’re encouraged to group these buttons to the left and right, avoiding the middle of the App Bar where possible, because it’s easier to reach the left and right with two thumbs without changing your grip on a tablet. (Microsoft tested this by getting people to finger-paint while holding prototype devices.)

The App Bar buttons themselves are widely spaced, making them finger-friendly, but they’re only monochrome symbols in circles with small text captions beneath.

I’ve stared hard at the icons for some sample apps and can’t always work out what they’re meant to suggest; I can’t help feeling that moving from 32 x 32 full-colour icons with alpha-blending on ribbon buttons to these tiny, monochrome squiggles is a huge step backwards.

I am convinced, however, that animation is utterly necessary for Metro Style apps. Modern, hardware-accelerated displays enable you to see buttons depressing, and items entering or leaving lists in real-time, and without such animated cues you can miss that a command has been executed; lack of feedback may lead you to press the button again out of frustration.