Major UI Themes in Windows 8
The motto for Windows 8 is “Content before Chrome”. This marks the first version of Windows where the entire screen is dedicated to the content that applications want to display. By default there are no window frames, menus, or toolbars. Application-wide features such as settings are hidden within an “application bar” that slides into view when the user needs it.
It is import to stress that every pixel is dedicated to the running application. Under the metro design there is no clock, taskbar, or notification tray. Whichever application is running gets the full screen by default or half the screen if the user wishes to see two at the same time.
The standard chrome is replaced by edge gestures. The left edge of the screen is used as a back button, it is usually used to return to the previous application. The right edge opens the “charms” menu, which contains application and system plug-ins such as search and share. Both the top and bottom edge contain the aforementioned application bar.
Most Metro style applications will start with the “Grid Application” layout. In a grid application the first view of the application is the content laid out in boxes. With this style of application there is no internal chrome, all interaction is done against the content itself.
Fast and Fluid
Performance is a serious concern with touch-based applications. Unlike the mouse, which has a bit of indirection to distract the user, touch based applications must respond immediately to any interaction.
Windows 8 includes a set of system animations. The animation library is available out of the box in most controls with little or no development work.
Windows 8 will introduce a new touch language. It will have a limited number of gestures, but all applications will be expected to support them. Multi-touch is essential in this model, users will expect to pick up an item with one finger and scroll the screen with another. This is a major break from mouse-based interactions which assume only one thing is being manipulated at a time.
Modal and time-delayed input is being down-played in Windows 8. For example, to select an item one slides their finger across it. There is no need to press-and-hold or switch to checkbox mode.
To navigate through the application a key concept is semantic zoom. As you zoom in and out the UI doesn’t just change size, it changes what is being shown. Zooming in on a calendar application will open a day and then a specific appointment. Zooming out may take the user to a week view and then a month view.
In Metro applications all applications need to support touch and mouse equally in the same user interface. Users will be using a mixture of touch, mouse, and keyboard depending on where they are and which device they happen to be using at the moment. Microsoft assumes that all desktop PCs will have touch screens while even the smallest tablet may have a docking station with mouse and keyboard. To make this easier there is some built-in support for common mouse functionality. An example of this is right-clicking, which will open the application bar and other contextual commands.
The baseline size that all applications need to support is 1024x768. This is the minimum screen size that Windows 8 will support so no application needs to work at a smaller resolution.
The next size applications need to support is widescreen, which is 1366x768. Generally speaking this won’t be very different from the baseline size. Screens must be at least this wide to support the next mode, snap view.
All applications are required to support a snap view. Though only 320 pixels wide, this must show everything that the user would expect from your application. Users also need to be able to smoothly move from standard and snap mode without losing their place.
Portrait mode is optional. Microsoft decided not to require this because most desktop and laptop computers don’t support turning the screen on the side. Still, most applications would benefit from this.
Contracts and Application Integration
Another major theme of Windows 8 is application integration. The operating system will expose a set of contracts for common functionality such as “search” and “share”.
Every application should implement the source side of the share contract. This allows it to send information to other applications in a quick and easy fashion. Share doesn’t just mean email and Twitter; the target of a share may be a translator, a note taking application, or anything else that you would otherwise paste information into. By implementing the source contract, an application automatically becomes compatible with all share targets.
Another contract that applications may be interested in search. After typing in a query in the “search charm”, the user touches the application and it is given some screen space to show its results. Since the list of applications stays visible users can quickly switch from one set of search results to another.
The search contract is not for internal searching such as a PDF reader’s find dialog. It is meant for applications that would need a top level search page anyways. A good example of something that needs search is a recipe app or a wrapper for Wikipedia. Utility applications would generally would not implement the search contract.
The picker contract allows applications and services to share data. Instead of having to download files and save them to the hard drive, one application can directly request data from another application. Unlike today where each application needs to implement the web services to call every service, the picker contract is agnostic. If your application supports the picker it can receive data from any picker source that the user happens to have installed.
Tiles are not icons; they are supposed to be an extension of the application. They should give the impression that the application is always running even when it isn’t. The goal is to invoke a emotional response from the user by showing them the information that is relevant to them. Personal application would show images from their photo gallery while a financial application may show a stock ticker from their portfolio.
Tiles are not gadgets; they have a single touch point. In order to ensure consistency the tiles are templated. While there are templates that allow full control, most applications will simply provide text and images that Windows will layout.
Tiles can support the idea of “peek” where they scroll up and down to show both text and images. The amount of scroll isn’t very much,
Notifications can appear at any time on top of any application. Users can ignore the message, open it, or slide it off the screen. Users can also disable notifications globally, so it is important to not rely on it.
Also note that there is no “junk drawer” for unseen notifications, users only get one chance to see it. If it is important that the user be able to see missed notifications then the application should update its live tile accordingly.
Applications can subscribe to push notifications. This is what allows Windows to update an application’s live tile even when the application isn’t running. It is important to understand that applications are only running when they are physically visible on the screen, so this is often the only way to keep the application responsive.
Metro applications are expected to use roaming settings. Once an application is configured on one device it should stay configured no matter which device the user happens to use next. The user’s Windows Live account will handle the back-end infrastructure for syncing the settings between machines.
No Explicit Saves
When switching between applications, Metro apps only have about five seconds to do something before they are suspended. Thus it is essential that applications are constantly saving their state. Rather than offer a save button, applications need to expose ways to undo actions.
Ideally a user should be able to alter some data with one device, pick up another device, and instantly see their changes. Everything from important business information to the save file for game is expected to work in this fashion.