2 Oct 2011

Summary of the talk on the Metro UI in Windows 8


This is a summary of Microsoft's excellent talk on the Metro UI in Windows 8.




Metro-style Design:

  • Metro is all about content, not chrome, and an immersive. Every pixel on screen is for content, and none for chrome, whether the app's or the OS's. Metro apps are full-screen all the time (except when the user snaps two apps together).
  • In particular, the touch version of IE 10 shows web pages full-screen. Microsoft expects this to provide a better browsing experience than the non-touch skin of IE 10, even when you're using a mouse and keyboard.
  • Text occupies a primary role in the Metro UI. It provides the structure of the app, rather than just being content poured within a structure created by other visual elements.
  • Whitespace is important -- it provides room for the UI to breathe, rather than having it all squeezed together.
  • Metro apps are highly consistent and use the same typographic grid. It's not jarring to switch from one app to another. The title is in the same place, with the same font, with the same padding on its side, etc.
  • Users swipe from the edges of the screen to reveal hidden UI.
  • The left and right edges are reserved by the OS. The left edge is to switch apps, and the right one is for "charms", like Start, Search, Share, etc. Your app can use these to search, share, etc.
  • The top and bottom edges do the same thing — reveal the app bar's hidden UI (called the app bar), overlaying the content. The edges of the screen are most convenient for users to reach with their fingers.
  • Put only the most commonly used controls on the canvas, like play in a music app. Put the others in the app bar. Don't worry that users are not going to discover these. They are, since it's consistent between apps.
  • Be great at doing only some things, rather than mediocre at doing many.



Fast and fluid:

  • Make the UI fast and fluid. No jerky movements. A fluid interface is one where everything comes from somewhere and goes somewhere.
  • Don't map touch gestures to mouse gestures, like press and hold -> right click. Design for the medium. To drag an icon from one screen to another, current touch systems behave as if you were dragging and dropping stuff using a mouse, by having the content scroll when you reach the edge of the screen. But if really design for touch, you expect to use another finger to scroll the content underneath.
  • Microsoft tried to reduce modes in the UI. To drag something, you don't have to enter a special drag mode, like with iOS — you just drag.
  • Zoom should not just magnify the same content -- it should show content at a summary or detail view suitable for the zoom level. For example, zoom out on the home screen, and the tiles become icons. Zoom out on a calendar and you see a month view. In other words, zoom should be semantic rather than optical. Users should also be able to act on the content differently at the new zoom level. For example, move whole home screens around rather than tiles within them.
  • You can slide a tile slightly downwards to select it. Again, you don't need to enter a mode to be able to select things.
  • Don't create a separate UI for mouse-and-keyboard — the same UI should work well in both modes. Standard controls do.



Snap & scale beautifully:

  • Apps can specify that they support only certain form factors, like 11.6 inches and above.
  • Windows 8 supports screens with different DPIs -- so should apps. In particular, you should provide vector art or, not as ideal, assets at three sizes: 1024 x 768 (the minimum Windows 8 supports), 1366x768+ (widescreen), a snapped view and, optionally, a portrait view.
  • Windows 8 is landscape-first (unlike the iPad, which requires apps to support both orientations). After all, landscape is required for laptop and desktop screens.
  • A snapped view should be the whole app and not a gadget kind of thing.



Use the right contracts:

  •  Similar to Intents in Android. Let two apps work together without each knowing the other.
  • The three important contracts are share, search and pick.
  • Share:
  • opens the chosen app in a side pane that disappears once the sharing is done, so you don't lose your context. 
  • Apps can identify themselves as being able to be the target of a share action for certain formats of data -- text, photos, etc. 
  • It's not just for social networks/email type apps -- meant for also a translator app, a notes app, a Read It later kind of app. It's not just sharing with people, but also with an app, like an image editor.
  • Search:
  • Searches opens its UI in the right pane and searches data from the current app, with suggestions (with photos). When the user taps a suggestion, that item appears in the main pane, in the app. 
  • In the right pane, the user can switch to another app to see results from that app. That way, you can search for something in multiple apps while moving fluidly between them. 
  • Not meant for "find in doc" -- use your own UI.
  • Picker:
  • lets you pick, say, a photo from a cloud service (or another computer on the LAN) just as conveniently as a local file. No more downloading a file to attach it to an email, and no more cluttered filesystem. 
  • similarly, if your app has content, you can implement the source part of the picker contract to let other apps use that content.
  • bottom-line for all contracts: Don't create an in-app UI to do what contracts can do.
  • The settings charm has a section at the bottom for system settings, and the area at the top is for app settings. Also put Help and About there. Don't build your own settings UI.



Invest in a great tile:

  • A tile is not an icon -- show content from the app.
  • Tiles create an emotional connection by showing the user their kids' photos, for example.
  • In some cases, users don't need to open the app to see the weather, for example.
  • Tiles have a single touch target -- no controls
  • You can choose from one of multiple templates -- not fully customizable. But there are almost 20 templates, so there's lots of flexibility.
  • Pick a template, and supply text and images, and the system handles the rest.
  • Tiles come in two sizes: small and an optional large tile.
  • You can pin a specific item from an app to the home screen, resulting in a deep link to that content within the app. Examples: a specific person from a social network app, a city from a weather app, a particular feed from a feed reader
  • In practice, as a user, you end up finning your favorite content from each of many apps -- the start screen becomes a kind of global dashboard for the things you care, across apps. Once you use this, everything else will feel antiquated.
  • It makes the start screen more personal, and lets people jump to the part of your app they care about, in addition to getting at-a-glance information from the start screen without opening your app.



Alive with activity:

  • Live tiles let you have a news app that actually shows the news on the start screen.
  • The idea is to make the OS alive with activity, the way the web is always changing, and unlike a desktop with static icons.
  • The start screen lets you put borders between groups of tiles. Like a folder, but it doesn't hide stuff in the hierarchy. You can name groups if you want to (we sometimes find it hard to come up with appropriate names for folders).
  • Tiles can show a number or glyph at the bottom-right corner, say to indicate the number of unread mails.
  • Tiles can also animate between two states, like a text and an image.



Notifications:

  • An app can put up a notification for urgent stuff, like calendar. Notifications slide in from the bottom-right of the screen.
  • Notifications appear no matter where the user is -- start screen or other apps.
  • There's no junk drawer for missed notifications. If it's important, update your tile.
  • Notifications remain on screen for only a short time. The user can throw them off screen, or turn off notifications per-app or globally.
  • Notifications also have templates, like tiles.
  • Require the user to opt-in before displaying notifications.


Live tiles and notifications can be updated:

  • when your app is running
  • at a scheduled time (alarm)
  • via push notifications. This is how apps like weather, news, Twitter update themselves constantly.



Roam to the cloud:

  • Your app is running only when it's visible on screen, and gets about 5 seconds to save its state before its process is suspended. Auto-save, don't prompt the user.
  • Most users login to Windows with a Windows Live ID. Doesn't have to mean Hotmail; could be Gmail via OpenID.
  • Every app gets space in the cloud for state, settings and a small amount of user data.
  • Use these to make it seamless for the user to move between devices. Sync the last listened to track, the last read page, or the level completed in a game.
  • OS settings are also synced.
  • If you want to sync more user data, you need to build your own service (easily) using Azure.



Metro Style Design Principles:

  • Pride in craftsmanship
  • Be fast and fluid
  • Authentically Digital
  • Do more with less
  • Win as one



Other:

  • Windows 8 natively supports multiple languages as first-class citizens: HTML/JS/CSS, C#, Visual Basic, and C++/C. You get tool support for all these languages.
  • The Visual Studio templates make it really easy to build a top-quality Metro app. Just configure a few properties and hook up the template to a data source.
  • The only way to kill apps is to go to the classic UI and open Task Manager.
  • Windows ships with a touch Dvorak keyboard
  • You can make more money making Windows apps than iOS apps, because of the reach of Windows.

No comments:

Post a Comment