Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

DELETE WHEN FINISHED

  • what should be in the toolbar

  • Clear definition of a toolbar

    • Only for Table, Widget-content, List

    • Not addressing Page level actions, Cards, Pop overs

  • general guidelines page addressing different types for different components

  • Should the Table (Widget) section of the toolbar be removed

  • Structure

    • (question) do we have a vertical toolbar? - no

      (question) take 2 rows? - no

Related Pages: << Links to related pages, if relevant >>

Description

A toolbar is a grouped set of buttons and other types of components used to apply action to data

<< Most communicative screenshot of the component >>

Types 

<< Relevant only if the component has several distinct types (e.g. editable tables, nested tables). In this case, each type should be described in a sub-page. The main page should be used only for the common grounds of the component>>

...

Type

...

Usage

...

Image

...

Link to the relevant page

...

 

...

Link to the relevant page

...

 

Usage & Behavior

General guidelines

Structure

...

Table of Contents

Description

A toolbar is a grouped set of controls, allowing users to perform actions on related content.

...

Usage & Behavior

The toolbar may apply to the whole page, or be associated with a data table, list, or chart.

Type

Image

Data Table

Image Added

List

Image Added

Chart

Image Added

Page

My schedule- group textual.pngImage Added

General guidelines

Structure

  • The toolbar is shown as a horizontal, single row.

  • It may contain one or more controls.

Placement and Positioning

  • The toolbar is located on top of a data container (Data table, Widget, List Etc…) and takes the full area (e.g. the data table).

  • It uses the maximum width of the data set In some casesarea.

  • Where relevant, the row of a toolbar can accommodate additional non-related components (e.g. a widget with a title text)Right-aligned- actions toolbar should be divided into two areas:

    • Action area - aligned to the left, including controls that impact the data (e.g. delete).

    Left
    • View area - aligned

    - actions impacting
    • to the right, including controls that impact the view of the data (e.g. print, search, change view mode etc.).
      If there is only a view area, it will be aligned to the left, depending on the context of the user flow.

Content

  • A toolbar

...

  • may include:

    • a variety of

...

...

Internal Logic

<<if there is a certain mechanism that cannot be separated from the component. See example: Data tables internal logic >>

States

According to Buttons states

Interaction

<<for example, how to change value – type, arrows, use slider. See example: Numeric stepper interaction>>

Validations and errors

According to Buttons states

Transitions

<<Where possible describe shortly and demonstrate transitions or animations of the component pattern with animated GIF>>

Best practices

<Whenever a recommendation (not a must) is provided>>

Use:

  • <…>

  • <…>

Don’t use

  • <…>

  • <…>

General

  • <…>

 

Future Version (TBD)

< Edge cases, uncertain aspects, incomplete description>

  • <…>

  • <…>

    • and a Search component.

    • information items, such as counters and statuses (See data table example above).

  • Dialog Buttons cannot be used within a toolbar.

  • If there are sets of controls (for example, table-level actions vs. row-level actions), they should be separated by a vertical divider.

  • In case of a large number of items, a three-dotted Icon Button may be used, allowing users to open an Action Menu (see the chart example above). In this case, the icon button will be the last control.

Internal Logic

  • Toolbar controls can be applied to selected items or the entire related content.

  • Toolbar controls can be enabled/disabled in response to data selection (e.g., a Delete control will be disabled if no data was selected).

States

The toolbar itself has no states. Each control on the toolbar will behave according to its own states.

Validations and errors

The toolbar itself has no validations or errors. Each control on the toolbar may have its own validations.

Best practices

Use:

  • if the user can perform actions or change the view of the related content.

  • if the related content allows multi selection.

Don’t use:

  • On a single-selection data table, if all actions can be performed only at a row-level.

  • If a ribbon pattern is used.

General:

  • Where possible, consider using only Icon Buttons, with corresponding Tooltips.

  • Icon buttons with text should be used to emphasize one or two specific actions.

Accessibility Compliance

Unless otherwise specified, see our general compliance information in Fundamentals - Accessibility.

Design

Zeplin link

Screen thumbnail

<<Short Zeplin link. You
Use this

>>

<<Screen with 200 width>>

Code

<<a box containing the code - when there is no code to present use the Coming Soon GIF>>

...

Delete at the end anything below this

How much to hide - Burger menu?

should tags be used?

Links -

...

Sap

...

toolbar cannot come together with Ribbon.

Examples

Image Removedhttps://

zpl.io/

2p6N8QQImage Removed

https://zpl.io/V4myolN

Image Removed

Image Removed

aB4Eedp

Image Removed

https://zpl.io/br8Njl5

Image Removed

https://zpl.io/begRk0p

Image Removed

https://zpl.io/aNzWlZa

Image Removed

https://app.zeplin.io/project/5979abf9bd8c83d7af16e80a/screen/5c5161dd9696de3093d54226/

Image Removed

https://zpl.io/2p9DX8N

Image Added

Code

...