Lead: Rotem Avidan (Unlicensed) -
| Status | ||||
|---|---|---|---|---|
|
| Table of Contents | ||||
|---|---|---|---|---|
|
Description
The card is an expanded container an expanded container of content and actions for single item.
Usage & Behavior
A card is a supplementary surface of content and actions for a one selected topic.
The card should be easy to scan and aiming at what action can be done at him.
Card status can be read or edit.
General guidelines
Structure
The card elements are:
1. The Card Body
The Card body has two state mode - read and edit.
This part will include the expanded information of the selected single subject which will display by:
A. Filed / Text
Using text or filed follow the card state mode (
...
readable or edit)
B. Status icons (optional)
Status icons display more indication and may be status or toggle
2. Action bar (optional)
The action bar includes more optional actions that affected on the single subject
...
...
Positioning and Size
1. The card will display as part of the Detail Pane
2. The card width is fixed - 280px and height may change follow the content
3. The card will not have an inside scroll
4. The card can not be drag and move
States
Usage
Card with not information not information vs. Card with information
...
Mode
View state mode - is when the card is unselected, the information will display but with out the action
...
Edit state mode - is when the card is selected, the the information and action will display 
...
Validations and Errors
1. The card doesn't have validation and errors as an item
2. The card context can have validation and errors - see Field Validation
Best practices
Using Card's fields and buttons clear and understandable what they are aiming to.
Keeping elements on hierarchy layout - first context and then action.
When to use card
1. If you have a massive workspace and you need to give more information specific for an item
...
2. Using Card when is needed seeing the expand information next to the selected single item, if it is not - use the Popup
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
<<How will the component work with keyboard only - without a mouse. Can be reference if written above
We already set a general guidelines described in Keyboard & Focus Management Guidelines >> >>
Screen reader support
<<Make sure the components support screen reader for content or behaviour where needed - see Screen Reader Guidelines >>
Contrast & size compliance
<<Visual designers must comply with the minimal of Contrast + Font Size Guidelines for each component>>
Design
Zeplin link | Screen thumbnail |
|---|---|
<<Zeplin Link>> | |
Code
<<a box containing the code - discuss with Femi>>
...