Introduction

TR TM Styleguide

This is the styleguide for legacy HRMTS systems applying new Talentech branding.

WCAG & accessibility

Semantic HTML and correct adherence to WCAG guidelines are key. Read our documentation, practices, and guidelines on WCAG processes.

Fundamentals

  • Write semantic HTML.
  • Content must be logically tabbable with keyboard.
  • All pages must be responsive.
  • Check consistency in browsers.

Components / elements / layout

Do:

  • Check the styleguide for the component needed.
  • If the styleguide does not have it, use Bootstrap documentation, find it there, copy it, and stick to defaults.
  • If you bump into a problem assume that Bootstrap has solved it. Be lazy.
  • If you still can't find what you need, talk to the Styleguide owner. They'll will create the component in alignment with quality guidelines, or reach a compromise with designers.
  • Layout grid: Boostrap has excellent documentation on how to use the column grid, and flexbox-based layouts

Bootstrap 4 layout grid

Boostrap 4 flex

Don't:

Do not add css. If you think you must, it is probably wrong structure, incomplete nesting, or wrong use of components. Double check with Styleguide / Bootstrap that the component syntax is correct and semantic. Or there might be local css sheets overrides that needs to be deleted. Check first what happens when you delete local styling. Make sure the stylesheet order in <head> cascades correctly. Double check if there are any stylesheet references in the footer. If problem persist talk to the Styleguide owner.

Many design issues in TM1 and TR can be solved by deleting local styles.

  • Never use fixed widths, heights or any definite px anywhere.
  • Never write css.
  • Never hardcode.
  • Never write content-text in uppercase.
  • Never use divs or <p> as "spacers".
  • Never use tables for anything else than data tables.
  • Never use <br/> .
  • Never use empty, classless or id-less divs.

The goal should be that all styling is controlled from the Styleguide. This will allow for global rebranding consistency and quality.

Figma sketches and Styleguide

Figma has its own component library, similar to any frontend. However: Figma is not 1:1 with code-logic, and Figma UI is an idealised world. Our legacy systems cannot be aligned 100% with this because there are too much local styling, and this is different between TR and TM1. This makes it impossible to control and rebrand consistently. We cannot create and maintain an entire Figma component library to be visually consistent for ONLY TM1 and TR: this would be impossible anyway, because of local styling. This is the reason why our rebranding is not where we want it to be. The more control given to Styleguide, the closer we'll get.

The ideal, the real, and progressive enhancements

The Figma sketches is An Ideal World, and what we AIM for.

This idealised world means we have to keep three concepts in our heads at the same time: the Ideal (Figma), the Real (application), and progressive enhancement (via Styleguide control). We aim for the ideal, work with the real world, and make sure we do no harm to allow for progressive enhancements.

Example: Figma has a very strict, global system of scale, grid, layout, increments, and spacing. This is not implemented in TR / TM1 (reasons above). So instead of adding individual layout to make a page fit the Figma Ideal, we must understand that as long as the component/element, in question is a core/default copied from Bootstrap or Styleguide, semantically correct, then the spacing will be implemented (progressively enhanced) eventually. Developers should not have to worry about these global issues. So we do no harm that can prevent this slow march towards the Ideal.

Global styling

Sometimes something "looks wrong", either by gut feeling, compared to Styleguide/Bootstrap components, or Figma sketches. An example could be for example headings that might seem to have too little space around them. This is an example of a thing that will clearly be a global issue for TM1 and TR alike, and should be handled from the Styleguide. It should be fixed globally, not by adding helper-classes that will create inconsistent layout across pages and apps. Just stick to the vanilla components, alert the Styleguide owner, and move on.

Helper-classes: When to use them. If the code is copied from a pure Styleguide-provided or Bootstrap-provided component verbatim, they should be out-of-the-box regarding design. If there still are anomalies in design, and it seems a helper-class is needed, such as margins m- ml- mr- mt- mb-, ask yourself: is this particular case a 100% unique case? is the use of this element or component the only place this will exist? Chances are the answer is no. So the helper classes should be avoided when possible. There should be standards defined globally.

CSS

Do not write css.

Telerik

Telerik "requires" and has its own stylesheets, but by use of correct classes and Bootstrap defaults a lot of this should be possible to remove or circumvent, apply Telerik controllers for Boostrap components, wrap or attatch Telerik components in Boostrap classes, or other similar solution that removes as much styling away from Telerik and over to the Styleguide and Bootstrap as possible. Telerik for data tables we cannot avoid for the forseeable future, at least not for TM1. But we should avoid using Telerik for layout whenever possible.

WCAG & accessibility

  • Write semantic html.
  • Use Styleguide and Bootstrap components.
  • Make sure you can navigate with the keyboard and tab through the page in a meaningful order.
  • Focus states are clearly visible. If not: check your structure / component use.
  • Run an accessibility / WCAG-checker, but bear in mind, they are merely indicative as they don't handle contextuals. They should catch the most glaring mistakes though.
  • Join #frontend and #wcag and ask questions.
  • Tabindex is not your friend: if you need it, look at structure first.

Responsiveness

Overall: we aim for responsiveness from 320px (smallest iPhone) and up. For TM1 and TR this is a bit optimistic, but "a very motivated user should be able to at least get things done, if she tilts her iPhone, to 568px". Bootstrap has excellent documentation.

Desktop

Check these browsers in all basic four Boostrap breakpoints (sm, md, lg / phone, tablet, desktop). Recommend doing this as you go along, not at the end.

  • MacOS Safari
  • MacOS Chrome/Chromium
  • MacOS Firefox
  • Windows Chrome/Chromium
  • Windows Firefox

Mobile

  • IOS Safari
  • Android Chrome

Look for consistency between them; and expected stacking of structure, components and content.

v1.0.811-rev-07dbbad