2022-06-01 Meeting notes

 Date

Jun 1, 2022

 Participants

  • @Gabriel Weinberg

 Goals

  • Discuss as many items as possible from value matrix

  • Update backlog

 Discussion topics

Time

Item

Presenter

Notes

Time

Item

Presenter

Notes

 

Discuss value matrix priority items

@Gabriel Weinberg

  • Design token perspective

    • Technically, SCSS variables represent design tokens today, consumers and implementations, variables are defined within SCSS and consumer needs to be using SCSS in order to access them. We would need an API service that would return values that are translated into SCSS. Great bc style dictionary standardizes format, technically multiple sources of truth today.

    • Themability could be tricky, bc Paragon is themable, orgs might have their own theme outside of edX.org, it still needs to be themable in some way.

      • Would you pass the theme to this API or would a different organizations hit different APIs?

    • this is often what folks "tokenize", I imagine themes may include some or all of this: Colors, Opacity, Typographic Scale, Shadows, Corner Radius, Vertical Spacers Animation Curves

    • Could potentially help with runtime theming (if there are theme changes, we currently require re-deploying all our frontend services)

    • What should our tokens support as an MVP?

      • Should it be the actual component, or just the styles that we care about?

      • How small is the MVP? maybe a base set of components that would be used in iOS, create tokenization of the base set. for example color, or font.

      • We could take current implementation, ditch SCSS, first step to identify the token from the variables we have today, create an API service layer that can populate the SCSS variables we want to start with.

    • Advanced customizations, could drill down into design tokens, user preferences on font size, etc.

    • Are there areas where it would be easier to start (e.g., avoiding needing loading assets such as fonts)?

      • Should fonts/assets be treated as “peer dependencies” (aka consumer provides the font asset, but design token provides the font name to use).

  • Mobile text/spacing options

  • Auto-size text area

  • Open edX community collab/contribution—should it exist?

  • Engineering surveys

  • Data/ROI

  • Card updates



Review “Needs Discovery” items from value matrix

@Gabriel Weinberg

  • Data/user sentiment

  • Visual regression testing

  • Native text truncation

  • Consistent props API

  • Evangelize within 2U

Save for last, if time allows (also posted in Slack)

[inform/demo] Notifications in Tabs with Bubble component; responsive Tabs

@Adam Stankiewicz

https://paragon-openedx.netlify.app/components/bubble/

https://paragon-openedx.netlify.app/components/tabs/

 

Discuss design change for Collapsible

@Raymond Zhou

https://paragon-openedx.netlify.app/components/collapsible/

In , there is a design for additional information on a collapsed Collapsible.

  • Is the “preview” content when collapsible is collapsed

  • Does card need to be updated to be more flexible?

 Action items

 Decisions