@czi-sds/mcp 0.5.2 → 0.5.4

package/data/zeroheight-exports/Responsive-Design.md

@@ -30,6 +30,10 @@ Header Navigation has been designed to collapse into a hamburger menu on narrow
 | --------------------- | -------------------- | -------------------- |
 | `--sds-breakpoint-sm` | `$sds-breakpoint-sm` | `breakpoints.sds-sm` |
 
+**Breakpoint_small**
+
+---
+
 #### Medium
 
 _Screens between 512px-1023px wide_
@@ -42,6 +46,10 @@ Depending on the number of nav items in the Header Navigation it will either col
 | --------------------- | -------------------- | -------------------- |
 | `--sds-breakpoint-md` | `$sds-breakpoint-md` | `breakpoints.sds-md` |
 
+**Breakpoint_medium**
+
+---
+
 #### Large
 
 _Screens >1024px wide_
@@ -52,6 +60,10 @@ Large breakpoint will be used when applications are viewed on large laptops, des
 | --------------------- | -------------------- | -------------------- |
 | `--sds-breakpoint-lg` | `$sds-breakpoint-lg` | `breakpoints.sds-lg` |
 
+**Breakpoint_large**
+
+---
+
 ### Typography
 
 SDS has two sets of typography, one for narrow screens and one for wide. Narrow screen typography is used when applications are viewed at the Small breakpoint (screen widths of less than 512px) and wide screen typography is used when applications are viewed at Medium or Large breakpoints (screen widths of 512px or greater).
@@ -63,18 +75,58 @@ Below are a few visual examples of the differences. See the Typography section f
 | Header XXL – wide | Header XXL – narrow |
 | :---------------- | :------------------ |
 
+**headerXxl_wide**
+
+---
+
+**headerXxl_narrow**
+
+---
+
 | Body L – wide | Body L – narrow |
 | :------------ | :-------------- |
 
+**bodyL_wide**
+
+---
+
+**bodyL_narrow**
+
+---
+
 | Caps XXS – wide | Caps XXS – narrow |
 | :-------------- | :---------------- |
 
+**capsXxs_wide**
+
+---
+
+**capsXxs_narrow**
+
+---
+
 | Tabular S – wide | Tabular S – narrow |
 | :--------------- | :----------------- |
 
+**tabularS_wide**
+
+---
+
+**tabularS_narrow**
+
+---
+
 | Code S – wide | Code S – narrow |
 | :------------ | :-------------- |
 
+**codeS_wide**
+
+---
+
+**codeS_narrow**
+
+---
+
 ## Code
 
 ## Overview

package/data/zeroheight-exports/Search-Input.md

@@ -16,7 +16,25 @@ Click on each state below to enter inspect view and get details on its code attr
 | **Default** | **Hover** | **Default** | **Focus** | **Disabled** |
 | ----------- | --------- | ----------- | --------- | ------------ |
 
+**InputSearch**
 
+---
+
+**InputSearch**
+
+---
+
+**InputSearch**
+
+---
+
+**InputSearch**
+
+---
+
+**InputSearch**
+
+---
 
 ### Small Search Input
 
@@ -27,13 +45,35 @@ Used in napari.org for searches within a given page.
 | **Default** | **Hover** | **Default** | **Focus** | **Disabled** |
 | ----------- | --------- | ----------- | --------- | ------------ |
 
+**InputSearch**
+
+---
+
+**InputSearch**
+
+---
+
+**InputSearch**
+
+---
+
+**InputSearch**
+
+---
+
+**InputSearch**
+
+---
+
 ---
 
 ### Search Input Spacing
 
 These rules establish how much margin should exist between and around elements.
 
+**Search Input spacing**
 
+---
 
 ## Code
 
@@ -49,5 +89,3 @@ These rules establish how much margin should exist between and around elements.
 ### InputSearch
 
 Storybook
-
-

package/data/zeroheight-exports/Search.md

@@ -23,7 +23,9 @@ Search is a flexible way for users to find data of interest or filter down their
 
 Search results are displayed on the current page by filtering down the visible content within the searchable area(s) to show matches only. This search is the most common pattern; it is used both at the component and the page levels.
 
+**napari hub + org_On-page Results flow_Overview**
 
+---
 
 ---
 
@@ -33,20 +35,26 @@ It is recommended to position your Search Input at the top level of the content
 
 For example, if the search will display results for a list of plugins (1), position the Search Input at the top of the list (2).
 
+**On-page Results – 1**
+
+---
+
 #### **2. Search Initiated by User**
 
 Search is initiated when the user clicks a button, hits “enter”, or completes some other user action.
 
 This method is recommended when search results must be fetched from the backend, or when the user needs to set up other specifications before initiating the search.
 
-
-
 #### **3.** Results Displayed in Searched Content Area
 
 Results are displayed by filtering the content in the searchable area (1) so that only search results are visible.
 
 If there are no results, it is recommended that a “No Results” blank state is displayed in the content area instead.
 
+**On-page Results – 3**
+
+---
+
 #### 4. User Takes Action on Results
 
 Depending on the product and the user’s workflow, users may take a number of next actions on the results, possibly including:
@@ -56,6 +64,10 @@ Depending on the product and the user’s workflow, users may take a number of n
 - Filter search results (3).
 - Interact with results, such as selecting a single result (4).
 
+**On-page Results – 4**
+
+---
+
 ---
 
 ### Use Case Examples
@@ -79,7 +91,9 @@ That being said, for the On-page Results flow, keep in mind:
 
 Search results are displayed on a different page than where the search was originally initiated. Depending on the use case, this may be a unique “Results” page, or an existing page where the data is usually located. The Results Page flow is often combined with the On-page Results flow. Learn more about Combining Search Types.
 
+**napari hub + org_Results Page flow_Overview**
 
+---
 
 ---
 
@@ -89,7 +103,9 @@ It is recommended to position Search Inputs at the top level of the content the
 
 For example, if the search will display results from across the whole site (1), position the Search Input in a top-level navigation or outside of the page content hierarchy (2).
 
+**Results Page – 1**
 
+---
 
 #### 2. **Search Initiated by User**
 
@@ -97,7 +113,9 @@ Search is initiated when the user clicks a button (1), hits “enter” (2), or
 
 Because results will be displayed on a new page, Live Search is not recommended.
 
+**Results Page – 2**
 
+---
 
 #### 3. Results Displayed on the Results page
 
@@ -107,7 +125,9 @@ The results page format depends on the product's use case and content. In the ex
 
 If there are no results, it is recommended to display a bank state on the results page.
 
+**Results Page – 3**
 
+---
 
 #### 4. User Takes Action on Results
 
@@ -117,7 +137,9 @@ Depending on the product and the user’s workflow, they may take a number of ne
 - Interact with results, like drilling down into a single result (2) .
 - Filter or Sort Results.
 
+**Results Page – 4**
 
+---
 
 ---
 
@@ -137,8 +159,16 @@ This section will describe search in some use cases currently used across CZI pr
 
 When searching the Menu Items within a Dropdown Menu, it is recommended to use the On-Page Results flow type. Why? Think of the Dropdown Menu as the “page” and the Menu Items as the content being searched. As the user searches, the content is filtered down without leaving the open Dropdown Menu.
 
+**Search within Dropdown Menu flow**
+
+---
+
 The following behaviors are recommended for displaying search results within a Dropdown Menu.
 
+**Search within Dropdown Menu behavior**
+
+---
+
 ## Other Considerations
 
 | Search is a complex component, and is highly subjective to each product's use case. While it's impossible to support and document every use case, here is a collection of patterns that may be useful to consider when implementing it. The patterns detailed below have not been developed by the SDS team and are simply examples pulled from products that utilize the SDS components. |     | **Jump to pattern:** Combining Search Types Supporting User Behavior |
@@ -154,12 +184,32 @@ Depending on the use case, there may be a need to combine multiple flow types. H
 
 In most use cases for the Results Page flow, it can be beneficial to provide users with a way to modify their search results by implementing the On-page Results flow within a Results Page design.
 
+**Results Page + On-page Results flow**
+
+---
+
 ---
 
 ## Patterns to Support User Behavior
 
 Below are some example behavior patterns worth considering to help support users in their searching. Evaluate if implementing these will help users’ workflows and if the product can support any technical requirements of implementation.
 
+**Display Search Results Count**
+
+---
+
+**Highlight Search Results**
+
+---
+
+**Surface Deep Results**
+
+---
+
+**Sort Results by a Display Order**
+
+---
+
 ---
 
 Search is a flexible way for users to find data of interest or filter down their data by a keyword. This allows users to take action on the available data without the distraction of irrelevant information.
@@ -179,6 +229,10 @@ CZ GEN EPI only uses the On-page Results flow pattern for adding search or filte
 
 Search results are displayed on the current page by filtering down the visible content within the searchable area(s) to show matches only. This search is the most common pattern; it is used both at the component and the page levels.
 
+**CZ GE_On-page Results flow_Overview**
+
+---
+
 ---
 
 #### **1. User types keyword into Search Input**
@@ -187,6 +241,10 @@ It is recommended to position the Search Input at the top level of the content t
 
 For example, if the search will display results for a single Table (1), position the Search Input at the top of the table (2).
 
+**On-page Results – 1**
+
+---
+
 #### **2A. Search Initiated Automatically (Live Search)**
 
 Otherwise known as "Live Search," as the user types, the app automatically initiates the search with each keystroke or after a specified delay in keystrokes.
@@ -205,7 +263,9 @@ Results are displayed by filtering the content in the searchable area (1) so tha
 
 If there are no results, it is recommended that a “No Results” blank state is displayed in the content area instead.
 
+**On-page Results – 3**
 
+---
 
 **4. User Takes Action on Results**
 
@@ -216,6 +276,10 @@ Depending on the product and the user’s workflow, users may take a number of n
 - Sort search results (3).
 - Interact with results, like drilling down into a single result, performing actions upon results, etc. (4).
 
+**On-page Results – 4**
+
+---
+
 ---
 
 ### Use Case Examples
@@ -240,14 +304,38 @@ This section will describe search in some use cases currently used across CZI pr
 
 When searching the Menu Items within a Dropdown Menu, it is recommended to use the On-Page Results flow type. Why? Think of the Dropdown Menu as the “page” and the Menu Items as the content being searched. As the user searches, the content is filtered down without leaving the open Dropdown Menu.
 
+**Search within Dropdown Menu flow**
+
+---
+
 The following behaviors are recommended for displaying search results within a Dropdown Menu.
 
+**Search within Dropdown Menu behavior**
+
+---
+
 ## Other Considerations
 
 ## Patterns to Support User Behavior
 
 Below are some example behavior patterns worth considering to help support users in their searching. Evaluate if implementing these will help users’ workflows and if the product can support any technical requirements of implementation.
 
+**Display Search Results Count**
+
+---
+
+**Highlight Search Results**
+
+---
+
+**Surface Deep Results**
+
+---
+
+**Sort Results by a Display Order**
+
+---
+
 ---
 
 Search is a flexible way for users to find data of interest or filter down their data by a keyword. This allows users to take action on the available data without the distraction of irrelevant information.
@@ -275,6 +363,10 @@ Search is a flexible way for users to find data of interest or filter down their
 
 Search results are displayed on the current page by filtering down the visible content within the searchable area(s) to show matches only. This search is the most common pattern; it is used both at the component and the page levels.
 
+**CZ ID_On-page Results flow_Overview_new**
+
+---
+
 ---
 
 #### **1. User types keyword into Search Input**
@@ -283,6 +375,10 @@ It is recommended to position the Search Input at the top level of the content t
 
 For example, if the search will display results in tables across multiple tabs (1), position the Search Input in the header (2).
 
+**On-page Results – 1**
+
+---
+
 #### **2. Search Initiated by User**
 
 Search is initiated when the user clicks a button, hits “enter”, or completes some other user action.
@@ -295,6 +391,10 @@ Results are displayed by filtering the content in the searchable area (1) so tha
 
 If there are no results, it is recommended that a “No Results” blank state is displayed in the content area instead.
 
+**On-page Results – 3**
+
+---
+
 #### **4. User Takes Action on Results**
 
 Depending on the product and the user’s workflow, users may take a number of next actions on the results, possibly including:
@@ -304,6 +404,10 @@ Depending on the product and the user’s workflow, users may take a number of n
 - Sort search results (3).
 - Interact with results, like drilling down into a single result, performing actions upon results, etc. (4).
 
+**On-page Results – 4**
+
+---
+
 ---
 
 ### Use Case Examples
@@ -324,6 +428,10 @@ That being said, for the On-page Results flow, keep in mind that paginated vs in
 
 Search results are displayed inside a Dropdown Menu that appears below the Search Input. The user will remain on the same page until they select a result from the Dropdown Menu.
 
+**CZ ID_Results Dropdown flow_Overview**
+
+---
+
 ---
 
 #### **1. User Types Keyword into Search Component**
@@ -332,6 +440,10 @@ It is recommended to position the Search Input at the top level of the content t
 
 For example, if the search will display results from across multiple tabs (1), position the Search Input in the header (2).
 
+**Results Dropdown – 1**
+
+---
+
 #### **2. Search Initiated (Live Update)**
 
 As the user types, the app automatically initiates the search with each keystroke.
@@ -344,6 +456,10 @@ Instead of updating the searched content area, results are displayed in a Dropdo
 
 If there are no results, it is recommended to display a bank state in the Dropdown Menu instead.
 
+**Results Dropdown – 3**
+
+---
+
 #### **4. User Takes Action on Results**
 
 Depending on the product and the user’s workflow, they may take a number of next actions on the results, possibly including:
@@ -352,6 +468,10 @@ Depending on the product and the user’s workflow, they may take a number of ne
 - Interact with results, such as drilling down into a single result (2) .
 - Initiate a different type of search flow. For example, the user clicks “enter” to filter page by search keyword (3). See Combining Search Types section to learn more.
 
+**Results Dropdown – 4**
+
+---
+
 ## Example Use Cases
 
 ## Example Use Cases
@@ -362,9 +482,15 @@ This section will describe search in some use cases currently used across CZI pr
 
 When searching the Menu Items within a Dropdown Menu, it is recommended to use the On-Page Results flow type. Why? Think of the Dropdown Menu as the “page” and the Menu Items as the content being searched. As the user searches, the content is filtered down without leaving the open Dropdown Menu.
 
+**Search within Dropdown Menu flow**
+
+---
+
 The following behaviors are recommended for displaying search results within a Dropdown Menu.
 
+**Search within Dropdown Menu behavior**
 
+---
 
 ## Other Considerations
 
@@ -381,12 +507,32 @@ Depending on the use case, there may be a need to combine multiple flow types. H
 
 CZ ID combines the Results Dropdown and the On-page Results flows. This allows users to jump to a specific result or filter the workspace by the search, depending on their needs.
 
+**Results Dropdown + On-Page Results flow**
+
+---
+
 ---
 
 ## Patterns to Support User Behavior
 
 Below are some example behavior patterns worth considering to help support users in their searching. Evaluate if implementing these will help users’ workflows and if the product can support any technical requirements of implementation.
 
+**Display Search Results Count**
+
+---
+
+**Highlight Search Results**
+
+---
+
+**Surface Deep Results**
+
+---
+
+**Sort Results by a Display Order**
+
+---
+
 ---
 
 Search is a flexible way for users to find data of interest or filter down their data by a keyword. This allows users to take action on the available data without the distraction of irrelevant information.
@@ -416,6 +562,10 @@ Search results are displayed on the current page by filtering down the visible c
 
 The example flow below uses CZ GEN EPI to show the on-page refresh of content that occurs when using the On-page Results flow.
 
+**SDS_On-page Results flow_Overview**
+
+---
+
 ---
 
 #### 1. User types keyword into Search Input
@@ -424,6 +574,10 @@ It is recommended to position the Search Input at the top level of the content t
 
 For example, if the search will display results for a single Table (1), position the Search Input at the top of the table (2).
 
+**On-page Results – 1**
+
+---
+
 #### 2A. Search Initiated Automatically (Live Search)
 
 Otherwise known as "Live Search," as the user types, the app automatically initiates the search with each keystroke or after a specified delay in keystrokes.
@@ -442,6 +596,10 @@ Results are displayed by filtering the content in the searchable area (1) so tha
 
 If there are no results, it is recommended that a “No Results” blank state is displayed in the content area instead.
 
+**On-page Results – 3**
+
+---
+
 #### 4. User Takes Action on Results
 
 Depending on the product and the user’s workflow, users may take a number of next actions on the results, possibly including:
@@ -451,6 +609,10 @@ Depending on the product and the user’s workflow, users may take a number of n
 - Sort search results (3).
 - Interact with results, like drilling down into a single result, performing actions upon results, etc. (4).
 
+**On-page Results – 4**
+
+---
+
 ---
 
 ### Use Case Examples
@@ -478,6 +640,10 @@ Search results are displayed inside a Dropdown Menu that appears below the Searc
 
 The example flow below uses CZ ID to show the contents of a Dropdown Menu filtering down to include only the Menu Items that match the keyword entered into the Search Input.
 
+**SDS_Results Dropdown flow_Overview**
+
+---
+
 ---
 
 #### 1. User Types Keyword into Search Component
@@ -486,6 +652,10 @@ It is recommended to position the Search Input at the top level of the content t
 
 For example, if the search will display results from across multiple tabs (1), position the Search Input in the header (2).
 
+**Results Dropdown – 1**
+
+---
+
 #### 2. Search Initiated (Live Update)
 
 As the user types, the app automatically initiates the search with each keystroke.
@@ -498,6 +668,10 @@ Instead of updating the searched content area, results are displayed in a Dropdo
 
 If there are no results, it is recommended to display a bank state in the Dropdown Menu instead.
 
+**Results Dropdown – 3**
+
+---
+
 #### 4. User Takes Action on Results
 
 Depending on the product and the user’s workflow, they may take a number of next actions on the results, possibly including:
@@ -506,6 +680,10 @@ Depending on the product and the user’s workflow, they may take a number of ne
 - Interact with results, such as drilling down into a single result (2) .
 - Initiate a different type of search flow. For example, the user clicks “enter” to filter page by search keyword (3). See Combining Search Types section to learn more.
 
+**Results Dropdown – 4**
+
+---
+
 ---
 
 ## Results Page
@@ -516,6 +694,10 @@ Search results are displayed on a different page than where the search was origi
 
 The example flow below uses napari.org to show the usage of a Results Page to display the outcome of a search.
 
+**SDS_Results Page flow_Overview_new**
+
+---
+
 ---
 
 #### 1. User Types Keyword into Search Component
@@ -524,12 +706,20 @@ It is recommended to position Search Inputs at the top level of the content the
 
 For example, if the search will display results from across the whole site (1), position the Search Input in a top-level navigation or outside of the page content hierarchy (2).
 
+**Results Page – 1**
+
+---
+
 #### 2. **Search Initiated by User**
 
 Search is initiated when the user clicks a button (1), hits “enter” (2), or some other user action.
 
 Because results will be displayed on a new page, Live Search is not recommended.
 
+**Results Page – 2**
+
+---
+
 #### 3. Results Displayed on the Results page
 
 After the user initiates the search, they are automatically directed to a results page.
@@ -538,6 +728,10 @@ The results page format depends on the product's use case and content. In the ex
 
 If there are no results, it is recommended to display a bank state on the results page.
 
+**Results Page – 3**
+
+---
+
 #### 4. User Takes Action on Results
 
 Depending on the product and the user’s workflow, they may take a number of next actions on the results, possibly including:
@@ -546,6 +740,10 @@ Depending on the product and the user’s workflow, they may take a number of ne
 - Interact with results, like drilling down into a single result (2) .
 - Filter or Sort Results.
 
+**Results Page – 4**
+
+---
+
 ---
 
 ### Technical Considerations
@@ -564,8 +762,16 @@ This section will describe search in some use cases currently used across CZI pr
 
 When searching the Menu Items within a Dropdown Menu, it is recommended to use the On-Page Results flow type. Why? Think of the Dropdown Menu as the “page” and the Menu Items as the content being searched. As the user searches, the content is filtered down without leaving the open Dropdown Menu.
 
+**Search within Dropdown Menu flow**
+
+---
+
 The following behaviors are recommended for displaying search results within a Dropdown Menu.
 
+**Search within Dropdown Menu behavior**
+
+---
+
 ## Other Considerations
 
 | Search is a complex component, and is highly subjective to each product's use case. While it's impossible to support and document every use case, here is a collection of patterns that may be useful to consider when implementing it. The patterns detailed below have not been developed by the SDS team and are simply examples pulled from products that utilize the SDS components. **Please consider the information in this section as inspiration only.** |     | **Jump to pattern:** Combining Search Types Supporting User Behavior |
@@ -581,12 +787,36 @@ Depending on the use case, there may be a need to combine multiple flow types. H
 
 In most use cases for the Results Page flow, it can be beneficial to provide users with a way to modify their search results by implementing the On-page Results flow within a Results Page design.
 
+**Results Page + On-page Results flow**
+
+---
+
 ### Results Dropdown + On-page Results Flow
 
 CZ ID combines the Results Dropdown and the On-page Results flows. This allows users to jump to a specific result or filter the workspace by the search, depending on their needs.
 
+**Results Dropdown + On-Page Results flow**
+
+---
+
 ---
 
 ## Patterns to Support User Behavior
 
 Below are some example behavior patterns worth considering to help support users in their searching. Evaluate if implementing these will help users’ workflows and if the product can support any technical requirements of implementation.
+
+**Display Search Results Count**
+
+---
+
+**Highlight Search Results**
+
+---
+
+**Surface Deep Results**
+
+---
+
+**Sort Results by a Display Order**
+
+---