Visible DS Implementation and Anderson Conference Repository Notes

Overview of the Anderson Conference Repository and Visible DS

• The project is currently housed within the "Anderson conference" repository.
• The central focus for development is the implementation and refinement of the "Visible DS" (Design System).
• The current state of the design system is incomplete and requires further development to be functional for the engineering and design teams.

Deficiencies and Objectives of the Current Design System

• Incompleteness: The system currently lacks basic formulas and essential tables or patterns that have been previously discussed.
• Fragmentation vs. Centralization:
  • Currently, different branches are creating their own unique components rather than pulling from a single source of truth.
  • For instance, internal users or branches such as "Cloud," "Angi," and "$508$" are all independently creating their own table components.
  • The objective is to ensure that a designer or developer does not have to redesign a table from scratch. They should be able to simply copy a pre-existing component from the design system into their specific product prototype.
• Tokenization: The goal of tokenization is to hide the complexity of manual styling. Instead of creating new styles, the system should allow for efficient sharing of components across the repository.

Technical Structure of the Visible DS

• The design system file structure is organized as follows:
  • Assets: Contains global resources such as company logos.
  • Components: Houses the actual functional code for elements like the logo component.
  • Design Tokens: Contains CSS files that define the visual language of the system. This is analogous to the variables used in "Primal."
  • Typography: A separate area or CRM dedicated to managing typographic styles.
  • Images: A dedicated section that also includes specific typographic assets and other visual media.

Design Tokens and CSS Implementation

• CSS Variable Structure: The design tokens are implemented via CSS files (e.g., light mode.css). These files define the code that powers the visual interface.
• Token Categorization:
  • Reference Tokens: These provide the foundational values for the system.
  • Family Tokens: These are used to group related styles and variables.
• Default Palettes: The system defines standard default palettes for various colors, including:
  • The specific look and value of standardized "gray."
  • The specific "brand color" and other associated color palettes.
• Elimination of Hard-Coded Values: A primary rule for the design system is that it must never define hard-coded values. Every color, spacing, or style choice must be derived from the established design tokens.

Workflow for AI Integration and Component Updates

• Training the "Clor" AI: The AI (referred to as "Clor") is being trained to interface with the design system. It is instructed to never use hard-coded values and to always select colors and styles directly from the design tokens.
• File Navigation and Utilization:
  • Users can access the "files" section within the Clor interface to see the results and structure of the design system.
  • Specific file paths can be copied from this section to guide the AI.
  • The workflow involves asking Clor to read specific files, such as the email file or general assets from "Azure DNS," before beginning any component updates.
• Evaluation and Flagging: Team members are encouraged to read through the existing structure in the Visible DS file and evaluate if it accurately represents the current design requirements. If any information is found to be outdated, it must be flagged for correction.

Specific Project Contexts and Portals

• Patient Portal: This specific portal is associated with "Branch studio."
• Relevance to Component Building: While the Patient Portal is a specific use case, it is noted as being less important for the immediate task of general component building within the design system.

Questions & Discussion

• Participant Question: "This is inside Visible DS file?"
• Speaker Response: "Yes. It's under the Visible DS, we'll have design tokens for that."
• Participant Question/Comment: "You're gonna come here. Okay? So when you open the files, you'll see the results here. Okay? So you can copy the part from here."
• Speaker Response: "I'll ask the clock to read it from here, read this email file. Or read everything like SS, everything from Azure DNS, and then we'll start with the component updates."