MICROSOFT_PRESS_EBOOK_PROGRAMMING_WINDOWS_8_APPS_WITH_HTML_CSS_AND_JAVASCRIPT_PDF

A common group of settings are those that allow the user to configure their roaming
experience—that is, a group of settings that determine what state is roamed (you see this on PC Settings
> Sync Your Settings). It is also recommended that you include account/profile management
commands within Settings, as well as login/logout functionality. As noted in Chapter 7, logins and
license agreements that are necessary to run the app at all should be shown upon launch. For ongoing
login-related functions, and to review license agreements and such, create the necessary commands
and panes within Settings. Refer to Guidelines and checklist for login controls for more information on
this subject. Guidelines for a Help command can also be found on Adding app help.
Behaviorally, settings panes are light-dismiss but also have a header with a back button to return to
the primary settings pane with all the commands. Because of the light-dismiss behavior, changing a
setting on a pane applies the setting immediately: there is no OK or Apply button or other such UI. If the
user wants to revert a change, she should just restore the original setting.
For this reason it’s a good idea to use simple controls that are easy to switch back, rather than
complex sets of controls that would be difficult to undo. The recommendation is to use toggle switches
for on/off values (rather than check boxes), a button to apply an action (but without closing the settings
UI), hyperlinks (to open the browser), text input boxes (which should be set to the appropriate type such
as email address, password, etc.), radio buttons for groups of up to five mutually exclusive items, and a
listbox (select) control for four to six text-only items.
In all your settings, think in terms of “less is more.” Avoid having all kinds of different settings,
because if the user is never going to find them, you probably don’t need to surface them in the first
place! Also, while a settings pane can scroll vertically, try to limit the overall size such that the user has to
pan down only once or twice, if at all.
Some other things to avoid with Settings:
• Don’t use Settings for workflow-related commands. Those belong on the app bar or on the app
canvas, as discussed in Chapter 7.
• Don’t use a top-level command in the Settings pane to perform an action other than linking to
another app (like the browser). That is, top-level commands should never execute an action
within the app.
• Don’t use settings commands to navigate within the app.
• Don’t use WinJS.UI.SettingsFlyout as a general-purpose control.
And on that note, let’s now look at the steps to use Settings and the SettingsFlyout properly!
Populating Commands
The first part of working with Settings is to provide your specific commands when the Settings charm is
invoked. Unlike app bar commands, these should always be the same no matter the state of the app; if
you have context-sensitive settings, place commands for those in the app bar.
336