---
# System prepended metadata

title: Summon App UX Spec Review and Pattern Library Update (3/16/2022)
tags: [' design', ' pattern library', v3]

---

---
tags: v3, design, pattern library
---

# Summon App UX Spec Review and Pattern Library Update (3/16/2022)

## Summon App UX Spec

- Overview:
    - Summoning flow for Baal in v3
    - Will need to iterate/refine tooltips and messaging
    - Began extracting form elements
- Components included to pull to library:
    - WalletConnect
    - SwitchChain
    - Form elements:
    - 
- UX User Flows:
    - Connect/disconnect
    - Knowing when to switch chains
- Development Notes:
    - Functional implementation notes, such as character limit on name when interacting with Baal
    - Form validation included
        - If we reuse validation, can move into a util library

### Questions

- Voting/Non-voting Stake Names
    - What do we want to call these? `vSTK` & `nVSTK`
    - Also considering `units` and `loot`
    - Loot is derivative of initial name (ie Voting Stake and Non-voting Stake)
        - This means that `votingStake` `votingStake-loot` in contract
        - Can display however needed on frontend

## Pattern Library Update

- Extracing components from the other UI specs, focusing on global components used across apps
- Pattern library design tokens and variants:
    - Font sizes 
    - Body typography
- Workflow:
    - Page in work that is "Near Complete"
        - Includes specs and notes
    - New components will be in the "Component Library" section in each spec, and then move into the *Pattern Library* Figma
- Noting variants as they go. For example:
    - Input
        - Default
        - WithAddress
        - WithErrors
        - WithValidation
- Pattern Library changes -> publish to all Figma instances
- Foundation theme tokens:
    - Light/dark support in all apps
    - Moving away from every DAO customing their pages -- instead aligning around a light/dark mode


## utils package notes

- Mental model: As soon as we copy/paste we abstract and add to a package
- when do we want to split out from a `commons` package into more specific ones?
- May eed seperate repo for data, legos, constants: not dynamic. Give ability to pull from same spot. Should this be in SDK?
- Libary input just data piece?
- Seperate imports per macro
- Robust component library should be able to break down into meanigful pieces
- add directories inside `src`
- legos build form, add validation and handle contract transactions
- keep it modular for both simple and complex. Some people may want to just it themselves
- Dream: GUI to put it together. Get the machine to type out the data
- Component library uses form builder library
- reliability and convenience
