In this article I will explain how we could use HTML to author web components instead of using JavaScript only.

This article is not about frontend frameworks that all offer one or the other way to work with components. Frameworks are great, but now it’s 2021, and we are now able to create web components as custom elements.

But when I saw examples where HTML templates were defined as plain strings, template literals or even with document.createElement(), I stopped. Why all this special treatment, just to enable encapsulation?

Yes, there are countless libraries that promise to make it easier, but they all require their own syntax with decorators or special conventions. They promise to make things easier, but instead burden us with even more things to learn.

There must be something… simpler?

Introducing: “HTML Components”

It took me a while until I formed a new understanding of HTML. Previously for me, HTML was synonymous with websites.

Until recently, I never thought of HTML files as components. But I think they can be. HTML provides all the parts that we need to author self-contained components that just work on their own. The idea of HTML Components isn’t new. In fact, it has been described already in 1998.

But back to today, with my proof-of-concept, we can import custom elements in two new ways:

Option 1: <custom-element>

This is a special custom element called, well, <custom-element> that will import the component. The imported component will then replace the <custom-element>. This syntax is inspired by elements such as <iframe>, <img>, <object>, <embed>, etc. that use a “src” attribute to embed external content.

After importing the component, you can then also use the component like that: <color-picker>.

Option 2: HTML Import Syntax

Alternatively, we can use the deprecated HTML Imports syntax by adding a link to the head of our document where we want to import the custom element:

With both options, we can use a “name” attribute to set or change the name of the imported component. This can be useful if we’re importing multiple <color-picker> elements. Since HTML components are not responsible for registering themselves, we have control over it.

<link rel="module" href="fancy-color-picker.html" name="color-picker">

Before I go into more detail, here’s an example:

• Here’s a color-picker.html hosted on Codepen.
• Another Codepen that imports the <color-picker>

Since we’re importing .html, not .js, we’ll be able to re-use the structure that HTML provides us, not for a website, but a component:

<head> with <meta> tags

Here, we can define meta data for our component, such as a title or other things that we might be tempted to stuff in a package.json.

<link>

Here, we can import external assets, such as fonts from a CDN or shared styles. Although I believe that components can only be sustainable without hosted external dependencies, linking other First Party resources is useful. Since we’re authoring standard HTML, the browser will take care of loading these resources.

<body>

Here, we can write standard, semantic HTML. The <body> serves as the “root” of our component. We can define <slot> elements, too!

<style>

Here, we can write standard CSS and use standard selectors, even body {} and h1 {}, without thinking about naming and scoping. Imagine it like that: if you open your HTML-Component in your browser, it will behave like a normal website. You only need to think about your component styles, but not the whole world in which the component might be placed later. The ShadowDOM will take care of it.

<script>

Here, we can write standard JavaScript. We can use DOM-APIs such as document.querySelector and element.addEventListener. No class methods, no getter/setters, … We can even load JavaScript libraries here. Don’t feel like syncing data between state and DOM? Try petite-vue, Alpine.js or your favorite reactive state management library.

Wait fool… you’re just describing HTML here!?

That’s right. For me, HTML is sort of a component format. So far we’ve used it to define everything that is required for a website to work. But because components are just smaller versions of that, HTML may be a capable format for authoring web components. You don’t need to learn how to write a constructor for a CustomElement and then figure out a way to write your multi-line template as a string or using createElement() all over the place. All you need is your knowledge about HTML as a document format.

Instead of moving all our web components into JavaScript and with it loose a lot of simplicity, let’s see how far we can take HTML instead.

This sounds too good to be true…

Right. If this was possible through a native browser API, I’d be done here. I’d link to further documentation on MDN and call it a day.

Unfortunately, native HTML imports were forgotten in favour of ES6 Module Imports.

Here’s what user Rounin says on StackOverflow:

It wasn’t so much that the concept behind HTML Imports was no good. It was simply that the implementation architecture — initially developed in 2011, a long time before ES6 Modules were finalised — has proven far from optimal, especially given the evolution, more recently, of more sophisticated technologies.

So while HTML Imports are dead, HTML Modules seem to be an active proposal.

But after briefly looking at it, it looks as if authoring HTML modules requires special treatment:

The template has to go, well, in a <template> tag. That makes the whole thing not work standalone in a browser. The HTML module also has to define exports to then be imported using ES6 module syntax.

To summarize: everything is bended towards JavaScript. And while yes, most web components will be interactive and require JavaScript, let’s not throw all the simplicity and capability that comes with HTML documents over board.

So, how do your boring “HTML Components” work?

It’s simple: we author components in HTML files. Write markup, styles, scripts. We develop and test it in isolation. Now the interesting part is to make the component work in a different environment where it is imported into another component, website or app.

To make components play together, we need a way to control the components from the outside context and a way for our component to communicate with its outside context.

Attributes, Props, …

Usually, we would need to define a static getter observedAttributes where we define the attributes of a custom element. Since we’re not writing a class at all, we need a different way. There are different options:

1. Meta Tags: We could use meta tags in the head of our HTML component and define attributes there.
2. Body Attributes: We could define the attributes on the body of our HTML components. Since this will become the ShadowRoot, it seems like a good option, too.
3. Events: We could use events where we would publish the component’s attributes once it’s instantiated. Doesn’t seem to be quite right, but JavaScript would of course be an option.

For my proof-of-concept I went with attributes on the <body> tag. So any attribute defined here will be used for the custom element definition later.

Inside our HTML component, we can listen for events when attributes change. This is the standard way to communicate between components and is the substitution for attributeChangeCallback(). This also means, that we can technically listen for any attribute change.

Vice versa, when our component changes some attribute, it can notify the hosting component about the change. For that we can use CustomEvents with a details payload.

CSS

Our component will be instantiated with a ShadowRoot.

This is such a good feature because it means we don’t have to worry about our component having any impact on the outside context. On the other hand, if we want to impact the styling of the HTML component itself, we can use CSS Custom Properties.

We can e.g. use a Custom Property for our text and background colors and also provide a fallback value. We can then define these Custom Property values on the outside context. Since the ShadowRoot comes with a {mode: "open"}, these values will be able to affect the HTML component.

We will skip other specifics of style inheritance related to Custom Elements to keep things short.

JavaScript

When we write JavaScript inside our HTML component, we can work with the document as we’re used to. There’s only one magic thing that happens behind the scenes: When you import the HTML component, any use of “document” inside your component will refer to the ShadowRoot. This is not only logical, but also means that the component won’t mess with document that it is embedded in. You still can interact with the outside context, but instead of using “document” directly, you might want to use events to keep things nicely encapsulated.

Okay… so how do I import HTML components?

Okay, we need a small JavaScript runtime for this. But don’t worry. You don’t have to install a library. You also don’t have to include it from a CDN (although you can!).

We’re talking about 50 lines of code and less than 1 KB. We could go through it line by line, but I’ll reserve that for another post.

There’s another reason, why I didn’t make this a “library”: I don’t think this is safe to use. I’m not a web security expert at all and I hope that informed readers will educate me and challenge the approach. What I describe here may not be safely possible in user land.

But maybe browsers could implement something like this. Who knows. I still think you can use this as long as you know what you’re importing (ideally, your own components). As soon as you’d import Third Party code, you should be aware that anything can happen, like in Node.js where we naively install code with dependencies we have no control over…

Where to go from here

This is rather a proposal than a final solution. The proof of concept doesn’t cover edge cases like missing component names, etc. — but it works and covers the “happy path”.

Maybe this whole idea is nuts and won’t fly. Or maybe it inspires people who work on browsers to not just focus on new syntax and JavaScript. Maybe there has been something in front of us all along that we forgot about: HTML.

Read my proposal with code and examples here:
https://gist.github.com/getflourish/a87b990265db8fc243c897f34d32f860

When redesigning a website or simply moving to a new CMS, migrating content is a core task. If you or your client authored hundreds or thousands of article over years, there is no way that you can migrate those by copy & pasting from one CMS to another.

No more database

If your old CMS had a database and your new CMS doesn’t, you need to figure out a way to migrate content from database tables to folders and files. In my case, I didn’t even have access to the database (neither did I want to mess with Drupal anyway).

Migrating without database access? Scrape it!

The good news was that each page on the website output a lot of structure meta data and the content was formatted as simple paragraphs with nothing fancy in between.

Given the structure of the HTML, it seemed very reasonable to migrate content by first scraping it from the website.

1. Scrape the content from the website
2. Format the content and meta data to match the new content structure
3. Generate Markdown files

Why scraping?

• Need to migrate a website to a flat file CMS, like Statamic or Kirby
• No access to the original database of a website
• No knowledge of the current CMS
• No easy way to export from the current CMS
• No way to import content into a flat file CMS other than creating files

Why not use the Statamic Importer?

While the importer can handle a collection of JSON content and generate entries from it, it has a drawback:

• no support for multi-lingual content

Statamic on Twitter

@getflourish Ahh, the importer doesn't support multi-lingual. It's possible to add support for it, but new features are slow in coming for v2 as v3 is right around the bend. 🤔

In my case, it was necessary to import entries in German and French, thus I had two options:

• use my poor PHP skills to hack around with the importer to support multiple languages
• generate .md files and copy them to the content folder (one folder per language)

Scraping

Without this library for NodeJS, this project would have not been possible. The sitemap-generator is intended to generate a XML Sitemap for a website and does so fairly well! Simply pass it a base URL and start the generator.

lgraubner/sitemap-generator

const SitemapGenerator = require("sitemap-generator");
const baseUrl = "https://your-base-url.com/some-path";

const generator = SitemapGenerator(baseUrl, {

  stripQuerystring: false

})

In order to generate the sitemap, the script crawls the entire website with all the links between the pages.

But instead of waiting for the script to finish and output the XML, I’ve used the callback function every time a new link is being added to the sitemap.

// register event listeners

generator.on('add', (url) => {
  // new link found
});

Parsing

Now, whenever we receive a new URL, we can fetch the URL and wait for the response which will be a string of HTML.

Using the library JSDOM we can then turn the string into a in memory document object model (DOM) that acts like a real DOM.

// Construct a new in-memory DOM from the HTML string
let document = new jsdom.JSDOM(htmlString).window.document;

This allows us to use querySelectors etc. to parse anything from each document. For example meta-tags, title, body content, …

For example, to receive the meta description, we can use:

document.querySelector("meta[name='description']").content;

When querying actual HTML content, such as an article, we might want to strip some of the HTML. We could:

• use innerText and remove any HTML / formatting
• use innerHTML and convert it to Markdown

The benefit from converting to Markdown is that line breaks and some formatting like bold, italic and headings are preserved.

I’ve used Turndown for this task.

domchristie/turndown

var TurndownService = require("turndown");

var turndownService = new TurndownService();

let node = document.querySelector("article");

let markdown = turndownService.turndown(node.innerHTML);

From all the queried information, we can then construct objects for each URL:

let data = {
  url,
  title,
  description, 
  markdown,
  ...
}

And ultimately collect all those chunks of data in an Array or Object which we can save to disk once the scraper is done.

fs.writeFile(output, JSON.stringify(collection), function(err) {
  if (err) {return console.log(err);}
  console.log("The file was saved!");
});

Transformation

Okay, it’s simple to get the data as JSON. But some flat file content management systems require markdown files in YAML format.

Fortunately, there is JS-YAML for that.

nodeca/js-yaml

Using this library, we can reformat the JSON to match the intended structure and then write individual files for each entry of the original collection.

yaml.safeDump(entry, { lineWidth: Infinity });

I’m not sure anymore if the lineWidth parameter is required, but it can help to avoid unnecessary line breaks when converting text to YAML.

Strip whitespace, control characters, etc.

When copy & pasting content from PDF to a CMS, editors might actually copy invisible control characters. While invisible to the reader, a converter like JS-YAML might get into trouble.

From my experience, it meant that paragraphs and new lines where output as literal “\n” which is not how a human would make a new line in markdown. I did ran a few regex before converting to YAML.

For example to replace some invisible whitespace with nothing:

processedText.replace(/›•/g, "");

Note: The • character is used to represent an actual invisible character.

I’ve tried some Regex ranges to only include visible ASCII characters but ultimately ended up manually creating rules for all the unwanted characters I could find in my content files.

Generating Markdown files

I then saved all the files with a specific format using the original publish date and slug.

German entries went into the root of the folder, French entries into a “fr” subfolder.

It was important that I both files shared the same UUID. For Statamic this must be a UUID/4.

Florian Schulz on Twitter

@statamic Okay, got it. The Index seems to get really confused when manually adding collection files using ids other than uuidv4. is_id() insider helpers.php and PathTags.php are responsible, probably for a good reason.

Once I figured out that I can’t just use any ID (like “123”), I simply switched to assigning each entry a UUID.

kelektiv/node-uuid

const uuidv4 = require('uuid/v4');
uuidv4(); // ⇨ '1b9d6bcd-bbfd-4b2d-9b5d-ab8dfbbd4bed

After running the script, it generated hundreds of markdown files, neatly organized in one folder per language, ready to import!

Summary

While there aren’t many steps and code involved, there were a few details that I had to figure out along the way. Once I had a nice big chunk of JSON with all the content, it was clear to me that this could be transformed into any structure required by the CMS.

I initially hoped that the Importer could do its magic by feeding it the JSON, but it turned out that it didn’t support multi-language content. Thus, I had to re-format the data, convert it to YAML and mess around with hidden white space, control characters and the like, but finally it worked out!

Based on my experience with Vue.js

Preface

I’ve been designing and developing components with Vue.js for the past 4 years and I’m really happy with it as it helps me to build prototypes and web apps in a fast and sane way.

When I recently started designing components with Angular, I knew that I had to expect more verbose code, boilerplate and not so great performance in general. The templating syntax has some quirks, but most of it comes down to “getting used to it”.

Syntax in Vue
v-model, v-on:click, v-bind:class, v-for, v-if

Syntax in Angular
[(ngModel)], (click), (class), *ngFor, *ngIf

The differences in the JavaScript part (module, component etc.) are bigger since Angular makes use of TypeScript, Classes, Decorators, Services, etc. and Vue is more or less a single JavaScript Object with some conventions.

But besides the things that exist in both frameworks in different ways, I’ve found some things that I had grown used to when working with Vue, that took me a while to figure out because they are not documented or a core feature of Angular.

• Hot module replacement
• Dynamic component rendering
• Transparent wrapper components
• Forwarding element attributes from the host component to a child
• Two way data binding with ngModel on custom components

Hot module replacement

When starting a new project via the vue-cli, hot module replacement is enabled out of the box. This is a massive improvement to the development experience and velocity. When making changes to code, instead of reloading the page manually, all state is maintained, style changes are applied in an instant, the page remains its scroll position, dialogs remain in their opened state, … 😍

Unfortunately, the Angular CLI does not ship with Hot Module Replacement. While in theory there is an option baked in to enable it, the actual activation requires quite some configuration in a variety of files and dependency on a 3rd party npm package. It’s not difficult to enable, but requires a new environment setup. 😫

Figuring out how to do this wasn’t easy either. It’s not like there is official doumentation on the Angular website for it. To make it easier for you, here is it, the guide to implementing Hot Module Replacement in Angular projects: https://github.com/angular/angular-cli/wiki/stories-configure-hmr

I think a lot of Angular developers are missing out on that feature that other frameworks, like Vue.js have built in. While I successfully implemented HMR, the experience is not quite like what Vue.js has to offer. Maintaining state is something you still would need to figure out yourself and CSS changes will still cause a re-compilation. This takes extra configuration and guides with issues to get it to work 😅

Out of the box, Angular makes frontend design quite hard. Longer compile times, no state persistence, hard reloads of the page add a lot of friction. 😢

Dynamic component rendering

When dynamically rendering components, for example from a JSON representation of a nested component structure, Vue.js shines because it has the “is” attribute. One can pass in a component name that matches some imported component and it will render as such. 😎

This allows you to render dynamic interfaces based on structured data, such as forms etc.

While Angular can do this, too, you need to write more code, using ComponentFactoryResolver, methods and whatnot 😫 It could be so simple!

https://angular.io/guide/dynamic-component-loader

Custom components with Two-way data binding

In Vue you can simply $emit a change event or input event from a custom component to enable v-model support. If you want to use ngModel on a custom component in Angular you need to implement an interface called ControlValueAccessor and a few more methods.

https://rangle.io/blog/angular-2-ngmodel-and-custom-form-components/

Transparent wrapper components

Since components in Vue can be defined in a template tag, you can easily create custom components that simple wrap single native elements, such as a button component that consists of a button but with an extended API (props, states, …). Vue will then only render that native button, and won’t show the custom component name in the DOM.

Angular on the other hand seems to render the custom component and the internals. This means, that you end up with a wrapper component and the native components.

This is probably the reason why Angular Material implements buttons using attributes, such as: <button matButton>. While this makes sense to avoid bloating the DOM, it also make the API inconsistent. Some components are implemented using attributes, some using custom selectors…

Forwarding element attributes from host to child

When creating components that are composed of native elements, such as button, input, etc. it can be useful if the custom component can immitate a native component.

For example a custom component might want to behave similar to it’s native pendant:

By default, Vue.js binds all attributes from the custom component instance onto the outer element of the component. In the case of the range slider, the component only exists of one element, this the input will receive all the attributes. Great! No need for custom API / props, because the native attributes do all the work for free! 👌

This gets more tricky, given a search field that should have a search icon and a loading spinner included. We could design a custom search component like this in Vue.js:

<custom-search v-model=“query” disabled />

or in Angular like this:

<custom-search [(ngModel)]=“query” disabled />

Implemented as a component in Vue like this:

Unfortunately, Vue needs a single child inside a component which is why the above example wraps everything in a div. Angular doesn’t, which is nicer. So you can easily create such a component template in Angular:

This component would result in an input with an icon displayed in front of it and a loading indicator after it (given the required CSS). To be able to control the custom-search like a normal input field, the Vue.js implementation can pass on all attributes onto the input field using v-bind=“$attrs”.

<input type=“search” v-bind=“$attrs” />

In that way, all the attributes from the <custom-search> will be applied to the nested input field. Cool! 🕹

In Angular it is not so easy and you actually need to implement code that copies all the attributes from the host component OnInit. 😫

https://stackoverflow.com/questions/43785547/angular2-passing-all-the-attributes-to-the-child-component

There are many more details that are more complicated to setup in Angular but at the end of the day most things work out.

I definitely prefer the simplicity of Vue.js when it comes to component design and frontend performance. But in practice the frameworks don’t differ too much anyway.

Vice versa, Angular shows the power of TypeScript and makes development much easier/safer. Can’t wait to benefit from this with the upcoming Vue.js 3.0 written in TypeScript 🍭

If something I wrote about doesn’t make sense or there are better ways to deal with the described drawbacks, please share your thoughts. I found it quite hard to find code examples, also because the terminology in Angular is different than it is in Vue, React, etc. 🕵️‍♂️

Switching from Vue to Angular is probably rare (https://stateofjs.co) but sometimes you have to work with what you’ve got. Designing good component design applies to any framework and ultimately the differences aren’t that big. I was afraid to check out Angular at first, but realized, it’s not so bad as I had expected.

I will certainly prefer Vue over Angular, but with so many languages and frameworks available, it’s always good to look beyond the tellerrand.

Two years ago, I published “Designing with Intent” in which I wrote about design tools that can capture the intent and relationships of a design in addition to mere properties and values.

Back then, I used methods like “interpolation” and concepts like “contrast” to describe a way of thinking and designing in extremes — between minimum and maximum states.

Instead of tweaking a dozen different font sizes for headings and body copy, one could define the base font size and scale factor that control the hierarchy between all of them.

Instead of tweaking text color and background color individually, one could define the desired contrast between them.

Instead of tweaking line spacing, font sizes, font weights, letter spacing, etc. for different screen sizes, one could define the relationship between those properties and have them dynamically adjust.

In the meantime, I took those concepts further and turned them into a web design tool, aimed at helping design for the browser, in the browser. With Ratio, I’m trying to turn my knowledge about design, writing CSS and creating design systems into a series of tools that enable both designers and developers to explore more and worry less.

This article explains some of my thinking behind Ratio and introduces some aspects of the interface in greater detail.

But before I go into that, I want to elaborate a little bit on design and programming and the popular question “Should designers code?”

Programming design

I think programming can be part of a design process, but it should not require switching to a text editor to do so. Creating abstractions and establishing intentional relationships are concepts that are too powerful to stay outside of a designer’s toolbox. They enable working with a dynamic medium and taming the uncontrollable.

The concepts that I wrote about two years ago actually don’t require a lot of code. But they do require fiddling with your text editor in order to fine tune values by typing numbers. They require getting out of the design tool in order to design.

In his genuine book “Flexible Typesetting”, Tim Brown wrote:

Your design tool is working against you. It is stuck in the traditional mindset of absolute measurements. This is precisely one reason why people very good at web design argue that designers should learn to write code. No mainstream design tools — and I work for a company that makes mainstream design tools — are completely appropriate for the practice of typesetting today. Some of the smartest people I know are building more appropriate tools, but for now you’ll need to make design decisions by writing and testing code. — Tim Brown, Flexible Typesetting

I fully agree and believe that a way to express and use more dynamic and flexible design concepts in an actual design environment would be beneficial for many people. It would be a lost oppurtunity for designers to leave those techniques up to developers to figure out how to implement design. Instead, we could be using aspects of programming — variables, interpolation, functions — to actually design.

If we utilize dynamic units, calculations and formulas, we can start to take back control over the web as a design medium. When we let go of the static mindset that comes with pages and artboards — fixed snapshots of an inherently dynamic medium — we can start to embrace the real potential of the web.

We can start to actually design interactivity. We can do the exciting work that’s all too often left to the developer’s interpretation. We can start to think in terms of intention and abstraction. When we think about web design, we need to think about the whole system and how things relate to each other.

It’s about the relationships, the boundaries, the extremes, and everything in between.

But in order to do so, we need tools to free our mind. We need tools that get out of the way. We need tools that allow us to design at the speed of thought. We need tools that are fluid and adapt. We need tools that suit us. Thus, we need to shape our own tools so that they can shape our work.

Introducing: Ratio

Instead of waiting for others to build a better design environment, I’ve created it myself. It’s called Ratio. It combines modular scales, fluid typography, color transformations, design tokens and the layout power of modern browsers.

Ratio equips designers with the same tools and concepts that developers use to implement complex design systems. Take creative control over typography, color, time and space by using variables, scales and functions. By appreciating the abstract and rationale, designers get the chance to explore more and worry less. Discovery instead of pixel pushing.

Under the hood, design in Ratio is powered by CSS. Thus, you can do everything that CSS can do. It’s certainly not the first tool doing that, but my approach is to be slightly more transparent about the underlying code and utilize it. If you want, you can always do some hand-coding in between.

But more importantly, Ratio provides interfaces that help you work with CSS without actually writing it. It helps you to visualize your design system and create abstractions when you want to. It’s my personal take on the web inspector. I love web inspectors and what they can do. But what I want is a web creator.

The power of CSS

Building a tool on top of CSS comes with a lot of built-in responsive design features. Just think about all the relative size units that you can work with: %, em, rem, vh, vw, and many more that enable us to encode relationships for dynamic design systems.

• % — a fraction of the element’s parent’s width
• em — a size relative to the element’s font size
• rem — a size relative to the root element’s font size
• vh — a fraction of the viewport’s height
• vw — a fraction of the viewport’s width
• vmax — the larger value of either the width or height of the viewport

Modern browsers support almost 500 CSS properties and CSS has become more and more powerful in recent years. One of the most recent additions, CSS Grid, introduces new units like fr (fraction), and functions like calc, repeat, min, max and minmax help to create flexible layouts.

With web fonts, OpenType features, media queries, flex-box, grid, transitions and animations we have all the styling possibilities needed to create beautiful interfaces.

Of course, for some things you’ll be better off using Canvas, WebGL or Shaders — but CSS on its own can do a lot. And with ambitious projects like Houdini, we might be able to invent new CSS properties which could turn CSS into an even more universal way to describe design with almost endless possibilities.

Auto-complete for design

Unfortunately, CSS is still a big black box to many since there are so many properties available and some properties are tedious to type. The good news: Ratio knows about all those properties and auto-completes them for you. It also provides abbreviations for the most commonly used properties, so you can just type “ff” to find “font-family”. Developers may know this from Emmet.

Another complexity of CSS is that all properties have default values, that you need to override to achieve your desired style. In order to figure out those default values, it’s often necessary to use the web inspector (think: default form element styles).

Ratio shows you those computed values right away — and you even learn about the default values. Did you know that the default text-align value is not “left”, but “start”? I didn’t, but it makes sense in order to support right-to-left languages.

The inspector interface also encourages you to re-use defined values, by offering you auto-completion. Even though your code editor may already be smart enough to collect defined properties, in Ratio, you will actually see the values that are meant to be re-used.

Design tokens

For many years, web developers have been using pre-processors like Sass or Less to extend the capabilities of CSS. A main feature that came with those were variables. This fundamental programming concept allowed developers to write more maintainable code. Variables have been useful to store color values, breakpoints, spacing values, timing values and typographic features.

With the rise of design systems on the web, re-using design properties has also arrived in the mindset of product designers. Design tokens, as popularized by Jina Anne (former Salesforce, Lightning Design System), are especially useful in the context of theming.

Ratio allows for the creation of variables in form of design tokens. Collections of design tokens can be created for any property: color, font-size, margin, box-shadow, border-radius, … really anything. By creating design tokens, you provide meaningful names to values. Those names will then be available and searchable in Ratio’s CSS inspector.

Being able to save common values for individual style properties is a fundamental tool for maintaining consistency, enables re-use of design systems, theming and is also a really fast way to style — by using the name of a design token instead of typing long and cryptic values over and over again. Naming becomes a design tool, rather than an afterthought in development.

Fluid Typography

While design tokens can be added manually, they can also be generated, scaled and interpolated across breakpoints. This enables the setup of modular scales and fluid typography. Instead of messing with individual font sizes of paragraphs, headings, blockquotes etc., you simply define base font sizes and scale ratios and let interpolation do the rest.

What may sound complicated and require some initial understanding of the concept, results in a very powerful mechanism to work with type that can be controlled by a few values and sliders. Ratio helps here by providing an interface to otherwise complex CSS formulas or Sass mixins.

Note: Setting up fluid type isn’t a special concept that only works for font sizes, but it’s a universal mechanism of programming design with Ratio. The interface applies to any property and can be useful for line spacing, margins, paddings, colors, shadows and more.

Inspectors in Ratio

Ratio doesn’t try to just give you a single all-purpose design inspector, but instead offers multiple different perspectives on code. That way, Ratio supports both sides of web design: exploration and engineering. With Ratio, you are in full control over individual properties, but you are also able to set up systems that orchestrate more than one thing at a time.

Color Canvas

For example, the color canvas visualizes connections between colors and can be used to transform from one color into another. As known from CSS pre-processors, colors can be darkened, lightened, shifted in hue, desaturated and more. Those are powerful mechanisms not only for developers that want to write less code, but also for designers that want to explore color combinations and design with theming in mind.

The color canvas might not be needed for smaller projects, but certainly shines with complex ones.

Complex systems, such as operating systems or business applications, may use several levels of color abstraction. For instance, MacOS recently introduced Dark Mode and encourages developers to use their color variables found inside NSColor. A different example with five levels of abstraction is Nylas Mail that can serve as an inspiration for setting up colors in Ratio.

In any case, the color canvas can be a great way to explain color systems to collaborators who would otherwise need to imagine it by reading source code or by building a style guide. With Ratio, visualizations that are often left to documentation become actual tools.

Driver Inspector

Another example of visualization of code is the driver inspector, an interface that works similar to a timeline in video editing tools. In addition to time, it can be used to manipulate values based on other variable inputs such as window size (breakpoints), scroll position (parallax scrolling), mouse position and more.

Each selector is shown with tracks for each property that has changing values. You can use the driver inspector to add, remove and move keyframes or change their corresponding values. It’s a simple way to see what is otherwise hidden in multiple places in your source code.

Credit where credit is due, Principle for Mac has been the main inspiration for using a timeline interface for more than just time.

CSS Inspector

When you select a layer in Ratio, you can see its related CSS declarations in the CSS inspector. That way, you have full access and control over styles — no limits. It’s like writing CSS to a file. But, compared to text editors, Ratio filters out the noise of other selectors so that you don’t need to scroll, jump and search around in your CSS files.

While showing you less, it also shows you more: The inspector highlights use of variables (design tokens), groups breakpoints per property and shows related selectors, such as hover states.

When you want to create a new rule for an existing selector, the inspector searches through all the existing selectors. When you type a selector that has already been defined, Ratio will enter the selector instead of creating it again. The interface prevents you from making unnecessary duplications. It’s like appending new CSS rules to the end of a file but the computer’s automatically cleaning up for you.

Style Dial

The style dial is the gestural counter part to the CSS inspector. It’s a compact interface that combines the most important aspects of typography, color and space into a radial menu. Instead of typing values, it allows you to spin/scroll values up or down while keeping your eyes on the content. The contextual menu has been designed for freestyle design exploration without constraints.

Since it supports keyboard shortcuts to switch between properties, tweaking font size, line height, letter spacing can become a fluid process of scrolling up/down and switching between tools using the keyboard — all while staying focussed on the actual text layer.

Extensibility

While Ratio already offers many different perspectives and interfaces on CSS, there are many more possibilities and web developers have already built tools for specific tasks.

CSS gradient generators, border radius tools, grid builders, color palette generators, modular scales, font pairing tools, … there will always be the need and desire to build custom interfaces and features. Thus, it is important to me that Ratio can be extended and that for instance design tokens can be generated by external tools.

To illustrate this, here’s an integration of the harmonious color palette generator by meodai. David is an expert when it comes to color systems and he’s built dozens of different interfaces to work with color. Using a simple mechanism, his existing web app can hook into Ratio and provide colors for it.

I want Ratio to provide the core tools on its own, but being an active Sketch and Adobe XD plugin developer, I think it’s important to build in extensibility right from the beginning.

A broader understanding of code

For now, we’re used to call code what is plain text in text files that get compiled and can run in a browser. But any form of communication is code. Any word we say, write, any image we draw, encodes information. It’s up to the other to interpret and understand.

When we start to loose our fear of the term code and programming, we can start to see behind the actual principles. The logic. The conditions. The meaning. The rules. It’s what we all work with, but often neglect. But if we embrace them, we can start to design with ratio. We need to become aware of the reasons behind our choices and decisions. And we then need the right tools to capture and express them.

[…] I hope this book inspires you. You can shape the words we use. You can influence design tools and do original work. You can return to tradition and map treasured, old advice onto this new world. — Tim Brown, Flexible Typesetting, p. 205

While I was already deeply working on Ratio, reading this sentence was a great reassurance and motivation to keep moving. Thanks Tim Brown!

The future of Ratio

Ratio is currently in closed Alpha with everything presented here being functional as shown in the video. In a future story I will write about technical aspects of Ratio and how it fits in with your existing projects and workflows.

From designers who want to design in the browser, to designers who want to simply tweak the last design details of a developed site, all the way to developers using it to setup design systems, there are many use cases that I have in mind.

If you are interested in future stories about Ratio, make sure to follow me here and @useratio on Twitter.

Sign up to be notified about the public release on useratio.com

Twitter and Facebook use infinite news feeds to display content. Seemingly simple, somewhat chronologically ordered, but algorithmically prioritized content of people, companies and news organizations you follow. Prioritizing and promoting content based on “relevance” is an attempt to handle the sheer amount of information being posted.

For example, the more you interact with someone or the more someone posts, the greater the chance that their tweets show up at the top of your news feed. People you never interact with or who post once a month are likely to be unseen and lost forever. Out of sight, out of mind.

Besides the filtering, the core idea still is: what’s new is more important. The newer something is, the higher up it appears in the feed. Nothing more boring than the news from yesterday. Or the last hour.

But wasn’t this supposed to be a social network? Something about people and keeping in touch? Unfortunately, it’s impossible to catch up when you are flooded by tweets, retweets, news, and spam and have no sense of start and end.

Let’s rethink the design.

Inbox everyone

Let’s hide all content from the feed. Let’s display all the people you are following. A complete list of all the people you are interested in. Name, avatar, date of last tweet. That’s it.

Reverse order

Now, instead of designing this as a news feed with the latest news on top, let’s reverse the order. Someone who tweeted a month ago is shown first, someone who just tweeted, all the way down at the bottom. In my case this revealed a few people who last tweeted 7 years ago.

Archive

Since we display all the people you are following, this would result in a very long list, and the old tweets you’ve already seen would always stick at the top. That doesn’t make sense. That’s why common news feeds don’t work this way.

But: While scrolling past people, we can mark them as “seen” and hide them until they post something again. A timestamp becomes the single filter that defines what we see or don’t see.

Time to catch up

Instead of hunting for the latest and greatest news, we now have a design that makes sure that every single person we’re following can be seen. Now, it is our choice to skim and scroll past them. It is our choice to tap and actively view the content. We are no longer distracted by images, animated GIFs or ads. Instead, we are driven by people and our interest in what they had to say — even if that was last week.

Back to the roots

By hiding retweets, favorites and replies, the design puts emphasis back on the original thoughts that people shared with the world, valuing the rare moments that people took time and energy to write something of their own. Likes and retweets can stay in the fast food feed.

Unfollow

Now, you may stumble upon people who haven’t appeared in your feed in a while, you may find that some of them are not interesting to you anymore. Such an interface makes it easy to unfollow them on the go. A nice side effect.

Why is this better?

1. You won’t miss activity from people who rarely tweet. Tweeting less doesn’t mean the content is not worth seeing. If people you care about say something, it matters.
2. People who tweet a lot will still show up, but never multiple times. They get one slot like everyone else. News organizations and other high frequency accounts will always be around, but not outrank the people who tweet once in a while.
3. It’s you doing the filtering, not the algorithm. By seeing the faces and names of people, you are likely to only look at the ones that seem relevant at this moment in time. Interested in tech? Look at the people you know work in that field. Interested in politics right now? You might look at other accounts instead.
4. Other than with the infinite scrolling feed, this design provides a clear start and end. We can explicitly display the number of accounts that you haven’t looked at. Transparent and finite.

But isn’t this… stressful?

You might think that this design would make you want to look at every single person’s recent tweet in order not to miss anything. Or to scroll to the bottom to see the most recent news. If you follow hundreds or thousands of people, yes, that would be a lot of work. But here’s the thing: by hiding distracting content and focusing on people, this design doesn’t entice you to look at everything and instead encourages you to choose consciously. I think that Twitter should not just be about news. It should also enable you to see what friends and colleagues, who are neither hyper active nor famous, share with the world.

Demo

Want to give it a try? Sign in with your own Twitter account to explore this concept. You can view all your followers, read their most recent tweet and tap into their timeline to read more. The site also remembers where you’ve left off, so that next time you visit, you can continue at the same point in time.

👉 www.florianschulz.info/twitter

Conclusion

I don’t see this as the one and only view that is better than a personalized feed. But it is another way to look at content. Maybe users could choose their own priority: be it latest news, or the things people had to say. The latter may be more work and less entertaining. But it might be more meaningful and helpful to stay in touch with the people we chose to follow.

In many aspects, smartphones are superior to their desktop counterparts. One killer feature of smartphones are their cameras whose image quality is so much better compared to integrated webcams of a desktop computer.

On the other hand, desktop computers are often more suited for work that requires large screen real estate and for working with files across different apps.

While working on Tracy, a web app that converts photos of sketches and drawings to vector graphics, I wanted to combine the benefits of both device types. I needed a simple way to transfer the drawings in front of me to my computer.

The usual workflow of getting a photo to my computer looks like this: Take a photo, wait for it to upload to the cloud (or get frustrated that it doesn’t work yet again), find the photo in the photos app, drag & drop it into the browser window. Cumbersome. Instead, with WebSockets, we can turn the smartphone into a connected scanner that can transfer photos directly to the desktop web app.

The following article will explain how I use WebSockets within Tracy to enable cross device communication. I will provide code snippets and a step by step tutorial on how to transfer images from a mobile browser to a desktop browser.

What are WebSockets?

WebSockets enable developers to push data between devices in real time without the need to store any data. WebSockets require a server that can send and receive data in form of messages, files, images, etc.

In our case we expect two clients: a desktop website and a mobile website. Both will share data with the server which immediately forwards data to all clients. Similar to a private conversation between you and a friend, we will need a shared channel for our cross device communication.

SocketIO is a JavaScript library that provides a concept of rooms that allows clients to join a room and then emit or broadcast messages to clients in that room. The name of a room can be any string, but in our case it will be a very long random ID that I will explain later.

For the server implementation, we will need Node.js. If you don’t have it, download and install it from here: https://nodejs.org/en/

Then:

1. Create a new folder
2. In that folder, create a file called package.json
3. Copy the following code into package.json

4. In Terminal, enter:

cd path/to/your/folder

5. In Terminal, enter

npm install

This will install our Node.js project and all its dependencies. Since we have Express and SocketIO already defined in our package.json, both packages will automatically be installed.

Server Code

Now, we will need to open and edit the index.js file. There we will add a few lines of code to setup an Express Server that will listen and react to messages coming through the WebSocket.

In your project folder, create a file called index.js and paste the following JavaScript code:

After importing required packages, the server will be started and it will serve a file called index.html that doesn’t exist yet. Because we might want to deploy the server on Heroku later, the port will be dynamically set by the environment variable, otherwise it defaults to 3000.

The WebSocket will then listen for clients to connect. Then, after a client requests to join a room, the WebSocket will capture and broadcast events from one client to all other clients in the same room.

Start the server
In Terminal, type:

npm start

This will start the server at http://localhost:3000. Nothing will happen so far. But we’ll soon connect a few clients…

Client Code

The client example shows a simple website with a file input field and an empty image element. Images selected through the file input will appear in the image element — on all websites.

In your project folder, create a file called index.html and paste the following JavaScript code:

If you now open localhost:3000 you should see a website with an input field.

Open the website in two browsers, select an image file in one and you should see the image appear in both browsers.

In the head of the page we see a JavaScript reference to /socket.io/socket.io.js which is a magic line of code because this JavaScript file doesn’t actually exist in our project.

But because we are running our own Node.js server with SocketIO installed, it will automatically provide a client version of SocketIO that we need to communicate with the server. Alternatively, we could link to a local or CDN version of socket.io.js.

We can then get an instance of SocketIO that, by default, connects to our local server:

After getting references to DOM elements, we join a room called “test”.

A channel name can be any string. Anyone who knows the room name could join it. In order to prevent strangers, you might want to generate very long random room names, such as “5bbad6cf-0e8d-43ce-b7d0-dc6e5726c8fa”.

This so called “UUID” is almost impossible to guess. In the case of Tracy, the desktop website takes care of generating the room ID. After the website has finished loading, the ID will be generated and the “join” event will be sent to the WebSocket.

Tracy then generates a QR code containing the room ID, so that other clients can join the same room. Such UUIDs can be generated using this package: https://www.npmjs.com/package/uuid4

In our example, all clients join the same, hard-coded room called “test” so there is no need to share the name of the room between clients.

After all this, the code takes care of reacting to changes of the file input, reading the file and emitting an event to the WebSocket with the actual image data.

And finally we’re also setting up a listener to receive image events that will then set the image’s src attribute.

In a real app, you might want to do more things such as detecting when a client connects or disconnects. Tracy also sends events when the image transfer starts and finishes so that the app can show a loading indicator.

Deploy

So far, the server and WebSocket run on our local machine. In order to make the project accessible at any time, we need to deploy it. If you don’t know how to host Node.js apps yourself, you can do this by using Heroku and Github.

1. Create a Github account and push the code to a repository
2. Create a Heroku account
3. Create a new app on Heroku
4. In the deploy tab, set up automatic deployments from Github
5. Make sure you have the Node.js Buildpack enabled in your app’s settings

With this integration, every time our code changes on Github, Heroku will deploy a new version. We can then also use the public URL of our app in other client apps using WebSockets. We simply need to tell SocketIO the address of our server.

var socket = io(https://your-app.herokuapp.com);

This will allow you to create apps on your local machine and use the Heroku server for communication only.

That’s it. It took me a while to learn about WebSockets, Socket.IO and figure out how all the pieces need to be connected. After I figured it out, I was quite happy how little code is required and how powerful the concept is.

❤️ WebSockets

A note on WebRTC

If you were wondering why we’d need a server at all… good point! Since we only want to send images between two clients, we don’t need a server. With improving support of WebRTC (Web Real Time Communication), we will soon be able to reliably establish direct connections between browsers. Unfortunately, WebRTC still requires a server to authenticate and establish connections. So while in theory WebRTC would be a better fit for sharing data between browsers, the setup is not simpler than using WebSockets which have far better browser support.

An attempt to build a font database with opentype.js

Even years after Avatar’s release, there’s one thing Ryan Gosling just can’t get over: the choice of the movie’s logo font “Papyrus”. In the parody produced by Saturday Night Live, the designer of the logo opens the font menu, browses the fonts one by one, and randomly decides to go with “Papyrus”.

The seemingly mindless choice of a font is a general problem with font menus: there are either too few or too many options.

On one hand, a limitation to system fonts, as seen in the video, can lead to a bad choice because there simply isn’t something better installed.

On the other hand, web font libraries with hundreds or thousands of fonts can be quite overwhelming and lead to a paradox of choice.

Dinner for none: The font menu’s bitter taste

The average font menu presents a list of available fonts, sorted by name, but completely unrelated otherwise: A typeface designed for bold headlines is followed by one designed for small user interfaces and then a fancy script typeface made for wedding invitations shows up. Now you either get trapped in a time consuming process of scrolling through the whole list from start to end or you simply decide to pick the first best match from the upper part of the list and call it a day.

This is obviously not an interface made for systematic exploration — but infinite surprises. While I like to be surprised, I also like to influence my odds.

A systematic approach to finding typefaces

There are various ways to limit the options. Before I dive into parsing font files, glyphs and metadata tables, let’s first have a look at classification, curated lists and then anatomy.

1. Classification

Early in design school I’ve learned about the history of writing and practiced calligraphy to understand how writing evolved and how tools had an immediate impact on the design of type faces.

This lead to sophisticated systems for classifying fonts based on their appearance throughout history. The simplest classifications are serif, sans-serif, monospaced, script and display typefaces. We can usually find those classes in form of filters on any font website:

Those simple filters might still give us too many options. That’s when more specific terms such as transitional serif, humanist serif or blackletter can be introduced to differentiate typefaces of the class serif.

Sometimes those subcategories are available as tags. But sometimes they just don’t exist in such detail. Maybe there are too many categories? Maybe users don’t understand all those options? Maybe there is just no complete and consistent data available?

2. Curated Lists

Another way to put order into the chaos is to rely on the knowledge of others: Human-curated font lists. We can find those for example on Fontshop. There you can find collections based around a decade in history such as “1930”, based on similarity such as “Helvetica Alternatives” or application specific lists like “Branding” or “Newspapers”.

Similar lists can be found on Typekit, TypeWolf or FontsInUse. I think those lists are great and I encourage everyone to start making their own lists with fonts you have already worked with or seen in application. It will pay off in the future to have those references.

3. Anatomy

The most complex way to look at typefaces is to focus on their design details and to try to understand what makes a typeface good or special. Fortunately, there are books on type design, typefaces and typography. They can teach us how to make typefaces, how to choose them and how to use them.

One of those books is “The Anatomy of Type” by Stephen Coles. A few years after design school, this book was a refresher that reveals details about 100 well established typefaces. Stephen Coles uses terms such as x-height, width, weight, ball terminals, serif style and others to describe the quality of typefaces.

After looking at those 100 typefaces I thought: what about the rest? What about the fonts on my computer? And the ones on the web? What are their xheight, width, weight and contrast? How can I find out?

Inside a font file: Lack of meta data

Before I started coding, I was hoping that I could find out about the properties of a font in an easy way. In theory, every font file comes with a variety of metadata tables that contain information about name, author, language and visual characteristics of the typeface. Width, weight and font family class are the obvious ones. But also information about xheight, cap height, average char width, ascenders and descenders could be found. Another set of metadata called Panose describes even more properties such as serif style, proportion, contrast and many more. Using font design apps such as Glyphs, anyone can inspect fonts to view this information:

But the availability of this information depends on the work that has been put into making the font. While some fonts provide a lot of information, this isn’t always the case, especially not for free or open source fonts such as the ones from Google Fonts. But even if information is provided, it’s not necessarily consistent or complete enough to make comparisons based on it.

DIY: Parsing fonts with opentype.js

So in order to classify and compare typefaces myself, I had to take a close look at font files and find automatic ways to extract information. Fonts are available in a variety of file formats, but eventually they are almost always available as TTF (TrueType Fonts).

Other formats are OTF (OpenType) that includes information for additional features such as ligatures or WOFF (Web Open Font Format) that can compress the font and store additional meta data.

These days, thanks to Frederik De Bleser’s opentype.js, we can inspect font files using JavaScript in a web browser. Opentype.js gives us access to vector information of all the glyphs included in a font file and it also provides access to key metrics and metadata tables.

A database of characteristics

In the following section I will describe how I measured contrast, x-height, width and weight of all fonts provided in the Google Fonts Library. The same methods could be applied to other font libraries such as Typekit or fonts from your computer.

Stroke contrast

The contrast describes the ratio of thin to thick strokes. There are typefaces with little stroke contrast, e.g. slab serifs or many sans serif typefaces designed for user interfaces, e.g. Roboto or San Francisco. There are others with a lot of contrast, such as Bodoni or Didot. To measure the contrast, we can trace the outlines of an “o” and look for the smallest and largest distances between inner and outer shape.

It’s a simple and comparable letter shape that almost always consists of two paths. It’s a good candidate for estimating the contrast of a typeface. (Side note: While seemingly simple, the shape of an “o” is actually quite hard to draw well, because the stroke needs to smoothly grow and shrink between thin and thick.)

opentype.js provides convenient ways to get path data to draw characters to a SVG element. I actually draw inner and outer paths separately. Then I used an algorithm that travels along each path and measures the distance at each point. We can then calculate the ratio between the longest and shortest distance and voila — we have a comparable contrast measurement.

x-height

The x-height is an important characteristic that can be an indicator for legibility and perceived size of a font. It is usually measured at the top of a lowercase x.

opentype.js provides us with the needed measurements, namely yMax for any glyph.

In addition to the absolute measurement, it might be useful to also compare the x-height to the height of the ascenders. Thus, we can get percentage values such as “the x-height is 60% of the uppercase letters”.

To make the values comparable (some fonts use 1000 unitsPerEm, others 2048 unitsPerEm), it is necessary to normalize the values and map them to a range of 0–1.

Width / Proportion

With this value I try to grasp how narrow or wide a font is. Is it rather condensed or extended? One idea I had was to measure the width of an “M”. But to make those comparable, one would need to put those into context of the overall size or the x-height. Some typefaces also might have very special “M” glyphs that don’t represent the rest of the typeface.

Another idea is to calculate the average glyph width using a sample word like “Hamburgefontsiv”. While this works quite well, it also would need some normalization in respect to the overall design and height of the typeface.

Another approach is to look at the proportion of an “o”. This gives suprisingly good values for comparing the widths of fonts.

Weight

To measure the weight, I render the lowercase „o“ character to a HTML canvas element, fill it black and paint the background white. I then measure the ratio between black and white pixels. A script or hairline font will show very little values, while a very heavy blocky font will show high values. This gave me okayish results, but I want to improve this by measuring actual stems of glyphs in the future.

Spacing

When all glyphs of a typeface have the same width, they are called monospaced. Important here is, that we can’t necessarily look a the glyphs themselves to determine the width. Even in a monospaced font, a dot character takes less visible space than a “m”. Thus, we need to take into account the advanceWidth property that describes the invisible width around a glyph. Here we can find out that Google Fonts uses monospaced as a style classification, but not to indicate the technical property. Fonts such as Lekton or Libre Barcode are not listed as monospaced, but technically they are.

Similarity

Once we have a table of values, we can normalize those and then compute distances to see how similar fonts are. I implemented a very basic version of it that isn’t terrible, but could be better with higher accuracy of the data. Also, we might perceive similarity different than an algorithm that treats every characteristic equally. In that case, we might need to weigh some properties more than others.

Demo

I’ve built an interface to make the database accessible. Fonts can be viewed in a grid of varying size to get an overview over all fonts or to take a look at details of a few fonts.

Fonts can be sorted by weight, x-height, contrast, width, name and number of styles. Depending on the sorting criteria, adequate glyphs are shown.

Area charts show the distribution of values and can be used to filter out certain values. Each font has a detail view with a few samples, glyphs, metrics, Panose information and similar fonts.

Explore the dataset
https://useratio.com/the-anatomy-of-a-thousand-typefaces

For some reason some fonts fail to load in Safari, so I recommend to use Chrome.

Screencast
https://vimeo.com/239318934

Findings

The dataset invites one to explore and find similarities and irregularities. Setting low contrast and serif will return all the slab serif fonts. Low x-height will give us mostly handwritten or script fonts. Very high values often indicate all caps typefaces.

Misfits
Selecting the lower or upper ends of the spectrum will often return very weird designs. They mostly fall into the category display.

Ugly differences
The grid overview reveals the awful differences of baselines and alignments. Some fonts are radically off the grid. And even with subtle differences, it becomes clear that a simple 1-to-1 font substitution is almost impossible — with the exception of some popular fonts that all seem to share a similar skeleton.

Average is good
It’s interesting to see that commonly used fonts we consider to be good, all fall into a similar subset. By adjusting the filters, I can cut down the list to less than half and all the popular fonts will still be there. Selecting the average ranges is a simple way to filter out the misfits and extremes.

Forked Fonts
We can also find fonts that look exactly the same as others but with different names. Some of those are forks that extend the character set to support additional languages, e.g. Alegreya & Sahitya.

Number of styles
Above all, the number of styles a font has is a good indicator for its quality — at least as long as designers still need to make a lot of effort to design various weights and styles. Variable fonts are on the horizon and infinite customization may be the future. But until then, it’s good advice to work with font families that have multiple styles. Thus, sorting the collection by number of styles is a fast way to get an overview of the best fonts available.

Summary

This is a complex way of looking at font exploration. Ultimately, the quality of results depends on the quality of the fonts and the data around them. Only browsing Google Fonts is very limiting as their overall quality isn’t known to be the best in class. I’ve already started to run analysis on the Typekit library and ultimately met new challenges of user interface performance when previewing so many fonts. Such an undertaking requires proper caching and preloading strategies. But I don’t have to go that far just yet.

With no AI involved, I now have a good understanding of what’s inside font files and what’s missing. The more and more I got into this, I realized how massive the field of font technology is and that I’m only getting into something that’s been done for decades already.

Possibilities

With such a dataset, one could do more things:

• find fallback fonts with a similar width or style
• automatically adjust font sizes and line heights based on x-height
• find font combinations based on similarity or difference
• build a custom font menu for Avatar’s poster designer
• …

Try the app
https://useratio.com/the-anatomy-of-a-thousand-typefaces

Watch screencast
https://vimeo.com/239318934

Before I publish the raw dataset I want to improve the analysis and try to add more characteristics. If you have any ideas for improvement, don’t hesitate to leave a comment. Thanks for reading!

Further reading

Panose Classification Metrics Guide
The guide from 1991 describes in detail how to measure individual glyphs to derive comparable metrics. Unfortunately those measurements need to be taken by hand and can be quite time-consuming.

Taking The Robots To Design School, Part 1 by Jon Gold
Already in May 2016, Jon Gold wrote about his approach to analysing fonts in depth, covering topics such as rule based design, artificial intelligence and the relevance of such datasets for design tools.

Google Fonts Tools
A set of open souce tools that are used to analyse fonts for use on the Google Fonts website. You can find similar algorithms there, but also other ones that for example determin the italic angle of a font.

Font Bakery
Font bakery is a set of Python tools that runs checks on TrueType files, and Google Fonts related metadata files.

Appendix

Q: Why didn’t you use data from web font services?
A: Services that provide fonts such as Typekit, Google Fonts, Fontstand, Fontshop, MyFonts, etc. all provide their own set of filters with more or less fine control. The APIs of those services also differ in the amount of information that is available for each font. Usually the category is provided, but other information is either left out or not compatible between the services.

The following example shows, that all we get from Google Fonts Web API for Roboto is its category sans-serif, variants and subsets. https://gist.github.com/getflourish/d79836b0bebb6b44f76389b623fd7dc1

The Typekit API provides more information about width, x-height, weight, classification, contrast, capitals and a recommendation.
https://gist.github.com/getflourish/8c7c9ab4ddcf422cbb77866b5cf61575

As you can see, in the example API result, the information about a font is provider-specific. In order to be more flexible and independent I started to do my own analysis.

What’s included:

• Dynamically render data to HTML using the simple template syntax
• Use v-model to keep user input and data in sync
• Using simple functions, like “length” in your markup
• Rendering lists using v-for (characters of a string, Array, Object, …)
• Adding user interaction with v-on (click, keyup, …) to call a method
• Using v-bind:class to conditionally apply classes to an element

What’s not included:

• entertaining music or sexy visuals
• Flux, SSR, Routing, Babel, Webpack, Functional Programming, Immutables, CSS-in-JS, … this isn’t necessary to create an interactive throw-away protoype. Save all of that for later and then use vue-cli or nuxt-js when you want to go develop something for real 👾

With those concepts, you can already achieve a lot without writing a lot of JavaScript.

You can learn more by reading the great documentation with many more examples at https://vuejs.org/

Enjoy and share this with your designer friends who are eager to add HTML prototypes to their toolbox but are afraid it would take them too long to learn 😎

The video

Note for the haters of template syntax: If prototyping speed is not your main goal and you rather want to develop a larger, scalable application, VueJS also lets you write components using more verbose code and render functions.

You can find the CodePen here: https://codepen.io/getflourish/pen/JNrMEe

In 2016, I’ve seen an ever increasing number of style guides and articles on design systems on the web. More and more web and interface designers started to document their color palettes, text styles and component libraries that help them with consistency and scalability.

While a lot of effort goes into documentation and implementation of design systems, I think we actually need some tools that help us create such systems in the first place.

Personally, I’m looking for better ways to design relationships and have means to express and communicate my design intentions.

I feel that the next generation of design tools would benefit from a solid foundation that promotes a systematic approach to screen design. These tools will likely need to work different than we’re used to, but it might also make us more productive and reduce the time for house-keeping.

Building my own tools

To illustrate my point, I developed a simple tool that helps me design a responsive typographic scale. It’s a visual interface for creating a modular scale with fluid type.

While Modular Scale for Sass and CSS calc() are simple to implement technically, I struggled to find the right values for all the parameters that are involved.

I felt tired of guessing and typing values, reloading the page to see changes, resizing the browser to see how it behaves on various screen sizes, etc. I felt rather trapped in a mechanical process, than being empowered by the system. I thought that I needed a simple interface to better understand the dependencies and behaviors of the different parameters. I had to see this in real-time.

How it works

Parameters, not values

There are two sets of controls on the left that I can use to manipulate the container width, base font size and contrast of the modular scale at each extreme. This is the core playground where I can tweak as long as I want and see how the system behaves.

It’s important to note, that sizes and contrast depend on the overall design and white space. While big contrast can look great on a big screen, the same contrast ratio will look off on a small mobile device screen.

This means, that simply making everything smaller on mobile (e.g. decreasing the base font size of the HTML element) isn’t enough. Titles will be too big compared to the available screen estate. We can improve that by using less contrast for the modular scale on our minimum end.

Interpolation

The tool shows minimum & maximum views (“masters”) of a sample article design with a few headings and body copy in different sizes. All font sizes in between are interpolated. This is the so called fluid type.

Instead of thinking about arbitrary breakpoints and fine tuning each font size for each breakpoint, would it be enough to just think about the extremes and how they play together? How does it feel to design minimum and maximum in parallel?

Designing with those “multiple masters” is common in the making of typefaces. By designing two extreme weights (e.g. black and thin), you are able to interpolate in between and generate as many weights as you want (e.g. bold, regular, light).

Usually, the visual quality of interpolations is not guaranteed to be perfect and manual adjustments by eye are required.

Such a combination of algorithmic automation and human fine tuning seems to be a good approach to me. Computers assisting with design, not taking over.

I believe that interpolation can be a useful method to deal with other complexities such as designing for many different devices, screens, light conditions, and other contexts that we cannot fully control or anticipate.

For more information on that topic of interpolation, I recommend reading “Interpolation Theory” from 1987 by Luc(as) de Groot.

Snappy previews

I can drag handles on each preview to temporarily resize them and see how the design responds when it gets wider or narrower. Once the mouse is released, the previews snap back to their initial size.

Steps

Each text layer shows a number on hover. This is the step used for the modular scale. I can increase / decrease the steps to make changes to the visual hierarchy while staying within the system.

Limitations

The tool is very limited and addresses only a few aspects of web typography. When we look at typography theory, there are a lot more rules and relationships that we could encode. To be more precise, we would also need to read the font metrics to derive the x-height or other measures as a base instead of using the font-size. Right now, two different fonts using the same parameters would lead to very different results. This is because the actual perceived size of a font is not directly related to the font size.

In reality, we would also need to be able to bind our system to HTML containers instead of relying on the width of the page. Currently, this is only possible with JavaScript and using libraries such as EQCSS. There is a lot more that needs to be done to make such a system more generic and bullet proof for various use cases.

So nope, you can’t:

• Choose fonts
• Change spacings
• …

Working with systems and limitations

Setting up a modular scale only in code is the wrong solution. Design tools and code environments need to be able to share the same information about the underlying systems. A middle man that understands various tools and formats might be needed. Theo by Salesforce is an interesting approach to that.

Think of it as a design police (or a design linter) that ensures that you stay within the system or whatever rules you agreed on as a team. Instead of freely choosing from a continuous range of font sizes, your tools would automatically snap when you resize. Similar mechanisms are imaginable when working with color, spaces, and other properties.

If that sounds interesting from a CSS point of view, you should check out “Dialog Size” by my co-worker David Aerne.

The concept of contrast

Using the contrast scrubber feels very powerful to me. Instead of tweaking multiple individual font sizes, I control one single parameter to influence the whole system. Although I usually read about “scale” or “factor” in articles about modular scale, I find the term “contrast” more suitable. While scrubbing, I directly influence the contrast between the body font size and all other sizes. The bigger the value, the bigger the contrast.

I also believe that contrast is a powerful way of thinking about various design relationships. It doesn’t only apply to a typographic scale, but also to space and color.

For example, instead of picking a text color that “looks good” and is legible, we could simply define a desired color contrast (e.g. 4.5) and let the design tool figure out the actual color based on the background color of the text.

That way we have aesthetic control (“high or low contrast”) while also ensuring legibility.

Build your own tools

I’ve made this tool as a proof-of-concept. I wanted to get a feeling for what it would be like to control and play with parameters instead of typing code. I also wanted to find out how designing for minimum & maximum at the same time feels and whether that is more useful than only seeing on state at a time.

All I get from those hacks are usually learnings. It takes a lot more effort to turn those ideas into real tools that work in production. But I still want to encourage anyone to start building your own (small) tools if you can. Help yourself!

Complaining about a lack of features won’t bring us anywhere soon. That’s also the reason behind the many Sketch plugins I developed. (Color Contrast Analyser, Line Height, Mate, Style Inventory, Consistency, …).

In my opinion, the fact that Sketch has a completely open API that plugin developers can build on, is the most powerful feature. The team behind Sketch basically accepted that they can’t solve every individual’s problem. But they made it incredibly easy to use our creativity to build tools on top of a solid foundation.

Try the tool

You can try “Adaptive Modular Scale” on CodePen. It’s not really intended for real world use and I didn’t test it thoroughly. It’s also pretty obvious that designing the “maximum” state requires a large screen or using the zoom control that I didn’t build 😇

Credits

I started to work on the tool after reading the article “Precise control over responsive typography” by Mike Riethmuller. Seeing that fluid type is possible with CSS today made it even more interesting to try it out in more detail. Is it a silver bullet? No. But it is one way to deal with typography on the web.

Modularscale.com is a tool that previews modular scale as a water fall of text. I think the website has made the concept a lot more popular. Personally, I find the type of visualisation only partially helpful. I like to see the system in context (example article or a real project). A tool by Tim Brown and Scott Kellum.

GridLover is a tool that also helps you establish a modular scale including a vertical rhythm. Essentially a better and more complete version of my experiment, but without the interpolation. I love how Tuomas Jomppanen and Ville Vanninen integrated scrubbers inside the CSS panel!

A brief introduction on scripting commands that computers love to do over and over again.

This post is an answer to a Sketch feature request by Information Architects that I’ve stumbled upon Twitter:

@sketchapp Hey, we all use your program here. We would love to have a “Select all below feature” similar to the one in Axure. Cheers! — via @iA

I want to explain how this is possible by writing a simple plugin, that you can also download on Github.

About writing Sketch plugins

It’s been almost a year since I’ve started using Sketch in my design process. In the meantime, I’ve developed dozens of plugins that help me and my colleagues in our daily work at Ginetta.

Fortunately, most plugins only require a few lines of JavaScript to select and manipulate layers.

Every time I find myself repeating something over and over again, it’s time to use the computer for what it’s good for: automating tedious tasks.

In this article, I briefly want show you how to select layers based on properties. Selections are the core of most plugins and they are actually quite simple to perform.

If you’ve never developed a Sketch plugin, but also feel the urge to improve the way you work with Sketch, I recommend that you read theSketch Developer Documentation.

Selecting layers with NSPredicate

The most efficient way to make selections is by using NSPredicate. It allows you to write simple queries that can select layers by style, text value, position, size and every other possible property of a layer, artboard, or page.

For example, the following line of code could be used to select all layers with a y-position greater than the mouse position:

var predicate = NSPredicate.predicateWithFormat(“frame.y > %@”, mouseY);

You could also select all text layers that have specific text value. Imagine you found a typo in a headline that appears on multiple artboards. If only you could select all those layers at once…

var predicate = NSPredicate.predicateWithFormat(“stringValue == %@”, referenceString);

To turn those selections into working plugins, you need to define a scope that you want to search on. This can be the whole document, a page, an artboard, a layer group or multiples of them.

The following command would set the scope to all children of the current page (including artboards, layers, shapes, …):

var scope = doc.currentPage().children();

Often, I find it more useful to only select layers that are on the same hierarchical level as the selected layer:

var scope = selection[0].parentGroup().layers().array();

Example plugin

For demonstration purposes, here is a bare bone example that selects all layers below a selected layer. I also wrote a plugin that uses the mouse position as a reference.

Imagine that you just removed a section in the middle of your design and now you want to move all layers below the section up to fill the gap.

We need to define the scope of our selection. In this case, we limit the selection to layers on the same layer level as the group that our selection is in.

var scope = selection[0].parentGroup().layers().array();

Because we want to get all layers below the current layer, we need to calculate the y-position of the bottom edge of the selected layer. The frame of a layer holds all the relevant position and size properties.

var frame = selection[0].frame();
var bottom = frame.y() + frame.height();

Now we can set up our NSPredicate filter, that checks each layers’frame.y property and compares it to the previously calculatedbottom value.

var predicate = NSPredicate.predicateWithFormat(“frame.y > %@”, bottom);

Now we need to get an array of matched layers

var queryResult = scope.filteredArrayUsingPredicate(predicate);

Finally, we can tell our document to select all those layers

doc.currentPage().selectLayers(queryResult);

That’s it. Less than 10 lines of code that are only a shortcut away to make your life easier.

I recommend that you check out the source code or download the plugin (for Sketch 3.3+) on Github.

To learn more or get inspired, check out my plugins Sketch Mate andSketch Style Inventory on Github. I also recommend you to join the Sketch Developer List.

Ginetta is a digital agency that specializes in user-centered design and development. We create meaningful experiences that are fast, simple and beautiful.

This post has originally been published at blog.ginetta.net

Custom Selections in Sketch App was originally published in Ginetta on Medium, where people are continuing the conversation by highlighting and responding to this story.