Material theme creation for Hack & Craft, by @nadalsol (Aug 2019) 

TOC Overview Problems to solve Project objectives Proposal #1 Proposal #2 Constraints Doubts 

Overview Hack & Craft uses Material Design as a design language on their projects. As developers, we need an agnostic base theme for H&C projects*, to avoid starting every project from scratch. This will be like a styling starting point, for new projects. (*) “hncbt” from now on. 

Problems to solve 1 Material components customisation. Development time for H&C projects is short, so we must be quicker. 2 CSS code repetition*. A good example are H&C input fields –quite different from Material– so a lot of styles must be customised per project. This is time consuming for developers. 3 Angular Material library only provides color theming (no theming for font-size, font-weight, line-height, spacing…), so Angular Material theming is not an option. (*) Code repetition also happens with HTML and probably JS, but this is out of our scope for now. 

Project objectives ● Faster development ● DRY approach (Don’t Repeat Yourself) ● Design consistency ● More robust UIs (less error prone) 

Proposal #1: Agnostic Sass settings in “hncbt” (specific settings per project) 

Proposal #1 “hncbt” private GitHub repo. 

Proposal #1 “hncbt” private GitHub repo > agnostic Sass settings file. 

Proposal #1 “hncbt” published as a private npm package. 

Proposal #1 “hncbt” npm package imported as a dependency, in child project. Sass settings inherited, then overriden with project specific settings. 

Proposal #1 “hncbt” npm package imported as a dependency, in child project. Sass settings inherited, then overriden with project specific settings. “hncbt” repo (agnostic settings) Dulux Admin repo (custom settings) Schneider Admin repo (custom settings) ... (custom settings) Build generated. Build generated. Build generated. Build generated. 

Proposal #2: Agnostic Sass settings + project specific settings in “hncbt” (CDN solution) 

Proposal #2 “hncbt” private GitHub repo (same as Proposal #1). 

Proposal #2 “hncbt” private GitHub repo > all Sass settings files. 

Proposal #2 “hncbt” could be published as a private npm package, or not. ? 

Proposal #2 All Sass settings lives in the “hncbt” agnostic theme. “N” builds per project must be generated in “hncbt”, and hosted on a CDN (same approach as Bootstrap or jQuery). 

Proposal #2 All Sass settings lives in the “hncbt” agnostic theme. “N” builds per project must be generated in “hncbt”, and hosted on a CDN (same approach as Bootstrap or jQuery). “hncbt” repo (agnostic settings) (dulux settings) (schneider settings) ... Dulux Admin repo Schneider Admin repo ... Build generated, also for child projects . Build generated. Styles imported from CDN. Build generated. Styles imported from CDN. Build generated. Styles imported from CDN. CDN 

Constraints 1 2 Designers must follow some rules in order to reuse components*. We’re already using Material Design, so this shouldn’t be a problem. 3 The “hncbt“ will be an external package. New iterations must be done there first, then child projects must update its dependency and fix breaking changes (if any). This implies more dev. time. 4 Need a Pattern Library in “hncbt”, in order to see how components looks like. Nice to have: also in child projects. Theming does not include layout changes, functionality or any other topic (only cosmetics). (*) For instance, defining dialog variants like small, medium and large (same for all projects). 

Doubts 1 2 Components behaviour (interaction) must be the same (i.e. dialogs always closing with an “x” icon or “Close” button). Of course, new components may always be extended. Theming will work for Admins (backoffices). I don’t think it will for more complex websites, like Dulux Connect. 

Thank you.