The Future of
Web Fonts

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. Type­faces make our websites slow. They produce FOUT — or FOIT if you prefer. They render in unpre­dictable ways. Why should we live with inflexible type that doesn’t scale, when the core nature of our medium is fluid and responsive?

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 tremen­dous shift that I see leading to richer, more responsive typographic experiences and vastly expanding the possibilities for web typography.

Variable Fonts Image credit: Erik van Blokland

Continue reading

Typography for User Interfaces

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, with the release of the iPhone (without flash) in 2007.

Our interfaces are written, text being the interface, and typography being our main discipline.

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 our 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.

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.

Continue reading

Relocating to San Francisco, CA

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 4th Edition of Viljamis.com

I designed the 3rd 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.

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.

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:

  1. Build a design system.
  2. Focus on the content, typography and readability.
  3. Better performance and faster loading.
  4. Switch to HTTPS and provide an offline experience.
  5. Ditch PHP and switch to a static site generator.
  6. 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 what­soever, 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.viljamis.com, v2.viljamis.com and v3.viljamis.com. ❦