[NOTE] Frontend Migration Notes

[seaerchin]

Discussion Points

1. Isomer internal theming (colours/typography etc)
   • We need colour tokens for our internal components and a colour palette for our base isomer-level theming
2. Failover plan with design - in case timeline needs extension etc
   • User Access Management (UAM) only requires input, button and dropdown. Former two can come from design system but dropdown is a new component and will be prioritised to avoid blocking design.
3. Scope of work
   • Design has a v1.5 figma, which is an intermediate state between the current look now and a hypothetical future look (v2). Hence, the scope for frontend refactor should also include a UI update to the v1.5 figma, in addition to code level changes.
   • Design might have new components (see here). These will also be included in the refactor going forward.

[NatMaeTan]

Please take the ones from the design system! When you say headers in preview you mean site preview during editing right?

[seaerchin]

yes de

[NatMaeTan]

Do you need me to map the current markdown header sizes to the specific design system ones? I don't think there's a clear mapping now to the text style sizes – unless yr literally just taking sizing references not to the text styles

Also this is just sizing and not font or font style right

[seaerchin]

i'm just mapping the html tag in the preview to the corresponding textStyle but h5/6 are not in the textStyle for design system so i might need your help there.

it's only fontSize and fontWeight (didn't change anything because it looks similar enough) because of emotion resetting css styling for h1-6 so we need something with higher specificity

[NatMaeTan]

OGP Design System text styles and Isomer Template/Preview text styles differ in font, weight, etc. Hence we are unable to map preview text styles to the OGP design system.

As preview is a reflection of the Isomer template and staging, we'd want to ensure that they match as closely as possible, if not identically. Hence, if we are not updating template text styles to match in this refactor, we should not be changing preview text styles to match the rest of the CMS interface since they are at their root, different text styles.

Hence, we will create new text styles for preview, based on the current text styles in staging/production (i.e. Isomer template).

Figma link for details of the text styles can be found here.

*Note: There is currently no documentation for Isomer template typography and text styles, hence we're recreating these based on what is in production on the template. However aside from size, line height and tracking have been calculated based on the OGP design system formula provided. This may cause a slight visual difference between preview (calculated) and template (legacy). However, since these values have now been properly calculated, we should eventually update the template fonts to match these line height and tracking values.
In addition, we will start documenting all other text styles used across the rest of the template (e.g. homepage)

**Second note: During this process, we realised that Preview header font weight and staging font weight are different (Bold 700 vs Normal 400), causing a visual discrepancy between the two. As an intermediate solution, we will match all header font weights to staging (Normal 400), but we should definitely push to change these header weights to Bold 700 when we next do a template update.

To dos when we next update template:

1. Change template text style values for:

• Line height
• Tracking
• Font weight

[seaerchin]

@prestonlimlianjie fyi for part 2 where preview vs staging differs

[seaerchin]

@NatMaeTan lmao just discovered something on preview vs live site.

1. if we have a heading in the body, the colour and fontWeight will be different from the live site
2. to get to the desired behaviour, we have to do # ** some heading ** (basically bold the heading)

[NatMaeTan]

Isomer color tokens

[seaerchin]

@NatMaeTan @audreytcy

migration will be gradual, so we will have instances where some pages use design system components but others don't. eventually, they should all be in design system but is it acceptable to have it in such a state or should it be all or nothing?

also, could i just get a sense of importance for the new components outlined here?

i'm inclined to put the cards as p2, with headers/bottom p3 (as the component as-is in isomer is pretty messy). for the modal, if it's just a design refresh, it might be doable but due to how intertwined modals in isomer are with data fetching logic, i'm disinclined to prioritize it @__@

[seaerchin]

clarified with @NatMaeTan and @audreytcy; both are ok with this.

[seaerchin]

List of visual differences between staging/prod
(pls edit this directly)

1. disabled placeholder text input is not in black but is faded
2. changed HeroSection button text from "Choose Image" to "Select" (space constraint + annoying to refactor as it also involves FormInput, which affects alot of other components)

[seaerchin]

@kathleenkhy @NatMaeTan we're not migrating the pages itself so there might be a few differences between v1.5 and the actual look on staging when deployed; will get @NatMaeTan to look thru and see what are some major diffs that we should fix for usability and if required, adjust timeline!

[seaerchin]

Release checklist for v1.5

Design

Prod

Rollback plan

1. we might be able to rollback the UI changes if deploy goes south - just need to change the netlify stuff
2. however, this will not work if clients don't refresh their browser!!

[NatMaeTan]

UI & Bug fixes from FE walkthrough 23 June