Lead:  Shani Laendler (Unlicensed) -  ONGOING 

Description

<< Short description of the component and when it is used >>

Usage & Behavior

General guidelines

Structure

1. Header:

   1. Widget name and additional information

   2. Actions: action icons and/or action menu

2. Content area

Placement and Positioning

• A widget can be placed anywhere in a page.
  Its location in comparison to other widgets will determine the possible expansion directions.

• In dashboards and dashboard-like pages, the widgets should be visually distinct from one another and from other elements on screen. The background of such spaces should support that, for example:
  

  

Content

• Widget header is aligned left.

• Additional information is aligned to the header, separated by a line separator. It should be short and informative.

  • Avoid presenting a long description that will not be presented to its full under various responsive states.

  • When space is constrained, it will be truncated. The full information will be presented in tooltip.

• Action icon buttons:

  • Includes only actions that are widget-related and NOT content-related (e.g. expand/collapse widget, maximize widget, delete widget, configure widget, etc.). Content-related actions will be presented within the content area only.

  • Actions are presented in hover

  • Up to 3 main actions will be presented using icon buttons. Additional secondary actions will be presented in an actions menu.

  • In some cases all actions can be presented in the action menu, especially when no action is a primary or important or when space is constrained:

    

  • When space is constrained, all actions may be moved to the actions menu.

Internal Logic

Tabbed Widget

Multiple content types can be gathered under a single widget, using tabs.

• The tabs replace the widget header and the additional information

• The action button refer to the widget as a hole (all 3 tabs together)

Widget Configuration

Generally speaking, all configurations should be saved per user for future sessions, so that if a user changes a widget location or resize it, it will remain in its new position/size for future sessions.

• Expand-collapse
  In some cases the widget can be collapsed. This option will be available from the action buttons area.
  The widget will be collapsed and expanded in animation
  

  

• Drag
  some widgets, especially on dashboard or dashboard-like pages, can be dragged to change their location.

  • In hover over the header area the mouse cursor will change to dragging state:

    

  • A drag handle may also be presented (always or in hover only), and will be placed left to the header:

    

• Resize: Some widgets can be resized.
  In hover over the resizable boundary line:

  • The mouse cursor will change to drag horizontally/vertically/diagonally

  • The boundary line will be visually presented as resizable

  • The hover and resize area should be at list 6 pixels wide.

States

State	Image
Regular
Hover
Active	-
Disabled	TBD - graphic design
Error	-
Focused	-
Focused Hover	-
Focused Active	-
Focused Disabled	-

Interaction

State	Image	Description
Regular
Hover		Action buttons are presented Text truncated (when relevant)
Hover - header
Hover - boarder line
Resize		Text truncated (when relevant) All actions are moved to the action menu (when relevant)
Collapse (click on Collapse icon button, or select ‘Collapse’ in menu)		The content area is collapsed in animation The ‘Collapse’ button is changed to 'Expand'

Validations and errors

No validation or error

Transitions

Expand collapse will be in animation. TBD - Graphics

Best practices

<<e.g. Slider should display a label its on>>

Use:

• In dashboards

• When an item stands by it’s own and should be configurable in size and location

• On spaces with more than 1 widget

• <…>

Don’t use:

• As a single widget in a page

• <…>

Future Version (TBD)

< Edge cases, uncertain aspects, incomplete description>

• <…>

• <…>

Accessibility compliance

<<In general each component should be A11y complied,  please follow the 3 guidelines linked below. At the very least we should document that each component is in compliance with each of the 3>>

Focus management

<<Does this component/Pattern requires specific handling?>>

See general guidelines described in /wiki/spaces/UX/pages/308969693

Screen reader support 

<<Does this component/Pattern requires specific handling?>>

See general guidelines described in /wiki/spaces/UX/pages/308248620

Contrast & size compliance

<<Does this component/Pattern requires specific handling?>>

Are taken into consideration. For more information see general guidelines described in Contrast + Font Size Guidelines

Design

Code

<<a box containing the code - discuss with Femi>>