Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Discuss as many items as possible from value matrix

  • Update backlog for RG

\uD83D\uDDE3 Discussion topics

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 https://2u-internal.atlassian.net/browse/TNL-9824, 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

...