Release KDS v6

[rtibbles]

❌ This issue is not open for contribution. Visit Contributing guidelines to learn about the contributing process and how to find suitable issues.

Overview

KDS V6 (currently being scoped) will include a variety of design pipline work including:

• triaged-out-rebranding-work for the product ecosystem that was intentionally scoped down to a MVP.
• tech debt/maintenance, including node js upgrade (and potentially Vue3 upgrade)

However, there are a variety of designed updates that we want to continually build out and phase into our products to update the look and feel, respond to user feedback (such as around images and iconography).

Rebranding/design changes

The next steps for the ecosystem updates will be focusing on relatively lower-effort but high impact and we will start with:

• buttons
• typography

These changes are stylistic, updating our defaults. Some changes will happen in KDS, some will be in the products themselves, and KDS documentation and guidance will need to be updated for reference moving forward.

Approach

Typography: The line height will be updated across all paragraph and header text, for any text that can roll into multiple lines. Line height changes should be considered for KButtons particularly those that are styled as links. Line height will need to be factored into and calculated into the default padding for:

• the outside of containers (i.e. <p>, <a>, <h_>, etc.)
• buttons (those that are styled as buttons, and need padding adjustments from the figma specs so that the true total height adds up to the spec

Standard KButtons
Because is still used throughout Studio, we will need to carefully coordinate work between the Studio KDS refactor, the KDS upgrades (for buttons), what's needed in Kolibri, and KDP. VBtn is used in ~70 files, and in about 40 of them, we have a "regular" (i.e. text) button in some form or another. The remaining ~25-30 are Icon buttons, which we can manage the upgrade of separately. The KDS in studio refactor is following a workflow based approach, to allow for more comprehensive QA, rather than a component-based approach. We could: make an exception to this general approach for the button upgrades, focusing specifically on non-icon VBtns and QAing comprehensively, roll out the changes in Studio later (this may also be more ideal, in terms of Studio release timelines), manage this aspect of the KDS <> Studio work internally, or some combination of these things.

Node upgrade

Other tech debt

Component updates to support upcoming feature work across the ecosystem

[MisRob]

@rtibbles @marcellamaki There may be few remaining places to take care of (I can check on it next year), but already pretty sure that majority of (non-icon) VBtn's are replaced by KButton's.