WIP: Web Assets design and development component library proposal #94698

New Issue

Márton Lente · 2024-05-17T12:25:04+02:00

Márton Lente commented

2024-05-17 12:25:04 +02:00

Web Assets design and development component library proposal

This proposal is a draft for building a design and development component library by extending and updating existing Web Assets components in a systematic way. It breaks down and organises existing Web Assets partials to an organised component architecture to prepare a Penpot component library for design, and a Storybook component library for development.

The proposal focuses on consolidation of existing components, that can be extended with new (mainly high level) components later.

Components

Base / Foundations

Basic properties like colours, grid and type. Design foundations that prevail in all low and high level components, and can't be broken down any further.

Properties

Colours
Effects
Grid
Icons
Type

Low level components

Basic custom UI elements that are made up of base elements. Low level elements can only contain other low level elements. Low level elements overlap and extend the list of basic native markup elements like button with custom elements like alert .

Alert
Badge
Button
Code
Details
Heading
List
Paragraph
Pullquote
Separator
(Spacer)
Quote
Table

Low level elements can't contain utility classes. Web Assets partials architecture overlaps, but doesn't match the component architecture proposed in this doc.

High level components

Complex custom UI components that are made up of other items. High level elements can contain both low level elements, and sometimes other high level items.

Box
Cards
Details
Footer
Hero
Navigation (Dropdown)
Navigation (Global)
Navigation (Tabs)
Notifications
Pagination
Sidebar
Audio
Avatar
Comment
Gallery
Media & text
Navdrawer
Video

New components are set with italics. High level elements can contain utility classes.

Docs and guidelines

Web Assets documentation is maintained in the wiki. Components should be self-explanatory enough to not require component-specific documentation.

The existing Web Assets reference page should be extended, improved and ported to Storybook, showing good usage examples of existing and new components. Optionally it should become publicly accessible.

Platforms

While the Penpot component library would help in design and prototyping, Storybook components would make assembling UIs in code more consistent and efficient. Setting design and code apart would also be an opportunity to focus and iterate on design in the design phase, and adding new, or refactoring existing components in development based on that in an efficient way. (Design objectives are to be discussed.)

Storybook components' dynamic features and interactivity is to be systematically designed. There should be a set of default configuration features that are available for all components, that can be extended on a per-component basis if needed.

Modules

Though not tightly related to the above, JavaScript modules could be added to help working with components' dynamically, and write JS code in projects with less repetition. Example: a vanilla JavaScript functions library with utility functions similar to jQuery's handy DOM manipulation and traversing tools.

Web Assets design and development component library proposal This proposal is a draft for building a design and development component library by extending and updating existing Web Assets components in a systematic way. It breaks down and organises existing Web Assets partials to an organised component architecture to prepare a Penpot component library for design, and a Storybook component library for development. The proposal focuses on consolidation of existing components, that can be extended with new (mainly high level) components later. ## Components ### Base / Foundations Basic properties like colours, grid and type. Design foundations that prevail in all low and high level components, and can't be broken down any further. #### Properties - Colours - Effects - Grid - Icons - Type ### Low level components Basic custom UI elements that are made up of base elements. Low level elements can only contain other low level elements. Low level elements overlap and extend the list of basic native markup elements like `button` with custom elements like `alert` . - Alert - Badge - Button - Code - Details - Heading - List - Paragraph - Pullquote - Separator - (Spacer) - Quote - Table Low level elements can't contain utility classes. Web Assets partials architecture overlaps, but doesn't match the component architecture proposed in this doc. ### High level components Complex custom UI components that are made up of other items. High level elements can contain both low level elements, and sometimes other high level items. - Box - Cards - Details - Footer - Hero - Navigation (Dropdown) - Navigation (Global) - Navigation (Tabs) - Notifications - Pagination - Sidebar - *Audio* - *Avatar* - *Comment* - *Gallery* - *Media & text* - *Navdrawer* - *Video* *New components are set with italics.* High level elements can contain utility classes. ## Docs and guidelines Web Assets documentation is maintained in the [wiki.](https://projects.blender.org/infrastructure/web-assets/wiki) Components should be self-explanatory enough to not require component-specific documentation. The existing Web Assets reference page should be extended, improved and ported to Storybook, showing good usage examples of existing and new components. Optionally it should become publicly accessible. ## Platforms While the Penpot component library would help in design and prototyping, Storybook components would make assembling UIs in code more consistent and efficient. Setting design and code apart would also be an opportunity to focus and iterate on design in the design phase, and adding new, or refactoring existing components in development based on that in an efficient way. (Design objectives are to be discussed.) Storybook components' dynamic features and interactivity is to be systematically designed. There should be a set of default configuration features that are available for all components, that can be extended on a per-component basis if needed. ## Modules Though not tightly related to the above, JavaScript modules could be added to help working with components' dynamically, and write JS code in projects with less repetition. Example: a vanilla JavaScript functions library with utility functions similar to jQuery's handy DOM manipulation and traversing tools.

Márton Lente added the

labels 2024-05-17 12:25:05 +02:00

Márton Lente changed title from ~~Web Assets design and development component library proposal~~ to WIP: Web Assets design and development component library proposal

2024-05-17 12:25:14 +02:00

Sign in to join this conversation.