DEV Community: Eduardo Ferreira

How-to: CSS Table Swipe Interaction

Eduardo Ferreira — Thu, 13 May 2021 21:59:47 +0000

Table rows or list items often have actions associated to them, such as deleting, sharing and editing. When designing for touch devices, designers can take advantage of swipe gestures to allow users to quickly perform common actions without having to navigate to a different page or open drawers or modal dialogs.

Gesture based interactions are supported by native mobile languages, but can be tricky to implement in HTML/CSS/JS and are often over-done with excessive use of JavaScript, which can cause low performance and chunky interactions.

In this post, I will walk through 3 simple steps to build a swipe gesture interaction using solely HTML, CSS and a little bit of JS.

Note: the demos in this post should be used on touch devices.

Basic requirements

Let’s start by defining what we want to build. Our swipe snippet should allow the user to:

Use touch to swipe a table row either right or left.
Unveil an action (icon and coloured background) when the user swipes.
Automatically restore scroll position when the user releases the finger.
Trigger an action when the user releases the finger (in case they have swiped far enough).

1. Setting the swipe-able element

As a first step, let’s create our swipe-able element and add basic styles to it. To style it, it is given a class named .swipe-element.

To set the stage for the swipe interaction, we can wrap the element around a div with the class name of .swipe-container.

To reduce the visual clutter, the .swipe-container should have the scrollbar hidden.
To automatically restore scroll position, the .swipe-container should have scroll-snap-type: x mandatory.
To indicate which element should be in focus when automatically restoring the scroll position, the swipe-element should have scroll-snap-align: start.

2. Adding the left and right actions

With the container and scrolling logic in place, the next step is to add the actions.

The icons used in this example are from the Material Icons font.

As a wrapper for the icon, the .action div, as well as the previously added .swipe-element should have min-width: 100%.
The i icon should have position: sticky to ensure it is always visible as soon as the user starts swiping.
the .right action should have justify-content: flex-end to make the icon stick to the right side.

3. Triggering the action

When the user releases the finger, our element should check how far the user has swiped and trigger an action in case they have done it far enough.

There should be a distinction between left and right swipe, so the application can handle them independently.

To start, an ontouchend event listener should be added to the .swipe-container.
In a function called handleSwipe(), we should first define the minDistance the user should swipe for the action to be triggered.
After that, we should calculate the swipeDistance by simply subtracting the container’s clientWidth from its scrollLeft.
Negative values represent a left swipe, while positive ones indicate a right one. In case the swipeDistance is smaller than minDistance * -1, we should trigger the left action, and if it is greater than minDistance, the right action should be triggered instead.
In case the user hasn’t swiped either left or right further than the minDistance, nothing should be triggered.

Conclusion

Using standard CSS selectors, we have built a swipe-able element that can be used for enhancing the user experience of lists and tables on mobile devices.

With some tweaks and a little bit of imagination, this snippet can be modified or extended to show only one action or indicating visually whether the user has swiped far enough, for example.

This component is also available as a plug-and-play in the Kor UI library.

Designing Color Systems — Transparent vs. Solid Shades

Eduardo Ferreira — Sat, 01 May 2021 01:25:15 +0000

From communicating visual hierarchy to expressing brand identity, colors play a key role in the design of products and design systems.

While some existing systems prefer the use of transparency for color shades, others rely solely on solid color palettes. In this post I will compare the two approaches and share my thoughts on the pros and cons of each.

Usage of color shades

Shades are used mostly for two purposes: indicating states such as hover, active or disabled and indicating hierarchy, such as for primary and secondary text.

Benchmarking design systems

Analysing four popular and well established design systems shows that there is no unanimity regarding which is the best. While Google’s Material and Adobe’s Spectrum prefer to use transparency, IBM’s Carbon and GitHub’s Primer stick to solid colors instead.

Comparing the two approaches

a) Amount of colors

The use of solid shades increase significantly the amount of variables required in a system, and can therefore make it harder to maintain and consume in comparison to the transparency approach.

In the example below, to define the states of a menu item would require 2 variables using transparency (blue) while it would take 8 unique solid colors (pink).

b) Theme-ability

Directly related to the amount of color variables, the use of transparency makes it easier to create and apply themes.

When using solid colors, switching from a light to a dark theme would require the creation of several new color values, while it would only require switching one variable when using transparency, as shown below, since the blending of foreground and background is done automatically by the use of the alpha channel.

c) Layering

Like Material Design, many design systems are based on a layered user interfaces. This usually means that ‘deeper’ layers appear darker while the ones close to the surface are shown in lighter colors (or the opposite in some cases).

Transparent shades (left) adapt easier to different backgrounds, since they keep the contrast between the element and its background mostly consistent.

Solid colors (right), on the other hand, appear darker or lighter depending on which layer they are placed on top.

d) Accessibility

The contrast between font and background is also affected by which approach you choose, and that has a high impact on the accessibility of the UI.

Solid shades give higher control by keeping the background stable and is therefore more suitable for that purpose, although good contrast ratios can still be ensured with transparency, for example by limiting the amount and color values of the layers.

Conclusion

While both approaches have their pros and cons, color systems based on transparencies are easier to use, maintain and scale.

Mature color systems usually offer a mix of both, such as applying solid swatches to containers and transparency to component states and content.

As mentioned on points c) and d), it is important to keep in mind the contrast ratio between container background, component background and content (especially text), so usability and accessibility are not compromised for the sake of ease of maintainance.

Design Systems — Designing UI Component APIs

Eduardo Ferreira — Thu, 29 Apr 2021 08:35:32 +0000

Not so long ago, user interfaces for the web were built mostly using standard HTML and CSS. The rise of frameworks such as React, Vue, Angular and Polymer made it possible to wrap and re-use UI components across parts of the same application or even between products.

Components found their perfect match with Design Systems, and allowed them to evolve from style guides or reference style sheets to full-blown libraries with modular assets containing Application Programming Interfaces (APIs) for setting a component’s appearance, content and behaviour.

1. Components vs. CSS-Only

Design systems can be implemented as component libraries or CSS-only stylesheets. While both have their pros and cons, in this post I will focus on the component-based approach.

Among the many advantages of using components over CSS-only libraries, these are the ones I consider the most valuable:

Design can be kept consistent by only exposing the parts which are supposed to be customised.
Product code becomes easier to read and maintain through the encapsulation of logic, styles and markup inside components.
Conflicting class names and other definitions can be avoided since they are isolated inside the component’s scope.

As an example, let us take a look at Material Design’s button implemented both ways. If only label, icon and type are customisable, a component approach only exposes the necessary APIs while a CSS-only approach exposes all the complexity:

2. Why should designers care?

Since APIs are not visible to the final users, it may not be clear why UX designers should be involved in designing them.

Components are first assembled by product teams before reaching the final users, and the API is the main interface between a component and product designers or developers consuming it. From this perspective, developers and designers are the first users of a Design System and their experience should be considered as well.

A well designed API will increase the developer’s experience, reducing the risk that they will implement their own solutions and therefore increasing productivity and enhancing the consistency of the final product.

3. Factors to consider

When designing a component and its corresponding API, some key factors should be considered to ensure they are easy to consume, consistent with the rest of the system, and easy to scale and maintain in the future.

a) Which variations should be offered?

With an overview of all possible use cases, designers can help define which parts of a component should be customisable through the use of properties and which should be kept stable, avoiding unwanted variations and therefore enhancing design consistency.

On the image below, label and icon are customisable, while icon-color and removable are not designed to be changed.

—

b) Which styles should be customisable?

Since consumers do not have access to the encapsulated content, customising styles can only be done through APIs.

CSS variables can be used for changing single css values (e.g. --border-radius). In case multiple styles should be changed together for a given variation (e.g. alert type changing icon color and font size) a property could be used instead.

Variables can be defined as a global theme (e.g. --accent-color) and modified for a single component, or new variables can be defined only for a given component (e.g. --footer-padding)

—

c) How will the component evolve in the future?

Components and their APIs evolve over time as new use cases arise. For this reason, they should be designed for change, based on facts or forecasts of how use cases may evolve.

An API that is not designed with evolution in mind will likely result in breaking changes when new use cases come up.

On the image below, the warning variation of the dialog could be defined as a warning boolean prop, but if error or success use cases are expected to come up in the future, it could instead be defined as a type="warning" string prop.

—

d) Which parts can be isolated?

Complex components are hard to consume. To simplify a component’s API, it is good practice to isolate smaller, reusable elements.

These elements can be wrapped inside the parent component or manually added by the consumer as child elements, depending on the amount of variation expected (see paragraph about slots below).

—

e) Where can content be inserted?

Not all functionalities of a component need to be pre-defined and offered through specific APIs.

For use cases that require more flexibility, consumers should be able to insert custom content inside pre-defined slots (AKA portals, containers or children areas).

Slots can define how its children elements will appear (e.g. from top to bottom or left to right, with 8px space between them), but the consumers have full control over the style of the inserted elements, since they are not encapsulated.

Conclusion

While it is extremely important that components are easy to use for the final users, developers and designers should be considered first-hand users of Design Systems and component libraries, and designing APIs that are easy to consume will significantly improve their experience.

Designers that understand how components API work can make more meaningful decisions when defining a component, and this will enhance the communication with developers as well.

Co-designing a Bonsai app with the r/Bonsai community

Eduardo Ferreira — Fri, 02 Apr 2021 18:33:33 +0000

🌐 Web App · 🤖 Play Store · 🍏 App Store

Bonsai can be literally translated as ‘tree planted in a tray’. It is an art form in which practitioners manipulate trees to make them resemble mature specimens but in a miniature form. For shaping the trees, artists perform various types of interventions, which require a considerable amount of knowledge in botany and plant physiology, making bonsai a practice significantly hard to learn.

In 2020, the COVID-19 lockdown coincided with the beginning of spring in the northern hemisphere, which is the busiest season for bonsai care. As a result, interest in Bonsai worldwide has almost doubled since March 2020 according to Google Trends:

Google Trends — ‘Bonsai’ interest over time

As I had to spend most of my time at home, I used the opportunity to resume this practice and added some plants to my collection. I quickly realised that in order to track the progress of my trees I had to document care events in form of notes and pictures, and searching for a tool I was surprised that none existed to serve this basic need.

With the support of another UX designer, a back-end developer and the r/Bonsai community as domain experts, I started working on Jooni in June 13, 2020 and the first version of the app was published 8 days after.

Today the app has 4000+ installs on Google’s Play Store and Apple’s App Store, 1000+ trees registered and 429 avg. weekly visitors, being the 2nd most popular app of its type.

—

Bonsai care journey

From seedling to mature tree, a bonsai specimen can often take over 20 years of intense care. For this reason, it is important that interventions are tracked to monitor progression and help decide what the next steps should be.

Interventions need to be performed at the right time of the year, and although these rules may vary based on species and location, artists usually follow the schedule shown on the image above.

—

Opportunities

Through online forums and interviews with artists and hobbyists, I have collected opportunities for improving bonsai care through the use of a digital tool. The most valuable findings were:

1. Communities are key to knowledge sharing among artists

Plants grow at a very slow rate, and therefore it takes time for an artist to know whether an intervention was successful or not, and for this reason learning solely through own experience is not a very efficient method. As a result, artists often gather in communities such as bonsai clubs or online forums such as Reddit. Jooni should create a strong sense of community and encourage exchange of experiences between artists of all levels.

2. Beginners are insecure about sharing pictures of their trees

When beginning in Bonsai, hobbyists are often not confident about sharing pictures of their trees, mostly because they fear criticism from more advanced users. If beginners were more comfortable sharing, they would be able to get guidance at the time they need it the most. To solve this issue, Jooni should make beginners feel safe about sharing their mistakes.

3. Experts often share only the best picture of their trees

In bonsai exhibitions, books or magazines, experts tend to share only the best pictures of their specimens, and while this can certainly inspire beginners, it will not help them to learn how to achieve that same result with their own trees. To solve this issue, Jooni should encourage experts to share the backstage pictures of their trees.

—

User flow

Based on the opportunities identified, the user flow has been defined and served as a basis for designing the user interfaces. It consists of 5 main screens through which the user can navigate:

Gallery: The entry point of the application, contains suggestions of trending trees and allows the user to sort by new or trending entries. On desktop it is shown as a 4 column grid while on mobile it has 1 column only.
Journal: Contains an overview of a single specimen, including its thumbnail, name, species, owner, number of likes, comments and list of events.
Event: Shows details of a chosen event, mainly its images and notes.
Profile: Displays all trees posted by a user, the badges earned by her/him, profile picture and other details.
Genus: Contains a list of trees belonging to a genus, care guidelines and list of species contained in it.

—

Releases and feedback loops

Using Reddit and Instagram as the main means of communicating with users, we have engaged with the community to provide feedback on newly released and upcoming features, helping us prioritise our work and give us input on their needs or pain points. For more direct input, we set up video calls to talk directly to individual users.

—

Solution

In an incremental manner, Jooni is continuously evolving based on feedback gathered from the community through social media, forums, app store reviews and data gathered through analytics. Functionalities have been defined to serve the goals and opportunities of the users mentioned before. To highlight some key features:

Trees tracked through Jooni are public by default, allowing other users to see and learn from their care history. Trees can be set to private by their owners.
Popular trees uploaded by expert artists are recommended to users so they can learn best practices from experienced peers.
Users are awarded badges as they complete certain achievements, including positive cases like uploading a popular tree or negative ones such as killing a specimen.
Users can export their progressions as images directly to social media such as Instagram, WhatsApp, Reddit or similar.
Users can schedule future events and get reminded when the date arrives.
Users can set preferences such as language (6 in total) and theme (light or dark).

Kor – Building a Design System from scratch

Eduardo Ferreira — Mon, 22 Feb 2021 14:35:19 +0000

🔗 See it live

In 2020 I planned to spend some of my free time in personal projects for learning new techniques and skills especially related to designing and building digital tools. Having worked on design systems professionally for some years, the logical first step to me was to have a component library that I could reuse across my projects, which would be:

Lightweight by only including the very 'core' components and functionalities
Customizable for allowing brand expression in different applications
Agnostic of framework for use on any application stack

Searching for existing solutions out there, I could not find one that would meet all these requirements. Some had too many features I wouldn't need, some did not allow style customization and most of them were based on a specific framework such as React, Vue or Angular.

I started building Kor on November 21, 2019 and the first version was published 4 days after. As of today, it has 7,000+ downloads on npm, 92 stars on GitHub and 300 monthly documentation users in average.

defining the base rules

Design systems are built on top of principles that are shared across UI components. Having a solid foundation helps ensuring the final solution is coherent and provides a basis for easy customization.

dimensions

Consistent dimensions have a high influence on the perceived harmony of the UI, and the best way to achieve it is by defining a base unit. In the case of Kor, tis unit was defined as 8px, a convention followed by most design systems which fits the most common screen resolutions. Usually units are defined as follows:

8px: Space between elements of a component
16px: Outer component margins
24px: Size of icons and line height

In rare cases such as in information-dense user interfaces, the 8px grid can be divided once more, resulting in increments of 4 such as 4, 12 or 20.

colors

Colors are used to convey hierarchy, highlight states and draw attention to certain UI components. To reduce complexity and make themes easy to modify, in Kor I have focused on reducing the number of colors to a bare minimum, and a total of 4 categories have been defined:

Base: Container backgrounds (such as app bar, cards, page)
Neutral: Positive and negative content colors (such as text, divider lines and transparent highlights)
Accent: Active state highlight and call to action colors
Functional: Confirmation, alert, error and neutral state colors

Default light and dark color schemes were defined and users are encouraged to design new themes by modifying as many color variables as desired.

typography

Font styles combine aspects such as typeface, size, line height and color, and are used to convey hierarchy, ensure readability and express brand identity. Keeping the amount of styles concise, 4 font styles have been defined and made customizable through variables:

Header 1: App bar label and content headings
Header 2: Component headings (e.g. tabs, cards)
Body 1: Component labels (e.g. tags, checkboxes)
Body 2: Component secondary text (e.g. avatar)

elevation

Another useful way to keep the UI organized and convey hierarchy of content is through the use of elevations. In Kor comes I have defined 4 layers which are set through the use of colors and shadows.

The color values for each layer are defined based on the natural effect of light on surfaces, meaning that layers closer to the viewer are brighter than the ones further in both light and dark themes.

Depending on the visual identity of the app, shadows and colors can be redefined or removed in case a flat appearance is preferred.

Layer 1: The background of the page
Layer 2: Side content (panes, nav bars)
Layer 3: Content containers (cards, accordions)
Layer 4: Overlayed content (notifications, modals)

iconography

Icons are a very important part of user interfaces and help to create visual rhythm and convey information in a quick way. In Kor I have opted to use the Material Design icons as they are open source, fit the 8px grid and covers most of the common use cases. In addition, users can include their own icon libraries as assets to replace or complement the standard set.

building components

Components are UI units which are generic (can be used in various use cases) and customizable through the use of properties, slots and events. Apps are usually composed of 80% common components such as buttons or inputs and 20% unique ones, such as maps or calendars. In Kor I have focused on the common ones to keep it concise and lightweight.

Properties are knobs through which components can be customized (e.g. labels of buttons)
Events are triggered by components to the app (e.g. button click)
Slot are containers in which custom content can be inserted (e.g. text inside a card)

a drag & drop sandbox

To help developers who are not so proficient with visual design and designers that are not into coding, I decided to create a sandbox where user interfaces can be created and customized by dragging aand dropping components into a canvas.

While there are plenty of prototyping tools available, their outcome can usually serve only as a reference for implementation, and most of the needs to be repeated again by the developer, so with this sandbox I experimented with narrowing this gap by generating production-level (or almost) HTML pages in a visual manner.

This project earned me my very first platinum award 💎 on Reddit, of which I am very proud 😎.

documentation, guidance and support

In parallel to designing and developing the design system, I have worked on the main documentation page for explaining how to set up, consume and contribute to Kor. The entire web app was made with the component library itself.

To explain certain features, I have written some posts on dev.to and Medium, which have been published by UX Planet, JavaScript in Plain English and Level Up Coding. Users currently raise feature requests and contribute to Kor directly through GitHub.

Kor UI themes #1: Twitch, Github, Spotify

Eduardo Ferreira — Sat, 03 Oct 2020 12:30:23 +0000

In this post we will showcase the three Kor UI themes inspired in well-known websites or web apps. We have chosen Twitch, GitHub and Spotify as references because of their harmonious base colors, rich use of accent colors and typography.

We will cover mainly two aspects of theming: customizing global variables (such as shadows, fonts and colors) and local component styles (such as border radius or tabs size).

Theme 1: Twitch

The user interface of Twitch is easily recognisable mainly for its moderate use of purple as an accent color and mostly grayscale base colors with a blue tint. A few component styles had to be set to match those used currently in the app.

Link to Stackblitz project

Key elements of the theme:

Base colors were set to blue-ish dark gray tint
Accent color was set to a bright purple
Shadows were removed (except for app and nav bars)
Fonts were set to the default sans-serif
Tab items were set to have accent font color when active or hovered and paddings got removed
Inputs got their bottom border removed and border radius increased

html, *[theme="dark"] {
  --accent-1: 169, 112, 255;
  --accent-1b: 179, 122, 255;
  --accent-1c: 159, 102, 255;
  --base-0: 24, 24, 27;
  --base-1: 14, 14, 16;
  --base-2: 31, 31, 35;
  --base-3: 44, 44, 46;
  /* outlines */
  --shadow-1: none;
}
html, body {
  /* fonts */
  --body-1: normal 14px/24px sans-serif;
  --body-2: normal 12px/16px sans-serif;
  --header-1: bold 16px/24px sans-serif;
  --header-2: bold 14px/24px sans-serif;
}
/* component styles */
kor-button {
  --accent-1: 145, 71, 255;
  --accent-1b: 155, 81, 255;
  --accent-1c: 135, 61, 245;
}
kor-nav-bar,
kor-app-bar {
  --shadow-1: 0 1px 2px rgba(0,0,0,.4);
}
kor-tab-item {
  padding: unset;
  min-width: unset;
  margin: 0 8px;
}
kor-tab-item:hover,
kor-tab-item[active] {
  --text-1: rgb(var(--accent-1));
}
kor-input {
  border: none;
  border-radius: 4px;
}

Theme 2: Github

In the last year, GitHub got a refresh in its UI and the new theme relies heavily on rounded corners and outlined shapes. Accent colors vary from case to case and another unique detail is the fact that the app bar has a mostly dark theme while the rest of the UI is based on a light color scheme.

Link to Stackblitz project

Key elements of the theme:

Base color of side panels was set to white and page base colors to a lighter shade of gray
Accent color was set to a dark shade of green
Shadows were replaced with thin outlines
Fonts were set to the default sans-serif
App bar theme was set to dark and base color changed to a dark shade of blue
Tab items had their active state indicator switched to orange

html, *[theme="light"] {
  --accent-1: 46, 164, 79;
  --accent-1b: 56, 174, 89;
  --accent-1c: 36, 154, 69;
  --base-1: 246, 248, 250;
  --base-2: 255, 255, 255;
  /* outlines */
  --shadow-1: 1px 1px 0px rgba(0, 0, 0, .1), -1px -1px 0px rgba(0, 0, 0, .1);
}
*[theme="dark"] {
  /* access bar */
  --base-0: 36, 41, 46;
}
html, body {
  /* fonts */
  --body-1: normal 14px/24px sans-serif;
  --body-2: normal 12px/16px sans-serif;
  --header-1: bold 16px/24px sans-serif;
  --header-2: bold 14px/24px sans-serif;
}
/* component styles */
kor-tab-item {
  --accent-1: 249, 130, 108;
}

Theme 3: Spotify

Spotify’s UI are mostly recognised by the pill-shaped buttons and monochromatic color scheme except for the use of green as the main accent color. The brand typography is also quite unique and recognisable through its circular capitals and wide characters.

Link to Stackblitz project

Key elements of the theme:

Base colors were slightly adjusted
Accent color was set to a dark shade of green
Shadows were removed
Fonts were set to ‘Raleway’ (closest open source match to - Spotify’s own ‘Circular’ font)
Buttons had their min-width and border-radius increased, while fonts got capitalised

Conclusion

In this post we have covered the basics of how themes can be created using Kor UI and we have chosen three popular websites or web apps as examples to showcase how it can be done.
These themes are public and can be used or modified by anybody. If you would like to know more about creating or modifying themes, we recommend checking the following post:

Design Systems: a glossary for developers & designers

Eduardo Ferreira — Sun, 27 Sep 2020 19:04:02 +0000

👋🏾 Introduction

Design systems are interdisciplinary by nature. They are built and consumed by designers and developers, therefore it is important for common terminologies to exist to support the communication between these two disciplines and other related actors.

Note: while some of the concepts are explained in a way that is more related to the context of web development, most of them are applicable to other contexts as well.

📖 Glossary

In this post we will present some key concepts from design and development, explain their meaning in the context of design systems and point to any ambiguity that may exist.

Foundation/Essentials/Principles

Example of Material Design foundations

Every design system is built on top of a set of fundamental rules which are shared across components or other parts. These rules can relate to visual design (e.g. animation, colors, typography) or define more abstract principles such as brand personality or writing style.

Components

Example of Kor UI button component

Perhaps the most used term, components are individual units (such as buttons, inputs, tabs) that have defined appearances and interaction paradigms. Components can have different variations and be customized through APIs (Application Programming Interfaces).

Patterns

Example of Carbon Design login pattern

Patterns define how different components can be combined in a certain way to serve specific user goals that are often repeated across screens or applications. For example, input fields, icons and buttons can be combined in a certain way to serve the goal of signing into an application. Examples of patterns are forms, navigation and onboarding.

Note: UX patterns should not be mistaken with ‘design patterns’ in software engineering, which are also common ways of solving problems but specifically related to the context of engineering.

Properties

Example of Kor UI card properties

Components can be modified through the use of properties (or ‘props’, for short). In the example of a button component, the text label, icon and disabled state can all be set through properties and combined to define a variation of that element.

Properties have types. For example, label can be set as a string, allowing any character to be entered, while disabled has a boolean type, allowing only true or false as value.

Slots

Example of Kor UI card slots

Components can have slots in which content can be inserted. For example, a card can have a top slot for tabs, a center slot for text and a bottom slot for buttons.

Events

Example of Kor UI tag events

Events are triggered by components in given circumstances. They are used by applications to react to user interactions or changes in the components. In web technologies (HTML), all components fire a set of standard events such as click or mouseover, but components can define their own custom events such as expanded, collapsed or checked.

Tokens/Variables

Design tokens or CSS variables are sets of values shared across components. For example, the body font size token can be defined as 14px, or the accent color token set to #51AA51 to reduce repetition and increase the ease of customization.

Classes

Classes can have two meanings. In CSS, classes are used to add styles on top of the standard ones, and this can be a way of theming design systems.

On the other hand, in software development classes are objects used for encapsulating data such as the definition of properties and functions. In this sense, components or utilities can be exported as classes.

Binding

When consuming a design system, one of the tasks performed by front-end developers is called binding (or data-binding), which means linking components to variables stored on a database or application.

Binding can happen from the component to the variable (e.g. editing an input field sets a variable to the value of the input) or from the variable to the component (e.g. the label of a button is a translated string coming from the database). Both types of binding can happen simultaneously, configuring a two-way data-binding.

Framework

Applications are usually built on top of frameworks that take care of tasks such as routing, data-binding or translation. For example, when building web apps, frameworks such as Angular, React or Vue are commonly used. While some frameworks can also come with component libraries, they are not intended to replace design systems but rather complement them.

Frameworks can also be used to build the components themselves, but a component built based on a given framework does not always have to be consumed by that same framework. For example, LitElement, Angular or Vue can generate components that can be consumed by any other.

✔️ Conclusion

While the explanations and terminologies listed in this post are based on the most common practices, you should be aware that they can defer across teams or institutions.

We hope this information will be useful for you and hope to see you soon in our upcoming posts :)

Building a dev.to clone using Kor UI

Eduardo Ferreira — Sun, 27 Sep 2020 11:22:52 +0000

This story is the first on a series where we will clone the front-end of existing websites or web apps to showcase some features of Kor UI and how they can be used to achieve various goals in UI design and development.

🗺️ Overview

Dev.to is a website focused on community discussions around topics related to software development. We have chosen the home page as a basis for our project because of its richness of layout and content.

Left: original; Right: Kor UI clone

In total, 34 Kor components have been used, 8 standard HTML elements (e.g. div, br) and only 27 CSS rules have been applied.

The technology chosen by us for the project was Angular (with SCSS stylesheets) and the codebase can be found in the Stackblitz project.

🎨 Part 1: Setting up the theme

The dev.to visual language is already quite close to the default styles of Kor UI, but there are some differences which have been handled through customisation in 3 levels: colors, fonts and component styles.

In this case we have chosen to extend the default dark theme since many styles are shared and wouldn’t need to be defined from scratch.

Left: Standard Kor UI dark theme; Right: Custom theme

Colors

The most obvious divergence between the default colors and the ones used by dev.to is concerning the blue-ish base colors. The luminosity of both schemes are similar, but the hues have been tweaked to match exactly the intended visual appearance.

In addition, the main accent color has been tweaked to match the purple tone used in dev.to (see for example on the button or active tab highlights).

*[theme="dark"] {
  /* accent colors changed from blue to purple */
  --accent-1: 123, 120, 255;
  --accent-1b: 133, 130, 255;
  --accent-1c: 113, 110, 245;{
  /* base colors changed from dark gray to dark blue tones */
  --base-0: 26, 38, 52;
  --base-1: 13, 19, 26;
  --base-2: 20, 29, 39;
  --base-3: 26, 38, 52;
  --base-4: 45, 45, 45;
}

Fonts

The typographic style in dev.to differs from the default Kor UI theme in 2 main points: font sizes and font family.

Since fonts are bigger in dev.to, the values of font size have been increased by 2px in all text styles. For example, the main body font has been changed from 14px to 16px.

The font family has also changed from Open Sans to sans-serif (custom fonts haven’t been loaded for convenience’s sake).

*[theme="dark"] {
  /* font sizes and family have been tweaked */
  --body-1: normal 16px/24px sans-serif;
  --body-2: normal 14px/16px sans-serif;
  --header-1: bold 18px/24px sans-serif;
  --header-2: bold 16px/24px sans-serif;
  font-family: sans-serif;
}

Component Styles

A few components had to have their default styles customised to match the design of the ones used in dev.to. Here is a complete list:

Primary buttons had their font color set to black instead of white.
Tabs had their bottom border removed and the vertical/horizontal sizes of tab items have been reduced
Menu items had text color changed to purple (accent) when hovered
Tags had their border removed and font color changed to a lighter shade

/* standard component style changes */
kor-button[color="primary"] {
  color: var(--neutral-2);
}
kor-tabs {
  border: unset;
  kor-tab-item {
    height: 40px;
    padding: 0 12px;
    min-width: unset;
  }
}
kor-menu-item:hover {
  --text-1: rgb(var(--accent-1));
}
kor-tag {
  border: unset;
  &:not(:hover) {
    --text-1: var(--text-2);
  }
}

📐 Part 2: Defining the layout

In viewports wider than 1280px, the content of the website becomes centered on the page instead of spanning from edge to edge. For this reason, a horizontal padding has been added to both kor-app-bar and to the kor-grid itself.

Since the homepage of dev.to is based on a 2-dimensional grid, the kor-grid component has been used and set to have grid-template-columns: 240px 2fr 1fr, as shown on the image below:

🏁 Conclusion

In this post we have showcased the flexibility of Kor UI and how developers and designers can customize themes to achieve unique visual appearance for expressing their brand’s personality.

Besides showing how color and fonts can be changed, we have seen that individual components can have their appearance modified without compromising their behaviour.

Furthermore, we have shown how complex layouts can be achieved through minimal settings and the use of components such as the Grid.

In the next stories of this series we will cover more diverse use cases, including mobile apps. We hope you have found the information useful and hope to see you next time!

Theming with Kor UI

Eduardo Ferreira — Wed, 19 Aug 2020 13:02:16 +0000

Theming web apps is especially useful for 2 purposes: enhancing brand expression and improving user experience. In this guide, I will share some best practices on creating and applying custom themes using Kor UI to help improve your app in both of these points.

🏷️ Enhancing brand expression

For companies developing apps based on an open source design system such as Kor UI, it is important that the visual appearance of UI components expresses the brand identity through elements such as fonts or colors.

While the re-use of components and patterns reduces the learning curve for users, having a UI that is excessively uniform with those of other similar products can be a missed opportunity for brand expression.

❤️ Improving user experience

Users of web or mobile apps nowadays expect them to allow setting preferred color schemes either automatically (e.g. based on preferred browser or OS theme) or manually (e.g. through user preference settings).

It is also important to mention that theming is a powerful method of improving accessibility for users with color blindness or other types of visual impairments, or even to improve readability of text for apps being used in places with excessive or low ambient light.

🎨 Customizing colors

As a starting point to understand how to customize colors, let's take a look into how the default themes are defined, which variables are available: and how they are categorized:

*[theme="dark"] {
  /* neutral colors are used mostly for text, icons, and lines */
  --neutral-1: 255, 255, 255;
  --neutral-2: 0, 0, 0;
  /* accent colors are used mostly for indicating active states in components */
  --accent-1: 60, 100, 240;
  --accent-1b: 70, 110, 250;
  --accent-1c: 50, 90, 230;
  /* base colors are used in containers and follow a layering approach */
  --base-0: 0, 0, 2;
  --base-1: 15, 15, 15;
  --base-2: 25, 25, 25;
  --base-3: 35, 35, 35;
  --base-4: 45, 45, 45;
  /* functional colors are used for indicating status */
  --functional-blue: 20, 120, 220;
  --functional-red: 220, 40, 40;
  --functional-yellow: 220, 160, 40;
  --functional-green: 40, 160, 40;
  /* text colors are used to define the font/icon colors and define hierarchy through opacity */
  --text-1: rgba(var(--neutral-1), .90);
  --text-2: rgba(var(--neutral-1), .60);
  --text-3: rgba(var(--neutral-1), .20);
  /* shadow colors are used for the layering of cards, app bar and other containers */
  --shadow-1: 0 2px 8px rgba(0,0,0,.2), 0 1px 4px rgba(0,0,0,.15);
}

Here are some tips when customizing each of the 6 existing color categories:

Neutral colors should take into consideration the lightness of the theme. If a theme is mostly dark (e.g. dark blue), set --neutral-1 to be white (or another light color) and --neutral-2 to be black (or another dark color).
Accent colors should convey a call-to-action and therefore have sufficient contrast with the background (base) colors. It is not good practice using colors that could clash with the functional ones (red, green, blue) as this could lead to user error or confusion.
Base colors are used as the background of containers and by default follow a layered approach, meaning that the deepest layers (--base-1) are darker than the ones closer to the surface (--base-4). If your app does not intend to use layering, you can just set all base colors to be the same.
Functional colors should convey meaning to the user (e.g. an error has happened) and therefore it is not recommended to change them drastically. Always look for accessibility or safety standards when updating them to avoid for example that users will ignore error messages.
Text colors should also go from strongest (--text-1, headline text) to lightest (--text-3, disabled text).
Shadow color is defined following the box-shadow definition (offset-x | offset-y | blur-radius | color). If you would like to use outlines instead of shadows, you can define it as 0 0 1px rgba(0, 0, 0, .4), for example.

Modifying vs. creating a theme

Kor UI comes with two pre-defined themes ready to be used: light and dark. When creating a new theme you should decide whether you would like to modify these defaults or create another one from scratch.

If you go for the first approach, you have the option of only modifying a few variables while keeping the others as-is, and if you go for the second you would need to define all of them:

/* here, only the accent colors are modified on the default dark theme */
*[theme="dark"] {
  --accent-1: 100, 100, 240;
  --accent-1b: 110, 110, 250;
  --accent-1c: 90, 90, 230;
}

/* while here all the variables have to be defined and a new name has to be given */
*[theme="high-contrast"] {
  /* ... */
}

After a new theme has been created, you can use it just like the default ones:

<html theme="high-contrast"> ... </html>

🗛 Customizing fonts

The definition of fonts in Kor UI is done on a document level, and two font families can be declared: one for headings (display) and another one for body text.

/* 
@font-face {
  font-family: 'my-body-font';
  src: url('./assets/fonts/body-font.woff2') format('woff2');
}

@font-face {
  font-family: 'my-display-font';
  src: url('./assets/fonts/display-font.woff2') format('woff2');
}

html, body {
  --body-1: normal 14px/24px 'my-body-font';
  --body-2: normal 12px/16px 'my-body-font';
  --header-1: bold 16px/24px 'my-display-font';
  --header-2: bold 14px/24px 'my-display-font';
  font-family: 'my-body-font', sans-serif;
}

The steps to modify the default fonts are:

Import font-face if you are not using a standard browser or system font. The files should be provided as an asset of you application and imported through css using the @font-face rule.
Update the variables to match you newly imported font. The variable is defined following the css font definition (font-weight | font-size/line-height | font-family). If you want body and header fonts to be the same, just use the same font family for all four variables.
Assign the default html font-family to be your newly defined body font.

Conclusion

In this guide we have covered the basics of customizing themes in Kor UI. Further customization is available by applying css to the components themselves (e.g. modifying the border radius of buttons) to make it fit even more your brand identity.

In a following post I will share some tips and best practices on applying themes based on user preference, browser presets, persistent theming and so on. I hope you enjoyed my first post and until next time!