From cd7e7dc423cba2d5efaab3e59a3995325d2d0b19 Mon Sep 17 00:00:00 2001 From: Dirk Dougherty Date: Tue, 5 May 2015 22:27:48 -0700 Subject: Doc change: remove design content that has moved to material spec. Change-Id: I335e3386633ae1e95891980b225885f5fed219b0 --- docs/html/design/building-blocks/buttons.jd | 99 ---- docs/html/design/building-blocks/dialogs.jd | 186 ------- docs/html/design/building-blocks/grid-lists.jd | 96 ---- docs/html/design/building-blocks/index.jd | 30 - docs/html/design/building-blocks/lists.jd | 56 -- docs/html/design/building-blocks/pickers.jd | 40 -- docs/html/design/building-blocks/progress.jd | 105 ---- docs/html/design/building-blocks/scrolling.jd | 39 -- docs/html/design/building-blocks/seek-bars.jd | 45 -- docs/html/design/building-blocks/spinners.jd | 54 -- docs/html/design/building-blocks/switches.jd | 64 --- docs/html/design/building-blocks/tabs.jd | 65 --- docs/html/design/building-blocks/text-fields.jd | 88 --- docs/html/design/design_toc.cs | 59 +- docs/html/design/downloads/index.jd | 187 +------ docs/html/design/get-started/creative-vision.jd | 7 +- docs/html/design/index.jd | 15 +- docs/html/design/patterns/gestures.jd | 135 ----- docs/html/design/patterns/index.jd | 30 - docs/html/design/patterns/multi-pane-layouts.jd | 130 ----- docs/html/design/patterns/navigation-drawer.jd | 346 ------------ docs/html/design/patterns/selection.jd | 123 ---- docs/html/design/patterns/settings.jd | 708 ------------------------ docs/html/design/style/branding.jd | 128 ----- docs/html/design/style/color.jd | 141 ----- docs/html/design/style/iconography.jd | 601 -------------------- docs/html/design/style/metrics-grids.jd | 90 --- docs/html/design/style/themes.jd | 53 -- docs/html/design/style/touch-feedback.jd | 95 ---- docs/html/design/style/typography.jd | 78 --- docs/html/design/style/writing.jd | 322 ----------- docs/html/design/videos/index.jd | 130 ----- 32 files changed, 26 insertions(+), 4319 deletions(-) delete mode 100644 docs/html/design/building-blocks/buttons.jd delete mode 100644 docs/html/design/building-blocks/dialogs.jd delete mode 100644 docs/html/design/building-blocks/grid-lists.jd delete mode 100644 docs/html/design/building-blocks/index.jd delete mode 100644 docs/html/design/building-blocks/lists.jd delete mode 100644 docs/html/design/building-blocks/pickers.jd delete mode 100644 docs/html/design/building-blocks/progress.jd delete mode 100644 docs/html/design/building-blocks/scrolling.jd delete mode 100644 docs/html/design/building-blocks/seek-bars.jd delete mode 100644 docs/html/design/building-blocks/spinners.jd delete mode 100644 docs/html/design/building-blocks/switches.jd delete mode 100644 docs/html/design/building-blocks/tabs.jd delete mode 100644 docs/html/design/building-blocks/text-fields.jd delete mode 100644 docs/html/design/patterns/gestures.jd delete mode 100644 docs/html/design/patterns/index.jd delete mode 100644 docs/html/design/patterns/multi-pane-layouts.jd delete mode 100644 docs/html/design/patterns/navigation-drawer.jd delete mode 100644 docs/html/design/patterns/selection.jd delete mode 100644 docs/html/design/patterns/settings.jd delete mode 100644 docs/html/design/style/branding.jd delete mode 100644 docs/html/design/style/color.jd delete mode 100644 docs/html/design/style/iconography.jd delete mode 100644 docs/html/design/style/metrics-grids.jd delete mode 100644 docs/html/design/style/themes.jd delete mode 100644 docs/html/design/style/touch-feedback.jd delete mode 100644 docs/html/design/style/typography.jd delete mode 100644 docs/html/design/style/writing.jd delete mode 100644 docs/html/design/videos/index.jd (limited to 'docs') diff --git a/docs/html/design/building-blocks/buttons.jd b/docs/html/design/building-blocks/buttons.jd deleted file mode 100644 index 713574a..0000000 --- a/docs/html/design/building-blocks/buttons.jd +++ /dev/null @@ -1,99 +0,0 @@ -page.title=Buttons -page.tags=button,input -@jd:body - - -
-

Material Design

-

Buttons

-

- - - -
-

Developer Docs

-

Buttons

-
- - -

A button consists of text and/or an image that clearly communicates what action - will occur when the user touches it. A button can have an image, text, or both. -

- -
-
- -
-
- -
-
- -
-
- -
-
-

An image alone works best when the action can be represented by a symbol that's well understood.

-
-
-

Text alone is most appropriate for actions that would be difficult to - represent visually, or are critical to convey in words to avoid any ambiguity.

-
-
-

- Both an icon and text is most appropriate when they complement each other: - each carrying its own bit of information, but together making a larger whole. -

- -

- For example, in a birthday reminder card in Google Now, the button's text - describes the action while its image indicates that the action will be done - in Google+. -

-
-
- -

What about button backgrounds?

- -
-
-

For image-only buttons, a background isn't necessary because - users are accustomed to interacting with objects.

- -
-
-
Don't
- -
-
-
Do
- -
-
-
- -
-

- For buttons with text, a background is also usually - unnecessary. To invite users to touch, phrase it as a clear action (e.g. - "Start", "Sign in") and use different color and formatting than the screen's - usual body text. -

- -

- Use buttons with backgrounds sparingly. Because they have a heavy appearance, - they work best when there's only one or two of them on the screen. They're - most appropriate for: -

- -
    -
  • A call to action you really want users to pursue (e.g. "Sign up")
    • -
  • A key decision point (e.g. "Accept" / "Decline")
    • -
  • When the user is about to commit a significant action (e.g. "Erase - everything", "Buy now")
    • -
-
-
- diff --git a/docs/html/design/building-blocks/dialogs.jd b/docs/html/design/building-blocks/dialogs.jd deleted file mode 100644 index 70460ba..0000000 --- a/docs/html/design/building-blocks/dialogs.jd +++ /dev/null @@ -1,186 +0,0 @@ -page.title=Dialogs -page.tags=dialog,alert,popup,toast -@jd:body - - -
-

Material Design

-

Dialogs

-

- - - -
-

Developer Docs

-

Dialogs

-
- - -

Dialogs prompt the user for decisions or additional information required by the app to continue a -task. Such requests can range from simple Cancel/OK decisions to more complex layouts asking the -user to adjust settings or enter text.

- - - -
- -
    -
  1. -

    Optional title region

    -

    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.

    -
    2. -
  2. -

    Content area

    -

    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.

    -
    3. - -
  3. -

    Action buttons

    -

    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:

    -
      - -
    • The dismissive action of a dialog is always on the left. Dismissive actions return to the user to the previous state.
      • -
    • The affirmative actions are on the right. Affirmative actions continue progress toward the user goal that triggered the dialog.
      • -
    -
    4. -
-
- - -
- Samples of typical dialog use in Android. -
- -

Alerts

- -

Alerts inform the user about a situation that requires their confirmation or acknowledgement before -proceeding. They differ slightly in appearance based upon the severity and impact of the message -conveyed.

- -
-
- - - -
-
- -

Alerts without title bars

-

Most alerts don't need titles. Usually the decision doesn't have a severe impact and can be summed -up succinctly in a sentence or two. The content area should either ask a question (such as "Delete -this conversation?") or make a clear statement whose relationship to the action buttons is obvious.

- -
-
- - -
-
- - - -
-
- -

Alerts with title bars

-

Use alerts with title bars sparingly. They are appropriate only when a high-risk operation involving -potential loss of data, connectivity, extra charges, and so on requires a clear question or -statement (the title) and some additional explanation (in the content area).

-

Keep the question or statement short: for example, "Erase USB storage?" Avoid apologies. A user -should be able to skip the content completely and still have a clear idea of what choices are -available based on the title and the text of the action buttons.

- -
-
-

When crafting a confirmation dialog, make the title meaningful by echoing the requested action.

- -
-
-
Don't
- - - - - - -
- Are you sure? -
-
-
-
Don't
- - - - - - -
- Warning! -
-
-
-
Do
- - - - - - -
- Erase USB storage? -
-
-
- - -

Popups

- -

Popups are lightweight version of dialogs that require a single selection from the user. Popups -don't have have explicit buttons that accept or cancel the operation. Instead, making a selection -advances the workflow, and simply touching outside the popup dismisses it.

- - - - -

Toasts

- - -
-
- -
- -

Toasts provide lightweight feedback about an operation in a small popup. For example, navigating -away from an email before you send it triggers a "Draft saved" toast to let you know that you can -continue editing later. Toasts automatically disappear after a timeout.

- - -
-

Material Design

-

Toasts

-

- - - - -
-

Developer Docs

-

Toasts

-
- - -
-
- - - -
-
- diff --git a/docs/html/design/building-blocks/grid-lists.jd b/docs/html/design/building-blocks/grid-lists.jd deleted file mode 100644 index 7a1c652..0000000 --- a/docs/html/design/building-blocks/grid-lists.jd +++ /dev/null @@ -1,96 +0,0 @@ -page.title=Grid Lists -page.tags=gridview,layout,listview -@jd:body - - - - - -
-

Material Design

-

Grid lists

-

- - - -
-

Developer Docs

-

Grid View

-
- - -

Grid lists are an alternative to standard list views. They are best suited for showing data sets -that represent themselves through images. In contrast to simple lists, grid lists may scroll either -vertically or horizontally.

- - - -

Generic Grids

- - -

The items in a grid list are arranged in two dimensions, one of which is fixed when scrolling -content. The scrolling direction dictates the ordering of the items within the grid list. Since the -scrolling direction is not deterministic, make it easy for the user to determine the orientation by -cutting off grid items to communicate where the overflow is located.

-

Avoid creating grid lists that scroll in two dimensions.

- - -
-
- - - -
-
- -

Vertical scrolling

-

Vertically scrolling grid list items are sorted in traditional western reading direction: -left-to-right and top-down. When displaying the list, cut off the items in the bottom row to -communicate that the user can scroll the list down to show additional items. Be sure to retain this -scheme when the user rotates the screen.

- -
-
- -
-
- - - -
-
- -

Horizontal scrolling

-

Horizontally scrolling lists fix the vertical axis of the item grid. Compared to vertically -scrolling lists, the sorting changes slightly to a top-down and left-to-right arrangement. Employ -the same technique of cutting off the items in the rightmost column to indicate the scrolling -direction.

-

Don't use scrolling tabs as a means to switch views in conjunction with horizontally scrolling grid -lists, because the horizontal gesture for view and content navigation will conflict. If you show -scrolling tabs for view navigation together with a grid list, use vertical grid scrolling for list -navigation.

- -
-
- - -

Grid List with Labels

- -

Use labels to display additional contextual information for your grid list items.

- - -
-
- - - -
-
- -

Style

-

Use semi-transparent panels on top of the grid list items to display your labels. This allows you to -control the contrast and ensures legibility of the labels while letting the content "shine through".

- -
-
diff --git a/docs/html/design/building-blocks/index.jd b/docs/html/design/building-blocks/index.jd deleted file mode 100644 index 7fb0e55..0000000 --- a/docs/html/design/building-blocks/index.jd +++ /dev/null @@ -1,30 +0,0 @@ -page.title=Building Blocks -header.justLinks=1 -footer.hide=1 -@jd:body - - - -
-
- Your inventory of ready-to-use elements for creating - outstanding apps. -

- Tabs -
- - - - -
diff --git a/docs/html/design/building-blocks/lists.jd b/docs/html/design/building-blocks/lists.jd deleted file mode 100644 index 85753c8..0000000 --- a/docs/html/design/building-blocks/lists.jd +++ /dev/null @@ -1,56 +0,0 @@ -page.title=Lists -page.tags=listview,layout -@jd:body - - -
-

Material Design

-

Lists

-

- - -

Lists present multiple line items in a vertical arrangement. They can be used for data selection as -well as drilldown navigation.

- -
 
- -
-
- - - -
-
- -
    -
  1. -

    Section Divider

    -

    Use section dividers to organize the content of your list into groups and facilitate scanning.

    -
    2. -
  2. -

    Line Items

    -

    List items can accommodate a wide range of data types in different arrangements, including - simple single-line items, multi-line items, and custom items with icons, checkboxes, and action - buttons.

    -
    3. -
- - -
-

Developer Docs

-

List View

-
- - - -
-

Material Design

-

Lists: Controls

-

- - - -
-
diff --git a/docs/html/design/building-blocks/pickers.jd b/docs/html/design/building-blocks/pickers.jd deleted file mode 100644 index 72da0f7..0000000 --- a/docs/html/design/building-blocks/pickers.jd +++ /dev/null @@ -1,40 +0,0 @@ -page.title=Pickers -page.tags=datepicker,timepicker -@jd:body - - -
-

Developer Docs

-

Pickers

-
- - -

Pickers provide a simple way to select a single value from a set. In addition to touching the -up/down arrow buttons, it's possible to set the desired value from the keyboard or via a swipe -gesture.

- -
-
- - - -
-
- -

Space considerations

-

Pickers can be used inline on a form, but their relatively large footprint is best suited for -display in a dialog. For inline display, consider using more compact controls such as text fields or -spinners.

- -
-
- -

Date and time pickers

- -

Android provides these as ready-to-use dialogs. Each picker is a dialog with a set of controls for -entering the parts of the date (month, day, year) or time (hour, minute, AM/PM). Using these in your -app helps ensure that a user's specification of a data or time input is valid and formatted -correctly. The format of a time and date picker adjusts automatically to the locale.

- - - diff --git a/docs/html/design/building-blocks/progress.jd b/docs/html/design/building-blocks/progress.jd deleted file mode 100644 index ae81440..0000000 --- a/docs/html/design/building-blocks/progress.jd +++ /dev/null @@ -1,105 +0,0 @@ -page.title=Progress & Activity -page.tags=progressbar,download,network -@jd:body - - -
-

Material Design

-

Progress and Activity

-

- - -

Progress bars and activity indicators signal to users that something is happening that will take a moment.

-

Progress bars

- -

Progress bars are for situations where the percentage completed can be determined. They give users a quick sense of how much longer an operation will take.

- - - -

A progress bar should always fill from 0% to 100% and never move backwards to a lower value. If multiple operations are happening in sequence, use the progress bar to represent the delay as a whole, so that when the bar reaches 100%, it doesn't return back to 0%.

- -
 
- - -
- Progress bar in Holo Dark and Holo Light. -
- -

Activity indicators

- -

Activity indicators are for operations of an indeterminate length. They ask users to wait a moment while something finishes up, without getting into specifics about what's happening behind the scenes.

- -

Two styles are available: a bar and a circle. Each is offered in a variety of sizes, in both Holo Light and Holo Dark themes. Choose the appropriate style and size for the surrounding context. For example, the largest activity circle works well when displayed in a blank content area, but not in a smaller dialog box. Each operation should only be represented by one activity indicator.

- -
-
- - - -
-
- -
    -

  1. Activity bar

    -

    In this example, an activity bar (in Holo Dark) appears when a user first requests a download. There's an unknown period of time when the download has not yet started. As soon as the download starts, this activity bar transforms into a progress bar.

    -
    2. -
- -
-
- -
-
- - - -
-
- -
    -

  1. Activity circle

    -

    In this example, an activity circle (in Holo Light) is used in the Gmail application when a message is being loaded because it's not possible to determine how long it will take to download the email.

    -

    When displaying an activity circle, do not include text to communicate what the app is doing. The moving circle alone provides sufficient feedback about the delay, and does so in an understated way that minimizes the impact.

    -

    -

    - -
    -

    -
    2. -
- -
-
- -

Custom indicators

-

The standard progress bar and activity indicators work well for most situations and should be used whenever possible to provide a consistent experience across Android. However, some situations may call for something more custom.

- -

Here's an example:
-In all of the Google Play apps (Music, Books, Movies, Magazines), we wanted the current download state of each item to be visible at all times at the top-level screen. These states are: -

-

-

We also needed to indicate progress from one download state to another, because downloading is not instantaneous.

-

This presented a challenge, because the Google Play apps use a variety of different layouts, and some of them are highly space-constrained. We didn't want this information to clutter the top-level screens, or compete too much with the cover art.

-

So we designed a custom indicator that could show all of the information in a tiny footprint, with the flexibility to appear on top of content if necessary.

- - - -

The color indicates whether it's downloaded (blue) or not (gray). The appearance of the pin indicates whether the download is permanent (white, upright) or temporary (gray, diagonal). And when state is in the process of changing, progress is indicated by a moving pie chart.

- -
-
- -
-
-
- Across Google Play apps with different layouts, the same custom indicator appears with each item. It communicates download state as well as progress, in a compact package that can be incorporated into any screen design. -
-
-
- -

If you find that the standard indicators aren't meeting your needs (due to space constraints, state complexities), by all means design your own. Make it feel like part of the Android family by injecting some of the visual characteristics of the standard indicators. In this example, we carried over the circular shape, the same shade of blue, and the flat and simple style.

diff --git a/docs/html/design/building-blocks/scrolling.jd b/docs/html/design/building-blocks/scrolling.jd deleted file mode 100644 index 04b1e4a..0000000 --- a/docs/html/design/building-blocks/scrolling.jd +++ /dev/null @@ -1,39 +0,0 @@ -page.title=Scrolling -page.tags=scrollview,listview -@jd:body - - -

Scrolling allows the user to navigate to content in the overflow using a swipe gesture. The -scrolling speed is proportional to the speed of the gesture.

-

Scroll Indicator

- -

Appears during scrolling to indicate what portion of the content is currently in view.

- -
- -
-
-
 
-
- -

Index Scrolling

- -

In addition to traditional scrolling, a long alphabetical list can also offer index scrolling: a way -to quickly navigate to the items that begin with a particular letter. With index scrolling, a scroll -indicator appears even when the user isn't scrolling. Touching or dragging it causes the current -letter to pop up in a prominent way.

- -
- -
-
-
 
-
diff --git a/docs/html/design/building-blocks/seek-bars.jd b/docs/html/design/building-blocks/seek-bars.jd deleted file mode 100644 index 04446d2..0000000 --- a/docs/html/design/building-blocks/seek-bars.jd +++ /dev/null @@ -1,45 +0,0 @@ -page.title=Seek Bars and Sliders -page.tags=seekbar,progressbar -@jd:body - - -
-

Material Design

-

Sliders

-

- - -

Interactive sliders make it possible to select a value from a continuous or discrete range of values -by moving the slider thumb. The smallest value is to the left, the largest to the right. The -interactive nature of the slider makes it a great choice for settings that reflect intensity levels, -such as volume, brightness, or color saturation.

- -
-
- - - -
-
- -
 
- -

Example

-

Interactive slider to set the ringer volume. The value can either be set through the hardware volume controls or interactively via a gesture.

- -
-
- - -
-
- - -
- Seek bars in Holo Light & Dark -
- -
-
 
-
diff --git a/docs/html/design/building-blocks/spinners.jd b/docs/html/design/building-blocks/spinners.jd deleted file mode 100644 index 31c5558..0000000 --- a/docs/html/design/building-blocks/spinners.jd +++ /dev/null @@ -1,54 +0,0 @@ -page.title=Spinners -page.tags=spinner,dropdown -@jd:body - - -
-

Material Design

-

Menus

-

- - - -
-

Developer Docs

-

Spinners

-
- - -

Spinners provide a quick way to select one value from a set. In the default state, a spinner shows -its currently selected value. Touching the spinner displays a dropdown menu with all other available -values, from which the user can select a new one.

- - -
-
- - - -

Spinners in forms

-

Spinners are useful for data picking in forms. They are compact and integrate nicely with other -components. Use spinners in forms for both simple data input and in combination with other input -fields. For example, a text field might let you edit an email address for a contact, while its -associated spinner allows you to select whether it's a Home or Work address.

- -
-
- - - -

Spinners in action bars

-

Use spinners in action bars to switch views. For example, Gmail uses a spinner to permit switching -between accounts or commonly used labels. Spinners are useful when changing the view is important to -your app, but not necessarily a frequent occurrence. In cases where view switching is frequent, use -tabs.

- -
-
- - -
- Spinners in the Holo Dark and Holo Light themes, in various states. -
- diff --git a/docs/html/design/building-blocks/switches.jd b/docs/html/design/building-blocks/switches.jd deleted file mode 100644 index 9dd09ca..0000000 --- a/docs/html/design/building-blocks/switches.jd +++ /dev/null @@ -1,64 +0,0 @@ -page.title=Switches -page.tags=switch,checkbox,radiobutton,button -@jd:body - - -
-

Material Design

-

Selection Controls

-

- - -

Switches allow the user to select options. There are three kinds of switches: checkboxes, radio -buttons, and on/off switches.

- - - -

Checkboxes

- - -
-

Developer Docs

-

Checkboxes

-
- - -

Checkboxes allow the user to select multiple options from a set. Avoid using a single checkbox to -turn an option off or on. Instead, use an on/off switch.

- - - - - -

Radio Buttons

- - -
-

Developer Docs

-

Radio Buttons

-
- - -

Radio buttons allow the user to select one option from a set. Use radio buttons for exclusive -selection if you think that the user needs to see all available options side-by-side. Otherwise, -consider a spinner, which uses less space.

- - - - - -

On/off Switches

- - -
-

Developer Docs

-

Toggle Buttons

-
- - -

On/off switches toggle the state of a single settings option.

- - - - diff --git a/docs/html/design/building-blocks/tabs.jd b/docs/html/design/building-blocks/tabs.jd deleted file mode 100644 index 1315a2f..0000000 --- a/docs/html/design/building-blocks/tabs.jd +++ /dev/null @@ -1,65 +0,0 @@ -page.title=Tabs -page.tags=tabs,actionbar,navigation,viewpager -@jd:body - - - - -
-

Material Design

-

Tabs

-

- - - -
-

Developer Docs

-

Creating Swipe Views
with 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.

- -

Scrollable Tabs

- - -
-
- -

Scrolling tab controls can contain a larger number of items than a standard tab control. To navigate -to the next/previous view, swipe left or right.

- -
-
- - -
- Scrolling tabs in the Play Store app. -
 
-
- -
-
- - -

Fixed Tabs

-

Fixed tabs display all items concurrently. To navigate to a different view, touch the tab, or swipe left or right.

-

Fixed tabs are displayed with equal width, based on the width of the widest tab label. If there is insufficient room to display all tabs, the tab labels themselves will be scrollable. For this reason, fixed tabs are best suited for displaying 3 or fewer tabs.

- - -
- Tabs in Holo Dark & Light. -
- - -
- Tabs in the Google Play Movies app. -
diff --git a/docs/html/design/building-blocks/text-fields.jd b/docs/html/design/building-blocks/text-fields.jd deleted file mode 100644 index 9403679..0000000 --- a/docs/html/design/building-blocks/text-fields.jd +++ /dev/null @@ -1,88 +0,0 @@ -page.title=Text Fields -page.tags=text,edittext,input -@jd:body - - - -
-

Material Design

-

Text Fields

-

- - - -
-

Developer Docs

-

Text Fields

-
- - -

Text fields allow the user to type text into your app. They can be either single line or multi-line. -Touching a text field places the cursor and automatically displays the keyboard. In addition to -typing, text fields allow for a variety of other activities, such as text selection (cut, copy, -paste) and data lookup via auto-completion.

- - -
-
- - - -
-
- -

Single line and multi line

-

Single-line fields automatically scroll their content to the left as the text input cursor reaches -the right edge of the input field. Multi-line text fields automatically break to a new line for -overflow text and scroll vertically when the cursor reaches the lower edge.

- - - -
-
- -

Text field types

-

Text fields can have different types, such as number, message, or email address. The type determines -what kind of characters are allowed inside the field, and may prompt the virtual keyboard to -optimize its layout for frequently used characters.

- -
-
- -

Auto-complete text fields

-

Use auto-complete text fields to present real-time completions or search results in popups, so users -can enter information more accurately and efficiently.

- -
-
- -

Text Selection

- -

Users can select any word in a text field with a long press. This action triggers a text selection -mode that facilitates extending the selection or choosing an action to perform on the selected text. -Selection mode includes:

- -
-
- - - -
-
- -
    -
  1. -

    Contextual action bar

    -

    A contextual action bar (CAB) displays the actions available to perform on the selection: - typically cut, copy, and paste, but apps can insert additional commands as needed.

    -
    2. -
  2. -

    Selection handles

    -

    Selection handles can be dragged to select more or less text while remaining in selection mode.

    -
    3. -
- -
-
- diff --git a/docs/html/design/design_toc.cs b/docs/html/design/design_toc.cs index 63f5cad..85569ef 100644 --- a/docs/html/design/design_toc.cs +++ b/docs/html/design/design_toc.cs @@ -1,15 +1,15 @@ diff --git a/docs/html/design/downloads/index.jd b/docs/html/design/downloads/index.jd index 0b9f59f..089a4af 100644 --- a/docs/html/design/downloads/index.jd +++ b/docs/html/design/downloads/index.jd @@ -3,107 +3,16 @@ page.tags=Icons,stencils,color swatches @jd:body -

You may use these materials without restriction to facilitate your app design -and implementation.

+

For icons, sticker sheets, and other downloadable resources, visit the +Design site or use the links below.

- -

Phone & Tablet Stencils

- -
-
- - -

Drag and drop your way to beautifully designed Android apps. The stencils feature the -rich typography, colors, interactive controls, and icons found throughout Android, along with -phone and tablet outlines to frame your creations. Source files for icons and controls are also -available.

- -
-
- - - -
- -
- -
-

Material Design

-

Layout Templates

-

- -
- -
- -
-

Material Design

-

Sticker Sheets

-

- -
- -
-

- Adobe® Photoshop® Stencils and Sources -

- -
-
- - - - - - -

Action Bar Icon Pack

- -
-
- -

Action bar icons are graphic buttons that represent the most important actions people can take -within your app. More on Action Bar Iconography

-

The download package includes icons that are scaled for various screen densities and suitable for -use with the Holo Light and Holo Dark themes. The package also includes unstyled icons that you can -modify to match your theme, plus source files.

- -
-
- - - -
- -
- -
-

Material Design

-

Sticker Sheets

-

- -
- -
- -

- Action Bar Icon Pack -

- -
+
- - -

Android Wear Materials

@@ -243,86 +152,4 @@ system indicators. Adobe® Photoshop® Icon
- - - - - -

Style

- -
-
- -

Roboto

-

Ice Cream Sandwich introduced a new type family named Roboto, created specifically for the -requirements of UI and high-resolution screens.

-

For Android Wear, Roboto Condensed is the system font and the Regular and Light variants should be used by all Wear apps.

-

More on Roboto

-

Roboto on Google Fonts

-

Roboto Condensed on Google Fonts

- -
-
- - - -
- -
- -
-

Material Design

-

Roboto Font

-

- -
- -
- -

- Roboto - Specimen Book -

- -
-
- -
-
- -

Color

-

In Android's color palette, each color has a corresponding darker -shade that can be used as a complement when needed.

-

More on Color

- -
-
- - - -
- -
- -
-

Material Design

-

Color Palettes

-

- -
- -
- -

- Color Swatches -

- -
-
+ \ No newline at end of file diff --git a/docs/html/design/get-started/creative-vision.jd b/docs/html/design/get-started/creative-vision.jd index 3955494..974d5d0 100644 --- a/docs/html/design/get-started/creative-vision.jd +++ b/docs/html/design/get-started/creative-vision.jd @@ -7,10 +7,9 @@ page.image=images/cards/design-creative-vision_2x.jpg
 

- Starting with Ice Cream Sandwich, we focused the design of - Android around these three overarching goals, which apply - to our core apps as well as the system at large. - As you work with Android, consider these goals. + Android design is shaped by three overarching goals for users that apply + to apps as well as the system at large. As you work with Android, + keep these goals in mind.

 
diff --git a/docs/html/design/index.jd b/docs/html/design/index.jd index 74af6e7..638f35b 100644 --- a/docs/html/design/index.jd +++ b/docs/html/design/index.jd @@ -14,17 +14,14 @@ footer.hide=1
-

Up and running with Material Design

+

Up and running with material design

- Android 5.0 introduces a design metaphor inspired by paper and ink that provides a reassuring sense of tactility. + Android uses a new design metaphor inspired by paper and ink that provides a reassuring + sense of tactility. Visit the material design site for more resources.

- Introducing Material Design -
- - - Material Design for Android + Introducing material design
@@ -56,7 +53,7 @@ footer.hide=1

Pure Android

- This is a place holder paragraph. Some text here would povide some context. + Design around Android's capabilities and conventions to give users the best experience.

Resources

- This is a place holder paragraph. Some text here would povide some context. + Essential downloads, stencils, and tools to help you create your design.
-
-

Material Design

-

Gestures

-

- - -

Gestures allow users to interact with your app by manipulating the screen objects you provide. The -following table shows the core gesture set that is supported in Android.

- -
 
- -
- -
- -

Touch

-

Triggers the default functionality for a given item.

-
    -
  • -

    Action

    -

    Press, lift

    • -
-
- -
- -

Long press

-

Enters data selection mode. Allows you to select one or more items in a view and act upon - the data using a contextual action bar. Avoid using long press for showing contextual menus.

-
    -
  • -

    Action

    -

    Press, wait, lift

    • -
-
- -
- -

Swipe or drag

-

Scrolls overflowing content, or navigates between views in the same hierarchy. Swipes are - quick and affect the screen even after the finger is picked up. Drags are slower and more precise, - and the screen stops responding when the finger is picked up.

-
    -
  • -

    Action

    -

    Press, move, lift

    • -
-
- -
- -
 
- -
- -
- -

Long press drag

-

Rearranges data within a view, or moves data into a container (e.g. folders on Home Screen).

-
    -
  • -

    Action

    -

    Long press, move, lift

    • -
-
- -
- -

Double touch

-

Scales up a standard amount around the target with each repeated gesture until reaching - maximum scale. For nested views, scales up the smallest targetable view, or returns it to - its original scale. Also used as a secondary gesture for text selection.

-
    -
  • -

    Action

    -

    Two touches in quick succession

    -
    • -
-
- -
- -

Double touch drag

-

Scales content by pushing away or pulling closer, centered around gesture.

-
    -
  • -

    Action

    -

    A single touch followed in quick succession by a drag up or down:

    -
      -
    • Dragging up decreases content scale
      • -
    • Dragging down increases content scale
      • -
    • Reversing drag direction reverses scaling.
      • -
    -
    • -
-
- -
- - -
 
- -
- -
- -

Pinch open

-

Zooms into content.

-
    -
  • -

    Action

    -

    2-finger press, move outwards, lift

    • -
-
- -
- -

Pinch close

-

Zooms out of content.

-
    -
  • -

    Action

    -

    2-finger press, move inwards, lift

    -
    • -
-
- -
- diff --git a/docs/html/design/patterns/index.jd b/docs/html/design/patterns/index.jd deleted file mode 100644 index e091a29..0000000 --- a/docs/html/design/patterns/index.jd +++ /dev/null @@ -1,30 +0,0 @@ -page.title=Patterns -header.justLinks=1 -footer.hide=1 -@jd:body - - - -
-
- Design apps that behave in a consistent, predictable - fashion. -

- New in Android -
- - - - -
diff --git a/docs/html/design/patterns/multi-pane-layouts.jd b/docs/html/design/patterns/multi-pane-layouts.jd deleted file mode 100644 index c9d3d84..0000000 --- a/docs/html/design/patterns/multi-pane-layouts.jd +++ /dev/null @@ -1,130 +0,0 @@ -page.title=Multi-pane Layouts -page.tags="tablet","navigation","layout","fragment" -page.metaDescription=Design guide with examples of how to flatten navigation and provide improved layout across the range of Android devices. - -@jd:body - - - -
-

Material Design

-

UI Regions and Guidance

-

- - - -
-

Developer Docs

-

Building a Dynamic UI with Fragments

-
- - -

When writing an app for Android, keep in mind that Android devices -come in many different screen sizes and types. Make sure that your app consistently provides a -balanced and aesthetically pleasing layout by adjusting its content to varying screen sizes and -orientations.

- -

Panels are a great way for your app to achieve this. They allow you to combine multiple views into -one compound view when a lot of horizontal screen real estate is available and by splitting them up -when less space is available.

-

Combining Multiple Views Into One

- -

On smaller devices your content is typically divided into a master grid or list view and a detail -view. Touching an item in the master view opens a different screen showing that item's detail -information.

- - - -

Because tablets have more screen real estate than phones, you can use panels to combine the related -list and detail views into a single compound view. This uses the additional space more efficiently -and makes navigating the app easier.

- - - -

In general, use the pane on the right to present more information about the item you selected in the -left pane. Make sure to keep the item in the left pane selected in order to establish the -relationship between the panels.

-

Compound Views and Orientation Changes

- -

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.

- -
-
- - - -
-
- -

Stretch/compress

-

Adjust the column width of your left pane to achieve a balanced layout in both orientations.

- -
-
- -
-
- - - -
-
- -

Stack

-

Rearrange the panels on your screen to match the orientation.

- -
-
- -
-
- - - -
-
- -

Expand/collapse

-

When the device rotates, collapse the left pane view to only show the most important information.

- -
-
- -
-
- - - -
-
- -

Show/hide

-

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.

- -
-
- - - - -

Checklist

- -
    -
  • -

    Plan in advance on how your app scales to different screen sizes and screen orientations.

    -
    • -
  • -

    Identify the most appropriate method for the panels in your compound views to reorganize - themselves when screen orientation changes.

    -
    • -
  • -

    Look for opportunities to consolidate your views into multi-panel compound views.

    -
    • -
  • -

    Make sure that your screens try to provide functional parity after the screen orientation - changes.

    -
    • -
diff --git a/docs/html/design/patterns/navigation-drawer.jd b/docs/html/design/patterns/navigation-drawer.jd deleted file mode 100644 index b359470..0000000 --- a/docs/html/design/patterns/navigation-drawer.jd +++ /dev/null @@ -1,346 +0,0 @@ -page.title=Navigation Drawer -page.tags=DrawerLayout,SlidingPaneLayout -@jd:body - - - -
-

Material Design

-

Side Nav

-

- - - -
-

Developer Docs

-

Creating a Navigation Drawer

-
- - - -

The navigation drawer is a panel that transitions in from the left edge of the screen and -displays the app’s main navigation options.

- - -

Displaying the navigation drawer

- -

The user can bring the navigation drawer onto the screen by swiping from the left edge of the -screen or by touching the application icon on the action bar.

- -

As the navigation drawer expands, it overlays the content but not the action bar. When the -drawer is fully extended, the action bar adjusts its content by replacing the current action -bar title with the app name and removing all actions that are contextual to the view underneath -the navigation drawer. The overflow menu with the standard action items for Settings and Help -remains visible.

- - -
- The user can open the drawer panel by touching the navigation drawer indicator. -
- -

Because they are transient, navigation drawers make views less cluttered. You can also use -them at deeper levels in the navigation hierarchy, allowing users to switch to your app's most -important screens from anywhere in the app.

- - -
- Open the drawer from anywhere in your app by swiping from the left edge of the screen. -
- - -

Dismissing the navigation drawer

- -

When the navigation drawer is expanded, the user can dismiss it in one of four ways:

-
    -
  • Touching the content outside the navigation drawer
    • -
  • Swiping to the left anywhere on the screen (including edge swipe from right)
    • -
  • Touching the app icon/title in the action bar
    • -
  • Pressing Back
    • -
- - -

When to Use the Navigation Drawer

- -

The navigation drawer is not a general replacement for top-level navigation via spinners -or tabs. The structure of your app should guide your choice of which pattern to use for -top-level switching. For more information on top-level switching mechanisms, see the -Application Structure design pattern.

-

Here are some examples of where navigation drawers work best:

- -

More than 3 top-level views

-

Navigation drawers are great for displaying a large number of navigation targets -concurrently. Use the navigation drawer if you have more than 3 unique top-level views. -If not, use fixed tabs for top-level organization to ease discovery and interaction.

- -

Cross-navigation from lower levels

-

If your app requires cross-navigating between lower-level screens, consider using the -navigation drawer. Because it is accessible from anywhere in the app, the drawer enables -efficient navigation from lower-level screens to other important places in your app.

- - -
- The navigation drawer makes cross-navigation at lower levels possible. -
- - -

Deep navigation branches

-

If you have particularly deep branches, navigating to the top-level of your app can become -repetitive and cumbersome with Up and Back alone. Since navigation drawers are accessible from -anywhere in the app, navigation up to the top level is faster and more efficient.

- - -
- The navigation drawer allows for quick jumps to the top-level of your app, removing the need - for repetitive Back or Up sequences. -
- - -

Navigation Hubs

- -

The navigation drawer is a reflection of your app’s structure and displays its major -navigation hubs. Think of navigation hubs as those places in your app that a user will want -to visit frequently or use as a jumping-off point to other parts of the app. -At a minimum, the navigation hubs are the top-level views, since they correspond to your app’s -major functional areas.

-

If your app’s structure is deep, you can add screens from lower levels that your users will -likely visit often and make those navigation hubs as well.

- - -
- The navigation drawer contains all of your app's navigation hubs. Include your top level - screens as well as important lower-level screens. -
- -
-
-

To facilitate access to the navigation drawer on navigation hubs, all screens that - correspond to an entry in your navigation drawer should show the navigation drawer indicator - next to the application icon in the action bar. Touching the app icon causes the navigation - drawer to slide in from the left.

-

All other lower-level screens show the traditional Up indicator next to the application - icon. The drawer is still accessible with an edge-swipe, but is not featured in the action bar.

-
-
- -
- App icon with navigation drawer indicator. -
-
-
- - -

Content of the Navigation Drawer

- -

Keep the content of the navigation drawer focused on app navigation. Expose the navigation -hubs of your app as list items inside the navigation drawer - one item per row. - -

-
-

Titles, icons, and counters

-

You can structure navigation targets by adding titles. The titles are not interactive, - but just organize navigation targets into functional topics. If you have many navigation - targets, use titles to orient the user within the drawer.

-

Navigation targets can have optional leading icons as well as trailing counters. Use - the counters to inform users about a changed state of data in the corresponding view.

-
-
- -
- Use titles and icons to organize your drawer. -
-
-
- -
-
- -
- Collapsible navigation items are split. Use the left side for navigation and the right - to collapse and expand items. -
-
-
-

Collapsible navigation items

-

If you have many views with some subordinate to others, consider collapsing them into one - expandable item to conserve space. - The parent in the navigation drawer then turns into a split item. The left side allows - navigation to the parent item’s view, and the right side collapses or expands the list of - child items.

-

At launch, the initial state of the collapsible items is up to you. As a rule, all - top-level view entries of the navigation drawer should be visible. If you have many collapsible - items, consider collapsing all items to allow the user to see the top-level views in their - entirety.

-

When the user opens the drawer from a lower-level screen, expand the associated branch - of the top-level view to give a stronger sense of place and highlight navigation opportunities - close to the user’s current - location in the app.

-
-
- - -

Navigation Drawers and Action Bars

- -

When the user expands the navigation drawer, the task focus switches to selecting an item -from the drawer. Because the drawer does not overlay the action bar, users may not realize that -the items in the action bar do not pertain to the navigation drawer.

-

To reduce confusion, adjust the content of the action bar to the following, once the drawer -is fully expanded:

-
    -
  • App icon
    • -
  • App name
    • -
  • Remove actions from the action bar that are contextual to the underlying view (such as - Create new, Refresh). You may retain actions with global scope, such as “Search”.
    • -
  • Overflow menu with expected navigation targets, such as Settings and Help.
    • -
- - -
- Clean up the action bar when the drawer is fully expanded. Remove actions that are not needed - and display your app's name in the title area. -
- -

Actions

-
-
- -
- Keep actions on the right side of the action bar and in the overflow -
-
-
-

Don’t place actions in the navigation drawer. Actions belong in the action bar, and the - user expects to see them there. Keep in mind that not all applications use the navigation - drawer pattern. It may be tempting to expose all your app’s capabilities in a single place, - but keep the bigger picture in mind. Place your actions where all apps display them.

-
-
-
-
-

This also applies to common navigation targets, such as access to Help or the app’s - Settings. As per style guide convention Help and Settings are always located in the action - overflow.

-
-
- -
- Keep Help and Settings in the overflow. -
-
-
- - -

Contextual action bars

-

Sometimes the user will be in a state where a contextual action bar (CAB) appears instead -of the app’s action bar. This typically happens when the user selects text or selects multiple -items after a press-and-hold gesture. While the CAB is visible, you should still allow the -user to open the navigation drawer using an edge swipe. However, replace the CAB with the -standard action bar while the navigation drawer is open. When the user dismisses the drawer, -re-display the CAB.

- - -
- Hide contextual action bars while the drawer is visible. -
- -

If the user navigates away from a view with selected content, deselect the content before -before navigating to the new view.

- - -

Interaction Details

- -

Introduce the user to the drawer at first use

-

Upon first launch of your app, introduce the user to the navigation drawer by -automatically opening it. This ensures that users know about the navigation drawer and prompts -them to learn about the structure of your app by exploring its content. Continue showing the -drawer upon subsequent launches until the user actively expands the navigation drawer manually. -Once you know that the user understands how to open the drawer, launch the app with the -navigation drawer closed.

- - -
- At first use, show the navigation drawer automatically to help the user learn the - functionality and structure of your app. -
- -

Give the user a quick peek

-

If the user touches the very left edge of the screen (within 20 dp from the left), have the -drawer peek out as soon as the finger makes contact with the display. This promotes accidental -discovery and provides richer feedback.

- - -
- The navigation drawer peeks out when the user touches the very left edge of the screen. -
- -

Highlights

-

When you open the navigation drawer from a screen that is represented inside the drawer, -highlight its entry in the drawer. Vice versa, if you open the drawer from a screen that is -not listed in the drawer, none of the items of the drawer should be highlighted.

- - -

Impact of Drawer on Overall App Navigation

- -

The navigation drawer is an alternative to other top-level navigation patterns. To make apps -with navigation drawers work consistently with apps that use a tab or spinner pattern, remember -that all navigation requirements for system Back and Up apply.

-

Pay special attention to the following situations:

- -

System Back at the top level of the app

-

Touching System Back at the app’s top level never opens the navigation drawer. Instead, -System Back behaves according to the navigation rules for the top level, such as navigating -to the previous app within the task or navigating to the Home screen.

- - -
- System Back does not show the drawer, but behaves according to the navigation rules for - the top level. -
- -

System Back after cross navigation to lower hierarchy levels

-

If the user navigates to a lower hierarchy screen from the navigation drawer and the screen -has a direct parent, then the Back stack is reset and Back points to the target screen’s parent. -This Back behavior is the same as when a user navigates into an app from a notification.

- - -
- Reset the Back stack if your lower-level navigation target has direct parents. -
- - -

Style

- -

The width of the navigation drawer depends on the content you want to display, but should be -between a minimum of 240 dp and a maximum of 320 dp. The height of the individual line items -should not fall below 48 dp. See the layout guideline below for recommendations on padding and -spacing.

- - -
- Layout guidelines for the navigation drawer. -
- - -

Pick the drawer background to best match your app’s theme. See the following examples -for a Holo light and a Holo dark themed drawer.

- - -
- Navigation drawers in Holo light and Holo dark themed apps. -
- - -

Navigation Drawer Checklist

- -

Even if you already support a similar navigation drawer, update your drawer to this -pattern to make sure that:

-
    -
  • The action bar remains in place and adjusts its content.
    • -
  • Your navigation drawer overlays the content.
    • -
  • Any view represented in the drawer has a navigation drawer indicator in its action bar - that allows the drawer to be opened by touching the app icon.
    • -
  • You take advantage of the new visual drawer transition.
    • -
  • Any view not represented in the drawer maintains the traditional Up indicator in its action bar.
    • -
  • You stay in sync with the general navigation patterns for Up and Back.
    • -
- diff --git a/docs/html/design/patterns/selection.jd b/docs/html/design/patterns/selection.jd deleted file mode 100644 index e00f726..0000000 --- a/docs/html/design/patterns/selection.jd +++ /dev/null @@ -1,123 +0,0 @@ -page.title=Selection -page.tags=actionmode,navigation,contextual -@jd:body - - -
-

Material Design

-

Selection

-

- - - -
-

Developer Docs

-

Menus: Creating Contextual Menus

-
- - - -

Android 3.0 changed the long press gesture—that is, a touch that's held in the same position for a moment—to be the global gesture to select data.. This affects the way you should -handle multi-select and contextual actions in your apps.

- -
 
- -
-
- -

What has changed?

-

In previous versions of Android, the long press gesture was universally used to display contextual -actions for a given data item in a contextual menu.

-

This pattern changed with Android 3.0. The long press gesture is now used to select data, combining -contextual actions and selection management functions for selected data into a new element called -the contextual action bar (CAB).

- -
-
- - -
- Traditional use of the long press gesture to show contextual menus. -
- -
-
- -

Using the contextual action bar

-

The contextual action bar (CAB) is a temporary action bar that overlays your app's current action bar while data -is selected. It appears after the user long-presses on a selectable data item.

- - - -
 
- -
-
- -

From here the user can:

-
    -
  • Select additional data items by touching them.
    • -
  • Trigger an action from the CAB that applies to all highlighted data items. The CAB then - automatically dismisses itself.
    • -
  • Dismiss the CAB via the navigation bar's Back button or the CAB's checkmark button. This removes - the CAB along with all selection highlights.
    • -
- -
-
- - - -
-
- -
-
- -

Selecting CAB actions

-

You can decide which actions and elements appear in the CAB. Use the guidelines in the Action Bar -pattern to decide which items to surface at the top level and which to move to the -action overflow.

-

Dynamically adjust CAB actions

-

In most cases you need to adjust the actions in the CAB dynamically as the user adds more items to -the selection. Actions that apply to a single selected data item don't necessarily apply to multiple -selected data items of the same kind.

- -
-
- - -
- Adjusting actions in the CAB as additional items are selected. -
- -
-
- -
-

Developer Guide

-

For information about how to create a contextual action bar, read - Using the contextual action mode.

-
- - -

Checklist

- -
    -
  • -

    Whenever your app supports the selection of multiple data items, make use of the contextual action - bar (CAB).

    -
    • -
  • -

    Reserve the long press gesture for selection exclusively. Don't use it to display traditional - contextual menus.

    -
    • -
  • -

    If you don't support multi-selection within a list, long press should do nothing.

    -
    • -
  • -

    Plan the actions you want to display inside of a CAB in the same way you would plan the actions - inside your app's action bar.

    -
    • -
diff --git a/docs/html/design/patterns/settings.jd b/docs/html/design/patterns/settings.jd deleted file mode 100644 index 9ba837a..0000000 --- a/docs/html/design/patterns/settings.jd +++ /dev/null @@ -1,708 +0,0 @@ -page.title=Settings -page.tags=preferences,sharedpreferences -@jd:body - - -
-

Material Design

-

Settings

-

- - - -
-

Developer Docs

-

Settings

-
- - - -

Settings is a place in your app where users indicate their preferences for how your app should -behave. This benefits users because:

- -
    -
  • You don't need to interrupt them with the same questions over and over when certain situations -arise. The settings predetermine what will always happen in those situations (see design -principle: Decide for me but -let me have the final say).
    • -
  • You help them feel at home and in control (see design principle: -Let me make it mine).
    • -
- -

Flow and Structure

- -

Provide access to Settings in the action overflow

- -

Settings is given low prominence in the UI because it's not frequently needed. Even if there's -room in the action bar, never make Settings -an action button. Always keep it in the action overflow and label it "Settings". Place it below -all other items except "Help".

- - - -
 
- -

Avoid the temptation to make everything a setting

- -

Because Settings is a few navigational steps away, no matter how many items you have, they'll -never clutter up the core part of your UI. This may seem like good news, but it also poses a -challenge.

- -

Settings can be a tempting place to keep a lot of stuff—like a hall closet where things -get stashed when you tidy up before company comes over. It's not a place where you spend lots of -time, so it's easy to rationalize and ignore its cluttered condition. But when users visit -Settings—however infrequently—they'll have the same expectations for the experience as -they do everywhere else in your app. More settings means more choices to make, and too many are -overwhelming.

- -

So don't punt on the difficult product decisions and debates that can bring on the urge to -"just make it a setting". For each control you're considering adding to Settings, make sure it -meets the bar:

- - - -
 
- -
-
- -

If you still have lots of settings, group related settings together

- -

The number of items an average human can hold in short-term memory is 7±2. If you -present a list of 10 or more settings (even after applying the criteria above), users will have -more difficulty scanning, comprehending, and processing them.

- -

You can remedy this by dividing some or all of the settings into groups, effectively turning -one long list into multiple shorter lists. A group of related settings can be presented in one of -two ways:

- -
    -

  1. Under a section divider

    2. -

  2. In a separate subscreen

    3. -
- -

You can use one or both these grouping techniques to organize your app's settings.

- -

For example, in the main screen of the Android Settings app, each item in the list navigates -to a subscreen of related settings. In addition, the items themselves are grouped under section -dividers.

- -
-
- - - -
-
- -

Grouping settings is not an exact science, but here's some advice for how to approach it, based -on the total number of settings in your app.

- -
 
- -
-
- -

7 or fewer

- -
-
- -

Don't group them at all. It won't benefit users and will seem like overkill.

- -
-
- -
-
- -

8 to 10

- -
-
- -

Try grouping related settings under 1 or 2 section dividers. If you have any "singletons" -(settings that don't relate to any other settings and can't be grouped under your section -dividers), treat them as follows:

- -
    -
  • If they include some of your most important settings, list them at the top without a section -divider.
    • -
  • Otherwise, list them at the bottom with a section divider called "OTHER", in order of -importance.
    • -
- -
-
- -
-
- -

11 to 15

- -
-
- -

Same advice as above, but try 2 to 4 section dividers.

- -

Also, try the following to reduce the list:

- -
    -
  • If 2 or more of the settings are mainly for power users, move them out of your main Settings -screen and into an "Advanced" subscreen. Place an item in the action overflow called "Advanced" to -navigate to it.
    • -
  • Look for "doubles": two settings that relate to one another, but not to any other settings. -Try to combine them into one setting, using the design patterns described later in this section. -For example, you might be able to redesign two related checkbox settings into one multiple choice -setting.
    • -
- -
-
- -
-
- -

16 or more

- -
-
- -

If you have any instances of 4 or more related settings, group them under a subscreen. Then use -the advice suggested above for the reduced list size.

- -
-
- - -

Design Patterns

- -
-
- -

Checkbox

-

Use this pattern for a setting that is either selected or not selected.

- -
-
- - - -
-
- -
-
- -

Multiple choice

-

Use this pattern for a setting that needs to present a discrete set of options, from which the -user can choose only one.

- -
-
- - - -
-
- -
-
- -

Slider

-

Use this pattern for a setting where the range of values are not discrete and fall along a -continuum.

- -
-
- - - -
-
- -
-
- -

Date/time

-

Use this pattern for a setting that needs to collect a date and/or time from the user.

- -
-
- - - -
-
- -
-
- -

Subscreen navigation

-

Use this pattern for navigating to a subscreen or sequence of subscreens that guide the user -through a more complex setup process.

-
    -
  • If navigating to a single subscreen, use the same title in both the subscreen and the label -navigating to it.
    • -
  • If navigating to a sequence of subscreens (as in this example), use a title that describes the -first step in the sequence.
    • -
- -
-
- - - -
-
- -
-
- -

List subscreen

-

Use this pattern for a setting or category of settings that contains a list of equivalent items. -

-

The label provides the name of the item, and secondary text may be used for status. (In this -example, status is reinforced with an icon to the right of the label.) Any actions associated with -the list appear in the action bar rather than the list itself.

- -
-
- - - -
-
- -
-
- -

Master on/off switch

-

Use this pattern for a category of settings that need a mechanism for turning on or off as a -whole.

-

An on/off switch is placed as the first item in the action bar of a subscreen. When the switch -is turned off, the items in the list disappear, replaced by text that describes why the list is -empty. If any actions require the switch to be on, they become disabled.

- -
-
- - - -
-
- -
-
- -
 
- -

You can also echo the master on/off switch in the menu item that leads to the subscreen. -However, you should only do this in cases where users rarely need to access the subscreen once -it's initially set up and more often just want to toggle the switch.

- -
-
- - - -
-
- -
-
- -

Individual on/off switch

-

Use this pattern for an individual setting that requires a more elaborate description than can -be provided in checkbox form.

-

The on/off switch only appears in the subscreen so that users aren't able to toggle it without -also being exposed to the descriptive text. Secondary text appears below the setting label to -reflect the current selection.

-

In this example, Android Beam is on by default. Since users might not know what this setting -does, we made the status more descriptive than just "On".

- -
-
- - - -
-
- -
-
- -

Dependency

-

Use this pattern for a setting that changes availability based on the value of another setting. -

-

The disabled setting appears below its dependency, without any indentation. If the setting -includes a status line, it says "Unavailable", and if the reason isn't obvious, a brief -explanation is included in the status.

-

If a given setting is a dependency to 3 or more settings, consider using a subscreen with a -master on/off switch so that your main settings screen isn't cluttered by lots of disabled items. -

- -
-
- - - -
-
- -

Defaults

- -

Take great care in choosing default values for each of your settings. Because settings -determine app behavior, your choices will contribute to users' first impressions of your app. Even -though users can change settings, they'll expect the initial states to be sensible. The following -questions (when applicable) may help inform your decisions:

- -
    -
  • Which choice would most users be likely to choose on their own if there were no default?
    • -
  • Which choice is the most neutral or middle-of-the-road?
    • -
  • Which choice is the least risky, controversial, or over-the-top?
    • -
  • Which choice uses the least amount of battery or mobile data?
    • -
  • Which choice best supports the design principle -Never lose my stuff?
    • -
  • Which choice best supports the design principle -Only interrupt -me if it's important? -
    • -
- -

Writing Guidelines

- -

Label clearly and concisely

- -

Writing a good label for a setting can be challenging because space is very limited. You only -get one line, and it's incredibly short on the smallest of devices. Follow these guidelines to -make your labels brief, meaningful, and scannable:

- -
    -
  • Write each label in sentence case (i.e. only the first word and proper nouns are capitalized). -
    • -
  • Don't start a label with an instructional verb like "Set", "Change", "Edit", "Modify", -"Manage", "Use", "Select", or "Choose". Users already understand that they can do these things to -settings.
    • -
  • Likewise, don't end a label with a word like "setting" or "settings". It's already implied. -
    • -
  • If the setting is part of a grouping, don't repeat the word(s) used in the section divider or -subscreen title.
    • -
  • Avoid starting a label with a negative word like "Don't" or "Never". For example, "Don't -allow" could be rephrased to "Block".
    • -
  • Steer clear of technical jargon as much as possible, unless it's a term widely understood by -your target users. Use common verbs and nouns to convey the setting's purpose rather than its -underlying technology.
    • -
  • Don't refer to the user. For example, for a setting allowing the user to turn notifications on -or off, label it "Notifications" instead of "Notify me".
    • -
- -

Once you've decided on labels for your settings, be sure to preview them on an -LDPI handset in portrait to make sure -they'll fit everywhere.

- -

Secondary text below is for status, not description…

- -

Before Ice Cream Sandwich, we often displayed secondary text below a label to further describe -it or provide instructions. Starting in Ice Cream Sandwich, we're using secondary text for status. -

- -
-
- -
Before
- - - - - - - - - - - - -
- Screen timeout -
- Adjust the delay before the screen automatically turns off -
- -
-
- -
After
- - - - - - - - - - - - -
- Sleep -
- After 10 minutes of inactivity -
- -
-
- -

Status in secondary text has the following benefits:

-
    -
  • Users can see at a glance what the current value of a setting is without having to navigate -any further.
    • -
  • It applies the design principle -Keep it brief, which -users greatly appreciate.
    • -
- -

…unless it's a checkbox setting

-

There's one important exception to the using secondary text for status: checkbox settings. -Here, use secondary text for description, not status. Status below a checkbox is unnecessary -because the checkbox already indicates it. The reason why it's appropriate to have a description -below a checkbox setting is because—unlike other controls—it doesn't display a dialog -or navigate to another screen where additional information can be provided.

- -

That said, if a checkbox setting's label is clear enough on its own, there's no need to also -provide a description. Only include one if necessary.

- -

Follow these guidelines to write checkbox setting descriptions:

-
    -
  • Keep it to one sentence and don't use ending punctuation.
    • -
  • Convey what happens when the setting is checked, phrased in the form of a command. Example: -"Allow data exchange", not "Allows data exchange".
    • -
  • Avoid repetition by choosing words that don't already appear in the label.
    • -
  • Don't refer to the user unless it's necessary for understanding the setting.
    • -
  • If you must refer to the user, do so in the second person ("you") rather than the first person -("I"). Android speaks to users, not on behalf of them.
    • -
- -

Writing examples

- -

The following are examples of changes we made to labels and secondary text in the Settings app -in Ice Cream Sandwich.

- -
-
- -
Before
- - - - - - - -
- Use tactile feedback -
- -
-
- -
After
- - - - - - - -
- Vibrate on touch -
- -
-
- -

In this checkbox setting, we eliminated the throwaway word "Use" and rephrased the label to be -more direct and understandable.

- -
- -
- -
-
- -
Before
- - - - - - - - - - - - -
- Screen timeout -
- Adjust the delay before the screen automatically turns off -
- -
-
- -
After
- - - - - - - - - - - - -
- Sleep -
- After 10 minutes of inactivity -
- -
-
- -

In this multiple choice setting, we changed the label to a friendlier term and also replaced -the description with status. We put some descriptive words around the selected value, "10 -minutes", because on its own, the meaning could be misinterpreted as "sleep for 10 minutes".

- -
-
- -
-
- -
Before
- - - - - - - - - - - - -
- Change screen lock -
- Change or disable pattern, PIN, or password security -
- -
-
- -
After
- - - - - - - - - - - - -
- Screen lock -
- Pattern -
- -
-
- -

This setting navigates to a a sequence of subscreens that allow users to choose a type of -screen lock and then set it up. We eliminated the throwaway word "Change" in the label, and -replaced the description with the current type of screen lock set up by the user. If the user -hasn't set up a screen lock, the secondary text says "None".

- -
-
- -
-
- -
Before
- - - - - - - - - - - - -
- NFC -
- Use Near Field Communication to read and exchange tags -
- -
-
- -
After
- - - - - - - - - - - - -
- NFC -
- Allow data exchange when the phone touches another device -
- -
-
- -

In this checkbox setting—although it's technical jargon—we kept the "NFC" label -because: (1) we couldn't find a clear, concise alternative, and (2) user familiarity with the -acronym is expected to increase dramatically in the next couple of years.

-

We did, however, rewrite the description. It's far less technical than before and does a better -job of conveying how and why you'd use NFC. We didn't include what the acronym stands for because -it doesn't mean anything to most users and would have taken up a lot of space.

- -
-
- - - -

Checklist

-
    -

  • Make sure each item in Settings meets the criteria for belonging there.

    • -

  • If you have more than 7 items, explore ways to group related settings.

    • -

  • Use design patterns wherever applicable so users don't face a learning curve.

    • -

  • Choose defaults that are safe, neutral, and fit the majority of users.

    • -

  • Give each setting a clear, concise label and use secondary text appropriately.

    • -
diff --git a/docs/html/design/style/branding.jd b/docs/html/design/style/branding.jd deleted file mode 100644 index 5995d03..0000000 --- a/docs/html/design/style/branding.jd +++ /dev/null @@ -1,128 +0,0 @@ -page.title=Your Branding -page.tags=branding,logo -@jd:body - -

Following Android design patterns doesn't mean that your app has to look the same as -everyone else's. In Android, your app can shine as an extension of your brand.

- -

Color

- - -
-

Material Design

-

UI Color Application

-

- - -

Use your brand color for accent by overriding the Android framework's default blue in UI elements like checkboxes, progress bars, radio buttons, sliders, tabs, and scroll indicators.

- -

Look for opportunities to use high-contrast color for emphasis, for example, as the background color of the action bar or a primary button. But don't go overboard: not all actions are equal, so use it only for the one or two most important things.

-

When customizing colors, touch feedback - should be subtle — just slightly lighter or darker than the untouched color.

- -
 
- -
-
- -
- The four colors of the Google Wallet logo provide a playful accent to the four dots - that appear as the user enters a PIN. -
-
-
- -
- The Google Play Music app has an orange theme color, which is used for emphasis - in the action bar and for accent in the selected tab, scroll indicator, and - hyperlinks. -
-
-
- - - -

Your app's launcher icon is - a key place to incorporate your logo, because it's what - users will look for and touch to begin using your app. You can carry the launcher - icon through to all the screens in your app by showing it in the - action bar along - with the name of the app.

- -

Another approach to consider is to have your logo take the place of the launcher icon -and app name in the action bar.

- - -
 
- -
-
- -
- Google+ reinforces its brand by carrying its launcher icon through to the action bar. -
- -
-
- -
- Example of a the logo in the action bar. This works well in cases where the brand's logo matches the name of the app. -
-
-
- - - - -
-

Material Design

-

Icons

-

- - -

If you have icons that you're already using for your app on other platforms -and they have a distinctive look intended to fit your brand, use them on your -Android app as well. If you take this approach, make sure your brand styling is -applied to every single icon in your app.

- - -
-
-

One exception: For any icon in your existing set where the symbol is different from - Android's, use Android's symbol but give it your brand's styling. That way, users will - understand what the purpose of the icon is based on what they've learned in other - Android apps (Design principle: - Give me tricks that - work everywhere). But the icon will still look like it belongs with all of - your other icons as a part of your brand.

- -
- -
- -
-
-
- -
-
-

Example:
-

-

The brand's normal icon for sharing on other platforms is a right arrow. -

- -
- -
- Don't - Do -
- -
-
- -

What if you don't already have your own icons — for example, if you're creating a -brand new app only for Android? In this case, use Android's standard icons and rely -more on color and logo for branding. Get the Action Bar Icon Pack, available for free -in Downloads.

diff --git a/docs/html/design/style/color.jd b/docs/html/design/style/color.jd deleted file mode 100644 index 4c5f5ab..0000000 --- a/docs/html/design/style/color.jd +++ /dev/null @@ -1,141 +0,0 @@ -page.title=Color -@jd:body - - - - -
-

Material Design

-

Color

-

- - -

Use color primarily for emphasis. Choose colors that fit with your brand and provide good contrast -between visual components. Note that red and green may be indistinguishable to color-blind users.

- -
-
    -
  • #33b5e5
    • -
  • #aa66cc
    • -
  • #99cc00
    • -
  • #ffbb33
    • -
  • #ff4444
    • -
-
- -
-
    -
  • #0099cc
    • -
  • #9933cc
    • -
  • #669900
    • -
  • #ff8800
    • -
  • #cc0000
    • -
-
- -

Palette

- -

Blue is the standard accent color in Android's color palette. Each color has a corresponding darker -shade that can be used as a complement when needed.

-

Download the swatches

- - - - diff --git a/docs/html/design/style/iconography.jd b/docs/html/design/style/iconography.jd deleted file mode 100644 index 8b6f3ab..0000000 --- a/docs/html/design/style/iconography.jd +++ /dev/null @@ -1,601 +0,0 @@ -page.title=Iconography -page.tags="icons" -meta.tags="icons, googleplay, listing, branding" -page.titleFriendly=Guidelines for creating your app's icons -@jd:body - - - - -

An icon is a graphic that takes up a small portion of screen real estate and provides a quick, -intuitive representation of an action, a status, or an app.

- -

When you design icons for your app, it's important to keep in mind that your -app may be installed on a variety of devices that offer a range of -pixel densities, as mentioned in -Devices -and Displays. But you can make your icons look great on all devices -by providing each icon in multiple sizes. When your app runs, Android checks the characteristics of -the device screen and loads the appropriate density-specific assets for your app.

- -

Because you will deliver each icon in multiple sizes to support different densities, -the design guidelines below -refer to the icon dimensions in dp -units, which are based on the pixel dimensions of a medium-density (MDPI) screen.

- - - -

So, to create an icon for different densities, you should follow the 2:3:4:6:8 -scaling ratio between the five primary densities (medium, high, x-high, xx-high, and -xxx-high respectively). For example, consider that the size for a launcher icon is specified to be -48x48 dp. This means the baseline (MDPI) asset is 48x48 px, and the -high-density(HDPI) asset should be 1.5x the baseline at 72x72 px, and the x-high -density (XHDPI) asset should be 2x the baseline at 96x96 px, and so on.

- -

Note: Android also supports low-density (LDPI) screens, -but you normally don't need to create custom assets at this size because Android -effectively down-scales your HDPI assets by 1/2 to match the expected size.

- - - - -

Launcher

- - -
-

Material Design

-

Product Icons

-

- - -

The launcher icon is the visual representation of your app on the Home or All Apps screen. Since the -user can change the Home screen's wallpaper, make sure that your launcher icon is clearly visible on -any type of background.

- -
-
- - - -
-
- - - -
-
- - - -
-
- -
-
- -

Sizes & scale

- -
    -
  • -

    Launcher icons on a mobile device must be 48x48 dp.

    • -
  • -

    Launcher icons for display on Google Play must be 512x512 pixels.

    • -
- -
-
- -

Proportions

- -
    -
  • -

    Full asset, 48x48 dp

    -
    • -
- -
-
- -

Style

-

Use a distinct silhouette. Three-dimensional, front view, with a slight perspective as if viewed -from above, so that users perceive some depth.

- -
-
- - -
-
-   -
-
- - - -
- -
- -
-
- - - -
 
- -
- -
- - -

Action Bar

- - -
-

Material Design

-

System Icons

-

- - -

- -Action bar icons are graphic buttons that represent the most important actions people can take -within your app. Each one should employ a simple metaphor representing a single concept that most -people can grasp at a glance. - -

-

- -Pre-defined glyphs should be used for certain common actions such as "refresh" and "share." The -download link below provides a package with icons that are scaled for various screen densities and -are suitable for use with the Holo Light and Holo Dark themes. The package also includes unstyled -icons that you can modify to match your theme, in addition to Adobe® Illustrator® source -files for further customization. - -

-

-Download the Action Bar Icon Pack -

- -
-
- - - -
-
- - - -
-
- - - -
-
- -
-
- -

Sizes & scale

- -
    -
  • -

    Action bar icons for phones should be 32x32 dp.

    • -
- -
-
- -

Focal area & proportions

- -
    -
  • -

    Full asset, 32x32 dp

    -

    Optical square, 24x24 dp

    -
    • -
- -
-
- -

Style

-

Pictographic, flat, not too detailed, with smooth curves or sharp shapes. If the graphic is thin, -rotate it 45° left or right to fill the focal space. The thickness of the strokes and negative -spaces should be a minimum of 2 dp.

- -
-
- - -
-
- -

Colors

-

Colors: #333333
-Enabled: 60% opacity
-Disabled: 30% opacity

-
 
- -

Colors: #FFFFFF
-Enabled: 80% opacity
-Disabled: 30% opacity

- -
-
- - - -
-
- - -

Small / Contextual Icons

- - -
-

Material Design

-

System Icons

-

- - -

Within the body of your app, use small icons to surface actions and/or provide status for specific -items. For example, in the Gmail app, each message has a star icon that marks the message as -important.

- - -
-
- - - -
-
- - - -
-
- - - -
-
- -
-
- -

Sizes & scale

- -
    -
  • -

    Small icons should be 16x16 dp.

    • -
- -
-
- -

Focal area & proportions

- -
    -
  • -

    Full asset, 16x16 dp

    -

    Optical square, 12x12 dp

    -
    • -
- -
-
- -

Style

-

Neutral, flat, and simple. Filled shapes are easier to see than thin strokes. Use a single visual -metaphor so that a user can easily recognize and understand its purpose.

- -
-
- - -
-
- - - -
 
- -

Colors

-

Use non-neutral colors sparingly and with purpose. For example, Gmail uses yellow in the star icon -to indicate a bookmarked message. If an icon is actionable, choose a color that contrasts well with -the background.

- -
-
- - - -
- -
- - -

Notification Icons

- - -
-

Material Design

-

System Icons

-

- - - -

If your app generates notifications, provide an icon that the system can display in the status bar -whenever a new notification is available.

- - -
-
- - - -
-
- - - -
-
- - - -
-
- -
-
- -

Sizes & scale

- -
    -
  • -

    Notification icons must be 24x24 dp.

    • -
- -
-
- -

Focal area & proportions

- -
    -
  • -

    Full asset, 24x24 dp

    -

    Optical square, 22x22 dp

    -
    • -
- -
-
- -

Style

-

Keep the style flat and simple, using the same single, visual metaphor as your launcher icon.

- -
-
- - -
-
- -

Colors

-

Notification icons must be entirely white. Also, the system may scale down and/or darken the icons.

- -
-
- - - -
- -
- - - - - - - - - - -

Design Tips

- -

Here are some tips you might find useful as you create icons or other -drawable assets for your application. These tips assume you are using -Adobe® Photoshop® or a similar raster and vector image-editing program.

- - - - -

Use vector shapes where possible

- -

Many image-editing programs such as Adobe® Photoshop® allow you to use a -combination of vector shapes and raster layers and effects. When possible, -use vector shapes so that if the need arises, assets can be scaled up without -loss of detail and edge crispness.

- -

Using vectors also makes it easy to align edges and corners to pixel -boundaries at smaller resolutions. - - - -

Start with large artboards

- -

Because you will need to create assets for different screen densities, -it is best to start your icon -designs on large artboards with dimensions that are multiples of the target icon -sizes. For example, launcher icons are 48, 72, 96, or 144 pixels wide, -depending on screen density (mdpi, hdpi, xhdpi, and xxhdpi, respectively). If you -initially draw launcher icons on an 864x864 artboard, it will be easier and -cleaner to adjust the icons when you scale the artboard down to the target -sizes for final asset creation.

- - - -

When scaling, redraw bitmap layers as needed

- -

If you scaled an image up from a bitmap layer, rather than from a vector -layer, those layers will need to be redrawn manually to appear crisp at higher -densities. For example if a 60x60 circle was painted as a bitmap for -mdpi it will need to be repainted as a 90x90 circle for hdpi.

- - - -

Use common naming conventions for icon assets

- -

Try to name files so that related assets will group together inside a -directory when they are sorted alphabetically. In particular, it helps to use a -common prefix for each icon type. For example:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Asset TypePrefixExample
Iconsic_ic_star.png
Launcher iconsic_launcheric_launcher_calendar.png
Menu icons and Action Bar iconsic_menuic_menu_archive.png
Status bar iconsic_stat_notifyic_stat_notify_msg.png
Tab iconsic_tabic_tab_recent.png
Dialog iconsic_dialogic_dialog_info.png
- -

Note that you are not required to use a shared prefix of any -type—doing so is for your convenience only.

- - -

Set up a working space that organizes files by density

- -

Supporting multiple screen densities means you must create multiple versions -of the same icon. To help keep the multiple copies of files safe and easier to -find, we recommend creating a directory structure in your working space that -organizes asset files based on the target density. For example:

- -
-art/...
-    mdpi/...
-        _pre_production/...
-            working_file.psd
-        finished_asset.png
-    hdpi/...
-        _pre_production/...
-            working_file.psd
-        finished_asset.png
-    xhdpi/...
-        _pre_production/...
-            working_file.psd
-        finished_asset.png
-    xxhdpi/...
-        _pre_production/...
-            working_file.psd
-        finished_asset.png
-
- -

Because the structure in your working space is similar to that of the application, you -can quickly determine which assets should be copied to each -resources directory. Separating assets by density also helps you detect any -variances in filenames across densities, which is important because -corresponding assets for different densities must share the same filename.

- -

For comparison, here's the resources directory structure of a typical -application:

- -
res/...
-    drawable-ldpi/...
-        finished_asset.png
-    drawable-mdpi/...
-        finished_asset.png
-    drawable-hdpi/...
-        finished_asset.png
-    drawable-xhdpi/...
-        finished_asset.png
-    drawable-xxhdpi/...
-        finished_asset.png
-
-    mipmap-ldpi/...
-        finished_launcher_asset.png
-    mipmap-mdpi/...
-        finished_launcher_asset.png
-    mipmap-hdpi/...
-        finished_launcher_asset.png
-    mipmap-xhdpi/...
-        finished_launcher_asset.png
-    mipmap-xxhdpi/...
-        finished_launcher_asset.png
-    mipmap-xxxhdpi/...
-        finished_launcher_asset.png
-
- -

For more information about how to save resources in the application project, -see Providing Resources. -

- -

For more information about using the mipmap folders, see -Managing Projects Overview.

- -

Provide an xxx-high-density launcher icon

- -

Some devices scale-up the launcher icon by as much as 25%. For example, if your highest density -launcher icon image is already extra-extra-high density, the scaling process will make it appear -less crisp. So you should provide a higher density launcher icon in the mipmap-xxxhdpi - directory, which the system uses instead of scaling up a smaller version of the icon.

- -

Note: The mipmap-xxxhdpi qualifier is necessary -only to provide a launcher icon that can appear larger than usual on an xxhdpi device. It is best -practice to place all your launcher icons in the res/mipmap-[density]/ folders. This -enables your app to display launcher icons that have a higher density than the device, without -scaling up a lower density version of the icon. You do not need to provide xxxhdpi assets for all -your app's images.

- -

See Supporting Multiple Screens for -more information.

- - -

Remove unnecessary metadata from final assets

- -

Although the Android SDK tools will automatically compress PNGs when packaging -application resources into the application binary, a good practice is to remove -unnecessary headers and metadata from your PNG assets. Tools such as OptiPNG or Pngcrush can ensure that this -metadata is removed and that your image asset file sizes are optimized.

- - diff --git a/docs/html/design/style/metrics-grids.jd b/docs/html/design/style/metrics-grids.jd deleted file mode 100644 index 97915b8..0000000 --- a/docs/html/design/style/metrics-grids.jd +++ /dev/null @@ -1,90 +0,0 @@ -page.title=Metrics and Grids -page.metaDescription=Optimize your app's UI by designing layouts based on density-independent grids. -page.tags="layout","screens" -meta.tags="multiple screens, layout, tablets" -page.image=/design/media/metrics_closeup.png -@jd:body - - - -
-

Material Design

-

Metrics and Keylines

-

- - - -

Devices vary not only in physical size, but also in screen density (DPI). To simplify the way you design for multiple screens, think of each device as -falling into a particular size bucket and density bucket:

-
    -
  • The size buckets are handset (smaller than -600dp) and tablet (larger than or equal 600dp).
    • -
  • The density buckets are LDPI, MDPI, HDPI, XHDPI, XXHDPI, and XXXHDPI.
    • -
- -

Optimize your application's UI by designing -alternative layouts for some of the different size buckets, and provide alternative bitmap images -for different density buckets.

- -

Because it's important that you design and implement your layouts for multiple densities, -the guidelines below and throught the documentation -refer to layout dimensions with dp measurements instead of pixels.

- - -
-
- - - -
-
- -

Space considerations

-

Devices vary in the amount of density-independent pixels (dp) they can display.

-

To see more, visit the - -Screen Sizes and Densities Device Dashboard.

- -
-
- - -

48dp Rhythm

- -

Touchable UI components are generally laid out along 48dp units.

- - - -
 
- -

Why 48dp?

-

On average, 48dp translate to a physical size of about 9mm (with some variability). This is -comfortably in the range of recommended target sizes (7-10 mm) for touchscreen objects and users -will be able to reliably and accurately target them with their fingers.

-

If you design your elements to be at least 48dp high and wide you can guarantee that:

-
    -
  • your targets will never be smaller than the minimum recommended target size of 7mm regardless of - what screen they are displayed on.
    • -
  • you strike a good compromise between overall information density on the one hand, and - targetability of UI elements on the other.
    • -
- - - -
 
- -

Mind the gaps

-

Spacing between each UI element is 8dp.

- -

Examples

- - diff --git a/docs/html/design/style/themes.jd b/docs/html/design/style/themes.jd deleted file mode 100644 index 6c8169b..0000000 --- a/docs/html/design/style/themes.jd +++ /dev/null @@ -1,53 +0,0 @@ -page.title=Themes -@jd:body - -
-
- - -
- Gmail in Holo Light. -
- - -
- Settings in Holo Dark. -
- -
-
- - - -
-

Material Design

-

Color Themes

-

- - - -

Themes are Android's mechanism for applying a consistent style to an app or activity. -The style specifies the visual properties of the elements that make up your user interface, -such as color, height, padding and font size. To promote greater cohesion between all apps -on the platform, Android provides two system themes that you can choose from when building apps:

-
    -
  • Holo Light
    • -
  • Holo Dark
    • -
-

Applying these themes will go a long way in helping you to build apps that fit right into the -general visual language of Android.

-

Pick the system theme that best matches the needs and design aesthetics for your app. If your -desire is to have a more distinct look for your app, using one of the system themes as a starting -point for your customizations is a good idea. The system themes provide a solid foundation on top -of which you can selectively implement your own visual stylings.

- -
-

Developer Guide

-

For information about how to apply themes such as Holo Light and Dark, and - how to build your own themes, see the - Styles and Themes API guide.

-
- -
-
diff --git a/docs/html/design/style/touch-feedback.jd b/docs/html/design/style/touch-feedback.jd deleted file mode 100644 index e1fac2f..0000000 --- a/docs/html/design/style/touch-feedback.jd +++ /dev/null @@ -1,95 +0,0 @@ -page.title=Touch Feedback -page.tags=input,button -@jd:body - -
-
- - -
-

Material Design

-

Responsive Interaction

-

- - - -

Use illumination and dimming to respond to touches, reinforce the resulting behaviors -of gestures, and indicate what actions are enabled and disabled.

- -

Be responsive to touches in a gentle way. Whenever a user touches an -actionable area in your app, let them know the app is "listening" by providing a visual -response. Make it subtle —just slightly lighter or darker than the untouched color. This -provides two benefits:

- - - -
- -
- -
-
Click image to replay...
-
-
- -

States

- - -
 
- - -
- Most of Android's UI elements have touch feedback built in, including - states that indicate whether touching the element will have any effect. -
- -
 
- -
-
- -

Communication

-

When your objects react to more complex gestures, help users -understand what the outcome will be.

- -

In Recents, when a user starts swiping a thumbnail left or right, it -begins to dim. This helps the user understand that swiping will cause the -item to be removed.

-
-
- - - -
-
-
 
- -
-
- - -

If a user attempts to scroll past the last home screen panel, the screen - content tilts to the right to indicate that further navigation in this direction - isn’t possible.

- -
-
- -

Boundaries

-

- When users try to scroll past the beginning or end of a scrollable area, - communicate the boundary with a visual cue. Many of Android's scrollable UI - widgets, like lists and grid lists, have support for boundary feedback built - in. If you’re building custom widgets, keep boundary feedback in mind and - provide it from within your app. -

diff --git a/docs/html/design/style/typography.jd b/docs/html/design/style/typography.jd deleted file mode 100644 index af76c40..0000000 --- a/docs/html/design/style/typography.jd +++ /dev/null @@ -1,78 +0,0 @@ -page.title=Typography -page.tags="textview","font" -page.metaDescription=How to use typography in your Android apps. -@jd:body - -
-
- - - -
- - -
-

Material Design

-

Typography

-

- - -
- -

- Download Roboto -

- -

The Android design language relies on traditional typographic tools such as scale, space, rhythm, -and alignment with an underlying grid. Successful deployment of these tools is essential to help -users quickly understand a screen of information. To support such use of typography, Ice Cream -Sandwich introduced a new type family named -Roboto, created -specifically for the requirements of UI and high-resolution screens.

- -

The current {@link android.widget.TextView} framework offers Roboto in thin, light, regular and bold -weights, along with an italic style for each weight. The framework also offers the -Roboto Condensed -variant in regular and bold weights, along with an italic style for each weight.

- - - -

Specimen Book

- -
-
- -
- -
-
- -

Default type colors

-

The Android UI uses the following default color styles: textColorPrimary and -textColorSecondary. For light themes use textColorPrimaryInverse and -textColorSecondaryInverse. The framework text color styles also support variants for -touch feedback states when used inside UI elements.

- - - -
-
- -

Typographic Scale

-

Contrast in type sizes can go a long way to create ordered, understandable layouts. However, too -many different sizes in the same UI can be messy. The Android framework uses the following limited -set of type sizes:

- - - -

Users can select a system-wide scaling factor for text in the Settings app. In order to support -these accessibility features, type should be specified in scale-independent pixels -(sp) -wherever possible. Layouts supporting scalable types should be tested against these settings.

- -
-
diff --git a/docs/html/design/style/writing.jd b/docs/html/design/style/writing.jd deleted file mode 100644 index 0c62a55..0000000 --- a/docs/html/design/style/writing.jd +++ /dev/null @@ -1,322 +0,0 @@ -page.title=Writing Style -page.tags=dialog,toast,notification -@jd:body - -

Android's Voice

- -

When writing text that appears in your app, keep it concise, simple, and friendly.

- -

Concise

- -
    -
  • Describe only what the user needs to know.
    • -
  • Eliminate redundancy, such as titles that restate the body of an information box.
    • -
  • Keep text as short as possible.
    • -
- -

Avoid wordy, stilted text

- -
-
- -
Don't
- -
- Consult the documentation that came with your phone for further instructions. -
- -
-
- -
Do
- -
- Read the instructions that came with your phone. -
- -
-
- -

Don't provide unnecessary information

- -
-
- -
From a Setup Wizard screen
- - - - - - - - - - - - -
- Signing in... -
- Your phone needs to communicate with
- Google servers to sign in to your account.
- This may take up to five minutes. -
- -
-
- -
From a Setup Wizard screen
- - - - - - - - - - - - -
- Signing in... -
- Your phone is contacting Google.
- This can take up to 5 minutes. -
- -
-
- -

Simple

- -
    -
  • Use short words, active verbs, and common nouns.
    • -
  • Put the most important thing first. “Front-load” the first 11 characters - with the most salient information in the string.
    • -
  • Don’t try to explain subtle differences. They are lost on most users.
    • -
- -

Focus on the user's concern, not technical details

- -
-
- -
Don't
- -
- Manually control GPS to prevent other apps from using it -
- -
-
- -
Do
- -
- To save power, switch Location mode to Battery saving -
- -
-
- -

Put top news first

- -
-
- -
Don't
- -
- 77 other people +1’d this, including Larry Page -
- -
-
- -
Do
- -
- Larry Page and 76 others +1’d this -
- -
-
- -

Put the user's goal first

- -
-
- -
Don't
- -
- Touch Next to complete setup using a Wi-Fi connection -
- -
-
- -
Do
- -
- To finish setup using Wi-Fi, touch Next -
- -
-
- - -

Friendly

- -
    -
  • Use contractions.
    • -
  • Talk directly to the reader. Use “you” to refer to the reader.
    • -
  • Keep your tone casual and conversational, but avoid slang.
    • - -
- -

Avoid being confusing or annoying

-
-
-
Don't
- - - - - - - - - - - -
- Sorry! -
- Activity MyAppActivity (in application
- MyApp) is not responding -
- -
-
-
Do
- - - - - - - - - - - -
- MyApp isn’t responding -
- Do you want to close it? -
-
-
- - -

Words to avoid

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Don't useUse
one, two, three, four, ...1, 2, 3, 4, ...
applicationapp
cannot, could not, do not, did not -will not, you willContractions: can’t, couldn’t, don’t, didn’t won’t, you’ll, and so on
okay, okOK
please, sorry, thank youAttempts at politeness can annoy the user, especially in messages that say - something has gone wrong.
- Exception: In Japanese, “please” is mandatory and imperative verbs should - be localized accordingly (turn on -> please turn on). -
there is, there are, it is
- and other “disappeared” subjects (grammatical expletives)		Use a noun as the subject
abort, kill, terminatestop, cancel, end, exit
fail, failed, negative languageIn general, use positive phrasing
- (for example, “do” rather than “don’t,” except in cases such as “Don’t show - again,” “Can’t connect,” and so on.)
me, I, my, mineyou, your, yours
Are you sure? Warning!Tell user the consequence instead, for example, “You’ll lose all photos - and media”
- -
- -

Formatting text

- -

Capitalization

- -
    -
  • Use sentence-style capitalization for all UI strings: “Words to live by.”
    • -
  • Capitalize all important words in: -
      -
    • App names (Calendar, Google Drive)
      • -
    • Named features (Android Beam, Face Unlock)
      • -
    • Proper nouns (Statue of Liberty, San Francisco Giants)
      • -
    -
    • -
  • Be conservative. Don't capitalize words that aren't part of a formal feature name: -
      -
    • Sim card lock, Home screen, not Sim Card Lock, Home Screen.
      • -
    -
    • -
- - -

Punctuation

-
    -
  • Period. Don't use a period after a single sentence or - phrase used in isolation, such as in a toast, label, or notification. Wherever two or - more sentences run together, use a period for each sentence.
    • -
  • Ellipsis. Use the ellipsis character (…) (Option-; on MacOS and … - in HTML) to indicate -
      -
    • Incompleteness, such as an action in progress (“Downloading...”) or truncated text.
      • -
    • That a menu item (such as Print… or Share…) leads to further UI involving significant - choices. Exception: Commands whose wording already implies further (but limited) UI, such - as Find in page or Pick a date, do not require an - ellipsis.
      • -
    -
    • -
diff --git a/docs/html/design/videos/index.jd b/docs/html/design/videos/index.jd deleted file mode 100644 index 3845b44..0000000 --- a/docs/html/design/videos/index.jd +++ /dev/null @@ -1,130 +0,0 @@ -page.title=Videos -@jd:body - -

The Android Design Team presents design-oriented sessions at Google I/O every year. Visit these pages to view the videos and presentations from the conferences.

- - - -
 
- -
-
-

Enchant, Simplify, Amaze: Android's Design Principles

-

Want to enchant people, simplify their lives, and make them feel amazing with your app? Learn how Android's Design Principles can help you create products that resonate with people. Find out about the meaning and research behind the principles. See real-world examples and practices from the Android Design team. Discover techniques for applying the principles in your daily work. No design experience necessary.

-
-
- -
-
- -
 
- -
-
-

Structure in Android App Design

-

Life is simple when your app is simple. But when your apps gets more complex, how do you choose between spinners, tabs, and drawers for navigation? Members of the Android Design team look at techniques for making your app predictable and pleasing to use.

-
-
- -
-
- -
 
- -
-
-

Fireside Chat with the Android Team

-

Pull up a chair and join the Android platform team for a fireside chat. It's your opportunity to ask us about the platform and learn a little bit more about why things work the way they do, from the people who built it.

-
-
- -
-
- -
 
- -
-
-

Agile UX Research Practice in Android

-

In the Android UX team, it is critical to get user feedback frequently and consistently so that we are able to iterate and develop the best-in-class designs for our users. We will discuss how the team applied "Pulse Studies" (iterative research sessions) in order to put new ideas, designs, and concepts in front of users on a regular basis; it requires minimal advance planning, it can have an immediate product impact, and it can meet urgent needs.

-
-
- -
-
- -
 
- -
-
-

Cognitive Science and Design

-

This session will provide an in-depth look at human perception and cognition, and its implications for interactive and visual design. The human brain is purely treated as an information processing machine, and we will teach the audience its attributes, its advantages, its limitations, and generally how to hack it.

-
-
- -
-
- - - -
 
- -
-
-

Android Design for Success

-

You have a great idea for an Android app. You want it to stand out among hundreds of thousands. You want your users to love it and tell everyone they know. The Android User Experience team is here to help. We talk about the Android Design guide and other tricks of the trade for creating apps that delight users and help them accomplish their goals. No design background is required.

-
-
- -
-
- -
 
- -
-
-

Android Design for Engineers

-

Design isn't black magic, it's a field that people can learn. In this talk two elite designers from Google give you an advanced crash course in interactive and visual design. Topics include mental models, natural mappings, metaphors, mode errors, visual hierarchies, typography and gestalt principles. Correctly applied, this knowledge can drastically improve the quality of your work.

-
-
- -
-
- -
 
- -
-
- -

An app is useless if people can't find their way around it. Android introduced big navigation-support changes in 3.0 and 4.0. The Action Bar offers a convenient control for Up navigation, the Back key's behavior became more consistent within tasks, and the Recent Tasks UI got an overhaul. In this talk, we discuss how and why we got where we are today, how to think about navigation when designing your app's user experience, and how to write apps that offer effortless navigation in multiple Android versions.

-
-
- -
-
- -
 
- -
-
-

So You've Read the Design Guide; Now What?

-

The Android Design Guide describes how to design beautiful Android apps, but not how to build them. In this talk we give practical tips for how to apply fit & finish as you implement your design, we show you how to avoid some common pitfalls, we describe some useful patterns, and show how tools can help.

-
-
- -
-
- -
 
- -
-
-

Playing with Patterns

-

Best-in-class application designers and developers talk about their experience in developing for Android, showing screenshots from their app, exploring the challenges they faced, and offering creative solutions congruent with the Android Design guide. Guests are invited to show examples of visual and interaction patterns in their application that manage to keep it simultaneously consistent and personal.

-
-
- -
-
- -

Videos for the entire Design Track can also be found on the Android Developers Channel on YouTube.

-- cgit v1.1