# About Helsinki University Design System

HUDS brings together the building blocks and best practises for designing and building interfaces with the look and feel of Helsinki University.

The Design system consists of Tokens, Components, Patterns and Templates.

Design tokens are the primitives of visual style, such as colors, fonts, their sizes and weights, borders, shadows etc. You can think them as base rules for the visual look. They will not have a visual representation themselves, but are used by Components.

Components are the smallest building blocks of the user interface. In the design system they encapsulate all styles and business logic into themselves, allowing them to be used anywhere usually without additional code.

Patterns are rules on how the Components will be used together. Think of a login form, where you need two input fields, a button and some validation logic. This can be codified in design system as a single block of code that has specific rules on how it should be used.

Templates define larger sections of the interface. They can be a definition for a whole page, or a subset of a page. They can encapsulate rules of grid, baseline, responsivity etc.

# Technology

HUDS is built using Web Components, which is a standard for defining custom html elements. They can be built using a lower level JavaScript API, but we chose to use Stencil.js, a compiler for web components. Using a tool like this gives the project more structure and allows easier authoring of components. After a component is built using Stencil, it will be bundled with other components as a library which can be imported in any modern browser using <script /> tags or used as a ES6 module with a build tool such as Webpack, Rollup or Parcel. The produced components can be then used in any frontend environment such as React, Vue, Angular or in a plain html environment such as Wordpress or Drupal.

Components that encapsulate logic, should have unit tests and documentation. Stencil can automatically generate part of the technical documentation and bootstrap testing files.

# Documentation

A style guide need a place to visually display both the components in action and the instructions on how to use them with code examples. A best way for this, given time constraints, is to use a static site generator capable of processing markdown files. At the moment we use VuePress, but this might change in the future.

# Build automation

Build automation is handled with Gitlab runners.

# Library

  • When a merge request to development branch is made, a runner checks if the library builds and passes all unit tests
  • When master branch is tagged with a new version number, A new version is built and published to npm registry, where it will be available for use for both module environments and via a some CDN mirroring npm registry.

# Documentation

  • When a merge request to development is made, a runner checks if the site builds and passes all unit tests
  • When master branch is tagged with a new version number, A new version is built and published as a static html site under https://static.helsinki.fi/ds