From ce470e17fd4298c1b8aa9a5fd7493bde7a6be840 Mon Sep 17 00:00:00 2001
From: Peter Ng
The title introduces the content of your dialog. It can, for example, identify the name of a - setting that the user is about to change, or request a decision.
-Dialog content varies widely. For settings dialogs, a dialog may contain UI elements such as - sliders, text fields, checkboxes, or radio buttons that allow the user to change app or system - settings. In other cases, such as alerts, the content may consist solely of text that provides - further context for a user decision.
-Action buttons are typically Cancel and/or OK, with OK indicating the preferred or most likely - action. However, if the options consist of specific actions such as Close or Wait rather than - a confirmation or cancellation of the action described in the content, then all the buttons - should be active verbs. As a rule, the dismissive action of a dialog is always on the left - whereas the affirmative actions are on the right.
-The title introduces the content of your dialog. It can, for example, identify the name of a + setting that the user is about to change, or request a decision.
+Dialog content varies widely. For settings dialogs, a dialog may contain UI elements such as + sliders, text fields, checkboxes, or radio buttons that allow the user to change app or system + settings. In other cases, such as alerts, the content may consist solely of text that provides + further context for a user decision.
+Action buttons are typically Cancel and/or OK, with OK indicating the preferred or most likely action. However, if the options consist of specific actions such as Close or Wait rather than a confirmation or cancellation of the action described in the content, then all the buttons should be active verbs. Order actions following these rules:
+
diff --git a/docs/html/design/building-blocks/index.jd b/docs/html/design/building-blocks/index.jd
index d915aae51abf..e55477567915 100644
--- a/docs/html/design/building-blocks/index.jd
+++ b/docs/html/design/building-blocks/index.jd
@@ -11,7 +11,7 @@ footer.hide=1
#text-overlay {
position: absolute;
left: 0;
- top: 472px;
+ top: 520px;
width: 450px;
}
diff --git a/docs/html/design/building-blocks/tabs.jd b/docs/html/design/building-blocks/tabs.jd
index 19ed1c3ff135..8a2eb41455b5 100644
--- a/docs/html/design/building-blocks/tabs.jd
+++ b/docs/html/design/building-blocks/tabs.jd
@@ -6,6 +6,7 @@ page.title=Tabs
Tabs in the action bar make it easy to explore and switch between different views or functional aspects of your app, or to browse categorized data sets.
+For details on using gestures to move between tabs, see the Swipe Views pattern.
Fixed tabs display all items concurrently. To navigate to a different view, touch the tab.
+Fixed tabs display all items concurrently. To navigate to a different view, touch the tab, or swipe left or right.
Show the most important actions of your app in the actions section. Actions that don't fit in the -action bar are moved automatically to the action overflow. +action bar are moved automatically to the action overflow. Long-press on an icon to view the action's name.
@@ -144,15 +144,19 @@ content of a CAB in order to insert the actions you would like the user to be abFor more information, refer to the Selection pattern.
-If your app displays data in different views, the action bar has three different controls to allow users to switch between them: tabs, spinners, and drawers.
Tabs display app views concurrently and make it easy to explore and switch between them. Use tabs -if you expect your users to switch views frequently.
+Tabs display app views concurrently and make it easy to explore and switch between them. Tabs may be fixed, where all tabs are simultaneously displayed, or may scroll, allowing a larger number of views to be presented.
-There are two types of tabs: fixed and scrollable.
+Use tabs if:
+The detail view allows you to view and act on your data. The layout of the detail view depends on -the data type being displayed, and therefore differs widely among apps.
+The detail view allows you to view and act on your data. The layout of the detail view depends on the data type being displayed, and therefore differs widely among apps.
Consider the activities people will perform in the detail view and arrange the layout accordingly. -For immersive content, make use of the lights-out mode to allow for distraction-free viewing of -full-screen content.
- -
+Consider the activities people will perform in the detail view and arrange the layout accordingly.
-
Immersive content like media and games is best experienced full screen without distractions. But that doesn't mean you can't also offer actions on the content like sharing, commenting, or searching. If the user hasn't interacted with any of the controls after a short period of time, automatically fade away the action bar and all system UI affordances so the user can lean back and enjoy the content. We call this lights-out mode. Later, if the user wants to take some action, they can touch anywhere on the screen to exit lights-out mode and bring back the controls.
+ +
+ If your users are likely to want to look at multiple items in sequence, allow them to navigate between items from within the detail view. Use swipe views or other techniques, such as filmstrips, diff --git a/docs/html/design/patterns/multi-pane-layouts.jd b/docs/html/design/patterns/multi-pane-layouts.jd index 0e63e32e72e2..f752be257ac0 100644 --- a/docs/html/design/patterns/multi-pane-layouts.jd +++ b/docs/html/design/patterns/multi-pane-layouts.jd @@ -26,8 +26,8 @@ left pane. Make sure to keep the item in the left pane selected in order to esta relationship between the panels.
Screens should have the same functionality regardless of orientation. If you use a compound view in -one orientation, don't split it up when the user rotates the screen. There are several techniques +
Screens should strive to have the same functionality regardless of orientation. If you use a compound view in +one orientation, try not to split it up when the user rotates the screen. There are several techniques you can use to adjust the layout after orientation change while keeping functional parity intact.
After rotating the device, show the right pane in fullscreen view. Use the Up icon in the action bar -to show the left panel and allow navigation to a different email. Hide the left panel by touching -the content in the detail panel.
+If your screen cannot accommodate the compound view on rotation show the right pane in full screen view on rotation to portrait. Use the Up icon in action bar to show the parent screen.
Look for opportunities to consolidate your views into multi-panel compound views.
Make sure that your screens provide functional parity after the screen orientation +
Make sure that your screens try to provide functional parity after the screen orientation changes.
If a view contains content that exceeds the width of the screen (e.g. a wide Email message), make sure the user's initial swipes will scroll horizontally within the view. Once the end of the content is reached, an additional swipe should navigate to the next view. In addition, support the use of edge swipes to immediately navigate between views when content scrolls horizontally.
+Consider adding contextual information in your detail view that informs the user about the relative list position of the currently visible item.