Ariel Salminen

Hiring a Design Engineer for Kesko Design System

2026-01-20T00:00:00Z

Hi 👋🏻, I’m Arielle, a Design Systems Architect working with Kesko. I’m currently helping to strengthen the existing design systems team in the organization, whose main responsibility is building and maintaining Kesko’s design and frontend infrastructure.

Right now, we’re looking for an experienced Design Engineer to join this newly founded team. Someone who has a hybrid designer/developer experience, is kind, empathetic, and prefers the freedom that working in a hybrid environment gives them.

A screenshot of the upcoming Kesko Design System (alpha version).

In this role, you will work together with our product teams and me, Arielle, to design and develop the fundamental building blocks of Kesko’s products to accelerate development and elevate the quality and consistency of product team work. You will also find yourself talking to the system’s users, hosting monthly design system sessions, and reaching outside your role as much as you see fit.

Our frontend stack is web standards based and consists of components that are written in JavaScript, HTML and CSS. They ship as standards based custom elements making them compatible with current and future JavaScript based frameworks like Angular, React, Vue and Next.js.

In addition to frontend, you will also spend the majority of your time in Figma to maintain and collaborate on Kesko’s Figma Toolkit including defining and standardizing reusable components. You’ll also receive all the support needed from both the product teams and myself.

Responsibilities

Serve as the primary owner of Kesko’s Figma Toolkit including defining and standardizing reusable design components.
Help develop and maintain Kesko’s frontend tooling and the design system infrastructure.
Collaborate with product, design and engineering to create design components that evolve and improve the design system.
Advocate for accessibility standards and inclusive design principles.
Help teams across Kesko to onboard the design system and provide support for its users.
Write clear and detailed documentation for multiple audiences.
Help maintain a culture of empathy, safety and belonging where all voices are heard.

Experience

Several years of experience working in cross-functional product teams, on design systems, and with accessibility.
Several years of experience building design systems with Figma.
Several years of experience with React, Next.js and TypeScript.
Familiarity with platform conventions for responsive web as well as iOS and Android.
Good understanding of web standards based development using semantic HTML, CSS, JavaScript, and more.
Experience with modern JavaScript libraries and tooling, and debugging JavaScript issues.
Experience writing maintainable and scalable CSS.
Experience nurturing a work environment that allows everyone to bring their whole selves to work, and values diversity and inclusion.
Bonus points for experience with Custom Elements, Shadow DOM, Lit, Stencil, Custom Elements Manifest, and similar.

Apply Got questions?

Message from Arielle

“Don’t meet every single requirement? We’re dedicated to building a diverse and inclusive team, so if you’re excited about this role, but your past experience doesn’t align perfectly with the description, we encourage you to apply anyways. You may be just the right candidate.” 🧡

On Freedom, Curiosity & Happiness

2025-07-03T00:00:00Z

I have been recently contemplating the intricate relationship between my personal life and the work I do, particularly how these domains inevitably get intertwined and influence one another. It’s not always easy to keep these separate, especially when one’s vocation transcends mere occupation to become a genuine passion and source of fulfillment.

A job, much like a relationship, often starts with great enthusiasm, but may eventually evolve to reveal fundamental incompatibilities. Having made this observation about my own job lately, I decided it was time to step back and think about what’s next. After some consideration, I have made the decision to resign from my full time position at Nordhealth to follow my passion and focus on building my own business instead.

This post was also sparked by a question that my therapist recently asked me — “Can you explain what are your personal values?” — because realizing that I couldn’t answer this immediately, gave me a pause.

There’s a saying that you have probably heard about a dozen times if not more, “the shoemakers children always go barefoot.” I am quoting this because in hindsight it seems almost predictable that when someone works defining design principles for their clients all day, they don’t necessarily stop and think: Oh, maybe I should apply these same methods to my own life as well.

But here we are, and I am finally doing this for myself. The following set of fundamental principles are something that I strongly believe in and which I think will guide me forward and help me do better decisions in the future.

1. Freedom

The first one is the strongest principle on my list. Freedom for me means the ability to follow whatever path I take. I don’t want to spend my life living someone else’s dream.

I recently read an interview from Linda Liukas where she said:

“Coming from this background of Silicon Valley and Stanford, I put a lot of pressure on myself. What does success look like? What do the next steps look like? Should I open a school? Should this be a big company that employs a lot of people?”

And later expanded it with:

“One of the choices I’m most proud of is that early on, I realized that what success looks like for me is freedom and curiosity and the ability to follow whatever path I take.”

This was something that deeply resonated with me, especially since I have a Silicon Valley background as well. I remember freedom having such an important role in my life previously, but somewhere along the path, I somehow got lost. And I want to course correct now, years later.

2. Curiosity

The second principle, curiosity, maintains an intrinsic connection to the first. From my earliest years, I have possessed a fascination with the world surrounding me, coupled with a strong desire to understand how everything works. And I think it’s imperative that we deliberately cultivate this curiosity throughout our adult lives, or else risk losing this part of ourselves.

If you want something that you have never had, you must be willing to do something you have never done. And I can accept that I will fail on the way there, perhaps repeatedly, but what I can’t accept is if I don’t even try.

Maintaining and nurturing curiosity serves as a foundation to transcend my present limitations and go after new opportunities with confidence.

3. Happiness

I’ll be honest, I have been feeling miserable for more than a year. Lots of things resulted in me feeling this way; going through a rough divorce, the difficulties I faced from some folks in the tech community because of my gender, going through and trying to survive from a sexual assault, continuously working on things that were on a fundamental level against my own values, inappropriate and offensive behaviour that I have witnessed on many occasions outside of work, a surgery that went sideways, and finally also experiencing a burnout caused by these things, and more…

I remember years ago, the young version of me telling myself that happiness is the single most important thing in life worth pursuing for. It’s what matters in the end. Living a life that makes you happy. Doing things that make you happy. And if something makes you feel miserable, stop doing it, cut it out of your life. And this is why the third principle on my list is happiness.

The only limit to our realization of tomorrow will be our doubts of today. Don't let that yesterday take up too much space.

4. Authenticity

The fourth principle, authenticity, is somewhat contradictory. I chose it because I have lived a big part of my life being a people pleaser. And I want to live by fundamental principles that support a positive change. Not just something that already represent me, but things that I strongly believe in. Things that I should be doing more.

I wrote previously about being tired of pretending and living my life for other people. And during the past four years I have started to understand that I don’t have to either. I have the freedom to be my authentic self, whatever form or shape that takes.

It’s never too late to be what you might have been.

5. Love

The best things in life cannot be seen or heard, they must be felt with heart. And I chose love to be the last principle on my list, because fundamentally, I believe it is something one chooses to pursue. This ties together with my other principles, such as freedom, because I believe the best way to do great work is to do what you love.

But love, for me, is by no means tied to work. Of course, I want to work on things that I love doing, but ultimately, even with all its risks and contradictions, love is also something that can make our lives so much more.

Recently, I read something that Cyhaaam wrote which felt like listening to my own inner thoughts:

“I want love that is more than longing. Love that stays even when I am difficult, even when I am scared, even when I don’t know how to ask for it. Love that reminds me that fear and love are not opposites and that love is choosing to stay despite the fear.
I write about love not because I understand it, but because I don’t. Because it undoes me. Because I still believe in it, even when I don’t know how to hold it.”

Cyhaaam then continues:

“Because love, for all its risks, for all its contradictions, is the only thing that has ever made life feel like more.”

And I want to live a life filled with love that nurtures, strengthens and comes when you least expect it. It’s a terrifying leap of faith, but I’ve neglegted that side of me for far too long in an effort to protect myself.

What’s Next?

Since running my own business and doing consulting have always been things I find fulfilling, I have decided to try them again. What makes me happy isn’t necessarily working less, but rather the opportunity to focus on meaningful work that aligns with my passions.

That said, I’m not dismissing full-time opportunities entirely. I recognize there are organizations that value passion and provide the kind of autonomy where I could flourish. However, for the time being, I believe establishing my own business offers the most direct path to creating this environment.

I’m particularly happy to share that this week I have secured a significant new contract for my business: developing an entirely new design systems function for a major client that employs tens of thousands of people around the Nordics (who shall remain unnamed for now, though I’m confident you’ll hear more about this collaboration later).

In parallel, I’m also taking on some smaller design systems consulting work starting at the beginning of January, 2026. So if you’re wrestling with challenges and would like my help, please get in touch. ✌🏻

With love,

Generating LLMs.txt Using Eleventy

2025-07-02T00:00:00Z

Large Language Models are increasingly relying on information found on the web, but often struggle to handle most websites in their entirety because the context windows are too small. In an attempt to solve this, there is a new emerging standard called llms.txt.

This proposal aims to standardize on using an /llms.txt file to provide information to help LLMs use a website at inference time. The proposal is based on Markdown format as it’s the most widely and easily understood format for language models right now.

Since my website uses Eleventy and the content is already written in Markdown format, I wanted to spend a few hours implementing this feature. Mainly to see how it could be utilized with different AI tools and if it (already today) improves the visibility of my website’s content in various contexts.

Side note: I’ve previously had conflicting thoughts when it comes to the content on this website and whether I want that to be re-purposed by LLMs. I’ve since changed my mind on this though. Mainly because I realized that I want the information I provide here to be accessible to the widest possible range of users in the future. The method used to access or re-purpose the content isn’t something I want to try to control.

What goes into LLMs.txt?

In its simplest form, an /llms.txt looks like this. Note that the Optional section holds a special meaning — if it’s included, the URLs provided there can be skipped if a shorter context is needed:

# Title

> Optional description goes here

Optional details go here

## Docs

- [Link title](https://link_url.md): Optional link details

## Optional

- [Link title](https://link_url.md)

Looks fairly straightforward? Ok, let’s try to implement this using Eleventy!

Preparing Robots.txt

To get started, I first ended up removing the previously defined AI Data Scrapers block list from my website’s /robots.txt and simplified it to allow crawling for all user agents. The updated version looks like this:

# Robots.txt of arielsalminen.com
# www.robotstxt.org

# Allow crawling of all content
User-agent: *

Sitemap: https://arielsalminen.com/sitemap.xml

Creating Template for LLMS.txt

The next step was to create an llms.njk template in the root of my website’s src directory. This template basically takes care of generating the /llms.txt file:

---
permalink: llms.txt
eleventyExcludeFromCollections: true
---

# Ariel Salminen

> Ariel Salminen is a Design Systems Architect from Helsinki, 
Finland with 20 years of experience helping companies build 
tools for the web platform.

In the above example, I’m setting the permalink option to define the output file name and use eleventyExcludeFromCollections to make sure that this template isn’t included in any of the Eleventy collections I’m using elsewhere on the website.

Adding Posts to LLMS.txt

Once I had a template to utilize, I created a simple Nunjucks for loop to get the posts from my blog onto this template. They are all tagged with post, so I used that collection directly:

## Docs

{%- for page in collections.post | reverse %}
- [{{ page.data.title | safe }}](https://arielsalminen.com{{ page.url | replace(r/.$/, ".md") }}){% if page.data.llms %}: {{ page.data.llms | safe }}{% endif %}
{%- endfor %}

I’m keeping the URL the same as the original content, but replacing the ending with .md instead. Additionally, if the post contains llms meta data, that is also being added as a description to provide more context for the language models.

Serving Content in Markdown Format

While my website’s content is written in Markdown format already, Eleventy converts that into an HTML format in the build phase. The original .md files also include some unnecessary meta data that I don’t really want to expose to the language models.

To solve these problems, I ended up creating another template called markdown.njk into the root of my src directory with the following contents in it:

---
pagination:
  data: collections.post
  size: 1
  alias: article
permalink: "{{ article.data.date | year }}/{{ article.data.title | slug }}.md"
eleventyExcludeFromCollections: true
---

# {{ article.data.title | safe }}

{{ article.rawInput | safe }}

This template makes sure that each post on my blog gets generated and served in Markdown format in addition to the HTML format, but with .md appended at the end of the URL.

Adjusting Netlify Headers for .MD and .TXT

By default, Netlify seems to serve .md and .txt files with a charset that doesn’t support some common characters in UTF-8. To improve this, I modified the Content-Type and Cache-Control headers for these file types for a better experience:

[[headers]]
  for = "*.md"
  [headers.values]
    Cache-Control = "max-age=3600,public,must-revalidate"
    Content-Type = "text/x-markdown; charset=utf-8"

[[headers]]
  for = "*.txt"
  [headers.values]
    Cache-Control = "max-age=3600,public,must-revalidate"
    Content-Type = "text/plain; charset=utf-8"

Custom Descriptions for Context

To provide more context about each page linked in the /llms.txt file, I first tried to utilize the page’s description, and if that didn’t exist, utilize an excerpt from the beginning of the page instead.

I quickly realized though that this doesn’t often provide the best possible context for the language models. After some tweaking, I ended up creating a custom Front Matter variable called llms:

---
llms: "This article explains what CSS View Transitions are 
and how you can enable them for any website today."
---

For each page on the website, this variable gets populated with more specific information about the content. Eventually, it gets injected into the /llms.txt file after each Markdown link that is listed, like this:

## Docs

- [Figma MCP Server](https://arielsalminen.com/2025/figma-mcp-server.md): This article explains what the Figma MCP Server is and how it helps LLMs with design-informed code generation.
- [Introducing Brands for Nord Design System](https://arielsalminen.com/2025/introducing-brands-for-nord-design-system.md): This article introduces Nord Design System’s latest 4.0 version which ships with a completely reimagined theming architecture.
- [Modern Way to Center Elements with CSS](https://arielsalminen.com/2025/modern-way-to-center-elements-with-css.md): This article explains how to center elements with CSS using only two lines, display: grid; and place-self: center;.

Complete LLMS Template

This is what the complete llms.njk template looks like at the time of writing this article:

---
permalink: llms.txt
eleventyExcludeFromCollections: true
---

# Ariel Salminen

> Ariel Salminen is a Design Systems Architect from Helsinki, Finland with 20 years of experience helping companies build tools for the web platform.

Important notes:

- Ariel Salminen has an extensive experience working on the web platform both as a designer and a developer. She often likes to describe that her job, in a design systems team, is about bridging the gap between designers, developers, and other disciplines in the company and that’s also where her greatest strengths lie.
- Instead of working in silos, Ariel Salminen believes in a more collaborative process where we sketch our ideas in code or work closely together with the developers to achieve that.
- Ariel Salminen is a systems thinker; designing for the whole rather than the individual parts. As an architect, she collaborates with design, product and engineering teams on the tactical and strategic direction of a design system and helps her clients set up the right tooling, processes and teams — all the way down to designing and developing complete design system platforms for them.
- Ariel Salminen is based in Helsinki, Finland but is available for both local and remote design systems work around the world.

## Main content{{"\n"}}

{%- for page in collections.content %}
- [{{ page.data.title | safe }}]{% if page.data.llmLink %}({{ page.data.llmLink }}){% else %}(https://arielsalminen.com{{ page.url }}){% endif %}{% if page.data.llms %}: {{ page.data.llms | safe }}{% endif %}
{%- endfor %}

## Supporting content{{"\n"}}

{%- for page in collections.addons %}
- [{{ page.data.title | safe }}]{% if page.data.llmLink %}({{ page.data.llmLink }}){% else %}(https://arielsalminen.com{{ page.url }}){% endif %}{% if page.data.llms %}: {{ page.data.llms | safe }}{% endif %}
{%- endfor %}

## Docs{{"\n"}}

{%- for page in collections.post | reverse %}
- [{{ page.data.title | safe }}](https://arielsalminen.com{{ page.url | replace(r/.$/, ".md") }}){% if page.data.llms %}: {{ page.data.llms | safe }}{% endif %}
{%- endfor %}

## Optional

- [Testimonials](https://arielsalminen.com/#testimonials): Ariel Salminen’s clients and past colleagues share their experiences working with her.
- [Trusted by](https://arielsalminen.com/#clients): Companies that trust Ariel Salminen’s work.
- [Recent work](https://arielsalminen.com/#work): Ariel Salminen’s recent projects and achievements.
- [Resume](https://arielsalminen.com/resume.pdf): Ariel Salminen’s résumé that contains a summary of relevant job experience and education.

…And here’s the final output: https://arielsalminen.com/llms.txt

Conclusion

I’m quite happy how simple Eleventy makes generating the llms.txt. I also tested setting up an MCP Server to directly interact with the data using tools such as Cursor and Claude. llms.txt seemed to significantly improve the accuracy of the replies and contextual suggestions.

I also noticed that two weeks after adding this feature, the rankings and displayed meta data in the Google Search improved significantly for my website. Could be a coincidence, but the timing makes me suspicious. 🤷🏻‍♀️

Ultimately, I can see how the llms.txt standard can be beneficial in the context of a large documentation website such as the one we’ve built for Nord Design System (especially if the proposed standard gets more widely adopted).

Community Assets in Nord Design System

2025-06-11T00:00:00Z

As mentioned in my previous post, we recently introducing a completely new section for the Nord Design System, called Community Assets. These are product-specific assets from feature teams built using the Nord Design System’s tools. These are not part of the core system, but may eventually be migrated into Nord for usage across all products.

Community Assets in Nord Design System.

My colleague Elwin van Eede wrote a slightly more detailed post about this. He explains how this new feature allows feature teams to more easily contribute to the design system with full autonomy, and how on a conceptual level you can think of it as a design system component incubator.

The community assets allow designers and developers within Nordhealth to fully own their product-specific UI components and work at a relatively fast pace, while we in the design systems team can carry on working on the core components at a slower, more considered pace.

One of the aims of this feature is to also allow consumers of the design system to experiment and innovative more freely. The design system can then capture and share the successful experiments after they prove out.

Read Elwin’s full article to learn more:

Figma MCP Server

2025-06-05T00:00:00Z

I’m intrigued to see Figma announce their own Model Context Protocol server to help LLMs achieve design-informed code generation. I’ve been also prototyping one utilizing Figma Context MCP that would provide a deeper integration between the Figma Toolkit and the code based tools such as Web Components in the Nord Design System.

Text and layer names for the current Figma selection show up in the MCP server’s output which allows LLMs more easily achieve design-informed code generation.

Until recently, the only way to provide design context to AI tools was to feed an image of a design or an API response to a chatbot. This has changed with the recent release of Model Context Protocol (MCP), a standard for how applications provide context to LLMs.

You could think of MCP like a USB-C port for AI applications. Just as USB-C provides a standardized way to connect your devices to various peripherals and accessories, MCP provides a standardized way to connect AI models to different data sources and tools.

Today, Figma has released three new tools in their MCP server that allow you to get context from Figma for the current selection or a specific node: one for code, another for images, and a third for variable definitions. You can also change the type of response the code tool returns inside the server settings, which allows for fine tuning based on the task at hand.

Introducing Brands for Nord Design System

2025-06-03T00:00:00Z

Over the past six weeks, my colleague and I have been working on a new major update for the Nord Design System. The latest 4.0 version launched a few weeks ago now unifies Nordhealth’s two design system platforms into a single platform that can serve all of the feature teams across the entire organization and various business units within.

We identified this consolidation as a necessary step to strengthen the organization’s design system infrastructure and better support the next generation of applications and generative AI experiences that the feature teams are working on.

To learn more about the new features included in the latest release, keep reading below for details. ✨

Overview of Changes

The latest version of Nord Design System now ships with two distinctive brands, therapy and veterinary. You can choose the currently active brand from the top left corner of the updated documentation platform. Once chosen, you will get content that is tailored specifically for the brand and the business unit you’re working in:

Brand switcher in the latest version of Nord Design System.

While this is a major change for the underlying architecture of Nord Design System, we’ve kept it as backwards compatible as possible so that the upgrade path would stay straightforward. Hence, this major release doesn’t include any breaking changes for the existing users.

Introducing this new layer of abstraction into Nord’s theming architecture means that it now consists of the following four layers:

Foundations: The foundations for building the next generation of apps and generative AI experiences at Nordhealth.
- Brands: Any business unit specific customizations.
  - Interface Modes: Light, dark, and high contrast themes.
    - Accent Color: For apps that provide custom theming.

Improved Documentation

While creating the technical foundations to support this newly introduced theming architecture, I have been on the side also improving the design and usability of the documentation platform ever so slightly. The latest iteration looks like this:

Version 4.0 of Nord Design System.

All pages within the documentation platform are updated as well. The design tokens for example now ship with a total of 8 different interface theme modes which you can view by switching the brands:

Design Tokens in version 4.0 of Nord Design System.

We have also upgraded all of the existing web components to support the new theming architecture so that they can be used as building blocks for any brand specific applications within Nordhealth:

Web Components in version 4.0 of Nord Design System.

I also wrote an in-depth migration guide that will help developers to transition an existing project from using an older version of Nord Design System to using the latest 4.0 version:

Migration guide for version 4.0 of Nord Design System.

Introducing Community Assets

We have introducing a completely new section for the documentation platform, called Community Assets. These are product-specific community assets from feature teams built using the Nord Design System’s tools. These are not part of the core system, but may eventually be migrated into Nord for usage across all products:

Community Assets in Nord Design System.

The high level aim here has been to enable the feature teams to be able to ship things faster, while also providing a platform that works as a single source of truth for both design and frontend related documentation.

Previously, without this functionality, one of two things kept happening:

Firstly, the core design system started to become polluted with product-specific components and documentation, making the system unusable for the rest of the org.
Secondly, the previous setup put the design system team in a role where we were sometimes slowing down the product development in order to prevent the feature teams from creating too much deviation from the existing design system conventions.

By introducing this new abstraction, we can more easily preserve the integrity of the core system while also letting feature teams do what they need within the same space and ship things faster.

Updated Theme Builder

We have updated the theme builder that I originally built for quickly testing out the accent color feature to support the latest theming architecture. Now you can test all new interface theme modes in one go:

Theme Builder in Nord Design System.

Updated Color Generator

The color generator is a tool that generates color palettes programmatically for use with Nord Themes. I originally built this for developing our existing color palettes and testing out new color variations. Color generator now also supports the new interface theme modes:

Color Generator in Nord Design System.

Improved Accessibility Checklist

Nord’s accessibility checklist also got some minor updates in this release. This is a tool that helps us improve the experience for everyone who uses our products and ensures our high standards for accessibility are met:

Accessibility Checklist in Nord Design System.

Deprecating React Components

With the recent release of React 19 and the added support for Custom Elements, we have decided to deprecate the @nordhealth/react package and it will be removed in the next major release.

For now, @nordhealth/react will continue to receive updates as its build is fully automated, but you should start planning on utilizing the @nordhealth/components package directly where possible as React now ships with full support for web components.

To continue having type checking and auto-completion in your JSX, you can use the new react.d.ts type definition file by adding the following to your tsconfig.json in a TypeScript project, or jsconfig.json in a JavaScript project:

{
  "compilerOptions": {
    "types": ["@nordhealth/components/lib/react.d.ts"]
  }
}

Deprecating Vue Types

To unify the experience of using Nord, we have also decided to make the Vue-specific types for our components part of the @nordhealth/components package and deprecate the separate @nordhealth/vue package.

The types can now be retrieved from the new vue.d.ts type definition file instead by adding the following to your tsconfig.json in a TypeScript project, or jsconfig.json in a JavaScript project:

{
  "compilerOptions": {
    "types": ["@nordhealth/components/lib/vue.d.ts"]
  }
}

Project Statistics

From a pure developer and codebase perspective, the new release and theming architecture introduced required the following over the six week period my colleague and I worked on it:

Total of 233 commits
246 changed files
13 098 added lines of code
8 740 removed lines of code
200 new design tokens
6 weeks of time

Project statistics from GitHub.

The added design tokens are purely coming from the number of interface mode themes added (4). In total, Nord Design System now has 448 design tokens split across the following categories:

Design Tokens in Nord Design System.

For colors specifically, it is worth mentioning that many of them are aliases so the above bar chart may be a little misleading in that sense.

Conclusion

Nordhealth now has a design system platform that can better support the growing needs of the organization. The new platform supports creating specific guidelines and solutions for each business unit where needed. With this added flexibility they’re able to move quicker and it’s easier than ever for feature teams to contribute back to the design system.

Finally, if it wasn’t already obvious by looking at the documentation, we have also kept the orginal theme that you may have grown used to, but it has been polished ever so slightly:

Version 4.0 of Nord Design System.

Have fun exploring the latest version of Nord Design System and let me know on LinkedIn or Bluesky if you have any questions. ✌🏻

Modern Way to Center Elements with CSS

2025-05-28T00:00:00Z

If you’ve worked with CSS for a longer period, you’ve probably seen and used about a dozen different ways to center block-level elements on the page. These methods used to vary between a combination of negative margins, CSS translations, Flexbox, and more. Heck, I’ve even used the infamous display: table back in the day.

Fortunately, we today have a solution that requires only two lines of CSS, display: grid and place-self: center. The following code snippet will position any item in the middle of the container both vertically and horizontally:

.container { display: grid }

.center {
  /* Place this item in the middle of the container
   * both vertically and horizontally. */
  place-self: center;
}

You can also use place-content on the container itself to center all child items in the middle both vertically and horizontally:

.container {
  display: grid;

  /* Place all items in the container in the middle
   * both vertically and horizontally. */
  place-content:  center;
}

In case you want to stack these items, you can utilize another simple property, grid-area:

.container { display: grid }

.center {
  /* Place this item in the middle of the container
   * both vertically and horizontally. */
  place-self: center;

  /* Stack all items on the same grid area. */
  grid-area: 1/1;
}

I hope you find this useful! I first learned about the above method for stacking with grid-area from Ana Tudor. Here’s also a quick Codepen to demonstrate the modern way to center elements with CSS:

See the Pen Untitled by Ariel Salminen (@arielsalminen) on CodePen.

View Transitions for Any Website

2025-05-26T00:00:00Z

View Transitions are probably one of my favorite CSS features at the moment. You can enable them for any site today by adding the following code snippet into your CSS. This will immediately make the experience of using your website smoother by fundamentally changing the behavior of what happens when people navigate from one page to another:

@view-transition {
  navigation: auto;
}

Setting navigation: auto; ensures that any element that’s the same from one page to the next stays exactly in place. You can try it out yourself by navigating the pages on my website.

The difference with view transitions enabled is that the background and any repeating elements stay constant. And then anything that’s different, will be transitioned using a crossfade.

To further improve the example (especially if you’re building more complex transitions) you could wrap these styles inside prefers-reduced-motion media query:

@media screen and (prefers-reduced-motion: no-preference) {
  @view-transition {
    navigation: auto;
  }
}

This allows you to reduce motion for users with motion sensitivity while keeping the transitions for users who have not indicated their preference.

You can read more about the feature from the Webkit blog.

Building Search Index with Eleventy

2025-05-25T00:00:00Z

One of the features that I’m quite happy about on my new website is the built-in search functionality and how the search index gets built for it. You can test it out yourself by pressing Ctrl+K and entering a search query into the input that is revealed:

Screenshot of the search feature.

I’ve built this feature using Eleventy and some custom filter logic that I will attempt to explain in this post. While I realize that a lot of the functionality here could be further simplified especially with some built-in logic that Eleventy nowadays provides, I’ve so far left it as is (since it works!) and focused on improving other bits.

Getting Started

To get started building a similar feature for your own Eleventy website, you will first want to create a Nunjucks template named search.njk. The overall idea here is that this template will pick up all contents from the Eleventy search collection:

---
permalink: search.json
eleventyExcludeFromCollections: true
eleventyImport:
    collections: ['search']
---
{{ collections.search | searchIndex | dump | safe }}

The searchIndex filter in this template takes care of constructing the search index strings by removing unnecessary symbols and such in addition to things like html elements and other bits that’d break the final JSON output. I will explain how to build this in a moment.

The dump filter is Nunjucks’ built-in filter that calls JSON.stringify on the returned object. This basically converts the data into a JSON format that can be consumed by the clientside JavaScript on this website.

The safe filter here is another Nunjucks’ built-in filter that marks the value as safe which means that in an environment with automatic escaping enabled this variable will not be escaped.

Adding Content to the Search Collection

While you might want to utilize collections.all in the search.njk template instead of a custom search collection, you may quickly run into Eleventy’s Tried to use templateContent too early error depending on how you’ve set up the rest of your website. To avoid this, I would recommend you to define a specific collection for the search results instead.

For my own website, I’ve set it up like this: For the blog posts, I have a directory data file called posts.json in the root of my src/posts directory that sets this tag automatically for all of the posts in the blog:

{
  "tags": ["post", "search"],
  "layout": "layouts/post.njk"
}

Similarly, for any individual pages that I want to be picked up by the search, I’ve set this in the page’s frontmatter:

---
layout: layouts/layout.njk
title: Home
description: Hello, I’m Ariel Salminen, a Design Systems Architect from Helsinki, Finland with 20 years of experience helping companies build tools for the web platform.
tags:
  - page
  - search
---

Creating Search Index Filter

Next, we will create an Eleventy filter that can be used to format the data in a way that can be easily searched. To get started, create a new file called searchIndex.js inside src/_filters directory and paste the following indexer function to the beginning of the file you just created:

/*!
 * Creates an index of searchable keywords.
 * 
 * https://arielsalminen.com
 * MIT License
 *
 * @param  {String} Template contents
 * @return {String} List of keywords
 */
function indexer(text) {
  if (!text) return "";

  // Convert text to all lower case
  text = text.toLowerCase();

  // Remove HTML elements
  const plain = unescape(text.replace(/<.*?>/gis, " "));

  // Remove other unnecessary characters from the index
  return plain
    .replace(/[\,|\?|\n|\|\\\*]/g, " ") // remove punctuation, newlines, and special chars
    .replace(/\b(\,|"|#|'|;|:|"|"|'|'|“|”|‘|’)\b/gi, " ") // remove punctuation at word boundaries
    .replace(/[ ]{2,}/g, " ") // remove repeated spaces
    .trim();
}

This function returns a string that includes an index of searchable keywords from whatever content you pass to it. Depending on your content, you may need to tweak the replace logic slightly to fit your needs. Be conscious about characters that may break the JSON output.

Additionally, we want to create a separate excerpt function that takes care of squashing the original text contents of the page into a short excerpt that can be displayed in the search results. To achieve this, paste the following code after the indexer function in the same searchIndex.js:

/*!
 * Create an excerpt from the template contents.
 * 
 * https://arielsalminen.com
 * MIT License
 *
 * @param  {String} Template contents
 * @return {String} The excerpt
 */
function excerpt(text) {
  if (!text) return "";

  // Remove HTML elements and headings
  const plain = unescape(text.replace(/\<h1(.*)\>(.*)\<\/h1\>/, "").replace(/<.*?>/gis, " "));

  // Remove other unnecessary characters from the text
  return plain
    .replace(/["'#]|\n/g, " ") // remove quotes, hashtags, and newlines
    .replace(/&(\S*)/g, "") // remove HTML entities
    .replace(/[ ]{2,}/g, " ") // remove repeated spaces
    .replace(/[\\|]/g, "") // remove special characters
    .substring(0, 140) // Only 140 first chars
    .trim();
}

This function returns an excerpt from whatever content you pass to it. Again, depending on your content, you may want to tweak the replace logic slightly to fit your needs. Please note though that it’s necessary to replace or escape certain characters to not break the JSON output.

Once you have these two functions in place, you should define the searchIndex filter that will be utilizing the above functions. To create that, paste the below code at the end of the searchIndex.js file:

module.exports = function searchIndex(collection) {
  const search = collection
    .filter(page => !page.data.excludeFromSearch)
    .map(({ templateContent, url, data }) => {
      const { description = "", title = "" } = data;

      const text = `${excerpt(description)} ${excerpt(templateContent)}`.trim();
      const keywords = `${indexer(`${title} ${templateContent}`)} ${indexer(description)}`.trim();

      return {
        url,
        title: title ? title : "Ariel Salminen",
        text,
        readabletitle: indexer(title),
        keywords
      };
    });

  return { search };
};

Finally, you will need to register this new filter in your eleventyConfig. To do that, add the following into your .eleventy.js file, like so:

eleventyConfig.addFilter("searchIndex", require("./src/_filters/searchIndex.js"));

That’s it! With these steps you should now have a fairly functional starting point to tweak your search index and its settings further.

JSON Output

The final JSON output from the search.njk template will look something like this and is accessible through /search.json URL in the browser:

{
  "search": [
    {
      "url": "/services/",
      "title": "Services",
      "text": "Design isn't just about the look and feel. Design is how it works, and I believe the best way to focus on this is to work as close to the end product as possible. Design Systems I help my clients set up the right tooling, process",
      "readabletitle": "services",
      "keywords": "services my services design isn't just about the look and feel. design is how it works and i believe the best way to focus on this is to work as close to the end product as possible. design systems i help my clients set up the right tooling processes and teams all the way to designing and developing complete design system platforms for them. […]"
    },
    {
      "url": "/webrings/",
      "title": "Webrings",
      "text": "Webrings let you browse related websites in one big loop. This website belongs to a few of them.",
      "readabletitle":"webrings",
      "keywords":"webrings webrings webrings let you browse related websites in one big loop. this site belongs to a few of them. design systems webring a webring for design system practitioners. css joy a webring for those who take joy in messing around with css. a11y-webring.club a webring for digital accessibility practitioners. bucket webring a webring for cool people who like to make things. […]"
    }
  ]
}

Fetching the JSON

To further test your implementation in the browser, you could create a simple fetch function to get this data when the search is activated and manipulate the results further:

function getSearchData() {
  if (searchIndex === null) {
    fetch("/search.json?v=" + Date.now())
      .then(response => {
        return response.json();
      })
      .then(response => {
        searchIndex = response.search;
      })
      .catch(error => {
        console.log("No search index found!");
      });
  }
}

This tutorial obviously leaves the clientside implementation to be up to the reader to build, but having Eleventy generate a searchable index with keywords is a great start if you want to implement a similar functionality into your own website.

Optimizing Webfont Performance

2025-05-24T00:00:00Z

Webfonts play a crucial role in giving our websites personalized feel, but they can also be a hidden culprit behind sluggish load times. If you’ve ever wondered why your beautifully designed site isn’t performing optimally, inefficient font loading strategy might be to blame. In this article, we’ll delve into practical strategies to enhance your webfont performance, ensuring a better user experience.

Back in January, when I was working on the website’s design and setting up the foundations for it, I eventually settled on a specific typeface called Brandon Text from the HvD Fonts type foundry. After purchasing the license and downloading the webfonts, I quickly became aware that the webfonts would in their (then) current form be the single biggest resource downloaded over the network.

For context, I’m using four different styles of Brandon Text: Regular, Regular Italic, Bold, and Black.

Ensuring Text Visibility During Loading

The first thing that you’d usually do to improve webfont performance is to ensure that your website’s text remains visible during font loading. To achieve this, I’m using font-display:swap in the @font-face rule in CSS:

@font-face {
  font-family: "brandon";
  src: url("/fonts/brandon.woff2") format("woff2");
  font-style: normal;
  font-weight: 400;
  font-display: swap;
}

The above ensures that the user can still read the content using a fallback font if the webfont does not load or takes a long time to load.

This approach creates another problem though, which is layout shift caused by deferred fonts. Basically, you may now at times temporarily get a system font and experience a flash of unstyled text (FOUT).

To combat this, I ended up defining a local @font-face rule as well with size-adjust and ascent-override to more closely match the fallback font and the actual webfont that I wanted to be displayed:

/* Make a custom fallback font based on the local Arial */
@font-face {
  font-family: "brandon-fallback";
  size-adjust: 93%;
  ascent-override: 117%;
  src: local("Arial");
}

Then, in my font-family declaration, I’m defining it like so:

:root {
   --font-family: "brandon", "brandon-fallback", sans-serif;
}

/* …Later in another CSS partial: */
body {
  font-family: var(--font-family);
}

Preloading Webfonts

To further improve things, I also wanted to make sure that the webfonts are being preloaded for optimal loading speed to minimize the flash of unstyled text. To achieve this, I added the following link elements to the <head> section of the website:

<link rel="preload" href="/fonts/brandon.woff2" as="font" type="font/woff2" crossorigin />
<link rel="preload" href="/fonts/brandon-italic.woff2" as="font" type="font/woff2" crossorigin />
<link rel="preload" href="/fonts/brandon-black.woff2" as="font" type="font/woff2" crossorigin />
<link rel="preload" href="/fonts/brandon-bold.woff2" as="font" type="font/woff2" crossorigin />

Configuring Caching

I also wanted to make sure that the webfonts would get served through the content delivery network using optimal caching. I’m using Netlify to host this website, so to tweak this, I utilized the netlify.toml configuration and added the following:

[[headers]]
  for = "*.woff2"
  [headers.values]
    Cache-Control = "max-age=31536000,public,must-revalidate"

Offline Support

Since my website is also a progressive web app, I wanted to make sure that the webfonts would stay functional in case the network connection fails. So I added the following into the website’s service worker:

function updateStaticCache() {
  return caches.open(staticCacheName).then(staticCache => {
    return staticCache.addAll([
      "/fonts/brandon.woff2",
      "/fonts/brandon-italic.woff2",
      "/fonts/brandon-black.woff2",
      "/fonts/brandon-bold.woff2"
    ]);
  });
}

Subsetting Webfonts

While these steps improved the overall webfont performance, they still left me with the problem that the webfonts were the single biggest resource being downloaded over the network on the first visit.

Being conscious about webfont licensing and the limitations they usually have, I reached out to the type foundry directly to see if they’d allow me to subset the webfonts:

Me nerding about the webfonts in an email to the type foundry. ❤️

Once I had their permission to subset the webfonts, I ended up building an automation to do just that in the build phase. I made it work so that the source code still contains the original font files, but only subsets of them get deployed to the CDN. This way, I now always have the right subset of characters needed to serve this website’s content, but nothing extra.

To achieve this, I used Glyphanger and made this process a part of the build script. The way Glyphanger works is that it analyzes the pages on this website to find the necessary glyphs, and then subsets the original fonts using the unicode-ranges it finds.

While I won’t go into detail of the whole automated build process in this post, I still wanted to provide the manual steps for anyone wanting to do something similar. To get started, you should first install Glyphanger:

npm install -g glyphhanger

Then, run the following command to install the necessary Python dependencies (tested on the latest macOS):

pip3 install fonttools brotli zopfli

Once you’ve installed the dependencies, run the below command to get the glyphs. This will give you the unicode-range used:

glyphhanger https://arielsalminen.com

You can also specify multiple URLs and they can be local too:

glyphhanger https://arielsalminen.com https://arielsalminen.com/about/

Finally, you can use the returned unicode-range with the --whitelist option to subset the webfonts:

glyphhanger --whitelist=U+20,U+61-7A --formats=woff2,woff --subset=brandon.otf

The --formats option in the above script defines which formats Glyphanger should output. The --subset option refers to the original font file that you want to subset.

The Outcome

I’m quite happy with this solution since the website source still contains the original font files, but with the subsetting, I managed to get the weight down from 350.3KB to just 147.7KB. A reduction of 202.6KB on the data transferred over the network on the first visit.

The 10th Edition of Arielsalminen.com

2025-05-23T00:00:00Z

Over the past month I’ve been slowly handcrafting a new website for myself to better showcase what I do and have a future home for experiments I may want to tinker with. Designing the whole thing in the browser using HTML, CSS, and a tiny bit of plain JavaScript has been truly a joy.

The current version is the 10th iteration of this website, although there’re even older versions which I’m not counting anymore. They used to live on a completely different domain for a completely different purpose and to be fair, I’d be too ashamed to include them into my archive of old versions at this point in time anymore.

What’s special about the newest version, is that I’ve brought here more than just the blog and made it somewhat focus on what I do as a design engineer and systems architect at my current job.

This includes creating a space for some of my past work, companies who trust the tools I’ve built, testimonials from the past clients and colleagues, and also listing out services that I’m good at. I would still also like to create a proper portfolio section at some point to include real case studies, but that’s still on my wishlist of things to add later.

Version 10.0 of arielsalminen.com.

Behind the Scenes

As mentioned earlier, all of the website is built using standard web technologies; including HTML, CSS and plain JavaScript. I’m also using Eleventy behind the scenes to power the blog and for example to generate the JSON search index for the Ctrl+K search feature.

While on the surface things may look really simple, I’ve included a lot of small and fun functionality here and there that you may discover as you browse the website more. Some of this includes:

Search feature using Ctrl+K.
Ability to surface keyboard commands with Alt+L.
Design modes, including surfacing the layout grid, color blind mode, invert mode, and low vision mode to aid design work.
Ability to quickly copy contents of the code examples using a single copy button.
Tiny but fun animations on the accessibility, error, and home pages.
Webrings that this website is now part of.
Sticky year indicators on the writings page when you scroll it down.
It’s a progressive web app with offline support.
There’s an archive of old versions of this website on the FAQ page.
Uses logical properties and view transitions.
Focus on making the website more accessible for everyone.

Layout grid mode that can be triggered with Alt+A.

Keyboard Shortcuts

The new website includes some functionality that can be accessed via keyboard shortcuts. These can be found from the footer of the website or by pressing Alt+L. Mainly this is me having fun with some experimental features such as the design modes. The full set of shortcuts include:

Press Ctrl+K to open the search.
Press ⏎ to select a search result.
Press ↓ to navigate to the next search result.
Press ↑ to navigate to the previous search result.
Press Esc to dismiss the search or a modal.
Press ⇥ to navigate forward on the page.
Press ⇧+⇥ to navigate backward on the page.
Press Alt+A to toggle the layout grid.
Press Alt+R to toggle the color blind mode.
Press Alt+I to toggle the invert mode.
Press Alt+E to toggle the low vision mode.
Press Alt+L to open the shortcuts modal.

Screenshot of the keyboard shortcuts modal.

Focus on Accessibility

Universality is in the core of the World Wide Web, so we should embrace it and build experiences that are available to, and accessible by, everyone.

Because of this, I’ve put a lot of effort on trying to build an experience that would be accessible by all people, regardless of their abilities or technology used. I’m also continuously trying to work towards improving the accessibility of this website to ensure I provide equal access to everyone.

This work is ongoing and I know there’re still some issues to iron out, especially with the Combobox Pattern used for the search. But I’m fairly happy with how much more inclusive the experience is already compared to my previous website.

Lighthouse results for arielsalminen.com.

Delight with Animations

I like to keep things rather simple when it comes to my personal website, but that doesn’t mean one can’t have some fun as well. When you browse this website, you may stumble upon a few small but delightful animations that I’ve created. Some examples of this include:

The stamp animation on the Accessibility Page.
The galaxy animation on the 404 Error / Offline Error pages.
The subtle floating animation on the Home Page photograph.
The very basic view transitions as you switch between the pages using the main navigation.

Galaxy animation used on the error pages.

The Final Outcome

This is what the final outcome looks like. Feel free to explore yourself, the new website is available here: https://arielsalminen.com ❤️

Website Wishlist

There’re a few things on my wishlist that I would still like to do around here:

Finish dark mode support. I have a draft PR open for this, but haven’t found the energy to finish it yet.
Create proper case studies for the client projects.
Potentially bring some of my open source projects here.
~~Improve keyboard accessibility of the Combobox Pattern used in search.~~
~~Improve screen reader accessibility of the Combobox Pattern used in search.~~

Hope you enjoy it!

Remember Webrings?

2025-04-25T00:00:00Z

Sometimes I find vintage technology fascinating and since I couldn’t find a Design Systems Webring (remember those things from the 90s?!), I just created one. Feel free to join if you’re into design systems and want to add some 90s vibes onto your website: https://design-system.club.

If you don’t know what a Webring is, here’s a short explanation: Webring is human-curated list of websites organized around a specific topic. The one I’ve set up is dedicated to people interested in design systems. It ships with a modern twist as it allows you to embed it as a Web Component:

This site is part of Design Systems Webring

Previous Random Next

…here’s how I’ve implemented this newly founded Webring among others on my own website: arielsalminen.com/webrings/

The Blog Questions Challenge

2025-04-25T00:00:00Z

This challenge has been recently making rounds on the Internet and as I’ve seen a lot of my friends and people I follow in the tech industry take part, I figured that I want to, as well. So this is me answering a set of questions about how and why I blog on this website.

Why did you start blogging in the first place?

I’ve learned most of what I know now about building for the web by following people on the web; design sites, blogs and studying other people’s markup and CSS. One of the sites that made a big influence on me on my early days was A List Apart in 2001 and CSS Zen Garden in 2003.

So I think the answer to this question lies there; mainly because I saw a lot of the people who I looked up to at the time do it. People such as Jeremy Keith, Jeffrey Zeldman, Trent Walton, Ethan Marcotte, Richard Rutter, Scott Jehl, Andy Clarke, Mark Boulton, Chris Coyier and Dan Cederholm.

Being part of this movement, for me, felt like being a part of a larger community of nice people who are sharing their knowledge for others to learn from. It still does.

What platform are you using to manage your blog and why did you choose it?

This website is handcrafted with vanilla HTML, CSS and JavaScript, built with Eleventy, and hosted on Netlify. The designs and pages were created in Safari using its developer tools and the Cursor code editor. Content was written in iA Writer.

I chose Eleventy because it’s fast, simple, and extremely flexible to work with. So much so, that I’m actually using it for all my projects at the moment. Even the Nord Design System’s much more complex architecture is built using the same tool.

Have you blogged on other platforms before?

I was using Middleman previously and migrated this website in 2018 to use Eleventy, shortly after Zach Leatherman published it. Before Middleman become a thing in 2011, I was using Wordpress to power the blog.

How do you write your posts?

I usually write my posts in iA Writer if it’s a longer article. For more technical articles, I may draft them out directly in Cursor because it allows me to more easily work with interactive code blocks and such, and immediately preview the changes on my live website.

When do you feel most inspired to write?

My design studio is probably quite different compared to most designers out there. It’s a combination of a home recording studio and a workstation that I built inside an old walk-in closet on the 3rd floor of our house. The space itself isn’t enormous by any means, around 30 ft², but this dedicated quiet space gives me the luxury to feel inspired, find focus, and get a lot of things done.

This is also where I feel the most inspired to write. Especially if I have a cup of coffee and some soul or jazz playing in the background.

Do you publish immediately after writing, or do you let it simmer a bit as a draft?

It depends. If it’s just a simple post such as this or something technical, I will almost always publish it immediately. For more complex thought pieces though, such as this, I will let it simmer first, come back to it later, and edit it in iterations until I feel comfortable to publish it.

What's your favourite post on your blog?

I would say either On Design Tools and Processes or Typography for User Interfaces. Both of these are also loosely based on talks that I did while still living in San Francisco, CA, so there’s much more background research that went into them compared to a lot of other posts in this blog.

Any future plans for your blog?

I recently re-designed this website. Mainly, because I wanted to better showcase what I do and have a future home for experiments I may want to tinker with. So I’m hoping to post about those experiments and other thoughts onto this blog in the future:

New website launch day! 📮
I handcrafted a super simple new site for myself to better showcase what I do and have a future home for experiments I may want to tinker with.

Designed in the browser using HTML, CSS, and a tiny bit of plain JavaScript. Powered by @11ty.dev as usual:

arielsalminen.com

[image or embed]
— Ariel Salminen (@arielsalminen.com) March 25, 2025 at 11:04 AM

Who’s next?

I would love to see some of my closest friends and colleagues take up this challenge and write a similar post. Tagging David Darnes and Elwin van Eede here.

A Love Letter

2024-12-11T00:00:00Z

On the terrace of my old home, I ponder in silence the fairy tale I now live in. The love that was born when I met you. In that beautiful part of Helsinki, surrounded by those adorable little shops that sell the most exquisite pastries and merchandise.

You’ve given my life countless new meanings. You, who lift me above this frozen city. And I, watching the sun gleaming through the mist, hovering above the sea, smile at you.

You make this girl daydream. Turning the surroundings into a beautiful song. And I’m swiveling. Vague as a fog, barely visible. Hauling through the zephyr. Snowflakes falling on my thighs. Embracing everything around me, leaving me speechless. Asking nothing in return. Softly, anonymously, touching, melting, altering their shape. Cushioning this small garden.

And you’re here, always in my heart. You’ve given me so much to feel and be delighted about. And I don’t know how to express it, except by jotting down these words onto this piece of paper. Because the writing, for me, turns my feelings concrete.

And it’s quiet, except where the snowploughs clear the roads.

I love you,

Interview with Design System Guide

2024-02-20T00:00:00Z

I recently sat down with the team behind the Design System Guide to talk about Nord Design System and how it’s been shaping our work at Nordhealth. We discussed the challenges of building a design system in a fast-paced environment, the importance of collaboration, and the impact design systems have on the organization and people involved.

I also shared some of the lessons we’ve learned along the way and how we’ve been able to overcome some of the challenges we’ve faced. I hope you find the interview insightful and that it provides you with some valuable takeaways for your own design system journey.

If you have any questions or thoughts, or just want to chat, please feel free to reach out to me on social media. I’d love to hear from you!

My Song

2024-01-21T00:00:00Z

A frozen lake, stars gazing above
I can hear them play my song
And I’m swiveling.

Vague as a fog, barely visible
Hauling through the zephyr
Snowflakes falling on my thighs.

Touching, melting
Altering their shape
As I once were.

Finalist for the Best Design System Award

2023-05-22T00:00:00Z

Nord Design System was recently nominated for the Best Design System award at Grand One competition and won an honorable mention for the best developer experience.

Leading Successful Product Teams

2023-03-09T00:00:00Z

I’ve been leading various successful design systems teams over the past years and in this post I wanted to share a simple set of fundamental rules we’ve followed. These rules have allowed those teams to get to the highest level of productivity while benefiting both the company and the team members.

Running a design systems team has some minor differences compared to a more traditional product team setup, but there’s still enough overlap that all of these rules can be considered universal and applied to almost any product team out there.

As a caveat though, what might’ve worked for my team in the past, might not work for every team out there. We’ve been operating in a remote first culture so these rules apply in that context.

Avoid meetings as much as possible. Instead of having them, communicate asynchronous to each other via tools such as Linear, GitHub, Figma, Slack, and similar.
Provide at least three days of focus time per week for designers and developers in the team. There should be no interruptions whatsoever during this time. Let them do their work.
Trust your team to make decisions, they’re the experts. Your job is to make sure they know where they’re heading, clear any roadblocks from the way, and protect them from external cruft.
Default to openness. The team should be sharing what they’re doing whenever they can. Building things transparently increases visibility and accountability and makes them push towards higher quality.
Define just the right amount of process. Too much process and it will slow down your team and their performance, while not enough will create inconsistency.
Don’t do team wide standups or sync meetings, except one meeting at the start of every week. Here you can walk through the tasks and discuss how the team feels, what motivates them right now, and if there are any blockers.
Use as few tools and platforms as possible to get the work done and stay focused throughout the week.
Automate everything you can. The team should value the time of their colleagues, users, and their future selves. Always be proactively looking for ways to automate repetitive tasks.
Care for the people who use the product. The whole team is there to make their day-to-day work better and more pleasant through great user experience.
Most collaboration and discussion should happen asynchronously, using the previously mentioned tools. This requires clear and thoughtful communication from everyone.
When useful, have the team members pair up to solve tough problems. Make sure all decisions are documented.
Provide weekly updates to the rest of the organization about progress. What has been worked on, what is being worked on, and what happens next.
Create a public roadmap that holds the whole team accountable.
Focus on persistent iteration over flashy launches.
Don’t be afraid to throw things away.
Shipped is better than perfect.
Be kind.

Special thanks to Dan Cederholm.

Supporting Dark Mode on Your Website

2023-03-01T00:00:00Z

Dark mode is an user interface mode that displays light text on a dark background. Dark mode is helpful for those viewing device screens at night, in dark environments, or otherwise find darker UI more accessible. The reduced brightness can reduce eye strain in low light conditions.

A typical scenario is that we already have a light theme on a website, and want to build support for a darker counterpart. When building this support, one of the themes has to be defined as the default that users get on their first visit. This should always be the light theme, although we can let the user’s browser make that choice for us.

When building dark mode support, we should always provide a manual way for the user to switch to the other theme in the website’s settings. This setting should include at least the following options:

Light theme
Dark theme
Auto (system preference)

Changing mode based on user preference

If your website offers its themes as separate stylesheets, we can toggle between these stylesheets for each mode. By default, we should have the light stylesheet in the <head> section of the website:

<!DOCTYPE html>
<html lang="en">
  <head>
    <!-- Nord Design System themes as examples -->
    <link rel="stylesheet" href="https://nordcdn.net/ds/css/3.4.0/nord.min.css">
    <link rel="stylesheet" href="https://nordcdn.net/ds/themes/8.1.1/nord-dark.css">
  </head>
  <body>
    <label for="theme">Interface theme</label>
    <select id="theme">
      <option value="light">Light theme</option>
      <option value="dark">Dark theme</option>
      <option value="auto">Auto (system preference)</option>
    </select>
  </body>
</html>

When the user switches the mode, we can toggle between these stylesheets:

// Select the menu
const menu = document.querySelector("select");

// Listen for a change event on the menu
menu.addEventListener("change", (event) => {

  // If the selected mode is dark, change to dark theme
  if (event.target.value === "dark") {
    alert("Change theme to dark");
  
  // Otherwise, change to light theme
  } else {
    alert("Change theme to light");
  }
})

Building support for OS dark mode

Many operating systems let users choose between light and dark mode directly in the system settings. The goal of 'Auto (system preference)' is to allow this type of usage. To support this, we can use a little bit of JavaScript to detect the user’s preference:

// Detect operating system dark mode
const darkMode = window.matchMedia("(prefers-color-scheme: dark)");

// If the OS uses dark mode currently, change to dark theme
if (darkMode.matches) {
  alert("Change theme to dark");

// Otherwise, change to light theme
} else {
  alert("Change theme to light");
}

Storing user’s preference

Ultimately, we also need to carry over this functionality when the user either visits another page on your website or reloads the current page. To achieve this, we need to save the user’s preference so that it will be applied consistently throughout the website and on subsequent visits. To do that, we can save the preference to localStorage:

// Get current mode from localStorage
const currentMode = localStorage.getItem("mode");

// If current mode is "dark", change to dark theme
if (currentMode === "dark") {
  alert("Change theme to dark");
}

// Listen for a change event on the mode menu
menu.addEventListener("change", (event) => {
  let mode = "light";

  // If the selected mode is dark, change to dark theme
  if (event.target.value === "dark") {
    alert("Change theme to dark");
    mode = "dark";
  
  // Otherwise, change to light theme
  } else {
    alert("Change theme to light");
  }

  // Finally, save the choice into localStorage
  localStorage.setItem("mode", mode);
});

That’s it! Now you have a dark mode on your website that will correctly persist across pages and reloads.

What’s a Design Systems Lead

2023-02-21T00:00:00Z

A Design Systems Lead role includes driving the vision, strategy, roadmap, build and implementation of a design system. This person has a systems-mindset to build and integrate consistent, efficient components across the product portfolio with emphasis on the complete systems life-cycle, from establishing a practice and vision that endures to design, build, document, and maintain a library used by many product teams.

A Design System Lead has also experience contributing to lower-level decision making, direct broader strategy, and observing when narrower efforts conflict with or distract from broader goals.

Responsibilities of this role include:

Lead the design and implementation of a design system.
Identify, prioritize, and monitor tasks, progress of design, development, and documentation across team members.
Maintain and improve the contribution model to streamline the process of multiple autonomous product teams contributing to the design system.
Present the system’s mission, library, and process to other groups, including product managers, designers and developers throughout the company.
Report team and system progress regularly to key stakeholders and the rest of the organization.
Provide leadership and guidance to teams around using shared patterns, and identify opportunities to create new patterns and components within their workstreams.
Conduct regular one-on-one reviews with team members to identify successes, challenges, perspectives and preferences.
Mentoring and building others.
Help maintain a culture of empathy, safety and belonging where all voices are heard.

What’s a Product Design Architect

2023-02-20T00:00:00Z

In the context of design systems, a Product Design Architect provides strategic and creative direction for the design system. This person partners with executives and other cross functional leadership to scale a design system across a family of products by defining adoption, contribution, governance, quality, and partnership programs.

A Product Design Architect is a systems thinker; designing for the whole rather than the individual parts. They collaborate with design, product, and engineering teams on the tactical and strategic direction.

Responsibilities of this role include:

Strategic and creative direction of Design System.
Strategic and creative direction of Design Language.
Partnership with design, product, and engineering.
Collaboration with designers and engineers to create portable and reusable platform solutions that power our products.
Distilling research learnings and business problems into client journeys and experience narratives.
Optimizing and evolving design processes and systems that are accessible and valuable to non-designers as well.
Doing hands-on user research, design, documentation and frontend architecture work.
Incorporating UX/UI best practices across our products.
Mentoring and building others.
Helping to maintain a culture of empathy, safety and belonging where all voices are heard.
Making it possible for great designs to happen everywhere in the organization.

Where Do We Belong

2022-12-28T00:00:00Z

I’ve been years watching everyone around me change. Seasons coming and going. People growing roots. Building houses. Giving birth to their babies. Becoming stable parents. And I’ve tried hard to change as well. Become that, understand it. I’ve been through these things, but I feel like I’m still the same scrawny kid full of dreams and restlessness.

Eventually, I’ve started becoming part of everything I’ve seen around the world, if nothing else. And when I’ve travelled forward, a small part of me is always left out there somewhere. On the deserts, mountains, forests, oceans, and the cities around the world. It’s a little bittersweet. It’s the same with people. I ain’t got roots and I don’t know where I belong.

I have this dream where I’m sitting on top of Mt. Tamalpais East Peak gazing over San Francisco city lights across the bay. Warm autumn breeze blowing from the Pacific Ocean. Misty mountains around me, swaying fields in the moonlight, colors of the autumn, and music that fills our souls.

Finalist for the Jamstack Conf Jammies

2022-10-25T00:00:00Z

Nord Design System was recently nominated for the Jamstack Conf Jammies award in “Project of the Year” category. Winners will be announced live at Jamstack Conf on November 7 – 8.

Nord was nominated for outstanding achievement in delivering best-in-class experiences to customers through innovative use of technologies across the Jamstack and its ecosystem. You can read more about the award on the official website.

Interview with Ariel Salminen

2022-09-02T00:00:00Z

I was recently interviewed by Lovers Magazine about what led me into design and what type of things inspire me as a designer. I think it was refreshing to answer their questions and really dive into the deep end of what ultimately took me where I am today.

I sometimes tend to forget that I’ve been working in this profession for two decades and many of the people I meet inside and outside of work are just starting their careers. I’m not really saying that I’d be offering any kind of career advice in this particular interview, but it’s still a brief look into one person’s journey to become a systems oriented designer.

If you’re interested, you can read the full interview here. I also created a small Spotify playlist for the readers of the magazine. These are tracks that I often listen to while working. There’s an Apple Music playlist available as well.

Launching Nord Design System

2022-04-05T00:00:00Z

We’re excited to announce the first major release of Nord Design System, v1.0. With this release, our design systems team is shipping a number of new tools and features to improve the experience of designing, building, and shipping products at Nordhealth.

Looking back in time, we started our design systems journey at the end of 2020 with initial user research, but the concrete design and development work on the system didn’t start before the late summer 2021 when Eric Habich, Nick Williams, and David Darnes joined the team.

Now, 8 months later, I’m excited that we’re launching Nord Design System and all of our tools for production usage! To learn more about the new features included, keep reading below. 🎉

New Packages

Nord Design System is divided into 7 npm packages and a Figma Toolkit. All of the packages can be used together or separately depending on the product team’s needs and often developers might install several of them in order to use Nord Design System, including:

@nordhealth/components
@nordhealth/react
@nordhealth/tokens
@nordhealth/themes
@nordhealth/css
@nordhealth/icons
@nordhealth/fonts

Figma Toolkit

Nord’s Figma Toolkit is a resource for exploration and collaboration. It contains the building blocks for designing with Nord. Our goal was to create a toolkit that anyone at Nordhealth could use to prototype ideas. We’ve written more about the toolkit and our thinking behind it in one of our monthly updates.

Our plan is to open source parts of the library in the Figma Community soon so that anyone can learn how we use Figma and benefit from the work we’re doing. Take a sneak peek of our Figma Community page to follow us and stay up to date on what we’ll publish there.

Theming

Nord uses CSS Custom Properties (sometimes referred to as CSS variables) to make its parts themable. CSS Custom Properties allow us to have our values stored in one place, then referenced in multiple other places.

A single theme in Nord is basically a plain CSS file which contains a :root CSS pseudo-class which declares global colors, gradients, box-shadows, and color aliases for the theme. Themes are usually referenced after our CSS Framework in the <head> of an application:

:root {
  /* ACCENT COLOR */
  --n-color-accent: {color};

  /* TEXT COLORS */
  --n-color-text: {color};
  --n-color-text-link: {color};
  --n-color-text-weak: {color};
  --n-color-text-weaker: {color};
  --n-color-text-weakest: {color};
  --n-color-text-on-accent: {color};
  --n-color-text-error: {color};
  --n-color-text-success: {color};

  /* NAVIGATION COLORS */
  --n-color-nav-surface: {color};
  --n-color-nav-heading: {color};
  --n-color-nav-hover: {color};

  /* BORDER COLORS */
  --n-color-border: {color};
  --n-color-border-strong: {color};

  /* SKIN COLORS */
  --n-color-surface: {color};
  --n-color-background: {color};
  --n-color-surface-raised: {color};

  /* STATUS COLORS */
  --n-color-status-warning: {color};
  --n-color-status-highlight: {color};
  --n-color-status-danger: {color};
  --n-color-status-success: {color};
  --n-color-status-info: {color};

  /* ETC… */
}

Nord’s theming also comes with a concept called Accent color which allows developers to provide a slightly branded experience for the users without having to build a full theme from scratch:

:root {
  /* CUSTOM ACCENT COLORS */
  --n-color-accent: {accent-color};
  --n-color-text-on-accent: {text-on-accent-color};
}

Dark mode

Dark mode is a user interface mode that displays light text on a dark background. Dark mode is helpful for those viewing device screens at night, in dark environments, or find darker UI more accessible. The reduced brightness can reduce eye strain in low light conditions.

CSS Custom Properties used in Nord’s theming make supporting dark mode incredibly quick and performant. A typical scenario here could be that we already have a light theme in an application, and want to build support for a darker counterpart. Nord now supports this out of the box so that we can provide a better experience for our users.

Theme Builder

We’ve created a tool called theme builder that our teams can use to test out the existing themes and the provided theming options. This can be useful for demonstrating the theming capabilities to users.

Theme builder allows developers to try features such as Accent color before implementing them into production environment and demonstrates how to programmatically pick the right text color based on the contrast ratio using our provided getTextColor function:

/*!
  * Get Nord text color for chosen accent color.
  * Derived from work by Brian Suda and Chris Ferdinandi.
  * MIT License.
  *
  * @param  {String} A hex color value
  * @return {String} The contrasting color (#0c1a3d or #fff)
  */
function getTextColor(color) {
  // If a leading # is provided, remove it
  if (color.slice(0, 1) === "#") {
    color = color.slice(1)
  }

  // If 3 character hex, convert to 6 character
  if (color.length === 3) {
    color = color.split("").map((hex) => {
      return hex + hex
    }).join("")
  }

  // Convert to RGB value
  const r = parseInt(color.substr(0, 2), 16)
  const g = parseInt(color.substr(2, 2), 16)
  const b = parseInt(color.substr(4, 2), 16)

  // Get YIQ color space ratio
  const yiq = (r * 299 + g * 587 + b * 114) / 1000

  // Finally return contrasting text color
  return yiq >= 160 ? "#0c1a3d" : "#fff"
}

The above function can be utilized with for example a color input. When the input value changes, we can set the new accent colors into a :root CSS pseudo-class:

<label for="color">Accent color</label>
<input id="color" type="color" value="#3559c7" />

<script>
  const input = document.querySelector("#color")
  const root = document.documentElement

  input.addEventListener("input", () => {
    const color = input.value
    const textColor = getTextColor(color)

    root.style.setProperty("--n-color-accent", color)
    root.style.setProperty("--n-color-text-on-accent", textColor)
  })
</script>

Design Tokens

Design tokens are a central location to store design related information such as colors, fonts, sizes, and transitions. These raw values are automatically transformed to different formats like Sass, CSS, JSON, and more. Nord Design System uses design tokens instead of hard coded values to ensure a better UI consistency across different platforms (hat tip to Jina!).

Please note that in most cases developers don’t have to install our design tokens package directly, they can use our CSS framework instead as it imports this package internally and gives access to both the tokens and a wide range of shorthand utility classes to modify an element’s appearance in their application.

Web Components

Nord makes it effortless to implement and use its components across any framework or no framework at all. We accomplish this by using standardized web platform APIs and Web Components.

We’ve chosen to use Web Components because there is a strong requirement for Nord to be used in many different contexts and with varying technologies — from static HTML pages to server-rendered apps, through to single page applications authored with frameworks such as React and Vue.js. Web Components work great for Nord, because they:

Are tech-agnostic instead of tech-specific
Future proof our system with Web Standards
Allow us to use any framework or no framework at all
Provide great encapsulation for styles and functionality

React Components

Whilst React supports Web Components, they are sligthly awkward to use as-is. For this reason, we provide React-specific wrapper components in a package called @nordhealth/react. This will allow developers to use the Nord components as you would any other React component.

A planned future release of React will greatly improve support for Web Components, which will make the wrapper components unnecessary. But until then, we recommend their use.

import "@nordhealth/css"
import { Button } from "@nordhealth/react"
import ReactDOM from "react-dom"

function App() {
  return (
    <Button variant="primary">Hello world</Button>
  )
}

ReactDOM.render(
  <App />,
  document.querySelector("#app")
)

CSS Framework

Nord Design System’s CSS Framework includes a wide range of shorthand utility classes to modify an element’s appearance in your application. The primary goal of this framework is to provide a method of styling elements with as little friction as possible.

Our CSS Framework also makes it possible to use the design tokens through memorable CSS based utility classes. Developers can either use this framework standalone, or with another CSS framework, as our CSS selectors are prefixed with .n- to prevent collisions.

RTL Support and Logical Properties

Historically in CSS, we used to apply properties such as margin relative to the direction of their sides. For example, margin-left was applied to the physical left side of an element. With logical properties, margin-left becomes margin-inline-start. This means that regardless of the language and text direction, the element will always have appropriate margin rules even in right-to-left languages.

Supporting multilingual applications and websites was an important requirement for Nord Design System. This is why we’ve made sure to use Logical Properties across all of our tools and also built test automation that warns us if we accidentally use the old style properties such as margin, padding, or border.

Rachel Andrew explaining the logic:

“… these values have moved away from the underlying assumption that content on the web maps to the physical dimensions of the screen, with the first word of a sentence being top left of the box it is in. The order of lines in grid-area makes complete sense if you had never encountered the existing way that we set these values in a shorthand.”

Nordicons

Nordicons is our proprietary icon library. We use Nordicons to provide additional meaning or in places where text label doesn’t fit. They communicate messages at a glance and draw attention to important information.

The easiest and recommended way to use Nordicons is via our dedicated Icon component that allows developers at Nordhealth to use all our icons and set their size and color according to our design tokens. The icon component provides properties that allow developers to adjust the following:

Name of the icon from Nordicons
Size of the icon according to our icon sizing tokens
Color of the icon according to our color tokens
Accessible label for the icon

Webfonts

Nord Design System provides a constrained, purposeful set of typographic styles that we use to present user interface and content as clearly and efficiently as possible.

For digital products, we use a typeface called Inter which is carefully crafted and designed for computer screens specifically. It features a tall x-height to aid in readability of mixed-case and lower-case text. Several OpenType features are provided as well, like contextual alternates and slashed zero for when you need to disambiguate 0 from O.

Nord CDN

Nord serves all of its packages via a Content Delivery Network for better performance and stability. Nord CDN also makes it fast to implement and use our packages for design work and prototyping user interface features. Some of the benefits of using Nord’s CDN include:

Faster load times and better performance for all users
CDN scales more rapidly during heavy traffic
Minimizes risk of traffic spikes at point of origin, ensuring stability
Decreases infrastructure costs due to traffic offloading
Faster to get up and running with development work

Documentation

Finally, but not the least, we’ve put a lot of effort into documenting the usage of different tools and decisions we’ve made along the way. For this, we’ve used a tool called Eleventy which generates everything from our interactive component playgrounds to static documentation pages that you can see on nordhealth.design website.

The documentation itself is public as it makes sharing and collaboration between different teams and third party vendors much easier as it increases the system’s visibility and accountability. This also makes us push towards higher quality and enables us to be more transparent. Finally, it serves as an amazing tool that we can leverage in recruiting.

What’s Coming Next

The Nord team is excited to finally bring these updates to everyone working at Nordhealth! 🥳 All of our tools are out of beta phase starting today and ready for production usage. There’re obviously many items we wanted to see in version 1.0 that didn’t quite make it. We’re excited to bring those to our users later this year. Next, we’ll be focusing on the following features:

Improved internationalization support for Web Components
Product team support by setting up knowledge-sharing processes that promote collaboration, pairing, and training
Forming new Nordhealth wide contribution models
Improving our test and process automation
Defining backlog prioritization model
Adding more features, components, and fixing bugs
And more…

If you have questions or feedback for us, feel free to reach out to us via Slack, Office Hours, Monthly Meetups, and also the feedback functionality found from the bottom of each page. Hope to hear from you soon.

P.S. We’re hiring for Nord team!
P.P.S. We’ve got interesting statistics about Nord here!

Nord Statistics For The First Year

2022-03-31T00:00:00Z

You’re reading the ninth Nord Design System monthly update. During the past month we’ve been preparing the system for official launch and making sure we offer stable API and comprehensive docs.

Looking back in time, we started our design system journey at the end of 2020 with initial user research. We did this because we wanted to first better understand the challenges we’re trying to solve at Nordhealth and how the design system might help.

Back then, we interviewed around 60 different persons from different teams, with different backgrounds, and with different levels of experience. The result of this research was an organizational challenges heatmap that highlighted organization level problems.

Once we had this data, we continued the research with a series of workshops. These workshops were meant to reveal a lack of alignment and personal biases across teams. The final output from these workshops was a set of prioritized actions that directly informed the backlog of the design system.

Once we knew what the challenges were, it was a matter of creating fundamental principles and goals for the system that we should follow to start solving these issues. The concrete design and development work on the design system started in August 2021 when Eric and Nick joined the team.

Now, 8 months later, we’re excited to launch Nord Design System and all of our tools for production usage! 🎉

Tools you can use today

All of our tools are out of beta phase starting today and ready for production usage. Web Components have also reached release candidate (RC) status and we’ll publish 1.0.0 next week unless significant bugs emerge.

You can read more about each tool below:

We hope you enjoy using Nord’s tools and help us improve them by providing feedback to us via Slack, Office Hours, Monthly Meetups, and also the feedback functionality found from the bottom of each documentation page. Hope to hear from you soon!

Statistics for the first year

We wanted to collect a few statistics here, so that we can better track the progress on Nord. We think some of these metrics are impressive for such a small team as for a long time the team was only one person, until we hired two more during summer 2021, and eventually by the end of the year the fourth person, Dave.

Here you go, the numbers:

Team has grown from 1 to 4

Nord team has grown from one to four persons and we’re currently hiring two more designers and developers for the team.

View careers and apply

109,431 lines of code written

We had three people write a total of 109,431 lines of code that form the foundations of Nord Design System today.

2,786 commits

We had three people make almost 3000 commits over the past year which are now merged to Main branch on Nordhealth GitHub.

1296 button variations and states

There are 1296 button variations and states. This includes all 6 themes we have, but you shouldn’t ever underestimate a button and what a seemingly simple component can cost to an organization when it’s being reinvented by every single product team.

3218 Figma frames

We’ve worked through 49 Figma files which contain a total of 107 pages and 3218 frames that we’ve used for background research, design exploration, prototyping, and the components themselves.

31 code based components

During the past 8 months we’ve designed and built a total of 31 code based Web Components. 27 of them can be seen in the documentation already and 4 more are waiting behind existing pull requests on GitHub.

32.96 kB total bundle size

Lit has helped us to keep Nord’s bundle size small. All of our CSS and Web Components combined weigh around 33 kB (minified and compressed).

95.57 % code coverage

Our automated tests currently cover 95.57% of the code base. We use Web Test Runner, Mocha, and Puppeteer to automate E2E, unit, accessibility, and screenshot diff tests.

256 design tokens

There are 256 design tokens that we use to store design variables like colors, font sizes and spacing information. These are used instead of hard coded values to ensure a better UI consistency across different platforms.

200,000+ page views

We have had over 200K page views on nordhealth.design documentation website since May, 2021 when we started measuring visits.

3373 hours of work

Our team of four persons has used a total of 3373 hours to design, build and maintain the system we have today.

282 versions published

During the past year we’ve published 282 packages versions to npm that have recently started getting more downloads as teams start utilizing these tools.

402 pages of documentation

We’ve created over 400 pages of documentation and live code examples combined during the past year which are all live at nordhealth.design.

100% Lighthouse performance score

Lighthouse, a tool by Google that evaluates websites by their performance, accessibility, and other best practices, scores our application templates with 100% score.

309 completed Linear issues

We’ve worked through a backlog of 385 tasks and completed 309 of them in a tool called Linear that we use for issue tracking and task prioritization.

120 completed roadmap goals

We’ve completed 120 high level roadmap goals since we’ve started the work on Nord.

~~Bug reporting capabilities and enhanced support for design system.~~
~~Improved documentation regarding getting started with Nord.~~
~~Creating content guidelines for components.~~
~~Web Components reaches stable 1.0 state.~~
- ~~Badge component~~
- ~~Button component~~
- ~~Calendar component~~
- ~~Card component~~
- ~~Checkbox component~~
- ~~Etc…~~

Nord Design System Architecture

2022-02-21T00:00:00Z

You’re reading the eigth Nord Design System monthly update. This month I wanted to give a little more insight into how we’ve architectured Nord’s packages and how they’re interconnected.

One of the recent major changes in Nord is that we’ve re-designed the underlying package architecture. The reason why we decided to do such a big fundamental change this close to our official release, is that we felt like the original structure was too complex to use and that there were too many dependencies between the different packages overall.

In early January we decided to do something about this and simplify the architecture. Originally, if you wanted to utilize any of the components, you had to first install and link our Design Tokens, then install and link Webfonts, then our CSS Framework, Themes, and finally the Web Components themself. That’s quite a few steps, huh?!

In the re-designed architecture we have two different levels to the packages:

On the first level, we have packages called Webfonts, Design Tokens, and Nordicons (illustrated below). These packages are like atoms of the systems as they don’t have external or internal dependencies into any other packages in the system.
On the second level, we have CSS Framework, Web Components, and Themes (illustrated below). These packages internally depend on the first level packages, but we wanted to hide these dependencies for the end user, Frontend Developer in this case, meaning that you’d more or less always install one or more of the second level packages only into your app to consume parts of the system:

As an example, if you would like to use our CSS Framework, you would only install that specific NPM package and that’s really it. You don’t have to care, as a user, that internally this package also also uses our Webfonts and Design Token packages:

Another example could be that if you’d want to skin your application with one of our themes, you’d also add the Themes package and choose a theme to use from it. Again, internally, we still use both Webfonts and Design Token packages, but as a user, you don’t have to care about those:

Finally, in the below example, we show all three first level packages being used internally (Webfonts, Design Tokens and Nordicons), but for the end user, only CSS Framework and Web Components will be relevant in this case:

You could also directly utilize one of the first level packages, like the Design Tokens if you’re working on a native iOS application and want to pull in the base colors and similar styles in XML format:

While the above is still possible, we wanted to avoid the user having to install a lot of different dependencies to be able to use a utility class from the CSS Framework, or a component from the Web Components package.

All of this seems quite evident in hindsight, but our original thinking was to strive for modularity to reduce the complexity and improve our system’s reusability by breaking it into small, easier to consume parts.

This modularity eventually increased the complexity for the users because we didn’t consider the API carefully enough, especially when it comes to CSS Custom Properties and the complex theming system we’ve got.

In the new architecture we’ve still kept the same level of modularity inside the system, but simplified it for our users and now offer a better and simpler API. These changes also nicely align with one of our key design principles which states that “developers should be able to start using our tools in minutes, not hours, days or weeks.”

Nord Design System October 2021 Update

2021-10-14T00:00:00Z

You’re reading the fifth Nord Design System monthly update. This month we’ve gained great momentum and have published four new packages, and made many improvements to Nord documentation.

As Nord Design System is still quite young, we feel like it’s a good idea to once in a while repeat why we are building these tools and what’s really the scope of our work. To us, a “design system” is a collection of reusable components and tools, guided by clear standards, that can be assembled together to build digital products and experiences.

What this means, is that we aren’t really designing the workflows and features of each product. Instead, our goal is to provide the best possible tools, components, and guidelines for our designers and developers working in each product team to be able to build more consistent products at scale, faster, and with better outcomes.

The ultimate end goal for us is to provide tools that allow us, as a company, to better serve our end users and that is really at the center of everything we do. We want to transform our culture, processes, and practices to support this mission and the design system is an important tool to help us with this transformation.

The fundamental purpose of Nord is to elevate our design and frontend development practices in-house, bring those disciplines closer together, improve the consistency between products, and also improve the working efficiency for everyone in the long run.

We’re here to make your life easier, let us know how we can help your team.

New this month

As mentioned earlier, we’ve published quite a few new packages and features this month, so we’re listing all of them below and linking to their respective documentation pages for detailed information about usage and such.

Nord Design Tokens 1.0.0

Design tokens are a tech-agnostic way to store variables. We use tokens instead of hard coded values to ensure a better UI consistency across different platforms. Design tokens reached stable state this week and they’re now ready for production usage.

Nord Themes 2.0.0

Nord’s parts are themable using CSS Custom Properties. We ship pre-made themes for Nordhealth, Veterinary and Healthcare. You can utilize these themes through our Themes package which reached stable state this week and is now ready for production usage.

Nordicons 1.0.0

Nordicons are used to provide additional meaning or in places where text label doesn’t fit. They communicate messages at a glance and draw attention to important information. Nordicons package reached stable state this week and is now ready for production usage.

Nord Webfonts 2.0.0

Nord Design System provides an npm package that makes it straightforward to use our webfonts. This package ships with all the necessary font files in addition to Sass, Less, and CSS for self-hosting. Nord’s Webfonts package reached stable state this week and is now ready for production usage.

Nord CDN

We now serve all of Nord’s packages via a new Content Delivery Network for better performance and stability. Nord CDN also makes it faster to implement and use our packages in production.

Improved documentation

We’ve worked on improving our documentation platform and added a handful of new features to make the daily usage nicer for everyone. The biggest changes include:

We’ve moved from global theming into a local theming. You can see this in action above and on e.g. our Design Tokens documentation or on Stack component page. No more hiding of content per theme, so all content is easier to discover.
All code examples now include “copy to clipboard” functionality. You can see this in action above and on e.g. Themes documentation. Additionally, we’ve also added this functionality to the Design Tokens documentation.
The search in the docs has been improved and it should now work much more reliably to make it quicker to find and discover content. Please note that when you search you can use arrow up/down keys and enter to select a result you want to open.
We’ve added a new visual style to highlight specific content from the rest when needed. There’s an example shown above this list.
The documentation itself is now using Nord Web Components so in a way we’re dog fooding ourselves with our own product to find issues and make it more robust.
There’s a lot of new content, including usage guidelines for Design Tokens, Themes, Webfonts, Nordicons, Nord CDN and more…

Nord Design System September 2021 Update

2021-09-07T00:00:00Z

You’re reading the fourth Nord Design System monthly update. This month we’ve been working on making sure that everyone at Nordhealth understands how and why we’re building a design system.

We started the design systems work at Nordhealth in late 2020. The way I usually recommend starting this work is via user research, which helps us to figure out what are the challenges on organization, team, and people level that we should be solving. We do this because all companies are different and there isn’t one solution that fits everyone when it comes to design systems.

Back then we interviewed ~60 different persons from different teams, with different backgrounds, and with different levels of experience. The result of this research was an organizational challenges heatmap that highlighted organization level problems.

Now that we had a clear list of challenges that we wanted to start solving, it was a matter of creating fundamental principles and goals for the system that we should follow to start solving these issues. We came up with these four goals for Nord:

At the same time, we also created design principles for the design systems work that would form the foundations for Nord and guide our team when working on the different parts of the system and help us do better and more informed decisions. These are the six design principles we created for Nord:

1. Put user needs first

We care for the people who use our products. We’re here to make their day-to-day and long-term work better and more pleasant through great user experience.

2. Strive for consistency, not uniformity

We should use the same language and design patterns wherever possible. This helps people get familiar with our services. Same holds true for the system and its developer experience.

3. Default to openness

We should share what we’re doing whenever we can. Building our services transparently increases their visibility and accountability and makes us push towards higher quality.

4. Make it accessible

Our services are for everyone. We make sure people with different needs can use our products and that they meet the accessibility standards outlined in WCAG 2.1.

5. Provide a good developer experience

Providing a good developer experience is very important to us. Developers should be able to start using our tools in minutes, not hours, days or weeks.

6. Automate everything you can

We value the time of our colleagues, users, and our future selves over our own. We are always proactively looking for ways to automate repetitive tasks and testing.

Whenever I talk about Nord Design System, one of the first things that I like to mention is that we’re building a system that is tech agnostic, not tech specific. Meaning that you can take any component from Nord and use it with any framework. That could be Angular, React, Preact, Vue.js, plain HTML, your old PHP application, or any future framework.

We achieve this by building on top of existing web standards (Web Components to be exact), instead of choosing a specific framework to go with. This is really important for us for a few reasons;

Tech-Agnostic Instead Of Tech-Specific

In order to create modular interfaces, a design system needs to be technology-agnostic instead of technology-specific. Web Components offer this benefit and make it easier to reduce our design system’s complexity and improve its reusability.

Future Proofing With Web Standards

Web Standards are more future proof than any given JavaScript framework. I’ve seen different frameworks come and go during my almost two decade long career on the web, but Web Standards keep thriving and evolving.

Any Framework Or No Framework

Web Components can be used with any JavaScript framework or no framework at all. This means we’re able to support all our product teams from a single codebase. This makes it possible for our small design system team to be very efficient.

Full Encapsulation

Shadow DOM allows components to have their own DOM tree that can’t be accidentally accessed from the main document. For us this means that “everything just works” when the components are implemented onto different environments and platforms. Most styles cannot penetrate a component from the outside, and styles inside a component won’t bleed out.

Nord’s tech-agnostic thinking isn’t limited to only components either, all our styles are agnostic as well. We use design tokens instead of hard coded values to ensure a better UI consistency across different platforms. Be that a web application, a native application, a mobile application, a VR solution, or something new that doesn’t even exist today.

Looking at the way Nord itself is structured, looks somewhat like shown in the picture above. The most important thing about the architecture is that we aren’t really talking about one gigantic design system, but multiple small modular systems that can be used either standalone or together depending on specific team’s needs.

So on a high-level we have design tokens which are the base building blocks of our design language. There we define things like colors, fonts, spacing, shadows, and other properties that create the visual look. Then on the second level we have packages such as Nord’s CSS Framework, Theme system, Web Components, and Figma components.

What ties it all together is our documentation and guidelines at nordhealth.design which is getting more and more automated as we move along.

The last thing I perhaps want to share in this update, is an early prototype of Nord’s UI components (there’s also an even older version which I did when I was the only person in the team: view that here).

We’ve been moving back and forth between Figma and HTML prototypes to be able adjust the micro interactions and how the UI feels in real use in real environment, which is the web browser. Things will definitely still change quite a lot as we’re rapidly iterating on the design and theming, but take a peek of what’s under work.

Nord Design System June 2021 Update

2021-06-30T00:00:00Z

You’re reading the third Nord Design System monthly update. This month we’ve been focusing on onboarding new team members and also rolling out the new brand guidelines into the documentation.

In the beginning of the month, Eric Habich, our new product designer, joined Nord Design System team. I’ve personally worked with Eric in the past with various clients when I was still living in the San Francisco Bay Area and knew beforehand how talented addition he’d be for our small team. As the first task to get more familiar with Nord, Eric illustrated our home page and the different tools we offer with these nifty drawings:

The interesting bit with these illustrations is that they’re all themed with CSS Custom Properties and use Nord’s theming feature. This means that each illustration variant in the documentation is actually the same SVG which gets its colors from the design tokens.

In late May, we also published Nordhealth brand guidelines. This is a result of the brand work we’ve been working on since February and which I shared a little about in the last monthly update:

Together with the above update, we’ve been also improving our downloads section throughout the month to make sure all the brand assets would be available there for downloading and usage:

Later during June, we started moving our focus more into product design and started doing both background research and competitive research to help us start designing the system’s parts. We currently have various related Figma documents under the Nord project, like for example the below Interface Audit:

…or this document where we’ve started collecting user flows, screens, and information architectures…

…or this document with typeface tests and visual directions to work with…

…and eventually also documents where we’ve started to draft out the actual interface concepts:

Finally, while we’ve moved things forward in Figma, we’ve also started researching on how to sync Figma, our different color themes, and the code based design tokens and built this prototype Figma plugin that fetches the tokens from Nord Design Tokens Node.js package and generates color libraries for Figma usage and syncing:

June has been busy, and there’re quite a few things under work behind the scenes which aren’t yet visible in the live system, but which will later start surfacing here in the form of components and larger user interface patterns. Right now though, as it is the end of the month, our whole team would like to wish you all wonderful summer holidays! We’ll catch up again with you in August.

Nord Design System May 2021 Update

2021-05-16T00:00:00Z

You’re reading the second Nord Design System monthly update. Since February, we’ve been busy rethinking our design processes and brand identity that was launched a few weeks ago.

During the past months our team has been busy rethinking our brand identity from the ground up. We wanted to go through this effort to mirror the growth and transformation of our company into the leading cloud-based provider of healthcare and veterinary software. As a result, “Three Plus Group” and “Finnish Net Solutions” now have a new name and corporate identity and are now all called Nordhealth.

Our new logo represents “togetherness.” Two sides working as one. So, on a business level, it represents a key driver for us, acquisition. For our customers and end users, it expresses the seamless use of our products to improve productivity and communication. We bring healthcare professionals closer to their patients. Our new logo also defines how our teams work as a strong unshakable unit. On a deeper level, the logo also illustrates a bigger idea, change and innovation in the global healthcare market.

This rebranding is a start of a bigger design transformation at Nordhealth. Our plan isn’t to merely rethink the corporate brand. The goal is to continue this work and rethink our design processes and digital products from the ground up and improve their user experience and user interfaces vastly.

This is where Nord Design System steps in. Nord is our platform for driving the design transformation.

Nordhealth Rebranding

2021-04-15T00:00:00Z

I’m happy to announce Three Plus Group’s and Finnish Net Solutions’ new name and corporate identity, Nordhealth. The name change is a result of a rebranding that I did for the company earlier this year.

It’s designed to mirror the growth and transformation of the company into the leading cloud-based provider of software for therapy clinics in the Nordics and veterinary clinics globally.

Charles MacBain, Chief Executive Officer at Nordhealth, commented the rebranding:

“As we near our 20th anniversary, we decided to rebrand our company to reflect our updated vision, mission and values. Although we have a global footprint, we wanted to pay tribute to our Nordic values which include innovation, creativity, design, sustainability, and equality, which our company strives to embody across the world.”

I personally commented the redesign in a recent press release:

“Our new brand represents ‘togetherness.’ Two sides working as one. So, on a business level it represents a key driver for us, acquisition. For our customers and end users, it expresses the seamless use of our products to improve productivity and communication.“

“We bring healthcare professionals closer to their patients. Our brand also defines how our teams work as a strong unshakable unit. On a deeper level, the brand also illustrates a bigger idea, change and innovation in the global healthcare market.”

The company rebranding is a start of a bigger design transformation at Nordhealth. Our plan isn’t just to rethink the global brand. The goal is to continue this work and also rethink the design processes and digital products from the ground up and improve their user experience vastly.

The rebranding I did included a full redesign of the company’s logo, website, graphics, communications and correspondence. Nordhealth’s new brand assets also included a simplified two color logo, along with a new website that I designed and developed, among with other visual communications tools that utilize simple, bold graphics to convey complex solutions in an understandable way.

Nord Design System February 2021 Update

2021-02-17T00:00:00Z

You’re reading the first ever Nord Design System monthly update. We’re just starting our design systems journey at Nordhealth and have created this documentation platform to support these efforts.

The aim of this platform is to serve as a hub for Nordhealth’s user interface design and frontend development work in the future. We’re pushing towards automating most parts of the documentation creation, but you should also expect to see manually crafted design guidelines, development tutorials, and similar here in the future.

To stay up to date with the latest releases and updates from our design systems team, you can follow the what’s new section that includes our current roadmap and any future updates we might release.

Currently, our main focus has been on brand refresh, exploring the overall visual direction, how the theming system works, and also creating the underlying technical architecture to support the work that follows.

Our draft style guide looks like this:

We’ve also started exploring components a little and how they could behave and look like. Here’s a concept on navigation that we’ve also tested on the documentation itself:

Last week, we also published the very first production ready design systems package, Nord Webfonts, which includes our UI typefaces and related tools to utilize them:

Nord Webfonts 1.0.1

Initial release of @nordhealth/fonts which includes Nordhealth Sans and Nordhealth Mono. For documentation and usage guidelines, please see Webfonts.
Makes @nordhealth/fonts package completely independent from @nordhealth/tokens.
Can now be used standalone without any other package from Nord.
Release date 11.2.2021.

We’ve also started drafting Nord Design Tokens which you can browse here. Make sure to try out the theme switcher on the top left corner of the browser window:

Finally, you can also view slidedeck for this month’s update below:

Design Principles of Nord Design System

2021-01-15T00:00:00Z

Nordhealth hired me in 2020 to help reimagine what the company’s approach to designing, building and shipping digital products at scale should look like. I started this work by conducting a series of user research activities and workshops to reveal a lack of alignment and personal biases across business units, products and teams to understand how the design system could help them.

When we had a clear view of the challenges that we wanted to solve, it was a matter of creating fundamental principles and goals for the system that we could follow as a team. We came up with four primary goals for Nord. At the same time, I also created design principles for the design systems work that would form the foundations for Nord and help us do better and more informed decisions. I’ve listed them below.

1. Put user needs first

We care for the people who use our products. We’re here to make their day-to-day and long-term work better and more pleasant through great user experience.

2. Strive for consistency, not uniformity

We should use the same language and design patterns wherever possible. This helps people get familiar with our services. Same holds true for the system and its developer experience.

3. Default to openness

We should share what we’re doing whenever we can. Building our services transparently increases their visibility and accountability and makes us push towards higher quality.

4. Make it accessible

Our services are for everyone. We make sure people with different needs can use our products and that they meet the accessibility standards outlined in WCAG 2.1.

5. Provide a good developer experience

Providing a good developer experience is very important to us. Developers should be able to start using our tools in minutes, not hours, days or weeks.

6. Automate everything you can

We value the time of our colleagues, users, and our future selves over our own. We are always proactively looking for ways to automate repetitive tasks and testing.

A Missed Opportunity

2020-12-09T00:00:00Z

Why does it feel like the devices we use are getting slower over time? A smartphone I bought a few years ago seems to be losing its edge when browsing websites. My computer struggles to play audio. Even my car’s interface can’t keep up anymore after all the updates. Am I just imagining or were they always like this?

No, these devices aren’t actually getting slower, it’s the software that is getting more bloated. Whenever new hardware is released out in the wild, it takes only a few months until it becomes the benchmark for software developers. Because hell, why not. We have all these resources to utilize, why wouldn’t we. Why give a fuck about the needs of users.

If you’ve observed this too, it’s not just your imagination. Software is becoming increasingly complex and requires more resources than ever before. As CPU power increases, software is expanded to consume that extra performance. We live in the era of disposability.

Fabien Sanglard recently wrote a fantastic article on this subject which triggered me to share his thoughts here. Fabien writes:

“For a few months, those who will buy M1 machines will enjoy great responsiveness and blazing start-up time. Some once bloated applications will again behave like most tools should. But soon these metrics will start to degrade. Responsiveness and start-up time will progressively revert to what they used to be and old ‘non-M1’ machines will become even slower than they used to.”

Fabien then continues:

“Doing the same thing should never become slower. Starting up an application should never take longer than it used to. If a feature is going to cost start-up time, I would rather not have it. Is it that we don't care about start-up time? Or is it that we don't have the choice?”

And I think there’s wisdom in Fabien’s words. As an industry, we aren’t paying attention. We don’t care, or we don’t have the choice. Either way, we forget the user, the performance, and that there’s more hardware than ours, and that not everyone on this planet has the latest and greatest devices or the connection speeds that we, ourself, might have. I wrote about this in 2015, but the situation is now even worse.

Fabien also shares ideas from Brett Wilson, a Software Engineer in the Chrome team. The principle their team follows is:

“We carefully monitor startup performance using an automated test that runs for almost every change to the code. This test was created very early in the project, when Google Chrome did almost nothing, and we have always followed a very simple rule: this test can never get any slower. Because it’s much easier to address performance problems as they are created than fixing them later, we are quick to fix or revert any regressions. As a result, our very large application starts as fast today as the very lightweight application we started out with.”

And I think more teams should do this. Don’t just trust your gut feeling. Maybe there isn’t much a single person can do on a large scale, but by putting my thoughts onto this post I am at least sharing this forward and making sure we’re implementing this practise with all my clients.

CodePen as a Component Editor

2020-12-01T00:00:00Z

When we started working on Duet Design System early last year, one of our goals was to create similar component playgrounds as I had previously built for Vue Design System. While this seemed like an obvious decision at first, we soon realized that maintaining a code editor of our own required far too much effort, especially since Duet’s documentation is a custom built platform created for a specific organization’s needs.

We figured there must be a simpler approach. Maybe all of it didn’t have to be a part of the documentation itself. The most important goal was to have a code playground which would enable quick prototyping and testing.

This got us thinking. We were already using CodePen when we needed to quickly prototype or design something in the browser. Could we utilize the same tool for the public website as well to make the component documentation more interactive?

Introducing CodePen API

Turns out CodePen has a nice API for this which allows you to start a new Pen with code and settings that you send across programmatically. To pre-fill a Pen with your own code and options, you post a form with data in JSON format to https://codepen.io/pen/define.

A simple example looks like this, try it out by clicking the “Edit on CodePen” button:

<form action="https://codepen.io/pen/define" method="POST" target="_blank">
  <input type="hidden" name="data" value='{"title": "Button", "html": "<button>Click me</button>"}' />
  <input type="submit" value="Edit on CodePen" />
</form>

If you observe the example above, you might notice that I have added a hidden input inside the form. This input has the data I want to be editable set as its value:

<input
  type="hidden"
  name="data"
  value='{
    "title": "Button",
    "html": "<button>Click me</button>"
  }'
/>

Now, in reality, we usually want a little more than this. CodePen’s API provides a set of options you can include in the JSON. In Duet Design System, we are utilizing the following options:

<input
  type="hidden"
  name="data"
  value='{
    "title": "Generated title",
    "html": "<button>Code that you want to be editable</button>",
    "css_external": "url-to-stylesheet.css;url-to-stylesheet.css",
    "js_external": "url-to-web-components.js"
    "layout": "left",
    "editors": "100"
  }'
/>

With css_external option we are first of all linking to the necessary stylesheets on Duet’s content delivery network. js_external option does the same, but for JavaScript. layout and editors define what the CodePen editor itself will look like. With the above settings the code editor will live on the left side and only HTML editor will be open by default.

In case you’re using a static website generator like i.e. Eleventy or Next.js to document your design system, you could programmatically generate all of the contents for this form.

In Duet the automation works roughly so that we first generate Markdown files based on JS Doc style comments in the components. These Markdown files are then transformed using Eleventy and its templating features into user editable static webpages, by looping through all the components and adding the necessary bits programmatically:

{%- for example in examples -%}
  <form action="https://codepen.io/pen/define" method="POST" target="_blank">
    <input
      type="hidden"
      name="data"
      value='{
        "title": "Duet — {{ example.name | capitalize }}",
        "html": "{{ example.code | safe }}",
        "css_external": "{% duet_css_assets %}",
        "js_external": "{% duet_component_assets %}",
        "layout": "left",
        "editors": "100"
      }'
    />
    <input type="submit" value="Edit in CodePen" />
  </form>
{%- endfor -%}

Escaping quotes and new lines

If you try to utilize the above example on your own website, you might quickly notice that it produces invalid JSON when you have e.g. ", ', or new lines in the HTML inside the JSON object. To escape all quotes in JSON, you could use something like:

const processedHtml = JSON.stringify(originalHtml)
    .replace(/"/g, "&quot;")
    .replace(/'/g, "&apos;");

In case you’re using Eleventy with Nunjucks (like we are), you could instead use something like this which replaces all quotes and makes sure new lines won’t break JSON:

value='{
  "html": "{{ your_html | safe | replace('"', '\\"') | replace('\'', '&#39;') | replace('\n', '\\n') }}"
}'

CodePen’s own documentation also includes clear guidelines on how to achieve this with the help of jQuery on the client side.

Conclusion

Our industry has a tendency to over-engineer things (yes, I am guilty too), so I’m happy that we found a solution that has vastly simplified things. What’s lovely as well, is that this feature has got some of our designers to start utilizing CodePen as their tool of choice for prototyping.

Today, Duet Design System has this functionality implemented for all of its component and template examples. Take a look of the Button component for example and hit the “Edit on CodePen” button.

TL;DR. If you have a small team and you’re looking for a simple way to have editable component examples in your design system documentation, CodePen’s API might be an option worth considering.

Duet Design System September 2020 Update

2020-09-22T00:00:00Z

You’re reading the ninth Duet monthly update. During the past month we’ve been busy improving the existing features, fixing bugs, and open sourcing Duet Date Picker.

As our team working on Duet Design System couldn’t find an existing date picker that would’ve ticked all the requirements we had for accessibility and performance, we decided to build one and open source it so that others could benefit from this work as well.

Duet Date Picker is an open source version of Duet Design System’s WCAG 2.1 compliant date picker. Duet Date Picker can be implemented and used across any JavaScript framework or no framework at all. We accomplish this by using standardized web platform APIs and Web Components.

Features

Can be used with any JavaScript framework.
No external dependencies.
Themable with CSS variables.
Weighs only 10kb minified and Gzip’ed (this includes all styles and icons).
Built with accessibility in mind to support WCAG 2.1.
Supports all modern browsers and screen readers.
Support for localization.
Customizable date parsing and formatting.
Comes with modified interface for mobile devices to provide better user experience.
Supports touch gestures for changing months and closing the picker.
Free to use under the MIT license.

Discussion on Twitter

Today we open sourced Duet date picker:

✨ Built for the modern web
⌨️ Keyboard and screen reader accessible
🗺️ Supports localisation
🎨 Themable with CSS variables
📱 Mobile friendly
⚡ Only 10kb gzipped (including all styles and icons!)https://t.co/B38UMdCFVT pic.twitter.com/43UTfpT02H
— Nick Williams (@WickyNilliams) September 17, 2020

Duet Date Picker, an accessible, WCAG 2.1 compliant date picker that can be implemented and used across any JavaScript framework or no framework at all. via @arielsalminen https://t.co/Frl8VdjzQh pic.twitter.com/3ZcHFLRb4Z
— Smashing Magazine (@smashingmag) September 18, 2020

Our team working on Duet Design System couldn’t find an existing date picker that would’ve ticked all the requirements we had for bundle size and accessibility (WCAG 2.1), so we decided to build one and open source it: https://t.co/As1KL1NWFM pic.twitter.com/HXuBPQNBaQ
— (@arielsalminen) September 17, 2020

New this month

In this section we’ll highlight every month new features and progress from Duet Design System. This month’s highlights include:

Duet Date Picker

As our team couldn’t find an existing date picker that would’ve ticked all the requirements we had for accessibility, we decided to build one and open source it so that others could benefit from this work as well.

Usage documentation

We’ve added new usage docs for each component that explain how and when the component should be used. There’re also better accessibility docs and further considerations to take into account on each component page.

iOS and Android support

We’ve added a new template demonstrating how to build a native view for iOS that utilizes Components, Design Tokens and CSS Framework. Similar techniques inside a native wrapper app could be used for Android as well.

Angular and React examples

In addition to improved Angular and React support, we’ve also created example projects that you can utilize. Both our GitHub account and CLI Tool now come with Angular and React specific templates that you can utilize.

Duet Markdown renderer

Duet now offers a custom renderer for the most popular JavaScript Markdown library marked.js, so that it outputs Duet components like <duet-paragraph> rather than standard HTML tags like <p>.

Until October!

Building Layouts with Duet Design System

2020-06-18T00:00:00Z

Following this tutorial you will learn how to build simple page layouts using Duet’s Design Tokens, CSS Framework, Web Components and other features.

For the sake of simplicity, this tutorial is framework agnostic and imports the different parts of Duet directly from JSDelivr. For production usage we recommend that you install the packages using NPM and host the different parts yourself.

Getting started

As the first step, you will want to create a basic HTML page that can be used for building the layout. There are no explicit requirements on what the HTML markup should look like, so let’s just go ahead and create a simple page with the correct lang attribute and a placeholder <title>:

<!doctype html>
<html lang="fi">
  <head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width,initial-scale=1.0" />
    <title>Ota yhteyttä | LähiTapiola</title>
  </head>
  <body></body>
</html>

Next, you need to import the necessary packages from Duet Design System in order to utilize them. For this particular layout, we want to use Fonts, CSS Framework and Web Components. To import these packages, add the following tags onto your page’s <head> section:

<!-- Fonts -->
<link rel="stylesheet" href="https://cdn.duetds.com/api/fonts/3.0.51/lib/localtapiola.css" integrity="sha384-5JYmtSD7nykpUvSmTW1CHMoBDkBZUpUmG0vuh+NUVtZag3F75Kr7+/JU3J7JV6Wq" crossorigin="anonymous" />

<!-- CSS Framework -->
<link rel="stylesheet" href="https://cdn.duetds.com/api/css/4.0.54/lib/duet.min.css" integrity="sha384-UoMJnpXiN8f7fKVnTzfKfyi7LzQlApQ+WTS9O3PXlYr6CO9yzou4glfsHV747f3v" crossorigin="anonymous" />

<!-- Components -->
<script type="module" src="https://cdn.duetds.com/api/components/9.1.0/lib/duet/duet.esm.js" integrity="sha384-bF+OBRaBhnoFC6ZeoybdILqDBpmydfNBcN5yNX8fh04nmMVxk4W8M0eYjA/PvFWq" crossorigin="anonymous"></script>
<script nomodule src="https://cdn.duetds.com/api/components/9.1.0/lib/duet/duet.js" integrity="sha384-n4xTNHGQg3FSzz+2wZW8XgoYYKDMF0D2oxxD7i4rfuxMF1qPvaBbl1fyyYtEKygw" crossorigin="anonymous"></script>

Once you’ve added each package shown above, the markup for the HTML page should look about like this:

<!doctype html>
<html lang="fi">
  <head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width,initial-scale=1.0" />
    <title>Ota yhteyttä | LähiTapiola</title>
    <link rel="stylesheet" href="https://cdn.duetds.com/api/fonts/3.0.51/lib/localtapiola.css" integrity="sha384-5JYmtSD7nykpUvSmTW1CHMoBDkBZUpUmG0vuh+NUVtZag3F75Kr7+/JU3J7JV6Wq" crossorigin="anonymous" />
    <link rel="stylesheet" href="https://cdn.duetds.com/api/css/4.0.54/lib/duet.min.css" integrity="sha384-UoMJnpXiN8f7fKVnTzfKfyi7LzQlApQ+WTS9O3PXlYr6CO9yzou4glfsHV747f3v" crossorigin="anonymous" />
    <script type="module" src="https://cdn.duetds.com/api/components/9.1.0/lib/duet/duet.esm.js" integrity="sha384-bF+OBRaBhnoFC6ZeoybdILqDBpmydfNBcN5yNX8fh04nmMVxk4W8M0eYjA/PvFWq" crossorigin="anonymous"></script>
    <script nomodule src="https://cdn.duetds.com/api/components/9.1.0/lib/duet/duet.js" integrity="sha384-n4xTNHGQg3FSzz+2wZW8XgoYYKDMF0D2oxxD7i4rfuxMF1qPvaBbl1fyyYtEKygw" crossorigin="anonymous"></script>
  </head>
  <body></body>
</html>

That’s all that’s required to start building completele layouts with Duet. In the next chapter we’ll cover the basics of Duet’s layout components and how to create the foundations for the rest of the content.

Laying foundations

Duet Design System contains certain components that should be used on most page layouts. One of those components is called Layout. Layout component, while not visible in the user interface itself, provides a structure for other components using a one or two column layout system.

To get started using Layout, add it inside your page’s <body>:

<body>
  <duet-layout></duet-layout>
</body>

<duet-layout> has three content areas which are called top, main and sidebar. To place content inside the main content area you need to first create a new element and tell it which area you want to render it in:

<body>
  <duet-layout>
    <div slot="main">Some content…</div>
  </duet-layout>
</body>

The above example renders “Some content…” text inside the Layout component’s main content area. In Web Component terms content areas are called “slots” which is where the attribute name also comes from.

Most of the time we also want our page to contain a header and a footer. You can add them, together with a few additional menu links like so:

<!doctype html>
<html lang="fi" class="duet-sticky-footer">
  <head>...</head>
  <body>
    <duet-header></duet-header>
    <duet-layout>
      <div slot="main">Some content…</div>
    </duet-layout>
    <duet-footer
      menu='[
      { "label": "Turvallisuus ja käyttöehdot", "href": "#" },
      { "label": "Evästeet", "href": "#" },
      { "label": "Henkilötietojen käsittely", "href": "#" }
    ]'>
    </duet-footer>
  </body>
</html>

Notice how we’ve also added .duet-sticky-footer class to <html> element. This makes sure our Footer always stays sticky at the bottom of the page, no matter how little content there might be before it.

At this point our page looks like this:

To make it a little nicer, let’s split the main content into two columns, add a background gradient from Duet’s CSS Framework, and use Card component to wrap our content:

<!doctype html>
<html lang="fi" class="duet-sticky-footer duet-bg-gradient">
  <head>...</head>
  <body>
    <duet-header></duet-header>
    <duet-layout>
      <div slot="main">
        <duet-card heading="Main" padding="large">
          <duet-paragraph>Main content</duet-paragraph>
        </duet-card>
      </div>
      <div slot="sidebar">
        <duet-card heading="Sidebar">Sidebar content</duet-card>
      </div>
    </duet-layout>
    <duet-footer
      menu='[
      { "label": "Turvallisuus ja käyttöehdot", "href": "#" },
      { "label": "Evästeet", "href": "#" },
      { "label": "Henkilötietojen käsittely", "href": "#" }
    ]'>
    </duet-footer>
  </body>
</html>

With the above markup we’ve now created a basic page layout to build upon:

Working with components

The underlying idea with Duet’s Components is that a developer can simply lay them on a page and the components themselves will take care of the surrounding space. This means that most of the time there shoudn’t be a need to use custom, application specific margins or paddings, for anything that’s coming from Duet.

In cases when you do need to adjust the spacing or margins, you can use Duet’s Spacer component and the provided Space Design Tokens.

As the next step, let’s create a simple contact form on the page we just did. This will help you understand how Duet’s components automatically handle the spacing in-between components and how the Spacer component can be used.

Modify your previous markup to include a form in the Layout component’s main content area:

<duet-layout>
  <div slot="main">
    <duet-card padding="large">
      <form novalidate>
      </form>
    </duet-card>
  </div>
</duet-layout>

Next, let’s add in some form elements, including two inputs, a textarea and a submit button:

<duet-layout>
  <div slot="main">
    <duet-card padding="large">
      <form novalidate>
        <duet-input label="Nimi" placeholder="Matti Meikäläinen" expand></duet-input>
        <duet-input label="Sähköposti" type="email" placeholder="nimi@email.com" expand></duet-input>
        <duet-textarea label="Viesti asiakaspalveluun" placeholder="Kirjoita tähän" expand></duet-textarea>
        <duet-button submit variation="primary">Lähetä</duet-button>
      </form>
    </duet-card>
  </div>
</duet-layout>

Finally, we’ll also add a little bit of text content and adjust the spacing slightly by adding two <duet-spacer/> components after the first paragraph and just before the submit button:

<duet-layout>
  <div slot="main">
    <duet-card padding="large">
      <form novalidate>
        <duet-heading level="h2">Ota yhteyttä</duet-heading>
        <duet-paragraph>
          Lähetä meille viesti kun haluat antaa palautetta tai pyytää
          yhteydenottoa. Jos olet jo asiakkaamme, asiasi hoituu parhaiten,
          kun kirjaudut verkkopalveluun.
        </duet-paragraph>
        <duet-spacer></duet-spacer>
        <duet-input label="Nimi" placeholder="Matti Meikäläinen" expand></duet-input>
        <duet-input label="Sähköposti" type="email" placeholder="nimi@email.com" expand></duet-input>
        <duet-textarea label="Viesti asiakaspalveluun" placeholder="Kirjoita tähän" expand></duet-textarea>
        <duet-spacer size="x-large"></duet-spacer>
        <duet-button submit variation="primary">Lähetä</duet-button>
      </form>
    </duet-card>
  </div>
  <div slot="sidebar">
    <duet-card padding="large" heading="Sivupalsta">
      Sivupalstaa voidaan käyttää pääsisältöön liittyvän tiedon näyttämiseen
      tai vaihtoehtoisesti nostamaan esiin aiheeseen liittyvää muuta sisältöä.
    </duet-card>
  </div>
</duet-layout>

The above markup produces now the following results:

As you can see the above webpage looks already pretty balanced without the need to add any custom CSS styles or elements onto the page.

Next, we could add a little more content to our Footer component. To achieve this, we can pass an array of items through a property called items:

<duet-footer
  items='[
    { "label": "Hae korvausta", "href": "#", "icon": "navigation-make-claim" },
    { "label": "Osta vakuutus", "href": "#", "icon": "action-buy-insurance" },
    { "label": "Yhteystiedot", "href": "#", "icon": "form-tel" }
  ]'
  menu='[
    { "label": "Turvallisuus ja käyttöehdot", "href": "#" },
    { "label": "Evästeet", "href": "#" },
    { "label": "Henkilötietojen käsittely", "href": "#" }
  ]'>
</duet-footer>

The above markup produces an additional menu for the footer:

To make our page layout ready, let’s add the rest of the header functionality:

<duet-header
  current-href="/yhteystiedot/"
  session='{ "label": "Kirjaudu sisään", "href": "/?login", "type": "login" }'
  items='[
    { "label": "Etusivu","href": "/" },
    { "label": "Vakuutukset", "href": "#" },
    { "label": "Vahinkoasiat", "href": "#" },
    { "label": "Säästöt ja sijoitukset", "href": "#" },
    { "label": "Laskut", "href": "#", "badge": "true" },
    { "label": "Viestit", "href": "#" }
  ]'>
</duet-header>
<duet-layout>
  ..
</duet-layout>

With these final changes, we’ve finished our first page layout.

Ready page layout:

Ready page markup:

<!doctype html>
<html lang="fi" class="duet-sticky-footer duet-bg-gradient">
  <head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width,initial-scale=1.0" />
    <title>Ota yhteyttä | LähiTapiola</title>
    <link rel="stylesheet" href="https://cdn.duetds.com/api/fonts/3.0.51/lib/localtapiola.css" integrity="sha384-5JYmtSD7nykpUvSmTW1CHMoBDkBZUpUmG0vuh+NUVtZag3F75Kr7+/JU3J7JV6Wq" crossorigin="anonymous" />
    <link rel="stylesheet" href="https://cdn.duetds.com/api/css/4.0.54/lib/duet.min.css" integrity="sha384-UoMJnpXiN8f7fKVnTzfKfyi7LzQlApQ+WTS9O3PXlYr6CO9yzou4glfsHV747f3v" crossorigin="anonymous" />
    <script type="module" src="https://cdn.duetds.com/api/components/9.1.0/lib/duet/duet.esm.js" integrity="sha384-bF+OBRaBhnoFC6ZeoybdILqDBpmydfNBcN5yNX8fh04nmMVxk4W8M0eYjA/PvFWq" crossorigin="anonymous"></script>
    <script nomodule src="https://cdn.duetds.com/api/components/9.1.0/lib/duet/duet.js" integrity="sha384-n4xTNHGQg3FSzz+2wZW8XgoYYKDMF0D2oxxD7i4rfuxMF1qPvaBbl1fyyYtEKygw" crossorigin="anonymous"></script>
  </head>
  <body>
    <duet-header
      current-href="/yhteystiedot/"
      session='{ "label": "Kirjaudu sisään", "href": "/?login", "type": "login" }'
      items='[
        { "label": "Etusivu","href": "/" },
        { "label": "Vakuutukset", "href": "#" },
        { "label": "Vahinkoasiat", "href": "#" },
        { "label": "Säästöt ja sijoitukset", "href": "#" },
        { "label": "Laskut", "href": "#", "badge": "true" },
        { "label": "Viestit", "href": "#" }
      ]'>
    </duet-header>
    <duet-layout>
      <div slot="main">
        <duet-card padding="large">
          <form novalidate>
            <duet-heading level="h2">Ota yhteyttä</duet-heading>
            <duet-paragraph>
              Lähetä meille viesti kun haluat antaa palautetta tai pyytää
              yhteydenottoa. Jos olet jo asiakkaamme, asiasi hoituu parhaiten,
              kun kirjaudut verkkopalveluun.
            </duet-paragraph>
            <duet-spacer></duet-spacer>
            <duet-input label="Nimi" placeholder="Matti Meikäläinen" expand></duet-input>
            <duet-input label="Sähköposti" type="email" placeholder="nimi@email.com" expand></duet-input>
            <duet-textarea label="Viesti asiakaspalveluun" placeholder="Kirjoita tähän" expand></duet-textarea>
            <duet-spacer size="x-large"></duet-spacer>
            <duet-button submit variation="primary">Lähetä</duet-button>
          </form>
        </duet-card>
      </div>
      <div slot="sidebar">
        <duet-card padding="large" heading="Sivupalsta">
          Sivupalstaa voidaan käyttää pääsisältöön liittyvän tiedon näyttämiseen
          tai vaihtoehtoisesti nostamaan esiin aiheeseen liittyvää muuta sisältöä.
        </duet-card>
      </div>
    </duet-layout>
    <duet-footer
      items='[
        { "label": "Hae korvausta", "href": "#", "icon": "navigation-make-claim" },
        { "label": "Osta vakuutus", "href": "#", "icon": "action-buy-insurance" },
        { "label": "Yhteystiedot", "href": "#", "icon": "form-tel" }
      ]'
      menu='[
        { "label": "Turvallisuus ja käyttöehdot", "href": "#" },
        { "label": "Evästeet", "href": "#" },
        { "label": "Henkilötietojen käsittely", "href": "#" }
      ]'>
    </duet-footer>
  </body>
</html>

Duet Design System June 2020 Update

2020-06-15T00:00:00Z

You’re reading the eighth Duet monthly update. Last month we asked from our users how we’re doing and what we could improve. We’ll share some of the results in this post.

In the beginning of May we sent out a user research survey to 106 Duet users. Roughly 55% of the people we reached out to answered our survey, which we consider a pretty solid number. We used Duet’s existing Web Components to build the survey and made the form save results onto a sheet file on submit.

100% of the people who answered told us that Duet has improved their work efficiency compared to the past. We’re thrilled about this, since it’s been our number one goal since day one. Secondly, 95.7% said that Duet has improved the accessibility of their product. Finally, 76.1% said that they use Duet either every week or every day at work.

Research data summarized:

Combining the answers into an easy to digest charts:

Verbal feedback:

“I think Duet is one of the best and most comprehensive (still not being bloated) design systems out there. Personally I'm not a fan of using t-shirt sizes in spacing or font size scale, but I also see the reasons behind using those. Naming is always hard.”

“The whole system really is wonderful and helpful, and am very happy with it. Since we have lot of projects and developers working, maybe the support system can be increased with a resource or so. Suppose if we have critical issues having dependency with duet fixes in multiple projects and a release nearing, it becomes a bit difficult.”

“Components should have more slotted contents rather than too many properties. This makes components more versatile and interfaces simpler.”

New this month

In this section we’ll highlight every month new features and progress from Duet Design System. This month’s highlights include:

Content Delivery Network

Duet now has a production ready Content Delivery Network. Some of the benefits of our CDN include: better performance for users, better scaling during heavy traffic, decrease of infrastructure costs due to offloading.

Cookie consent informs users about cookie usage. This banner can be shown to users when they visit a website or an application for the first time.

Tray component

Tray component can be used to reveal additional information to an user on a small viewport, that would normally be shown in the sticky sidebar of the Layout component.

Until August!

Duet Design System April 2020 Update

2020-04-23T00:00:00Z

You’re reading the seventh Duet Design System monthly update. This time last year we published our first Web Components package, version 0.0.1-alpha.1.

As our Web Components turn one year old today, it’s a good time to reflect back and see what we’ve accomplished so far. The road here hasn’t always been straight nor without obstacles. When we started last year there were more open questions than answers. Our main technical concerns were:

Can we make Web Components accessible for everyone?
How do we support basic form submissions?
Can we make them work without JavaScript?
Can we make them work with React.js?
Can we support search engines?
Is the technology ready for production?
What about Internet Explorer 11?

Turns out each of the above challenges can be solved. While we aren’t able to explain each one in detail in this short update, it was Stencil.js that helped us solve Server Side Rendering and React.js support.

At the time of writing we now have 45 accessible Web Components that can be used in production applications. Last month we also published production ready React components, and this week we’re coming out with updated Angular components, also ready for production usage.

During the past month we’ve been also testing our code based components in a design tool called Framer X. Framer allows designers to use the same Web Components that developers use, drag and drop them onto the canvas, and adjust their properties through Framer’s layout panel.

We’re excited about this direction, but it also requires us to do more validation with the different product teams to understand whether or not this is something we’re going to officially support. Big thanks to the Framer team, Dave and Iain, for helpful comments and allowing us to trial their Web Beta.

Finally, we published Web Components v4.0 with some major improvements this month. Our bundle size is 267Kb smaller now (non-gzipped) if counting all 45+ Web Components, and rendering also became 0.5× faster compared to previous generations.

Here are quick statistics of the first year:

From zero to 23+ customer facing services utilizing Duet in one year.
Developer productivity with CSS has improved 4.91×.
450 000 page views from 70+ countries on duetds.com.
45 ready to use Angular, React, and Web Components.
4 000+ component instances in use in different products.
4 000+ feature updates and bug fixes to the design system.
1 000+ design system package versions published.
600+ automated deploys of documentation.
400+ pages of documentation written.
500+ automated tests running.
12 Node.js packages.

New this month

In this section we’ll highlight every month new features and progress from Duet Design System. This month’s highlights include:

Angular Components

Duet’s Angular components are now out of experimental status and officially supported, meaning they can be used in production apps! This change simplifies work for teams working with Web Components, Angular and forms.

Framer X Beta

During the past month we’ve been testing our code based components in a design tool called Framer X. Framer allows designers to use the same Web Components that developers use, drag and drop them onto the canvas, and adjust their properties through Framer’s layout panel.

Web Components reach 4.0

Duet Web Components 4.0 is out with some major improvements. Our bundle size is 267Kb smaller (non-gzipped) if counting all 45+ components, and rendering also becomes 0.5× faster compared to previous generations.

Table component

Newly introduced Table component is a lightweight and un-opinionated component for enhancing tabular data. In addition to data tables, it can also be used for comparison tables in the context of products.

Until June!

Using Duet Design System’s CLI Tools

2020-03-23T00:00:00Z

Following this tutorial you will learn how to utilize Duet’s Command Line Interface to create simple websites that can be shared via GitHub Pages, Amazon S3, and Azure Storage.

Before moving further, please make sure you have Node.js 12.x or newer installed. You can install the latest version through their website.

For guidance on deploying prototypes created with the Duet CLI to Github pages, please refer to Sharing Prototypes.

Getting started

As the first step, you will want to install Duet’s Command Line Interface globally on your machine using Node Package Manager. To do so, run the following command in your terminal:

npm install -g @duetds/cli

Once you’ve installed the CLI package, you can open up any directory in your terminal and run Duet’s “create” command. Create command allows you to quickly set up a development environment with everything you might need from Duet preconfigured:

create-duet-app

Alternatively, you can run the CLI without having to install by using npx, which is included with npm:

npx @duetds/cli

Running either of the above commands will next ask you to choose the template that you want to use in your project:

Please choose which Duet template to use (Use arrow keys)

  ❯ Eleventy
    Eleventy-SSR
    HTML
    Angular
    React

Picking Eleventy or Eleventy-SSR generates a multi-page project with features like global navigation and footer (SSR in this context means “Server Side Rendered”).
The HTML option generates a simple one page project that has fonts, components, and CSS Framework preloaded.
The Angular option generates an angular project configured to use the @duetds/angular package, fonts, CSS framework, and a basic router/multi-page setup.
The React option generates a react project derived from create-react-app, which comes configured to use the @duetds/react package, fonts, and CSS framework.

The full feature set for both Eleventy templates include:

Preconfigured Eleventy project starter with commands for developing, testing, and building the project.
Everything you need to create a simple production ready static website: Header and Footer partials, global navigation, LocalTapiola favicons, Manifest files, Robots.txt, and HTML/CSS/JS minification.
SSR (Server Side Rendering) for Duet Web Components.
Use Duet Design Tokens in SCSS without configuration.
Additionally comes with Duet Fonts and Duet CSS Framework preconfigured.

Once you’ve picked the template, you will be next asked to enter a name for the project. This is also the name of the directory that will be generated. By default, if you just hit enter, the project will be called “duet-prototype”:

Enter a name for this project (duet-prototype)

Finally, the last step asks whether you want to initialize a GIT repository or not. This defaults to “No”:

Initialize a git repository? (y/N)

After this Duet’s Command Line Interface will generate a project for you and show step by step what’s happening:

Initialize a git repository? Yes

  ✔ Create project directory
  ✔ Copy project files
  ✔ Create build and deploy automation
  ✔ Configure .gitignore
  ✔ Initialize git
  ✔ Install dependencies

Once finished, run cd [project-name] and refer to the README.md file inside this directory for further template specific usage instructions.

Duet Design System March 2020 Update

2020-03-03T00:00:00Z

You’re reading the sixth Duet Design System monthly update. This time the update covers both February and March as it looks like we forgot to push an update out last month.

At the time of writing, Duet is now being utilized in 23 different web applications at LocalTapiola and Turva. This number is almost twice as high now compared to last November. As a result of this quick adoption rate, we’ve had to rethink some of the processes and introduce more transparency towards the product teams.

An example of this is our new bi-weekly gathering for Frontend Developers. The aim is to walk through new and upcoming features of Duet Design System and also address any questions developers might have about them. Similarly, we’ve also had weekly gatherings for designers and third party design partners for quite some time now.

During the last month the biggest change for Duet was the introduction of Command Line Interface. CLI helps developers and frontend oriented designers to quickly set up a development environment that has all our packages preconfigured. This makes prototyping and creating simple websites using Duet much quicker.

We’ve been also setting up new prototyping environments and process automations into GitHub. These will soon be used together with the new CLI tools introduced.

Finally, we’re right now in the progress of moving away from Sketch app towards using Duet’s code based components as a design tool instead. This is an exciting new direction we’ll be sharing more about in a few months.

New this month

In this section we’ll highlight every month new features and progress from Duet Design System. This month’s highlights include:

React components v3.0 released

Duet’s React library is now out of experimental status and officially supported by us. This means that it can be used in production apps and doesn’t anymore require complex configuration to make things work with e.g. Gatsby.

Command line interface

Duet now comes with a Command Line Interface (CLI) that helps you to quickly set up a development environment that has all our packages preconfigured. This makes prototyping and creating simple websites much quicker.

Stepper component

Newly introduced Stepper component can be used to create wizard-like workflows by dividing content into logical steps. The user can then navigate backwards by clicking on the header of a completed step.

Updated List component

List component replaces Duet’s old Definition List that is now deprecated. This new component allows developers to put any type of content inside the slots of the List and also adds a long waited server side rendering support.

On the roadmap next

Table component is under work right now and will be published soon.
Prototyping environments and related automation is under work and ready for usage next week.
Finally, we’re focusing onto making it possible to use Duet’s code based Web Components directly inside design tools.

Until April!

Duet Design System January 2020 Update

2020-01-20T00:00:00Z

You’re reading the fifth Duet Design System monthly update. This update focuses on new feature and component improvements we’ve been working on.

The past month has kept us rather busy. We’ve spent most of our time helping developers working in the different product teams to get their applications production ready, while also improving the accessibility of Duet Design System’s Web Components.

Compared to the beginning of December, we’re now down from roughly 30 accessibility issues to just 4 non-critical ones. This means that our components now fully support all the common screen reader and OS combinations like:

VoiceOver on macOS and iOS
TalkBack on Android
NVDA on Windows
Jaws on Windows

In addition to accessibility improvements, we’ve also worked on new components. For some time one of the most requested component has been a modal, so we’re happy to tell that Modal is finally out of prototype status and ready for production use.

We’ve also improved the overall automation for Duet’s icon library. Its generation doesn’t include manual steps anymore, which means we’re able to add new icons or edit existing ones much more effortlessly.

Finally, we’re happy to announce that we have a new frontend developer, Nick Williams, starting to work with us to help make Duet Design System even more robust for the teams consuming it. Welcome Nick!

New this month

In this section we’ll highlight every month new features and progress from Duet Design System. This month’s highlights include:

Server side rendering

Server Side Rendering refers to JavaScript application’s ability to render on the server rather than in the user’s browser. Duet’s components now support this and can be rendered on a Node.js server for better performance.

import hydrate from "@duetds/components/hydrate"

hydrate.renderToString(content, {
  clientHydrateAnnotations: true,
  removeScripts: false,
  removeUnusedStyles: false
})

Updated components view

We’ve been working on improving the components listing and created preview images for each component. Additionally Duet’s global search has been improved to make it easier to find a specific component.

Introducing tutorials

To make it easier to learn how to build applications using Duet Design System, we’ve started writing tutorials that currently cover topics like layout creation and server side rendering.

On the roadmap next

Our first priority is to onboard new team members and determine together how we want to continue developing features in 2020.
The next priority is to focus on a new drag and drop browser based interface builder for Duet’s Web Components.
Finally, we’re also focusing on getting the last missing components ready for production usage. For an up-to-date list on progress and what’s under work, view component statuses.

Until February!

SSR with Duet Web Components

2020-01-18T00:00:00Z

Following this tutorial you will learn how to server side render Duet Design System’s Web Components using Eleventy and other static site generators.

For this particular tutorial we’re assuming you already have a working Eleventy website up and running with Duet’s Fonts and CSS Framework. If you aren’t familiar with Eleventy, its documentation provides easy to follow getting started instructions.

Getting started

To get started with server side rendering, install Duet’s Web Components and NCP into your own project by running:

npm install @duetds/components ncp --save-dev

Once installed, add a script to your package.json that copies the component library from Duet’s package into a location you’ve specified:

"scripts": {
  "copy:components": "ncp ./node_modules/@duetds/components/lib ./src/js/components"
}

In the above example we’re copying the components into src/js/components directory. You can now call this script while starting up your app or build process to make sure you’ve always got the latest components copied over:

"start": "copy:components & dev"

Once you have a copy task in place and have copied the component library over, you can put script tags similar to these in the <head> of your page:

<script type="module" src="/js/components/duet/duet.esm.js"></script>
<script nomodule src="/js/components/duet/duet.js"></script>

The above scripts will take care of client side hydration of the server side rendered components, nothing else is required.

SSR configuration

Now that we’re done with the client side hydration, it’s time to configure Eleventy to render our Web Components on server.

Duet’s Web Components package includes a hydrate app for this usage. The hydrate app is a bundle of the same components, but compiled so that they can be hydrated on a Node.js server and generate static HTML and CSS.

To get started, import the hydrate app into your .eleventy.js configuration:

const hydrate = require("@duetds/components/hydrate")

Next, add the following transform into your .eleventy.js configuration file that takes content as an input and processes it using Duet’s hydrate app:

const hydrate = require("@duetds/components/hydrate")

module.exports = function(config) {
  config.addTransform("hydrate", async (content, outputPath) => {
    if (outputPath.endsWith(".html")) {
      try {
        const results = await hydrate.renderToString(content, {
          clientHydrateAnnotations: true,
          removeScripts: false,
          removeUnusedStyles: false
        })
        return results.html
      } catch (error) {
        return error
      }
    }
    return content
  })
}

Most of the time you probably only want to do the rendering in production environment, so you could modify the above to include a check for that:

const hydrate = require("@duetds/components/hydrate")

module.exports = function(config) {
  config.addTransform("hydrate", async (content, outputPath) => {
    if (process.env.ELEVENTY_ENV == "production") {
      if (outputPath.endsWith(".html")) {
        try {
          const results = await hydrate.renderToString(content, {
            clientHydrateAnnotations: true,
            removeScripts: false,
            removeUnusedStyles: false
          })
          return results.html
        } catch (error) {
          return error
        }
      }
    }
    return content
  })
}

The above transform now gives you server side rendered components that function without JavaScript. Please note that you need to separately pre-render the content for each theme you want to support.

One thing to also keep in mind is that if you’re doing HTML minification, you should configure it so that it won’t remove comments from HTML as the client side hydration relies on them to be available. If you’re using html-minifier with Eleventy, you can configure it like this:

const htmlmin = require("html-minifier")

module.exports = function(config) {
  config.addTransform("htmlmin", function(content, outputPath) {
    if (process.env.ELEVENTY_ENV == "production") {
      if (outputPath.endsWith(".html")) {
        let minified = htmlmin.minify(content, {
          // Client side hydration won’t work if comments are removed
          removeComments: false
        })
        return minified
      }
    }
    return content
  })
}

Why We Use Web Components

2019-12-28T00:00:00Z

It’s August, 2018. I’m at the office, sitting by the window staring rain pouring down from the sky. A warm cup of tea in my hand, about to sip it, but the phone suddenly rings. I don’t recognize the number. I hesitate for a moment whether to pick it up or not. Maybe it’s again a telemarketer trying to sell me something?

Thinking of this particular autumn evening today, a year and a half later, I’m delighted I picked up the phone. This one phone call ended up having a major impact, as the end result was the biggest personal project I have worked on so far.

While I used to work with bigger clients and projects when we lived in United States, this felt different. I personally sold the project and were responsible for most of the things from initial research all the way to the design system’s overall architecture.

A few months went by after our first call. I went to see the client during a couple of occasions to plan the possible collaboration. After some back and forth negotiation we ultimately started working together in the beginning of January, 2019.

And so Duet Design System was born.

Controversial opinions

As you might have guessed based on the title, Duet Design System has something to do with Web Components. Quite a lot actually. Our whole frontend component architecture is based on Web Components. But how and why did we end up using them? Seems like a very controversial tech, at least if you solely base your opinion on what’s happening on Twitter.

Well if anything, we didn’t actually start by choosing Web Components. It was more that they chose us. Truth speaking, we weren’t even considering them until only later on in the spring once the research I was working on started suggesting us that they might be the most viable option.

One of the biggest challenges for us turned out to be the number of different tech stacks in use. My client had applications built using Angular, React, Ember, Vanilla JavaScript, basic HTML, native code. And more.

We couldn’t just choose [a framework] because the different tech stacks were picked by different teams (or even different sub-companies) for different reasons and we would have never succeeded if we would have tried to force everyone to use a specific technology like React.

Instead, we had the urge to create a technology-agnostic instead of technology-specific system. A system that is based on Web Standards and would survive the births and deaths of JavaScript frameworks.

What are Web Components?

Web Components are a set of technologies that provide a standards based component model for the Web. They allow you to create reusable Custom Elements with their functionality encapsulated away from the rest of the code. Primary technologies used to create them include:

Best parts of Web Components

This past year has made me a big advocate for Web Components. What previously seemed like a distant black box that I tried to stay away from, has now become an important part of my toolset. If I would have to list the main reasons why Web Components work so greatly for Duet Design System, it would be these four things:

1. Tech-agnostic instead of tech-specific

2. Future proofing with Web Standards

3. Any framework or no framework

Web Components can be used with basically any JavaScript framework or no framework at all. This means we’re able to support all our product teams from a single codebase. This makes it possible for our small design system team to be very efficient. Currently we can offer support for all of the following with just one set of components:

4. Full Encapsulation

Shadow DOM allows components to have their own DOM tree that can’t be accidentally accessed from the main document. For us this means that “everything just works” when the components are implemented onto different environments and platforms. Styles cannot penetrate a component from the outside, and styles inside a component won’t bleed out.

Debunking Myths

I guess you really can’t talk about Web Components without also talking about their negative sides. They’re built on evolving standards which have their flaws and limitations. I’ve seen a few myths go around though which I’d like to clear just a bit for anyone wondering:

1. Shadow DOM doesn’t work with forms

This is true to some extent and one of the drawbacks of Shadow DOM. It makes sense though if you think about it. Shadow DOM isn’t a part of the normal DOM tree/document. Whether this is an issue for you or not depends on what you’re building.

There’re a few approaches on how to get around this, but the easiest is to not use Shadow DOM for components that host form inputs. The other option would be to create an invisible input and append that with JavaScript to the parent document.

2. Web components can’t be server side rendered

Not true. We’ve built support for server side rendering into our Web Components. While it might be hard to do if you would have to build a solution from scratch, there are tools like Stencil.js that solve this for you.

Duet’s Web Components package includes a hydrate app that is a bundle of the same components, but compiled so that they can be hydrated on a Node.js server and generate static HTML and CSS.

3. Using web components means duplicate CSS

It can if you don’t make your components modular enough. But if your frontend architecture is designed around reusability and modularity then this isn’t really an issue. Yes, you might have to set margin and padding once to zero for each Shadow DOM, but let’s not exaggerate the impact of this. We use one Sass mixin for this in Duet.

4. Web components aren’t accessible

Not true at all. Of course you can construct them in a way which isn’t accessible. But so you can do by building things with [insert a JavaScript framework] as well. We provide support for WCAG 2.1 Spec and have tested our Web Components to work with all common screen reader and OS combinations like:

VoiceOver on macOS and iOS
TalkBack on Android
NVDA on Windows
Jaws on Windows

5. Web components don’t work with React

This is both true and false. Web Components themselves work fine, but by default React passes all data to Custom Elements in the form of attributes, meaning you can’t pass objects or arrays without workarounds. Additionally, because React has its own synthetic event system, it cannot listen for DOM events coming from Custom Elements without the use of refs.

Both of these issues can be fixed, but for some they might be showstoppers. For our team the benefits of Web Components far surpassed these and we decided to work our way around these issues by automatically wrapping our Web Components with React based wrappers.

6. Web Components aren’t production ready

This last myth I probably hear the most often. People seem to assume that because Web Components are built on evolving standards they can’t be used for anything else except experiments. Well guess what, the whole World Wide Web is a set of standards that are constantly transitioning and evolving.

If you need to see some real life examples, take a look of Firefox’s user interface that is now built with Web Components. Or Apple who uses Web Components in their new Apple Music service.

The future is bright

This is an incredibly exciting time to be a web developer. New standards^[1] like the Web Components have made it so much easier to build systems that can support a range of platforms and frameworks via a single code base. To be completely honest; five years ago I would have probably laughed if someone would have claimed that all of this would be easy.

Enthusiastic from our positive experiences, the next step is to expand towards native apps and create browser based tools around Duet’s Web Components that allow us to move further from static design tools.

Web Components out in the wild

^[1] If we can really consider something introduced in 2011 to be new anymore.

Design System Won’t Fix Your Problems

2019-12-27T00:00:00Z

Ever read an article praising design systems and how they magically solve design and frontend challenges? I’ve sure seen this being repeated in one form or another. Maybe not with these exact exaggerated words, but the underlying message has been close. While there might be a spark of truth there somewhere, it can be quite misleading to make this kind of statements without explaining what’s really required.

You might’ve seen or been on the other side as well, where organizations invest large sums of money to hire external agencies to create design systems for them. These agencies often work completely detached in their own silos and only claim to blend into the client’s organization. While this is a good business model for the agencies selling and creating these systems, it rarely works out for the client organization.

Real life example of this behaviour: a manager at Organization Y hears about design systems and how they solved the challenges of Organization X. They want to get on the bandwagon as well. Agency Z sees this as a money making opportunity and sells them a team of designers and developers who will design and build the system for Organization Y. The starting price is over one million US dollars.

While this works as a great marketing and produces a nice portfolio piece for the Agency Z to sell even more expensive projects like this in the future, the Organization Y is ultimately left with a product that isn’t utilized or serving a real purpose.

This happens for a few reasons, but the main one being that the people working in-house don’t really believe in nor are part of the design system Agency Z created. Why would they care or change their habits for someone who doesn’t even work in Organization Y?

So begins the slow and painful death of the system.

Eventually someone needs to be blamed, so Organization Y fires the manager and stops further contracts with Agency Z.

Everyone loses.

At no point does Organization Y consider, nor is told, that for the design system to actually work, it needs to be an internal product owned by the organization, not an outsourced project.

You can’t just hire an agency to create a design system and expect that the system alone will solve something. It won’t do much before the people in the organization align on this idea as well, believe in it, invest in it, and create a culture of collaboration around it.

Many agencies selling design systems as projects won’t explain this to you. I’ve had to witness this so many times that it lead me to write this post. I’m thinking the biggest reason being that they either don’t have enough experience on the matter, or that it’s against their core business model that relies on selling as many hours as they can.

Imagine someone from an agency explaining in a sales meeting:

“We don’t think you should hire an agency to create your design system, but instead have an in-house team. The most we can do is to help you kick off the work while providing our expertise.”

There are exceptions of course. To both reasons why you might need an agency and the agencies themselves.

We don’t live in a black and white world.

So while it’s probably a bad idea to hire an external agency to create your whole system, it could be helpful to have someone external from an agency to lead you towards the right direction if your organization lacks the necessary experience and expertise.

Just stay away from folks who try to convince you that having a design system alone will solve something.

It won’t.

It’s just the beginning.

Duet Design System December 2019 Update

2019-12-01T00:00:00Z

You’re reading the fourth Duet Design System monthly update. In this update we’ll share statistics and feedback we’ve received regarding Duet’s public launch.

Last month marked a major milestone for us as we launched Duet publicly. A little under a month has gone by, and we’ve seen more than 12.000 unique visitors from all over the globe.

Most of the visitors are coming from United States, Finland, and the UK, but in total we’re seeing traffic from 72 different countries. A simplified overview of the past three+ weeks’ statistics looks like this:

200.000 page views
12.000 unique visitors
72 countries represented
52.000 goal completions
100+ websites and blogs sharing Duet
1 million files served via our CDN

While a lot of the traffic has been coming from social media, Duet has also been shared on these websites, publications, and newsletters:

The conversation has been fairly active on Twitter too. I personally tweeted this on November 6th and it ended up being the single biggest source of traffic for our documentation (thanks to all the retweets, people):

Extremely happy to tell that we’ve finally made Duet Design System’s docs public. Features I’m personally proud about:

— Can be used with any JS framework
— Supports WCAG 2.1
— Comes in two themes
— Minimal network footprint
— Uses Web Componentshttps://t.co/v9PET3G8BS
— (@arielsalminen) November 6, 2019

Zach Leatherman, who created the tool called Eleventy that our documentation also uses, commented:

I’ve been waiting eagerly for this launch—it really feels like a new gold standard for long-term framework independent design systems.

“can be also used *without* any JS framework.” 🎉

Amazing work @arielsalminen!https://t.co/PBHpli81cR
— Zach Leatherman (@zachleat) 6. marraskuuta 2019

Jad Limcaco, who’s working at Apple commented:

I really like how they simplified it so it can be used for prototyping really easily. All you do is add some script tags. Then you can use the components in HTML like so:

<duet-button variation="primary">Send</duet-button> pic.twitter.com/J3aQ5kL5Oq
— Jad Limcaco (@JadLimcaco) November 6, 2019

Nathan Curtis, who co-founded EightShapes commented:

Duet design system roadmap, published on their site, full on with struckthrough completed items!https://t.co/D5HwGLYGTm
Per @arielsalminen
HT @jamesmelzer
CC @ClayHero
— Nathan Curtis (@nathanacurtis) November 12, 2019

Jordam Dimitrov asked us:

@Lahi_Tapiola I saw https://t.co/Ia5fQpiLC7 and it's awesome! We need to make a similar platform for our DS, did you use something ready or it's custom-made? :)
— Jordan Dimitrov (@iamjdimitrov) November 6, 2019

Karlis Upitis commented:

Yet another great Design System https://t.co/ffzrj0g4JK
A lot of useful resources e.g. this diagram - "when to add a new component?" pic.twitter.com/1zTmkVl0g7
— Karlis Upitis (@_karlisup) November 29, 2019

Javier Cuello commented:

This looks really good to see how a design system works and is documented *for real*. It includes components code, design tokens, naming conventions and more. https://t.co/OswNYtWGTH
— Javier 'Simón' Cuello (@millonestarde) November 6, 2019

Similarly, Teppo Haste from our team shared Duet on LinkedIn which resulted in a bunch of new traffic and questions about the work we’ve done so far:

All in all, we’re really happy about the reception. This makes us want to push towards even higher quality content in the future for both our clients, and the design and development teams utilizing Duet.

Now is also a good time to say thanks to all our partners that have been a part of this journey so far: Kuudes, Dunning, Kruger & Associates, HiQ Finland, CGI, Tata Consultancy Services, and all in-house teams, a big thank you!

New this month

In this section we’ll highlight every month new features and progress from Duet Design System. This month’s highlights include:

Desktop application

Duet’s documentation is now available as a progressive web app with offline support. Using Chrome on Desktop and Android, or Safari on iOS lets you install Duet onto your device. Follow these instructions to get started.

Process for adding components

We’ve completely reworked our contributing guidelines and have included a new flow diagram that helps you determine whether a component belongs to the design system or should be kept application specific instead.

New layout tools

During the past month we’ve focused on improving Duet’s layout tools. We’ve introduced new components like Layout, Grid, Grid Item and Spacer. The responsive capabilities of most components have been improved as well.

Visual regression tests

Automated visual regression tests allow us to make sure that our components render as expected across different browsers after changes are made to the code. They also help us deliver higher quality releases with less bugs.

On the roadmap next

Getting more components ready for production usage is still our first priority at the moment. For an up-to-date list on progress and what’s under work, view component statuses.
Our next priority is to support designers and developers who start utilizing these new parts. If you have any questions, please view support page and reach out.
Finally, we’re also starting to focus more on contribution and adoption from different teams and plan for 2020.

Until 2020!

Duet Design System November 2019 Update

2019-11-01T00:00:00Z

You’re reading the third Duet Design System monthly update. This month marks a major milestone for us as we’re launching our new design system publicly.

After ten months of hard work, we’re extremely happy to announce that we’ve removed the authentication and made the documentation public. This change will make sharing and collaboration between different teams and third party vendors much easier. This is also a chance for us to be more transparent towards our users and share the work-in-progress.

We’re also excited to see continuous rise in the adoption rate of Duet inside LocalTapiola and Turva. We follow this with a Node.js based tool that we’ve built. The tool automatically measures Duet’s adoption and utilization levels across our product portfolio, and helps us understand where and how the system is being utilized and how it affects the work of different teams.

At the time of writing, thirteen product teams utilize Duet directly in their app. Four out of those thirteen teams already have most of their frontend UI using Duet’s packages instead of custom built solutions. This quick adoption rate has somewhat affected our pace developing new features as we’ve had to provide a lot more support to our users. This is a very positive problem to have though!

Remember, if you have any questions or problems, don’t hesitate to contact us directly. We’ve also created a comprehensive FAQ page that should answer some of your questions as well.

The above screenshot reveals a tiny portion of our statistics tool. This graph shows the total installations of our core packages. This is probably the least important information in the whole tool, but fun statistic to have nevertheless.

New this month

In this section we’ll highlight every month new features and progress from Duet Design System. This month’s highlights include:

New brand typeface

We’ve been working on a new interface and brand typeface since early 2019 together with type designer Kostas Bartsokas. The typeface, called LahiTapiola Sans, is now ready and downloadable from typography page.

Design principles

Design principles form the foundation of Duet. They guide our team when working on different parts of the system and help us do better and more informed decisions.

React and Angular components

To make it easier to use Duet’s Web Components on different frameworks, we’ve created React and Angular specific wrappers. This means you now get the ability to use for example ngmodel on inputs and other form fields.

// Install Duet’s React package
npm install @duetds/react

// Import a React component from the above package
import React, { Component } from "react";
import { DuetButton } from "@duetds/react";

// utilize the imported component
export class Example extends Component {
  render() {
    return (
      <DuetButton variation="primary">
        Primary button
      </DuetButton>
    );
  }
}

On the roadmap next

Getting more components ready for production usage is still our first priority at the moment. For an up-to-date list on progress and what’s under work, view component statuses.
Our next priority is to support designers and developers who start utilizing these new parts. If you have any questions, please view support page and reach out.
Finally, we’re also starting to focus more on contribution and adoption from different teams and plan for 2020.

Until December!

Duet Design System October 2019 Update

2019-10-01T00:00:00Z

You’re reading the second Duet Design System monthly update. This update focuses on accessibility and performance updates that we’ve been working on.

During the past month we’ve focused on getting more components ready for production usage together with some big accessibility and performance improvements. At the time of writing, we now have 25 production ready components together with 5 example templates you can use.

Making all these new features accessible has become an important part of our workflow. While the new accessibility law requires us to do so, the more important part is that it allows us to improve the experience for everyone who uses our products. To achieve this, we’ve created an accessibility checklist that helps us remember to tick all the necessary boxes.

We’ve been also working on optimizing Duet’s packages for better performance. All packages now weigh around 90 KB combined which is pretty good, considering that this includes static assets as well. Current network footprints for different parts look like this:

Web Components Runtime: 1.3 KB gzipped
Design Tokens: 1.5 KB gzipped
CSS Framework: 3 KB gzipped
Fonts CSS: 300 bytes gzipped
WOFF2 fonts: 46.6 KB
All 302 icons combined: 43.9 KB

New this month

In this section we’ll highlight every month new features and progress from Duet Design System. This month’s highlights include:

Visual Studio Code extension

Visual Studio Code is an editor optimized for building modern web apps. To ease up the usage, we’ve created an extension that does autocompletion for Duet’s components and component properties.

Accessibility checklist

Accessibility checklist is a tool created and used by Duet’s core team when developing new features. It helps us improve the experience for everyone who uses our products and can be useful for other teams as well.

CSS Framework

Duet’s CSS Framework includes a wide range of shorthand utility classes to modify an element’s appearance in your own application. It’s also an useful companion to include on a page when using our components.

<!-- To change text colors -->
<p class="duet-color-primary">Text</p>
<p class="duet-color-secondary">Text</p>

<!-- To change background colors -->
<div class="duet-bg-primary"></div>
<div class="duet-bg-secondary"></div>

<!-- To change fills of SVGs -->
<svg class="duet-fill-primary"></svg>
<svg class="duet-fill-secondary"></svg>

On the roadmap next

Getting more components ready for production usage is still our first priority at the moment. For an up-to-date list on progress and what’s under work, view component statuses.
Our next priority is to support designers and developers who start utilizing these new parts. If you have any questions, please view support page and reach out.
Finally, we’re also working on an internal tool that will allow us to measure Duet’s adoption and usage. This will help us understand where and how Duet is being used and how it affects the workflows of other teams.

Until November!

Duet Design System September 2019 Update

2019-09-06T00:00:00Z

You’re reading the very first Duet Design System monthly update. As this is the first of its kind, we’ll do a short recap on what has been accomplished so far.

Where we’re now

We started working on Duet earlier this year in the form of user research and interviews. This was done to recognize organizational challenges and to create a solid plan for the work to follow. The challenges recognized were divided into different categories and based on them, the goals for the system became:

Improved work efficiency for designers and developers
Improved user interface consistency and quality
Improved communication between teams and people
Shared documentation platform

Since those early days we’ve made a lot of progress on all these fronts. We now have a living and breathing system that’s divided into six front-end packages, a documentation platform, and a Sketch toolkit that the designers use.

We’ve also created many smaller utility tools such as Duet Zeplin extension. This extension shows Duet’s Design Tokens instead of hard coded values in the Zeplin app.

The packages and tools created can be used together or separately depending on your team’s individual needs. This makes it easier to start adopting parts of the design system into existing applications.

While there’s a lot more work to do, especially on the communication part, we’re excited about the fact that we’re quite a bit ahead of our original schedule. That gives us some headway to improve the communication via these monthly updates and weekly design system “office hours” where you can just show up with your design system questions and support requests (every Thursday at 2pm).

If you have any questions right now, don’t hesitate to contact us directly. We’ve also created a comprehensive FAQ page that should answer some of your questions as well.

New this month

In this section we’ll highlight every month new features and progress from Duet Design System. This month’s highlights include:

Duet Zeplin extension

Zeplin is a tool we use to handoff designs with accurate specs, assets and code snippets to developers. To ease up the usage and make it more efficient for developers, we’ve created an extension that shows Duet’s Design Tokens in Zeplin.

Icon search

To make it easier to find a specific icon (or many!), we’ve created a better user interface for searching Duet’s icons. Each of the icons is now also tagged with a bunch of keywords for easier discoverability.

New components

We’re working hard on your component requests. That’s finally paying off as we’re now seeing the first actual components being rolled out to production applications. See Navigation or Hero Area for examples of such components.

On the roadmap next

Getting more components ready for production usage is our first priority at the moment. For an up-to-date list on progress and what’s under work, view component statuses.
Our next priority is to support designers and developers who start utilizing these new parts. If you have any questions, please view support page and reach out.
Finally, we’re working on the documentation and trying to make sure it covers most of the things you might ask. Recently, we updated the Getting Started guidelines for both developers and designers. If you feel like something’s missing, please let us know.

Until next time!

Design Principles of Duet Design System

2019-03-20T00:00:00Z

LocalTapiola hired me in 2019 to help reimagine what the company’s approach to designing, building and shipping digital products at scale should look like. I started this work by conducting a series of user research activities and workshops to reveal a lack of alignment and personal biases across business units, products and teams to understand how the design system could help them.

When we had a clear view of the challenges that we wanted to solve, it was a matter of creating fundamental principles for the system that we could follow as a team. These are the principles that I created for Duet:

1. Universality

Universality is in the core of the World Wide Web, so we should embrace it and build systems that are available to, and accessible by, everyone.

2. Consistency

Consistency enhances clarity and makes our system more predictable and efficient to use. Users shouldn’t have to wonder whether different actions or terminology used mean the same thing.

3. Performance

Good performance is good user experience. We should strive towards making our system as fast as possible in terms of both network footprint and the time it takes to become interactive.

4. Modularity

Modularity reduces complexity and improves our system’s reusability by breaking it into small, easy to consume parts.

Vue Design System

2018-03-13T00:00:00Z

Vue Design System is a set of organized tools, patterns, and practices that work as the foundation for Vue.js application development. What initially started as a quick-n-dirty prototyping tool for a client of mine, has grown into a fully capable systems tool that provides an environment where the pattern library and live application can be perfectly in sync.

For me personally, Vue Design System has become as much of a design systems teaching and learning platform, as it is a tool that’s capable of growing from a prototype to a fully fleshed-out system that multiple applications can depend on.

In this article, I will shed some light to the processes and workflow I use to get started with a new design system project. An article, I would’ve wanted to come across when first starting with design systems and trying to figure out the best approaches. While I’ve written this from Vue Design System’s perspective, the concepts and processes I introduce here will work with any tool.

The Structure

A design system can help establish a common vocabulary between everyone in an organization and ease the collaboration between different disciplines. I’ve seen it go the other way around too when important decisions have been made in a rush. To avoid that, Vue Design System introduces the following framework for naming that I’ve found working well in the past:

Let’s quickly walk through each of these concepts before diving into the workflow part.

Principles

Design principles are the foundation of the whole system. They form the basis of a good product and help the team with decision making. They are there to guide you and your team when working with the myriad parts of the system and help you do better and more informed decisions.

Tokens

Design tokens are the atoms of the system as Salesforce describes them. In Vue Design System they are used instead of hard coded values to ensure a better consistency across any platform. To give you a concrete example, this is how Vue Design System has its tokens defined:

# FONT-SIZE
font_size_xx_large:
  value: "64px"
font_size_x_large:
  value: "48px"
font_size_large:
  value: "24px"
font_size_base:
  value: "16px"
font_size_small:
  value: "13px"
font_size_x_small:
  value: "11px"

In the background, a tool called Theo converts the above format to both Sass and Json, so that you can utilize the tokens across the system:

// Example using SCSS
.heading {
  @include stack-space($space-small);
  font-family: $font-family-heading;
  line-height: $line-height-heading;
}

You can also import the tokens in JavaScript:

// Import tokens
import tokens from "@/tokens/tokens.raw.json"

Elements

Elements utilize decisions made on the token level. A simple example of an element would be a button, a link, or an input. Anything that cannot be broken down further. I use the name ‘element’ since everything in Vue and React world is nowadays ‘a component.’ Using that term for anything else would be confusing.

Patterns

Patterns are UI Patterns that fall on the more complex side of the spectrum. So for example things like a date picker, a data table, or a visualization. Patterns utilize both elements and tokens. If you wonder whether something should be called an element or a pattern, ask yourself this question: “Can this be broken down into smaller pieces?” If the answer is yes, it should most likely be a pattern in Vue Design System.

Templates

Finally, Vue Design System has templates which exist to document the layout and structure of a section. I am not calling these pages since semantically that would be incorrect. While they can be pages, that’s not their only functionality. Templates consist of the three things mentioned above: tokens, elements, and patterns.

My Workflow

Now that you’re familiar with the structure of Vue Design System, it’s time for us to move forward. While my process almost always starts with research, I’m expecting here that we’ve already done that, have the necessary buy-in from the executives, and have an interface inventory ready. Maybe you even got a design systems team formed at this point, and everyone is eagerly waiting to get started.

The way I tend to start the work is by organizing a few day long workshops first. After the initial workshops, I begin running more intensive design sprints with the whole team. This is done to get a kick-start for the whole project. Overall, the process I use looks somewhat like this:

Figure out organizational challenges
Define principles for the system
Quick draft of type, color, and spacing
Find unified design direction by exploring
Iterate on color palette, type, and spacing
Define initial set of system’s parts

Workspace after a design systems sprint at Nosto.

Figuring out challenges

Often the challenges related to people, organization’s structure, and the underlying processes are the hardest things any given system faces. They’re also some of the primary reasons we’re building these systems for in the first place. What I’m trying to say here, is that it’s not enough to build a system. That itself won’t solve anything. You need to make an organization to adopt it and maintain it over time. Get people excited about it. Only then the system will start solving the things it was meant to.

This is why I tend to start any systems project by running a so called Challenges Workshop. This workshop is meant to reveal a lack of alignment and personal biases across teams. It has a tendency to show organizational challenges too, which is where the name comes from.

To run this workshop, I use a similar model that Jonathan Courtney describes in his article called Lightning Decision Jam—solve problems without discussion. If you’re interested, you can view the slides I use on SlideShare. The output of the workshop is a set of prioritized actions that directly inform the backlog of the design system.

Keep in mind that while the format of this workshop is very strict, things don’t always go like planned and you need to be ready to go with the flow. People will ask questions. There will be unexpected breaks. The important person you expected won’t be able to join. But that’s all ok.

Challenges Exercise slidedeck. View the deck.

Defining principles

Once you’ve figured out what the tough problems are that you’re trying to solve, the work should continue from the guiding principles. Maybe your company already has design principles in place, or maybe you can utilize some of your brand guidelines as the base here. Nevertheless, this is where the groundwork for the system is done.

If you remember this diagram I shared earlier, it shows how everything in Vue Design System is based on the underlying principles:

The way I’ve done this in the past, is by running a few dedicated workshops which have helped us to create high level draft principles. After the workshops, I’ve assigned one person to iterate on the principles. At the same time we, as a team, have provided feedback and helped to edit the design principles further.

Defining design principles at Nosto.

Drafting type, color & spacing

Once your principles start shaping up and you’ve got a draft that you can share to stakeholders, it’s time to start planning the system’s tokens.

One way to do this, is by creating a quick draft styleguide by one or a few designers. The point is not to make something final or to spend a lot of time this early. Instead, try to create something quick and simple that you can utilize in the next steps moving forward.

I suggest you to try to capture any ideas about a new design direction as well, if any. Recently, I did a quick draft styleguide for one of my clients that looked like this:

Yhdistysavain’s draft styleguide.

Finding unified design direction

At this point, I usually want to pull the whole design systems team together and clear their calendar. After we’ve agreed on the schedule, we focus on different products or product features to redesign utilizing the principles and design tokens created.

I call this the Design System Kick-off Sprint. It’s important to involve stakeholders in review sessions once or twice a week during this sprint to get their approval and to keep them in the loop.

Recently, I ran three 4 day long sprints with a client of mine where our schedule looked like this:

Design System Kick-off sprint schedule.

The principles and the draft styleguide created during the first week guided our work into a unified direction while allowing room for exploration and discovery. At the end of each day we reviewed, discussed, and spent time examining how different patterns started to emerge.

Finally, this initial sprint also allowed us to change our course multiple times where necessary. It made us immediately focus on the big picture like the full views and features, before we started defining our tokens, elements and patterns more during the third and the fourth week.

Defining color palette at Nosto.

Defining the parts

It’s during these sprints, when I also start introducing people to Vue Design System and teach them how to use GitHub if they aren’t familiar with it. We learn how to version and document everything from the start and use GitHub’s tools to track the progress on the system.

At the end of these sprints we’ll have a rough living documentation. The documentation includes our design principles, type scale, color guidelines and spacing usage with additional prototypes.

Vue Design System’s example styleguide.

In the past, I’ve been fortunate to work with clients who have had designers to code up their ideas into real living templates during these sprints, but it doesn’t have to work like that. My first recommendation is always to start with whatever tools you’re comfortable with to keep the initial pace fast.

Often, the output from the very first sprints might be just a set of principles, design specs, and tokens organized in a visual document or a Google Sheet. Other times, it might be a collection of components in a Sketch document. And that’s completely fine.

A Way Forward

We’ve now kicked-off the work and created a solid foundation to build upon. Now’s the time for your systems team to dive into using Vue Design System, start using a more structured workflow, having weekly design system sessions, and focus on delivering the 1.0 version.

Separate from this article, I have created comprehensive docs for the tool itself that are part of the GitHub repository. The docs shows you how to start building components and where the system’s pieces live. Some parts of it are under work, but I will be working on them to make sure that the docs cover most of the questions you might have, if not all.

If you want, you can follow the progress on Vue Design System on GitHub. I’ve also created a roadmap of features I’d like to bring in next and will be updating the feature set there.

To learn more about Vue Design System and to see the full list of features, see the new website and GitHub repo.

Workspace

2018-02-19T00:00:00Z

I’m happy. I’ve been succesfully running my design studio for the past 8 months and recently moved into a new office space. Since then I’ve been setting up the workspace to suit the way I want to work and create things. This dedicated quiet space gives me the luxury to focus and get much more done than I could get anywhere else before.

While I find myself constantly switching between different working modes like running a design systems workshop, working at client’s premises, or doing a remote meeting with a team in another city, I like having this personal space where I can come back to think and focus. A space for exploration and tinkering.

My workspace is a part of a bigger office, but with a dedicated room and a door. This is what my setup currently looks like (click for bigger photos):

Workspace with lots of wall to draw on

A mini device lab sitting on my desk:

Mini device lab

A tiny design systems book library:

Design Systems book library

I also have dedicated set of things that I take with me to workshops. It includes post-its, stickers, sharpies, and a timer in a small toolbox:

Post-its, stickers, sharpies, and a timer

Finally, I’ve been getting more and more back to photography recently and made a switch to Sony A7R II some time back. Behind the lenses is Loupedeck photo editing console:

Camera, lenses, and editing console

There’re a few things I’d still like to do here:

Firstly, I’d like to switch back to an adjustable desk at some point so that I can work both sitting and standing.

In addition, I’d like to bring here a lounge chair we have in our basement to help me get away from the computer when I run out of answers and need to think instead.

I’ve been also considering bringing a part of my record collection and a turntable with some speakers here, but I might just end up getting a HomePod. We’ll see.

If you have any questions about the setup ping me on Bluesky.

Full list

15" Macbook Pro, which is my main workhorse.
LG Ultrafine 5K screen for design work.
10 year old 24" Cinema Display that I use mostly for testing Webfont rendering on low res screens.
Vanamco Device Lab mobile device test stand.
Loupedeck photo editing console.
Sony A7R II camera with 25+85mm Zeiss Batis lenses.
Modulo modular whiteboards for sketching.
Vitra Eames plastic chair.
Vitra Toolbox for workshop gears.
Eames Prints on walls from House Industries.
Time Timer visual timer.

Design Principles of Nosto Design System

2017-11-12T00:00:00Z

Nosto hired me in 2017 to help reimagine what the company’s approach to designing and building digital products at scale should look like. I started this work by conducting a series of user research activities and workshops to reveal a lack of alignment and personal biases across business units, products and teams to understand how the design system could help them.

When we had a clear view of the challenges that we wanted to solve, it was a matter of creating fundamental principles for the system that they could follow as a team. These are the draft design principles that I helped to bring together:

1. Build for merchants

We put our merchants at the center of everything we do. Our success comes from their success and we focus on helping them serve their customers better. We aim to understand the challenges of different types of merchants and base our decisions on data and research whenever possible.

2. Make it actionable

We build tools that empower retailers to work with complex things in an easy way. Our focus is on delivering value by helping our customers reach their objectives, and all our design decisions strive to make that possible.

3. Aim for consistency

The experience of using Nosto should be cohesive, so we use consistent language, patterns, and components when building new things. We promote familiarity and approachability by investing in keeping things aligned.

4. Design with purpose

Our aim is to deliver an enjoyable experience to our merchants by making their lives easier and helping them succeed in their business. We believe that good design serves a purpose and we put in the effort in order to help our product teams move fast.

Work in Progress

2017-07-04T00:00:00Z

March, 2017. We were still living in the United States. It was a time of great anxiety for us. Just a couple weeks earlier I had been laid off from my previous job in California, Donald Trump had become the president, and we were suddenly living in this foreign country without valid Visas and no plans for the future whatsoever.

There we were, about to have a baby, not able to fly back to Europe anymore and trying to figure out what’s going to happen next. The company I used to work for got sold and our previous Visas couldn’t be transferred, which basically got us here. Just a week before all this started, I remember discussing with my wife how I could see us growing old in this country.

For a moment it felt like a bad dream in which we were fugitives living on enemy soil. In some ways, that dream felt real and vivid to us. I mean, it sounds frankly awkward when saying it out loud now, but back then so many things happened at once. I wasn’t even sure if it was legal for us to stay in the country after our Visas expired, so I tried to keep my mouth shut as well as I could. If anyone asked; It was good. It was all going so good.

Later on, things started slowly unraveling as our second child, Inga, was born in Redwood City, California. During the next few weeks—and ultimately months—we managed to get all the necessary paperwork done to get the whole family back to Europe safely. We applied for new Visas, got the birth certificates for the baby, social security number for her, US passport, and so on. It felt relieving. We were free to leave the country that once felt like a home to us.

At the same time, in the middle of everything, I had this crazy idea to start up my own design studio when we’re back in Europe. I had no savings, no clients, no real plans, nothing—heck, we didn’t even have a home anymore—just this quirky feeling inside of me and a few suitcases full of clothes.

But even then, I felt like I just had to do it. I didn’t want to go work for someone else. I wanted my freedom, and my wife kept on encouraging me to do it.

As strange as it might sound, one of the forces that kept pushing me forward was how much dirt happened to us in such a short period of time. After all that, I kind of felt like nothing’s gonna stop us anymore.

We’re gonna push forward with this feeling.
Everything’s gonna work out.

And it did.

This brings us back to the present day. We’re in Helsinki now. We still don’t have a permanent home, but at least we’ve found one and can start planning the move next month. My design studio is also up and running and I’ve found a bunch of great clients to work with. The next 5 months are more or less booked and I can’t wait to tell you about the projects I’m going to be working on.

I’m still accepting smaller consulting gigs for the fall and longer engagements from November forward, so if you’re interested, see the studio website and drop me a line via the contact form or email.

I’m most interested in helping startups and larger organizations to design, build and manage their Design Systems. During the past two years, I’ve been mainly working on large enterprise level systems and data visualization heavy projects with a few of the biggest Fortune 500 companies in San Francisco, CA.

In addition, I’m also interested in longer term, Style Guide driven design projects for the web. Instead of mocking up all the different variations of a product as static images in a tool like Sketch, I prefer to prototype these in the browser instead and go back and forth between design tools and code. You can read more about my process from the studio’s website.

If this sounds like something you might be interested in, get in touch and we’ll work it from there. ✌️

On Design Tools and Processes

2017-02-12T00:00:00Z

For the past year(s) I’ve been chasing for answers. Looking for new tools, thinking about design processes and figuring out what design really means to me. At times I’ve felt so disconnected with our processes that I’ve wondered if my career choice was right.

For a field rooted in the fine arts this period of change has been increasingly hard and is about to get even harder. We’ve moved away from designing static pages to creating digital systems of components, but we’ve done that mostly by using the same static design tools like Illustrator, Sketch, or even Figma. Tools that haven’t changed on a fundamental level in the past three decades.

Now, I think there’s something wrong with that picture. Our design products are becoming more and more dynamic, but our tools still treat them as blank canvases to paint on. Why?

New York City Transit Manual. Image: Standards Manual

A Trip Down Memory Lane

To start unwrapping this, I want to first take you back in time, approximately 30 years. You ready…?

Me, circa 1990 using Macintosh LC

Imagine you’ve just landed in the 80s. 1986 to be exact. You’re sitting in front of a Macintosh 128K with a black and white display. You’re about to start creating a marketing booklet for one of your clients, so you go ahead and launch an application called Aldus PageMaker. You know it’s going to be printed in A4, so you choose that as the page size.

Aldus Pagemaker running on Mac OS

Two years later, in 1988, you’ve upgraded your design tool of choice to the latest industry standard, QuarkXPress 1.0. It’s fundamentally more or less the same as the previous application you got used to, but you like Quark’s modern sleek toolkit.

QuarkXPress running on Mac OS

Fast forward 10 years, it’s 1998. You’re using Pagemaker 6.0. Your medium is print. It all makes so much sense.

Pagemaker 6.0

As your career path moves more and more towards web design, things are starting to get hairy. You start experimenting with various tools like CorelDraw…

…Freehand…

…Fireworks…

…Illustrator and Photoshop…

…Sketch…

…and even Figma.

But there’s this thought in the back of your head which makes you feel like you’ve been here before. All these years, all this time, and no progress at all, huh?

Your design tools still fundamentally work the same way as they did three decades ago. Either a fixed canvas and the concept of a page is forced by the tool, or the tool forces you into such mental mode.

99 Problems, But A Tool Ain’t One?

Let’s continue our exercise a little longer and imagine launching one of the more recent tools I shared. What’s the first thing you do? ------ Well, if you’re at all like me, you either choose your artboard size or draw an empty box to place your content in.

Empty box

As you continue, you might draw some more boxes.

More empty boxes

Eventually, you probably replace or fill these boxes with something more “meaningful.”

More meaningful boxes

Ok, that’s enough, you probably get my point by now.

Houston, We've Got a Problem

Firstly, the web doesn’t have a fixed canvas, but for some odd reason we keep on using tools and processes that force us into thinking about these fixed containers around our designs.

The control which designers know in the print medium is simply a limitation of the printed page. We should embrace the fact that the web doesn’t have these same constraints.

Android screen size fragmentation in 2012. Image: OpenSignal

Secondly, our tools falsely enforce the page metaphor even though we aren’t actually designing pages. Our canvas is infinite, but the tools we use force us into thinking about pages instead of systems of components or materials to build with.

Our canvas is infinite

Thirdly, our tools encourage form over content. It should be the other way around. Our decisions should start from the content out, not canvas in. Design in the absence of content is not design, it’s decoration like Jeffrey Zeldman once wrote.

Form over content

Finally, our tools completely discourage systematic thinking. They make it hard to pay attention on how different parts of a system influence one another within a whole.

SalesForce Lightning Design System

Past Reveals The Future

For a field rooted in the fine arts, this makes sense. Graphic design provided us a history spanning for centuries, so it’s natural that we borrowed our vocabulary and concepts like canvas and page from it. But when a new medium borrows from an existing one, some of it makes sense, but a lot generally doesn’t.

When John Allsopp wrote The Dao of Web Design in 2000, I’m not sure he knew how relevant the article would be almost two decades after it was written. Even with the introduction of responsive design and new component based workflows, I feel like we’re still repeating the same mistakes.

In 1928, a German writer called Walter Benjamin predicted that writers would soon start to compose their work with a typewriter, instead of a pen. He wrote something along the lines:

“By writing directly into a mechanical form rather than a manuscript, the writer would be working closer to the nature of the multiplied result, and through an increased awareness and gradual mastery of the form’s new limitations and possibilities the writing itself would evolve.”

— Walter Benjamin

I find Walter’s century-old thinking fascinating. I feel like it’s close to what we should be doing on the web today as well. By working closer to the nature of the result our work itself evolves. We become more aware of the unknowns and how different parts of a system influence one another.

Walter Benjamin. Image: The American Reader

Walter’s thoughts on increased awareness take me back to the original questions I presented at the beginning of this article:

“What design really means to me?
What kind of tools and processes will we use in the future?”

Turns out the answer to both of these questions has been in front of me all this time, but I’ve tried too hard to convince myself that I should be using design tools to do design. Even when they actually seem to be limiting my capabilities as a designer.

Contemporary Design Process

Changing our ways of thinking and doing isn’t easy. Sometimes it’s necessary though, and the first step on this journey is to let go. Let go of our imaginary feel of control. Forget the boundaries presented by our tools and ways of thinking. Break out of the silos we’ve created.

As our design products are becoming more dynamic, it makes less and less sense to separate the design and the development disciplines. Instead of working in silos, I foresee a future where the terms designer and developer are interchangeable. A future where we are comfortable sketching our ideas in code or working closely with developers to achieve that.

Design is not just what it looks like and feels like. Design is how it works and sketching in code enables us to focus on that. Moving quicker to code helps us to put content over form, embrace the fluid nature of the web, and focus on systems of components instead of pages. It also helps us to find user experience issues that previously only became visible once the implementation started.

AirBnB’s React renderer for Sketch App that treats Sketch as a pure render function and keeps their code based design system the source of truth. Image: Jon Gold

This transition doesn’t have to be all or nothing, though. We can start taking baby steps towards better workflows today. Instead of for example trying to mockup all the different variations as static images in Sketch, we should probably prototype more complex features in the browser. That prototype can eventually be turned into a simple code based design system that outputs infinite variations for us.

When moving further, we should also introduce new processes and start utilizing tools such as style guides, pattern libraries, and modular code based designs systems that encourage conversation and collaboration not only by developers, but by designers and shareholders as well. This will eventually help each discipline to better understand the full breadth of our work from many perspectives.

In 10 years, I imagine us looking back at the period we live in right now with the same sense of disbelief that some of us remember from the past. History has a tendency to repeat itself, and we need to stop repeating the same mistakes over and over.

Let’s get rid of

~~Fixed canvas thinking~~
~~The page metaphor~~
~~Form over content~~
~~Tools that discourage systematic thinking~~
~~Designers and developers working separately~~
~~Designers working only on static mockups~~
~~Showing clients static comps and asking for sign-off~~

References And Links

^[1] First and foremost, I want to thank Frank Chimero for his talk called The Web’s Grain. It’s an amazing resource and gave me the idea for the box and canvas illustrations.

^[2] Secondly, I want to thank Rune Madsen for his article titled On Meta-Design and Algorithmic Design Systems. It has been a tremendous source of inspiration for me over the past couple of years.

^[3] Finally, thanks to Jon Gold for his exploration on Declarative Design Tools. It gave me the enthusiasm to write this article.

More resources and further reading in random order:

On Meta-Design and Algorithmic Design Systems by Rune Madsen
The Web’s Grain by Frank Chimero
Thought as a Technology by Michael Nielsen
A Dao of Web Design by John Allsopp
Create Design Systems, Not Pages by Brad Frost
Design Machines by Travis Gertz
Programming Design Systems by Rune Madsen
Walls Come Tumbling Down by Andy Clarke
Design is How it Works by iA
Taking The Robots To Design School by Jon Gold
Declarative Design Tools by Jon Gold
A Visual Lexicon by Robin Rendle

The Future of Web Fonts

2016-10-09T00:00:00Z

We love typefaces. They give our sites and applications personalized feel. They convey the information and tell a story. They establish information hierarchy. But they’re also full of problems. Typefaces make our websites slow. They produce FOUT — or FOIT if you prefer. They render in unpredictable ways. Why should we live with inflexible type that doesn’t scale, when the core nature of our medium is fluid and responsive?

TLDR; We don’t have to. Three weeks ago, Apple, Google, Microsoft and Adobe introduced a new font format called Variable Fonts. In a gist, Variable Fonts provide the flexibility of multiple fonts in a single file that can adapt fluidly to any type of screen or device. One font, near infinite variations.

When using web fonts today, you have to load separate font files for each style and weight, resulting in long download times and FOUT/FOIT. With Variable Fonts, we can request just one highly optimized file including all the weights and styles of a typeface. This is a tremendous shift that I see leading to richer, more responsive typographic experiences and vastly expanding the possibilities for web typography.

Image credit: Erik van Blokland

The concept of grades also becomes closer to reality. Having grades with separate font files always seemed a bit impractical, but with Variable Fonts things will change. With the new format we can start doing typographic fine adjustments based on not just the screen size and density, but also on the text rasterizer and antialiasing engine being used — all while not having to worry about the page weight.

Imagine also tailoring the width and height of your font’s characters for better readability across different screens. Imagine making your font’s x-height just a tad bigger at small sizes for greater legibility.

All this and much more will be possible soon.

Image credit: Microsoft

Recently, CSS Working Group added the first draft of the Variable Fonts Specification to CSS Fonts Level 4 spec. See below what the usage currently looks like. If you have improvement ideas, I encourage you to create a GitHub issue.

Point positions for a non-default instance, image credit: Microsoft

WebKit has also started implementing the new OpenType 1.8 Specification that Variable Fonts are part of, and you can see the progress in the latest Safari nightly build. @litherum has even put together a demo showing Variable Fonts in action.

Animated example by @litherium. The bug with glyph advances has been fixed, but the fix hasn’t yet landed WebKit Nightly, thus you see the glyphs overlapping.

Usage Examples

Semibold weight:

<div style="font-weight: 632;">
  The Quick Brown Fox
</div>

Semicondensed weight:

<div style='font-stretch: 83.7%;'>
  The Quick Brown Fox
</div>

Using the “ital” axis:

<div style="font-style: italic;">
  The Quick Brown Fox
</div>

Animating weight and width axes:

<style>
  @keyframes zoom {
    from { font-variation-settings: "wght" 400, "wdth" 85 }
    to { font-variation-settings: "wght" 800, "wdth" 105 }
  }
</style>

<div style="animation-duration: 3s; animation-name: zoom;">
  The Quick Brown Fox
</div>

Variable Font as a web font:

<style>
@font-face {
  font-family: "VariableFont";
  src: url("VariableFont.otf");
}
</style>

<div style="font-family: 'VariableFont';">
  The Quick Brown Fox
</div>

The future of digital typography looks intriguing. It’s not all figured out yet, but I’m excited to see where this journey leads us.

Typography for User Interfaces

2016-06-21T00:00:00Z

Back in 2004, when I had just started my career, sIFR was the hottest thing out there. It was developed by Shaun Inman and it embedded custom fonts in a small Flash movie, which could be utilized with a little bit of JavaScript and CSS. At the time, it was basically the only way to use custom fonts in browsers like Firefox or Safari. The fact that this technique relied on Flash soon made it obsolete though, with the release of the iPhone in 2007.

In 2008, browsers started eventually supporting the new CSS3 @font-face rule. It had already been a part of the CSS spec in 1998, but later got pulled out of it. I remember the excitement when I managed to convince one of my clients to utilize the new @font-face and rely on progressive enhancement to deliver an enhanced experience for browsers which already supported this feature.

Since my early days in the industry, I’ve grown to love type and all the little nuances that go into setting it. In this article, I want to share some of the fundamentals that I’ve learned, and hopefully help you get better at setting type for user interfaces.

“Our interfaces are written, text being the interface, and typography being our main discipline.”

— Ariel Salminen

The first GUIs

While the history of typography dates back about five thousand years, we’ve had graphical user interfaces for mere four decades. One of the key turning points was in 1973, when Xerox introduced Alto, which in essence created the foundation for today’s graphical UIs. Alto was born a decade before any other GUI hit the mass market, and was seen as the future of computing.

This early development for Alto evolved to Xerox Star in the 80s and became the first commercial operating system with GUI.

Although neither Alto nor Star never really took off the ground, they greatly influenced the future development at Apple and Microsoft with their revolutionary mouse-driven GUI. A couple years later, in 1984, Steve Jobs introduced the first Mac OS.

The release of the Macintosh meant custom typography suddenly becoming available to the masses for the first time ever. The original Mac came pre-installed with many iconic typefaces, and over the next few years, multiple type foundries started releasing more and more digital versions of their popular typefaces.

When inspecting these early graphical user interfaces closer, we realize that most of their elements are written language. These GUIs are essentially pure text — collections of singular words displayed in isolation from one another.

We can make a similar observation by inspecting almost any modern interface too. Our interfaces are written, text being the interface, and typography being our main discipline.

Text is interface

Every word and letter in an interface matters. Good writing is good design. Text is ultimately interface, and it’s us, the designers, who are the copywriters shaping this information.

Take a look at the example below and imagine the elements taken apart and put down on a table in front of you. Observe what’s left. A collection of singular words, two images and few icons.

Our work is not about putting random things on screen and making them look pretty, but instead starting from the most important parts, the copy and the content, and figuring other details up from there. That’s where the core of our craft lies.

The clarity of letterforms plays a key role too. It might not seem to matter much at first, especially if our brain needs to pause only for a fraction of a second to decipher a word shape. But when we multiply this across numerous instances and letter combinations, our typographic choices become much more apparent.

Of course, there are more nuances to interface design; things like balance, positioning, hierarchy and structure, but good copywriting and typography takes us 95% there.

“A great designer knows how to work with text not just as content, he treats text as a user interface.”

– Oliver Reichenstein

How we read

If the letters that we put on screens are so important, then we should spend some time studying how we read and how that affects our design decisions.

One of the key findings that I had back when I was reading Billy Whited’s article on Setting Type for User Interfaces, is that the efficiency with which we read is a function of the amount of text available to us as we do so. This means that an isolated word that has fewer than 20 characters will be read more slowly than a word that forms a part of a longer sentence.

This results from the fact that our eyes don’t move smoothly across the text when we read longer sentences. Instead, they make discrete jumps between words, which are called saccades.

Saccades improve our reading capabilities and make it possible for us to skip shorter functional words completely. This is a key factor to keep in mind since our interfaces tend to have mostly isolated words. In essence, it means that we cannot rely on the effects of saccades at all.

Eventually, knowing that the identification of individual letters plays the most critical part in the reading process, it’s becoming apparent why our choice of typeface is extremely important.

In the past, many thought we recognize words by their so called Bouma shape, or the outline that a word creates. In later studies this was proven to be somewhat wrong, and the readability and legibility of a given typeface should not be anymore evaluated only by its ability to generate a good bouma shape. Instead, we need to pay more attention to the letterforms themselves.

What makes letters legible?

At first, it might seem hard or just plain impossible to answer this question. Since reading is a matter of habit, we read best, what we read most. How could we possibly determine what features make letters legible? To start gaining an understanding, we need to first break sentences into words, words into letters, and letters into smaller parts and start looking the finer details.

In 2008, Department of Psychology at the University of Victoria did empirical tests to reveal which areas of lowercase and uppercase Latin letters are most efficient for reading.

The study revealed a few interesting things. First of all, it revealed that line terminations are the most important features for letter identification.

The image above shows which areas we pay most attention to when recognizing letters. These areas of a typeface should be designed both in a generic and familiar way and also in a way that stresses letter differentiation.

In 2010, there was also another study, by Sofie Beier and Kevin Larson, that focused testing letter variations of frequently misrecognized letters.

This study found that some variations were more legible than others, despite the letters within a font having similar size, weight and personality. The results showed that narrow letters benefit from being widened, and that x-height characters benefit from using more of the ascending and descending area.

We can gain more understanding about the legibility of a given typeface by using a tool I built for a recent project. Legibility App allows you to simulate different (often harsh) viewing conditions by applying a level of filters on top of the text — like blur, overglow and pixelation. The app is in beta, and for the time being, works in Chrome, Opera and Safari.

What to look for in a UI typeface?

Understanding how we read and what features make letters legible gives us a better overall view on what we should look for when choosing a UI typeface. I’ve gathered 10 key things below.

1. Legibility

Legibility is the number one factor to consider. Letterforms need to be clear and recognizable. Letters with clear distinction in their forms perform better as user interface elements.^[5] Many sans serif typefaces, including Helvetica, have indistinguishable capital I and lowercase l, making these particular fonts bad choices for interfaces.

Source Sans Pro on the left compared to Helvetica on the right. It’s almost impossible to differentiate the first 3 letters on Helvetica. Source Sans Pro on the other hand performs much better. Some people would also agree that Helvetica sucks for any type of UI work since it wasn’t really developed for use on screen displays.

“Helvetica sucks. It really wasn’t designed for small sizes on screens. Words like ‘milliliter’ can be very difficult to decipher.”

– Erik Spiekermann

When Apple “momentarily” switched to using Helvetica as their main interface typeface, it caused real usability and readability issues for certain users. Eventually, this was one of the reasons that led Apple to design the typeface we now know as San Francisco. This new typeface is designed specifically for screens and it has higher x-height than Helvetica, looser spacing, and its letters are easier to distinguish from one another.

Image credit: Thomas Byttebier

2. Modesty

An ideal UI typeface doesn’t scream for attention, but rather goes unnoticed. The typeface you choose should stay out of the users’ way when they try to complete their task, by honoring the content in a way that doesn’t add to the users’ cognitive load.

3. Flexibility

A UI typeface needs to be flexible. We are designing experiences for medium(s), where it’s not possible to control our user’s abilities, context, browser, screen size, connection speed, or even the input method used.

The typeface we choose should support these vast contexts and work well in different sizes, devices, and on a small screen in particular. Sans serifs that are made to work at small sizes on low resolution are preferred.^[5]

4. Large x-height

X-height means the height of a lowercase “x”. You want to look out for a typeface with large x-height since it’s in general easier to read and renders better in small sizes. Don’t go too far though, since too large x-height makes the letters n and h difficult to distinguish.

5. Wide proportions

Proportions refer to the width of a character in relation to its height. You want to look out for a typeface with wide proportions since it helps with legibility and is easier to read in small sizes on a screen.

Image credit: Adobe Acumin

6. Loose letter spacing

The space around the letters is as important as the space within them. Letters that are too close to each other can be hard to read. A good UI typeface should have enough breathing room in-between letters, and even spacing to establish a steady rhythm.

On the other hand, if there’s too much spacing, the integrity of the word breaks. A good rule of thumb is that letter space should be slightly smaller than the counter space inside the letterforms.

“A good rule of thumb is that letter space should be slightly smaller than the counter space inside the letterforms.”

— Ariel Salminen

7. Low stroke contrast

Good UI typefaces have low stroke contrast. Typefaces with high-contrast might look good at larger sizes, but at small sizes on a screen thin strokes easily disappear. On the other end of the spectrum, we have typefaces like Arial and Helvetica, that can have too little contrast between letter shapes, making the letters indistinguishable from each other.

It’s all about finding a balance between the two. Imagine the example below as a horizontal scale. You want to aim for something that is more towards the example on the right side.

8. OpenType features

Making sure that the typeface you choose supports OpenType features is important, since it provides much more flexibility for us. It’s often also an indicator that there’s a good support for different languages and special characters.

For me, one of the most useful OpenType Features has been tabular figures, which are numerals that share a common width. You might want to use them for example when working with timers or counters, or when you have a table displaying information like IP numbers.

Image credit: Fontblog

9. Fallback fonts

Below is an experience that you’re all probably familiar with. What’s happening here is that the web fonts are blocking the actual content from showing up before they’re all fully loaded.

Image credit: Filament Group

This can be easily fixed by loading the fonts in a non-blocking manner, which drastically cuts the loading time for the content. The drawback is that we need to define fallback fonts from the default system fonts, which show while our custom fonts are loading.

Image credit: Filament Group

10. Hinting

Hinting is a process where fonts are adjusted for maximum readability on computer monitors. Hinting tries to make vector curves render nicely to a grid of pixels by providing a set of guidelines for different sizes. At low screen resolutions hinting is critical for producing clear, legible text.

Windows is notorious for its bad font rendering without hinting, so make sure to always test on a Windows device that has low DPI monitor connected to it. This helps you to ensure that the letter forms stay legible.

Image credit: Typotheque

The Future(s)

It’s been a relatively short ride for us, and I expect to see a lot of progress in terms of how type behaves on the web, how our typographic tools mature, how font formats keep evolving, and how we’ll be utilizing type in the (near) future.

I imagine we’ll start seeing much more progressively enhanced experiences where the text itself is fundamentally more important than our suggestions about how it should be typeset.^[6] It’s really how things have always worked on the web, but we’re only now starting to take this issue seriously.

For ideal typography, we also have to know as much as possible about each user’s reading environment. This may seem obvious, but it really isn’t.^[7] In the future though, I imagine typefaces becoming more aware of their surroundings and starting to respond to a number of factors like viewport, resolution, type rendering engine used, ambient light, screen brightness and even the viewing distance.

I also predict that fonts’ legibility adjustments will be eventually linked to OS’s accessibility options so that typefaces can automatically start adapting to different user needs.

Overall, I see the future for UI typography being all about sensors and font formats that can respond to data acquired from these sensors, and eventually also new typographic tools that have contextual awareness which integrates more intelligent algorithms to our workflows.

All this is needed so that we, and the typefaces that we work with, can better respond to all these contexts we have to deal with.

Image credit: Luke Wroblewski

To ease our work…

Image credit: Samsung GearVR

…make our interfaces faster…

Image credit: MozVR

…more accessible…

Image credit: Callan & Co

…and eventually more legible and productive too…

Image credit: Microsoft Hololens

…because ultimately, good typography enables productivity for everyone. It could even save your life.

This article is loosely based on a talk that I did in one of our internal design events in San Francisco, CA. See the slide deck (browse with arrow keys).

View slidedeck

Relocating to San Francisco, CA

2015-12-18T00:00:00Z

I’m terribly excited to tell that we’re moving to San Francisco Bay Area in the beginning of 2016! I’m joining a new company, Idean, as a Senior Interaction Designer and Iisa will be starting preschool there, which makes this a tremendous change for the whole family. All of this is something we’ve been planning for a while already, so we’re thrilled that it’s finally happening.

As of today, we’ve packed everything we have—from the 12" record collection to Iisa’s toys—into a shipping container and it’s already in the harbor waiting to get shipped to the United States. We’re still staying in Finland for the Christmas, seeing relatives and enjoying some quiet time, before flying to San Francisco in January.

It’s been interesting few years at Adtile, and I’m grateful for all the things I’ve learned, but it’s time to move on towards new adventures.

Looking forward to meeting Karl the Fog.

The 7th Edition of Arielsalminen.com

2015-11-23T00:00:00Z

I designed the 6th edition of this website almost 5 years ago, which is an eternity by today’s standards. The previous version was one of the first responsive websites out there that was built mobile first from start to finish. Everything was also done progressive enhancement in mind, which made it last well throughout the years.

But as with many personal projects, there eventually came a point when the content started becoming obsolete, type didn’t work anymore like I wanted it to, and even updating the website became so terrible experience that I just stopped doing it.

It was time to rethink. After some pondering, I came up with these 6 goals for the new version:

Build a design system.
Focus on the content, typography and readability.
Better performance and faster loading.
Switch to HTTPS and provide an offline experience.
Ditch PHP and switch to a static site generator.
Move hosting to Amazon S3 and use CloudFront as CDN.

Challenges

Maintaining a website with a 5 years old CMS can be a challenge itself, but moving all that cruft to a completely new platform can be even more challenging. The previous version had also hundreds of subpages and the image resources alone took almost 1 gigabyte of space on the server. The need to convert all that content to a new format was the biggest reason why I didn’t even attempt to do this any earlier.

Originally, I thought I’d write about the workflow behind the redesign, but as it turns out, my process was somewhat unusual and it wouldn’t probably morph into a nice, readable article, just yet.

Basically, I went with gut feeling with pretty much everything you see here. There’s no grid, no fancy ratios used, no typographic scale, and no magic numbers that the layout, type or colors would be based on.

Shocked? Well, that’s really how it all started. But the intriguing part is that this ‘chaotic’ way of working, that included no proper workflow whatsoever, eventually formed a living design system, a tiny tool for content sketches, and even a grid for both layout and baseline.

Now, I won’t be encouraging anyone to necessarily start working this way. Grids, typographic scales and ratios can be very helpful tools, and I tend to use them when in hurry. Lately, however, I’ve wanted to learn to trust my own instincts more and let go of the imaginary feeling of control we’ve created for ourselves.

Results

I quite like the simplicity here. Not just the layout and structure, but also how quick and simple this is to update. I’m basically doing all the updates now using Markdown format in a plain old text editor, and then deploying the changes to Amazon S3 with a beta version of Upstatic (btw, I did the website!).

There’s also the living style guide, which I’m happy about, as it helps me to more easily define a common visual language for all the individual components.

There’s no commenting, but if you’d like to leave feedback, please tweet to me instead. If you’re looking for the old versions of this website they are still accessible too, via v1.arielsalminen.com, v2.arielsalminen.com, v3.arielsalminen.com, v4.arielsalminen.com, v5.arielsalminen.com, v6.arielsalminen.com, v7.arielsalminen.com.

The Iconic Work of Reid Miles

2015-11-14T00:00:00Z

Reid Miles was an American modernist designer, a genius of his time, best known for his work for Blue Note Records through the 1950’s and 60’s. During this period he designed almost 500 record covers for the label. This article is a tribute to Miles, who’s work continues to inspire me and many others.

Reid Miles in the 1970s. Image credit: Blue Note Records.

The Backstory

It’s the summer of 1998 — a long wait has finally come to an end. After saving for months I’ve acquired my first turntable. It’s Technics SL-1210 MK II and I am carrying it uphill towards home that is nearly two and a half miles further. The package weighs 26 pounds, not an easy task for the scrawny teenager I was back then.

I remember vividly how I after arriving tear apart the package, took out all the gleaming parts, put them together, and the great enthusiasm and eagerness I felt inside. I also remember how I connected the turntable to the speakers and played the first vinyls I had picked up months earlier.

There I was, eyes closed, letting the unison of the brasses sink into my brain.

Seventeen years later, that same turntable still looks and works like a brand new thing. It was and still is an amazingly well built piece. I feel the same about the work of Reid Miles. He was a genius, ahead of his time, and the way he treated the typography as visual elements that can be broken apart and form something new still feels fresh.^[1]

I didn’t know it back then, but the day I bought the turntable and started collecting vinyls shaped my future career as a designer. Slowly through the years the jazz music and artworks of these 12" records became the main source of inspiration for me.

Miles’ Early Days

Reid Miles was born in Chicago on the 4th of July 1927, American Independence Day, making him only twelve years old when Blue Note was founded. When the Stock Market crashed in 1929, Miles’ parents divorced and he moved with his mother and younger sister to Long Beach, California. After high school Miles joined the Navy and, following his discharge, moved back to Los Angeles to enrol at Chouinard Art Institute.

Chouinard Art Institute. Image credit: California Institute of the Arts.

According to Miles himself, he didn’t enrol because of some lofty ambitions towards art. He told in a series of interviews that he did it because of a girl who he was dating at the time. Miles had also just returned from World War II and could use the G.I. Bill education benefits.

To him, it felt like a better idea to go to an easy art school than somewhere else. The dating didn’t work out, — but three months later, things just clicked and Miles knew what he wanted to do.^[2]

After finishing his studies at the Chouinard Art Institute, Miles headed towards New York to look for a job with the biggest portfolio he could possibly find.

“If the portfolio didn’t fit on the desk, I wasn’t talking to the right person. You need a fierce competition to do good work and when I started out, I would be competing against 11 other people for a job as an assistant to an art director at a little agency.”

John Hermansader, an American painter and a graphic designer, gave Miles his first job in New York. One of Hermansader’s clients at the time was Blue Note Records, which eventually led to Miles’ involvement too.^[2]

Photograph by Francis Wolff on the left and the final cover design by Reid Miles on the right. Image credit: Blue Note Records.

Blue Notes

In 1951, when Blue Note began releasing 10" records, Hermansader — who later hired Miles — was one of their first designers. Many don’t know that Hermansader, along with Paul Bacon, were the ones who did the groundwork for Blue Note’s design style, which Miles then continued to develop further with his own unique twist.

Late in 1955, Blue Note made the change to 12" record format. It was around this same time when the company hired Reid Miles as their Art Director and asked him to adapt their existing cover concepts to the new, larger format.

Miles started his work from Blue Note BLP-1509 by Milt Jackson and The Thelonious Monk Quintet, and went on, designing almost 500 covers during a period of 15 years.

Blue Note BLP-1509 record cover.

In the Fifties, Miles often worked in close collaboration with Andy Warhol, who helped him turn his concept designs to illustrations. One of the most famous results of this joint effort between the two is the cover of The Congregation by Johnny Griffin, which has reached an iconic status in the history of jazz. Later on Miles’ and Warhol’s relationship even led to him posing nude for one of Andy’s famous portraits.^[5]

The cover of “The Congregation” album.

Although Warhol and artists such as Harold Feinstein were also working for Blue Note, it wasn’t until Reid Miles took over as the Art Director that the label could match the design style with its legendary ‘Blue Note sound.’

Whether this meant Miles’ creative use of black and white photographs or the way he treated the typography, “Miles made the cover sound like it knew what it lay in store for the listener” writes Felix Cromey in The Cover Art of Blue Note Records.^[3]

“Fifty Bucks an album…they loved it, thought it was modern, they thought it went with the music…one or two colors to work with at that time and some outrageous graphics!”

Reid Miles’ association with the label ended around 1967 when Alfred Lion, one of the founders of Blue Note, retired. Miles later returned permanently to Los Angeles, where he became famous for being paid $1,000,000/year to produce Coca-Cola ads that mimicked Norman Rockwell paintings. Quite a contrast to the fifty bucks an album that he was paid by Blue Note.

Miles continued working in his Hollywood studio for various clients until a massive coronary in 1993, which lead to his somewhat dramatic death.^[4]

Co-founder of Blue Note Records Alfred Lion and photographer Francis Wolff. Image credit: Francis Wolff / Blue Note Records.

Conclusion

During the Fifties, when the design industry was in flux, Reid Miles pushed forward the way the typography is treated with his bold, playful designs, creative use of typefaces, and his distinct preference for contrast and asymmetry.

Personally, I’d like to think, that Reid Miles did the same to modern typography, as Charles and Ray Eames did to modern architecture and furniture.

“I think typography in the early Fifties was in a renaissance period anyway. It happened especially on album covers because they were not so restrictive as advertising.”

— Reid Miles

Blue Note reunion concert in Town Hall, New York, February 22, 1985. From left to right: president and CEO of the Blue Note Label Group Bruce Lundvall, co-foudner of Blue Note Records Alfred Lion, designer Reid Miles, recording engineer Rudy Van Gelder and producer Michael Cuscuna. Image credit: Blue Note Records.

Designs

A selection of Reid Miles’ designs from the 1950’s and 60’s. Most of these covers Miles designed for Blue Note, but there are few others included as well. Let the work speak for itself.

References

The Many Faces of The Web

2015-04-27T00:00:00Z

During the winter 2014, me and my family rented an apartment from San Diego, CA for few months through my work. While staying there, we had an AT&T hotspot device that provided the network connection. For us, relying on this device, meant constant drops of connection, network latency like we’ve never seen before, and websites that were completely broken because JavaScript wasn’t loading at all. A part of this can be explained by the poor reception at the location where we were staying, but overall, the whole experience put me thinking.

All these contexts, where our websites are viewed in, vary so wildly that we have to start paying more attention to how we design and build. The web is fragile and the situation isn’t going to change any time soon.

Stop breaking the web

There’s this thought in my head that, like a broken record, keeps repeating to me and everyone around: “Stop breaking the web.” And if I think about it more, I realize it’s related to this fundamental idea that I have, which makes me want to push the web forward and make it a better place. Because isn’t that what we, the designers and developers of this medium, should strive for and be proud of?

On a bigger scale, I mean things like making our websites accessible to everyone. Making them work with different input methods like touch, mouse, keyboard or voice. Making them load and perform fast. Providing everyone access to this vast network of connected things. And if we don’t strive for all of this, what’s the point of working on the web? To me, this is what the web is and has always been about. Making people’s lives better. Making information accessible to everyone—wherever, whenever and as fast as possible.

The thing about the web that still fascinates me after all these years, is how universally accessible it is. How you can publish something out there and how someone on the other side of this planet can just pick up a connected device and access that content. Even more fascinating, use assistive technology that reads the content for the user. But—it’s also so easy to break this connection if we don’t pay attention.

How we build

I feel like there’s a growing trend in our industry to forget accessibility. To not pay attention. Forget progressively enhanced experiences. Forget the universality of the medium that we are working on. Forget that not everyone on this planet has the latest and greatest devices or the connection speeds that we, ourself, might have.

This worries me and puts me thinking.

Instead of coming up with all these new tools and JavaScript frameworks, shouldn’t we try to emphasize the importance of learning the underlying fundamentals of the web? Teach those who are just stepping to this medium and starting their careers. By not making our stack more and more complex, but by telling about the best practices that should guide our work and the importance of basic things.

Why accessibility is important and why does it make a difference. Why is progressive enhancement important. Why everyone doesn’t have to get the same experience and why it isn’t even a sane goal. Why do we need performance budgets. Why it’s important to make websites work even when JavaScript doesn’t load. Why we can’t rely on a browser feature to be available. Why we need to focus on features and constraints rather than browsers and devices. And so on and so on.

Embrace the medium

The web is more than just a set of protocols and agreements—HTTP, URLs, HTML. It’s also built with a set of principles that—much like the principles underlying the internet itself—are founded on ideas of universality and accessibility (as Jeremy Keith states it).

We are designing and building experiences for a medium, where it’s not possible to control our user’s age, abilities, context, device, browser, screen size, operating system, connection speed, or even the input method they are using. The contexts, where our websites will be eventually viewed in, are a mix of variables we can’t control.

Universality is in the core of the World Wide Web, so we should embrace it and build websites that are available to, and accessible by, everyone. We are designing and building for the many faces of the web.

Dear Web,
I want to make you a better place.

Interview With Workspiration

2015-04-13T00:00:00Z

I am Ariel Salminen, a designer and developer living in Helsinki, Finland. I have worked in the web industry for over a decade and have designed websites, applications, and large systems for start-ups and companies of all sizes. My core belief is that all content on the web should be accessible to anyone using any kind of device to access the internet.

I am currently working as a Lead Frontend Designer at Adtile Technologies (San Diego based start-up). I am also an author at Smashing Magazine and the founder of Helsinki Device Lab, which was established to help web designers and developers to be able to test their work on the ever-growing range of mobile devices.

I have created popular open source libraries such as Responsive Nav, Responsive Slides, Tiny Nav, Remote Preview and Molten Leading. These tools are being used by companies like AT&T, Converse, the jQuery Foundation, Microsoft, Ted, U.S. Government and Zynga.

How did you get started in web design?

I started off by studying traditional print design in two different schools. I have always been more interested about the web, but at the time I was studying (early 00’s) there wasn’t much to choose from if you wanted to learn web design.

Basically, I have learned most of what I know now by following people on the web; design sites, blogs and studying other people’s markup and CSS. One of the sites that made a big influence on me on my early days was A List Apart in 2001 and CSS Zen Garden in 2003.

They both encouraged people to forget table-based layouts and adopt this new technique that used semantic markup and CSS layouts. I was just graduated and starting my career as a freelance designer and the new way of doing things, separating the structure from the presentation, just made sense to me. It still does of course.

What hardware and software do you use for your work?

I have a 13" Retina Macbook Pro hooked up to a Cinema Display, but recently I have found myself working more and more just on the laptop because of the higher PPI screen.

In addition to pen and paper, the tools I use most are Atom editor, iA Writer, Typecast and Browser’s built-in developer tools. I also spend a lot of time using Illustrator and Photoshop, but I am trying to move more towards Sketch.

What is your ideal work environment?

I love working from home. That’s, for me, the most creative and productive environment in the whole world. We live right next to the Baltic Sea with windows facing the water, so it’s nice to take breaks and just stare outside.

I would recommend everyone designing websites to read Nicely Said: Writing for the Web with Style and Purpose by Nicole Fenton and Kate Kiefer Lee.

Who are the creatives you admire most?

I admire the work of Reid Miles. He was an American modernist designer, best known for his iconic work for Blue Note Records through the 1950’s and 60’s.

Dashes in Web Typography

2015-03-09T00:00:00Z

This is an experiment I did months ago, but eventually never ended up posting it here. I had already forgotten the whole thing until it few weeks ago suddenly started popping up on my Twitter and Facebook timelines via other people. It’s a simple one pager you can use for example as a cheatsheet for various dashes.

View demo

Molten Leading

2014-06-27T00:00:00Z

Manually adjusting line-height with media queries for optimum readability across vast number of screen sizes can be hard. What makes it even harder, is, that instead of the screen width, the line-height should be relative to its container’s width and its font settings in order to achieve proper readability and appropriate spacing.

Thanks to @Wilto, there has been a jQuery plugin called “Molten Leading” around for quite some time already which makes it possible to automate this process and define a minimum width at which the adjustment starts, a maximum element width where it stops, and a minimum and maximum line-height to adjust through.

I wanted to use something similar in one of my latest projects, but I didn’t want to introduce new dependencies to external JavaScript libraries just because of this one feature. I also wanted something that would have a bit better performance, so I decided to write a custom version of Molten Leading without any library dependencies. All this is now available on GitHub too, so take a look and give it a spin.

Features

Automatically adjust line-height based on element width.
Works in all browsers, including IE6 and up.
Uses requestAnimationFrame for the best possible performance.
Free to use in both commercial and non-commercial projects.
Doesn’t require external JavaScript libraries.
Supports px, em and rem CSS units.
Weighs only 1.17kb minified and Gzip’ed.
Supports multiple instances.

Download

Molten Leading on GitHub→

Interview With .Net Magazine

2014-05-01T00:00:00Z

I was recently interviewed by .Net Magazine (in issue 254) about how web experts manage cross-platform testing. There’s a quote from me in the article that I think is interesting:

“I believe in testing on real devices. Software simulators can be useful, but in the end they can only do that: simulate the experience. At home, I use a setup with six physical devices running continuously when I'm designing something. I also tend to visit the nearby Open Device Lab a few times to make sure that everything works on a wider range of devices.”

Fixed Single Page Navigation

2014-03-03T00:00:00Z

Today, we are open sourcing the JavaScript code and the assets we used to build the responsive navigation on Adtile’s website. The code and examples are hosted on GitHub and can be found from here. There’s a live example too, under Adtile’s site, give it a spin. Read more about the features provided from the link below.

A Dive Into Plain JavaScript

2014-01-16T00:00:00Z

While I’ve worked over a decade building various web services and systems, it has only been the past 3 years that I’ve started learning more on how to work with plain JavaScript, instead of using jQuery or similar libraries as the starting point when it comes to interactivity. The fact that I’m learning a dozen new things every day now, has made working on Adtile’s JavaScript SDK feel more like building an open source project than actual work, and I have to say I like that a lot.

Today, I’m going to share some of the basic things I’ve learned during the past years, which will hopefully also help you to dive into the world of plain JavaScript, making it easier to decide whether or not you will need jQuery in your next project.

Progressive Enhancement

While libraries like jQuery help to forget most of the browser inconsistencies, you really become familiar with them once you start using plain JavaScript for everything. To avoid writing JavaScript that’s full of browser hacks and code which only solves browser compatibility issues, I recommend building a progressively enhanced experience using feature detection to only target the more modern browsers. This doesn’t mean that browsers like IE7 don’t see anything at all, it just means that they get a more basic experience without JavaScript enhancements.

Here’s How We’re Doing It

We have a separate JavaScript partial which has all the feature tests. The actual list of tests is often much longer, but let’s get back to this a bit later. To rule out some of the older browsers we use these two tests:

var test = {
  addEventListener : !!window.addEventListener,
  querySelectorAll : !!document.querySelectorAll,
};

Then, in the main application partial, we detect if these features are supported by using this simple if statement below. If they aren’t supported, the browser won’t execute any of this code:

if (test.addEventListener && test.querySelectorAll) {
  this.init();
}

These two tests make sure that we have a native way of using CSS selectors in our JavaScript (querySelectorAll), a way to easily add and remove events (addEventListener) and also that the browser’s standards support is better than what IE8 has. Read more about this technique called “Cutting the mustard” from BBC’s blog.

Browser Support

Here’s a rough list of the browsers which support the features we are testing, and will hence keep executing the JavaScript:

IE9+
Firefox 3.5+
Opera 9+
Safari 4+
Chrome 1+
iPhone and iPad iOS1+
Android phone and tablets 2.1+
Blackberry OS6+
Windows 7.5+
Mobile Firefox
Opera Mobile

The Basics, Plain JavaSript Way

Let’s start looking how the most basic and often needed functionalities work in plain JavaScript, compared to jQuery. For each example, I’m going to provide both the jQuery and plain JavaScript approach.

Document Ready

With jQuery, many are probably used to using document.ready like so:

$(document).ready(function() {
  // Code
});

But did you know that you can just put all of your JavaScript at the bottom of your page and that does basically the same thing? JavaScript has also an event listener for the DOM content loaded event which you can use instead of jQuery’s document.ready:

document.addEventListener("DOMContentLoaded", function() {
  // Code
}, false);

Selectors API

JavaScript’s native selectors API is very good. It works with CSS selectors and is very similar to what jQuery provides. If you are used to writing this in jQuery:

var element = $("div");

You can now replace that with:

var element = document.querySelector("div");

Or, to select all div’s inside some container:

var elements = document.querySelectorAll(".container div");

You can also query against a specific element to find it’s children:

var navigation = document.querySelector("nav");
var links = navigation.querySelectorAll("a");

Quite straightforward, easy to understand, and doesn’t really require much more writing now does it? To go a little further, we could even build a tiny JavaScript library for ourselves for simple DOM querying. Here’s something that Andrew Lunny has came up with:

// This gives us simple dollar function and event binding
var $ = document.querySelectorAll.bind(document);
Element.prototype.on = Element.prototype.addEventListener;

// This is how you use it
$(".element")[0].on("touchstart", handleTouch, false);

Traversing the DOM

Traversing the DOM with plain JavaScript is a bit harder than it is with jQuery. But not too hard. Here are some simple examples:

// Getting the parent node
var parent = document.querySelector("div").parentNode;

// Getting the next node
var next = document.querySelector("div").nextSibling;

// Getting the previous node
var next = document.querySelector("div").previousSibling;

// Getting the first child element
var child = document.querySelector("div").children[0];

// Getting the last child
var last = document.querySelector("div").lastElementChild;

Adding and Removing Classes

With jQuery, adding, removing and checking if an element has certain classes is really simple. It’s a bit more complex with plain JavaScript, but not too much so. Giving element a class called "foo" and replacing all the current classes:

// Select an element
var element = document.querySelector(".some-class");

// Give class "foo" to the element
element.className = "foo";

Adding a class without replacing the current classes:

element.className += " foo";

Removing "no-js" class from html-element and replacing it with "js":

<html class="no-js">
<head>
  <script>
    document.documentElement.className = "js";
  </script>
……

That was quite straightforward, right? Next step, removing only certain classes, is a bit more complex. I’ve been using this small helper function in a separate partial called util.js. It takes 2 parameters: element and the class you want to remove:

// removeClass, takes two params: element and classname
function removeClass(el, cls) {
  var reg = new RegExp("(\\s|^)" + cls + "(\\s|$)");
  el.className = el.className.replace(reg, " ").replace(/(^\s*)|(\s*$)/g,"");
}

Then, in the main application partial, I’ve been using it like so:

removeClass(element, "foo");

If you also want to check an element against some class, kind of like jQuery’s hasClass works, you could add this in your utils:

// hasClass, takes two params: element and classname
function hasClass(el, cls) {
  return el.className && new RegExp("(\\s|^)" + cls + "(\\s|$)").test(el.className);
}

…and use it like so:

// Check if an element has class "foo"
if (hasClass(element, "foo")) {

  // Show an alert message if it does
  alert("Element has the class!");
}

Introducing HTML5 classList API

If you only need to support more modern browsers like IE10+, Chrome, Firefox, Opera and Safari, you could also start using HTML5’s classList functionality which makes adding and removing classes even easier.

This is something, that I ended up doing with our latest Developer Docs, as the functionality I was developing, was more like an enhancement to the UI and not really something that would break the experience if it wasn’t present.

You can detect if the browser supports the classList API by using this simple if statement:

if ("classList" in document.documentElement) {
  // classList is supported, now do something with it
}

Adding, removing and toggling classes with classList:

// Adding a class
element.classList.add("bar");

// Removing a class
element.classList.remove("foo");

// Checking if has a class
element.classList.contains("foo");

// Toggle a class
element.classList.toggle("active");

One other benefit of using classList is that it will perform much better than using the raw className property. If you had an element like this:

<div id="test" class="one two three"></div>

Which you’d want to manipulate:

var element = document.querySelector("#test");
addClass(element, "two");
removeClass(element, "four");

For each of these methods the className property would be read from and then written to, triggering a browser repaint. However, this is not the case if we use the relevant classList methods instead:

var element = document.querySelector("#test");
element.classList.add("two");
element.classList.remove("four");

With classList the underlying className is only altered when necessary. Given that we are adding a class that is already present and removing a class that isn’t, the className is never touched, meaning we’ve just avoided two repaints!

Event Listeners

Adding and removing event listeners from elements is almost as simple in plain JavaScript as it’s in jQuery. Things get a bit more complex when you have to add multiple event listeners, but I’ll explain that in a bit. The simplest example, which will just pop out an alert message when an element is clicked, is as follows:

element.addEventListener("click", function() {
  alert("You clicked");
}, false);

To achieve this same functionality on all of the elements on a given page, we have to loop through each element, and give them all eventListeners:

// Select all links
var links = document.querySelectorAll("a");

// For each link element
[].forEach.call(links, function(el) {

  // Add event listener
  el.addEventListener("click", function(event) {
    event.preventDefault();
    alert("You clicked");
  }, false);

});

One of JavaScript’s greatest features related to event listeners is the fact that addEventListener can take an object as a second argument that will automatically look for a method called handleEvent and call it. Ryan Seddon has covered this technique thoroughly in his article, so I’m just gonna give a fast example and you can read more about it from his blog:

var object = {
  init: function() {
    button.addEventListener("click", this, false);
    button.addEventListener("touchstart", this, false);
  },
  handleEvent: function(e) {
    switch(e.type) {
      case "click":
        this.action();
        break;
      case "touchstart":
        this.action();
        break;
    }
  },
  action: function() {
    alert("Clicked or touched!");
  }
};

// Init
object.init();

Manipulating the DOM

Manipulating the DOM with plain JavaScript might sound like a horrible idea at first, but it really isn’t much more complex that using jQuery. Below, we have an example that selects an element from the DOM, clones it, manipulates the clone’s styles with JavaScript and then replaces the original element with the manipulated one.

// Select an element
var element = document.querySelector(".class");

// Clone it
var clone = element.cloneNode(true);

// Do some manipulation off the DOM
clone.style.background = "#000";

// Replaces the original element with the new cloned one
element.parentNode.replaceChild(clone, element);

If you don’t want to replace anything in the DOM, but instead append the newly created div inside the <body>, you could do it like this:

document.body.appendChild(clone);

If you feel like you’d want to read even more about different DOM methods, I’d suggest you to head over to Peter-Paul Koch’s DOM Core tables.

Diving Deeper

I’m going to share two bit more advanced techniques here, which I’ve recently discovered. These are both functionalities we have needed while building Adtile, so you might find these useful too.

Determining Max-Width of Responsive Images in JS

This is one of my own favorites, and it’s very useful if you ever need to manipulate fluid images with JavaScript. As browsers return the current resized dimensions of an image by default, we have to come up with some other solution. Luckily, modern browsers now have a way of doing this:

var maxWidth = img.naturalWidth;

This will give us image’s max-width: 100% value in pixels and it’s supported in IE9, Chrome, Firefox, Safari and Opera. We can also take this further and add support for older browsers by loading the image into an in-memory object:

// Get image's max-width:100%; in pixels
function getMaxWidth(img) {
  var maxWidth;

  // Check if naturalWidth is supported
  if (img.naturalWidth !== undefined) {
    maxWidth = img.naturalWidth;

  // Not supported, use in-memory solution as fallback
  } else {
    var image = new Image();
    image.src = img.src;
    maxWidth = image.width;
  }

  // Return the max-width
  return maxWidth;
}

You should note that the images must be fully loaded before checking for the width. This is what we’ve been using to make sure they have dimensions:

function hasDimensions(img) {
  return !!((img.complete && typeof img.naturalWidth !== "undefined") || img.width);
}

Determining if an Element is in the Viewport

You can get the position of any element on the page using getBoundingClientRect method. Below is a simple function showing how simple and powerful it can be. This function takes one parameter, which is the element you want to check. It will return true when the element is visible:

// Determine if an element is in the visible viewport
function isInViewport(element) {
  var rect = element.getBoundingClientRect();
  var html = document.documentElement;
  return (
    rect.top >= 0 &&
    rect.left >= 0 &&
    rect.bottom <= (window.innerHeight || html.clientHeight) &&
    rect.right <= (window.innerWidth || html.clientWidth)
  );
}

The above function could be used by adding a "scroll" event listener to the window and then calling isInViewport().

Conclusion

Whether or not you should use jQuery in your next project depends a lot on what you are building. If it’s something that requires large amounts of front-end code, you should probably use it. However, if you’re building a JavaScript plugin or a library, you might want to consider sticking with just plain JavaScript. Using plain JavaScript means fewer requests and less data to load. It also means that you aren’t forcing developers to add jQuery to their project just because of that dependency.

A New Path

2013-05-07T00:00:00Z

Today, after over two years, I’ll be leaving my position at Kisko Labs. I’ve started working on a new responsive advertising solution for smartphones and tablets called Adtile. Another big news is, that we have just received a $2.7 million funding to bring this product to the market. There’s also a story about us on TechCrunch, so check that out.

Banner ads might still function well in print, but it’s clear that they just don’t work on screen and especially on mobile devices anymore. Instead of trying to make the current model work somehow, we decided to start with an entirely new idea and ditch the old model—and the annoying banners. As we are focusing on mobile and building a customizable SDK for both web and native app developers, we will be also building another device lab soon only for this purpose.

The company where I’ll be working at, TenFarms, is based in Los Angeles, so I will be most likely spending time in the US a lot more too. Besides Adtile, I’ll be soon revamping the whole web presence of our second product, Photopoll iOS application too.

Helsinki Device Lab, which I established about 10 months ago, will still stay at the Kisko Labs offices and I will be still maintaining it together with the Kisko guys, so that’s one thing which won’t change because of all this. The Helsinki Device Lab will also soon be at the Webshaped conference, so come say hello if you are coming there.

Kudos to everyone at Kisko Labs and thank you for the past years! I don’t think that I’ve ever been so productive or learned so much new in such a little time. That’s all because of y’all. I will miss you a lot, but will also be visiting the office occasionally to check the devices, do some testing, and to have a chat & tea with you.

Plugin For Responsive Navigation

2013-04-09T00:00:00Z

Responsive Nav is a tiny JavaScript plugin which weighs only 1.6KB minified and Gzip’ed, and helps you to create a toggled navigation for small screens. It uses touch events and CSS3 transitions for the best possible performance.

It also contains a “clever” workaround that makes it possible to transition to height: auto, which isn’t normally possible with CSS3 transitions. The plugin, along the site, was released today on Smashing Magazine.

Prototyping Responsive Typography

2013-02-25T00:00:00Z

The history of typography dates back about 5,000 years. It starts from a series of pictograms, which then evolved to hieroglyphs in Egypt and later around 1,200BC to Phoenician alphabets. Almost 2,500 years later the Chinese invented first movable type which later revolutionized everything in the west when Gutenberg invented latin movable type. Many of the basic concepts of typesetting are still the same as 500 years ago.

Web typography, and digital typography in general, is a huge step forward in this history. It has made setting type fast and easy compared with hand-setting metal type. Responsiveness, when added on top of this, makes this period of change we are living very fascinating. Not only is centuries old design theory being rewritten, but the process of how design happens is now changing too (as Mark Boulton states it).

When talking about “responsive typography,” I don’t just mean flexible body text, but also that all our decisions should be based on universality. Universality, as a design principle, should guide us when choosing web fonts and when testing how our type works on various devices and platforms. It should be the core principle behind all the work we do.

New Process

About a year ago I wrote Responsive Workflow article describing my responsive design process. It was an article that gathered a lot of buzz, but I think it just scratched the surface a bit and never really tried to fully describe what’s happening behind the curtains. In this article I’m going to open the curtain and explain a new phase which I would today add to my year old workflow drawing. The new design phase is somewhere between prototyping and visual design phases, and I call it the “Typography Prototyping Phase.”

As I earlier in that article wrote, typography for the Web is really hard to design anywhere else than inside the browser. This is today even more true than it was a year ago. Typography prototype tries to solve this by doing the hard choices before jumping to other tools like Photoshop.

Basically, a typography prototype is a single web page that consists of the project’s actual content. It’s designed in the browser using real web fonts and tools like Typecast. A typography prototype includes font choices, styles for the basic text content and a typographic scale, but nothing else.

Content precedes design. Design in the absence of content is not design, it's decoration.”

– Jeffrey Zeldman

Planting the seed

All our decisions should start from the content out, not canvas in. This means we shouldn’t start doing any design work before having the project’s actual content on hand (or something that is very near the actual content). That’s because the content and the language used has a big impact on how our typography will work. This is especially true with display type and headers, but also with paragraphs and line-lengths. Having the real content also helps to judge if the font choices fit the mood correctly.

Below is an example of what the typography prototype looks like before any styles have been applied. This basic HTML page is already responsive on its own—by default, like Andy Hume states it, so you can immediately start testing how it works on various devices:

Choosing typefaces

Choosing type combinations, which are legible and readable across multiple devices and operating systems isn’t easy. Windows XP, which still has relatively high usage percent globally (24.29% at the moment of writing), is notorious for its poor font rendering. By default it doesn’t have ClearType antialiasing on at all, except in IE8. Fonts which haven’t been properly hinted for use on screen, tend to look like this when viewed there:

When choosing typefaces for the Web you should look out for the following qualities: Style and form, How easy it is to read, typeface’s intended usage—is it meant for longform reading or is it a display type, it’s character set, file size, OpenType font features, how it renders on different screens and if it is hinted for screen or not. Some good tools which can help with the process are Web Font Specimen, Typecast app and Typekit’s font browser.

It’s important that we choose the typefaces before making any other decisions about the layout. This way we can later on determine what the optimal font sizes are for the project, based on how the selected typefaces render at different sizes. Below is an example of what the typography prototype looks like on various platforms after the typefaces have been picked and we start testing how they actually render:

Useful Resources:

Choosing a scale

A scale, or more precisely, a modular scale, is a sequence of numbers that relate to one another in a meaningful way. A modular scale helps us to choose font sizes, line heights, margins, and more. Modular scales also make it easier to achieve a visual harmony in the whole design.

I recommend calculating typographic scales using the ideal text size of the chosen body typeface + a ratio, which could for example be the Golden Ratio 1:1.618. I tend to use either Tim Brown’s Modular Scale Calculator to build a custom scale, or, if the sizes match, the scale described in my previous typography article:

Tim, who also made the calculator I just mentioned, has written an in-depth guide about modular scales and how to use them on the Web. Tim’s methods are very similar to the ones I use myself too, and this is a short excerpt from his article:

Sizing type on the web is tricky because of the limited resolution involved. One pixel of font-size up or down can completely change how a typeface—and thus a whole text—looks. But once I found the size I liked, 18px, I had a number upon which to base my modular scale.”

Sizing type

There are no absolute sizes when it comes to measuring web type. Everything is relative. That’s why you should avoid using absolute values like pixels and instead embrace the fluid nature of the Web using units like percents and EMs. The size of the type you should use depends on the reading distance, device’s resolution and the typeface used. Reading distance also varies depending on the device used—is it a device held in hand, is it a tablet or is it a desktop device? Or maybe it’s something in between these?

A good starting point is to set the body font-size initially to 100%, which zeroes our scales to the “normal” of a given environment and then design and build for larger screens from that point upwards by using the modular scale we calculated earlier.

I do this by using a function in Sass which automatically converts pixels to EMs so that I don’t have to manually calculate them. The function below works by taking two arguments, pixels and context. You can either use the default context and specify only the pixels you want to convert—or you can specify pixels and a context for the conversion:

$browser-context: 16; // Default

@function em($pixels, $context: $browser-context) {
  @return #{$pixels/$context}em
}

…and then later in the CSS we can just pick numbers from the scale, 16/24/72, and they get automatically converted to EMs:

body {
  font-size: em(16);
}

p.intro {
  font-size: em(24);
}

h1 {
  font-size: em(72);
}

Below is an example of what the typography prototype looks like now, when we have our scale and have applied some base font sizes from that, but haven’t really tweaked the leading or margins at all:

Leading and white space

Leading (line-height in CSS) is the vertical distance between baselines of two lines of text. Leading has a big impact on the readability of a paragraph, so we should be careful when adjusting it. We should use tighter leading in a narrower paragraph, and looser in a wider one. This is to aid the readability and can be achieved by changing the line-height inside our media queries, or by using Mat Marquis’s plugin called Molten Leading.

High DPI screens add some extra complexity as they tend to require different line-heights than the lower DPI screens. Joni Korpi thinks this is because the text looks visually thinner with the extra pixels in use. Less weight = less line height needed.

In the example below, I’ve adjusted the leading of the header, paragraphs, margins, and also the line lengths to be more comfortable to the eye. Everything is based on the numbers found from the scale I created earlier. The example you see here is now basically a ready typography prototype which can be used as the base for the rest of our work:

Additional Tips

Screens with different pixel densities require different grades of the same font, just like different papers in print do. In theory, this is a great idea, but in reality, there aren’t that many fonts which would have grades (and hardly any have been designed for screen use). Newspapers have been using graded fonts for different papers for a long time, but it’s a quite new concept on the Web.
Sometimes using different body fonts for different screen types is better than using the same font all the way. A List Apart’s new redesign is experimenting with this idea. They are using Georgia Pro Condensed in the smallest breakpoint, to see if layouts are enhanced by fitting in more characters per line.
If needed, use non-breaking spaces between last two words to avoid orphans in fluid paragraphs ( ).
Always use non-breaking spaces in expressions in which figures and abbreviations are separated by a space (e.g. 20 kg, 4:00 pm) and where text breaking across two lines might be disruptive to the reader.
Try to keep the line length between 45-75 characters per line.

Conclusion

The finished typography prototype will be used as the foundation for the rest of our work. We have the recipe, and now we need to start thinking how the colours and the layout will be cooked. This way, when we start our work from the most crucial parts—the content and the typography—and build everything else up from that point, there’s much less chance that we will get lost along the way.

File Upload Support on Mobile

2012-12-18T00:00:00Z

I were quite surprised few weeks ago when I found out with Matt, my colleague, that no one has tested thoroughly which mobile browsers support input type=file and how to reliably detect the support. After an hour of Googling we literally gave up and decided to find it out ourselves. The results are shared here to everyone for future reference.

For the detection part, I am using similar code as Modernizr does, but I’ve added a separate user agent regexp to check against browsers that falsely report support. There are quite many of those false positives really, at least all Windows Phone devices running OS 7.0-8.0, Android devices running OS 1.0-2.2, Kindle devices running OS 1.0-3.0 and all WebOS devices running OS 1.0-3.0.5 (Although the latter ones being quite old already).

Testing

For the testing part, I used this page which was loaded on to all devices in our device lab. Thanks to David Blooman, Juha Ristolainen and Mike Arvela, I were able to test this on older Blackberry devices, Windows RT tablet and on Windows Phone 8 too. Below is the JS part used for the detection, which can also be found from GitHub:

// Detect file input support
var isFileInputSupported = (function () {
  // Handle devices which falsely report support
  if (navigator.userAgent.match(/(Android (1.0|1.1|1.5|1.6|2.0|2.1))|(Windows Phone (OS 7|8.0))|(XBLWP)|(ZuneWP)|(w(eb)?OSBrowser)|(webOS)|(Kindle\/(1.0|2.0|2.5|3.0))/)) {
    return false;
  }
  // Create test element
  var el = document.createElement("input");
  el.type = "file";
  return !el.disabled;
})();

// Add 'fileinput' class to html element if supported
if (isFileInputSupported) {
  document.documentElement.className += " fileinput";
}

Additionally, I tested manually on every device that the uploading actually works, and for that I used just basic html form:

<form action="http://www.tipjar.com/cgi-bin/test" enctype="multipart/form-data" method="post">
  <input type="file" name="image">
  <input type="submit" value="Upload">
</form>

Test Results

OS	Works
Android 1.0–2.1	No
Android 2.2+	Yes
Blackberry 1.0–5.0	No
Blackberry 6.0+	Yes
Blackberry Tablet 2.0+	Yes
Firefox OS 1.0	No
iOS 1.0–5.1.1	No
iOS 6.0–7.1.2	Yes
iOS 8.0	No
iOS 8.0.2+	Yes
Kindle 1.0–3.0	No
Maemo 5.0+	Yes
Meego 1.2+	Yes
Symbian 9.1–10.1	Yes
WebOS 1.0–3.0.5	No
Windows Phone 7.0–8.0	No
Windows Phone 8.1	Yes
Windows RT	Yes

Notes

Android devices which are running OS2.1 and under still support file uploads through Opera Mobile and Opera Mini, but not through the default Webkit based browser.
Amazon Kindle Keyboard reports that it support file uploads, but when you click the “browse” button, the device displays an alert box saying “file uploads not supported.”
On older Windows Phone OS the file input shows up, but doesn’t respond to touch at all or give any kind of feedback that it isn’t supported.

Conclusion

The support is actually quite good nowadays, Windows Phone OS and older iOS being the biggest drawbacks. I were also quite surprised to notice that even our oldest Symbian devices from around 2004 supported file uploads. Also, with almost all of the test devices, if the upload worked on the default browser, it also worked on other browsers like Firefox Mobile and Opera Mobile/Mini too.

Update 8 Jan 2013: False positives on Modernizr are now fixed and it's using the same UA detection introduced in this post!

Update 28 Apr 2014: Windows Phone 8.1 added.

Remote Preview

2012-11-11T00:00:00Z

Remote preview is a tiny JavaScript based tool which I built for our test lab. It allows you to preview any URL on large number of mobile devices simultaneously. Just enter a URL, hit enter, and new URL gets automatically loaded on each device. Remote preview works on platforms like Android, Blackberry, iOS, Maemo, Meego, Symbian, Windows Phone and WebOS.

Remote Preview works by making an ajax call every 1100ms to check if the url in the ‘url’ file is changed. If it is, the script will then change the src attribute of the iframe and load a new page into it. If there’s no changes, the script will just keep polling the url file until something changes. Remote Preview allows very fast previewing of different URL’s to check for possible layout problems, which can then be debugged using various other tools depending on the platform where they occur.

There are some issues and limitations with the way it’s being done, but as there currently is no other tool which allows you to preview web pages on all these platforms, I think this can be a handy addition to any test lab’s toolset.

Basic usage

Copy and paste all files to a public Dropbox folder/server/localhost, edit ‘url’ file and wait for devices to refresh. That’s all! You might also want to bookmark Remote Preview to your device’s home screen for fast & easy application like access later on (bonus: If you moved all files to a server or localhost, you can control the devices via web browser by pointing your browser to the directory named ‘control’).

Browser support

Current version is tested to be working on at least:

OS	Browser
Android 2.1 – 4.1.2	Stock WebKit + Chrome
Blackberry 7.0	Stock Browser
iOS 4.2.1+	Mobile Safari
Mac OS X	Safari, Chrome, Firefox, Opera
Maemo 5.0	Stock WebKit
Meego 1.2	Stock WebKit
Symbian 3	Stock WebKit
Symbian Belle	Stock WebKit
WebOS 3.0.5	Stock WebKit
Windows Phone 7.5	Internet Explorer Mobile
Windows 7	Internet Explorer 9

Download

Remote Preview on GitHub→

Building A Device Stand

2012-11-05T00:00:00Z

Not so long after the device lab was born I realized that we need a much better way to store and charge all the 40+ devices. There didn’t seem to be any existing solution available which you could just buy, so I started thinking what would be the easiest way to do something like that myself. After some research I ran into this device testing station by 64 Digital and thought it looked like a perfect solution.

The main idea is to provide a dynamic and secure way to store phones, tablets and other devices and make it possible to use them for testing without the need to actually remove them from the stand. Devices are held in place using Velcro tape which is attached both to the back of the phones and the stand. That makes it easy to detach the phones, but it also makes them stick securely to the wall. The whole stand system is done from two 800mm wide racks, and I’m planning to make a third one too so that we have available space to continue expanding our device collection.

The wood materials for both racks cost under 30 euros. The Velcro tape was actually the most expensive part as 25 meters of it cost about 70 euros + shipping. I used two full work days to built these and third to paint them. I guess someone with actual experience might be a lot faster as about half of that time went into trial and error.

See the process below and grab my drawings:

Establishing An Open Device Lab

2012-09-25T00:00:00Z

I wrote an article to Smashing Magazine. It’s an in-depth guide about how to establish an open device lab. The article gives practical tips about things like location, how to get devices, what devices to get and what software to use.

It would not have been possible to write it without the help from Shaun Dunne, Jeremy Keith, David Blooman and Andre Jay Meissner. Thank you people, I owe you one.

Helsinki Open Device Lab

2012-08-20T00:00:00Z

If you’ve been building websites during the past two years you must know that the web doesn’t live on a desk anymore. The reality is that we now need to test our work on multiple devices, instead of just few desktop browsers. All this is easier said than done. It's easy when you have a dozen devices laying on the desk in front of you, but what about the rest of us? Devices are expensive and the landscape is ever expanding.

That is the reason why we decided to set up an open device lab to Kisko’s office. ‘Open’ meaning that anyone can pop round, use the devices freely and contribute by lending their old devices to us. The list isn’t very long yet, but it will grow over time. I am also planning to contact few device manufacturers to help us out here.

Joni Korpi and I are leaving our spare devices at the office for testing purposes and we are hoping to see others to contribute too. Kisko Labs is also—in addition to the space—giving four devices for testing purposes. If you’ve got an old mobile device which you aren’t using anymore and it’s just gathering dust, then why not lend it to our lab. The device will of course remain yours all the time, and you can take it back whenever you want.

I will post more info about the project either here or on Twitter once we get everything up and running. I also made a site for the lab which can be found at devicelab.fi. Shout outs also to Jeremy Keith who started this whole ‘open device lab’ thing in the first place.

How things are looking at the moment:

Location

Kisko Labs is located downtown Helsinki, next to Katri Valas park. Our address is Vilhovuorenkatu 11D, 00500 Helsinki, FI. Before coming make sure we’re at the office by sending message to @kiskolabs at least few days beforehand.

Current devices

Device list moved to devicelab.fi

Our wish list

Android 3.x device
SonyEricsson LT15i Xperia Arc
Blackberry 5.x device
Blackberry 6.x device

Responsive Workflow

2012-05-28T00:00:00Z

During the last week I was at the Webshaped conference listening Stephen Hay’s talk about responsive design workflow. This post isn’t going to be strictly about that, but as Stephen’s way reminded somewhat the way I work myself, it made me want to write down some thoughts about my workflow and how it has evolved during the past two or three years and how it might still evolve in the future.

About three or four years ago—when I mostly did just static width sites—my projects went through the different phases in the order illustrated below, which looks like a typical waterfall process. Back then there wasn’t much room for revisions, and what clients saw were either the wireframes or almost finished Photoshop designs.

That model kind of used to work back then, but now there’s just one problem. Waterfall model doesn’t make that much sense when combined with responsive design. Actually it wasn’t ever very optimal way to do web design, but as I and everyone around me were so used to delivering things in that specific order we never really tried to challenge that.

The new way

This is the process I use today when doing responsive web design (illustrated below). I used Mark Boulton’s workflow article and Stephen Hay’s presentation as resources while writing this. My new process reminds more agile than waterfall model and I’m going to explain each step in more detail further on.

Workflow in short: Starts from the content out and encourages to spend time to really think it through. After the first content drafts are done I convert them to HTML prototypes, open them up in a mobile browser, and look how the order of the content works there. I do sketching and visual design mostly before and after prototyping. After first sketches I usually go pretty fast back to the HTML prototype and start adding some CSS to see how my ideas actually work. The whole process happens in iterations which usually go somewhat like this: sketch → prototype → design → test → discuss until it works. The order might not be this linear in reality, but I wanted to simplify my diagram for this article.

Discover

The first stage is about information gathering, getting to know the client and research work. The goal here is to gain better understanding of the client’s business, competitors and main goals of the project. Without proper knowledge it’s almost impossible to know what the client actually needs/wants.

During this stage I ask a lot of questions like: “Why people would come to your site?”, “What is the main goal you are trying to achieve?”, “Who are your main competitors?” …and so on. You can get ideas on what to ask by browsing through project sheets of other design firms:

Plan

Planning is done based on the knowledge that is gathered during the first stage. In this stage I usually start by refining the concept and move on to work on the user stories and the information architecture. I also work on establishing and describing content elements, which can then be rated with a level of importance. Based on that importance we can then do rough HTML wireframes of the views. These last two steps are quite identical to Stephen’s workflow steps ‘Content inventory’ and ‘Content reference wireframes.’

Text design

“Text design” here means that we write (design) all the contents of the website down in textual form. This is one of the most important stages in the whole process, and yet it’s probably also the most underrated step. I say this because in my opinion it doesn’t make much sense to go any further if we don’t have the actual content at hand. Content is the reason why people come to the website and the whole process should start from that.

I often do this step in HTML without styles, as then we can instantly see how the content appears in a narrow single column layout and if the order is correct. This is also basically the way the site will be shown to users using screen readers.

Keep in mind that it doesn’t have to be the final draft yet, as we can refine it during the prototyping. This step is also possible to accomplish using text documents which works almost equally well.

Sketch

Sketching ideas down is usually something which happens all the time, but it’s especially important before jumping to browser. I often test my sketches using the HTML text designs I did in the previous step (which basically mean that I add a few CSS rules on top of them).

By spending a short time sketching you can save yourself hours on the computer. Not only will you save yourself hours, you may even afford yourself some peace of mind. (…) I challenge you to start employing sketching as a part of your process and you will see a dramatic decrease in the amount of times you hit that virtual wall of nothingness.”

– Tara Roskell

Prototype

Prototyping early in HTML/CSS is necessary as that’s the only way to truly see how the layout will respond to different viewport sizes. This also allows me to show the actual site much sooner to the client and react early to problems which the design might have.

Unlike Stephen, I don’t really work on “breakpoint graphs” before the actual prototyping or design. It’s good to be aware of the various breakpoints and what works for different viewport sizes—or doesn’t, and it’s probably also a good idea to let the client know what the landscape is like, but I let the actual content in the browser to be the judge when making decisions.

Below is a device breakpoint diagram which I did based on the Pragmatic responsive design by Stephanie Rieger and Metal Toad’s Simple Device Diagram. I did it because I felt that the other one was too old and the other one was just completely missing Symbian devices which are quite popular around here (click the image to view a bigger PDF version):

Visual Design

This step happens in iterations before and after prototyping. I still use Photoshop to do most of the design, but I’m moving more and more towards design in a browser. Especially typography seems to be something which is really hard to get working anywhere else than inside the browser (Although at the same time I have noticed that if I do the jump too early, everything will end up looking flat, uninspiring and somehow cluttered).

The most important part here is to use a tool which doesn’t restrain your creativity. It can be the browser, Photoshop, Fireworks, InDesign or anything else that feels right.

Test

Introducing testing as a part of your process early will save you from having bigger problems later on. Just look at the device breakpoint diagram I did and add all the browser quirks on top of that, and you should start to understand why it's almost impossible to build responsive sites without testing them on a number of actual devices. Testing should also include user testing as that’s really the easiest way to see how the prototype actually works in terms of usability and which parts of it might still need work.

I mostly do all the testing with the devices I already have, but sometimes there’s a real need to bring in new devices or even go to a store and do some field testing there. That doesn’t cost anything, at least not yet…

Discuss

Discuss with the client during all iterations. Present the actual HTML prototypes to the client and show how they work on actual devices. Avoid ‘The Big Reveal’ like Mark Boulton said.

Iterate

Sketch → prototype → design → test → discuss until it works.

Conclusion

There is no perfect workflow. What works for me, might not work for everyone, and I have a feeling that the changes in my workflow are just the start of the transition. What I described here works best when designing websites (large or small) but it might need some adjustments to work well with web application design which is somewhat different (depending, of course, what kind of application it is).

Resources

Update 12 Jun 2012: This post has been translated to Russian.

Update 13 Apr 2013: Added Spanish translation.

Modular Grids

2012-05-08T00:00:00Z

Couple months ago while I were designing a website I remembered a technique I had long forgotten. I used to use this technique before I moved from print design to web design about eight years ago and it was, for me, an essential way to utilize modular grids better. Grids in design are kind of like the scales in music. They give you a way to anchor your layout elements and typography to a certain rhythm.

What is a modular grid

A modular grid is a grid which has consistent horizontal divisions from top to bottom in addition to vertical divisions from left to right. Modular grids are created by positioning horizontal guidelines in relation to a baseline grid that governs the whole document. Baseline grids serve to anchor all (or nearly all) layout elements to a common rhythm. ^[1]

Illustration from the book titled Thinking with type, by Ellen Lupton.

How to use a grid

The thing is, I don’t actually even know the reason why I abandoned this good practice when I moved forward on my career. I might have unwittingly thought that the same practices wouldn’t work in the digital world, but oh boy, I was so wrong back then. This technique is also so bloody simple that I wouldn’t be surprised to hear if most of you are already doing something similar.

My method is this: While you are aligning the design elements to a grid, zoom out the layout (in a browser or a design tool) so much that the size of the layout is around 30-40% of the original and about the size of your phone’s screen in landscape orientation.

This way it’s much easier to see the balance of the whole layout and if it works visually or not. I also promise that it will make you a much faster (and hopefully better) designer. At least that is how I feel it transformed my own process. Of course, after you’ve zoomed back in to see the layout in its real size, you then have to fine-tune elements and typography and start working on the smaller details.

Remember that not all layouts work the same way though, and because of that, you shouldn’t always force elements to a grid.

Tools to get you started

There is this tool called Modular Grid Pattern which has a Photoshop extension which allows you to create modular grids directly inside Photoshop. Then there’s also this interesting experiment which uses a fluid modular grid framework. There are also a number of tools that allow you to create and use responsive grids, but they are mostly multicolumn grids (with or without baseline grid) and not modular.

Tools are just tools though and the best way to actually start learning is to pick or make a grid yourself and start using it. Check also my resources below, thegridsystem.org for example has a lot of interesting articles and templates if you want to dive deeper.

Screenshot from the Modular Grid Pattern app.

Extending CSS With Sass

2012-04-15T00:00:00Z

CSS is designed primarily to enable the separation of content from presentation, including elements such as the layout, colors, and fonts. This separation improves content accessibility and provides more flexibility and control over the presentation. CSS is quite flexible language on its own, but as websites become more and more complex we sometimes need to have more control.

I’m using Sass to extend the basic behavior of CSS and this post is mostly about some basic things I’m using. I’ll also assume that you know something about Sass already and that’s why I won’t dive deep into what it actually is. If you are running OS X, you can get Sass up and running using these two commands below. The first one installs Sass Ruby gem and the second one translates your .scss file into a .css file.

gem install sass
sass --watch style.scss:style.css

Partials

Using Sass’s @import you can organize your styles into a smaller partials. @import in Sass works a bit differently if compared to CSS @import statement. The difference is that when Sass is processed all the partials will be combined into a single CSS file which reduces unnecessary HTTP requests and speeds up the loading time. I usually have one “main” Sass file where I have all my variables, mixins, etc. and where I do the importing.

@import "fontface";
@import "reset";
@import "header";
@import "content";
@import "footer";
@import "print";

This way you can separate different sections/features.

Variables

Variables are good when you need to, for example, use the same colors again and again. They allow you to specify widely used values in a single place and I usually specify them as the first thing in my main stylesheet.

$color-red: rgb(124,42,0);
$color-blue: rgb(0,109,143);
$color-green: rgb(55,87,25);
$font-body: sans-serif;
$font-headers: "PTSansCustom", Arial, sans-serif;

And then later we can use them like this:

h1 {
  font-family: $font-headers;
  color: $color-blue;
}

The benefit of this is that when you need to later adjust or change that shade of blue, you only need to change it to one place.

Converting Pixels to EMs

One of the most useful features for me has been the ability to convert pixels to EMs without the need to use calculator. This function below does that and it works by taking two arguments, pixels and context. You can either use the default context and specify only the pixels you want to convert – or you can specify pixels and a custom context for the conversion.

$browser-context: 16; // Default

@function em($pixels, $context: $browser-context) {
  @return #{$pixels/$context}em
}

And then later this function can be used like below (converts 36px to EM units):

h1 {
  font-size: em(36);
}

If you’ve converted all your pixels to EMs you can even scale the whole layout inside Media Queries with this simple percent conversion:

@media screen and (min-width: 60em) {
  body { font-size: percentage(16 / 16); }
}

@media screen and (min-width: 80em) {
  body { font-size: percentage(18 / 16); }
}

Making a simple grid system

Making your own grid system is also pretty straightforward in Sass. The following example is a Sass @mixin from David Demaree’s article on A List Apart which takes one argument—$span—which will be passed into our @mixin as a variable:

$column-width: 21em;
$gutter: 1.5em;

@mixin grid($span) {
  float: left;
  margin-right: $gutter;
  margin-bottom: $gutter;
  width: ($column-width * $span) + ($gutter * ($span - 1));
}

And then later that mixin can be used with containers using simple @include:

header {
  @include grid(3);
}

article {
  @include grid(2);
}

aside {
  @include grid(1);
  margin-right: 0;
}

To make this a bit easier to understand, our grid (layout) would now look like this when containers are laid on top of it:

More Resources

I’m just scratching the surface here on what’s possible, and I suggest you to read more about some of these techniques from A List Apart and from the resources I’ve provided below.

Scaling with EM units

2012-03-05T00:00:00Z

Recently I started testing how proportional scaling of bigger layouts would work in reality and if it makes any sense. It’s possible when using EM units and then changing body’s font-size when viewport’s height grows above certain point. Basically that means, that I have to change only one or two css properties between @media queries which are targeting larger screen sizes.

The reason why I started doing this, is that I wanted to rethink my current approach to responsive design and try something which would make the process at least a bit easier.

Warning: You’ll need to view my demo on at least 24" or 27" monitor with 1920×1200 resolution or bigger. Otherwise you won’t see this method in full effect and it might be harder to understand the benefits.

Demo viewed on 27" and 15" screens:

The idea is that when the screen size grows, the demo still takes approximately the same amount of screen estate.

CSS and @media queries

This method makes most sense when combined with mobile first approach. After you’ve reached the “optimal desktop size” you can start scaling the layout up for larger screen sizes. The most important thing is to specify all units in your stylesheet with EMs, so that we can scale everything by changing body’s font-size. That works because EMs are relative to parent element’s font-size.

You can easily figure out the needed break points by scaling the window bigger and looking when the layout starts to break apart or look awkward. That’s the point when you’ll want the next @media query to trigger and scale the layout a bit bigger.

body {
  font-size: 81.25%;
}

@media (min-width: 68em) and (min-height: 53em) {
  body {
    font-size: 87.5%;
  }
}

@media (min-width: 75em) and (min-height: 57em) {
  body {
    font-size: 93.75%;
  }
}

@media (min-width: 80em) and (min-height: 62em) {
  body {
    font-size: 100%;
  }
}

Check out my demo to get a better picture of this. Try also scaling the browser window bigger/smaller + remember to do the testing on a big screen.

Images

I recommend using either SVG or some sort of adaptive images approach with this technique. You can get going with just one image version, but you should remember that when you optimize for the largest size possible it’s usually way too heavy for mobile devices + can also look quite awkward when browsers scale it down too much.

The future

This method won’t work with all designs, but at least when combined with a design which has elements which are somehow relative to the viewport dimensions, it makes it much easier to adapt the layout to different sizes.

Also: I heard two days ago that Webkit nightly builds started supporting viewport-relative lengths through the “vw” and “vh” units in CSS. In addition to Webkit, IE9 is the only browser out there right now that supports these new units. We cannot probably start using them right away, but they’ll open up many new possibilities to make it much easier to scale elements according to the viewport. Before we reach the point where all major browsers support these units we can use this EM method.

Resources

Please note that the demo layout I’m using is copyrighted work and cannot be used as a template/boilerplate for your work. ~~The actual site will be launched later on different URL.~~ The actual site is here.

Adaptive vs Responsive, What’s The Difference?

2012-02-23T00:00:00Z

There seems to be some confusion about these terms and what they mean, so here’s my thoughts on the subject and few links to back them up. I’m usually not very keen when it comes to debating over what something is called, but this time I wanted to make it clear, as I hear this question quite often.

“Responsive design” is a subset of a larger concept which is called “Adaptive design.” When talking about responsive we refer to the layout only (Ethan Marcotte, fluid grids, flexible images & media queries).

“Adaptive design” on the other hand includes much more than just fluid layout. In practice it means the same thing as progressive enhancement, which means in short, that we aim to deliver the best possible experience to the widest possible audience. Also: “Adaptive design” shouldn’t be mixed with “Adaptive layout” which is a completely different thing.

Finally, “Adaptive layout” means a layout done by combining multiple fixed widths. Right now, I feel that Adaptive layout—when done right and when fixed widths are combined with fluid widths—is one form of responsive design and not just an alternative to it. Zeldman shared a bit similar idea in his blog post from 2011.

Links/sources:

Update v1. If my post made things look more complicated than they actually are, then this all in short: Resposive design is a subset of adaptive design. Responsive design = fluid layout only, while adaptive design = fluid layout + progressive enhancement.

On Typography

2012-01-21T00:00:00Z

I have been intrigued by the idea of making a typographic scale out of a musical scale that would not only be very readable, but also aesthetically pleasing. This whole idea started after the launch of my new site. At first, I ignored to see it, but weeks later I started to notice that the textual content of the site is actually pretty harsh for the eyes and the reading experience isn’t that great.

You can read it—I’m quite sure of that—but the longer you browse the content, the more your eyes start to hurt. Literally. One reason for this is the contrast between the text and the background, but there’s also more to it than just that, so I started wondering:

How could I improve it?
How to make building of responsive typography easier?
Can typography look good and be readable on so wide range of devices?
Are there any patterns where I could base my decisions on?

The foundation

At the time I were thinking about the subject, I had a Skype chat open with Joni Korpi and we were discussing about similar problems in Responsive Design. Later on the evening, when I had already went to sleep, Joni pasted me a link to 24 Ways article about Music, Harmony and Proportion in Web Design. The idea didn’t hit me instantly after I read it, but about a week or two later I was hooked and started studying how Musical Scales could help me to make the perfect Typographic Scale for the Web.

Since I’ve been following close-by music producers and artists—who compose their tracks with the help of a scale—for most of my youth, I felt pretty confident to base the rhythm and proportions on the chromatic scale. There are different versions of the scale and I decided to go with the Pythagorean one. That decision was mostly based on the information I could find from the Web.

The Chromatic Scale

The chromatic scale is a musical scale with twelve pitches, each a semitone apart. On a modern piano or other equal-tempered instrument, all the half steps are the same size. An equal tempered chromatic scale is a non-diatonic scale having no tonic because of the symmetry of its equally spaced tones.^[1]

The most common conception of the chromatic scale before the 13th century was the Pythagorean chromatic scale. Due to a different tuning technique, the twelve semitones in this scale have two slightly different sizes. Thus, the scale is not perfectly symmetric. Many other tuning systems, developed in the ensuing centuries, share a similar asymmetry.^[2]

Different notes and their Ratio/Pitch/Math:

Don’t compose without a scale

“In the sixteenth century, a series of common sizes developed among European typographers, and the series survived with little change and few additions for 400 years. [...] Use the old familiar scale, or use new scales of your own devising, but limit yourself, at first, to a modest set of distinct and related intervals.” ^[3]

That’s an excerpt from a book called The Elements of Typographic Style by Robert Bringhurst. Basically, the use of a scale in typography is something that have been practised for centuries. It’s not something that I just invented. Today you can see it, for example, in all word processing applications that let you choose font-size or change line-height.

At this point, you might want to ask why did I even want to build a new scale if there’s a scale that have been used for centuries? How could I possibly build a better one?

The short answer: I never believed that I could do it better, but I wanted to learn more in-depth what is the foundation of good typography. I’ve always felt that typography is the most crucial part of a design and also the hardest thing to master.

Composing the layout

The first thing I did, is that I forgot pixels and started using EMs for everything. That’s because they give a lot more control for scaling and making the typography responsive. The chromatic scale is also easy to convert to EMs, so there are many arguments to support this decision.

What I basically did first, is that I started testing different combinations and notes that play well together and started adding some calculations to the mix. After about a week of testing the results were quite interesting: No matter what combinations I used, I always ended up having a scale that’s very similar to the centuries old Typographic Scale described in Alex Charchar’s article.

That only covered the various font sizes though, but I added a 1.5em baseline grid into the mix and with the help of that calculated optimal white space needed for the headings, paragraphs and other elements.

The result of all this is the page you are reading right now. ~~It’s using the same “foundation”~~ which I’m going to share later on in this article. If you are eager, then go ahead and grab a copy of it from GitHub and tweak/use it in any way you want. It might not be perfect yet, probably never will, but if it works for you I’m more than happy to share it.

About the responsiveness

I started with a mobile first approach and wanted to make sure that the content preserves it’s readability from about 200px and up. So not only smartphones, but also feature phones that have slightly smaller screens.

The interesting thing for me is, that the more I build responsive sites, the more the current way of building them feels complex and hard. I can, for example, choose to make a completely fluid layout or a set of static layouts. Or take a mixed approach that has both fluid and fixed widths (but this isn’t really the hard part yet).

There’s also often a lot of “magic” happening inside various Media Queries and we tend (or tended) to think more device widths than what the layout can handle. Things get also interesting when you are building a site that runs on top of a CMS where your client does all the updating and even more so when you start adding advertising and dynamic content into the mix.

I tried to leave all these problems aside when thinking this, but I really couldn’t. The way which I might see myself working in the future is probably somehow based on the way how this template is built. It basically has only one one column layout which just scales up or down. Then the next layout after that—when the screen size is big enough—could be the more complex one, which includes more columns and “richer” experience (isn’t included in this template). So that’s two different fluid/fixed/mixed layouts which we can then scale up or down to create even more responsiveness.

The thing which I kind of like in this approach, is that I’d only have to build one layout for the mobile and one for the desktop and anything in between (or bigger) would just scale. I know that there are more things to consider than just that, but if I could get going with only minimal CSS changes between the Media Queries, let’s say, only the body’s font-size, max-width and maybe some padding, that would be wonderful.

Final layout

Below is the base CSS for the template I came up with. Different CSS declarations are explained below the code.

BTW: If you are using Firefox/Safari/Chrome to read this, and want to see the whole layout in effect, I suggest you to try Safari and install Resizer Extension so that you can see the narrowest layouts with your desktop browser (also a handy tool when building sites).

body {
  font: 75%/1.5em Georgia, serif;
  max-width: 40.49984em;
  color: rgb(0,0,0);
  margin: 0 auto;
  padding: 1em;
}

@media print {
  /* styles for print */
}

@media screen and (min-width: 15.652em) {
  body {
    font-size: 87.5%;
  }
}

@media screen and (min-width: 19.9375em) {
  body {
    font-size: 100%;
    padding: 1.5em;
  }
}

@media screen and (min-width: 29.9375em) {
  body {
    max-width: 34.3em;
    padding: 1.5em 3em;
  }
}

@media screen and (min-width: 38em) {
  body {
    padding: 4.5em 3em 7.59372em;
  }
}

@media screen and (min-width: 99.9375em) {
  body {
    max-width: 34.43736em;
    line-height: 1.75em;
    font-size: 112.5%;
  }
}

CSS in short: the first layout for feature phones is using 12px base font-size and the max-width and horizontal centering are there for browsers that don’t support Media Queries. Then inside next Media Queries the whole layout starts to scale slightly bigger just by changing the body’s font-size. This works because EMs are always relative to parent element’s font-size and I’m using EMs everywhere instead of pixels.

Simple yet effective.

Get the code

Point your browser to the GitHub project page.
Read my newer blog post about the subject: Scaling with EM units.
If you have questions send me a tweet.

References and links

First and foremost, I should thank Iain Lamb for his exploration of scale and rhythm in typography. He was the one that gave me the idea to base my decisions on the Chromatic Scale. I should also thank Alex Charchar for his article about Typographic Scale.

Then there is the 24 Ways article which I mentioned earlier, where it all kind of started: Music, Harmony, Proportion in Web Design.

^[1] Benward & Saker (2003). Music: In Theory and Practice, Vol. I. Seventh Edition. ISBN 978-0072942620.

^[2] Excerpt from a Wikipedia article about the Chromatic Scale.

^[3] Bringhurst, Robert (2003). The Elements of Typographic Style. Third edition. ISBN 978-0881792065.

Convert A List To A Select

2012-01-03T00:00:00Z

I created another responsive jQuery plugin during the Christmas holidays. It’s called TinyNav and it can convert <ul> or <ol> based navigation to a dropdown for small screen.

TinyNav.js is a tiny jQuery plugin (304 bytes minified and gzipped) that converts <ul> and <ol> navigations to a select dropdowns for small screen. It also automatically selects the current page and adds selected="selected" for that item.”

Fluid Image Replacement Techniques

2011-12-18T00:00:00Z

While you can find two dozen blog posts and articles about various image replacement techniques using Google, I couldn’t find any article that would help when you want the replacement to be fluid.

If the term “image replacement” is unknown to you, it basically means that we replace some content on a page—usually text—with an image.

I’m not a huge fan of using image replacements in the first place, but it’s often necessary to do so. One quite popular example is a logo. Logos—when used on a Web page—are usually images that have text inside them. If we want that text content to be visible to search engines, screen readers and text based browsers (Elinks, Lynx, ...) we need to use some kind of image replacement technique.

The most popular image replacement technique right now is probably this:

HTML:

<h1>Header</h1>

CSS:

h1 {
  background: url(image.jpg) no-repeat;
  text-indent: -9999px;
  overflow: hidden;
  width: 100px;
  height: 50px;
}

I think that the method described above is good if we just need to replace a logo, but what can we do when we want the replacement to be fluid and scale with the layout? Well, we could add a background-size CSS property which is supported in Firefox, Safari, Chrome, Opera, and IE9+ to make it a bit better:

CSS:

h1 {
  -webkit-background-size: 100% auto;
  -moz-background-size: 100% auto;
  background-size: 100% auto;
}

Now by changing the width and height of the header between different Media Query trigger points we could change the size of the replacement image. That doesn’t help much though if we want/need the replacement to be completely fluid.

Back to the past

Because of the non-fluid nature of the last example, I’m suggesting an alternative method to “replace” the text, which, I think, is actually the way image replacement was done before all these CSS methods about 10 years ago (...now added with few improvements):

HTML:

<h1>
  <img src="image.jpg" alt="Header">
</h1>

CSS:

h1 img {
  width: 100%;
  height: inherit;
  -ms-interpolation-mode: bicubic;
}

@media print {
  h1 img {
    display: none;
  }
  h1:after {
    content: "Header";
  }
}

This method also hides the image when you print the page and replaces it with the text from the image. This is something that’s really useful if the text inside the image is white as on my own home page. You might also want to add a max-width for the H1 or the IMG to avoid the image scaling too much.

I’m not a SEO expert so I don’t know how this particular technique performs against H1 with real text content, but at least screen readers, text browsers and search engines see the text now (I tested if the ALT description used in this kind of example shows up in Google results by searching for my own site and the words inside ALT description. The text did, in fact, show up there).

Putting more thought into this

I started wondering if it's possible to automatically get the content of the ALT description for printing, so that we wouldn't have to write all the texts inside the stylesheet. This is what I came up with:

CSS:

@media print {
  h1 img {
    display: none;
  }
  h1 img:after {
    content: attr(alt);
  }
}

That should work in all major browsers + now we don't have to worry so much about our stylesheet anymore.

Usage of an H1 tag

I’d say that you shouldn’t probably wrap a logo inside an H1 tag. The Example uses H1 just because the main header on this site uses an image replacement and this blog post kind of grew up from that particular use case. I’m using image replacement because I wanted to make the header look identical across multiple platforms/devices, also the ones that don’t have support for @font-face.

ResponsiveSlides.js

2011-12-04T00:00:00Z

I created this plugin while I were developing my own site and decided few days ago to release it as an open source version. Its basic function is to create responsive slideshow using images inside a container. The interesting thing is, that this is actually the very first JavaScript plugin I’ve done and that’s why I thought that I should write down some notes while I’m at it.

Basics first

Let’s start with the Markup and CSS. I used the same markup which I used on blog.kiskolabs.com as the foundation for this plugin, but I wanted to make it a bit better this time. The problem with my previous version was that if there was any content below the slideshow, you had to change the height between Media Query triggerpoints for it to work properly. Now we don’t have to specify/calculate height anymore, so this scales really smoothly.

HTML:

<div id="slides">
  <img src="1.jpg" alt="" />
  <img src="2.jpg" alt="" />
  <img src="3.jpg" alt="" />
</div>

CSS:

#slides {
  position: relative;
  overflow: hidden;
  max-width: 800px;
  width: 100%;
}

img {
  position: absolute;
  height: inherit;
  width: 100%;
  left: 0;
  top: 0;
}

.img_visible {
  position: relative;
  float: left;
}

The markup is really simple: you only need one container and few images inside that. Max-width on the container isn't necessary, but we might want to prevent images scaling too much.

The last img_visible class in CSS fixes the height problem I mentioned earlier. It’s basically applied to a slide when it fades in and removed when it fades out. The idea for using position: relative on visible slide came from a comment on the previous blog post. float: left makes the fix also work on IE6.

That part is pretty straightforward, but what about JavaScript?

Making it a plugin

There’s a pretty good tutorial on docs.jquery.com about writing your own plugins. It’s a good place to start if you are interested to learn how it works. After you become familiar with the concept you can try something simple first and build up from there.

I had three things in my mind when I started doing this. First, it should scale smoothly without any glitches, second, the whole plugin should be very light in file size and third, I wanted to avoid feature bloat. Because of the second and the third thing there isn’t very many options you can customize and I didn’t even plan to include much more in the future.

Hooking it up:

$("#slides").responsiveSlides({
  auto: true,           // Boolean: Animate automatically, true/false
  speed: 1000,          // Integer: Speed of the transition, in ms
  timeout: 4000,        // Integer: Time between transitions, in ms
  pager: false,         // Boolean: Show pager, true or false
  nav: false,           // Boolean: Show navigation, true or false
  prevText: "Previous", // String: Text for the "previous" button
  nextText: "Next",     // String: Text for the "next" button
  maxwidth: "none",     // Integer: Max-width of the slideshow, in px
  controls: "",         // Selector: Where controls should be appended
  namespace: "rslides"  // String: change the default namespace used
});

Was it worth it?

I think it was. I learned a ton about jQuery plugins + now I have something to use with new projects. I do know though, that there’s still a lot of things that I could probably do better, but given the time that I used for the development, I’m satisfied with the results. See the plugin in action on it’s homepage and check out the repository on GitHub.

Update: Decided to change the name “AdaptiveSlides.js” to “ResponsiveSlides.js”. That just makes more sense here.

Update 2: I changed the markup to use unordered lists. Check out the new version.

New Website

2011-11-20T00:00:00Z

Since you are here, you have probably noticed that there’s a new design which I have been working on for some time now. I wanted to focus on the content and make something much more simple. I also wanted my site to work with various devices from smartphones to TV’s. That’s why I used the so called “Mobile First” technique and made the whole site responsive from about 240px and up.

As a starting point for the work I used the 320 and up boilerplate, but I ended up changing almost everything to suit my own way of working (if you don’t know, the 320 and up is a boilerplate that prevents mobile devices from downloading desktop assets by using a tiny screen’s stylesheet as its starting point). I’m still using small parts of it like the folder structure, print styles and JavaScript helpers for iPhone, but that’s about it.

When you are using tiny screen’s stylesheet as the starting point you have to design the mobile version first and build up from there progressively. The best thing in that approach is that it’s relatively easy to get the site working with large number of devices, even on devices that don’t support Media Queries. This “reversed” approach also forces you to think more about the content.

Viewed on different devices:

The end result

I created probably dozen different drafts before I started to work with the one design I really liked. At somepoint I even hand drew some of the texts using Mensch. I'm still not quite satisfied with the way this turned out to be, but I can improve things here along the way.

Below is a quote from Jason Rhodes’ post titled “More Responsive Design, Please.” It holds the same meaning in it as the introduction on my home page, and I think it summarizes exquisitely what I was thinking while I were building this site, and how we—as a web designers—should be building the web.

You either build for a device or you build for the web. You can’t build a web-app that’s just for the iMac. If you try, people will access it from other devices and rightfully expect to be able to use it, because that’s what the web is. When we build for the web, our initial design should respond to what we know about our users, and the layout and content should be able to subtly respond to a user’s capabilities on the fly. That’s how we build a more responsive web. Not a mobile web, or a desktop web, or an iPad web, or any other kind of web we might try to predict.”

Update: You can now browse older versions of this site via subdomains: v1.arielsalminen.com and v2.arielsalminen.com. I also fixed some accessibility issues: Now the navigation works properly on small screen when JavaScript is turned off.

Responsive jQuery Slideshow Revisited

2011-11-19T00:00:00Z

I wrote a blog post about making responsive jQuery slideshow on 18 May 2010 (You can read it here). Since then much has happened and there’s now quite a lot of options where you could choose from. I did a short summary for this blog post about the options out there right now.

I’m myself using Dynamic carousel plugin by Mat Marquis on the home page, but I made slight changes to how it handles the touch events and dragging. ~~If you want to try it out, head to the home page with either iPhone or iPad and try dragging the text caption under the big headline~~. Update: I removed the slider from the home page. Mainly because it didn't make so much sense in that context.

I also created a tiny script while developing my own site and despite it being really simple I decided to release it as a plugin. If all you need is fading (with pagination), then it might be what you want to use.

ResponsiveSlides.js, this one I created while developing my site.
Fully fluid, responsive CSS carousel. This one is pretty neat, it uses CSS keyframes.
FlexSlider, a fully responsive jQuery slider plugin.
Photo Swipe, Image gallery for mobile and touch devices.
Dynamic Carousel, a carousel plugin built for responsive layouts.
Blueberry, a simple, fluid, responsive jQuery image slider
Elastislide, a Responsive jQuery Carousel Plugin.
wmuSlider, a jQuery responsive slider.

Responsive jQuery Slideshow

2010-08-18T00:00:00Z

This example makes it possible to have a fluid jQuery slideshow which scales responsively. This is the same method that I used on the new kiskolabs.com.

I am using Jonathan Snook’s Simple jQuery Slideshow in this example, but you could really use any JavaScript solution with this HTML/CSS combo. I think it’s easiest if I just show the source code and provide live example for you to try out.

HTML:

<div id="slideshow">
  <img src="1.jpg" />
  <img src="2.jpg" />
  <img src="3.jpg" />
</div>

CSS:

#slideshow {
  width: 100%;
  position: relative;
}

img {
  top: 0;
  left: 0;
  width: 100%;
  max-width: 600px;
  height: auto;
  position: absolute;
}

JavaScript:

$(function () {
	// Simplest jQuery slideshow by Jonathan Snook
	$('#slideshow img:gt(0)').hide();
	setInterval(function () {
		$('#slideshow :first-child').fadeOut(1000)
			.next('img').fadeIn(1000).end().appendTo('#slideshow');
	}, 4000);
});

That’s everything required.

Update:

I made an updated version of this, read the new blog post here and check out the plugin here: responsiveslides.com.

Google Favicon Re-Created with CSS

2010-02-12T00:00:00Z

Forget CSS3, images, semantics, better methods and that it doesn’t make any sense. I did this just for fun. Larger versions are here for illustration purposes only. Use if you want, but I can’t really figure any real world use for this. Nevetheless, this is the 16×16px Google favicon re-created with 256 list items and no images:

Download code

Ariel Salminen

Hiring a Design Engineer for Kesko Design System

Responsibilities #

Experience #

Message from Arielle #

On Freedom, Curiosity & Happiness

1. Freedom #

2. Curiosity #

3. Happiness #

4. Authenticity #

5. Love #

What’s Next? #

Generating LLMs.txt Using Eleventy

What goes into LLMs.txt? #

Preparing Robots.txt #

Creating Template for LLMS.txt #

Adding Posts to LLMS.txt #

Serving Content in Markdown Format #

Adjusting Netlify Headers for .MD and .TXT #

Custom Descriptions for Context #

Complete LLMS Template #

Conclusion #

Further Reading #

Community Assets in Nord Design System

Figma MCP Server

Introducing Brands for Nord Design System

Overview of Changes #

Improved Documentation #

Introducing Community Assets #

Updated Theme Builder #

Updated Color Generator #

Improved Accessibility Checklist #

Deprecating React Components #

Deprecating Vue Types #

Project Statistics #

Conclusion #

Further Reading #

Modern Way to Center Elements with CSS

View Transitions for Any Website

Building Search Index with Eleventy

Getting Started #

Adding Content to the Search Collection #

Creating Search Index Filter #

JSON Output #

Fetching the JSON #

Optimizing Webfont Performance

Ensuring Text Visibility During Loading #

Preloading Webfonts #

Configuring Caching #

Offline Support #

Subsetting Webfonts #

The Outcome #

The 10th Edition of Arielsalminen.com

Behind the Scenes #

Keyboard Shortcuts #

Focus on Accessibility #

Delight with Animations #

The Final Outcome #

Further Reading #

Website Wishlist #

Remember Webrings?

The Blog Questions Challenge

Why did you start blogging in the first place? #

What platform are you using to manage your blog and why did you choose it? #

Have you blogged on other platforms before? #

How do you write your posts? #

When do you feel most inspired to write? #

Do you publish immediately after writing, or do you let it simmer a bit as a draft? #

What's your favourite post on your blog? #

Any future plans for your blog? #

Who’s next? #

A Love Letter

Interview with Design System Guide

My Song

Finalist for the Best Design System Award

Leading Successful Product Teams

Supporting Dark Mode on Your Website

Changing mode based on user preference #

Building support for OS dark mode #

Storing user’s preference #

Responsibilities

Experience

Message from Arielle

1. Freedom

2. Curiosity

3. Happiness

4. Authenticity

5. Love

What’s Next?

What goes into LLMs.txt?

Preparing Robots.txt

Creating Template for LLMS.txt

Adding Posts to LLMS.txt

Serving Content in Markdown Format

Adjusting Netlify Headers for .MD and .TXT

Custom Descriptions for Context

Complete LLMS Template

Conclusion

Further Reading

Overview of Changes

Improved Documentation

Introducing Community Assets

Updated Theme Builder

Updated Color Generator

Improved Accessibility Checklist

Deprecating React Components

Deprecating Vue Types

Project Statistics

Conclusion

Further Reading

Getting Started

Adding Content to the Search Collection

Creating Search Index Filter

JSON Output

Fetching the JSON

Ensuring Text Visibility During Loading

Preloading Webfonts

Configuring Caching

Offline Support

Subsetting Webfonts

The Outcome

Behind the Scenes

Keyboard Shortcuts

Focus on Accessibility

Delight with Animations

The Final Outcome

Further Reading

Website Wishlist

Why did you start blogging in the first place?

What platform are you using to manage your blog and why did you choose it?

Have you blogged on other platforms before?

How do you write your posts?

When do you feel most inspired to write?

Do you publish immediately after writing, or do you let it simmer a bit as a draft?

What's your favourite post on your blog?

Any future plans for your blog?

Who’s next?

Changing mode based on user preference

Building support for OS dark mode

Storing user’s preference

Responsibilities of this role include:

Responsibilities of this role include:

New Packages

Figma Toolkit

Theming

Dark mode

Theme Builder

Design Tokens

Web Components

React Components

CSS Framework

RTL Support and Logical Properties

Nordicons

Webfonts

Nord CDN

Documentation

What’s Coming Next

Tools you can use today

Statistics for the first year

Team has grown from 1 to 4