UI/UX Guidelines
Becoming familiar with all the guidelines for Windows 8 users is an essential part of being a Windows 8 developer. If you violate certain conventions, your application cannot even be deployed via the Window Store.
Learning these guidelines and conventions will take you a while. You can find a launch page for the complete set of guidelines at http://bit.ly/Win8UXGuidelines. You should study those carefully.
To set the stage, though, here are a few of the most important concepts, particularly ones that are probably at significant variance from the applications you have written before.
Interaction between Your App and the Windows 8 OS
The earlier discussion of charms, app bar, and nav bar are part of the standard way apps are supposed to interact with the OS. So are contracts for Search and Share.
There are a number of other conventions in this general area of OS interaction. For example, your application should not have a Close button, or any equivalent functionality. A standard gesture is available to close an app. It can be done with either touch or mouse; while an app is open, start at the top of the screen, and drag toward the middle until you see the app shrink and center on the screen. Then continue dragging to the bottom, and the app will be closed.
Chromeless Apps
Windows 8 apps are “chromeless.” That simply means none of the border cosmetics in earlier versions of Windows are present. Windows 8 apps have no sizable borders, no title bar, and none of the buttons you associate with the title bar. The OS expects the user to focus most of the time on one application, and thus it is optimized to show one application on a clean surface.
The screens in an app are commonly called views. In older technologies, it was common for views to have buttons for operations such as Save. Views in Windows 8 apps should not have such buttons on the main view, because it's easy for them to be activated inadvertently during a touch operation. The app bar is the preferred location for any such buttons needed by your app, because it comes into view only when the user does the proper gesture to request it.
Snapped Views
Multiple apps are shown only via a “snapped” view, with a limit of two apps at a time. In a snapped view, one app gets a reduced slice of the screen that is 320 pixels wide. This view can be on either side of the screen. The rest of the screen, which is significantly bigger, hosts the other app. An example screen with a snapped view is shown in Figure 13.2.
Figure 13.2 Only two apps can share the Windows 8 screen at a time. One app is in a “snapped view” which is 320 pixels wide. The other app takes up the remaining screen space.
Windows 8 furnishes a mouse or touch gesture to make an app snapped. It's similar to the close gesture just discussed. With an app open in full screen, drag from the middle top until the app shrinks and centers in the screen. Then, instead of dragging to the bottom as you do with a close, drag to either side to make the app snap to that side.
To pass certification for placement in the Windows Store, your app is required to support a snapped view. It is up to you to design an appropriate view for when your app is snapped. In the case of the Music player shown in Figure 13.2, the designer decided to show a sparse vertical view of the music being played, with some minimal controls. Some applications merely place status information in the snapped view.
Typeface and Font Guidelines
Windows 8 has a standard set of typefaces you are supposed to use in your apps. The most commonly used typeface is Segoe, an elegant sans serif typeface. It's nicer than the typical fonts such as Arial that many applications use today, and there's no reason to change it for line-of-business applications.
If you application has a lot of content to be read and/or edited, you are expected to take advantage of two other standard typefaces. For parts of an application where the user would be reading and editing, such a detailed product description or an email message, you should use Calibri. For apps that are primarily intended for reading, such as a newsreader app, content should be in Cambria.
The Windows 8 UX guidelines include recommendations about using particular font sizes and weights. You should become familiar with those and use them unless you have a very good reason not to do so.
Sizing and Layout of Visual Elements in an App
In earlier XAML platforms, you were on your own to decide sizing of elements. For apps in Windows XAML, however, you need to try to be consistent with the conventions for screen layout in Windows 8 apps.
Most sizing of items, such as data items in a list, should be based on the “grid system,” in which blocks of 20∞20 pixels for the basis for a number of larger sizes. Spacer areas are often 10 pixels wide or high. The built-in application templates can give you a push in that direction. They include some sample data templates that are sized according to the Windows 8 guidelines. You'll see the list of templates and sizes in the section on Windows 8 Application Templates below.
You also need to provide appropriately sized header areas and margins. These can vary to suit the type of touch navigation that is being used.
The UX guidelines give precise details and recommendations, but you'll look at one typical case. Suppose you wanted a view with a list of items on the left side of the screen, and you intended the list to scroll vertically. Such a view might provide a header area that was 100 pixels high, and provide a margin on the left of 120 pixels. In fact, you will use those numbers in the first ListView example later in the chapter, because it does vertical scrolling.
The topics above only furnish a starting point for user experience guidelines. You should invest time to become familiar with the entire set. Remember, some of the user experience guidelines are required for your app to be certified in the Windows Store, which is discussed in Chapter 20.