I’ve been down in an audio plugin rabbit hole lately. More on that in a later blog post. But I just stumbled upon a set of free plugins that might be of interest to you, if you are doing voice recordings of any kind – be it a podcast, voice over, or, let’s say, video tutorials. There are, of course, many more free plugins for that use case. Again, I might cover more of them in separate blog posts, also to document my own research. Let me know if that sounds remotely interesting.

But back to the plugins I wanted to talk about: the Accusonus ERA 6 Bundle. Accusonus was a company founded in 2013 by Alex Tsilfidis and Elias Kokkinis in Greece. The company produced sophisticated audio restoration plugins that removed noise, clicks, hum, reverb from recordings, and improved the sound of voice recordings in various other ways, including the use of AI. In 2022, Meta bought the company, and after that, Accusonus’s products were sunset and all traces of the company quickly got erased from the Web.

However, shortly before they vanished, Accusonus made their ERA 6 Bundle of audio repair tools available for free. And those audio plugins can still be downloaded from the Internet Archive.

The bundle, which is Apple Silicon compatible but also available for Windows, includes plugins like De-Breath, Mouth De-Clicker, De-Esser (Pro), Noise Remover (Pro), Reverb Remover (Pro), Plosive Remover, Voice Leveler, and many more. I just gave most of them a try in Reaper – and they seem to do an amazing job!

You can download the installers from the Internet Archive.

As Twitter is (far too) slowly falling apart and more and more people are looking for alternatives, Bluesky is enjoying a surge in popularity at the moment.

One neat little feature is that you can use your own domain as your handle on Bluesky. In a way, this is the perfect handle for this new era of decentralized social media. Your personal domain is part of your digital identity on the independent Web and uniquely yours. Your domain is owned by you and is under your control, which also makes impersonation much harder. And if you ever decide to switch servers, you can always take your domain with you.

If you don’t own a custom domain yet, Bluesky lets you purchase and manage domains directly through them. But of course, you can also register your domain at any other service, like one from the directory of green hosting providers by the Green Web Foundation.

But chances are that you already own a personal domain. Setting it as your Bluesky handle is then quick and straightforward. All you have to do is set a DNS record for your domain.

1. Open the left side menu on Bluesky by clicking your profile picture thumbnail or the menu button in the upper left on the home screen. Click “Settings” and scroll down to the “Advanced” section. Click “Change handle.”
   

   

2. Next, click “I have my own domain.”
3. On the following screen, enter your domain name and copy the domain value which you will enter in a new TXT record for your domain in a few seconds.

   

4. Now, go your domain registrar and find the DNS settings for your domain. This will, of course, vary depending on the registrar you bought your domain from. In my case (German hosting provider all-inkl.com), it looks like this:

   

   Add a new TXT record with `_atproto` as the (sub)domain, TXT as the type, and enter the domain value you copied before in the value (or data) field.
5. Wait a few seconds (or minutes) so that the new DNS settings are in effect and the servers on the Web know about this change. Then go back to Bluesky and click “Verify DNS Record“.

   

6. Et voilà! Your domain is now your handle. 🎉

In case you want to dig a little deeper, the Bluesky team has published much more detailed instructions on their blog.

Subscribe to Own Your Web

I’m writing a newsletter about building and running personal websites and creating and publishing on the Web – full of actionable insights, best practices, hacks, links, tools, and other things I found or explored.

Sign up here:
👉 https://matthiasott.com/newsletter

In what looks like a very smart move, the team at Mastodon just released a very nice new feature for media organizations, journalists and bloggers: when someone shares a link to an article by certain news outlets like The Verge, MacStories, or MacRumors, the official Mastodon app as well as the web version will now show a direct link to an author’s fediverse profile.

What is primarily aimed at journalists and news organizations for now, is a feature that might soon work for bloggers and anyone sharing posts on their personal sites, too. And it makes a lot of sense in this context: While I always try to mention the authors of the articles I am sharing on social media, I also forget to do it at times. Others also just don’t want to invest the effort to search for the respective Mastodon, Threads, or other handles of the person who wrote the post every time they share a link. And that’s okay, I guess. With this new author byline, a direct connection between the article and the corresponding fediverse accounts is established that increases the visibility of authors and their accounts a lot.

To make the new feature work, the Mastodon team decided to invent a new Open Graph meta tag:

<meta property="fediverse:creator" content="@[email protected]" />

The handle can be any fediverse account, including Flipboard, Threads, WordPress (with the ActivityPub plugin installed), PeerTube, Pixelfed, and many others. And because the feature is also part of Mastodon’s API, it can be implemented by third party apps like Mona or Ivory in the future.

For now, the feature only works with a small number of news outlets. On the Mastodon blog, Eugen Rochko mentions that it will only show up for links to moderator-approved websites and that support for the tag is currently rolled out on mastodon.social and any other server that uses a recent Mastodon nightly release. It sounds a bit like admins running their own instances (on a nightly release) might already be able to approve sites as well, including personal websites and blogs. But I couldn’t confirm this yet.

Anyway, I just added the Open Graph tag to my site. And although it doesn’t work for personal blogs yet, it also doesn’t hurt and I’m already looking forward to the day we will all see our account handles appear underneath our posts.

PS: While adding the meta tag, I discovered that I urgently need to take care of my Open Graph images next… so stay tuned.

The Logitech Spotlight presentation remote is a sleek piece of hardware. It is comparatively small, fits nicely in the palm of your hand, and the buttons come with a very satisfying, albeit for my taste a tiny bit too loud, click. But most importantly, the brushed aluminium design feels sturdy, high-quality, and elegant. Exactly the piece of gear that you buy because you want a reliable, long-lasting device that does not fail you.

Imagine my irritation, when I pulled out my Spotlight after several months of not using it – and it just didn’t charge anymore. Not with the supplied USB-C cable, not with any USB-C cable. Regardless of which cable and power source I tried, the remote remained silent and also didn’t show the pulsating light at the top that would indicate that the device is being charged.

Now, further imagine my disbelief and bewilderment when a quick online search brought up this tutorial on YouTube of how to “fix” this issue: https://www.youtube.com/watch?v=KuDt2un6zvI

Tldw; Because of how the Spotlight is engineered, it will die if you not charge it regularly and there is no way to reset it or bring it back to life in any other way. Even if you plug it in for hours, it won’t come back to life because it doesn’t even have that last little spark of electricity in it that would allow the device to recognize that it is being charged. The only solution presented in the video: soldering two wires to the contacts of the battery and then charging it with an external charger – after forcefully opening (and possibly damaging) the device. What a mess.

But then, one of the comments drew my attention:

“I charged very briefly (1 Minute) by using just 2 AA batteries, that was enough to give it the boost to wake up. Amazing advice, thank you so much!”

That didn’t sound all that bad anymore! Charging it briefly with a few AA batteries? I can try that. So I got to work – and ultimately brought the remote back to life. If you happen to have a Spotlight as well and ever run into the same problem, I hope this helps. Here’s a short guide:

1. Carefully remove the back plate:

I used a tool from iFixit they call Jimmy, which has a very thin steel blade, to open the back and lift it up a little bit at the middle of the device. Do this very slowly – the back plate is just glued onto the frame, but it can break, especially at the upper end, where it has a plastic latch. Then, I used opening picks to carefully lift up the back plate all around, ending at the top.

2. Lift up the plastic foil covering the battery contacts.

3. Build a charger

If you’re like me and don’t happen to have something like a (LiPo) battery charger at hand, connect two or three AA batteries in series, e.g. with some tape, so that their contacts are touching each other. Also attach two wires, one on the positive and one on the negative terminal of your “battery pack”.

4. Engage!

Now, hold the cables to the contacts of the Spotlight’s battery. The hot, positive wire should touch the positive contact (that’s the one with a little red cable connected to it) and the negative wire the other terminal.

I had to try twice but only held the cables onto the contacts for about 30 seconds, which was enough to provide a tiny spark of life. You won’t see or hear anything yet, though. But now …

5. Plug a USB-C cable into the remote

It should reward you with a very satisfying vibration to let you know that it is indeed back from the dead. Also, the pulsating LED at the top should now be back. 🥳

6. Put the back plate back in place and press it on.

Happy charging – and happy presenting! Oh, and don’t forget to regularly charge this touchy little piece of hardware in the future.

I just published the 11th issue of Own Your Web, my newsletter about designing, building, creating, and publishing on the Web. When I started the newsletter back in autumn of 2023, I didn’t yet know what form the newsletter would take on, if people would like it, and also whether I would like doing it or not. Eleven issues in, I can say with confidence that I enjoy researching and writing those issues a lot! And with more than 1700 subscribers via email and RSS after just a few months and after all the feedback I received via social media and email – thank you all! 🤗🥳💚 –, I want to keep running this project as long as possible. In order to do that, though, I need to make it more sustainable. Naturally, setting up such a project and writing a newsletter every other week takes up a considerable amount of time. Also, hosting a newsletter costs a bit of money as well. Currently, I use Buttondown to do all the management and sending of the issues, and although Buttondown is not one of the most expensive solutions out there and is definitely worth every penny, the monthly fee still adds up. Providing a “free” newsletter isn’t that free for the person writing it, after all.

So, going forward, my goal is to make Own Your Web a little more sustainable, first of all by making sure that at least the costs and, going forward, maybe even a good portion of my working hours that go into this newsletter are covered.

C.R.E.A.M.

But how do you make a newsletter sustainable? Do you add a paywall? Do you offer memberships for supporters? Do you ask people to buy you a coffee? Do you add sponsors or ads to the newsletter? Do you plaster it with affiliate links until it is indiscernible from spam? Do you do all of the above?

“Monetizing” any type of work online certainly isn’t easy. Many platforms promise that you can grow your publication into a thriving online business in no time – or at least make it sustainable. But in reality, they are often the only ones who really start earning money that actually pays the bills. And so, many people desperately try to do anything they can to squeeze out the last few dollars out of a project that started as a fun idea.

The Right Fit

There is something that really bugs me about this race to the bottom: I started this newsletter out of a passion for the open web and want it to be a genuinely useful, impactful, but also trustworthy resource. And that’s why I feel deeply that it would be a mistake to not be true to the values that connect me with my readers. Like, for example, the belief in a web that is open, distributed, and controlled by people creating beautiful things instead of marketing departments flooding the web with crap content, the targeted advertising industry harvesting data to create user profiles, and a few social media platforms manipulating your behavior to hook you into their walled gardens. Or values like the belief that owning your work, your data, your identity, and your connections online is one of the most valuable and empowering aspects of being a citizen of the open web. But most importantly, the conviction that the Web we all want to build together needs to be built on mutual respect and an appreciation of each other’s unique perspectives, struggles, and identities.

Therefore, whatever I do to make the newsletter more sustainable, it needs to be in line with what this newsletter is: a newsletter about being independent, about owning your web.

Sponsors Welcome

That’s why I will start looking for people or companies that would like to support the newsletter as sponsors – but I will be very careful in selecting them. They need to be in line with the values and goals of the newsletter. They need to be a perfect fit for you, the readers. They need to be people and companies that are trustworthy and supportive of the open web and that bring real value to you and everyone else who wants to own their web. Regarding the type of sponsorship, I am currently considering either a short “supported by” line with a link or, if it offers real value to my readers, a short shoutout inside the newsletter.

So: if you would like to support the publication or can think of a company that would be a good fit, let me know: 👉[email protected]👈

And then, there is still also the option of asking all of you for support. Completely optional and voluntary – the newsletter will always be free –, but maybe a small contribution on a pay-what-you-want basis is something that a few of you would indeed do if it helps support the publication. I guess I’ll do that as well and see how it plays out.

I’m curious: how do you feel about all that? What kind of support or sponsorship do you find the most appropriate and valuable? Are you already supporting other projects? Or, do you also not mind a few ads for interesting products if they don’t track you? Or are you maybe even running a project yourself and have figured out a way to make it work sustainably for you? I’d love to hear your thoughts on this! So let me know via Webmention, Mastodon, email, or in a response blog post.

Your bi-weekly dose of inspiration:
Own Your Web, my newsletter about building and running personal websites and creating and publishing on the Web.

Sign up here:
👉 https://matthiasott.com/newsletter

Imagine you post and make new friends on an online network for more than a decade – and suddenly, your account gets suspended for no apparent reason. And there is nothing you can do about it.

Or imagine the online community you were an active part of for years just closes down and all user data gets deleted after a few months. And there is nothing you can do about it.

Or imagine that a site you poured all your thoughts and writing into decides overnight that it might be a good idea to sell access to all user data to a company that is training their large language model with it. And again, there is nothing you can do about it.

Now imagine a place where you actually own your content, your connections, and your online identity.

And now, imagine that this place is your personal website, under your own domain name, under your control.

This is the basic idea behind the IndieWeb.

A Community of Personal Sites

The IndieWeb is a community of independent and personal websites and the people behind those sites creating tools that enable a decentralized, people-focused alternative to the corporate web and its social media silos. Initiated in 2010 by Aaron Parecki, editor of the Webmention and Micropub open web standards, and Tantek Çelik, co-author of microformats, the IndieWeb has grown into an active community with members and followers worldwide.

Events

If you want to get involved, you can attend (or even help to organize) one of the IndieWebCamps, which are regular brainstorming and building events that take place several times a year in the US and Europe. They are a wonderful opportunity to meet like-minded people and work together on community topics and also tinker with your personal site. Typically, an IndieWebCamp will span two days. On the first day, participants learn, share, and discuss ideas and concepts in various sessions. The second day is for creating, hacking, and, at the end of the day, demonstrating what everyone managed to build. It is an exciting and inspiring experience in a very welcoming atmosphere. I’ve been to a few IndieWebCamps (Düsseldorf, Berlin, and Nuremberg) and it was always fantastic!

Another great way to meet people and work on your personal sites together are the Homebrew Website Club meetups that regularly take place in several cities around the globe. See https://events.indieweb.org/ for upcoming events – and don’t hesitate to start something in your city, if you feel like it.

But also if you don’t want or can’t attend in-person events or join the IndieWeb chat, there are many ideas and technologies that have come out of the IndieWeb movement and its underlying principles that are worth checking out.

POSSE

One of the most useful and impactful concepts of the IndieWeb is the idea to publish everything you create on your own site first and then syndicate it elsewhere, also called POSSE. This simple but effective principle allows you to stay in charge of your content and each post‘s canonical URL while also distributing it into the many different social networks and online communities where friends who aren’t part of the IndieWeb or don’t (yet) have a personal site might hang out. And because you ideally always link back to your original post, discovery of your original content is improved as well. You can learn more about the many advantages of POSSE on the IndieWeb wiki: https://indieweb.org/POSSE

Webmention

Another IndieWeb building block that you’ve probably heard of before is the Webmention protocol. Webmentions allow you to collect interactions like comments, likes, reposts, or other responses from various sources and feed them back into your site. How it works is simple: if you link to a website in a post, you can send a Webmention to notify it. If the site supports Webmentions, it may display your post as a reaction. And you can do the same for all sites that send you a Webmention. This way, you can have a conversation from one website to another, sending posts back and forth.

There are also many other promising tools like IndieAuth, which lets you use your own domain to sign in to other sites and services, Micropub, an API for creating, editing, and deleting posts on websites like your own, or WebSub, an open protocol to send and receive notifications when web content – like the feed of a personal website – is updated.

The IndieWeb – For Everyone?

One complaint I frequently hear though when I talk to people about the IndieWeb is that many of its technologies are still not accessible enough to people without a web development background. And there is some truth to that. Despite a growing number of useful plugins, for example for WordPress or Kirby, and a lot of helpful articles and tutorials, e.g. for Eleventy, many of the solutions that the IndieWeb offers are still very much nerd territory. All the more important are projects like the amazing Indiekit by Paul Robert Lloyd, a little Node.js server with all the parts needed to publish content on your personal website and share it on social networks.

The IndieWeb has already been playing a key role in developing many of the tools that make an independent, decentralized network of personal websites possible. This in itself is invaluable. Now it is on all of us to implement more and more of those features into our sites, build even more tools and solutions for the independent web, and help to lower the barrier of entry so that the IndieWeb’s vision of owning your content and online identity will be more accessible to evermore people. Every step we take will change the Web for the better. Because ultimately, the IndieWeb is for everyone.

The next chapter of the IndieWeb awaits and the fight for an independent, open web seems more worthwhile and promising than ever. Tim Berners-Lee once said: “You can make the walled garden very very sweet. But the jungle outside is always more appealing in the long term.”

Let’s make this jungle wild, exciting, and beautiful again.

This post first appeared in Issue 11 of Own Your Web, my newsletter about building and running personal websites and creating and publishing on the Web.

Sign up here:
👉 https://matthiasott.com/newsletter

Every day, we browse the Web and scroll our timelines. And every day, we find even more interesting websites, blog posts, articles, videos, podcasts, and other insights and ideas that we want to document, preserve, and share. The most obvious way to save something of interest still is to create a good old bookmark. And there are many different ways to do this.

First of all, you could save your bookmarks in your browser. While there is generally nothing wrong about that and I know many people for whom this solution works well, it can still be a bit cumbersome to organize your bookmarks this way, especially if you want to also add tags or notes. You could also save your favorites in a read-it-later app like Pocket or Omnivore. Or, you could save and manage your favorite links with bookmarking services like Raindrop, Pinboard, or the open-source tool LinkAce.

But all those solutions are missing an important bit: the social aspect of bookmarking, also known as sharing links with others. Once upon a system time, sites like Zootool, StumbleUpon, or Delicious not only let us save bookmarks, but also made it possible to discover new, interesting links that others had saved. This social aspect, this way of curating and sharing a collection of links that others can follow, has become a lost art.

Today, social media sites have made it seductively convenient to quickly post links that will immediately be rewarded with views, likes, and reposts. As a result, many of us seem to instinctively drop most of the interesting links we find right into the timelines of the many – oh, so many! – social media silos. With the recent revival of personal websites and blogs, however, a lot of people are rediscovering a more thoughtful and persistent alternative: sharing links on their personal websites.

Sharing links on your own site indeed has several advantages:

You own them. Bookmarking services come and go. On your own site, you can build up an archive of links that will survive any turmoil.

You can look at them again. Because that’s the reason you are saving a bookmark in the first place, right?

You can share them. If you add a links section to your website, people will be able to discover new and relevant content through someone they know and trust. No algorithm can beat that.

You can provide an RSS feed. This makes it easier for people to always get your latest links automatically. And, as mentioned in the last issue about RSS, this also helps with the discoverability of all our sites and posts.

You can cross-post your links. Using tools like IFTTT, Zapier, n8n, or Echo, you could take the RSS feed of your links section, for example, and automatically cross-post new links to Mastodon, LinkedIn, and BlueSky (via Micro.blog) – or also backup your links on other services like Pinboard or Notion.

You can send Webmentions and notify the sites you bookmarked that you did so.

You can turn your links into a weekly roundup post or a little newsletter for everyone who does not visit your site regularly but might enjoy a regular bunch of links.

You can create a solution that is as sophisticated as you want it to be. You can add (colorful) tags, notes, a search, filters, screenshots – and whatever else you come up with and are adventurous enough to build.

If you are athirst for some inspiration or want to start following the link blogs of others, take a look at the many sites people shared on Mastodon. (Thank you! 🤗) Ana is sharing bookmarks on her site, as well. So do Nicolas, Marc, and Hidde, who recently also wrote about his approach. Andy is collecting links as well now and also shared a run-down of his links setup. One of my personal favorites is Jeremy’s links section, just because he constantly adds new and interesting links including a short but succinct comment. And, to end the roundup with a shameless plug, my own site has a links section as well.

In whatever way you decide to implement your collection of links, pay attention to two things: first, try to make posting links regularly a habit. This works best when the links section of your site is your primary place where you collect bookmarks. And secondly, make adding and publishing bookmarks as easy as possible, for example by adding a bookmarklet. The easier adding a link is, the more likely it is that you will stick to it.

How do you currently save and share your links? Do you already have a links section on your site? Or are you planning to do so? Let me know via Webmention, Mastodon, email, or in a response blog post.

This post first appeared in Issue 10 of Own Your Web, my newsletter about building and running personal websites and creating and publishing on the Web.

Sign up here:
👉 https://matthiasott.com/newsletter

In the last issue of Own Your Web, we looked at blogrolls as one way to improve the visibility and discoverability of our sites. Whether or not you want to add a blogroll to your site is a matter of personal preference. But there is something else which probably everyone with a personal website should do: adding an RSS feed.

What’s RSS?

RSS, which stands for either “Really Simple Syndication” or also “RDF Site Summary” or “Rich Site Summary”, is a way to distribute the content of your site through a feed that people can subscribe to. Basically, you provide a feed of your website’s content that gets updated every time you publish something new. People can subscribe to that feed – and the feeds of other websites – and then read all updates in their feed reader of choice, all in one place. This way, readers don’t have to repeatedly visit various websites and other sources of interest to look if new posts have been published, but can instead pull in all new posts automatically. For you as a publisher, this also has the huge advantage that people who enjoy reading your posts will automatically get to see them once their feed reader updates all sources.

Developed around the turn of the millennium by people like Dan Libby and Ramanathan V. Guha at Netscape, as well as Dave Winer and the late Aaron Swartz, RSS became widely popular during the first blogging wave in the early 2000s. Today, it is the technology underpinning many news aggregators and also the distribution mechanism behind podcasting.

What makes RSS so powerful is that it is an open format. RSS is one of the reasons the blogosphere grew so rapidly and it is the reason why podcasting exploded: because this open format allowed everyone to participate by simply publishing a feed anywhere on the web, without being restricted by platform requirements, closed APIs, and paywalls. And this superpower is also why RSS is having a renaissance today: it allows everyone to subscribe to, share, syndicate, and cross-post content on the open web. And it also enables creative automations using tools like Zapier, IFTTT, Huggin, or n8n.

Adding an RSS feed to your site

How easy it is to an RSS feed to your site – or also individual feeds for different content types – depends on the system you are using. Many services, platforms, and content management systems already come with a built-in feed, so there is nothing to do on your side. If you have a WordPress site, for example, people can simply add /feed/ to the end of the domain name to get the RSS feed of your site: https://pfefferle.org/feed/. The same works for Tumblr or Ghost URLs if you add /rss/ at the end. Medium also provides RSS feeds for profiles, publications, and topics. (By the way: did you know that you can also add .rss to the end of any Mastodon user profile URL to get an RSS feed? https://mastodon.social/@matthiasott.rss)

Sometimes, adding a feed to your site takes a little more work, though, because you might have to install a plugin, like for Kirby or Eleventy, or even write the XML template code for the feed yourself, for example if you are using Craft CMS. Adding a feed is such a common problem, however, that you should be able to find a straightforward solution fairly quickly. In any case, make sure to validate your feed, for instance with the W3C Feed Validation Service.

Oh, and if you are feeling adventurous, you can even style your RSS feed with XSL(T). 🎨

Making your feed visible

Once your site has an RSS feed, it makes sense to put a prominent link to the feed somewhere on your site so that people will actually find it. Many blogs and personal websites have a link to their RSS feed(s) in the header or footer of the layout. If you also add an (orange) RSS icon, it is even easier to spot. Ideally, you should also expose the RSS feed in the <head> of your HTML so that browsers and feed readers can automatically find the feed when someone pastes in the site’s URL. Some of you also provide additional information about their feeds on a separate page, especially if they provide several different feeds, like Jose or Jeremy do, for example.

Reading feeds

You might at times hear people moan about RSS not being used anymore. But that doesn’t reflect my experience at all, at least in my little web design and development bubble. Although RSS is far from being used by the average mainstream internet user (for now), it is as useful as ever if you are looking for a more deliberate, calm, and algorithm-free way of reading your favorite blogs and newsletters. And there are now more feed readers and content aggregation platforms than ever before which allow you to collect and manage feeds while also providing a great reading experience. Yes, Google killed Google Reader in 2013, which was quite popular at the time. But several other services and apps jumped in to fill the gap so that innovation in that space never really came to a halt. Most of those services come with their own web-based reading interfaces and mobile apps, but you can almost always combine them with other native apps to improve your reading experience, especially on mobile devices. Here are a few popular options:

• Feedbin – One of the most popular readers for web feeds, newsletters, podcasts, and YouTube channels. For $5 a month, you get a clean interface with native apps and all search, management, import, and export options you need.

• inoreader – Another popular RSS reader and content aggregation platform with a free plan and a well-designed interface, mobile apps, and advanced features like keyword monitoring and automation options.

• feedly - Feedly used to be one the most popular RSS reader for beginners. They still offer a free plan that allows you to follow up to 100 feeds and organize them into 3 folders.

• The Old Reader - Free for up to 100 feeds, The Old Reader has been around since 2012. In addition to classical features, it also lets you find friends on Facebook or Google contacts and like, share, and discuss posts with them.

• NewsBlur – A reader that is free on the web, iPad, iPhone, and Android for up to 64 sites. Useful premium features start at $36 per year.

• BazQux Reader – For $30 a year, you get a fast and clean in­ter­face with a focus on read­ing, without ads and tracking.

• Flipboard – Flipboard is a news app and “smart magazine” that aggregates content from various sources that recently even federated with the Fediverse, allowing you to discover and follow millions of people who are posting content on the Fediverse.

• Reeder - my RSS reader of choice for Mac and iOS, which you can even use without an additional hosted service via iCloud sync.

• NetNewsWire - a very popular, free and open source RSS reading app for Mac, iPhone, and iPad.

• RSSOwl – a free and cross-platform desktop app (Windows, Linux, and Mac).

• Tiny Tiny RSS - a self-hosted, web-based, open-source reader that also comes with an Android client.

Finding and curating your feeds

To get the most out of your RSS experience, it makes sense to slowly and carefully add more websites you like to your feed reader. Tailoring your feed of feeds to your interests this way can reduce the noise and will leave you with a selection of people that regularly publish high-quality posts. As a starting point, you could take a look at the many RSS feeds people shared when I asked on Mastodon last week and in 2022. Manuel also asked everyone to share their feeds a while ago and just yesterday, Molly White asked people to share their blog URLs. At the time of writing, she has already received more than 400 replies.

It can also be interesting to see which feeds others are following. That’s where OPML comes in. If you export a list of feeds from your RSS reader, it will probably be exported in the OPML format. And some people like to share their OPML files publicly. Stuart was one of the first people I saw sharing their list, Chris shared his humongous list as well, here is Paul’s collection, here’s Šime’s, this is Jeremy’s, and here is mine.

And, last but not least, you can also browse directories like Blogroll, this Big List of Personal Websites, ohh.directory, or Personalsit.es to find interesting blogs and websites to follow.

Radical Syndication Superpowers

There is no denying that RSS is having a moment again. Not only because it allows us all to improve the discoverability of our work and explore online content in a personalized and deliberate way, but also because it remains one of the most powerful and influential technologies of the open web. RSS already is the cornerstone of many open technology systems like podcasting, which can’t be owned and controlled by any one company. As Anil Dash notes, this alone is radical, because it is the triumph of exactly the kind of technology that's supposed to be impossible: open and empowering tech that allows people to have ownership over their work and their relationship with their audience.

And we’re just getting started.

This post first appeared in Issue 9 of Own Your Web, my newsletter about building and running personal websites and creating and publishing on the Web.

Sign up here:
👉 https://matthiasott.com/newsletter

For my birthday, I got a new pair of speakers for my home office / home studio. After looking around for quite some time, I settled on the ADAM Audio T5V in the end. The T5Vs are affordable, entry-level studio monitors with a 5“ woofer that are optimized for smaller rooms. And it doesn’t make sense to blast much more bass into my 3 by 3 meter office anyway. I’m still far from being experienced when it comes to judging the sound quality coming out of professional speakers, but I wanted something that would allow me to reliably judge occasional (and soon more frequent?) audio recordings. A first listen confirmed the many positive reviews I watched and read: connected to the MOTU M2 via balanced XLR, and without having had the time to properly burn them in yet, the T5Vs still produced an impressively clear, rich, and powerful sound.

Looking at the frequency response curve of the speakers, you’ll see that they in fact have a relatively flat response curve, which means that neither the lows (the “bass”) nor the mids are too pronounced. There seems to be a little boost in the higher frequencies above 5 kHz but this can probably be adjusted via a switch on the back.

A flat frequency response is exactly what we want when the goal is to assess and master audio recordings, but of course, I also want to use the speakers to listen to music of all genres. From Run the Jewels, MF DOOM (all caps when you spell the man name), or Kendrick to The Strokes, the Arctic Monkeys, or David Bowie to Portishead, DJ Krush, Max Richter, Hans Zimmer’s Dune, or Beethoven played by the Vienna Philharmonic or Igor Levit. And that’s when you realize you need some equalization.

Thus far, I’d been mostly using headphones while at work and whenever I wanted to slightly adjust the sound, I opened a little app called eqMac. But I also recently switched to the more analytical sounding Austrian Audio Hi-X60 which had already increased my appetite for a proper solution for EQing my Macs audio output.

Last but not least, equalization can be useful to compensate for problematic resonances or other characteristics of your room. But thus far, I’ve not entered those spheres (yet).

EQing Mac System Audio

There are a few ways you can use equalization on the Mac. First, you could use the built-in equalizer of Spotify or any other music app. In the case of Spotify though, I got horrifying results. I don’t know what they do but it destroyed the signal completely and introduced crackles and clipping.

Then, there are a few apps that adjust the output of your Mac’s system audio and sometimes also let you add effects, like eqMac, Sound Control, or Boom 2. My experience using eqMac, which comes with a free and a pro version, was fine overall. It allowed me to make quick basic adjustments, but it was also annoying at times, especially because I regularly had to start it twice (?) until it finally opened or when the EQ settings quickly lead to clipping audio.

So I had another look around, and the most promising app, which also a few people suggested on Mastodon, is SoundSource by Rogue Amoeba. Rogue Amoeba are also the creators of LoopBack, an ingenious and indispensable tool for routing and combining different audio signals and outputs, especially when you are running online workshops or streaming sessions.

SoundSource lives in your menu bar and lets you not only adjust the volume of your system audio, but also individually for each of the running applications. You can adjust the audio with a 10-band equalizer, again both system-wide as well as on a per-app basis, and much more. What really sets SoundSource apart and convinced me in the end, though, are two more effects: the headphone EQ effect allows you to automatically equalize and tailor the sound to your specific headphone model. You can pick from thousands of presets and also add your own.

The second killer feature is support for Audio Units, Apple’s system-level plug-in architecture for Core Audio. What this basically means is that you can use all the free or paid plugins that you can use in audio workstations – like Logic Pro, Audition, Pro Tools, Reaper, Ableton Live, or PreSonus Studio One – to adjust your system audio, too.

And suddenly, the possibilities for equalization on the Mac seem endless. Just look at this list of only a few popular EQ plugins:

• FabFilter Pro-Q 3
• iZotope Neutron
• okesound soothe2
• Soundtheory Gullfoss
• TDR Nova
• TDR VOS SlickEQ
• Ignite Amps PTEq-X
• Luftikus
• Sonimus SonEQ

In my case, this means I can use iZotope Nectar 3 Elements, for example:

And who knows, maybe I’ll soon actually adjust for all the weird resonances in here…

What do you use to adjust the audio on your Mac or in your room? What are your favorite plugins? Let me know via Webmention, Mastodon, email, or in a response blog post.

I’m turning 42 today and yes, I am as surprised about that number as you are. If 42 really is the answer to life, the universe, and everything, then maybe it makes sense to look back on what the old lad actually learned in all those years. So, here is a list of 42 life lessons, similar to the one Chris wrote when he was still 40. Incomplete and mostly unstructured. For my younger self as much as for my children and anyone reading this.

1. Don’t panic.
2. Love yourself. Take care of yourself. You can only help others if you are strong yourself.
3. Love your family.
4. Love your friends.
5. Respect is everything.
6. Be patient with yourself and others.
7. Be generous. It will make others and you happy.
8. Time is precious. Spend it with the people you love the most.
9. Children grow up incredibly fast. Enjoy every moment you have with them. Be there.
10. It is true: You will regret the things you didn’t do more than the things you did do. And time flies so much faster than you think. Before you know it, you won’t be able to do many of the things you thought you had an endless amount of time for. So do the things you dream of now.
11. Don’t think small. Seriously, don’t. You can do more and be more than others make you think. Or, to quote Rick Rubin: “However you frame yourself as an artist, the frame is too small.”
12. Even if you don’t want to admit it to yourself, you are still full of fear. Fear of being judged and criticized, fear of what others may think, fear of failure. And everyone around you is full of fear, too. It is one of the primary forces behind human action – or rather inaction. The fear will never go away completely. But the more you do things despite of being afraid, the easier they will become. Fear also means that what you are up to is actually important. Framing it as “excitement” also helps.
13. Every time you do something you are afraid of, you will grow. So step out of your comfort zone. You will be fine.
14. If you are enthusiastic about something, go for it. Go all in. Go deep.
15. If you have an idea, write it down immediately. Don’t try to remember it. You will forget it.
16. Don’t let other people tell you what you are good at or who you are. You can do and learn almost anything. Follow your curiosity.
17. The older you get, the more you’ll find out about who you are. This is fun (most of the time).
18. There is a beast in all of us. Be aware of that. Controlling your emotions and your anger will make you a better person.
19. We all make mistakes along the way. A lot of mistakes. That’s okay as long as we constantly try to learn from them. Remember: The first draft of anything is shit.
20. You don’t have to be friends with everyone. Some people are just different than you, a very few are toxic. There is no need to pander to them or trying to please them.
21. Do your taxes in time.
22. You cannot know what works and what sticks. So play and try out everything. Never stop prototyping.
23. Getting started is more important than finding the right productivity method or framework or tool. Start today and try to optimize along the way.
24. Football is life. The rest is mere details.
25. Write as much as you can. It clarifies your thinking, it makes you a better communicator, and it will open so many doors. Also: there is no such thing as writers block.
26. Don’t be scared to write in a language that is not your first language. You’ll grow.
27. Enjoy the process. It will not only lead to better outcomes, but it will also make you happier. The journey really is the reward.
28. Don’t work for assholes.
29. Be very careful in what you say yes to. In the beginning of your career, you’ll probably have to say yes more often, but you’ll actually also learn a lot from whatever you will do. Later, you should only say yes if you feel good about it. Learn to politely say no to everything else.
30. Pay attention to your gut feeling. It is a good indicator and often there is some truth to it, especially with growing experience. If you don’t have a good feeling about something, take a second to investigate and identify why that is.
31. Don’t spend your money on useless things. Be very careful about what to buy. If possible, don’t pick the cheapest option. If you can afford it, investing in better food, better furniture, or tools always pays off.
32. All designers should learn how to code. Everyone should.
33. Our brain is fascinating and highly malleable up into old age. But it is also fragile. So take good care of it.
34. Your body will age. It really, actually will. You can’t start to take care of it soon enough.
35. Exercise.
36. Eat much, much, much more plants. This hasn’t anything to do with being a vegetarian, a vegan, or any other box you think people will put you into. No, it will actually make you healthier, happier, and stronger. There are billions of bacteria in your gut that influence what food you like, how well your immune system works, and how happy you are. They weigh about as much as your brain. Feeding them with good stuff will make you happy.
37. Smoking is a really stupid idea.
38. Alcohol is completely unnecessary. As much as your parents, your family, your friends, society, and, above all, advertising want to make you think it is something that everyone does and a beer here and there is totally fine, it will slowly creep into your daily habits and constantly occupy your liver, which then can’t take care of the other stuff. It will disrupt your sleep and destroy all positive effects of the little exercise or sports you have time for. Any amount of it also kills your cells. Everywhere in your body and in your brain. Just don’t buy it anymore. You will feel so much better.
39. Coffee is great. Try not to drink it in the first 1.5 hours after getting up and four hours before bed time.
40. Sleep is not the cousin of death. Sleep deprivation is. Sorry, Nas. Sleep at least 6.5 to 8 hours a night.
41. Listen to as much music as you possibly can.
42. RTJ! 👉🏻🤛🏿
43. If you learn an instrument, try to play it at often as possible. Once it becomes second nature, you will be able to do magical things with it. Don’t do it like me and try to do only what’s necessary. Try to master it.
44. Mastering something takes time and a lot of practice. Don’t believe you can do something only because you are “talented”. If you don’t put in the time and effort, you won’t become great at it.
45. Farts are hilarious.
46. Get a personal website.
47. When in doubt, make a list. If it turns out to be longer than expected and you still feel like you can’t cut it down, great!

Whether you are running online workshops, hosting a live stream, or recording audio or video content, optimal audio quality is absolutely essential. People in your audience might tolerate if your video is noisy or not perfectly sharp. But if your audio quality is poor, for example when something is constantly crackling or whooshing in the background or your voice is distorted, it gets irritating and annoying for your listeners pretty quickly.

I’m therefore constantly experimenting with various ways to improve the audio (and video) setup and the acoustics in my little home office in the attic. Last year, I added a dynamic broadcast microphone, the Røde Procaster, for spoken word which has a cardioid polar pattern and great off-axis rejection, meaning it primarily records what’s directly in front of it. I also added an audio interface with really clean preamps, the MOTU M2, and treated my room a bit. However, the key to recording impeccable audio is not only good technical equipment, but also making sure you record the right things in the first place. An important part of that: removing background noise as much as possible.

Cutting Out the Noise

Which type of background noise you have to deal with depends on the environment you are recording in. In my case, there is a street outside which can get quite loud at times. Unfortunately, there is not too much you can do to block that kind of outside noise from entering the room other than trying to improve the insulation of the windows or the door. The second type of background noise, however, is one that you often can in fact control. And that’s the noise inside your room. Be it an air conditioner, loud computer fans, or other appliances – you might want to turn everything off that makes noise before you hit record.

In the past, I had a monitor, for example, that made a constant, very high-pitched beeping sound which then turned up in the recordings as well. So I had to turn this monitor off when recording and eventually replaced it. This improved the noise floor of the audio considerably.

But there were still two pain points that I had to deal with: the hum of the fan of my key light, an Aputure Amaran 200d, and the whirr of a fan I attached to the back of my camera, a Sony ZV-E10, to prevent it from overheating during longer sessions like online workshops. Both sounds were still clearly audible on recordings and the way I had dealt with in the past was to pull down the respective frequencies with the live equalizer of the Blackmagic ATEM Mini, through which the audio runs for live streams:

This worked fairly well. But, of course, I wasn’t satisfied. I wanted to be able to record audio also without the ATEM Mini, only using the MOTU M2 audio interface. What I had tried in the past as well was to record a few seconds of silence and then use this snippet’s noise floor to eliminate the hum and hiss with a de-noise plugin. I got good results from that, too. But this is still another extra production step that you don’t want to have to do every time you record something. The best way to reduce noise and get a clean recording is still to eliminate the original sound source in the first place. So I went on a little quest to do exactly that.

Silencing the Amaran 200d

The Aputure Amaran 200d is an affordable LED light that can output a lot of light. It can therefore get quite hot and that’s why it has a fan built in. When I bought the light, there was no way to adjust the speed of this fan. Once you turned the light on, the fan would run at full speed, regardless of how hot the device actually was. But a few days ago, I had an idea: what if Aputure in the meantime had released a firmware update for the device? And in fact, there it was: a firmware update that allows you to switch the fan from “medium” to “smart” in the Sidus Link app controlling the light so that the fan adjusts its speed to the actual temperature. This immediately reduced the fan speed from 1500 rpm to under 1000 rpm and the hum was gone. First problem solved! 🥳

Silencing the Noctua fan on the back of the Sony ZV-E10

Sony cameras are well-known for overheating in challenging situations. So one of the first things people do when they get a new Sony camera is to switch the “Auto Power OFF Temp.” setting to “High”. This prevents the system from shutting off too early to cool down. My ZV-E10, an entry-level mirrorless camera, has the same issues. When you record in 4K or are using the camera in USB cam mode, it overheats fairly quickly. I’d even say that this is a construction error, because it prevents you to use the camera as advertised. Using it as a USB camera is basically impossible. But there are a few things you can do to work around this issue:

• Always open the flip out screen on the back so that the heat can dissipate better.
• If the situation allows, never run the camera with a real battery, but use an AC adapter with a dummy battery instead.
• To use it as a USB camera, connect the camera to your computer via the HDMI port and a capture card like the Elgato Cam Link, not via USB-C.

All those measures helped a lot already, but the camera still shut down at times after long usage or when the office got hotter in summer. So, as a last resort, I mounted a small Noctua fan to the back of the camera and connected it to a USB power adapter. The camera never overheated again.

But as it is the case with over-engineered solutions (👋, SPAs), as soon as you solve one problem you realize that you just created at least one new one. In my case, it was the aforementioned whirring noise of the fan which was, although the fan is already quite silent (max. 19.6 dB(A)), still audible in recordings.

So last week, I decided to finally tackle this problem with two a two-layered approach. First, I replaced the fan with cheap aluminium heat sinks. I had to cut off three rows of fins from one of the heat sinks to be able to affix not only one. In a perfect world, this will suffice to fix the problem. But because Murphy’s law, I re-added the fan as well, and ordered a USB fan controller to be able to adjust the output voltage and thus throttle the speed of the fan, just in case I’ll ever have to turn it on again. Second problem solved. For now. I guess…

The Details Are Not the Details

As you can see, sometimes it takes a bit of creativity and tinkering to optimize your setup. I’m fully aware that most of you won’t run into the same problems as I did. But maybe sharing this example of my tour de-noise helps you to approach similar problems with the same mindset. You might think that putting in that much effort into such seemingly small details isn’t worth the time and energy. You might be right. And you can and should definitely start recording anything without worrying that much about background noise. Yet in my experience, caring about and honing in the details often makes the difference between good and great. Regardless of what you’re building or creating, paying attention to the final touch is worth it and can be very satisfying. And you’ll also learn a lot along the way. For example, in which direction you should mount a cooling fan.*

Do you have a setup to record audio or video? Did you run into similar problems? What tricks and hacks did you use to improve your setup and the quality of your recordings? Let me know via Webmention, Mastodon, email, or – my personal favorite – in a response blog post.

*So that it pulls and blows the hot air away from the device.

The web platform is changing rapidly these days. With every major browser release, more and more powerful features get added, many of which are based on previous input about what web developers need to build better for the web. One way for browser vendors and developer advocates to get this useful input is to ask web developers about what features they are interested in or where their biggest pain points are. Last year, for example, many people shared their CSS wishlists.

Brian Kardell, developer advocate at Igalia, just asked the opposite question: which of the features that got shipped in the last few years have actually proved to be the most valuable? Which features do you use all the time? An interesting question to think about for a little while. Also because we tend to overlook how fantastic it is to be able to use those features which would have been unimaginable just a few years ago. Or, as Jeremy demonstrated in his talk at border:none last year, many of the features we now take for granted actually almost sound “too good to be true”.

So, what features are this for me? What features am I using almost daily or don’t want to miss anymore? Here’s a quick list:

• CSS math functions min(), max() and clamp() – I use clamp() all the time, both as a smarter replacement of min-width and max-width in fluid layouts, as well as to dynamically scale my typography based on the viewport width.

• Lazy loading via attribute for images & iframes – Being able to lazily slap a loading="lazy" attribute on all images in my HTML (except for the images within the first viewport) for a considerable performance boost without a single line of JavaScript is just amazing.

• :focus-visible CSS pseudo-class – I’ve already written about how useful this seemingly little addition to CSS can be to improve the accessibility of our sites. I’m now using :focus-visible in every single project I build.

• CSS font-display – Another seemingly small addition to CSS with an invaluable impact: using font-display: swap as the most basic but also a performant and robust font loading strategy.

• CSS selectors: :where() and :is() – I’ve started using both selectors, but especially :where() because it always has 0 specificity, in my base style sheets whenever I’m declaring something that might later be overwritten. Like heading styles, for example.

• prefers-color-scheme media query – Isn’t it amazing that we now can sit in our bed in the evening and write blog posts in the dark with dark mode turned on? And isn’t it too good to be true to be able to adjust our designs to that preference?

I’m sure I’m forgetting a few things and you might have your own favorites, so feel free to reply with your own blog post. I’m curious to see what features you can’t live without anymore.

Matt Mullenweg, co-founder of WordPress and CEO of Automattic, recently sat down with Tim Ferriss to talk about a bunch of different things. One of those things: blogging.

It might not come as a surprise, but Matt described blogging as one of the most rewarding things he did last year. Not only because blogging, or writing in general, forces you to clarify your thinking, or because publishing is such a vulnerable, scary, and thus brave act, but in particular because of what happens afterwards and how much you learn from it. All the comments, the interactions, the follow-ups that make blogging so beautiful.

That was when Tim shared something he had noticed: that the discussions that used to happen in comments, have, for the most part, moved over to social media. Which is definitely something I noticed, too. So many blogs – even some big names – either have empty or neglected comment sections these days, or even none at all.

Comments are tricky. You probably need to manage them to prevent annoying or nasty comments, spam, or SEO backlink posts. As Matt points out, by being very clear about what you allow in your comment section, you also set an example. You set the tone and the standard which people will follow. But even if you manage to do all that, how do you get people to comment on your site in the first place? Because when you in fact do get them, comments can be an invaluable and vital feedback mechanism.

So, the question becomes:

How could one create the best comment section on the internet?

The two briefly touch on that but mostly from the moderation perspective. Yet I feel like there is much more to it. The best comment section on the internet could, for example:

• encourage people to reply – already through its design
• make it incredibly easy and convenient to comment and edit comments
• feel very chat-like
• allow people to give feedback on comments (like, upvote, dislike, report etc.)
• make discussions and threads visible and easily consumable
• allow people to comment with their social media accounts
• let people immediately share their comments on social media as well
• include comments from social media platforms or from other websites via Webmentions and ActivityPub in a really smart way

Especially the last point seems worth exploring. Because if we not only want to bring back blogging but also create a thriving ecosystem of interconnected sites, combining comments on your sites with comments coming from other sources could be vital. Webmentions, for instance, currently still come in completely different flavors and most often, the snippet that gets displayed does not feel like a comment at all. Taken out of context like that, it is often not very useful if you don’t want to visit the other site as well. What if we could change that and make at least the snippet more useful? Or, what if we combined likes of an article with real comments and so on and created a truly vibrant section – interesting, entertaining, and highly interactive?

Comments used to be at the heart of the interactions that happened around blogs and personal sites. It’s time to bring them – and the people – back to our sites.

What do you think? How should the best comment section on the internet look like? Does your site have comments? And what are the best comment sections you have come across? I'd love to hear your thoughts – ideally in a blog post. Because this site doesn't have comments yet…

At the beginning of 2023, I wrote in a blog post which I titled The Year of the Personal Website:

In the search for a permanent home on the web, more and more people are now rediscovering the personal website as a place to share and document their thoughts and publish their work. [I’ve written at length before](https://matthiasott.com/articles/into-the-personal-website-verse) about why this is such a good idea: Your personal website is a place that provides immense creative freedom and control. It’s a place to write, create, and share whatever you like, without the need to ask for anyone’s permission. It is also the perfect place to explore and try new things, like different types of posts, different styles, and new web technologies. It is your playground, your platform, your personal corner on the Web.

So how about we make 2023 the year of the personal website? The year in which we launch our first site or redesign our old one, publish a little more often, and add RSS and Webmentions to our websites so that we can write posts back and forth. The year we make our sites more fussy, more quirky, and more personal. The year we document what we improved, share what we learned, and help each other getting started. The year we finally create a community of critical mass around all our personal websites. The year we take back our Web.

And, looking back at 2023, did we deliver?

You bet. 😁

It all started with articles like Bring back personal blogging by Monique Judge for The Verge or the Bring Back Blogging project by Ash Huang and Ryan Putnam, who encouraged us all to get into the habit and publish at least three blog posts until the end of January 2023.

Throughout the year, fueled by the further decay of Twitter and the ongoing reshuffling of power on the internet, heaps of us indeed rediscovered blogging and started tinkering with their sites again. It was a joy to follow this development and add more and more sites to my RSS reader. If you want to get a glimpse of the richness of posts people published this year, take a look at all the replies to this question I posted on Mastodon: what were your favorite blog posts of the year?

All of this feels adventurous and exciting, but it also feels like we’re just getting started. There is still so much we can improve on our existing sites and so much we can learn about making our sites a central part of our online identities. There are still so many tools to be created to improve the discoverability of sites and posts and to connect our sites to each other and to the Fediverse, for example. And there are still so many sites to be built and blog posts to be written and published. So, how about we make 2024 the year of the personal website again? And, for maximum consistency, every year that follows? How about, from now on, we make every year the year of the personal website – and make the internet human, creative, personal, and weird again?

Here’s to a successful, healthy, playful, and fearless 2024. I can’t wait to see what you create.

🎆💚✊

This post first appeared in Issue 6 of Own Your Web, my newsletter about building and running personal websites and creating and publishing on the Web.

Sign up here:
👉 https://matthiasott.com/newsletter

It’s not going well.

After all-time heat records were shattered worldwide during heat waves across all continents and ongoing wildfires eradicated 5 % of the entire forest area of Canada, 2023 will be the hottest year ever recorded (1.43°C above the 1850-1900 pre-industrial average to date). At the same time, it feels like nobody is really listening to the scientists who have been warning about the consequences of burning fossil fuels for decades. Greenhouse gas emissions are rising faster than ever, the fossil fuel industry is making record profits (I don’t need to look for a link for that one, right?) and – despite all the greenwashing – is investing billions into new oil and gas projects. Meanwhile, governments in Germany and elsewhere are still subsidizing fossil fuels and even invested billions into gas and oil to prevent an energy crisis brought about by one of the world’s major gas exporting countries by inflicting war on a neighboring country. And now, the highest German court has ruled a €60 billion climate fund unconstitutional, because reallocating unused debt from the COVID-19 pandemic for climate action and the green energy transition “does not satisfy the constitutional requirements for emergency borrowing.“ Well…

It’s not going well. There’s no denying it.

But there’s also simply no alternative to rapidly changing our energy sectors, agriculture, housing, and transportation systems, if we want to avoid the most severe impacts of global warming. So what can we do? Repeat the warnings and share ever more depressing news about the growing impact of a rapidly changing climate? This did raise awareness for the problem in the past, but it also creates feelings of guilt and powerlessness, even in the most determined amongst us. Or, even worse, fear paralysis.

As Jason Kottke writes, “climate scientist Kate Marvel is done warning people about the problems with our climate and has moved on to highlighting our success in combatting it.” Why? Because, as grim as the outlook might seem, there are also lots of reasons to be optimistic:

As a result, Portugal just ran on 100% renewable energy for six days in a row and China’s CO2 emissions may be falling already, seven years ahead of their already ambitious schedule.

Humans are allergic to change. And, as Jeremy impressively demonstrated, we tend to overlook the changes that happen more gradually. We want the Big Bang, the sudden change, the headline that reads, “successful nuclear fusion solves climate change for good.” But that’s (usually) not how change works. Change often happens gradually, first very slowly, and then, once it reaches a certain threshold, it can happen overnight. The future is already here, it’s just not very evenly distributed yet. Another reason to be hopeful.

But the most important reason is that humans thrive on stories. We need them to guide us. Stories, in particular shared stories within a group, unite us in our endeavors and lead the way when things get tough. And herein lies the power of the narrative that there is indeed a way forward, a way out of this mess into a more healthy and less deadly future. It works for everyone: Suddenly, being a climate activist doesn’t mean to be against something or someone (okay, let’s still be against fossil fuel companies). Suddenly, being a climate activist means being for something, rewarding your dopamine system with little steps towards a worthwhile goal: bringing about positive change now.

It’s not going well. But that’s about to change.

Where were you in 2013 and what were you doing back then? What have you done over those last ten years? How have the last ten years changed your life, your work, or what’s important to you? I don’t know about you, but I definitely don’t often pause to reflect about the past decade like that. Far too often, we are too busy and caught in the here and now.

Now, imagine you get asked by two conference organizers to not only reflect about the last ten years but to actually give a talk about what has changed for you over that time span. That’s exactly what Joschi Kuphal and Marc Thiele did when they came up with the idea to organize a very special event: a ten-year anniversary edition of border:none. Same venue, same speakers, same price (30 €). Plus a second day and more speakers with a focus on diversity and inclusion.

And so, people got the rare opportunity to either talk about or listen to a very special collection of retrospectives and stories. Already after the first few talks, an interesting theme emerged: almost nobody gave a technical talk. Many even expressed a feeling of disillusionment with the state of the Web and the tech industry in general. Instead, people talked about very personal observations, journeys, struggles, and passions.

Jay, for example, spoke about the monsters inside our heads that hold us back from inducing necessary change and how important it is to not stay silent in the face of lies and hate. Tobias shared a deeply personal story about how his family history lead him to always search for new communities while, deep down inside, never feeling quite at home. Bastian reflected on failure, the satisfaction that comes from building things, and the value of a sense of quality, trust, honesty, and happiness. And Rodney took us to where he found relief from not being able to think about nothing but work: up in the air, paragliding. 🤯

Our brains are wired to prioritize short-term problem solving (= survival) over long-term thinking. That’s why we often end up sliding from one seemingly urgent task into the next without considering the long term implications of our actions. And before we know it, ten years have passed. Border:none 2023 demonstrated impressively that what truly matters in the end isn’t how good you are at running in the hamster wheel. In hindsight, the things you will remember, the things you will be most proud of, are the things that brought you a sense of purpose, happiness, and belonging, as well as the moments when you took a risk or stood up for something. At the same time, the things you’ll regret probably won’t be the things you did as much as the things you didn’t do.

As Jeremy illustrated in his talk Of Time And the Web, it’s easy to overlook the profound positive changes that can happen over larger timescales. Things we take for granted today, like the eradication of a disease like smallpox, are actually things that we would have considered “too good to be true” just a few years earlier. In much the same way, every little step we take, every decision we make, can add up to make a profound difference. Change is possible. It is on us to take the first steps, although we might have to step out of our comfort zone and the outcome might be uncertain. We all only get to play once, so we better play without fear and create something beautiful.

Then, there really are no borders.

~

PS: What border:none also showed me is how wonderful and replenishing it is to meet so many people again whom I can consider my friends now. It was amazing to see and talk to all of you. Thank you for creating this invaluable opportunity, Joschi and Marc! ❤️

I just sent out the first issue of my new newsletter Own Your Web.

Own Your Web is a newsletter for anyone who wants to design, build, create, and publish on the Web. Every other week, I’ll send out an email full of actionable insights, best practices, hacks, links, books, tools, and other high-quality insights I found or explored. Whether you want to get started with your own personal website or level up as a designer, developer, or independent creator working with the ever-changing material of the Web, this little email is for you.

Having a personal website in 2023 is a superpower. It’s a place to write, create, explore, and share whatever you like, without limitations. It’s a playground to try out new things, tinker with new technologies, and build something beyond the ordinary. It’s a tool to make yourself heard, to participate in online discourse, create community, and make new friends. And, it’s a place to truly own your content and tell your story. It’s your personal home on the Web.

But while it is as easy as never before to get started with a personal site, is it, at the same time, harder than ever to handle the complexity that surrounds websites today. Which domain should you pick? Which tech stack, content management system, or platform is the right one? Or should you use a static site generator instead? What about frameworks? Do I need to learn JavaScript? How do I choose a typeface in less than a year’s time? Which modern CSS features are safe to use? How can I make my site performant and accessible for everyone? To SEO or not to SEO? What are Webmentions? What’s RSS? And, what the heck should I write about, after all?!?

As you can see, there’s no shortage of topics to cover in a newsletter like this one. 😉 My current plan therefore is that each issue will highlight one specific topic, idea, or question that we all run into at some point. But I’ll always also include a tasty bunch of generally useful links that popped up in my feed reader.

If that sounds like something you might enjoy, sign up for free here:

👉 https://matthiasott.com/newsletter

–

PS: If you are thinking about starting your own newsletter soon, have a look at Buttondown, the service I’m using for Own Your Web. Setting up the newsletter was a breeze and Justin and team were quick to respond whenever I had questions. But what I enjoy the most is how easy it is to actually write your newsletter. You can write your email in plain markdown or, if you prefer that, in a rich text editor. To add images, you simply drag and drop them into your text. They will automatically get delivered via CDN. You can also configure your own sending (or even hosting) domain and there are numerous advanced features (depending on the plan), like automations, webhooks, tags, or an API to programmatically interact with your newsletter and subscribers. And, starting with the basic plan, you can customize your newsletter with your own HTML and CSS snippets.

If you use the following link, you’ll get $9 off of your first month of Buttondown. In return, I’ll earn a commission that supports my newsletter. 🤗

https://buttondown.email/refer/ownyourweb

After three years, I finally replaced my old Intel MacBook Pro – and its cracked screen – with a new machine. I’m still holding back a bit with my excitement for this 16-inch M1 Max MacBook Pro, just because I was really disappointed with my previous Mac. But thus far, it has been amazing. While I’m writing this, I’m sitting in bed, with the computer on my lap, and everything is running so smoothly and blazingly fast. This is as close as it gets to working at the speed of thought – and all this without any fan noise.

Whenever I get a new computer, I use it as an opportunity to start fresh. It’s a bit like moving: you only take with you what you really need and want in your new home. That’s why I also like to reevaluate which apps I use or don’t use anymore and have a look at what other applications I could try to improve my setup. After all, that’s part of the joy of setting up a new machine, right?

Here’s a list of all the apps I installed on my Mac this time in addition to what’s installed on a new Mac already. I might install more apps and I’ll add them to this post later. I’ll also leave out all the chat and video conferencing apps like Slack, Discord, Zoom, MS Teams, Skype, WebEx, and so forth. Also, it’d be great to hear: which apps you can’t live without on your Mac?

Writing – and Reading

iA Writer

My writing app of choice. 😍 iA Writer is where I jot down rough notes, write shitty first drafts, and finish my final posts. Everything is synched across my devices via iCloud so I can write and take notes whenever and wherever I want. I’ve been using it for years now and can’t imagine working without it.

Reeder 5

RSS! RSS! RSS! (Almost) every day, I start the day by opening Reeder to see what all of you wrote on their personal sites. You’ll find my OPML of personal sites here, by the way. The latest version of this neat RSS feed reader app even comes with sync via iCloud, so you don’t need an additional service like Feedly anymore to save and sync your feeds.

Workflow and Productivity

Notion

It took a bit getting used to Notion, because it offers so much flexibility in how you structure your documents and workspaces. But it has since become an invaluable tool for me to document and refine project information and workflows. Notion is like Confluence should be. ;) Notion is also completely free to get started.

In case you want to try it, you can use this link to sign up, by which you’ll also help support me and my content 🤗: Get Notion

Things

Things is the task management tool I use to organize my days and projects. It is available for Mac, iPhone (and Watch), and iPad and it is just great to be able to access your lists of lists from everywhere. Although I’m not a practitioner of GTD (Getting Things Done) or any other productivity technique, I still use Things on a daily basis to keep track of the most important tasks.

Timery for Toggl

I track my hours across all my clients projects (and, as of late, unpaid side projects) with Toggl. It works really well in the browser, but the mobile app has always been a pain to use, especially when it comes to entering times manually. I recently came across Timery, which provides a great UI on top of free or paid Toggl accounts. Thus far, it looks like it might enhance my time tracking experience a lot, especially on iOS.

Cron

Cron is “the next-generation calendar for professionals and teams” with an intuitive UI built for speed and I wanted to give it a try. It currently only works with Google Calendar, which might keep me from switching completely as my whole calendar is on iCloud at the moment. But we’ll see how it goes.

Spotify

I don’t function without music. It’s also my favorite productivity tool. 😉

System Tools and Utilities

Raycast

Raycast is a launcher for MacOS. It replaces the default Spotlight search and lets you complete tasks, calculate (and you can hit ⏎ to copy the result!), search, and, of course, open apps quickly. You can also install various extensions for tools like the Calendar, Shortcuts, GitHub, Notion, VS Code, Zoom, and many more. My personal favorite: the window management extension that lets you define keyboard shortcuts for all kinds of window positions.

The Unarchiver

A neat little tool to unpack all kinds of archives, from ZIP to RAR to Tar to 7z.

Amphetamine

Sometimes, your Mac just shouldn’t go to sleep. In a workshop or while presenting or teaching online, for example. Amphetamine takes care of that.

Radio Silence

Just like Little Snitch, Radio Silence is a firewall app that monitors your internet connection and shows you every network connection in real time. This way, you can quickly identify whenever an app wants to “phone home” and block it with a single slick.

Aiko

Aiko is a free app by Sindre Sorhus that provides high-quality transcription for audio files from meetings, lectures, podcasts, and more. It is powered by powered by OpenAI’s Whisper model running locally on your device.

KeyCastr

If you’re running online workshops or recording screencasts, it can be really helpful to display all your keystrokes in a corner of the screen. KeyCastr is a free, open-source utility that lets you do this.

Pro Mouse

Pro Mouse is another useful utility when you’re presenting or running workshops online. It puts a circle around your mouse pointer and lets you zoom in and even draw on the screen.

Web Development

Visual Studio Code

Well, it’s VS Code. ¯_(ツ)_/¯

Tower

Tower is my Git client of choice. It’s simple and a joy to use and makes some of the more advanced Git features easy to handle for people who don’t like to do everything via the command line.

Fork

Another Git client that some people recommended. I will give it a try and see how it does compared to Tower.

Transmit 5

I still use SFTP regularly, and Transmit by Panic just gets the job done, fast and reliably, including rules (“don’t upload .DS_Store files, please”) and file sync.

iTerm2

iTerm2 is a replacement for the macOS Terminal with great features like search and autocomplete.

Sequel Ace

Sequel Ace is the “sequel” to Sequel Pro. It’s a fast, easy-to-use database management application for working with MySQL and MariaDB databases.

ImageOptim

ImageOptim is an open-source tool to dramatically reduce the size of images using modern image optimization tools and encoders. Invaluable if you care about web performance or need to stay within a certain file size budget with your images.

Design

Adobe After Effects, Illustrator, InDesign, Photoshop, Photoshop Beta, XD

For anyone working in the creative industry, Adobe’s apps like Photoshop or Illustrator are indispensable tools and many of them are effectively industry standards. In my work with agencies, for example, I use Photoshop, Illustrator, and currently also Adobe XD on a daily basis.

Figma

More and more agencies and clients of mine are using Figma, so that’s obviously a must-have as well.

Affinity Designer, Photo, and Publisher 2

If you’re looking for design and photo editing software that is easy to use and not subscription-based, Affinity’s apps might be for you. For €179.99, you’ll get three powerful apps that run smoothly on Mac, Windows, and iPadOS. You can also try them out for free for 30 days.

Audio and Video

Loopback

Rogue Amoeba’s Loopback is an amazing, invaluable tool if you want full control over your audio workflow. With Loopback, you can combine audio coming from applications and audio input devices and turn them into as many virtual input or output devices as you need.

Blackmagic ATEM Software Control

My workshop setup also includes an ATEM Mini video switcher and ATEM Software Control lets me configure everything, including on-the-fly equalization of the microphone audio signal.

eqMac

An equalizer for macOS for more oomph! when listening to RTJ, Kendrick, etc.

Reaper + Ultraschall

Reaper is a DAW (digital audio workstation) for recording, editing and producing audio. Ultraschall is a free extension for Reaper that turns the UI into an optimized podcast production environment.

iZotope Product Portal + RX Elements + Nectar + Neutron

iZotope’s audio plugins and software tools let you mix, repair, clean up, and improve your audio recordings.

HandBrake

HandBrake is a useful little open-source tool to convert video from nearly any format to a selection of modern, widely supported codecs and formats like MP4 or WebM.

DaVinci Resolve

Used by Hollywood, Blackmagic’s DaVinci Resolve is an all-in-one software for video editing, color correction, and motion graphics, much like Adobe Premiere or Apple’s Final Cut Pro. With one key difference: it’s free.

☕︎

Alright, that’s the list for now. Let me know in the Webmentions below, for example by answering to this post on Mastodon, which apps you can’t live without and make sure to subscribe via RSS for the next blog post. 😉

In a recent project, the web fonts I bought and downloaded were only available as WOFF2 files. Staring in disbelief at the unpacked folder full of WOFF2 files, I wondered: Why did they not include WOFF files as well? Isn’t WOFF still needed? Or is it finally time to ditch WOFF? At least building for the Web includes regularly reevaluating how you do things. So, I asked the people of Mastodon. The unanimous answer: It’s WOFF2 or nothin’!

I still vividly remember how a post by Zach at the end of 2016 made me abandon the “bulletproof” @font-face syntax that also included TTF, EOT, and SVG font formats in favor of a much-reduced version using only two font formats: WOFF2 and WOFF.

Apparently, the web font world has changed once more and the new modern @font-face syntax now looks like this:

@font-face {

  font-family: "Open Sans";
  src: url("opensans.woff2") format('woff2');

}

Pretty simple, right? Just one format.

As Zach wrote in his article, “given that web fonts for readable content fall back to system fonts when formats are not supported, it’s ok to be progressive here.”

Which browsers are we sending into the dark lands of system fonts with this syntax?

• IE 11, 10, 9, 8, 7, …
• Chrome 4 through 35
• Edge 12 and 13
• Safari 3 through 9.1
• Firefox 2 through 38
• Opera 22 and below
• Android 4.4.4 KitKat (less than 0.5 % of Android devices) and below
• Mobile Safari (iOS) 3.2 through 9.3

According to Caniuse.com, almost 95 % of users have a browser with support for WOFF2 today. If you look at the date relative statistics, you’ll notice that the major shift happened in 2015 and 2016. By the end of 2016, all major browsers supported WOFF2 in their latest versions. Seven years later, support has grown to a level where it seems totally fine to not include WOFF anymore – unless you know for a fact that a large percentage of your users is still using older devices and browsers. On the other hand, there is no reason to remove WOFF from already existing projects either. If you include WOFF2 before WOFF in your @font-face syntax – and the order really matters here –, modern browsers will use and download the WOFF2 versions anyway.

But if you find yourself sitting in front of your computer one day, staring at a folder full of only WOFF2 files, it is comforting to know that WOFF has indeed left the building.

Regardless of which country and school system you grew up in, chances are you have heard this sentence at least once from one of your teachers. I, for one, remember my elementary school teacher rebuking pupils who were pointing at the lines of words in their books. And thirty years later, as my son just confirmed to me, this hasn’t changed a bit. At a certain age, students are told to not read with their fingers anymore.

The idea behind this is that fluent readers don’t have to rely on their fingers anymore and that pointing will slow students down and prevent them from growing into fluent, expressive readers. So while almost all children learning to read will naturally use their fingers as training wheels to not lose focus and to stay in line, the same behavior is later often seen as an indicator for poor reading abilities and, sometimes, even a reason for concern. If little Jack can’t read properly without using his index finger as a pointer, he probably has some reading difficulties, right?

Imagine my astonishment, when I listened to an interview with Jim Kwik in which he said (I’m paraphrasing):

What? 🤯

And indeed, as a quick online search revealed, this seems to be a well-known fact in the speed reading community, which I am – obviously – not a member of.

But why does it work?

As Jim explains, our brains are wired to detect and be attracted by movement. If anything moves in our field of view – let’s take a saber-tooth tiger in a bush as an underused example, or a lightsaber, if you like – it is hard to not let your attention be grabbed by it. By using our finger, we force our brain to focus on the movement right in front of us. More focus means less distraction and this faster reading. Another reason is that our visual and tactile senses are closely linked. What does a baby do when you rattle with a key or a colorful toy in front of her eyes? She grabs for the toy. You can see and grab the thing? Now, that must be real.

All this is also backed up by scientific studies: as one study by researchers at the University of Sydney showed, for example, finger tracing even makes learning in general easier and more motivating. Associate Professor Paul Ginns provides an additional explanation:

“It seems that humans are biologically wired so that we pay closer attention to the space near our hands. So, when using an index finger to trace visual stimuli, these elements of a lesson receive processing priority. Tracing can also assist learning because it ‘chunks’ all the important elements of new material into one piece of information, making it easier for us to learn.”

Just like Google is constantly indexing the Web, OpenAI is now crawling the open Web to scrape content from websites for free to train their LLM (lucrative language model) “AI” products.

But, as I learned from a post by Ethan on Mastodon, you can disallow GPTBot to get its tiny robot hands on your writing by adding those two lines of code to your website’s robots.txt:

User-agent: GPTBot
Disallow: /

Good riddance, GPTBot! 👋

Alright, let’s write more about CSS! CSS! CSS!

Change

I’ve been writing CSS since the early 2000s, shortly after we ditched building web layouts with tables and spacer GIFs in favor of hacking our designs together with floats. CSS has since become my favorite programming language and, looking back on how the language has developed in all those years, one thing is certain: CSS is not the same anymore. The CSS we were writing in 2003 was different from the CSS we were writing ten years later in 2013. Fast forward another ten years, and the CSS we are writing today is again far more powerful but also far more complex than ever before.

The fact that CSS has evolved isn’t a huge revelation in the first place, of course. CSS, just like the Web, has always been changing. Remember the excitement, for example, when we first got to use properties like box-shadow, background-size, or border-radius?

If you attended this year’s CSS Day in Amsterdam, however, or watched the videos via the live stream, like I did, you might have noticed that this time, something feels different. This time, the changes coming to CSS are so fundamental on so many levels that it almost feels like a singularity. There is now the CSS before and the CSS after the early 2020s. Want to select the parent of an element? Not possible because of how the browser parses CSS? Well, now it is, with :has(). Want to adjust an element based on the dimensions of its container? Not possible because it might create endless loops? Well, it is now, thanks to container queries and the accompanying new length units. Each of those features in itself is an incredibly useful and long-awaited addition to CSS and the Web platform. Together with other modern features like custom properties, min(), max(), or clamp(), sizing keywords like min-content, max-content, and fit-content, you can create flexible and robust components and layouts like never before. The very foundations of how we understand and write CSS have changed radically.

Sea Change

Beyond all this, however, there is an even bigger and more fundamental shift happening that characterizes this new era of CSS:

CSS is now the most powerful design tool for the Web.

For many, many years, creating high-quality websites largely meant that designers had to fight what felt like an uphill battle to somehow make their ideas work in browsers. At the same time, sentences like “I’m really sorry, but this solution you designed just can’t be done with CSS” became part of each developer’s repertoire of standard answers. The pretty pictures designers envisioned (and got approval for from stakeholders) were often too advanced for the still maturing styling language. Creating killer websites meant understanding and working around the constraints and quirks of CSS.

So the designers learned their lessons and started to create more compatible layouts, for example by using the average 12-column grid almost exclusively. The platform was the limiting factor.

This has now changed to the opposite.

Want to emulate and confidently design a layout that leverages the potential of CSS Grid in any of the major design tools like Figma, Adobe XD, or Sketch? Not possible. Want to define a color in one of the wide gamut color spaces like OKLCH, which result in more vibrant and natural colors on modern screens, maybe by using a color picker? Not possible. You want to simulate fluid typography that dynamically scales font sizes based on the viewport or container size and also define minimum and maximum values like you can do it in CSS with clamp()? Not possible. Or how about defining a fallback font in case your web font doesn’t load? Good luck using any screen design tool on the market. Not only are all of those things – very clearly – important design decisions, but they are also easily possible with just a few lines of CSS. In this new era of CSS, the design tools are now the limiting factor.

In a talk I gave last year at CSS Café, I also talked about ways to close this growing gap between design tools and CSS. Closer collaboration, more prototyping, and more people engineering the design at the intersection of web design and development are just some of the things we can do. But all of this isn’t easy and will take time. Some teams are already exploring and working in new, more connected ways. For others, it will be harder to break old habits.

Tool Change

What I expect to see overall is that the perception and thus the role of CSS in the design process will change from being mainly a presentational styling tool at the end of the waterfall to a tool that is being used at the heart of making design decisions early on. The value of a designer who knows how to prototype and build web components with modern CSS will therefore increase a lot. As a design engineering freelancer, I’m noticing this already.

After his talk at CSS Day, Heydon got asked whether he thinks that designers should now learn CSS. He answered with the polite restraint and diplomatic prudence of someone who had (possibly) once broken the Large Hadron Collider. But his answer showed how CSS has already been understood and used by many people: as a design tool, a means to an end, a material to explore and work with. And, as a tool that lets you think and make decisions, at the center of the design process.

This is the new CSS. The most powerful design tool for the Web ever. Only by using CSS, you can leverage what the platform is now capable of. Only by designing with the new CSS, you can create designs that flexibly adapt to different contexts and different types of content. Only by using the new CSS, you can build designs that are truly “of the Web”, materially honest, and elegantly efficient. Should designers learn CSS? As Heydon said:

This piece by Cory Doctorow about blogging, which I read a few days ago, is exceptional. Why?

I already knew that blogging – and having a personal website in general – is a superpower.

I had heard before of Vannevar Bush’s groundbreaking essay “As We May Think” that directly inspired the invention of hypertext by Ted Nelson and Douglas Engelbart, which, in turn, had a huge influence on the WorldWideWeb project.

I also knew that a blog lets you document your thoughts and impressions in what can become an archive for your notes and a record of your experiences over time.

I knew that by sitting down and writing, your writing will inevitably improve.

And, I knew that some people are bad at writing regularly and that others – and that’s why we like to call them “writers” – aren’t.

What Cory describes in his post, however, goes far beyond those individual ideas. He combines them into an approach to blogging that is maybe the most compelling and empowering reason to have a blog.

The Act of Publishing Keeps Us Honest

It all starts with the idea that a blog isn’t just a mere collection of notes in a Web-log. It is more than that because it involves one crucially important, magical act: publishing. Publishing our notes holds us as authors accountable, it forces us to shape our notes so that others will be able to make sense of them as well. Instead of quickly jotting down an incomplete fragment, we are forced to think about what it really is that makes the thought we are writing about so valuable. Why is it relevant? What is the essence of it? What is the best structure to convey that? What do we need to include to communicate it to someone reading our post? This, in turn, also makes it easier for ourselves to interpret our notes later. Instead of kidding ourselves into thinking that our future self will certainly be able to decode our dashed off notes, when we want to consult our record of collected memories, publishing our notes forces us to exercise care. As Cory writes: “Writing for an audience keeps me honest.”

The Source Material

The second important realization is that blogging allows you to collect a vast amount of disparate fragments of information. Any thought, any link, any idea that you come across and that seems to be significant can be documented – including the context and why it seems important – and collected into your own personal “Memex”. That’s the name Vannevar Bush picked in “As We May Think” for his vision of a future device “in which an individual stores all his books, records, and communications, and which is mechanized so that it may be consulted with exceeding speed and flexibility. It is an enlarged intimate supplement to his memory.”

As a supplement to your memory, all those disparate notes sit there ready to suddenly merge into new ideas and turn into something bigger:

Rick Rubin describes a similar creative process in his book “The Creative Act”, which I recently listened to in the excellent audiobook version. His approach is to not limit his input at all, meaning that he curiously allows to enter his mind whatever draws his attention, regardless of whether it might seem relevant or “useless” in his current situation. There is no such thing as useless information, because you never know which new ideas will emerge as a synthesis of all the individual fragments of creative input you were exposed to in the past. Limiting your input will limit the potential for new combinations to arise. Everything we see, do, think, feel, imagine, and experience is the source material, and from it, we build each creative moment.

The thing is: This process isn’t a science. The only thing we can do is to be curious, keep a record of the things we deem to be significant, and constantly look for clues pointing to new ideas, for fragments of thought suddenly turning into something bigger.

What does Cory Doctorow do when one of those “nucleation events” occurs? He uses the search and the tag-based filters built into his blog(s) to surface everything he has ever written about that subject. For one, to aide his memory, but also as a starting point for further research.

A Habit – and a Decision

There is just one piece missing in the puzzle for this “Memex Method” to work. Writing regularly. Daily, even. I know that many of us – including myself – often don’t “find” enough time to write. But here’s the catch: writing every day isn’t just an aspirational goal, it’s a decision. You don’t wait until you find some time to write or only write when you’re kissed by the muse. No, you make the conscious decision to write every day, because that’s what a writer does. Over time, your writing will improve, but more importantly, writing and filling your archive will turn into a habit.

Wouldn’t it be great to feel invincible because you’re building an archive?

Nobody knows you.

You are not entitled to anyone’s attention.

Be respectful, be helpful, be kind.

Your personal website isn’t a replacement for social media. It’s much more than that.

Who is your site for?

Document your life.

Your perspective matters.

Capture your thoughts.

Share what makes you lean forward.

Use RSS.

You never know what sticks.

Make it easy to publish.

Enjoy the process.

The adverb is not your friend.

Typography is everything.

You will surprise yourself.

You will grow.

Be curious. Be intentional.

This is your playground. Play.

Your canvas is limitless.

Sell the world.

Hit publish.

It’s yours.

Manuel asked:

It’s a great question: Everybody just seems to define most of their global custom properties (aka CSS variables) on the :root selector without giving it a second thought – and so am I. But why :root?

The answer is that there is no real reason. It’s just a convention. Defining custom properties on the :root selector might make them look a bit more like global variables, because :root is the equivalent of the root element of your document. In HTML, this is the html element. In SVG, it is the svg element. But besides this potential gain of flexibility – in case you ever wanted to apply the same properties to different types of documents – there is no real technical benefit. You could just as well define all global custom properties on the body element and they would still work exactly the same way.

Sure, you would need to write your JavaScript in a slightly different way, if you wanted to work with your custom properties in JS. Instead of accessing them via the document root element like this:

getComputedStyle(document.documentElement).getPropertyValue("--color")

you would need to retrieve or set their values on the body element:

getComputedStyle(document.body).getPropertyValue("--color")

But this also is just a matter of preference.

Also, the fact that :root has a higher specificity than html might be interesting to know but also doesn’t really make a difference in practice.

The Limits of Inheritance

So yes, there seem to be no real differences between using :root and body. And therefore, using :root, as it is the outermost element, seems to make the most sense. However, Manuel pointed me to the fact that because of how the CSS inheritance model works, using :root does not always guarantee that a custom property is indeed inherited into all elements. It doesn’t currently work for the ::backdrop pseudo-element, for example, which is the element behind elements in full screen mode like <dialog>, as well as for the ::selection pseudo-element that lets you style the parts of a document that a user has selected. In both cases, trying to use a custom property that has been defined on :root will prove fruitless. The CSS Working Group is discussing ways to solve this. But it is definitely an issue many people might not be aware of.

Avoiding :root Growth

Regardless of those inconsistencies in inheritance and although we could also define them on <body>, using the :root selector to define our global custom properties has become a common practice. But what’s really interesting to me is that by using this convention, we also seem to have become a bit complacent in the way we use custom properties. Because defining most or all of your custom properties on :root can also become a problem. Kevin Powell has written about this on CSS-Tricks: if you just use this single place for all your custom properties, you might be able to manage all the “settings” of your CSS in one place, but you will also lose a lot of flexibility. When building components, for example, it is important to design and code them in such a way that you can easily change the implementation or add or remove them without affecting the global code around them or even breaking other parts of the system. Globally defined local properties would make that a lot harder. There is just no reason to define local custom properties in :root that actually belong to individual components.

As Lea Verou noted in her brilliant talk CSS Variable Secrets at CSS Day last year, we are also still not leveraging the full potential of custom properties when it comes to their depth, meaning how many properties inherit or include values from other properties. Or, to put it in another way, we don’t put custom properties inside each other very often. One reason might be that we are still mostly treating CSS custom properties like constants. We mostly use them as replacements for fixed values that we only have to define in one central place, which often happens to be, you guessed it, :root. Leaving this habit behind, however, and understanding that custom properties can do so much more is the key to unlocking their full potential.

To give you just one example derived from Lea’s talk, you can use custom properties locally that are basically like private variables but based on a global variable. Sounds complicated? Imagine a simple button component with a background color stored in a global custom property:

/* tokens.css */
:root {
	--color: hsl(160, 100%, 75%);
}

/* button.css */
button {
  background-color: var(--color);
}

This would work well in general and would also inherit the color value nicely into the button component. In a design system (or a modular website), this is exactly what you want. However, it is always a good idea to provide a fallback for custom properties, also because the component would then still work well even without the --color property being defined. With a local custom property that is based on the global property but already has the fallback baked in, you maintain the flexibility of being able to manipulate the color from the outside of the component. At the same time, you make the implementation much more robust:

/* tokens.css */
:root {
	--color: hsl(160, 100%, 75%);
}

/* button.css */
button {
  --_color: var(--color, black)
  background-color: var(--_color);
}

If we now use the button component within a system that provides a --color, the button has a background in the color we defined. If not, the component still works and uses the fallback color, black, instead. Inside of our component, we can use the local custom property (written with an underscore, again a convention) to define hover styles, borders, box-shadows, and more. And, we can still manipulate or set the --color variable from the outside of our component without breaking it. As Lea puts it: CSS variables effectively allow us to create a higher-level styling API.

This is just one powerful example which shows that combining global with local properties can lead to much more flexible and robust CSS. So while it might be still a good idea to define your global custom properties on :root as a best practice, also try to think beyond that. You can use CSS custom properties everywhere all at once.

Today, I started a new project with Kirby CMS. (No, it’s not my personal site. That one’s still brewing…)

Kirby is a lightweight, no-fuzz content management system (CMS) created by Bastian Allgeier, which works well for projects of any size. It is easy to install and amazing to work with in development, also because it adapts to the structure and size of your project and you can flexibly configure the interface of the backend, the Kirby Panel, accordingly.

Kirby is a so-called flat file CMS, which means that in order to create the structure of your website (“app”) with all its subpages and routes etc., you basically create a folder structure and put text files or images inside of those folders. Kirby then pulls the content from those files and displays them. This speeds up the initial setup of the project structure a lot and also means that, if you want to, you can put all your content in the same Git repository you’re using for the rest of your code. No database needed. The nice thing is: your team mates, clients, or content managers don’t have to be as nerdy as you and can still use the Panel to add and edit content as well. As a developer, you get the full flexibility of writing your own templates and template snippets and you can use the many smart, built-in objects and methods to display and manipulate your content. Kirby has great docs, a rich plugin ecosystem, an API to interact with your site or access content, and it can also be used as a headless CMS. The team behind and the community around the CMS is lovely and always ready to support you via the Community Forum , which is already full of answers as well. One last thing: a lot of people seem to be prejudiced against PHP these days, so you will be delighted to learn that Kirby is based on PHP with all the robustness and broad support across the industry that comes with it. 😉

Kirby = Successful Projects

So yes, as you might have noticed by now, I am a big fan of Kirby, especially because it allows you to solve common problems in a straightforward way, making my life as a designer and developer so much easier, but also because my clients have always been very happy with the content editing experience in the backend – without exception. Kirby enables successful projects.

But it is not only really useful to build client projects. It also powers loads of personal websites and side projects. So if you are looking for a CMS that is fast as heck and a joy to work with, I’d give it a try.

My plan is to share a bit of my experience and process from this project and from building a few projects with Kirby in the past here on my site. I don’t know which steps or learnings will make it into a post, but I’d love to document a few crucial steps for myself and anyone who wants to build a site with Kirby.

If there is anything that you would like to learn, let me know via a blog post of your own – and a Webmention – or on Mastodon. Although I certainly don’t have all the answers, I might run into similar challenges and feel the urge to share how a solution could look like.

Oh! Have you published a post, a tutorial, a plugin, or anything else that could be useful for the community? Let me know as well.

PS: My friend Manuel Matuzović is rebuilding his personal site with Kirby at the moment and shares his process and many useful tricks on how to build a modern, accessible website in short videos on Vimeo.

A while ago, I wrote about what you could include in a README file for a project. Based on this post and a few practical examples of READMEs, I created and published a template that I will use in my own projects going forward.

It is available on GitHub: https://github.com/matthiasott/README-template

The template might certainly change a bit over time. But as it is now, I think it includes the most important sections I might need in most projects. Because not every project is created equal, the idea is to just use what you need and delete the rest of the template. So in case you want to use it as a starting point, feel free to modify it – and also notify me about any improvements that could be made.

An Automatically Generated TOC

Depending on the size of your README, it might also make sense to also include a TOC, a Table of Contents, at the start of the file. You could create such a TOC manually, but I also found a neat little package called DocToc, that automatically creates such a TOC for you, including anchor links to the respective sections of your file. Actually, you can use DocToc to generate a table of contents not only for a README but for any kind of markdown file inside a local git repository.

You install the package globally via npm (so Node.js and npm are a requirement):

npm install -g doctoc

You can then generate or update table of contents for all markdown files including all subfolders with the command

doctoc .

If you only want to generate or update a TOC in an individual file, you add the file name to the command:

doctoc README.md

By default, DocToc will create a TOC including anchor links using the GitHub markdown parser. But you can also tell it to create compatible links in the style of Bitbucket, Gitlab, or Ghost, for example, by using a flag:

doctoc README.md --bitbucket

If you want to specify where in your README DocToc adds the table of contents, you can place two lines of comments in your files and DocToc will place (and update) your TOC at this position:

<!-- START doctoc -->
<!-- END doctoc -->

You can even specify a title for the TOC with the --title option:

doctoc --title '**Table of Contents**'

So, in my case, I used this command to automatically generate the table of contents for my README template:

doctoc README.md --title '## Table of Contents'

Now, every time I need to update the TOC, I run DocToc and it will automatically update all items, titles, and links. Nice!

A README editor

Just a quick addition: While doing a bit more research for a good README structure, I also stumbled upon a handy editor made by Katherine Oelsner. Readme.so lets you create an individual README by adding sections from a list of snippets. You just select the sections you want to include in your README, rearrange them via drag and drop if needed, adjust the text, and download your template. A nice and easy way to create your README as well, especially if none of your projects is like the other and a rigid template structure therefore wouldn’t make much sense.

Manuel shared how he approaches writing and publishing blog posts on his personal site. If you follow him, and especially if his RSS feed is on your list of feeds, you know that Manuel indeed does put out a lot of posts. Just recently, he completed 100 posts about more or less modern CSS, so his process certainly works for him.

Keeping The Friction Low

What works for some people might not work for others. So if you struggle to put out blog posts, Manuel’s approach might work well for you or also not work at all. But there are a few things he mentions that are, in my experience, key if you want to publish posts more easily. For example, he does not care about the details too much, particularly early in the process. This keeps the friction low and it keeps you going. It maintains momentum. This includes that he doesn’t care about typos, correct sentence structure, or anything else that people might call “a mistake”. Separating a quick, messy research and drafting phase and a final writing phase also makes writing much easier because you already know what you want to write about.

The Input Phase

My usual process is somewhat similar. I also collect all the stuff I can find – links, examples, own thoughts – in a very messy and rough way in iA Writer in a markdown file in my drafts folder. Sometimes I have nothing but a first idea or a post title. Sometimes I’ll write down a few keywords and paste a bunch of links into the document, sometimes I’ll write a few sentences with key points, and sometimes even a few paragraphs. This really depends on the topic and my form of the day. 😉 It helps if this input collection phase is short and, for example, done in just one hour or throughout a day. For some posts, I might also collect ideas and links for several weeks.

The Shitty First Draft

I then write most of the shitty first draft of the post, usually in one go, and I also don’t fiddle around with the sentences and grammar yet. There might also be a bit of German in there when I can’t find the right word for something immediately. This first version of your post is not about getting it right. It’s about getting it out. And knowing that you don’t need to get it right at the first try gives you an immense amount of freedom. It permits you to write freely and without pressure. By the way: not putting pressure on yourself also means that if you have a great idea for a sentence or happen to write a paragraph in one go that is just right, you are, of course, allowed to polish it a little right away. The important thing is just to not lose the flow and keep going until the end of the post.

Editing

After writing this first draft, I go through the post with my “editor self”, often on the next day with a clear mind and bit of distance. It is amazing how different a post can feel after a good night of sleep. I now try to cut out all the unnecessary stuff. I read the post out loud and imagine that I’m reading it for the very first time. Is everything clear and concise? Do the sentences connect? Could I add a few headings to make the structure of the text more clear? Does the main point come across? Are the code samples fine? It the title good?

What is important in this phase is that you don’t confuse the editor in you with the inner critic. As Rick Rubin writes in his book “The Creative Act”, the inner critic doubts the work and undermines it, while “the editor steps back, views the work holistically, and supports its full potential.”

Publication

The last important step is to not overdo it with the fine-tuning of the post. As Chris Coyier said, “we’re not shootin’ for the Pulitzer over here”. So, at some point, I ignore the voice in my head that tells me that I could still improve the post further, move the text over to Craft CMS to look at it in preview mode, and, ultimately, hit publish.

How do I know that a post is ready? I have no clue. I think there is a sense of completeness that can be felt, the feeling that while you could hone the details forever, it would not make the post any better. And you also can’t really add or remove something without making the piece worse. That feeling often comes out of a sudden. Just seconds ago, a post might have felt unfinished. You change just one little detail and, suddenly, it’s done.

After publishing it on my site, I always read the post one last time. And almost every time, I will find something that I overlooked. A missing link, a typo, whatever it is – that last check is always worth it.

What About You?

What is your process of writing blog posts? I’d love to hear what works for you. Maybe in a blog post in response to this one?

Solid documentation of a project is important, especially if you’re working in a team. When all information about how to install, deploy, or contribute to a project is buried in only one person’s brain, you’re in trouble once you have to make changes and that person is on vacation or has even left the team. So, a README file at the root of your project is not only your friend, it’s essential.

What’s in a README?

But what information should you put into the README of, let’s say, a website project? I’ve seen (and written) quite a few short and incomplete READMEs, so coming up with a good one surely is an art in itself.

The answer is, as always: it depends. It depends on the project itself, the team size, or the time and budget you have. So there really is no right or wrong here. There are, however, a few things almost every README has. Here’s a list of things you might consider to include:

Name and Description

What is this project about? What does the project do? Why is it useful? What problem does it solve? Who is it for?

Installation

How do you install the project and what do you need for it? Mention all dependencies that need to be installed first. Ideally, you also provide version numbers. (I’m looking at you, Node.js…)

Configuration and Usage

Instructions for how to configure, run, and use the project. For example, you can include the commands needed to start the development environment or any other useful and important commands.

Deployment

Instructions for how to deploy the project to a production environment, including any server requirements and commands used. And, in case you are using a CI/CD pipeline, for example, how do any automated processes work?

Testing

Any unit or integration tests people can run to assure that everything’s working as expected? Any frameworks or commands that are needed here? And are there any tests in your deployment pipeline that ensure that no errors make it into the live site?

How to contribute

Often overlooked, but so important: how do you contribute to the project? Are there any guidelines you should adhere to, for example, related to the coding syntax? But also: how is the approval process? Do people commit their changes to Git branches? Do they write pull requests? Who can merge and push, and so on? And who is the point of contact for the project in case you have questions?

License

If applicable, and especially if the project is publicly available, provide license information.

Roadmap

What are you planning to add in the future? Any known bugs or missing features?

Changelog

What did change with which version?

Authors and Acknowledgments

If people helped to build the project or provided useful contributions like features or bug fixes, or also if your project is built on other people’s open source code, mention them and – thank them!

~

I’m sure that I’m still missing some things. So if there is anything you would add, write a quick response blog post. ;) But whatever you include in your next README (template?), keep in mind that a good README is concise, complete, and up to date. It doesn’t necessarily have to be short. If there’s a lot to say and know about a project, then write it down. But always have the people in mind who will read the file. Keep it as short and simple as possible and also consider that not everyone might know what you know. So better include a few bits of information or links too many to make sure everyone will be able to get started and successfully work with your project.

For more useful tips and resources about READMEs, also have a look at the GitHub docs, this article by Binyamin Green, Make a README, and Awesome READMEs.

Leonie Watson just shared an interesting audio snippet on Mastodon:

https://front-end.social/@tink/110007014963441869

What sounds like her speaking about accessibility is actually not Leonie, but an AI-generated synthetic voice, a cloned version of Leonie’s voice based on audio training data.

I was aware of the fact that speech synthesis is getting much better and that machine learning plays a big role in synthetic voices sounding more realistic, for example by adding modulation, variation, and emotion. But when you listen to some of the samples of the voices on play.ht, it is astonishing to see just how accurate and realistic those voices, and especially cloned voices, have become. It is now almost impossible to distinguish a human speaker from a synthetic voice. Mind-blowing and, at the same time, scary and full of potential for misuse.

First of all, this is an amazing thing for everyone who, like Leonie, uses assistive technology to browse the Web, read content, and who interacts with any other kind of user interface that is based on audio output. Listening to robotic, unemotional voices everywhere isn’t fun. So imagine how beautiful the Web suddenly sounds once you let a warm, gentle, human-sounding voice – or maybe even a familiar voice like your very own – read the content for you. Imagine a chat where the voices of many contacts will be synthesized so that not only people reading messages visually will, very literally, hear the other person’s voice in their head without the distracting artificial charm of Siri. Or imagine someone visiting your website and, if they like, they can listen to an audio version of all the posts you ever wrote – read by you. Or you – no, everyone! – speaking every language fluently in business calls. You can already use tools like resemble.ai to clone a voice based on three minutes of data and use an API to integrate that voice into whatever you’re building.

But I’m sure that by now, you’ve also thought about a bunch of not to desirable futures. Voice bots calling you in the middle of the night, trying to sell you an insurance (okay, this is already happening). Scammers calling your grandma. People canceling your orders or placing new ones on your behalf. Artists getting their voices pirated and used to create an endless stream of sameness. Basically everyone could be stealing and remixing each other’s voices, because they’re up for grabs. Prank’d!

(Related: I’m now pretty sure that my descendants will have a fully interactive virtual version of me in some kind of app that they can open whenever they miss me…)

All of this will happen in some way or another. But with all things related to “AI”, it’s on us to decide which future we want to create.

After about a year of living in our new home, after waiting for our neighbors to finish their driveway (life lesson: don’t expect gratitude from strangers), after our wholehearted horticulturist recovered from an acute illness, and after thaw had set in in the southwestern part of Germany, the circumstances finally were ideal for the ground work on our garden to begin.

My humble role in it: digging a whole between the sidewalk and our front door for the bushes. Not necessarily those typically German bushes that grow into a beautiful, thick hedge, but still large enough to keep the kids from running into the street or to (hopefully) impress a few Swabian SUV drivers to not use the sidewalk for a little sidestep. The latter won’t happen, I know. It’s just to keep us motivated.

So I dug a pit. About 50 centimeters deep. Beautiful. Impressive, even, to the amateur craftsman. But then, the crucial question: is it deep enough? Didn’t our horticulturist say that about 50–70 centimeters should be enough? But it’s a narrow pit, so… On the other hand, our (friendly) neighbors tell me that their whole in the ground wasn’t much deeper. And look at their tree back there, it clearly has enough fertile soil to, one day, grow into a huge, magnificent… does it, though?

After pondering about it for a little while, I gave in and stopped digging. 50 centimeters should do it. Also, my back and my arms hurt. Time to call it a day. It’s Saturday and my football (⚽️) team won.

But during the evening and the whole Sunday, that nagging feeling remained. What if 50 centimeters… ah, come on, that’s plenty! I dug like a pro!

Monday

The horticulturist (what a lovely word) arrives.

“Oh, I see you were busy! That should do it. The bushes won’t grow very tall and you’ll probably need a bit more fertilizer, but it’s okay.”

“But what if we want beautiful, healthy plants?”

So that’s what I did today. 20 more centimeters.

Sometimes, it’s better to trust that gut feeling that tells you that if you don’t want to half-ass it, you need to go a little further.

And sometimes, you just need someone who tells you to dig deeper.

Dave wrote about what he calls The Feature Work → Maintenance Work Loop: he often finds himself working in cycles of Feature Work and Maintenance Work, “balancing the growth and health of a product with a cycle of building and repairing”.

I’ve noticed the same both in design and development work. There are phases in all creative work where we go broad, where we explore new ideas, concepts, or features, where we create lots of layout variations or build prototypes. This work is about the broad strokes, about expansion, discovery, and play. It is is then often followed by a phase of refinement, of fine-tuning the details, selecting the pieces we want to continue with and throwing out the superfluous. But it can also be about maintenance, taking care of a design system or a code base and improving what’s there to be able to move efficiently again.

Rick Rubin talks about very similar phases in his latest book The Creative Act. In the experimentation phase it is all about growth, about generating possibilities, and discovering which creative seeds have the most potential.

In the crafting phase that follows, we start with the labor of building out what has revealed itself as the best way forward. You might feel less excited about this phase because it can be daunting and is often less glamorous. But, as Rubin notes:

So if you feel like this crafting phase is less enthralling, remember that it is equally important as the exploration phase for the final result. It might, as Rubin writes, help to think of it as another opportunity to play. Just that this time, you’re playing at a much more fine-grained, more intricate level. You’re now in control over the details. If you put love and care into this phase, it can be clearly recognized in the final work. Or, in the words of Charles Eames:

Let’s call it what it is: Progressive Web Apps (PWAs) were a great idea full of potential but they never really caught on. One reason for that was that although you could add any website to the Home Screen in Apple’s iOS, it always felt like nothing more but a fancy bookmark. Your PWA would get a nice app icon and open immediately, but it had no access to crucial system level features like notifications.

This changed yesterday with the release of iOS and iPadOS 16.4 beta 1. What nobody would have deemed possible for years finally happened: Apple added support for Web Push to home screen web apps. Developers can now use the Push API, Notifications API, and Service Workers to send system notifications after asking for permission. Those notifications will work exactly like other app notifications. They will show up in places like your Lock Screen or in Notification Center and you control them via the system settings.

One more thing…

iOS and iPadOS 16.4 will also add support for the Screen Wake Lock API, the Screen Orientation API, the User Activation API, and Web Codecs API video support.

The Web platform always wins.

As I noted yesterday, screen readers don’t convey the semantics of many HTML elements like strong or em.

When I shared my post on Mastodon, Stéphane Deschamps chimed in and pointed to an promising candidate recommendation fresh from the press that might give authors much more control over how screen readers handle their content: CSS Speech Module Level 1.

Please bear in mind that this is still only a so-called W3C Candidate Recommendation Draft. This means that it is not a standard (yet), nothing of this is available in any browser as of today, and a lot of things might still change before any browser implements any of those features.

Still, it is worth to have a first look at what is being discussed at the W3C. And because the process is quite open these days, you can also provide feedback if you want.

Reading through the document, you’ll encounter a few really exciting properties that might one day find their way into CSS.

Auditory Styles

The voice-volume property, for example, allows authors to control the volume level of the speech synthesizer with keywords like ‘x-soft’, ‘soft’, ‘medium’, ‘loud’, ‘x-loud’ – or adjust the volume by a certain decibel value.

With the speak property, you’ll be able to declare whether or not a piece of text should be read at all using keywords like ‘auto’, ‘never’, or ‘always’.

Where it gets really interesting is the speak-as property. With the ‘spell-out’ keyword, text will be spelled one letter at a time. ‘digits’ will make the screen reader speak numbers one digit at a time. And with ‘literal-punctuation’ or ‘no-punctuation’, you can control whether or not semicolons, braces, and so on are named aloud. Really useful, not only for product, brand, or band names.

There are many more interesting properties that let you insert pauses, for example, or playback auditory cues before or after an element. And you will even be able to adjust voice characteristics like age or gender with the voice-family property and the voice-rate at which voice is spoken in words per minute.

Overall, this looks like a really exciting new draft of a document of which the first version, as I realized, was published more than ten years ago. It is great to see that editors like Léonie Watson and Elika Etemad (fantasai) are now working on this again. Let’s hope that this time, also with the growing awareness for accessibility in Corporate America and the EU, enough momentum can be gained so that many of those properties make it into browsers as soon as possible.

I always was under the impression that if I add emphasis to a piece of text in HTML by adding an em or a strong element, this emphasis would also be indicated to screen reader users in some way. For example, by a change of the tone of voice, much like if you are reading a text out aloud and add emphasis to a certain word by speaking slightly louder.

It turns out that this is not the case at all. As Steve Faulkner recently documented (again), none of the most commonly used screen readers like VoiceOver, JAWS, or NVDA convey the text semantics of those elements to users. And they also don’t expose em or strong element role semantics in the accessibility tree.

At first, I was kind of disappointed to hear that. Isn’t emphasis an important part of the design? Isn’t this the reason we are writing semantic HTML in the first place? But honestly, the explanation as to why NVDA, which supported it for a while, even removed support again reads more than plausible:

Does this mean that you don’t need to use semantic elements to convey emphasis? Of course not. You never know where the semantics still matter. And it is also just the right way to indicate emphasis in HTML for the majority of users. But it is nevertheless interesting and important to know that screen readers don’t care by default.

CSS Container Queries are now available in all major browsers. 🥳 With the release of Firefox 110 yesterday, the stable versions of Chrome, Safari, Edge, and Firefox all support them. There have been many major additions to CSS in recent years, but this one is definitely one of the most impactful game changers. Being able to use not only features of the browser viewport but the dimensions (or other characteristics) of individual containers to change our layouts will once more fundamentally change the way we create responsive and even more flexible layouts on the Web.

During work on the spec, the syntax for Container Queries changed several times. This is also why I held back on writing a longer post exploring container queries in the past. Now, however, the syntax for size queries and units is stable and you can start to use Container Queries in production. So make sure that you use the correct syntax – Miriam has written about this – and that you progressively enhance your layout, of course, so that people with older browsers (which will still be the majority of users for a little bit of time) get a solid baseline experience.

I personally can’t wait to use them more often from now on and I’m sure that if you keep your eyes open, opportunities to effectively apply container queries will surface everywhere, just as with :has(). And particularly because they work so well on smaller elements, I’m quite sure that there will be plenty of ways to also use them without breaking our layouts in older browsers.

And I also can’t wait to see all your demos and best practices emerge. 🎉

~

Here are a few fantastic posts and examples to get you started:

Day 56: container queries, by Manuel Matuzović
https://www.matuzo.at/blog/2022/100daysof-day56/

Use the Right Container Query Syntax, by Miriam Suzanne
https://www.oddbird.net/2022/08/18/cq-syntax/

A Primer On CSS Container Queries, by Stephanie Eckles
https://www.smashingmagazine.com/2021/05/complete-guide-css-container-queries/

CSS container queries are finally here, by Ahmad Shadeed
https://ishadeed.com/article/container-queries-are-finally-here/

A CodePen collection of container query examples by Miriam Suzanne
https://codepen.io/collection/XQrgJo

I want to start a little experiment: I want to see if I can reduce my TTFB, which is, of course, short for “time to fresh blogpost”.

Why? Because I think this is something where I can still improve a lot. Although I am aware that a few of you are indeed reading my posts and that this comes with some responsibility, I now also know that there really is no bar for a blog post. And although I’ll always strive to write useful things, I’ve reached a point where I think that writing about more things faster is actually a worthwhile goal. The more ideas you put out into the world, the larger the surface for those ideas to connect, interact, and flourish.

One thing that keeps me from publishing more is that I (still) fiddle around with many posts for too long. There is a time for perfecting a post and going really deep, don’t get me wrong. On the Web, however, it’s smart to save this polishing for the pieces you love the most. For the rest, the most important thing is that you hit publish.

So, here is the challenge: Each day, I’ll write about something for no more than half an hour. 30 minutes. If I am faster than that, fine. If not, then… I don’t know, haha. Maybe I’ll publish the post anyway – unfinished? For how long do I want to do this? I have no idea, either. Looks like I still have to think about a few details, but hey – I just finished the first post.

Jeremy wrote a little something about streams, in particular about streams on personal websites. His home page actually is like a stream: links, notes, and blog posts all appear underneath each other in chronological order.

Many of us are now rediscovering or reviving their personal sites, not only because the demise of Twitter has made it abundantly clear that we need to shift our attention away from large social media silos when we share our ideas, thoughts, and ramblings online. Our personal sites are the perfect home for all those personal bits and pieces. All those short and long-form posts, notes, thoughts, photos, links, but also just little things we notice in our world, things we learn, and things that excite us – they all belong on our personal websites first. So if you were asking yourself what you should post on your site, the correct answer is, of course, “everything you want”. Your personal site is your home on the Web. It is your playground but it is also a very subjective and individual account of all the things you think and care about. All the things that happen in your head. And on your home page, it can all come together in one large stream of different kinds of posts.

You could even think of this home stream as what in literature is called a “stream of consciousness”: a constant stream of the multitudinous thoughts and feelings which pass through the mind of a narrator. Your website is a way for you to share your stream of consciousness, that temporary and subjective and highly biased snippet of the universe, with everyone else, including your future self. In all its multitudes.

If you look at my home page, you can see that I haven’t yet turned it into a stream. It almost looks like I haven’t posted anything since 2019. This wasn’t a conscious decision and it is something that I am going to change in the process of redesigning my site this year. And I couldn’t agree more to what Jeremy wrote. If your home stream looks like a collection of posts that all look visually distinct, more “like a chaotic second-hand bookstore”, it will be much closer to who you and your unpolished stream of consciousness actually are. It will make your site more personal and, if you want future visitors to be able to tell the difference between you and an AI, more human.

A lot of us are still working from home these days. Many are in meetings every day, more and more people are holding important customer presentations or running workshops from their little home office, and some are even joining podcasts and online meetups as guests, or are starting their own video channels or video courses.

Naturally, high-quality sound is something to think about. It might even be the most important part of your appearance, even more crucial than good video and lighting. So we might buy better microphones or treat out rooms with foam or, way way better, absorbing sound panels.

There is, however, one little detail that many noobs – me included – tend to forget about but which makes a huge difference in how our recordings sound, even (or especially) with the best of microphones: the reflective surfaces right in front of you.

If you have the feeling (or recorded proof) that your microphone picks up a lot of boomy reflections, consider adjusting the position so that it faces more away from your desk or computer monitors. As Bandrew demonstrates in this plain and simple explainer video, this tiny change can make a huge difference!

And it might even save you a bit of money, as well. Boom! (Sorry.)

When it comes to tracking and analyzing a website‘s traffic, Google Analytics (GA) seems to be the obvious choice: everyone knows it, it’s powerful, it’s free, it’s used by millions of sites. 53 % of sites worldwide, to be precise. No wonder many clients ask for it and many people who build websites willingly add it to the sites they build and sell.

There are, however, a lot of downsides that come with using GA. And some of them are actually real downers. Using GA can be bad for the performance of your site, you are giving all the stats about your site to the largest ad-tech firm in the world for free (that companies readily do this still blows my mind), and most people will never use it for more than to occasionally access a few (often partially inaccurate) stats, also lacking any proper strategy on which insights they really want to collect and how to translate those insights into real action. The most daunting drawbacks, however, are related to privacy and regulations like GDPR. When you add GA to a site, it will transfer personal information to Google, so you not only have to adjust your privacy policy accordingly but also obtain consent from your users. The same goes for the cookies that GA stores on your users’ machines. Using GA means that your site needs a cookie consent banner – lovely!

Looks like there are many good reasons to look for alternatives to Google Analytics. And thankfully, there are quite a few these days, many of which not only provide a nice set of features but are also privacy-focused and often even cookie-free.

Here’s a short list of some interesting options. Many of them were suggested to me by all the lovely people who replied to a post of mine on Mastodon. By the way: if you ask a question on Mastodon, you’ll receive so many helpful answers – it’s wild! Imagine Twitter but with real human interaction.

• Plausible
• Simple Analytics
• Fathom
• Matomo
• Cabin
• Umami
• Pirsch

Also, Pelle shared a link to a longer list of European alternatives to GA.

We all want to do our best work. We all want to create something of value. But what if you’re stuck? What if the solution just doesn’t show up, the idea just won’t come, the interesting just doesn’t want to happen? Writers sometimes call it writer’s block, but not only writers experience it. Everyone who does creative work knows this feeling of just not being able to make progress.

Whenever we’re stuck like this, it is important to recognize that this is totally normal and nothing to be worried about. Such a creative block isn’t really a blocker, it’s more of a short break. The best way to cope with this is to first of all continue to work. Inspiration strikes not when we sit and wait but when we start immersing ourselves in a problem. So don’t wait for the muse to kiss you. Walk on.

I’m currently listening to the audio version of The Creative Act: A Way of Being, a fantastic new book on the creative process by Rick Rubin, the legendary music producer who not only co-founded Def Jam Recordings but has also worked with artists like the Beastie Boys, Run-DMC, Slayer, Danzig, Johnny Cash, System of a Down, the Red Hot Chili Peppers, Metallica, Eminem, Jay-Z, The Strokes, and many more.

In his book, Rubin shares one of the secrets of getting unstuck when you’ve hit a wall and your work isn’t getting any better: breaking the sameness. This can happen in various ways. You could, for example, break down a large, seemingly insurmountable challenge into small tasks. Like: write just one line every day, no matter how good or bad you think it is. Soon, you’ll be able to write entire songs again.

What can also help is a change of the environment, or, how we call it in German, a “Tapetenwechsel” (= a “change of the wallpaper”), to inspire a fresh perspective. When the Red Hot Chili Peppers told him that they had enough of recording studios, Rubin took them to a (haunted…?) mansion to record Blood Sugar Sex Magik there. Other artists recorded in the dark, early in the morning, on a mountain playing for the ocean, or even hanging upside down while singing. By creating conditions outside of the normal we increase the surface area for new feelings to arise and new ideas to happen.

Such a Tapetenwechsel might also be a change of context. When a singer doesn’t connect to a song, it can be helpful to add a new meaning or backstory to the lyrics of a song. A love song, for example, might sound different if sung for a long-lost soulmate, a partner of thirty years that you don’t get along with, a person you saw on the street but never spoke to, or your mother. With one artist, Rubin suggested singing a love song written to a woman as a devotional to God instead. (As Rubin revealed in an interview, this artist was Johnny Cash and the song was “First Time I Ever Saw Your Face”.)

Another Tapetenwechsel you could try is to change or break the rules of the game. When you intentionally redefine the limitations and constraints of your project, you can break up patterns that hold you back. When you set parameters that force you out of your comfort zone, it is easier to innovate and find a new side of yourself and your work. If you always write on a laptop, try writing by hand. If you’re right-handed, paint with your left hand. If you always write long paragraphs, force yourself to only write short sentences. If you always use small font sizes, go big with your typography. Whatever you choose, it’s of little importance if your work is better. As Rubin writes:

I have a tip for everyone who’s now – or very soon – trying to find out whether a text was written by a human or an AI.

Sure, you could train another AI to look for clues and confidently call it a “classifier”. But chances are, your classifier won’t be fully reliable. It might not work on short texts. Or, it might incorrectly but confidently label AI-written text as human-written. Also, people will sure as hell edit AI-written text so that it can’t be detected anymore.

Given that you have no idea how those algorithms really work, you might as well just use the classifier written by the same company that is currently gifting you the gift of AI for free. Sounds really reassuring, right?

Instead, how about you try this:

Look for the soul.

Today, I turned 41. It was a wonderful, relaxed day with my family – and my parents’ dog who is a bit of a maniac… 😅

I also got to try out my two “office” birthday presents: a new microphone for voice, the Røde Procaster, and an audio interface, the MOTU M2.

The Røde Procaster is a dynamic microphone that was primarily designed for spoken word. Unfortunately, my office in the attic is much noisier than I had hoped, because there is a street with a bit of traffic outside. So while my default workshop XLR microphone, boomed out of frame, is great when you are running a more lively session and you don’t want a boom arm in your face, it still picks up a lot of ambient noise like traffic or playing kids. That’s why I needed a dynamic microphone, which, by nature of it’s design and the resulting “cardioid polar pattern”, will pick up much less ambient noise and allows me to first and foremost record what’s being said right in front of the microphone.

Choosing a microphone turned out to be much harder than expected. I wanted something that would be sufficient for occasional podcast visits (for now) or to record the voiceover track for tutorial videos I sometimes do for clients. After countless hours of watching reviews on YouTube, two microphones made it to the finals: the legendary Shure SM7B and the Røde Procaster. The Shure definitely seems to be the better and more popular microphone overall, but it comes with a hefty price tag of about 380–400 Euro (or Dollars). I know that this is not what audio engineers would call an expensive microphone, but it is a lot if you don’t want to use the mic that often. The Røde Procaster, which comes in at around 180 Euro, is a much more budget-friendly option that received a lot of favorable reviews. It is susceptible to handling noise and p-p-p-plosive sounds, but when it comes to the audio quality, it outperforms both microphones that are a little bit cheaper (Røde Podmic) and a bit pricier (Shure MV7X). It also does a really good job at rejecting noise. So I ultimately decided to give it a try and see for myself. With the nice side effect that I got a microphone and an audio interface for the price of an SM7B.

The MOTU M2 is an audio interface that lets you connect two inputs, like XLR microphones, for example. It comes with really good preamps with very low self noise and up to 60 db of gain to boost the signal of your microphone. Dynamic microphones like the Shure SM7B or the Røde Procaster are quiet microphones that need a lot of additional boost. The M2 can drive both of them without an additional signal booster like a Cloudlifter or a Fethead. And what’s just fabulous is that the M2 has a little color LCD display with level meters for inputs and outputs, so you can immediately see when your signal is too low or clipping. And they’re fun to watch, too, of course.

I’m really looking forward to using these two devices in my setup this year. What are you using to record audio and what is your favorite microphone? Looking forward to your answer – in a blog post maybe?

Alright. Enough talk. Let’s get to it.

One of my plans for 2023 is to redesign this website. Here is the thing: it is easy to promise things to yourself. It is much harder to deliver, especially when the project is quite large and you have to do it in your spare time, like the redesign of a personal site. So the best way to finally begin is to start today. And that’s what I’m doing.

There are a few considerations to make when you redesign a site that has been around for a while and on which quite a bit of content has been published over the years. So I will try to share in the best possible way my thought process and the steps I will take (and not take) to redesign the site, and I hope it might help some of you who are or will be in a similar situation. (That might well include my future self.) Of course, everything I document will only be applicable to other sites to a certain extent. So take it with a grain of salt and draw your own conclusions.

Doing an Inventory

My current website is now about seven years old. I am generally still mostly happy with it regarding the convenience of posting and, astonishingly, the design. But there are also a lot of things that need to be updated to more modern browser technologies or which simply don’t work anymore. For example, the site runs on Craft CMS and when I built it in 2015 and 2016, there was no Webmention plugin available for Craft. So I had to write one from scratch because I really wanted to add them to the site. The code of this Webmention plugin has been neglected quite a bit: I wrote the plugin for version 2 of Craft. The current version is 4. Consequently, updating the plugin for the latest version of the CMS will probably be one of the major parts of the redesign, because how you build plugins for Craft has changed significantly.

What else do I have to do?

Upgrading from Craft 2 to 4

First of all, I want to update the site itself to Craft 4. Craft is a somewhat classical PHP CMS with a database. This has many advantages when it comes to handling data on the server, but upgrading a static site that uses markdown files for the posts would probably save me some of the database hassle. I will first have to upgrade the site and the database from version 2 to 3 and then from 3 to 4. We’ll see how well this goes.

A New Build Process

My current site still uses Grunt (…remember?) to build the CSS and a little bit of JavaScript. I have since not used Grunt a lot anymore and feel much more comfortable working with Gulp or Vite with PostCSS. So I want to set up a new build process from scratch, keeping it as lightweight and simple as possible. At least, it should serve me for another 5 to 10 (?!?) years. For this, I might re-use some of the code of my Eleventy starter kit, qu'est appelée Eleventy Plus Vite.

Consolidating the Structure

The structure of the site will probably stay more or less the same. Over time, I pushed the works section more and more into the back. Just because I did not have the time to add more projects or an NDA didn’t allow for it. I might merge the articles and notes sections, though. When I started the site, I had the idea of writing mostly longer blog posts and to publish them only a few times a year. This has changed a lot, also with me becoming more fluent in writing in English and because I realized that I don’t publish “articles” anymore – I write blog posts. Maybe the new section will therefore just be called “blog” or “writing”. Again, we’ll see.

Improving the HTML

Keeping the structure intact also means that I won’t do a lot of changes to the HTML of the templates. At least, that’s the plan for now. I will remove some of the older stuff like JavaScript lazy loading of images and do this with the loading HTML attribute instead. And I also want to make more use of includes and partials, thinking more in components, and improve the overall quality of the HTML.

Better Accessibility and Performance

Over the last few years, I’ve been learning a lot about creating accessible interfaces for the Web and there is quite a bit that can be improved on my site. The same goes for performance. Although I tried my best to reach a four hundos Lighthouse score when I built the site, many best practices have since improved and I want to make the site load faster (again). This will involve a lot of tinkering – I’m looking at you, Service Worker – but it also promises to be a lot of fun.

New CSS 😍

I can’t wait to start with this part. My plan is to throw almost all the CSS into the bin and start fresh, using all the great new (layout) features that CSS offers these days. I will heavily make use of CSS Grid and Flexbox, of course. But also experimenting with more experimental features like :has() and container queries might be fun. But definitely, I will make the typography completely fluid this time, using an approach like Utopia. I also will use variable fonts – and I already have a few typefaces on the shortlist. More on that in a separate post about the typography of the site once it is done. Ah! The new design should also have a dark mode, using custom properties for the theming.

An Open Redesign – Yes or No?

As you can see, there is already a lot on the list. And I probably also forgot a few things that will pop up in the process. So expect a lot of blog posts about many of the aspects of the redesign.

However, I’m still not sure whether I should do an open redesign or if it makes more sense to document most of the redesign separately and share those posts once the new design goes live. What do you think?

We all know that it is going to happen. It’s not a question of if, but when Twitter will collapse. By the way: one day, Medium will follow. So will Instagram, YouTube, and TikTok. Or Mastodon.

Many people are now desperately waiting for their Twitter archives, hoping that they’ll arrive before all their content is lost for good. For those who were using Twitter primarily for ephemeral chatter, all this isn’t that tragic. But for others, all their posts, conversations, and connections on the social network were a significant part of their online identity. They are about to lose a place on the Web into which they put a huge amount of time, attention, and energy.

Especially if you are a designer, an artist, a photographer, a writer, a blogger, a creator of any kind, owning your work is as important as ever. Social media platforms might be great for distributing your content and creating a network of like-minded people around you. But they will always be ephemeral, transient, and impermanent – not the best place to preserve your thoughts, words, and brushstrokes.

In the search for a permanent home on the web, more and more people are now rediscovering the personal website as a place to share and document their thoughts and publish their work. I’ve written at length before about why this is such a good idea: Your personal website is a place that provides immense creative freedom and control. It’s a place to write, create, and share whatever you like, without the need to ask for anyone’s permission. It is also the perfect place to explore and try new things, like different types of posts, different styles, and new web technologies. It is your playground, your platform, your personal corner on the Web.

That’s why it warms my heart to read articles like Bring back personal blogging by Monique Judge on a site like The Verge or to add my site to projects like Bring Back Blogging by Ash Huang and Ryan Putnam, who encourage us all to get into the habit and publish at least three blog posts until the end of January. Oh, and if that’s important to you, as Chris Coyier notes, There Can Be Money in Blogging, too.

So how about we make 2023 the year of the personal website? The year in which we launch our first site or redesign our old one, publish a little more often, and add RSS and Webmentions to our websites so that we can write posts back and forth. The year we make our sites more fussy, more quirky, and more personal. The year we document what we improved, share what we learned, and help each other getting started. The year we finally create a community of critical mass around all our personal websites. The year we take back our Web.

I’ll start tonight.

For the last day of this year’s Independent Type Foundry Advent Calendar, we’re back in Berlin. NaN is a foundry and type design practice “balancing weirdness and wisdom” that was founded by designer Luke Prowse. In late 2021, Luke was joined by Jean-Baptiste Morizot, who had already launched Phantom Foundry in 2018.

NaN’s growing library of retail typefaces could be described as beautifully weird and playful, full of expressive creative talent combined with font engineering at the highest level.

NaN Tragedy is a functional but unconventional serif designed by Jean-Baptiste Morizot. Based on a classic skeleton, quirky details and an exaggerated calligraphic contrast are less pronounced in the text styles but more extreme and expressive in the display cuts.

NaN Holo by Luke Prowse is a constructed neo-grotesk with “biological forms disrupting an otherwise tensely machined flow.” The mix of rounded and squared details makes it a solid and reliable but also surprising and warm design.

NaN Jaune by Jérémy Landes is a sans-serif full of contrast and contradictions – from closed apertures to deep ink-traps to extreme stroke contrast, in three different optical sizes – Maxi, Midi, and Mini.

And then, there’s NaN Tresor, Christoph Koeberlin’s latest masterpiece. Peculiar, charming, full of energy, and immediately recognizable. A revival not of a single typeface, but of an entire genre. NaN Tresor is an homage to the very first grotesk typefaces with all their charming inconsistencies. To reproduce the feeling of this era, Christoph took an unconventional approach: he carefully translated the historical inconsistencies and quirky design details into a typeface with three optical sizes and almost 2000 characters and glyph variations, sometimes eight alternates per glyph plus swashes. In the variable font, this idea fully unfolds: the individual irregularities and distinctive characteristics of the design can flexibly inform each other into a wide range of playful variations.

You can get trial fonts of all NaN typefaces – and also make sure to try the lovely color picker in the upper right corner if you’re visiting the website on a larger screen… 😍

☞ https://www.nan.xyz

PS: Happy Holidays! ✨🎄🤗

❦

This post is part of the Independent Type Foundry Advent Calendar 2022

Typotheque is a type design studio based in The Hague, Netherlands. Founded in 1999 by Peter Biľak, who also teaches typeface design at the renowned postgraduate course TypeMedia at the Royal Academy of Art in The Hague, the foundry is well-known for the excellent design quality of its typefaces and a focus on extended language support. Many of the typefaces in the vast catalogue are superfamilies that come with sans, serif, display, or mono styles and support for hundreds of languages.

Greta is a superfamily designed by Peter Biľak that was been planned from the outset as a system of interrelated styles. Following the architectural approach Adrian Frutiger pioneered with his Univers, Greta was not only designed as a family of weights and styles but also as a system of continuous optical sizes.

Brenner is a superfamily designed by Nikola Djurek that also combines various styles, like a rational, unobtrusive neo-grotesk sans-serif and a confident, high-contrast serif, into a coherent type system.

Ping is a resolutely modern, fluid sans-serif typeface designed by Peter Biľak and various others with a special design approach: its simplified letterforms are constructed with the least number of pen strokes. So lowercase letters ‘a’, ‘d’, ‘p’, ‘b’ and ‘g’ are drawn without lifting the pen at all.

Rapida by Michelangelo Nigra’s, which started as a thesis project on the TypeMedia master's course, is a charming serif designed for long form reading. It’s counterpart, Rapidissima, takes the design ideas behind Rapids to the extremes with dramatic sloping (24 degrees), very high contrast between strokes, and sharp and extressive lettershapes.

You can try all Typotheque fonts with Fontstand and they also offer an 80 % educational discount for students, teachers, faculty, schools, and educational institutions.

☞ https://www.typotheque.com

❦

This post is part of the Independent Type Foundry Advent Calendar 2022

205TF is a type foundry based in Lyon, France. It was founded in 2017 by Damien Gautier and Florence Roller who run the foundry together with foundry manager Rémi Forte. Collaborating with many independent type designers, they have built a library of typefaces that is wonderfully diverse, full of energy, and that has its very own character. As they write on their website, in all their designs “a certain French spirit can be felt.” And so, the TF in the foundry’s name stands not only for Type Foundry but also Typographie Française.

You could probably spend hours browsing the catalog that consists in the majority of expressive and quirky display and editorial typefaces. So it’s again hard to pick any favorites – it will depend on your project which typeface suits your needs. Here are a few for which you will also find great design examples on Fonts In Use.

Plaak designed by Damien Gautier and inspired by French street signs, is a sturdy, expressive sans-serif with a wide range of styles. Maax, also by Damien, takes an interesting approach: each style of the sans-serif consists of four variations with slightly adjusted letterforms – Standard, Geometric, Modern, and Grotesk. Clifton by Yoann Minet is a poetic serif with inverted contrast. And Louize by Matthieu Cortat is a warm and elegant old-style serif, a revival of “Augustaux” by Lyonnais printer Louis Perrin, in itself one of the first revivals in the history of typography.

I could go on and on like that. :) Maybe just have a look at the many wonderful designs yourself and download free test versions I of your favorites to try them.

☞ https://www.205.tf

❦

This post is part of the Independent Type Foundry Advent Calendar 2022

For day 21, we’re back in Berlin, where a young graphic designer with a love for type decided in 2008 to make his passion his full-time job. Today, Hannes von Döhren’s type foundry called HvD Fonts sells a wide range of typefaces, some of them being hugely popular designs. The catalog does not only include high-quality sans-serif and serif typefaces but also a surprisingly large variety of expressive display fonts.

Brandon Grotesque was the typeface that put Hannes on the map for many of us. Awarded with a Certificate of Typographic Excellence by the Type Directors Club in 2011, this geometric sans captures the atmosphere of the 1920s and classics like Futura but combines it with the warmth of slightly rounded corners and a charming, contemporary openness.

FF Mark, released in 2013 and created by Hannes von Döhren, Christoph Koeberlin, and the FontFont Type Department with creative input of Erik Spiekermann, is one of the most iconic contemporary geometric sans-serif designs out there – clean, balanced, and readable.

Fabrikat, designed by Christoph Koeberlin, Hannes von Döhren, and Inga Plönnigs, is a geometric sans reminiscent of DIN. Engineered, straightforward, reduced, functional, and also available in a narrower version and a monospaced design.

Palast, designed by Hannes von Döhren and Bernd Volmer, is a transitional, slightly geometric serif typeface that comes in three optical sizes: Poster, Display, and Text.

And the latest addition to the library is Hannes’s Match, a compact and confident grotesk.

☞ https://www.hvdfonts.com

❦

This post is part of the Independent Type Foundry Advent Calendar 2022

Tobias Frere-Jones is one of the most accomplished type designers in the world. He worked at Font Bureau in Boston where he designed modern classics like Benton Sans or Interstate. He later returned to his hometown New York City and, at Hoefler & Frere-Jones, created timeless designs like Whitney and Gotham. Then, in 2015, Tobias founded his own company, Frere-Jones type. A year later, he was joined by Nina Stössinger, who, just like Tobias, teaches type design at Yale School of Art.

The library of Frere-Jones Type is small but exquisite, with all typefaces being designed with intention, care, and a lot of attention to detail. A few highlights:

Mallory was the first release of the foundry and Tobias’s take on combining his own mixed heritage, being part British part American, into a geometric but relaxed type family.

Exchange is a sturdy, compact, and clear serif that started as a commission for The Wall Street Journal and was revised and extended for the retail release.

Magnet is an energetic and surprising sans-serif family, designed by Inga Plönnigs. Tightly packed headline cuts – including backslanted versions – are combined with standard styles that are quieter but still intriguing with their deeply cut notches and unusual details.

Community Gothic, designed by Tobias Frere-Jones, Fred Shallcrass, and Nina Stössinger, is a patchwork family, inspired by the sans serif “jobbing” typefaces of the nineteenth century. Each style draws from different historical examples, leading to different shapes and different construction styles of the individual weights that were then finely tuned into a system that has a common, reliable base but allows each glyph to deviate from the norm to a certain extent.

Also make sure to read some of the blog posts that meticulously document the design of each release. Each is a little type design lesson on its own.

☞ https://frerejones.com

❦

This post is part of the Independent Type Foundry Advent Calendar 2022

Fontwerk was founded in 2019 by Ivo Gabrowitsch in Berlin. Building on his excellent network and years of experience as marketing director at FontShop and Monotype, Ivo has assembled a permanent team of great designers and font engineers that also regularly collaborates with a freelance network of international design professionals.

One look at the library and you can already see the signature style of the “typographic epicentre” that is Berlin: typefaces of extremely high quality and a lot of attention to detail. Useful, thorough, aesthetically pleasing – and always recognizable in their design.

Case is a neo-grotesk superfamily in the tradition of Akzidenz Grotesk or Univers designed by Erik Spiekermann, Anja Meiners, and Ralph du Carrois. They put in all their experience to design a typeface that captures the essence of the best parts of this genre but also adds in new ideas. The result is a design that achieves something that is incredibly hard: it has a familiar, solid, and clear base but at the same time it has its very own individual, contemporary character.

The versatile Nice Superfamily by Jan Fromm is a clear but lively serif that comes in four optical sizes. The smaller optical sizes are optimized for legibility while the larger sizes emphasize expressiveness with high stroke contrasts and sharp serifs.

And Christoph Koeberlin’s Pangea Superfamily is a compact but friendly geometric sans that brilliantly weaves in elements of grotesk typefaces like a double-story a or a “spectacle-g”. It comes in a wide range of styles and optical sizes and, as you would expect from one of the best font engineers out there, is available as a variable font as well. You can try out the different axes and read more about the design on Christoph’s website. Also remarkable: Christoph is donating 25% of his income from Pangea to the preservation of the rainforest and to large-scale reforestation projects.

Oh, and also make sure to have a look at Nikolai, designed by Franziska Weitgruber. A striking contemporary reinterpretation of Renaissance serifs that evolved on Future Fonts into a beautiful design full of character.

Fontwerk provides trial fonts for all typefaces and students can purchase all font families for the price of a regular weight. Fantastic!

☞ https://fontwerk.com

❦

This post is part of the Independent Type Foundry Advent Calendar 2022

Vectro is a type design studio based in Portland founded in 2021 by Lizy Gershenzon and Travis Kochel. The two have been running the design studio Scribble Tone for several years but their most-noticed project (and company) is probably Future Fonts, a platform for experimental, high-quality fonts in progress. On Future Fonts, type designers can sell early, unfinished versions of their typefaces at a fraction of the final price to support further development and get early feedback. But most importantly, Lizy and Travis have created a community with Future Fonts that empowers type designers to grow and learn. Foundries like Ohno or Blast owe much of their success to the visibility they have on Future Fonts, and in the community Slack channel, seasoned designers like Kris Sowersby are providing feedback and useful advice.

Vectro is Lizy‘s and Travis‘s latest endeavor and the new home for all their own typefaces going forward. But they’re also collaborating with other type designers to build up a library that is useful, playful, and expressive, but that also leverages latest font technologies like variable fonts.

Rainer is a tightly compressed sans with a large x-height by Philipp Neumeyer (whom you might remember from his designs published with TypeMates). The typeface started out on Future Fonts as well and now found its way into Vectro‘s catalog. Vctr Mono is a warm and slightly goofy monospaced typeface by Travis and Lizy that was inspired by text found on the lenses and bodies of manual cameras. Analog is a confident, wide industrial sans-serif with low contrast. And WHOA is an experimental variable font, “named after the sound commonly heard after dragging the slider for the first time.” Try it. It’s true. :)

Trial fonts are available and students get a 50 % discount on all fonts.

☞ https://www.vectrotype.com/

❦

This post is part of the Independent Type Foundry Advent Calendar 2022

You probably have seen several of his typefaces on MyFonts before. Maybe you even purchased one or more of them. For almost 10 years, he was selling his fonts on Monotype platforms. This year, Berlin-born and -based designer René Bieder launched his own independent shop for his typefaces. And it is full of treasures.

When the idea to sell the typefaces of his studio independently grew in René about two years ago, he immediately knew that he would have to raise the bar for such a huge project and he started to revise some of his most popular designs. At first, he planned to do only a few minor adjustments. But as time progressed, he realized that if you change just a few small details in the system that is a typeface, you might as well rework the whole family and include even more adjustments. All of a sudden, he found himself jumping back and forth between revisions of six of his existing typefaces while also working on new designs – with the positive side effect that he could always look at the work with fresh eyes. The result? A whopping total of 14 revised or new type families, designed within two years. Since October 2022, René has been publishing one of the eight completely new families every month. So there’s even more to come.

With that many designs of outstanding quality, it is incredibly hard to pick a few favorites. I will give it a try, but promise me to look at the typefaces in the library yourself.

Neue Campton is the redesign of one of René’s most successful typefaces. The challenge in reworking the geometric sans-serif was to keep the balance between creating an expressive, new aesthetic while also keeping the original spirit of Campton alive.

With Neue Faktum, a grotesk that combines organic and mechanical shapes into a cohesive design, the process of revising the family proved to be easier, because the design details of the typeface were distinctive enough already. So, René primarily redrew all the curves.

Kreol was the first one of the new designs to be released. The serif typeface comes with gorgeous high-contrast strokes and a sturdy, sometimes crisp, but always elegant appearance.

Spyk takes some of the details that can be found in Kreol even further and turns up the volume into an extroverted, lively, and razor-sharp design. This might well be a TDC winner in 2023. ;)

Trial fonts are available for all typefaces. And if you hurry up and buy one of the new type families, you will get a limited edition poster for free.

☞ https://www.renebieder.com

❦

This post is part of the Independent Type Foundry Advent Calendar 2022

R-Typography is a type foundry based in Lisbon Portugal, founded by Rui Abreu in 2008 and now run together with Catarina Vaz.

Rui drew his first type designs while still working as a designer in advertising agencies. One day, he decided to send a design to to Peter Bruhn of the Swedish foundry Fountain. Peter not only recognized that this young designer from Portugal could draw letters, but he would also become his mentor as they collaborated for a few projects, including the TDC award-winning Orbe. From Peter, Rui not only learned how much hard work and dedication it takes to produce a typeface, but he also realized that a foundry is more than the sum of its collective typefaces. As he says, “What makes a foundry is the whole body of knowledge.”

And so, when you look at the growing catalogue of R-Typography, it seems that what is driving Rui today is not only the desire to cover a wide range of styles and curate a collection of useful and beautiful typefaces. Just as important is that the foundry’s ‘body of knowledge’ is growing artistically but also regarding methods, production techniques, and tooling.

The library of R-Typography now contains a range of great sans-serifs, like the geometric but pleasantly warm Azo Sans in all its variations, the constructed Sul Sans, sort of a Portuguese version of DIN, and Rui’s recent reinterpretation of Futura: Atica. Staff is a sturdy, contemporary neo-grotesk sans family for wide range of applications and a more recent, text-oriented version in Staff Grotesk.

The serif families are where you can see that Rui really knows how to balance contrast and shape. Like in Grifo and Gliko Modern, two serif designs for editorial use with high stroke contrast, or Flecha, a sharp, sturdy, yet delicate and “Fleischmann-y” old-style typeface. The latest release of the foundry is Rizoma, a contemporary typographic interpretation of Roman inscription letters, elegant and slightly constructivist.

As it is the standard nowadays, you can get free test fonts with a limited character set. And I also encourage you to read a few of the interesting post in the stories section, where Rui writes about the design ideas behind the typefaces.

☞ https://www.r-typography.com

❦

This post is part of the Independent Type Foundry Advent Calendar 2022

David Jonathan Ross (DJR) had been working with The Font Bureau for nearly a decade, when he decided to start his own type foundry in 2016, now located in the hills of Western Massachusetts.

David’s typefaces literally come in all shapes and sizes, and in all of them, his love for exploration, experimentation, and play is evident. It almost seems as if David just can’t get enough of trying out new genres, drawing new shapes, finding new ideas for typefaces that nobody has done before, while pushing the boundaries of what font technology and type engineering can do. As a result, David has been awarded with several TDC awards and, in 2018, received the Prix Charles Peignot by the Association Typographique Internationale.

Many of David’s experiments and up as fonts in his Font of the Month Club. For a tiny subscription fee, members of the club will get one of David’s latest fonts every month. And the variety of designs on this “playground” is just stunning. So just scroll through the history of fonts – and also take a look at the type designs on David’s website that I don’t mention here.

While many of David’s designs remain experiments or single fonts (for now), some of them even grow into whole type families. Like the much applauded Roslindale, a serif family that comes with sturdy and stylish text styles but gets expressive and ornate in display sizes.

Or Forma DJR, a revival of the classic Italian sans-serif from 1968, that was the Italian type foundry Nebiolo’s answer to Helvetica. Based on proofs Indra Kupferschmid printed from a casting of the original Forma in lead, David and Roger Black designed a contemporary digital version of Forma that captures the charm of all the interesting, unintentional byproducts of the printing process in the typeface’s design details.

Also worth mentioning, especially for the coders out there, is Input, a monospaced (and proportional) type system David specifically designed for coding environments. The typeface comes in a wide range of widths and styles, so that you can pick the right type face for your editor according to your personal preference. I have been using Input as my typeface in Sublime Text and later Visual Studio Code for years now and don’t want to miss it.

For all typefaces, you can get trial fonts, sometimes even including the variable font versions, for evaluation and internal testing purposes.

And if you love conference talks, also make sure to watch the talks David gave at beyond tellerrand in 2016 and 2018 for a deep-dive into type design and (extreme) typography.

☞ https://djr.com

❦

This post is part of the Independent Type Foundry Advent Calendar 2022

Bonjour Paris! The type design community in Paris is buzzing and today, we’re looking at one of the younger foundries that has already received a lot of praise. Interval Type is the foundry of art director and type designer Ilya Naumoff. Before he founded Interval Type, Ilya was part of Black[Foundry] and worked with foundries in France and Switzerland.

The library of Interval Type is small but already full of gems. Englisch is a playful display typeface that draws inspiration from 17th and 18th century English type designs to create a slightly eccentric and charming contemporary design that has been awarded with a TDC award for type design this year.

Factor A and Factor B are the geometric sans-serifs in the collection. Factor A is the warmer of the two, Factor B is more rational in its shapes. But both have a contemporary appeal, not only because of little quirky details but also because of a wide set of squiggly alternates.

Rooftop is a sturdy grotesk inspired by the american grotesks of the early 20th century but with slightly squarish curves, a design detail that I fondly remember from designs like T-Star and my only clumsy attempt at type design as a student in the early 2000s. Stravinsky is a a slightly chaotic, experimental grotesk display typeface.

And then there is Oceanic. Full of bold, organic shapes and exuberant, contrasting friskiness. Odd, quirky, elegant – and TDC-awarded in 2022 as well. Oceanic Text, the more sober serif counterpart for running text completes the family, creating the perfect mix for a wide range of applications.

For all fonts, you can get free trial fonts with a limited character set.

☞ https://intervaltype.com

❦

This post is part of the Independent Type Foundry Advent Calendar 2022

Newglyph is a type design studio based in Lausanne, Switzerland, founded by Ian Party and his team in 2019. If that name rings a bell, it’s because just yesterday, we looked at another foundry Ian co-founded: Swiss Typefaces. Newglyph is his latest endeavor and is focused on “the research, design, and development of fonts and variable font technology”. Also, 10% of the foundry’s proceeds go to non-profit organizations “committed to protecting our planet and all life on earth”.

The library of Newglyph currently consists of two major font collections that were all designed by Ian himself. In a way, the collections are taking the design approach Ian used for his designs at Swiss Typefaces one step further by making all of the designs variable fonts. Ian’s goal was to make “all these styles interpolate and blend together to make it a fluid aesthetic variable font with enormous possibilities in styles that had never been done before.” If you give the website access to your motion sensor (gyroscope) on a mobile device, you’ll be able to manipulate the weight and width of the files by moving your device, by the way. On devices with a pointing device, the cursor movement will change the weight and width of the type.

The Classic collection consists of 7 variable fonts – Antarctica, Baikal, Crystal, Sunlight, Alpaga, Amazonia, Alaska, and Atacama – that range from grotesk and geometric sans-serifs over monospaced fonts to several serif designs. All designs share the same attention to detail and a certain Swiss precision but also have their very own contemporary character.

The Discovery collection, on the other hand, is all about expressiveness. It’s all in there: geometric shapes, organic shapes, extreme contrasts, abruptly cut-off terminals, and confident strokes in all directions. And again, almost all typefaces in the collection are variable fonts.

The license for all fonts includes desktop, web, apps, electronic publications, video, and much more – basically everything you’ll ever need as well as free updates. You can get free trial fonts with a limited character set and students can buy a lifetime license for each typeface for 50 CHF and only 150 CHF for whole collections.

☞ https://newglyph.com/

❦

This post is part of the Independent Type Foundry Advent Calendar 2022

Many type foundries claim to be offering innovative designs and flexible type systems. But few deliver on this promise like Swiss Typefaces does. Founded in 2005 in Lausanne by Maxime Büchi and Ian Party (first as B&P type foundry), who were later joined by Emmanuel Rey, the foundry approaches a lot of things differently. Where other foundries offer type families with a certain range of weights and styles, Swiss Typefaces provides designers with typeface collections that share similar foundational design elements but offer a wide range of visual variation, allowing for true flexibility.

Centerpiece of the library is Ian Party’s Suisse typeface that consists of 6 collections with a total of 55 styles, including the grotesque Suisse Int’l and its serif counterpart Suisse Works.

SangBleu follows the same conceptional approach but manages to take it even further to a point where it breaks with conventional typeface classifications like sans/serif/slab. The five collections of SangBleu are all romans, but their design characteristics, like contrast or serifs, become sometimes more, sometimes less pronounced. The result is an innovative, organic supercollection that offers a lot of flexibility.

Euclid, designed by Emmanuel Rey, is the geometric sans-serif in the library, With its variations Circular A, Circular B, Square, Triangle, and Flex, it is worth a closer look as well.

Another thing that sets Swiss Typefaces apart is their licensing model. If you buy one of their typefaces, the license will always include desktop as well as web fonts. For students, they even offer lifetime licenses of their typeface collections for only 50 CHF. They also have a Lab section on their site, where you can get early, experimental versions of upcoming type designs. And if you want to try the typefaces, you can always get free trial versions in desktop and web formats with a limited character set.

☞ https://www.swisstypefaces.com

❦

This post is part of the Independent Type Foundry Advent Calendar 2022

Sharp Type is a digital type foundry based in New York City and was founded in 2015 by Chantra Malee and Lucas Sharp. Chantra is in charge of strategy, brand management, graphic design, sales, and communication for the foundry, while Lucas acts as type director. Before he got into type design, Lucas Sharp was a painter. That’s why his work is, above all, shaped by the love of balanced and compelling form and beauty, but his foundry’s type designs also uniquely combine those traits with the utilitarian aspect of design and state-of-the-art type engineering. Many of the typefaces in the library are exploring edges and are groundbreaking in how they bring together expressive, contrasting details with a coherent visual appearance.

Sharp Type’s library contains a broad variety of styles, ranging from expressive display typefaces like Frauen, an ode to German calligraphy, or the contemporary blackletter Respira Black, to charming serif designs like Doyle.

The most notable designs of the catalog are, however, the sans serifs. There is the warm but neutral geometric sans-serif Sharp Sans, for example, an iteration of the display typeface used by Michael Bierut’s team at Pentagram for the Hillary Clinton 2016 campaign.

Sharp Grotesk is a neo-grotesk superfamily with an incredibly wide range of styles that explores the edges of what is possible in sans-serif typography. Or, to quote from the Sharp Type website: “Swiss styling collides with the unexpected construction and wonky imperfectionism of 20th-century American wood type in Lucas Sharp’s monument to Adrian Frutiger.”

Garnett is the first typeface designed by Connor Davenport, senior typeface designer and technical director at Sharp Type. The design of the family combines the source material of the early, quirky grotesques of 19th-century Britain with hints of American Gothics into a confident, striking, and distinct contemporary typeface.

And then, there is Marc Rouault’s Trois Mille – expressive, unseen, and truly genre-redefining in its innovative design. The design of the type family that started as Marc’s TypeMedia thesis project in 2016 is based on a simple but effective idea: by always orienting the pen at 0° for horizontal strokes and 90° for verticals, hairlines only occur at the stroke intersections and some interior strokes and joins, while the rest of the strokes remain thick. This breakthrough idea led to a contrast methodology Sharp calls “internal contrast”. It’s what makes Trois Mille so exiting and charmingly weird and it is also the foundational methodology behind Beatrice, with all its dramatic visual oddity culminating in Beatrice Display.

Trial fonts with a limited character set are available as well as a few nice things.

☞ https://sharptype.co

❦

This post is part of the Independent Type Foundry Advent Calendar 2022

Colophon Foundry is a foundry based on London founded by Anthony Sheret and Edd Harrington. The two designers started working together in 2009 in a shared graphic design studio in Brighton and began designing their own typefaces for the projects of their studio The Entente.

Their most popular typeface, especially in the early years of the foundry, is Aperçu, a quirky grotesque full of references to classic realist typefaces like Johnston, Gill Sans, Neuzeit, and Franklin Gothic, but with a contemporary feel.

Other notable releases in the wide-ranging library are Basis and the recently released Chromatic superfamily that travels different genres of sans-serifs.

If you want to test the typefaces first, you can get free demo fonts with a limited character set. And you can also order goods like posters and scarfs.

☞ https://www.colophon-foundry.org/

❦

This post is part of the Independent Type Foundry Advent Calendar 2022

Commercial Type is a custom type design studio founded in 2007 by Paul Barnes and Christian Schwartz, based in New York City and London. They have worked to build a growing library of excellent quality with “a balance between highly versatile ‘vanilla’ typefaces that can do whatever a designer needs, and expressive typefaces that allow a designer to sit back and let the typeface do the hard work of making a piece of design interesting and memorable.”

Paul and Christian both have a background in publication design and had already collaborated on the type system for the newspaper The Guardian. So, when they founded Commercial Type, the Guardian Collection became the cornerstone and most successful set of typefaces of their library.

Other popular typefaces include sans-serif workhorses like the clear and optimistic Atlas and the plain but friendly Graphik, but also more expressive, characterful designs like Action Text, Druk, Original Sans, or Canela. Make sure to also have a look at Commercial Classics, their library of typefaces based on classic designs from typographic history.

Both designers have also collaborated with other foundries like Font Bureau, FontFont, or House Industries, with one notable release being Neue Haas Grotesk, a revival of Max Miedinger’s original Helvetica, which Commercial Type published in collaboration with Linotype in 2011.

Just like it is the case for all foundries features in this advent calendar, Commercial Type’s fonts are available as web fonts for self-hosting and you can get trial fonts as well.

☞ https://commercialtype.com

❦

This post is part of the Independent Type Foundry Advent Calendar 2022

Hej! Time to look at the next type foundry and this time, we travel to Scandinavia. Letters from Sweden, founded by self taught type designer Göran Söderström in 2011, is based in Stockholm and designs retail and custom typefaces for local and international clients. Instead of following an overly conceptual or even dogmatic approach, the type designs of Letters from Sweden all share a certain uncontrived, straightforward, but also crafty style.

Highlights of the library include the straightforward Lab Grotesque, the sturdy but elegant serif superfamily Ivar, strongly influenced by Times, and the geometric sans serif Rund that comes with a nice design detail: Rund’s curved strokes have subtly concave terminal shapes, as if they were cut off by a circle.

You can try out all fonts on the website by typing and even changing the font wherever there is a type sample on the site. Test fonts with a limited character set are available on request.

☞ https://lettersfromsweden.se

❦

This post is part of the Independent Type Foundry Advent Calendar 2022

Founded in 1993 by Cornel Windlin and Stephan Müller, Lineto is Switzerland’s first digital type foundry. Over the last three decades, Lineto has collaborated with type designers from all around the world and shaped one of the most impressive and high-quality libraries available. The catalogue covers many different genres but is definitely best-known for typefaces that are deeply rooted in the history of Swiss type design. When people think of the contemporary Swiss Style, they first think of Lineto.

Laurenz Brunner’s critically acclaimed and immensely popular LL Akkurat, first published in 2004, is maybe the most famous of the bunch. It is precise, robust, and constructed, so everything you would expect from a classic, neo-modernist sans-serif. But in all its rationality, it also maintains subtle warmth and contemporary appeal.

LL Circular is a geometric sans-serif and Laurenz Brunner’s second official release after LL Akkurat. It’s a fresh take on the genre that has its roots in the Germany of the 1920s with typefaces like Futura or Kabel. LL Circular evolved from a purely geometric approach into a design with a lot of character that again combines purity with warmth.

And LL Unica77 is the only official digital revival of the legendary Haas Unica. Haas Unica’s original designers, like 83-year-old Christian Mengelt, joined Lineto to re-master the typeface from their own drawings, and they continue to participate in the type family’s ongoing expansion.

There are even more fantastic works to explore in the collection, like LL Replica by Zurich-based studio NORM, LL Lettera Text by Kobi Benezri which is inspired by a typewriter font designed by Josef Müller-Brockmann for Olivetti in 1968, or Arve Båtevik’s new take on Paul Renner’s Futura: LL Supreme. So make sure to delve a bit among the various typefaces. For all of them, you can get demo fonts after creating an account.

☞ https://lineto.com

❦

This post is part of the Independent Type Foundry Advent Calendar 2022

Sometimes, it can take quite a while for a foundry to finally become sustainable. Sometimes, like in the case of James Edmondson, it can take 17 type families.

James Edmondson started Ohno in 2015, “born from a love of expressive typography and craft.” And, as he shares in a wonderful account of his life story, it took about 6 years until Degular came “like a bolt of lightning” to the library, immediately making the foundry sustainable. It certainly is one of the designs with more focus on practicality than expressiveness, but still you feel a bit of the playful and quirky design details that make other typefaces of the foundry so unique and give it its very own expressive visual style. Like Covik Sans, which started as James’ graduation project in TypeMedia in a effort to create something interesting and original. Or the even more expressive and charmingly bold display fonts like Beastly, Irregardless, or Blazeface. My personal highlight, Obviously, is a playful sans-serif that combines the charm of hand painted signage with impact of Impact. Unmistakable, confident, dense, wide, and with a delicious semislant in the variable font. If you want to learn more about each typeface, by the way, read the texts in the type specimens. ;) And if you want to test them, you can get free demo fonts with a limited character set.

Oh no! I almost forgot to mention that you can also get merch from Ohno and listen to fabulous conversations with people like Christian Schwarz, Lizy Gershenzon, and Travis Kochel on the Ohno Radio podcast.

And if you’re inspired now and want to learn more about type design, have a look at the Ohno Type School.

☞ https://ohnotype.co

❦

This post is part of the Independent Type Foundry Advent Calendar 2022

Milieu Grotesque was founded in 2010 by graphic and type designers Timo Gaessner and Alexander Colby in Zurich. Today, the foundry is based in Lisbon, Portugal. Milieu Grotesque’s typefaces are versatile and system-oriented but also have a distinctive and often slightly quirky character which has made them a popular choice for contemporary graphic designers.

Milieu Grotesque’s small but refined library is steadily being expanded and regularly updated. Their most recognized typeface is Maison Neue, a reworking of Maison with slightly less quirky details, that was published as a superfamily in 2012 and revised in 2017. Maison Neue is a grotesk that references the reduced formality of the constructed sans-serifs of the early 20th century, bringing the oddities of those typefaces it into the present day in a well-balanced and less dogmatic way.

But also the other typefaces in the catalogue are worth a cover look, not only because they are all made with a lot of care and attention to detail and very well executed and mastered. All of their designs combine the functional with the unexpected. There is Lacrima, a comprehensive family based on the famous IBM Golfball typewriter. Patron is based on the contradictory ideas of type designers Günther Gerhard Lange and Roger Excoffon, merging expressiveness and consequent precision into a modern, versatile grotesk. And Brezel Grotesk is a modern but friendly grotesk with an “inward curling stroke ends that subtly commemorate the ubiquitous silhouette of a Bavarian pretzel.”

☞ https://www.milieugrotesque.com/

❦

This post is part of the Independent Type Foundry Advent Calendar 2022

TypeMates is a comparatively young foundry from Germany, founded in 2015 by Lisa Fischbach, Jakob Runge, and Nils Thomsen. Despite its young age, the foundry has already worked with large clients on custom typefaces and has managed to grow its catalogue of typefaces into an impressive collection of extremely high-quality, distinctive designs, collaborating with type designers from all around Europe.

Highlights of the collection are the indestructible Pensum Pro, the poetic (and TDC awarded) Resonay, the sturdy yet warm slab serif Harrison Serif Pro (also TDC awarded), the pragmatic constructed grotesk Halvar, and the unaffected and confident Norbert Superfamily by Philipp Neumeyer, which also just received a Certificate of Typographic Excellence by the Type Directors Club. TypeMates offer free demo fonts with a limited character set for all their typefaces.

☞ https://www.typemates.com/

❦

This post is part of the Independent Type Foundry Advent Calendar 2022

For day three, we travel to New Zealand, where Klim Type Foundry was founded in 2005 by type designer Kris Sowersby. After having worked a while as a graphic designer, Kris was contacted by Chester Jenkins from Vllg who wanted to release Kris’ first typeface Feijoa. It was published in 2007 and the first royalty cheques from the sales of Feijoa allowed him to focus on type design full time.

Klim (“milk” spelled backwards) has since published a broad range of high-quality typefaces of which many can be considered modern classics already. National first gained Klim international recognition, also because of a TDC award in 2008. Since then, Klim has touched on many genres of type design, always drawing inspiration and paying tribute to classics of type history but creating contemporary designs at an extraordinary level of detail and quality. Calibre is a neo-grotesk sans serif inspired by lettering on West Berlin street signs. Epicene is a poetic hommage to the crackling Baroque letterforms of designers like Rosart and Fleischmann. And then there is Söhne, the ultimate descendant of Akzidenz Grotesk – confident, sturdy, and authentic.

When you visit Klim’s website, definitely take some time to read a few of the design information posts that Kris is writing for each release, like this one for Söhne. They are just outstanding. Each is a little, respectful journey into the history of type design but also documents the extraordinary attention to detail and craftsmanship that is evident in all typefaces of the Klim Type Foundry.

Oh, and they also have a store, Klim Goods with a lot of beautiful products and sold-out posters. ;)

☞ https://klim.co.nz/

Dinamo is another type foundry from Switzerland, founded by Fabian Harb and Johannes Breyer in Basel. After moving to Berlin for a few years, they now operate from different cities and via a network of satellite members across the globe. They don’t see themselves as a foundry only but take on various projects from graphic design to app design and beyond. Dinamo also runs a small shop, Dinamo Hardware, where they transform type-thinking into tangible objects.

One of their most important and popular type designs is Favorit, which has been used by the independent label Warp records (home to Aphex Twin and Brian Eno, for example) as their official typeface. The sans-serif feels somewhat familiar but still different and interesting. Fabian Harb describes its DNA like this: slightly “mechanical” in character, “low contrast” in terms of the way in which it is drawn, a real “workhorse” in that it has the ability to handle any content, and, very importantly, having a “humorous touch” — the odd, toothless uncle you meet at a birthday party who always tells the best jokes.

Their catalogue of fonts includes various designs from sans (Repro, Monument Grotesk) to serif (Laica) to mono (Diatype Rounded Mono) as well as more experimental typefaces like Grow or Maxi. Gravity also stands out as a playful and powerful headline typeface.

Dinamo also lets you customize your font files with their Font Customizer™ before checkout so that you can select which alternate character like double or single story a should be the default for your fonts. Really nice.

They offer variable fonts for most of their typefaces and you can download trial fonts for free.

Also check out their great tutorial on how to use (and animate!) variable fonts.

☞ https://abcdinamo.com 👄

❦

This post is part of the Independent Type Foundry Advent Calendar 2022

We’ll start the advent calendar with one of the most successful foundries of the last decade. Grilli Type is a Swiss type foundry that was founded in 2009 by Noël Leu and Thierry Blancpain. Today, the studio numbers eight people dispersed all across the globe. The foundry is known for creating high-quality, contemporary typefaces that push the boundaries of what is possible with type design. Some of their most notable typefaces include GT Planar, GT Sectra, and GT America – but it is actually really hard to pick a favorite because all of their type designs are distinctive and unique.

Also make sure to have a look at the special minisites that accompany each Grilli Type release. Each of them is a beautifully designed digital type specimen that often also shows the intricate details and characteristic design elements in animated infographics. And in case you want to test drive some of their fonts, they offer trial versions with a subset of characters.

In case you understand German, you might also enjoy the conversation with type designer and account director at Grilli Type Tobias Rechsteiner in episode 85 of the podcast OHNE DEN HYPE.

☞ https://www.grillitype.com

❦

This post is part of the Independent Type Foundry Advent Calendar 2022

The independent type design community has grown tremendously over the last couple of years and the quality and variety of fonts is truly breathtaking. A little while ago, I started jotting down a few type foundries to have a list that I could come back to whenever I was in need of inspiration for new typefaces for a project. What started with a few dozen foundries grew and grew over time to a list that now contains more than 110 foundries.

When I shared this on Mastodon, I did not only receive a reply from the Type Directors Club that my list is actually dwarfed by their own list of almost 2000 independent foundries, but also, Andreas suggested that instead of waiting forever until I share my list, I could also make an advent calendar out of it. So, here it is (sorry, Andreas ¯\_(ツ)_/¯):

The Independent Type Foundry Advent Calendar 2022.

Each day of the advent calendar will feature a different type foundry and highlight some of their most notable typefaces. It will be a highly opinionated and almost arbitrary selection of a few of my favorites from the list. So don’t be upset, if your personal favorite foundry doesn’t make it into the calendar. And who knows, maybe we’ll have another calendar next year. But first, let’s look at 24 of the best independent type foundries from all over the world.

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21
• 22
• 23
• 24

I just had a casual chat with ChatGPT that I wanted to share with you. Many of the things I asked and the answers I received are related to a talk I gave last week at CSS Café. I wanted to know what an algorithm might think about all of this.

Decide for yourself where this sits on a scale between interesting and scary. Here’s our “conversation” about typography, the Web, prototyping, design engineering, and tabs versus spaces.

—

Me: Hi ChatGPT! Could you explain the typographic concept of kerning to me?

ChatGPT: Yes, certainly! Kerning is the process of adjusting the space between individual letters in a font to improve the overall appearance of the text. This is typically done to make the letters appear more evenly spaced and visually appealing. Kerning is an important typographic concept because it helps to create a more cohesive and harmonious look for the text, which can improve readability and overall design aesthetic.

But how does this differ from letter spacing?

Letter spacing, also known as tracking, refers to the overall spacing of the letters in a block of text. This is different from kerning, which is the adjustment of the space between individual letters. While kerning is typically used to improve the appearance of specific letter pairs, letter spacing is applied to an entire block of text to adjust the overall density of the letters.

Thank you! And what would you say is most important when working with typography on the web?

When working with typography on the web, there are a few key factors to consider to ensure that your text is legible and visually appealing. Some of the most important factors include:

• Choosing high-quality fonts that are optimized for the web
• Using appropriate font sizes and styles to improve readability
• Ensuring that the colors used for the text and background provide sufficient contrast
• Using appropriate line spacing to improve readability
• Considering the device and screen size of your audience when designing your web page

Overall, the most important thing to keep in mind when working with typography on the web is to prioritize readability and user experience.

Interesting! What do you mean by appropriate line spacing?

Line spacing, also known as leading, refers to the amount of space between the lines of text on a page. In general, it's important to use appropriate line spacing to ensure that the text is easy to read and understand. Too little line spacing can make the text feel cramped and difficult to read, while too much line spacing can make the text feel scattered and disorganized.

The appropriate line spacing for a given block of text will depend on factors such as the font size, typeface, and overall design of the page. In general, a line spacing of 1.5 times the font size is considered to be a good starting point for most text. This can be adjusted as needed based on the specific requirements of the design.

In addition to choosing an appropriate line spacing, it's also important to ensure that the spacing between lines is consistent throughout the text. This will help to create a cohesive and harmonious design, and will make the text easier to read.

I see… so would you say that line spacing is the most important element of good typography?

While line spacing is an important element of good typography, it's not the only factor to consider. In general, good typography involves a combination of factors, including the choice of font, font size and style, color, and overall design. All of these elements work together to create a cohesive and visually appealing design, and to improve the readability of the text.

As such, it's not accurate to say that any one element of typography is the most important. Instead, it's important to consider all of the factors that contribute to good typography, and to balance them in a way that achieves the desired aesthetic and readability.

Do you know what fluid web typography is?

Fluid web typography refers to the use of responsive design techniques to ensure that text is displayed optimally on different screen sizes and devices. This typically involves using relative units, such as percentages or ems, for font sizes and other typographic elements, rather than absolute units like pixels. This allows the text to scale and adjust automatically as the screen size or device changes, ensuring that the text is always legible and easy to read.

Fluid web typography is an important concept because it allows web designers to create websites that are easily readable and user-friendly on a wide range of devices and screen sizes. This is especially important in the current landscape, where people use a variety of devices to access the web, including smartphones, tablets, laptops, and desktop computers. By using responsive design techniques, web designers can ensure that their websites are accessible and usable on any device.

Oh wow! So it adjusts to the size of the screen automatically? And how can I come up with harmonic sizes for headings and body text?

Yes, that's correct! With fluid web typography, the text is automatically adjusted to the size of the screen using responsive design techniques. This ensures that the text is always legible and easy to read, regardless of the device or screen size.

As for choosing harmonic sizes for headings and body text, there are a few general guidelines that you can follow. In general, it's a good idea to use a hierarchy of font sizes for your headings, with the largest font size reserved for the main heading and smaller font sizes used for subheadings and other hierarchy levels. This will help to create a clear and organized structure for your text, and will make it easier for readers to navigate the content.

When it comes to body text, it's generally recommended to use a font size of at least 16 pixels for easy readability. This can vary depending on the specific font and design, but in general, it's a good starting point. You can then adjust the font size as needed based on the specific requirements of your design.

Overall, the key to creating harmonic sizes for headings and body text is to experiment and adjust as needed to achieve the desired aesthetic and readability. There is no one-size-fits-all solution, so it's important to be willing to try different font sizes and styles to find the best fit for your specific design.

Would a modular scale help in this case?

A modular scale is a tool that designers can use to create a harmonious and consistent visual hierarchy in their designs. It's based on the principle that certain numerical relationships, such as those found in the Fibonacci sequence, can create a sense of order and balance in design.

To use a modular scale, a designer selects a base font size and then creates a range of sizes based on the chosen scale. For example, if the base font size is 16 pixels, the designer might create a range of sizes that includes 24 pixels, 36 pixels, and 48 pixels, based on the selected scale. This allows the designer to create a consistent and harmonious hierarchy of font sizes for headings and body text.

In terms of creating harmonic sizes for headings and body text, a modular scale can be a useful tool. It can help designers to create a consistent and organized structure for their text, and to ensure that the different font sizes used throughout the design are in harmony with one another. However, it's important to remember that a modular scale is just one tool among many, and that the ultimate goal is to create a design that is aesthetically pleasing and easy to read. As such, designers should be willing to experiment and adjust their designs as needed to achieve the desired results.

Oh yes, experimentation is really important. What about the importance of prototyping for creating things on the web?

Prototyping is an important part of the design process, including when creating things on the web. Prototyping allows designers to quickly and easily create a working model of their design, which they can then test and refine. This allows designers to try out different ideas and approaches, and to see how they work in practice before committing to a final design.

There are many benefits to prototyping when creating things on the web. Some of the key benefits include:

• Allowing designers to quickly and easily experiment with different ideas and approaches
• Enabling designers to test and evaluate their designs before committing to a final version
• Providing a tangible, interactive model that can be used to gather feedback from users and stakeholders
• Helping designers to identify and resolve any issues or problems with the design before it is implemented
• Providing a starting point for the development process, which can save time and resources in the long run

Overall, prototyping is an essential part of the design process, and can greatly facilitate the creation of effective and user-friendly designs for the web.

Ah, I understand. Would you say that prototyping also helps designers and developers to collaborate better?

Yes, that's correct! Prototyping can be a valuable tool for facilitating collaboration between designers and developers. By providing a working model of the design, a prototype can help designers and developers to communicate and coordinate more effectively.

Having a prototype can make it easier for designers and developers to discuss and understand the design, and to identify any potential issues or challenges. It can also provide a common point of reference for designers and developers to work from, which can help to ensure that everyone is on the same page and working towards the same goal.

In addition, a prototype can serve as a starting point for the development process, providing a clear direction and a solid foundation for the work that needs to be done. This can help to streamline the development process, and can reduce the need for extensive back-and-forth communication and coordination.

Overall, prototyping can be a valuable tool for facilitating collaboration between designers and developers, and can help to create more effective and efficient working relationships.

Oh yes, creating better working relationships is so important today. What else could help with this?

There are many different strategies and approaches that can help to facilitate better working relationships between designers and developers. Some of the key strategies that can be effective include:

• Clearly defining roles and responsibilities, and establishing a clear division of labor
• Providing training and support to ensure that everyone has the skills and knowledge they need to do their jobs effectively
• Communicating openly and transparently, and fostering a culture of collaboration and teamwork
• Encouraging open dialogue and feedback, and promoting a culture of continuous learning and improvement
• Establishing clear goals and objectives, and regularly reviewing and adjusting them as needed

Overall, the key to creating effective working relationships between designers and developers is to prioritize communication, collaboration, and continuous improvement. By implementing strategies and approaches that support these goals, organizations can create a more cohesive and productive working environment that benefits everyone involved.

A clear division of labor? Really? I think that working in silos is one of the core problems that contributes to the widening gap between design and engineering, don’t you think? What about design engineering, for example? Or learning from each other at the intersection of design and development? Don’t you think that this would help a lot because it creates a better understanding of each other's problems and mental models?

You're right, working in silos can create barriers and hinder collaboration between designers and developers. This is why it's important to promote open communication and collaboration, and to encourage designers and developers to learn from one another and work together to solve problems.

Design engineering, which involves the integration of design and engineering principles and practices, is one approach that can help to bridge the gap between design and development. By combining the creative and aesthetic perspective of design with the technical and functional perspective of engineering, design engineering can help to create more effective and user-friendly products and services.

In addition, learning from one another at the intersection of design and development can also be a valuable way to improve collaboration and understanding. By fostering an environment in which designers and developers can learn from and support one another, organizations can create a more cohesive and productive working environment.

Overall, it's important to avoid working in silos, and to instead promote open communication and collaboration between designers and developers. This can help to create a better understanding of each other's perspectives and needs, and can facilitate the creation of more effective and user-friendly products and services.

I see you agree with me here. One thing that bugs me at the moment is that it seems like there is so much movement in the world of web standards and so many new features are coming to browsers that it sometimes feels like everyone is having a hard time staying up to date. It almost feels like we don’t know what is possible with the web as a material anymore. So we end up designing standard solutions that don’t leverage the potential of the web platform. Would you agree? And how can we solve that?

Yes, it's true that there is a lot of movement and change in the world of web standards, and that can make it challenging for designers and developers to stay up to date. This is especially true given the rapid pace of technological change and the constant evolution of the web as a platform.

One of the key challenges in this regard is that many designers and developers are accustomed to working with familiar tools and approaches, and may be hesitant to try new technologies or approaches. This can result in the use of "standard" solutions that don't fully leverage the potential of the web platform, and that may not be as effective or user-friendly as they could be.

To address this challenge, it's important for designers and developers to continuously learn and adapt to new technologies and approaches. This can involve staying up to date with the latest developments in the world of web standards, attending conferences and workshops, and experimenting with new technologies and approaches.

In addition, it's also important to foster a culture of collaboration and learning within organizations. By encouraging designers and developers to learn from and support one another, organizations can create an environment that promotes continuous learning and innovation.

Overall, staying up to date with the latest developments in web standards and technologies can be challenging, but it's an essential part of creating effective and user-friendly designs. By continuously learning and adapting, designers and developers can ensure that they are fully leveraging the potential of the web platform.

Oh yes, true words of wisdom here. Thank you. Is there a book you could recommend for people who want to learn more?

I'm sorry, but I am not able to recommend books as I am a large language model trained by OpenAI and do not have the ability to browse the web or access external information. I am only able to provide information based on the knowledge I have been trained on, which has a fixed cutoff point.

If you are interested in learning more about web design and development, there are many books available on the subject. A quick online search for books on web design and development should provide a range of options to choose from. Some of the most popular and highly-rated books on the subject include "Don't Make Me Think" by Steve Krug, "Designing Web Interfaces" by Bill Scott and Theresa Neil, and "HTML & CSS: Design and Build Websites" by Jon Duckett. These books and others like them can provide valuable insights and practical guidance for anyone interested in learning more about web design and development.

I just received a question from Bastian, one of our readers: Would you say that designers should learn to code?

The decision of whether or not designers should learn to code is a complex one, and ultimately depends on individual circumstances and goals. There are arguments both for and against designers learning to code, and there is no one-size-fits-all answer to this question.

One argument in favor of designers learning to code is that it can help them to better understand the technical limitations and capabilities of the web platform, and to create more effective and user-friendly designs. By having a working knowledge of coding, designers can communicate more effectively with developers and have a better understanding of how their designs will be implemented.

On the other hand, there is also a strong argument that designers should focus on design principles and concepts, rather than on specific technical skills like coding. Designers have a unique perspective and skill set that is valuable in its own right, and learning to code does not necessarily make them better designers.

Ultimately, whether or not designers should learn to code is a decision that each individual designer must make for themselves, based on their own goals and circumstances. Some designers may benefit from learning to code, while others may be better served by focusing on design principles and concepts.

That’s a very diplomatic answer, thank you. One last question: Tabs or spaces?

The debate over whether to use tabs or spaces for indentation in code is a long-standing one, and there is no one right answer. Both tabs and spaces have their pros and cons, and the choice ultimately depends on personal preference and the specific requirements of the project.

One advantage of using tabs is that they take up less space than spaces, which can be useful in cases where file size is a concern. In addition, tabs are generally considered to be more flexible than spaces, as they can be adjusted to fit different indentation levels and styles.

On the other hand, spaces are often preferred by some developers because they are more predictable and consistent. Since spaces always take up the same amount of space, regardless of the size of the font or the display device, they can be easier to work with in some cases. In addition, spaces are also more widely supported by code editors and other tools, which can make them a more practical choice in some cases.

Ultimately, the choice between tabs and spaces is a matter of personal preference and project requirements. Some developers may prefer tabs, while others may prefer spaces. As long as the indentation is consistent and the code is readable, either option can be effective.

I heard that tabs are actually better for accessibility? For blind developers, for example. What’s your opinion on that?

It's true that tabs can be more accessible for blind developers, as they can be more easily interpreted by screen reader software. Since screen readers typically interpret tabs as a single unit, rather than as a series of individual spaces, they can be easier for blind developers to navigate and understand.

In contrast, spaces can be more difficult for screen readers to interpret, as they are typically read out one space at a time. This can make it harder for blind developers to understand the structure and indentation of the code, which can be a barrier to accessibility.

Overall, while tabs and spaces both have their pros and cons, tabs may be the more accessible option for blind developers. By using tabs for indentation, developers can ensure that their code is more easily interpreted by screen reader software, and can make it more accessible to blind developers.

Thank you. That was a great conversation. I enjoyed it a lot. Is there anything you would like to say to the people who might read our conversation? Any parting words?

Thank you for the kind words! I'm glad that you enjoyed our conversation. As for any parting words, I would just like to remind readers that staying up to date with the latest developments in web standards and technologies is an essential part of creating effective and user-friendly designs. By continuously learning and adapting, designers and developers can ensure that they are fully leveraging the potential of the web platform, and can create designs that are engaging, user-friendly, and innovative.

Websites, oh websites!

Thou art a vast and wondrous realm, filled with knowledge and information to be explored.

Thou art a tool for communication and connection, allowing us to share our thoughts and ideas with others across the globe.

Thou art a source of entertainment and delight, providing us with endless hours of distraction and enjoyment.

Websites, thou art a marvel of modern technology, a gift to humanity.

Long may thou reign!

★

Generated with ChatGPT, which you can currently test for free during the research preview.

Since the first days of the Web, people have been thinking and debating hard about the best ways forward. The network, the protocols, the browsers, the documents, HTML, CSS, and Javascript – all those things are the result of years of countless discussions, fights, mistakes, and course-corrections. And as long as the Web has been around, people have been looking for ways to innovate, to improve, and to move the Web forward.

It all started with an era where only a very few early adopters were laying the very foundations of what we take for granted today – including weird and also wrong decisions that we have to work with today. New HTML elements, for example, were introduced with or sometimes also, famously, without much consensus. Like in the case of the IMG tag that Marc Andreessen casually suggested in an email thread in 1993 and then, although it was met with some opposition, simply released in the next version of his Mosaic browser. A few years later, we witnessed the browser wars with Microsoft emerging as the winning company that would dominate the browser market for quite some time. Just like Netscape did with its Navigator, Microsoft implemented its own exclusive features at the time in an attempt to reinforce Internet Explorer’s monopoly position. That browsers pushed for their own agenda started to become a real problem for web designers and developers who had a hard time building for this fragmented Web and, as a response to all the frustration, in 1998, the Web Standards Project was born. Its goal was to remind browser vendors that “HTML, XML, CSS and the DOM are more than just a set of interesting technologies” and that by defining their own standards, companies were actively hurting both authors and users of the Web. I sometimes wonder how the Web would look like today if the people who started the Web Standards movement had remained silent or if their project would not have been successful.

But their efforts were successful and it is one of the main reasons why we have quite a healthy standards process today, with all browser vendors and developers at companies like Google, Apple, or Mozilla working towards the same goal: a consistent and thorough implementation of W3C-specified standards. These open and evolving platform standards are the foundation of everything we build on the Web today. They move slower than some of us might wish, but that’s intentional. Everyone has learned from the mistakes of the past where elements like <blink> found their way into browsers. If a new standard is defined today, it better is specified as thoroughly as possible and with resilience in mind. After all, it will be part of the foundational layer of the Web for years to come. Even after 31 years, the worlds first website can be viewed in any browser without any issues. And if you use a picture element or CSS Grid on a website today, you should be able to expect it to work just as flawlessly 31 years from now.

The web platform in 2022 is less fragmented and more powerful than ever. Not only in terms of occasional new HTML elements like picture, but also when it comes to new CSS features. CSS Grid arrived in almost all major browsers roughly at the same time. And the same thing is now happening with features like :has(), Container Queries, or Cascade Layers. New JavaScript Web APIs make the platform more capable than ever and native Web Components are opening the door for technology-agnostic, robust implementations of custom user interface components.

In recent years, JavaScript frameworks have dominated the public discussion. To many developers, they not only offer a very convenient way to work, but they also seem to be superior to web standards that have even been labeled as being “broken” by some. Why?

Maybe Jeremy is right. Maybe the majority of full-stack developers doesn’t trust native platform features enough. Maybe they’re under the impression that much of what they’re trying to do is so sophisticated and advanced that native browser features and plain HTML, CSS, and JavaScript can’t possibly be powerful enough to compete. Maybe they believe that this is also the reason why frameworks exist in the first place: because browsers are inconsistent, unreliable, and antiquated, and because plain HTML, CSS, and JavaScript are limited and not up to par with the requirements of modern web development. This is exactly the card some frameworks play when they proclaim on their websites that “best practices don’t work.”

Yes, frameworks often provide a great developer experience, they make things easy that used to be harder to achieve before, and they seemingly work at the bleeding edge of technology and innovate at mind-blowing speed.

And as, once more, Jeremy Keith points out in his great talk In and Out Of Style, we depend on all the innovation that happens in the faster, more trendy corners because people build things to solve problems for which the standards might not offer a solution yet. Many of the latest additions to HTML, CSS, and JavaScript first existed as JavaScript libraries or frameworks or pre-processors or polyfills and then found their way into the standards process, back into the layers of web technology that move slower and are more resilient.

But does this make web standards and native platform features weaker or even obsolete? To the contrary. Frameworks come and go. They are transient. Web standards, on the other hand, are the reason the Web is good now and it will become even better in the future. Web standards are why we can all build for the Web using a shared understanding of what it actually means to build resilient, performant, and accessible solutions with the foundational material of the Web. In fact, it feels like the pendulum has just started to swing back again as people realize just how bad frameworks are for performance and as they start exploring new CSS features, native web components, and what can be built on top of all that. Let’s just not forget that we need to take everyone with us, including clients, managers, content strategists, designers, and developers on all sides of all front- and backends.

Happy Blue Beanie Day, everyone.

Twitter is not well. Many of us were worried that Elon Musk might rapidly change the face of the platform. But only very few expected things to go down so rapidly. After the latest deadline to respond whether they want to stay, it looks like about 75 % of the remaining workforce has not opted in to the tech billionaire‘s “extremely hardcore” Twitter 2.0 and will therefore leave the company. From the outside, it all looks like a complete mess and that it’s only a matter of time until we see a data breach or a major outage, because nobody can guarantee the stability of the platform anymore.

The Nest We Built

For many of us, Twitter was a special place on the Web. It was the place where not only celebrities, politicians, or journalists were commenting on the latest trends in society. It was also the home of the majority of the Web community. On Twitter, we would meet people who shared our values and interests, we got to know peers in our industry, and many of the people we briefly tweeted with at first became good online – or even offline – friends over the years.

Despite many questionable management decisions or problems with moderation, despite changes to the timeline and many failed attempts to introduce new features, Twitter prevailed because of the people on the platform who made this comparatively small social network relevant and interesting.

Now that everything seems to go up in flames, people are posting farewell messages or are retweeting some of their favorite tweets for a last time. There are lots of emotions involved, which just shows that many of us would have loved to see this place thrive just a little longer. But what I also noticed is that many of those who are jumping ship and getting an account on Mastodon, are mentioning that “it feels like the early Twitter from 2009”. There was something missing that they now recognize while scrolling down a much calmer, chronological timeline again.

Because, as sad as all this is, Twitter already had already become but a shadow of it’s former self. Many people had already turned their back on the attention-sucking algorithmic version of what had once been a place to have amazing conversations. Those who stayed didn’t do it because Twitter was becoming better, but because they still valued their remaining friends on the site and, maybe, also because they kept clinging to the memory of early Twitter, unwilling to let go. Maybe the Twitter we all loved was long gone, anyway.

A Reset

The end of Twitter as we know it might be a perfect time to take a step back and review our use of social media in general. Whenever a site like Twitter goes down, it takes a vast amount of data and a large chunk of our collective web history down with it. And that’s also true for all the other social media platforms people are now starting to use as alternatives.

There is one place, however, that will stay with you whatever happens to all the platforms you post on: your personal website. So if you don’t have your own website yet, get a domain today, own your content, and publish on your own site. This doesn’t mean that you need to stop using social media or that you should use solely your website instead of other tools of communication. But think about the things that you would like to preserve or share that aren’t ephemeral and temporary. For those things, those thoughts, a personal website is the perfect place. Plus, it is the perfect playground to explore new web technologies or try out new stuff. The possibilities are endless.

Spreading Our Wings

In every ending there is a new beginning. The end of Twitter is also a huge opportunity to start something new and amazing, to build new communities and new tools for communicating online. It is a chance to explore new ways to connect our websites to each other, develop new formats for publishing our thoughts, or rediscover alternative ways to discover content, like RSS. And, if you look closely, you can already see and feel a spark of enthusiasm all around. People are linking to their blogs, are sending out their newsletters, or are suddenly reviving old side-projects. Almost as if they just needed permission to finally move on.

The end of Twitter could prove to be a blessing for the Open Web.

Or, to quote Brent Simmons: “The web is wide open again, for the first time in what feels like forever.”

The bird is not well. So it is time to request and download an archive of your Twitter data now, if you haven’t done this recently. After you have requested your archive, it can take a while until you receive it. I requested my archive on the day Elon walked in and got an email notice that my archive is ready for download after about a day. I suppose it might take a little longer at the moment because more people might request their data.

Once your archive is on your machine, you will have a browsable HTML archive of your tweets, direct messages, and moments including media like images, videos, and GIFs. This is nice, but it also has a few flaws. For one, you can’t easily copy your Tweets somewhere else, for example, into your website because they are stored in a complex JSON structure. But even more dangerous: your links are all still t.co links. This hides the original URL you shared and redirects all traffic over Twitter’s servers. But this is not only inconvenient, it is also dangerous. Just imagine what happens when t.co ever goes down: all URLs you ever shared are now unretrievable. And then, there are the images: all images in your archive are much smaller than the ones you originally shared, and when you click to expand them, you are taken to the Twitter website once again. So, your Twitter archive is far from being a safe, independent backup in case you want to delete your account or if Twitter ever dies completely.

But luckily, there is help in the form of a Python script called Twitter Archive Parser, a project startet by Tim Hutton.

This script does the following:

• It converts the tweets in your archive to markdown with embedded images, videos and links.
• It replaces t.co URLs with their original versions.
• It copies used images to an output folder, to allow them to be moved to a new home.
• Afterwards, it asks if you want to try downloading the original size images using download_better_images.py.

The most challenging part of using it might be that you need to install Python3 first (😅). But once this is done, all you have to do is to put the little parser.py script into your downloaded Twitter archive folder and run it via python parser.py.

And that’s it. My Tweets are now available as Markdown and all links are converted into the originally shared URLs. 🎉

Like in this Tweet from 2011:

'I've been doing this for fifty years and I know what I'm doing!' Rand v Jobs: when egos collide http://www.creativereview.co.uk/cr-blog/2011/october/jobs-v-rand #design

(Originally on Twitter: [Wed Nov 02 07:05:48 +0000 2011](https://twitter.com/m_ott/status/131628052932341761))

If you also want to download high-res versions of your images, you can optionally do that as well, but it will ask you first – and downloading them can take a little while.

There are other scripts that do similar or slightly other things – you can find links to some of them in the GitHub repository as well – yet in my case those two little scripts did the job well and it was all I needed (for now). Thanks a lot, Tim! 👏

When author Jim Collins first met his hero Peter Drucker, whom many regard as the greatest management thinker of all time, the two men where at very different points in their lives. Here, a man in his thirties, eager to start a new endeavor, a new self-directed path, but equally terrified by the uncertainty of the outcome. There, in his rattan Wicker chair, the seasoned and accomplished 86-year-old – curiously asking questions and answering those of his counterpart with eloquence and wisdom.

When their long conversation came to an end, Collins, thankful for all the advice he had received, asked Drucker how he could pay him back. Drucker replied:

“You have already paid me back because I have learned.

But I do have a request: that you change your question a little bit.

It seems to me you spend a lot of time trying — worrying about if you’re going to survive. Well, you’ll probably survive. And you spend too much time thinking about if you’ll be successful. It’s the wrong question.

The question is, how to be useful.”

–

From a great conversation on the Tim Ferriss Show, episode #361. Transcript.

It takes years to become good at it. So we read books, take classes, and visit workshops to become better. And still, it may take a lifetime to master it. But more than anything, it is one of the things that makes us human:

Writing.

But now, the algorithms are coming for us. Artificial intelligence algorithms, in particular GPT-3, are not only able to produce news reports, product descriptions, or SEO mashup pieces today, but also texts in the styles of different authors that read astonishingly well, especially to the more casual reader.

Services that let you create document outlines for certain topics or that write whole long-form blog posts within seconds are popping up by the dozens. Just take a look at the huge list at the end of this post. Currently, the quality of the generated texts still varies. You might end up with a piece that feels clunky and unfinished, or you might read a text that is more or less indistinguishable from something a human being could have written. Given the rate of innovation in the field of AI, however, very soon we won’t be able to tell whether a human being or an algorithm has written what we are reading.

How will we use those tools?

As a bicycle for the mind? For example, to improve our own writing by generating alternative phrases or paragraphs that we can use as inspiration or starting points? Or, will we use them to first replace the junior copywriters at our company and later everyone else who is creating written pieces?

Besides the ethical implications of all that, I wonder, however: What about the process of writing? What about intention and the careful choice of words? What about the electricity of metaphor and the magic of rhythm? What about evoking emotions in our audience? What about imagination? What about personality?

Everything an AI burps out will always be “produced”. It will never be “written”.

Sturgeon's law states that “ninety percent of everything is crap” (thanks, Jeremy). This law can easily be applied to written content on the Internet. Out of that 90 %, a large percentage will soon be coming from algorithms that will reproduce information at a speed and cost no human will be able to compete with.

But the remaining 10 %, those are our playing field. Genuine, respectful, imperfect, imaginative, inspirational – and full of the evocative power of language.

First We Shape Our Tools

• https://writesonic.com
• https://hyperwriteai.com
• https://writerly.ai/
• https://www.shortlyai.com/
• https://kafkai.com/
• https://www.jasper.ai/
• https://copylime.com/
• https://www.copy.ai/
• https://www.frase.io/
• https://deepai.org/
• https://qopywriter.ai/
• https://inferkit.com/
• https://scalenut.com/
• https://rytr.me/
• https://simplified.com/
• https://quillbot.com/

The hellsite has a new king. And so, many are moving from Twitter to other social networks like micro.blog or Mastodon or are at least trying out those other options while waiting how things might develop.

Cross-posting – or not?

One of the first questions that comes to mind is: how can I post on both Twitter and Mastodon so that I don’t have to post my status updates separately? A good idea and something that can be done in various ways.

There are, however, a few problems that come with cross-posting from one platform to another. For one, it can look a little weird when your posts on one platform obviously look like they have been written for another platform. Your tweets might contain user handles from Mastodon that don’t exist on Twitter or a Mastodon post could contain a “RT” (for retweet) or quoted tweets. This can look like you don’t really care about the people spending time on the other platform. But especially the user handles can be problematic because people might not know what to do with them or why they look so differently.

But even if you are fine with all that, cross-posting doesn’t solve one of the biggest problems when it comes to posting content online: if you post your thoughts into a silo like Twitter, they are, to a certain extent, out of your control. You can delete (or maybe even edit) them, yes. But when a platform goes down, you end up with the problem of having to export and backup your data again.

POSSE

Wouldn’t it be great to be able to post tweets, toots, or other status updates on your own site first? Especially the more important ones that you want to preserve? At least, your own site will be with you even when Twitter goes away or your account suddenly gets suspended. This is one of the basic principles of the IndieWeb: publish on your own site, syndicate elsewhere. Or short: POSSE.

You can see an example here on my site. I am syndicating all posts of my microblog section to Twitter, micro.blog, and Mastodon.

The first thing you need to do to achieve all this is to create a section on your site that you can use to post short status updates. This microblogging section then needs an RSS feed. Mine is this one, for example. Whenever you post a status, a new item will be added to the feed. And we can then use the feed to send new items to Mastodon, Twitter, or any other platform.

I won’t cover in this post how you can set up an RSS feed for your site. Yet it shouldn’t be that hard to find solutions online for whatever you are using under the hood of your site. And for the sake of brevity, I will also focus on syndicating your posts to Twitter and Mastodon only.

Syndication with IFTTT

With an RSS feed in place, the next step is now to use a service that will send new feed items to the different platforms. We’ll use IFTTT for that, so you will need at least a free account there. Of course, you could also use Zapier or any other automation tool that you prefer.

Let’s start with how you can set things up for Twitter.

Syndicating to Twitter

The first step is to create a new Applet:

Now, under “If this”, select “Add” to add a trigger and search for and select “RSS Feed”. Select “New feed item”, which creates a trigger that fires every time a new item is added to your feed. Paste in your RSS feed URL and finish this step via the “Create trigger” button.

Next, we need to define what should happen when the trigger fires. Select “Add” next to “Then that” and search for and select “Twitter”. Select “Post a tweet” or also “Post a tweet with image”. Connect your Twitter account. For the Tweet text, you can use the fields that are available under “Add ingredient”. You can use {{EntryTitle}},{{EntryUrl}}, or {{EntryContent}}, for example.

Select continue, rename your applet if you want to, and complete the process with the “finish” button. And you’re done! 🙌

If you have a free account, your applet will only run once every hour or so. But whenever there is a new item, IFTTT will automatically post a tweet for you.

Syndicating to Mastodon

With Mastodon, setting up syndication is a little bit trickier. That’s simply because there is no built-in integration for Mastodon in IFTTT. Thankfully, I found a helpful article by Kelson Vibber about “How to Post to Mastodon From Anything Using IFTTT”.

You can still post to Mastodon using a feature called Webhooks. IFTTT Webhooks let you create Applets that can make or receive any kind of web request. So first, we need to activate that.

Go to IFTTT Webhooks and activate the feature by clicking on “Connect“ button.

Now we need to make sure IFTTT is allowed to make a request to post stuff. For this, we need to add IFTTT as an application in the settings of your Mastodon account. Go to Preferences > Development/Your Applications (e.g. on mastodon.social you’ll find it here). Add a new application and enter a name for it. Under Application website, you need to add the full URL of your IFTTT Webhook. You’ll find it on the Webhooks Settings page. From the checkboxes below, only select write:statuses.

Now, everything is ready to create our applet. The first step is the same like in the Twitter example. Create a new Applet and add your RSS feed as the trigger. Now comes the juicy part: Select “Add” next to “Then that” and search for “Webhooks”, select it, and then choose “Make a web request”.

Now you need to add the details of the request to Mastodon.

The “URL” should look like this:

https://mastodon.example.com/api/v1/statuses?access_token=1234567890

Make sure to replace the mastodon.example.com with the domain of your instance’s server! Also replace 1234567890 at the end of the URL with the access token of the application you created in Mastodon in the settings. To find the token, click on the Application and look for “Your access token”.

The “Method” should be POST.

For the “Content Type”, select application/x-www-form-urlencoded.

Ignore “Additional Headers”. For the ”Body” of the Request, use something like

status={{EntryContent}}

You can also add other ingredients like the URL or date of the post. Just make sure to include the status= part so that everything is working properly.

Lastly, select continue, rename your applet if you want to, and complete the process with the “finish” button.

And you’re done again!

Now, whenever you post a status update on your own site, it will show up (after a little delay) on both platforms. 🎉

It could happen out of the blue, without any warning. It could happen without you knowing what you did wrong. It could happen today.

Twitter could just suspend you.

Gone. Your Tweets, your followers, your thoughts, your jokes, your conversations. They’re just gone.

Gone, not because you did something wrong, like not abiding by the Twitter rules. No. Gone, because a flawed algorithm or an overwhelmed moderator decided that something justified a suspension. Maybe you wrote something that could be misinterpreted when taken out of context. Or, an army of trolls or bots with bad intentions reported you. You probably wouldn’t know because Twitter just wouldn’t tell you. They would just erase your content.

Gone. Years of careful consideration, of sharing your knowledge, of building connections, of building a reputation.

My friend Manuel Matuzović just got his account suspended by Twitter. He does not know why – Twitter did not yet give a reason for banning him.

Thankfully, Manuel still has a platform that he owns. A platform that nobody can simply suspend or delete. His own personal website.

I’ve written before about the many good reasons why a personal website is your ultimate home on the Web. Twitter randomly banning users by accident is just another example of the many ways you can lose your content if you don’t own it.

So if you are on Twitter, download a copy of your data from time to time. In fact, it could be a good idea to do it this week before the Elon Musk deal might close. You could also connect your Twitter account to your website and archive your Tweets to take ownership of them. Or, you can do it like Jeremy Keith and many others on the IndieWeb and write Tweets and even replies via your website and post them to Twitter from there.

But most importantly, always write your most important thoughts on your own site. You can share the link on as many platforms as you like and have conversations with anyone who wants to connect with you and your work. But nobody can take it from you. You are in control. Forever.

I bet you know this: You’ve created something – a drawing, a layout, a video, a piece of code, or a blog post – and after you’re more or less done, you pause and you look at it. And you don’t like it.

Maybe it is a little detail that is not right, or maybe you don’t like the whole piece for reasons you cannot explain. Whatever it is, you are just sure that this one piece of work isn’t particularly good. Or is it?

Whenever I’m in such a situation or people mention feeling the same way, I have to think about an interview Debbie Millman did for her Design Matters podcast. In their lovely conversation, comic artist Lynda Barry told a story about one of her teachers in art school. Lynda had just finished a drawing. She and her teacher were looking at it, when Lynda said: “I don’t really like this drawing.” Her teacher paused, then she went:

What?

“The drawing is already here. It’s none of your business whether you like it or not.”

For Lynda, this was the crucial moment of her entire career. She realized that there is another way to look at her work besides just asking “do I like it or not?”

You don’t have to like your work for it to work. Liking or not liking it isn’t the essential part of making something. As long as you are the only judge and as long as it is unpublished, even, what’s the difference whether you like it or not? Or, to put it another way: everything you create will only work if it helps other people or if they like what you created. Every piece of art that is supposed to have a value and impact in our culture is meaningless unless it is seen by someone. Only by the interplay between your work and the people who interact with it, its real value will reveal itself.

So, if you did your best when you created a piece of work, but your perfectionism or fear of judgement or lack of confidence makes you not like it, ask yourself: who is this piece for and will it work? And then, allow it to exist, to grow, to evolve, to improve, to fade away, or to shine. But first, make it work.

I love building prototypes. They allow me to explore and sketch ideas, test my assumptions, and try out things at an early stage to make better design decisions. Prototyping is the single best tool we have in our toolbox as designers and developers. And because anything can be a prototype, I use whatever gets the job done: Sometimes, I grab a pen and do a series of rough sketches. Sometimes, I use prototyping software like Adobe XD or ProtoPie to try out an idea for an interaction. And sometimes, I write code.

Prototyping with code is my favorite way to build prototypes whenever I want to work with the real material of the Web and sketch out an idea in the browser with HTML, CSS, and JavaScript. Maybe it’s a layout that uses CSS Grid, a GSAP animation test, or a little interactive component. Whatever it is, I try to focus on the essence of what I want to try out and learn. What I don’t focus on, however, is code quality. And this is where it can get complicated.

What I’ve experienced several times now, is that other team members will misunderstand this conscious decision to not write production code in a prototype. Some engineers will wonder why code prototypes were created when they can’t even reuse the code of those prototypes in production. To project managers, it sometimes feels like we are doing work twice and are wasting precious time and budget. Maybe the problem also lies in how differently designers and developers understand prototypes. Here’s Bill Buxton quoting a junior industrial designer:

Maybe that’s it: To me, a prototype is a means to an end, a rough sketch, a shitty first draft. It will probably even be thrown away once we’ve found what we were looking for. A code prototype is not a first step in the process of building the final thing, it is a tool that helps you decide whether and how you should build something in the first place.

A prototype lets us make better design decisions at any step of the process because we can see what works. And to see what works, we don’t need production-ready code. A shitty code prototype will do.

I couldn’t agree more to what Dave wrote in his recent blog post about the increasing demands of the front-end web: the job of a front-end developer is getting ever more complex. From writing well-structured, semantic HTML to the latest (fantastic) new CSS features, to accessibility, performance, animation, data handling, components, frameworks, and so many more things – it almost seems impossible to become an expert at everything a developer is expected to know today. Therefore, we need to find ways to split the responsibilities. We need new roles at the intersections.

At the same time, I see more and more designers struggling to get an idea of what is possible even with the most basic materials we all build with: HTML, CSS, and JavaScript. Just take all the new CSS layout features as an example: CSS Grid, Flexbox, multi-column layout, fluid layouts with clamp(), min(), and max(), and so on. Browsers are more capable today than ever before and layout on the Web isn’t a hack anymore. Yet in my experience, and from asking designers in my workshops, I know that most designers (unless they write CSS themselves) have no idea that the very fundamentals of how we do layout on the web have changed unlike ever before. How are they going to make the best use of what’s possible and design materially honest solutions when they don’t even know those features exist let alone have an idea how they work?

So yes, our jobs as builders for the front-end web have become mind-bogglingly complex and inventing new roles will help to release some of the pressure we all feel. But there is still the need to learn from each other across disciplines, as well. Designers need to know what is possible in the front end. Front-end developers have to get a better understanding of design basics to fill the gaps in a design, for example, between breakpoints.

Adding roles at the intersections could provide the knowledge needed to close those gaps. Because instead of fiddling around with something you don’t fully understand or don’t feel comfortable with yet, especially when working under a tight deadline, imagine having someone who can actually show you the most important bits and provide the necessary context. What would that leave you with? The knowledge and understanding of why and how to do it on your own next time. And: more time to do what you are best at doing.

At the same time, it is important to not shift all the responsibility upon the person filling a new role like “Design Engineer”, “CSS Engineer“, or “Front-end Designer”. Building for the Web is a team sport and it is crucial that we never stop to talk to each other and learn from each other frequently, openly, and with a beginner’s mind, regardless of each other’s roles and responsibilities. Learning from each other happens gradually and sometimes slowly, but it is one of the superpowers of cross-functional teams. And yet again, roles at the intersections can help with this, because they increase the surface area for collaboration.

Just like Dave, “I don’t have answers, only questions”. Adding bridge roles is a good thing and something that does happen already. In fact, I am working in a design engineering role in many of my projects these days. But what else can we do about the growing complexity of the Web? Do we need to eliminate 80 % of the work? Do we need to improve education? Do we need to become more open and supportive as a community? Do we need to talk more, write more, teach more, prototype more, and share more best practices? Or, do we maybe need less? Do we need to focus on the essentials?

A while ago, I wrote about Dieter Rams’ principle of “less but better”. What could “less but better” look like for the front-end web?

Please use whatever tool gets the job done and makes sense for you.

But then again, I’ve seen so many frameworks and tools come and go that it can be dangerous to put all your eggs in one basket. You know what really is time well spent and a worthy investment into your future, your career, and your team? Learning the basics and becoming really good at them.

Therefore, don’t let tools cover up weak spots in your or your team’s knowledge. Because what looks like a flaw at first glance is actually an opportunity to learn and improve.

And don’t let any tool make you believe that it isn’t worthwhile to learn the foundations of web technology or let it stop you from participating in the vital dialogue that pushes the platform and its standards forward.

There are many ways to adjust your CSS code to a browser’s support for a specific CSS feature. If you want to check if a certain property is supported, you can write a feature query using the @supports at-rule, for example:

@supports (display: grid) {
  div {
    display: grid;
  }
}

If the browser supports display: grid, it will apply all the styles inside of the at-rule. Otherwise, it will just ignore the whole block.

If you want to check for support of a whole selector, you can use the @supports selector() function, which has surprisingly good browser support.

@supports selector(:nth-child(1 of .class)) {
	/* Do something… */
}

In case you want to learn more, Chris Coyier also wrote a nice piece about how to use @supports selector().

In a current project, however, I ran into a situation where I needed to test for support of the relatively new :where() selector. The tricky situation: both :where() and @supports selector() landed in browsers at about the same time, so if you want to check for support in an older browser, like Safari 13, you’re out of luck. Providing a sensible fallback for older browsers was one of the requirements, though, so I had to look for an alternative. And in the end, I decided to use JavaScript.

I found the solution in a post by Lea Verou. In 2011, she wrote about how to test for CSS selector support by creating a new <style> element with the selector we want to test for and then reading out the stylesheet to see if the rule actually exists. A really smart solution to detect support even in browsers <IE8.

But she also mentioned a much simpler solution: Using document.querySelector() in a try...catch statement. And since support for the Selectors API is very good these days, I settled on trying this. And it is indeed straightforward:

try {
    document.querySelector(selector)
} catch (error) {
    console.error(error)
}

First, we let the browser try to execute the document.querySelector() method with the selector we want to test. In case the selector is invalid, an exception is thrown and the code in the catch block is executed. In the example above, the error will then be output to the console.

We can now wrap this in a reusable function that returns true in case our selector is supported and false if is isn’t:

const isSelectorSupported = (selector) => {
    try {
        document.querySelector(selector)
        return true
    } catch (error) {
        return false
    }
}

Now, you can test for support of any selector and, for example, add a class to the <html> element, if a browser “cuts the mustard.”

if (isSelectorSupported(":where(body)")) {
    document.documentElement.classList.add("supports-where")
}

I’d still recommend you use a CSS-only solution to check for support whenever possible. But for all other cases, this little helper function might prove very useful.

✍️✍️✍️ Edit

Shortly after I shared this post on Twitter, I received two replies by Mehdi Merah and Bramus van Damme, who both suggested alternative methods of detecting support for a selector. First of all: thanks a lot! 🤗 Let's have a look at them.

Using CSS Custom Properties to check for selector support

Mehdi mentioned that one could also use CSS Custom Properties to emulate @supports in JavaScript. A smart solution and one that can be combined with your existing rules. The idea is that you first define a custom property that basically acts as a boolean variable and then set it to a different value inside of the selector you want to test support for:

:root {
  --supports-selector-where: 0;
  
  @supports selector(:where(a)) {
    --supports-selector-where: 1;
  }
}

In our case, we can even reduce it further and only set the custom property using a selector with :where(). If the browser supports it, it will set the custom property to 1:

:where(:root) {
  --supports-selector-where: 1;
}

In JavaScript, we can now access the value of our custom property with getComputedStyle and getPropertyValue. And if the value is 1, we know that the selector is supported.

const rootStyles = getComputedStyle(document.documentElement)
const supportsSelectorWhere = rootStyles.getPropertyValue('--supports-selector-where').trim() == "1"

console.log(supportsSelectorWhere) // boolean -> true if supported

This technique can not only be used to detect support for selectors but for any other cases where you want to communicate a status from CSS back to JavaScript. Andy Bell wrote a brilliant little helper function that even lets you state which datatype you want to get back:

/**
 * Pass in an element and its CSS Custom Property that you want the value of.
 * Optionally, you can determine what datatype you get back.
 *
 * @param {String} propKey
 * @param {HTMLELement} element=document.documentElement
 * @param {String} castAs='string'
 * @returns {*}
 */
const getCSSCustomProp = (propKey, element = document.documentElement, castAs = 'string') => {
  let response = getComputedStyle(element).getPropertyValue(propKey);

  // Tidy up the string if there's something to work with
  if (response.length) {
    response = response.replace(/\'|"/g, '').trim();
  }

  // Convert the response into a whatever type we wanted
  switch (castAs) {
    case 'number':
    case 'int':
      return parseInt(response, 10);
    case 'float':
      return parseFloat(response, 10);
    case 'boolean':
    case 'bool':
      return response === 'true' || response === '1';
  }

  // Return the string response by default
  return response;
};

With this helper function, we can check for support for :where() with the custom property from before and one line of JS:

const isWhereSupported = getCSSCustomProp('--supports-selector-where', document.documentElement, 'boolean')

Using CSS.supports()

Bramus suggested taking another route: the CSS.supports() method. This native JavaScript method with really good browser support accepts anything you may put inside a supports at-rule, so we can do this:

const supportsWhere = CSS.supports('selector(:where())');

if (supportsWhere) {
    document.documentElement.classList.add("supports-where");
}

And that’s it. Plain and simple.

Definitely my favorite solution because of good browser support and its simplicity – and something I probably wouldn’t have learned about if I hadn’t written and shared a blog post about my problem.

I’m right with Dave on this one! 💚

…and…

But it is also important to know that emphasizing individual responsibility is one of the new strategies of the fossil fuel industry to distract from their own contributions and to create “apocalypse fatigue” – you don’t act because it doesn’t seem to make a difference anyway.

When it comes to individual action, we have to get to a point where we all realize that we are, actually, not alone. Some of us drive and fly less often, some eat less or no meat, some save energy or install solar panels. Some of us join a climate movement, but not everyone has to.

But we all do something, because it is the right thing to do. And even if it feels like we are the only person doing it, it will make a difference.

We can see it when the folks at Apple start talking about how “green” their products are in their keynotes.

We can see it when, suddenly, discounters in Germany start printing on their packaging how much plastic they are saving.

We can see it when, seemingly out of nowhere, we elect leaders who actually make change happen.

You probably know this situation. You are working on a project and one of the npm packages you are working with contains a nasty bug or is lacking a critical feature. Of course, you first head over to the repository, e.g. on GitHub, and draft an issue. Maybe you even write a fix yourself and create a pull request. But, depending on the project, it might take a while until someone finds the time to review your issue or merge and publish the pull request. Sometimes, the project even is completely unmaintained. Whatever the reason, you might want to patch the package yourself to be able to move on. So what do you do?

Wouldn’t it be ideal to be able to fix the issue immediately but still maintain the connection to npm, being able to update the package with all other dependencies?

This is what patch-package does.

You install it via npm

npm i -D patch-package

And add a script command to your package.json file that runs after npm install:

"scripts": {
+  "postinstall": "patch-package"
 }

Now you can fix the bug in one of your dependencies, hit save, and, when you’re done, run:

npx patch-package your-package-name

This will create a .patch file that contains your changes. All the patches you create this way are then applied automatically when you use npm (or yarn).

Patch-package might not be the right solution for larger fixes or when you are writing a change that is really consequential. Also keep in mind that you might not be able to oversee all the consequences of a change, also regarding other packages. But for minor fixes, patch-package can save your day.

And, once your pull request has been merged, you can – and should – remove your patch again, of course.

You know what makes it so easy for many people to just dump their thoughts into a silo like Twitter instead of writing a post on their own site?

You don’t have to come up with a title for your post.

Providing a proper document outline is one of the most effective things you can do to improve the accessibility of your HTML. Like the headings of the chapters and subchapters in a book, the structure of the heading elements in our HTML should have a semantic, tree-like structure. The most important headline, most often also the title of your document, is the one and only <h1>. Headings nested one level deeper in the structure should be <h2>s, headings nested within those parts of your documents should be <h3>s and so on – until you might even reach <h6>.

Headings Convey Structure

The advantage of providing such a clear structure is not only that you force yourself to structure your document more thoroughly. The headings of your document are also a way to provide your users with a first glimpse of what is on your page and how it is structured. Scanning the headings of your page, users get a feeling of what you want to tell them and if that’s what they are looking for. The same is true for screenreader users, but they can also use your headings as a tool to quickly navigate to the sections that interest them. VoiceOver, the screenreader built into macOS and iOS, for example, does provide a feature called “rotor”. With the rotor, users are able to navigate through a list of headlines. But this feature can only be used effectively if the document outline is properly structured. If your document provides a mess of different heading levels all mixed up (maybe also because you used headings to visually style text), it will be much harder for users to understand the structure of the page.

Tools to Check Your Headings

Long story short: a nicely structured document outline, with a clear hierarchy and no skipped heading levels, is one of the hallmarks of accessible web design. And it is also a requirement for a website to pass an accessibility test. But what can you do if you want to check the heading structure of a page? Do you open up the developer tools of your favorite browser and start clicking through the document structure, opening all the nodes to check whether there is a headline in there and if it has the right level? Although this would be very dutiful, there are, of course, more efficient ways to check your heading structure. There is now a plethora of options out there that can help you with this. Some list all headings for you, others highlight the heading levels directly on the page, many do both. But which tool is good? What are people using most often? I wasn’t sure myself, so I asked Twitter:

What tool do you use when you want to see the headings outline of an HTML document?

— Matthias Ott (@m_ott) July 12, 2022

The amount of answers I received was staggering (thank you all!) and while a few people mentioned tools I already knew, many more were useful additions I didn’t know before. Here is a little list of (almost) all the answers I got. Some of those tools are also useful to check for other accessibility issues, like color contrast, general markup issues, or missing alt attributes. So make sure to not just pick the first one from the list but try out a few of them:

• The WAVE browser extension (Chrome, Firefox, Edge) was mentioned by quite a few people – one of my favorites, for sure.
• H123 Bookmarklet (Thanks again, Sara!)
• Headings Bookmarklet for Accessibility Testing by Paul J. Adam, who also has many more useful bookmarklets
• Polypane, Kilian Valkhof’s brilliant browser for developers, has a nice feature to list and navigate through the heading structure.
• Sa11y is a simple in-page checker that visually highlights common accessibility and usability issues, including headings.
• Tota11y, an an accessibility visualization toolkit by Khan Academy, also does a great job in highlighting all headings and their levels.
• Accessibility Insights for Web has a feature that highlights the headings on a page as well.
• The Web Developer extension (for Chrome, Firefox, and Opera) by Chris Pederick also shows you the document outline of the current page
• HeadingsMap in an extension available for Chrome and Firefox that does exactly that: map the headings of your document.

Yesterday, I shared how to test a whole website for accessibility issues with Pa11y and how to output the results as HTML. I also shared the link on Twitter, as I usually do, and Darek Kay chimed in, mentioning an alternative tool he created: Evaluatory.

Just like Pa11y, Evaluatory scans a website for accessibility and markup issues. Under the hood, it uses Deque Systems’ axe-core to test for accessibility issues and html-validate to validate your markup. It then outputs the results into a folder as HTML as well. Compared to the Pa11y check, Evaluatory comes with a few nice improvements. It checks for issues at multiple breakpoints at the same time, it can emulate dark mode, disable JavaScript (yes, Heydon!), and also run tests for all URLs referenced in a sitemap. And, it even takes screenshots for different breakpoints of each page it tests.

You can install it globally via npm, for example:

npm install -g evaluatory

And then run a test against a sitemap:

evaluatory --sitemap https://www.porsche.com/germany/Sitemap.smap

And this is how the HTML looks like after the tests are finished – in my case, in dark mode:

I really like the way Evaluatory presents the results! You get a link to the web page that was tested for quick access and can also open a detailed summary for each page. Here, the test results are sorted by category (base, axe-core, html-validate, and screenshots). A link to the respective rule that was violated is provided for more information and you also get syntax-highlighted code snippets which makes it easy to find the lines in your code that are affected. Overall, Evaluatory looks like a great addition – or even an alternative – to scanning your sites with Pa11y. Nice work, Darek! 👏

This week, I’m doing an accessibility audit for a client. One of the first steps is to have a general look at the site. You can – and should – do that manually for sure, but another very useful way to get a good first impression of how good or bad things are is to use an automated tool like Pa11y.

Pa11y is a set of free and open-source tools with which you can test a website for all kinds of accessibility (a11y) issues like insufficient color contrast, missing alt texts, missing labels, wrong heading levels, problems regarding ARIA roles, or general HTML validation issues. There are different tools available: pa11y itself is a command-line interface to run a one-off accessibility test against a web page. Pa11y Dashboard is a web interface for Pa11y to constantly keep an eye on the current a11y status of one or more websites. It is powered by Pa11y Webservice. And then, there is Pa11y CI, an accessibility test runner built using Pa11y that lets you run tests as part of a Continuous Integration environment. This is especially useful if you want to make sure that no issues make it to the live site.

Installing Pa11y

Node.js is a prerequisite – you might want to install it via nvm first. Then, install Pa11y globally via the command line:

npm install -g pa11y

Now, you can run tests against a URL…

pa11y https://example.com

…or a file:

pa11y ./path/to/your/file.html

Pa11y will run the test and display the results in the terminal.

There is much more you can do with Pa11y, in particular the JavaScript Interface, but this would be beyond the scope of this post. So have a look at the GitHub repository in case you want to learn more.

Pa11y CI

Running a test against a URL or a file is already super helpful, but wouldn’t it be nice to run a test for a whole site and, let’s say, get a report of the results in HTML?

This is can be done with Pa11y CI. While Pa11y CI is best used to run automated tests, you can run it manually as a command-line tool as well. And it comes with a neat feature: you can tell it to run a test against a whole sitemap. Let’s try this. First, we install Pa11y CI globally:

npm install -g pa11y-ci

Now, you could create a config file that includes all the URLs that Pa11y CI should check. But you can also feed it with an XML sitemap with the --sitemap option:

pa11y-ci --sitemap https://pa11y.org/sitemap.xml

Pick Your Reporter

We’ve seen that when we run a test with either pa11y or pa11y-ci, the results will be output to the command line by default. But this can be changed by switching the so-called “reporter” from cli to something else. You could use csvor json, for example, but you can also output the test results as HTML. Pa11y now has an HTML reporter built in. The reporter can be set via the --reporter option. So when you are using Pa11y, you can write:

pa11y --reporter html https://example.com

But in our case, we want to run a test against a whole sitemap with Pa11y CI. Here, we have to install one additional rpm package that adds an HTML reporter: Pa11y CI HTML Reporter.

You install it via npm again:

npm install pa11y-ci-reporter-html

Now, this reporter can again be set via the --reporter option:

pa11y-ci --reporter=pa11y-ci-reporter-html https://pa11y.org/

Pa11y CI will now run its test(s) and output the results in the current working directory as HTML. Nice! In the example above, we ran the test against a single URL, so the last step is to run the tests against a sitemap using the HTML reporter:

pa11y-ci --reporter=pa11y-ci-reporter-html --sitemap https://pa11y.org/sitemap.xml

The result:

Et voilà! We have generated a nice HTML overview of the test results of the whole website we want to test. Now, we can go on and dig deeper, document existing issues in more detail, or even – if we have access to the codebase – immediately fix a few things to reduce the number of issues we see.

Again, an automated tool like Pa11y is not a substitute for a proper accessibility audit by an actual human being – particularly one using a screen reader. But it does give you a good general overview and helps you to quickly address many of the things that are wrong in your codebase.

The Cascade is legendary. Legendary because it is the C in CSS. Legendary in how well it works to determine which selector wins when browsers apply styles to HTML. And legendary in how little many of us really know about it.

Bramus van Damme recently gave a fantastic talk about the Cascade at CSS Day. Whether you want to learn what the Cascade is and how it works or you already are familiar with it, watching this talk will be equally valuable for you. Bramus does a great job explaining the different steps of the Cascade and what specificity has to do with it in a way that you really understand it.

He then goes on to show how the new concept of Cascade Layers works and what you can do with them. For example, they can be used to better separate the styles of a component library or third party components from the rest of your CSS. Cascade Layers are already supported by all modern browsers, so it is time to get familiar with them.

If you want to learn more about the Cascade and Cascade Layers, have a look at the slides from Bramus’ talk, his great blog post about Cascade Layers, and also the following articles:

• Cascade layers are coming to your browser, Una Kravets

• A Complete Guide to CSS Cascade Layers, Miriam Suzanne

• Getting Started With CSS Cascade Layers, Stephanie Eckles

What’s the single best thing you can do if you want to learn a new tool or evaluate a new technology? Right, it’s getting your hands dirty.

Only by building something tangible, like a realistic prototype or even a real project, you’ll get immediate answers to the questions that are relevant to you and your specific context. Based on those insights, you can then make an informed decision about whether this tool is the right one for you or not. Also, it is so much fun to build something new, right?

So imagine my excitement (🥳🎈) when I recently decided to start a new side project and finally got to try out Eleventy, Zach Leatherman’s lovely Static Site Generator. And because every good side project begins by starting another side project and also because the The Law of Eleventy™ demands that you create a starter project as the first step of your learning journey, I did exactly this: set up a starter project.

Another thought I had immediately was that I could also try out Vite, Evan You’s blazing-fast build tool. I had heard a lot of praise for it and also listened to a really intriguing episode of Chris’s and Dave’s ShopTalk Show with Evan You. So I had a look at it and, luckily, also found a plugin Zach had published earlier this year that lets you use Vite with Eleventy.

A clear, performant base

The thing with starter projects is that they grow old very quickly. Of course, when you set everything up, you want to add the latest tools, all those dependencies that are currently state-of-the-art, and also want to try out new things. But this, in turn, means that you now might have to update your project more regularly and also re-evaluate some of the decisions you made. On the other hand, as long as, for example, a build process works, you might not need to change a running system. And there is always the process of learning something new that makes setting up a starter project valuable in itself.

So, I set out to create a starter that should be as simple and concise as possible, not only to make it easier to understand for anyone who wants to get their head around it as well – including or my future self – but also to reduce the need for maintenance. At the same time, I wanted it to have all the features already built in that I would enjoy in such a base project. For example, a really performant base with Critical CSS, a web font loading strategy, or also base styles for responsive typography. And, of course, RSS.

The result of my endeavors is Eleventy Plus Vite, a starter project with the following features:

• Eleventy 2.0.0-canary
• New Eleventy 2.0 Dev Server with live reload
• Vite as Middleware in Eleventy Dev Server (uses eleventy-plugin-vite)
• Eleventy build output post-processed by Vite (with Rollup)
• CSS/Sass post-processing with PostCSS incl. Autoprefixer and cssnano
• Uses my own opinionated CSS/Sass structure
• Critical CSS, generated and inlined via rollup-plugin-critical. The main CSS file is then loaded asynchronously with Scott Jehl’s media loading strategy (adds media="print" and swaps to media="all" once loaded)
• Example implementation of a web font loading strategy (critical FOFT with preload)
• Basic fluid typography based on Utopia
• Basic dark mode support (using prefers-color-scheme and CSS Custom Properties)
• Polyfill for focus-visible
• RSS feed already included 🧡
• XML sitemap
• Four Hundos Lighthouse score 💯💯💯💯

There were quite a few things to get my head around, besides learning about how to use Eleventy and Vite. For example, I had also not worked with Rollup before, which Vite uses to bundle JavaScript modules. And many of the plugins I now use in the starter were also new to me. But that’s exactly why building something real is so valuable: in order to find solutions for problems that seem complex and unsolvable at first, you are forced to play, explore, and blindly try out things that sometimes work and most often don’t. And step by step, you understand how everything works.

If you want to get started with Eleventy as well, maybe you better don’t use my starter. 😉 Have a look at Eleventy and a few other starter projects yourself. There is also a brilliant introduction by Andy Bell, Learn Eleventy From Scratch. The course is now Open Source and although it might be outdated here and there because it is from 2020, it still explains the basic concepts very well. Stephanie Eckles wrote A Deep Dive Into Eleventy Static Site Generator for Smashing Magazine and she also collected a lot of useful resources on the website 11ty Rocks!. And, besides many more articles you can find on the Web, there is the Eleventy Documentation, to help you get started.

Thanks so much again to all the people who created a starter project or Eleventy site before me, especially Stephanie, Miriam, Max, and Zach. I learned so much from your different approaches (and shamelessly copied a bit of code here and there as well… 😇)!

Oh yes, and I’ll keep you posted on any updates I make to the project, for example, the dark mode toggle I am currently working on.

Who should you write for? Your friends and family? Your colleagues and peers? The people you look up to? Everyone in the community? Everyone on the Internet?

The answer? None of those people. You should only write for one person and one person only: you.

Me? But who would read the things I write only for myself?

Well, you would. Or, more precisely, all the people who are a lot like you. People who are a good match to your interests, your ideas, your values, and who can, therefore, relate to your stories. And on the Internet, more people than you think might be a lot like you.

There are, roughly estimated, about 4.5 billion people online, of which about 25 % speak English. That’s around 1.125 billion potential readers. If only one out of a thousand people is a bit like you and enjoys the work you create just for yourself, that’s still more than a million people. Of course, you won’t reach them all. But the more they love what they read, the more likely it is that they tell someone who is also a lot like you.

So, the next time you start thinking about your audience and whether they might like what you are writing or not, or what you can do to appeal to as many of them as possible, try this: do it like Tim Urban and picture a stadium full of people who are just like you*. Would they like what you write? What would they like to have a discussion about? What would make them laugh? What would fascinate them? Would they care if your English not be perfect? Would they be angry if you made a spelilng error? (I mean, if they really would, go ahead and correct those errors, but you get the point.) And then, do it like Chris Coyier and “punt out a thought early rather than wait until [you] have some perfect way to present it.”

Someone just like you might like it, share it, mention it at a meetup or conference, and, most importantly, might connect with you. Because ultimately, all of this isn’t about clicks, visits, and likes. It’s about human connection and building relationships while we share a bit of time together on this little blue dot. Right, Miriam?

—

*This is just one of the many interesting topics Julian Shapiro and Courtland Allen talk about in their latest Brains podcast episode about writing with David Perell and Tim Urban.

I love reading posts in which people talk about recent updates to their personal sites. It does three things:

1. It shows the person reading your post that you care about this little corner of the Web and that it is worth doing so.
2. It (most often) demonstrates why you picked a certain solution and how you implemented it. Maybe it even introduces your readers to a new idea they haven’t thought about yet. Most definitely, they will learn something new.
3. It acts as motivation for people to work on their sites, as well. And it also shows that you, too, might have experienced a few roadblocks and had to make decisions with an unclear outcome – regardless of how experienced you are or how many followers you have. The medium is the message.

Just recently, Hidde wrote an in-depth post outlining his approach to adding a dark mode toggle to his site. This made Kilian link to a post in which he explains his approach of adding a third option for the default system setting. And now, Ethan has written about his recent updates to his site, including, you already guessed it, his new theme switcher.

Last week, I released a little starter kit for Eleventy Plus Vite that already respects the user’s system settings for a light or dark mode via the prefers-color-scheme media query. The next thing on my list is to add a theme switcher. I’ll read all posts I can find, including Hidde’s, Kilian’s, and Ethan’s, with much interest and will then publish an update about this update here.

Why don’t you do the same with something you are working on?

One of the most fascinating things about the Web is how it has evolved. By that, I don’t mean so much the mind-blowing speed of growth, but rather how the foundational languages, APIs, and browsers have been able to adapt to an ever-evolving, ever-changing environment. With all the innovation going on, we somehow still managed to create robust foundational layers – like HTML, CSS, and JavaScript – that allowed for steady improvement but that also didn’t fail. And this is maybe the most amazing fact about the Web as a system of systems: it was resilient enough to persist and, at the same time, flexible enough to adapt.

For one, this is thanks to a lot of smart people who, despite all the arbitrariness involved in the creation of the Web, also made a lot of smart, foundational decisions. Like Tim Berners-Lee, the inventor of the World Wide Web, who recognized that the success of his invention would highly depend on how easy it would be for people to adapt it and who, therefore, not only based HTML on SGML, a language the folks at CERN were already familiar with, but who also decided that it would be sufficient for a hyperlink on the Web to go in one direction only, instead of being bidirectional, which would have made it much harder for people to link to a source.

But today’s success of the Web is also based on another principle: agreement. The agreement on certain standards that everyone will adhere to – the people writing the specs, the browser makers implementing them, and all authors writing code for the Web. Unlike in the dark times of the browser wars, what becomes a standard is today based on agreement. Agreement is what made it possible that new features like CSS Grid shipped in a short timeframe in all major browsers. Agreement on what should become part of the foundational technologies of the Web is also why we now have variables, aka Custom Properties, in CSS, or why we now can select DOM elements by querying for a CSS selector with Vanilla JavaScript (with querySelector and querySelectorAll) – something that had only been possible with jQuery for a long time. And only one of the many things you might not need jQuery for anymore.

Jeremy Keith has just given a fantastic talk at CSS Day about all of this: in “In And Out Of Style,” Jeremy not only talks about the foundational ideas and principles behind CSS, but also about how long-term trends always appeared and disappeared over time and how they have influenced and shaped the Web Standards we work with today. It is a wonderful talk, for one because of the way Jeremy tells the stories about the Web and its history, but also because of the underlying message: by hacking our way around the shortcomings of the Web, we influence what we agree upon and what ultimately becomes a standard. So, just like promoting the idea that Web Standards, CSS, or other best-practices are broken, is wrong, we should also not just accept things as they are. All the hacks, libraries, and frameworks that help us get things done today might well shape how the Web of the future looks like. As creators, we are actively influencing the future of the Web. What a great reason to become part of that feedback loop, share your thoughts and experience, and get involved in important projects that push the Web forward – like open-ui.org.

Even if you have been posting on your own site for quite some time, blogging regularly can still be challenging. Ask almost anyone who blogs and they will probably tell you the same: They would very much like to hit that publish button more often, but, somehow, it just doesn’t happen. One reason for that can be that we feel like every post has to be perfect, so we start fiddling with our text longer and longer. Another reason could be that we don’t find the time to write more often between everything else that is going on in our lives. And then, there are all the things related to writing itself that can hold us back, like finding something to write about in the first place, structuring our writing, editing the posts, and so on. And, just like with other habits, once you let the series break and more and more time has passed since your last post, it is getting even harder to publish again.

Here is a thought. Maybe, we are overthinking it. Maybe, the one thing we should care most about is just putting stuff out there. At least, this is the primary reason we have a personal website, right? We have it to document and share random thoughts, things we learned, and nuggets we found. If we don’t put stuff out there, why have a website in the first place?

When I think of people who publish regularly, three come to mind immediately. For one, there is Seth Godin, of course, who has been publishing a blog post every single day since 1548 or so. Jeremy Keith is another avid writer and a busy bee when it comes to posting all kinds of thoughts and links on this website – which really feels like an extension of his mind. But the guy who is the primary reason I sat down to write the post you are reading is Chris Coyier. Chris, who recently sold his blog CSS-Tricks to Digital Ocean, is now posting a lot on his personal site again, and it’s so inspiring and refreshing to see how he approaches it. Some posts are longer while others are short. There are a lot of posts about the Web and web technology, of course, but there are also others about health, mandolins, writing, teaching, identifying plants, good typography, and collections of random thoughts. It really feels like a personal site that is there for a reason.

So how do they do it? Do they sit down at their desk – very consciously – and take the time to write? You better believe they do. Do they write without worrying too much about what others might think or how polished their posts are? For sure. But, more importantly, it looks like they are enjoying the process of creating and have found a way to make publishing easy for them. And those two things might really be the key to publishing more often:

1. Enjoy the practice.

2. Make it as convenient and comfortable as possible to publish.

Now, there’s only one thing left to do to just put stuff out there.

Don’t overthink it – hit publish.

Maybe you want to publish a project but don’t want everyone to see what mess you created before your initial release. Maybe you want to hand over a Git repository to a third party who should not peek into your complete git commit history. Whatever the reason, here is how you can get rid of all past commits in a branch without losing your latest work.

Disclaimer: what follows are a few Git commands for the terminal. If you are a little bit like me, you probably prefer a GUI like Git Tower (❤️). But in this case, using the command line seems to be the fastest solution. Also, make sure to install Git on your machine. And probably don’t do this in an established repo that you share with a larger team as it might break stuff for them.

First, make sure you are in a your project root directory and checkout a new branch with the --orphan flag.

git checkout --orphan latest_branch

This will create a new, empty (“orphaned”) branch without any commits. Then, add all the files in your working directory:

git add -A

Now commit all your changes.

git commit -am "first commit message"

With all your work safely stored in the new branch, it is time to delete the old branch, e.g. the main branch:

git branch -D main

Now – and you probably already guessed it, right? – rename the current branch (the one you just created) into main:

git branch -m main

And finally, update the remote repository using the force of Git. Thanks to Frederic Hemberger for pointing out that --force-with-lease is probably better than using --force because it won’t overwrite the commits of others in case the branch has changed in the meantime.

git push --force-with-lease origin main

🙌🎉

I know all this might sound obvious to some of you and yes, I found this solution on StackOverflow, but I wanted to write it down to have it at hand the next time I need it. And maybe it is useful for you as well?

BTW, do you know what’s also useful when working with Git in the command line? Oh Shit, Git!

Maybe you are afraid to start writing because you think that you can’t write.

I don’t believe that’s true. Everyone can write. You have written letters or email before, right? You are constantly writing coworkers, friends, and family text messages or are chatting on your social networks of choice.

What I do believe, though, is that we are our most cruel critics. In reality, other’s often don’t care half as much about your writing as you do. Most of us aren’t born with the writing styles of James Joyce, Ray Bradbury, or Toni Morrison. But rest assured that even they started at some point, creating things that many would consider bad writing.

So, don’t hesitate to put bad writing on paper or on the screen. Here’s one good way to start: Write down everything you know about a random topic you care about in loose fragments. Just a bunch of unrelated words, sentences, or paragraphs will do. Write shitty first drafts. Resist the urge to polish at this early stage. Then look at all the mess you produced and give yourself a pat on the back. You now have material to work with! Try to make sense of it. What are the main points you want to make? What should people remember to get value out of your ramblings? What could you talk about first? What isn’t necessary for the main storyline of your post? Then begin to rewrite the post. Start to polish a few sentences here and there that don’t look right. Leave out the less important bits. Read it out loud. Correct what still sounds weird or might be unclear. Look at your draft with a beginners’ mind. Then hit publish even though you think you did a terrible job. Repeat.

School teaches us to avoid mistakes at all costs. This was useful back when making a mistake at the assembly line would mean you’d lose your thumb and the whole production would come to a halt. Those days are long gone. We now live in a world where making mistakes is slowly being recognized as what it is: the most natural way to learn by experience. Just look at how kids play and learn!

So let me correct my own mistake from the beginning of this post. Yes, your writing might indeed be really, really bad. Not only your drafts might be shitty. But that doesn’t mean that your views on things are less valuable. You will become better. You will grow.

What a great reason to start.

~

This post is part of a series:

• Unblocking Your Writing Blocks, Or: Debunking the Reasons That Keep You from Writing Your First Blog Post Today.

• Unblocking Your Writing Blocks, Part 2: I’m Not an Expert nor a “Thought Leader”

One of the reasons you’re not blogging on your own personal website might be that you’re thinking: “Why would people listen to what I have to say? I’m not an industry expert, after all.”

I get that. You might not work for the Apples, Googles, or Microsofts out there. You might not speak at meetups or conferences or publish articles at one of the online magazines everyone is reading. You might even think that what you are struggling with every day isn’t worth sharing at all. Who wants to read about your boring day-to-day stuff, right?

Well, I do. Who said that only so-called “experts” or “thought leaders” are allowed to share their observations and opinions? Everyone of us brings their unique set of experiences to the table and has something valuable to contribute, even if it is the tiniest of thoughts. You might think it isn’t worth sharing, but maybe you also underestimate how much you actually know and overestimate how much others know? Maybe, your opinion is even more valuable than that of a well-known public figure because your experience paints an unfiltered, more accurate picture of the reality of building for the Web or creating something special?

So, write about what you know. Write about the questions you have. Write about your successes. Write about what you learned. Write about what didn’t work. Write about why you think others might be wrong about something. Write about why you do the work you love the way you do it. Or, write about how you would love to do your work.

Once you start writing about something, you will also realize that explaining an idea to others is one of the best ways to learn and grow your own expertise. You don’t have to consider yourself an expert to start writing, but you might well become one along the way.

You’ll never find out unless you try.

~

This post is part of a series:

• Unblocking Your Writing Blocks, Or: Debunking the Reasons That Keep You from Writing Your First Blog Post Today.

I’m sitting in the ICE 205, one of the German high-speed trains, traveling back home after two days in Düsseldorf at Beyond Tellerrand, Marc Thiele’s lovely conference about design, development, the Web, and creativity in general. It was the first time I went to an in-person event since the beginning of the pandemic, and to say it was great to finally meet people again would be an understatement. It was outright amazing.

We all got used to meeting and collaborating online over the past two years, and many of our favorite conferences and meetups moved online, too. But while running community events online can definitely work and might have its own unique advantages – one being that you can join from anywhere in the world – there is still something missing from all those online experiences: connecting with each other in person. All the smiles, the stories, and different personalities. All the spontaneous discussions, inspiring conversations, and relaxed chats. Listening to the talks of others together, learning together, and laughing together. Meeting like-minded people, seeing old friends again, and finding new ones. Human connection. This is what's at the heart of Beyond Tellerrand and it's what makes in-person events so valuable and special.

Once again, I am returning home full of new insights, new ideas, new memories, and new energy. It was such a pleasure to meet all of you!

I don’t remember the exact moment anymore. But I remember that it was with a mix of disbelief and disappointment that I realized one day that there was no way to select the parent of an element in CSS.

Wait, what? This can’t be. Why?

Obviously, I wasn’t alone. Everyone who has ever learned CSS has probably found themselves in the same situation and asked themselves the same question: Why is it that we don’t have a parent selector in CSS? As Jonathan Snook described in an elaborate post back in 2010, it was not only because of performance concerns but also because of the way browsers render a document and apply the computed styles to elements: as a stream, one element after the other as they come in. When an element is rendered to the viewport, its parent is already there, including all its beautiful styling. Repainting the parent – and, consequently, all other parents – after the fact would then require another evaluation of all parent selectors. This, Remy Sharp agreed back then, would again be so expensive on the render engine that it wouldn't make sense to implement a parent selector.

So, we all accepted the inevitable and did our best to work around it. We added helper classes to our templates via back-end logic or with JavaScript in the frontend. And it somewhat worked. But in almost every project, there still was this one moment where a parent selector would have been the quickest and most “materially honest” solution.

:has has arrived

All of this changed last month when Apple released Safari 15.4 which, as the first browser, supports the :has() pseudo-class, which is one of the CSS Level 4 Selectors. “It was long thought such a selector was not possible, but our team figured out a way to highly optimize performance and deliver a flexible solution that does not slow the page,” Jen Simmons and Jon Davis wrote in the release notes.

There it is. A parent selector. But :has is not only useful as a parent selector. It also opens up a lot more interesting opportunities. But first, let’s have a look at how it works.

The :has pseudo-class takes a relative selector list and will then represent an element if at least one other element matches the selectors in the list. Sounds overly complicated when you write it down, so here is a basic example. Let’s say you want to select all button elements which include an svg element, like an icon. You can now write:

button:has(svg) { … }

Try the CodePen demo – and make sure to view it in Safari 15.4. ;)

Or, if you want to style an article differently if it has a headline inside that is followed by a paragraph:

article:has(h2 + p, h3 + p) { … }

You can also combine :has with the :not pseudo-class to select an element if it does not contain certain other elements, in this case, a headline:

section:not(:has(h1, h2, h3, h4, h5, h6)) { … }

It is also possible to use pseudo-classes like :hover, :focus, or :checked. You could style a form element when a checkbox inside has been checked, for example:

form:has(input[type="checkbox"]:checked) { … }

You could then also use the general sibling combinator ~ to change the styling of the form depending on how many of the checkboxes have been selected:

/* Two checkboxes are :checked… */

form:has(input[type="checkbox"]:checked ~ input[type="checkbox"]:checked) { 
  box-shadow: inset 0 0 0 0.5rem blue;
  background-color: rgb(150, 187, 235);
}

/* Three checkboxes are :checked… */

form:has(input[type="checkbox"]:checked ~ input[type="checkbox"]:checked ~ input[type="checkbox"]:checked) { 
  box-shadow: inset 0 0 0 0.5rem rgb(0, 160, 0);
  background-color: rgb(136, 233, 136);
}

Try the CodePen demo.

Although this demo might not be the most practical example, all this is still starting to get interesting, right?

Using :has to adjust a Grid

CSS Grid generally works from the container in and before :has, there wasn’t really a way to adjust the Grid based on what’s inside. What if we could use :has to adjust the CSS Grid layout of a container based on the number of elements inside of it? Here, so-called quantity queries can be useful. Heydon Pickering has written the ultimate article about them. By combining the :nth-child and :nth-last-child pseudo-classes inside our :has selector list, we can adjust the layout by “counting” the elements inside. Here is how we can target a grid with two elements inside, for example:

.grid:has(:nth-child(2):last-child) {
  grid-template-columns: 1fr 1fr;
}

So, if our Grid container has an element inside that is both the second child as well as the last child of our container, the grid should have two columns. The same also works with three columns:

.grid:has(:nth-child(3):last-child) {
  grid-template-columns: 1fr 1fr 1fr;
}

Finally, we can also create a grid layout that has four columns if the container has four or more elements inside. To achieve this, we select at least one element that is either the fourth or one of all following elements:

.grid:has(:nth-child(n+4)) {
  grid-template-columns: repeat(4, 1fr);
}

Here is a CodePen demo again.

As you can see, there are lots of amazing use cases for :has as a parent selector and it still feels like this is only scratching the surface of what people will come up with. :has lets us style elements based on whether the child of an element is selected, has focus, or whether it is present at all. And we can even target an element based on how many children it has. All this will allow for much more flexible components. Just think of all the variations of content and context that can exist inside a design system and you know how valuable this will be.

But wait, there is more!

:has as a previous sibling selector

Because :has accepts a relative selector list, you can also select an element if it has another element that follows it. Or, in other words, we can use :has to select the previous sibling of an element:

:has(+ .second) {
  background-color: darkmagenta;
}

Try it on CodePen.

Again, there are so many practical use cases for this! For example, you could style an image differently when there is a caption below it:

figure img:has(+ figcaption) {
  /* Do something with the image */
}

The possibilities of using :has in useful and creative ways to write more flexible and robust CSS seem endless. And as is the case with so many of the new features that are currently being added to CSS, I can't wait to see what other creative uses for :has you all come up with. One recent example is this brilliant demo by Michelle Barker, where she combines animated grid tracks with the :has selector.

Testing for support

For now, Safari is the only browser with support for :has. In the upcoming version 101 of Chrome, you’ll be able to activate it via the Experimental Web Platform features flag, however. While this is promising, it will certainly take a little while until :has is supported by the majority of browsers. In the meantime, we can once more use progressive enhancement to already use :has in browsers that support it. As Michelle Barker notes, you can test for support for :has with a @supports feature query using the selector() function:

@supports selector(:has(*)) {
  /* Code for browsers with support for :has */
}

Thus, you can target supporting browsers in a future friendly way. Because once :has is supported by another browser, your code will work automatically in this browser as well.

Do you have more ideas about how to use :has? Have you seen more interesting examples and demos? And will you start using it already? Let me know via Webmention, email, or Twitter.

Links

• Meet :has, A Native CSS Parent Selector (And More), by Adrian Bece
• :has() Has Landed in Safari, by Michelle Barker
• The CSS :has() selector is way more than a “Parent Selector”, by Bramus Van Damme
• The CSS :has Selector (and 4+ Examples), by Robin Rendle
• Using :has() as a CSS Parent Selector and much more, by Jen Simmons

Hans Zimmer just won an Academy Award for his musical score for “Dune,” and if you have seen the movie or listened to the soundtrack, you know why. Zimmer’s soundtrack for Denis Villeneuve’s adaptation of Frank Herbert’s classic sci-fi novel is an otherworldly masterpiece that combines Zimmer’s deep, gigantic trademark sound with unorthodox elements like whistling bamboo flutes, distorted guitars that sound like bagpipes, actual bagpipes, scraping metal, and synthesized, rumbling drums. The result is a mysterious, menacing, and captivating soundscape that defies comparison. Disturbing in its beauty, enchanting in its intensity.

When Zimmer was asked to write the music for Dune, one of the first things he knew was that he didn’t want to create the next classical orchestra soundtrack for a science-fiction movie. Instead, he had a certain idea of a sound in his head that would match the setting of the story. A story that was supposed to happen in the future, in a different culture, and on a different planet. So he set out to invent new sounds by using and combining existing instruments in unconventional ways and by even inventing instruments that didn’t yet exist. He worked with an instrument sculptor who builds instruments out of metal, distorted human voices with a compressor beyond recognition, and asked his musicians to play their instruments in the most unusual ways. “Don’t play it like the flute,” Zimmer said to his flutist Pedro Eustache, “Play it as if it was the wind whistling through the desert dunes.”

Why am I telling you all of this? Because no matter what you love to create, there is something to be learned from the way Zimmer approached this project. We are all striving to create work that is novel, innovative, memorable, and inspiring. To get there, however, we tend to focus on getting things right, on avoiding mistakes, on “being professional”. Yes, it is important to have the commitment, dedication, and attention to detail of a professional. But being right? That will only take you so far. What is much more important is to approach the problem in front of you with curiosity and an open mind. With an urge to explore what can be found beyond the ordinary, beyond the right way of doing things. If you want to create something that nobody has come up with yet, it is important that you try out all the crazy ideas others are afraid to try, that you build prototypes, improvise, and freely play with the materials and the technologies you have at hand.

You might not know where this play will lead you. You will discover that some things work and others don’t. You will run into dead ends and discover other paths that open up before you. You will have to abandon some of your ideas while new ideas are born. To discover something totally new, you need to play this game as unafraid and reckless as a child. Play it loud or quiet, fast or slow, alone or, even better, in a team.

Just make sure you don’t play it like the flute.

Hans Zimmer on technology and music:

“It took a while for us to figure out how to actually use this. You have to learn technology in one way or the other. And I don’t mean by reading a book […] or by going on the Internet and spending a bit of time. It’s a more instinctive type of learning where you figure out how far you can push the thing. Where is the sweet spot?”

Why is it that although we are now in the millions building and creating for the Web, only very few share their knowledge and experience on their own websites? Or, in other words: Why doesn’t every one of us have a blog?

Zach Leatherman asked this question on Twitter the other day and added: “can you imagine knowing everything you know and not sharing it? It’s a little selfish when you think about it.”

Zach was teasing, of course, but the responses that followed painted a pretty accurate picture of why it is so hard for many people to publish on their sites: There are a million reasons to not even start.

But many of the reasons holding us back aren’t actually the blockers we think they are. So why not have a look at the most common ones and debunk them, one blog post at a time? Written from the perspective of someone who hesitated for more than 10 years until he finally started his blog. Someone who has written quite a few posts in which he promises to “write again more regularly (promise!)”. And someone who now believes that starting to write on his site was one of the best decisions of his life.

All of those thoughts and worries were floating around in my head at some point as well. And many remain to be regular guests at the writing table.

Let’s start with one of the most obvious ones:

1. I don’t have a large following or audience. Nobody will read my blog posts anyway.

Of course, you don’t have an audience. Your writing doesn’t exist out there yet. But does it even matter? The first thing you have to do if you want to publish work on your site is to let go of the idea that the more people read your articles the better your articles – or you as a writer – are. Quantity is not the same as quality or value. Yes, it is great when a lot of people read what you have to say. But far too often, we measure success only by looking at the number of visitors or page views, while instead we should be looking at how valuable our posts can be for other people. An idea that I like a lot in this regard is the one Sara Soueidan shared in her post “Just Write”: “Even if only one person learns something from your article, you’ll feel great, and that you’ve contributed — even if just a little bit — to this amazing community that we’re all constantly learning from.” Even if only a few people read your post, it can have a profound impact on them – and on you.

Yes, you will probably start by writing into the void, not knowing if anyone reads your articles or cares at all. View it as a chance to practice, to make mistakes, and to get better. This is your chance for unlimited bowling and your chance to learn what kind of writing brings you joy. And if you end up writing things that people like, great! Over time, more and more people will take notice.

~

What are some of the reasons that keep or kept you from getting started? Let me know via Webmention, email, or Twitter. And make sure to subscribe to my RSS feed to not miss the next post debunking reason number two: “I’m not an expert nor a ‘thought leader’”.

Over the first couple of days of 2022, I read a lot of year-in-review posts, like Michelle’s, Dave’s, Hidde’s, and Jeremy’s, to name a few. What a pleasure to read about such a great variety of different perspectives and realities! Thank you, everyone.

In my case, last year was in many respects different than most of the years before, not only because of the ongoing pandemic. For my family and me, 2021 was a year full of changes. The most breaking of all: We spent the last weeks of the year in our new home – our biggest project to date and as indefinitely rewarding as exhausting. Our children now go to a different school and kindergarten, and although we stayed in the greater area of Stuttgart, Germany, we still moved quite a few kilometers away from close friends and family. With such change always comes uncertainty: How will our life turn out with all the new things to digest and the new paths to take? It takes time to get used to new, unfamiliar surroundings. Not only inside the house but also outside. It takes time to identify what works and what doesn’t, now that the familiar world that seemed controllable and predictable is gone. It takes time until a new home really becomes your home.

Now that 2022 is a few weeks old and I've had some time to process this milestone, it finally feels like things are getting back to a new – but exciting – normal. So I figured I’d start this new chapter with my more than over-due year-in-review post that somewhat draws a line under the last year. But instead of listing all projects, workshops, and other accomplishments like in previous years, I want to look ahead.

I will continue to give remote design workshops in 2022 for and with the Adobe XD team in even more formats as part of a growing international team of designers. (If you are interested in a workshop for your team, let me know. 😉) I will continue to teach interface prototyping at the Muthesius Academy of Fine Arts and Design in Kiel. I might read a couple of books (just like last year, most of them in audio form) and write about them here. And I certainly won’t stop working as an independent user experience designer and design engineer for design agencies as well as my own clients. Last year, all of this was heavily disrupted by the final weeks of construction of our home where I stopped writing on my personal site altogether to focus on the remaining client projects as much as possible. Something which, although I had expected to be much more busy than usual, still took me by surprise.

I have a lot more planned for this year now that things have calmed down a bit. Above all, I’m looking forward to getting back to writing on this site. But at the same time, I am very excited to be in my new home office now. It is the first time in years that I have a dedicated little office space at home with a real desk. A real desk! And a door I can close! So I spent quite some time setting everything up so that it is a comfortable place that works just as well for teaching and running remote workshops as for uninterrupted periods of client work or writing. The first month of 2022 already felt like a very good start. It feels like I’m finally back on track.

There still is a lot to do in and around the house. We still don’t have baseboards in most of the rooms. We still don’t have a dishwasher (thank you, global chip shortage). We still don’t have a garden. So 2022 will certainly include a few more interesting tinkering projects away from the computer for me. But I also can’t wait to create, build, and share for and on the Web again this year. There are so many amazing things happening in web design and development which I am so excited to dive into now that I will have more time for it again. And, I’m eagerly looking forward to everything all of you will create and share on your personal sites, in your podcasts, talks, and everywhere else.

Here’s to everything we change in 2022. I couldn’t be more curious!

30 years ago, on August 6, 1991, a computer scientist working at CERN introduced a project to the public he had been working on for several months. The project, as he described, combined “the techniques of information retrieval and hypertext to make an easy but powerful global information system”. The name of the project: the “World Wide Web”. “Try it”, Tim Berners-Lee wrote in his message on Usenet. And we did.

Over the past 30 years, the Web has grown up. But just like with every other new medium, we first had to overcome our limiting views and habits from the past. Because like every other medium that came before it, the Web is different.

The Web is ever-expanding.

The Web is device-agnostic.

The Web is unpredictable.

The Web is evermore standardized.

The Web is non-linear.

The Web is flexible.

The Web is responsive.

The Web is a playground.

The Web is open.

If you have been around since the 1990s or early 2000s, you know all of this. You have experienced the early years of wild and rampant exploration and experimentation. You also marveled at the fast pace of the industry with companies growing like fury just to be insignificant or even out of business a few years later. You have learned to dance with the ever-changing nature of the Web and you’ve seen web standards emerge from a soup of different approaches and philosophies. You have seen Flash come and go. You witnessed the rise of the blogosphere, user-generated content, and Social Media. And regardless of what your individual contribution was, (even if it was the Spacer GIF) we all made the Web what it is today.

There is also a lot to not like about today’s Web. No wonder many people feel nostalgic about the early days. But while 30 years can feel like a lot of time and things seem to be set in stone, it is important to remember that the Web is still in its infancy as a medium and as a set of standards and technologies.

When cinema was 30 years old, people were still watching silent films in black and white. It was only in the 1920s and 1930s when the use of sound and color – at first two colors and then even three (“Technicolor!”) – would become mainstream. No sound and color. After 30 years. This is where we are with the Web. We have left behind the first phase of imitation and exploration that cinema underwent as well. We are standing on the shoulders of giants (called web standards) but we are still just getting started.

What if the 2020s will be for the Web what the 1920s were for cinema? What if, both in terms of artistic creative expression and technological advancements, the best is yet to come? I have no idea what the web will look like in another 30 years. But I am sure that we will look back at the first 30 years of the Web like we look back at the silent era in cinema today: as the formative years of a medium that was about to evolve to even higher heights.

The Web has always been about what each and every one of us contributes. And contributing is easier and more important than ever. So let’s not leave the future of the Web to big tech alone. Inclusiveness, accessibility, performance, security, usability, decentralization, openness – in almost all areas, the Web is far from done. I can’t wait to see what the next 30 years on the Web will bring. Let’s shape them together.

~

If you are new to the Web or would like to learn more about its history, there is a marvelous newsletter by Jay Hofmann called The History of the Web. Jeremy Keith also read it on the ShopTalk Show podcast. Make sure to give it a listen!

It was about the same time last year that I decided to change something. I hadn’t written and published as many posts on my site as I had wished to get done. And it was nagging me. If this site was meant to be a place of reflection and experimentation, if it was supposed to be my personal home on the web, why didn’t I put in the effort and write more often? Why didn’t I share my struggles, my experiences, and little insights and inspirational bits that might help someone out there on their way? So I decided to start a 100 days of writing challenge. After 64 increasingly not-so-daily posts, I declared the experiment a failure. But one from which I learned a whole lot.

Well, here we go again. It is July 2021 and I haven’t published a post on this site since April. And once again, it bugs me. Yes, I had a lot of client work to do and prioritizing work – unless it is over family – is still not the worst of choices, especially in a pandemic. But it’s also far too easy to hide behind all the daily work instead of creating and writing. Isn’t it telling that I somehow still “found” the time to scroll Twitter’s timeline every day and watched more videos on tech and camera gear than I probably should?

It is incredibly hard to form a habit but it is even harder to sustain it. If you ever started your own thing – like publishing on your own website, just to come up with the most obvious example here –, you might know what I mean. One of the keys to writing regularly is to remember that you don’t need to write the perfectly elaborate piece all the time. If you care for something, even if it’s only the smallest nugget of insight, it is worth sharing it in whatever form the idea takes on. The posts that have the most positive impact are always standing on the shoulders of giant piles of bad writing and unfinished ideas. So it really doesn’t matter if you don’t bring it home all the time.

Results are always the outcome of a process. And it is this process that we should focus on. It is this process that we should own and that should bring us joy and fulfillment. So I will remember my own words back from when I started this notes section: I wanted to publish notes that are “quick, raw, unpolished, short, sometimes also a bit longer. Sometimes only an image, a hasty sketch, or a drawing. But always without the need to finalize anything.”

There is so much to write about every single day. Let’s get back to work.

(Well, maybe I’ll polish some of the posts. Just a little, tiny bit…)

He played the piano like no other. Literally. When legendary jazz pianist Thelonious Monk sat down at the piano and started playing, he would hit the keys with his fingers held flat, almost attacking them to produce the ringing, percussive sound he was known for. His compositions and improvisations were full of dissonances and melodic twists and he often divided single-line melodies between the two hands. Yes, at the time, Monk’s play was definitely different.

One day, he was listening to the radio when a music critic talked about how amazing Monk’s play was although he didn’t use “the right notes”.

Monk immediately grabbed the phone and left an unambiguous message for the radio host:

His answer was as blunt as it was true: If you don’t like how I play – fine! That’s your right. But that doesn’t make my way of composing or playing wrong. It’s just not for you.

The same is true for many other things we create. Take your personal website, for example. Your writing might not appeal to others. People might find it irrelevant or even dislike your style or your message, especially if you are writing about something new and unconventional. But if it’s important to you and if it contains a bit of yourself – and it certainly will –, whatever you write and publish on your site isn’t wrong. You are free to try out different formats, techniques, and styles. Write about what you think and care about. Find your unique way to express yourself.

A personal website ain't got no wrong words.

I love to watch my children play.

How they invent things and stories. How they jump into roles and, just as quickly, change roles again. How they interact and react to each other’s ideas and the twists and turns of their play. Let’s cook something! Oh, we are knights now! Can you see our horses? Aha, the wizard arrives in his spaceship! Where is his magic wand? And all of a sudden, an ordinary wooden stick turns into a magic tool. Problem solved! They can play like this for hours, inventing the most amazing, wondrous, and, in the eyes of us adults, silly and absurdly illogical things.

This is the way kids explore their surroundings and learn. They look at something and not only think about what is but also imagine what could be. Without rules, free from doubt, and free from fear. Then, they try out their idea and immediately find out what works and what doesn’t.

Over time, though, and certainly school and the world of adults is to blame here, most of us lose this ability to play freely. We learn about mistakes and are being taught how important it is to avoid and fear them. We learn that there are rules we have to abide by, some of them important, but some of them completely arbitrary. And we learn to stop being silly and playful and that being sincere, logical, and accurate is the way to succeed. We learn how to be productive workers who do things efficiently.

There is just one problem: In the rapidly changing world we now live in, especially on the Web, this mindset is not what’s needed anymore. In the industrial era, companies used to be focused on error prevention, consistency, and replicability. Preventing errors in more and more rigidly defined processes was key to increasing productivity and production quality and, consequently, being able to sell products at high margins that were better than the competition.

With the rise of computers, robotics, and the Web, however, there has been a fundamental shift towards innovation being the primary driver of success. Being efficient just isn’t the point anymore. It is how innovative and flexible you are and if you are able to solve problems in an ever more complex technological and social environment in a creative and novel way.

Our ongoing obsession with efficiency in the world of tech and design leads to many companies implementing ever more rigid processes and (design) systems. This might make some outcomes more predictable, but they will also become less innovative. This is because true innovation and truly new ideas will only happen when people have the freedom to explore creative solutions that seem unconventional or even unreasonable at first – and if they feel safe to do so. Or, as Sarah Drasner recently wrote on Twitter:

If the people on your team trust each other, it is much easier to talk about seemingly foolish ideas. In an environment where adults feel like they have permission to play, they will open their minds to new concepts and possibilities.

Building prototypes can be invaluable here, because it allows you to explore different solutions in a playful way, building and thinking with the materials at hand. When you build a prototype, you are doing the same a child is doing when she transforms a wooden stick into a magic wand. You’re imagining something new in a playful dialogue with the world around you. And because you are “just” playing, you are allowed to unlock your imagination and to go beyond what is reasonable or common. This is how new ideas are formed.

So the next time you are trying to solve a problem, give yourself permission to explore it freely. Build a few prototypes. Try out things with an open mind and without presumptions. And when someone walks by and asks what you are doing, just answer:

You know that feeling when you are leaving a movie theater after having watched a superhero movie and it almost feels as if you had superpowers yourself?

I just had a similar experience, but this time with a feeling of calmness, focus, and appreciation for my surroundings. What did I do? I finally watched Gary Hustwit’s documentary “Rams”.

Dieter Rams is one of the most influential industrial designers of the 20th century. As head of design at Braun and Vitsœ, he introduced a clean, elegant, and functional design language to a wider public and influenced generations of industrial and digital designers.

Today, Rams is also well-known for his Ten Principles of Good Design. Rams’ ten principles have been cited over and over again, to the extent that some people are now even making fun of the cult around Rams and his work. But looking at most of the design work today, many designers could still use a bit of Rams’ attitude towards building products.

It almost seems as if most of us still haven’t understood Rams’ principles at the core. His attentiveness, his care, his openness, his deep respect for people and the environment, and his willingness to constantly improve. But above all, there is the statement that opens and ends Hustwit’s film: “Less but better.” Not “less is more”. Not “good design is invisible”. Not “go fast and break things.” No. Less but better.

We are living in times of rapid social and technological change. In order to keep up with the pace, we seem to be always looking for more, especially on the Web. More likes, more visits, more content, more tools, more process, more speed, more efficiency, more data! This mindset might be the reason why the world of tech is currently struggling to live up to the responsibility that comes with influencing the lives of billions of people. When you always want more today, you don’t have time to think about the long-term impact and implications of your actions tomorrow. “Less but better”, on the other hand, strikes me as a useful principle because it helps us create things that are well thought-out, high-quality, long-lasting, and resilient instead.

Less stuff but better things.
Less traffic but better transportation.
Less complexity but better systems.
Less bloat but better code.
Less tracking but better content.
Less writing but a clearer message.

Design is the result of a series of decisions. But when you are working in a modern, flexible, and iterative way, there often are no upfront plans or requirements you can base your decisions on. You will need a set of basic principles to guide you and to tell you which way to go. A set of principles that defines what good design is for you. If you write them down, add “less but better” to the list.

It happened again. And I bet this has happened to you before, too. I’m talking of New Year’s resolutions. Every year we make them and tell ourselves that this time, yes, this time it is going to work, for sure. But then, suddenly, it is February, and nothing has changed. (Except for climate policy and basic decency being back in the White House. 🙌)

Unless we are really disciplined and somehow made it work before, we already know upfront about how hard it is to change our habits and to approach something new. It doesn’t even have to be something scary or insurmountable. To the contrary: The easier our goal sounds, the easier it is to trick ourselves into thinking that this time, because it is such a minor thing to start with or to stop doing, it will actually be easier to make a change. Far from it. The easier something seems to be, the less serious we take it. And so we end up prioritizing other things instead.

There are two ways to solve this. And if you know another one, please let me know.

For one, we can stop making New Year’s resolutions. I believe it was Derek Sivers who once mentioned that he even stopped celebrating New Years altogether. For him, the turn of the year is just an arbitrary date that even differs depending on which calendar you adhere to. So there is also no reason to believe that just by making a resolution on this random date will be any different than changing your diet on September 13th. Yet there is something to be said for certain dates having a bit more weight, both culturally and emotionally. For many of us, the turn of years is also a time of reflection. A rare opportunity to look at what you did and where you want to go next. It is a break that is set arbitrarily. But at least it is a break and an opportunity for change. And many families and especially children love it, too. So I’d rather keep it and do something else to change my habits.

Which brings us to the second, and maybe more effective step you can take, instead of just making the next vague resolution: Whatever you want to achieve, put it in your calendar. Don’t promise yourself that you will make it whenever you “find the time”. You won’t. Debbie Millman once said that if we come up with an excuse like “I did not find the time”, it really just means that something wasn’t important enough for us to give it a higher priority. So you want to write more regularly or start exercising again? Put a dedicated day and time for it into your calendar. If you can’t do it now, why would you be able to do it next week or next month? Make sure that when Wednesday evening comes, you know that this is your time to write. Or, three days a week, the first thing you do in the morning is some exercise. If you skip it from time to time, that’s okay, too. But if you do, make sure to get back on track the other day.

So guess who promised to write two articles a week and start exercising again in his year in review post and a post about his typical day…? Exactly. 😉 So I will now practice what I preach an add two things to my calendar: A dedicated time to write. And two morning workouts, let’s say on Tuesdays and Fridays. Let’s see how it goes.

But maybe, I should not tell you about this.

Colin Devroe kicked off a series of “My Typical Day” posts. He tagged Dan Mall (and Chris Coyier, Jeremy Keith and others) and Dan tagged Sara Soueidan (and Dave Rupert, Rob Weychert, and others) and Sara tagged me (and Cassie Evans, Anton Sten, and others).

Although I’ve never been a timeboxing champion or productivity nerd, I find it fascinating to see how other people structure their days and balance professional work and the private parts of their lives. It’s interesting to see how different our schedules and approaches often are, although we might do work in similar areas. And I particularly enjoy noticing those little details that might be worth trying out yourself. So I’m happy to play the game.

As is the case with almost all of us, my typical day has changed since last February. But then again, because I already used to work remotely a lot before the pandemic, there are things about my schedule that haven’t changed at all.

• 7:00 – I get up to make coffee for my wife and me. On regular school days, I have to get up a bit earlier, at about 6:30.

• 7:30 (pandemic schedule) – The kids are awake. I prepare breakfast for them and, most of the time, for the adults, too.

• 8:00 – I take a shower. Important: I end the shower with about 2–3 minutes of cold water. I know that this sounds very Tim-Ferriss-y. But I feel so much better thereafter and ready to start the day refreshed, that I don’t want to miss it. Also, I’m telling myself that it has positive effects on my migraines – but who knows. 😉

• Between 8:30 and 9:30 – Work starts. It’s also time for the second (or third) coffee. Depending on the projects I have, I might start to do conceptual UX work, visual design, prototyping, or front-end development. If I can, I will start the day with smaller but more urgent or lighter tasks. For one, to get the feeling of having accomplished something early in the day. But it also helps to tackle the more demanding and time-consuming tasks with more serenity, because my head is freed from the most pressing stuff. This can also backfire, though, when there are a lot of smaller tasks and if, for example, even more “urgent” todos like bug fixes or client feedback roll in. When this happens, it is important to say “no” or at least to clearly communicate when you do not have the time to work on something immediately without sacrificing progress on other things.

  On most days, I have a first high of productivity at about 10 am. And if I am lucky, I am able to do deeper, focused work until about 12:30. Let’s be honest, though: Getting into the “flow” with two kids at home and messaging and meetings with coworkers and clients in Slack, Webex, Teams, Hangouts, Trello, Jira, Confluence, Skype, Twitter, and email? Good luck. To everyone who did not work from home before the pandemic: This is not how remote work usually is!

• 12:30 – Lunch break. On most days, I prepare lunch for my family while listening to podcasts or an audiobook. And I deeply enjoy that we often extend the lunch break a bit to talk and recharge for the afternoon.

• 14:00 – Work continues. Again, it takes me about an hour to ramp up again and at about 4pm I am most productive.

• 18:30 – More food for the hungry mouths. And once again a lot of talking and laughing at the table.

• 20:00 – Time to put the children to bed.

• 21:30 – Leisure time. Well, kind of. I’ve almost completely stopped watching TV or Netflix. When I do, it’s usually football (aka soccer) or a movie together with my wife. I also don’t play games anymore. Instead, I might read a bit from the RSS feeds in Reeder, scroll through Twitter (and need to force myself to STOP IT AGAIN!!!), do some light research on a topic that interests me, or watch a few videos of talks and other interesting things. Sometimes, I work on my website or other small, “useless“ projects.

  But most importantly, I regularly use the evening hours to write. How much I get done depends a lot on my energy on that particular day. But I try to sit down to write as often as I can, because I’ve found that it is important to start in the first place and to make this a habit.

• 0:00 – Bedtime. A few years ago, I used to stay up until two or three in the morning, but I feel like I’m too old for that now. :) I still can’t let go of my smartphone, though, and so I often fall asleep at about 1 am.

A few things worth noting:

For one, I am far from having a fixed schedule. I even think it is healthy, at least for me, to grant myself the freedom to deviate from a the schedule above. When life happens, when I am running an online workshop, or when work is just not fitting into a regular schedule, it’s important to be flexible enough to react to different circumstances – especially in the current situation. This flexibility is also one of the things I enjoy most about working as a freelance designer.

I envy people like Sara Soueidan or Dan Mall who get up really early to do creative, meaningful work in the calmer morning hours before the busyness of the day kicks off. And although I’ve always been a night owl, I am currently starting to enjoy going to bed and getting up a little earlier. Maybe, I am on my way to becoming more of a morning person while I’m approaching my forties? Who knows.

Also, you might have noticed that there is no time for exercise in my typical day at the moment. This is not good and something I want to change again soon.

–

What about you? Do you have a typical day you’d like to share? If you do, then let me know via Webmention, email, or Twitter.

I am also tagging Diana ilithya, Michelle Barker, Manuel Matuzović, Simon Collison, and Zach “CLI” Leatherman.

Hip-hop has lost one of its finest artists to ever touch the mic and an MPC. Daniel Dumile, better known by his stage name MF DOOM, passed away on October 31, 2020, at the age of 49.

Dumile, who performed in a metal face mask, was a child of the Golden Era and a master of his craft. A hero of underground rap, he was known for his densely constructed, genius rhyme schemes and his raw, elliptical lines. In his obituary for The Guardian, Stevie Chick writes: “In a genre where ego was all, Dumile remained laid back but still dominated as he broke tempos and rules. His lines dripped black humour and stoner-friendly cultural references, but the mind assembling them was wicked sharp, stacking up multiple rhymes like Super Mario power-ups, and fond of meta-textual intrigue.”

The name MF DOOM will always be inextricably linked with “Madvillainy”, the legendary album he released in 2004 together with producer Madlib, who contributed the beats and samples creating the perfect sound for DOOM’s rhymes. Sasha Frere-Jones (the older brother of type designer Tobias Frere-Jones) attests DOOM in a review in The New Yorker that he “takes a deep pleasure in words: alliteration, internal rhymes, and pure sound. The point of ‘Madvillainy’ is largely poetic—celebrating the language of music and the music of language.”

Daniel Dumile was a writer's writer and a deeply committed artist. At a time when the world was listening to the popular hip-hop tracks of Bad Boy Records, Aftermath, and Def Jam, Dumile put on a mask so that people would focus on the lyrical content and the stories he wanted to tell. He stayed true to himself and his practice and inspired a generation of artists with his dedication and ingenuity. Creators of all disciplines could use some of that today.

Rest in power, MF DOOM. You will be missed.

–

If you want to learn more about the life and work of Daniel Dumile, here you go:

• The Mask of Doom, by Ta-Nehisi Coates
• MF DOOM, Masked Mythmaker, by Will Gottsegen
• MF DOOM - Interview with the Masked Villain | Red Bull Music Academy Lecture
• MF DOOM - The Man Behind The Mask Documentary

So, that was 2020. First of all, I hope that you and your loved-ones are well, that you had something to do this year that brought you fulfillment and a sense of purpose, and that you haven’t been affected too heavily by COVID-19 and the lockdowns that were both financially and emotionally challenging for so many of us.

My mother, for example, “picked” one of the most weird and tough years as the last one running her pediatric practice before transitioning into retirement. And just like her, countless people in the medical sector not only had to fight the virus and their own fears of being infected, but also those irresponsible and disrespectful idiots who seem to think that we are living in a video game where reality and physics are a matter of opinions that can be debated on social media. To all those anti-maskers: You are in the minority and you are wrong. To all the healthcare workers, all those countless people in system-relevant jobs, to all volunteers, and to everyone who just stayed at home and acted responsibly: Thank you! 💚

But as challenging and tough this year might have been, there are also many things that should give us confidence looking forward. Historically, many great initiatives, companies, and movements had their origins in times of crisis. It is when we have to adapt to difficult situations when we focus on what is really important and, often out of necessity, are willing to take risks and make the changes necessary to reinvent the status quo. I will therefore take a look at what I learned or what I believe might be some of the positive takeaways of this year.

UX/UI and Front-End Work

The main focus of my work was once more design and development work for the web. I contributed to several projects either doing conceptional work, interface design jobs, front-end development, or – and this is where I feel most at home – a combination of those areas. I was lucky in that most of my projects were barely affected by the pandemic. Many people I talked to had to fight much harder and some were even let go right at the start of the first lockdown. But with a few exceptions, the Web industry did well overall. And even for those who were hit harder, like shop owners or event organizers, the Web offered ways to compensate for the loss at least a little bit. Just imagine such a crisis in the 1970s or 80s and the dire consequences on a world economy and societies nowhere near as connected and flexible as today.

One of the projects this year included making a site fully accessible that has been online for a few years now. An accessibility audit – done by the unparalleled Joschi Kuphal – revealed lots of things to improve and I learned so much more about designing and implementing accessible solutions for the Web in the process. For example, how important it is that the whole team knows what it takes to make a site accessible. From project management to design to development to content editing – everyone needs to know that a) a11y is a thing and b) what to pay attention to to make the site more inclusive.

In-person Workshops Online Workshops

When it comes to workshops, my year started with a visit of Interaction 20 in Milan for and with the Adobe XDI team. We had a lot of fun together, met many new and also some familiar faces, and I even went for a midnight run through the streets of Milan.

Then, the pandemic hit. Shortly after we had all returned home, Italy saw a first sharp rise of new cases and it became clear that giving in-person workshops would not be possible for the foreseeable future. So, over the course of the following weeks, our team around Andre Jay Meissner developed an online version of our Adobe XD design and prototyping workshops and we have since delivered dozens of “XD Immersive” workshops. I myself ran a total of seven workshops and learned a ton along the way. Not only about how to interact with online audiences and explain design and prototyping concepts live into a camera, but also about the technical aspect of running those online events. Microphones, lighting, cameras, switchers, preamps, and software, for example, are only a few topics where you can spend ~~hours~~ days in the infamous YouTube rabbit hole. But then again: what an incredible platform YouTube is to learn about all those things! My plan for the new year is to continually upgrade my tech setup so that the quality of my audio and video improves even further. Not only for the Adobe workshops but also for my general workshops on modern responsive design (at the intersection of design and code) and prototyping for the Web. If your team would love to take part in such an event, let me know!

Teaching

2020 was the eighth year that I taught Interface Prototyping at the Muthesius University of Fine Arts and Design, Kiel. This time, the seminar had to take place via zoom. Just like for other teachers and professors this was a first for me. But although I prefer to be in the same room with the students, it worked out well overall and I am looking forward to the next semester.

Writing

I started a writing challenge at the end of May with the ambitious goal of writing and publishing a post every day. As was to be expected, this turned out to be super hard. After I managed to publish daily for about 40 days, the frequency started to deteriorate. I ultimately lost my streak somewhere towards the end of October, when my regular design work just turned out to be more and more time consuming. But still, with a total of 70 posts published on my website, it turned out to be my most productive year in terms of writing yet. Here are some of my most-read articles of 2020:

• How I Structure My CSS (for Now)
• The Thing With Leading in CSS
• Milton Glaser – Ten Things I Have Learned
• Painting With the Web
• My Visual Studio Code Setup: Extensions and Themes
• :focus-visible Is Here
• Lateral Thinking With Withered Technology
• The Curse of Knowledge

At the end of the year, Chris Coyier asked if I would like to contribute to his end-of-year series and so the year ended with my debut article on CSS-Tricks. I answered the question “what is one thing you learned about building websites this year?” with a little love letter to the personal website: Make it personal.

I love writing a lot and to me it feels like 2020 was the year where I truly made writing part of my practice. For 2021, I am starting a new challenge that might fit my schedule a bit better: Publish at least two blog posts a week. We’ll see if this is a frequency that is more sustainable and that also allows for some time to edit the post more thoroughly.

Reading (Audiobooks)

Last year, I started listening to audiobooks again and I continued to do so in 2020. I read a lot for and at work so listening to audiobooks while cleaning the apartment or cooking is a welcome change. Some of my favorite books this year:

• The Hitchhiker's Guide to the Galaxy, by Douglas Adams, read by Stephen Fry (!)
• Exhalation: Stories, by Ted Chiang
• Radical Candor, by Kim Scott
• The Mind and the Brain: Neuroplasticity and the Power of Mental Force, by Jeffrey M. Schwartz and Sharon Begley
• Brain Rules, by John Medina
• Range: Why Generalists Triumph in a Specialized World, by David Epstein
• Talk Like TED, by Carmine Gallo
• Trillion Dollar Coach, by Eric Schmidt, Jonathan Rosenberg, and Alan Eagle
• Steve Jobs, by Walter Isaacson
• Feck Perfuction, by James Victore (Can’t get enough of this one.)
• The Catalyst, by Jonah Berger
• Influence: The Psychology of Persuasion, by Robert B. Cialdini
• The 7 Habits of Highly Effective People, by Stephen Covey
• Tribe of Mentors, by Tim Ferriss
• Hell Yeah or No – what’s worth doing, by Derek Sivers
• The Practice, by Seth Godin
• Writing Tools: 55 Essential Strategies for Every Writer, by Roy Peter Clark

2021

For my family and me, the new year will bring a lot of change which I am already looking forward to a lot. Next autumn, we will move into a new home. This means that we will have to relocate and settle down in a new environment. But it also means that we will finally have a home that is ours. And I get to set up a sophisticated home network. 🤓 I’ll keep you posted.

The arbitrary date that is New Year’s Day will not wipe away everything that was bad about 2020. But looking forward, I believe that we will see a lot of progress and positive change as a result of the difficult year that was 2020. Humans are now able to develop several vaccines against a highly infectious virus within a year. Remote work is blossoming and people will not want to give up this newly gained flexibility. 2020 also showed us how valuable some things we usually take for granted are. And 2020 showed that the only way forward is to care, to trust each other, and to work together on what is truly important. One of those challenges ahead is to fight climate change. Once COVID is overcome, this should be our top priority. Even small changes matter here.

I wish you the best of luck with everything you do in 2021. May it be a healthy, happy, and successful year for you and your loved-ones. Happy 2021, my friends! 🎉

We all want to make the right decisions. Not only because we want to be successful, but often simply because we want to avoid the negative consequences of making the wrong decision. We are risk-averse beings. So we put a lot of emphasis on the decision itself. We collect information, analyze, evaluate, discuss, and ponder. Just to make sure that we will definitely and undoubtedly pick the right option.

The truth is, though, that it is incredibly unlikely that we might ever gather enough information to make a truly informed decision, a decision that is definitely the right one. It just isn’t possible, because the future is impossible to predict and full of unknowns and variables we can’t control.

Instead of focusing solely on decision making, a much better strategy might be to get into a position where you end up with better decisions in the first place – regardless of which option you choose. How? By creating more and, most importantly, better options. This will inevitably increase the likelihood of making better decisions.

There is no guarantee, of course. Bad decisions are still very likely. And so, as Stripe CEO Patrick Collison suggests in this interview with Tim Ferriss, much more important than making a particular decision, is the ability to correct course once you realize that the decision might have been wrong. However, this is easier said than done. Once a decision is made, once a plan is in place, it becomes much harder to recognize that we’ve been wrong. All the time, money, and effort that went into making our idea work? It’s all wasted. But is it, really? Look at it this way: You made your decision with the best information you had and with the best of intentions. Now that you gathered enough information to know it was the wrong decision, you can focus on the right option instead and start investing into building the right thing and solving the right problems.

-

This is the 64th post of my 100 days of writing series. You can find a list of all posts here.

Have you ever seen Gerhard Richter painting?

It is phenomenal to watch. He might start one of his large, abstract paintings by carefully applying oil paint to the canvas with a thick brush. Then, he begins to scrape, smear, or add new layers of paint with a large, home-made squeegee. After each change, Richter pauses, takes a step back, and looks at the result: What did just happen with the picture? What composition has come about? Where have interesting parts emerged? What is the next move that might bring the piece one step closer to completion? And which action would be a mistake? There is a lot of intention and carefulness in this process, yet Richter equally respects the results of accident and chance. He lets go of a certain kind of control to let things happen that are surprising and exciting. But at the same time, Richter always exerts enough control to influence the result. He decides what to keep and what to destroy. It is the ultimate creative process: a constant dialogue.

So much about this reminds me of designing and building for the Web: The unpredictability, the peculiarities of the material, the improvisation, the bugs, the happy accidents. There is one crucial difference, though. By using static wireframes and static layouts, by separating design and development, we are often limiting our ability to have that creative dialogue with the Web and its materials. We are limiting our potential for playful exploration and for creating surprising and novel solutions. And, most importantly, we are limiting our ability to make conscious, well-informed decisions going forward. By adding more and more layers of abstraction, we are breaking the feedback loop of the creative process.

Ask any artist, musician, or writer and they might tell you that this conversation at the heart of the creative process is what makes their work special and so fulfilling. No piece of art exists in its final form in the head of the artist before the first brush stroke is put on the canvas. No musician has a full piece of music in her head without a conversation with instruments or the score. And no novel is done before the first word is put on paper or a computer screen. Constant reflection and refinement are key to creating any piece of work. This is what lets creators of any profession learn and grow, and, ultimately, achieve mastery. And the same is true for any user interface, design pattern, piece of code, or content on the Web.

There are a lot of amazing new technologies just around the corner. CSS Houdini with the Paint API, for example, or various other Web APIs like the WebXR Device API for creating augmented or virtual reality experiences or the Web Speech API to design voice user interfaces. If we want to explore and create amazing things with those new technologies, we need to be able to have that creative dialogue with the materials in front of us. And in most cases, this means: We need to work directly in the browser. We need to paint with code.

So maybe this is the perfect time to get your hands dirty with some real paint and finally learn to code? Or, if you are a developer, to inform yourself about white space, contrast, color theory, and web typography to be able to take that step back and look at your work. And even if all of this isn’t an option for you and your team at the moment, you can still look for ways to bridge the gap between design and development and to enable that creative dialogue. Carry out little experiments together, dissect examples together to get an idea of what is possible, build prototypes together, and design and decide in the browser together.

We all love to design and build for and with the Web. Yet far too long we have adhered to ways of working that are residues of the print era. This served us well for a while, but the Web isn’t like that anymore. The canvas has changed. The materials have changed.

It is time we finally start painting with the Web.

❦

Interviewer: How do you know when [your paintings] are finished?

Richter:

-

This is the 63rd post of my 100 days of writing series. You can find a list of all posts here.

One of the most important features of a website that is built with accessibility in mind is that it can be navigated with a keyboard. Most blind users and many users with motor disabilities rely on keyboard navigation, either with a standard keyboard or with a device that mimics the functionality of a keyboard. Providing strong visual indicators that highlight the element that currently has keyboard focus is therefore indispensable. In CSS, the focus styles for an element can be changed via the :focus pseudo-class.

a:focus {
  outline: 3px solid blue;
}

Hiding Focus Styles Is Bad Practice

Besides accessibility requirements, there are also design considerations to be made, though: For some users, a strong visual focus indicator once they click an element with a mouse or touch it with their finger can be irritating or feel “clunky”. Often, the focus highlight is only visible for a short time just before a page change occurs. This is an additional visual change in the interface that users have to process and understand. Without the knowledge that this highlight around the element is actually an accessibility feature, people might be distracted or irritated. Sometimes, it is even perceived as an error. And while some designers certainly are far more sensitive to the aesthetic qualities of an interface than its users – and would be well-advised to get used to a bit more accessibility-oriented, contrasted designs –, it is still relatable that focus indicators might feel like an intrusive break in an otherwise carefully balanced visual design if the designers missed to actively style them.

Many clients and designers, therefore, insist that developers remove the focus styles altogether for purely aesthetic reasons.

a:focus {
  outline: none;
}

Don’t do this. It is an uninformed decision that actively excludes people and should not be an acceptable solution in 2020 anymore. We have to do better. But how?

One way out of this dilemma would be to consciously design the focus state of an element so that it is perceived as a natural part of the transition from one state of the interface to the next. This, however, is not always easy or possible.

:focus-visible to the Rescue

Luckily, there is now another option: The :focus-visible pseudo-class. According to the spec, “the intent of :focus-visible is to allow authors to provide clearly identifiable focus styles which are visible when a user is likely to need to understand where the focus is, and not visible in other cases.” Or, in other words, it lets you show focus styles only when they are needed, using the same heuristic that the browser uses to decide whether to show the default focus indicator:

/* Hide focus styles if they're not needed, for example, 
when an element receives focus via the mouse. */
:focus:not(:focus-visible) {
  outline: 0;
}

/* Show focus styles on keyboard focus. */
:focus-visible {
  outline: 3px solid blue;
}

In October 2020, Chrome 86 shipped with support for :focus-visible, Firefox also supports it since version 85, and older versions of Firefox support it via the :-moz-focusring pseudo-class since 2011. Support in WebKit is also coming, thanks to a recent initiative by Igalia. Edit: Support for :focus-visible shipped in Safari 15.4. So there is no need to hold back. You can start using :focus-visible now! Once more, progressive enhancement is your friend here. You can define regular focus styles for non-supporting browsers and then overwrite them for browsers that support :focus-visible.

:focus {
  outline: 3px solid blue;
}

:focus:not(:focus-visible) {
  outline: 0;
}

:focus-visible {
  outline: 3px solid blue;
}

You can try it out in this Codepen:

See the Pen :focus-visible Demo by Matthias Ott (@matthiasott) on CodePen.

Note that :focus-visible always applies in combination with :focus. So if you inspect it in Chrome’s Developer Tools, for example, make sure to tick both boxes to see the appropriate focus styles.

A Polyfill for Older Browsers

If you need to support a wider range of browsers, including Safari, there is also a polyfill. It simply adds a focus-visible class to all focused elements in situations in which otherwise the :focus-visible pseudo-selector would match.

Once the script is added to your page, the code looks much like in the examples above. The only difference is that now we are using classes to define the visible focus styles in our CSS:

.js-focus-visible :focus:not(.focus-visible) {
  outline: none;
}

.js-focus-visible .focus-visible {
  outline: 3px solid blue;
}

If you decide to use the polyfill, make sure to pay attention to how it behaves in combination with your existing focus styles. It might still be a valid choice to only use the polyfill until Safari also adds support for :focus-visible. But regardless of which method you decide to use, it is fabulous that we now have a solution to a problem that was often “fixed” by developers and designers by making websites less accessible. :focus-visible now offers a solution that is accessible and makes users, designers, and developers happy.

Further reading

• With :focus-visible, you can have focus styles when it makes sense, by Hidde de Vries
• The Focus-Indicated Pseudo-class: :focus-visible, W3C CSS Selectors Level 4
• Giving users and developers more control over focus
• :focus-visible and backwards compatibility, by Patrick H. Lauke
• focus-visible Polyfill
• Can I use :focus-visible CSS pseudo-class?
• Navigate using just your keyboard, by Dave Rupert
• Focusing on Focus Styles, by Eric Bailey

-

This is the 62nd post of my 100 days of writing series. You can find a list of all posts here.

Ethan Marcotte just gave a fabulous remote talk at SydCSS on the nature of design systems and the challenges of creating and maintaining them over time. Ethan managed to comprise so many of the things I’ve been hearing, noticing, and thinking about in such a concise and clear way I could never articulate it. If you are working with or planning to build a design system – and who doesn’t, these days – I can’t recommend this talk enough.

Four of the things Ethan talked about stood out to me. They often get overlooked yet are so important to get right if you want to make the best of your design system.

Visibility

Design systems and pattern libraries are a blessing in that they enable us to design modular systems. We can look at single components and design patterns individually and improve them over time. But very often, this design process happens in a vacuum. We focus a lot on the initial design of a pattern but it is difficult to say where and how the pattern is actually used in the wild by different teams and as time goes by. By making visible what the actual impact and real-world applications of a design system look like, it can be far better adjusted to the reality and needs of the organization. And for designers, it is easier to see everything that’s broken.

Context

One way to increase visibility is to look at design patterns in context. No pattern exists in isolation. It always shapes and is shaped by its environment. And on today’s Web, the number of possible contexts is endless. A component can be used on different pages and products, on different screens, in different browsers, with different content, or also be used by people with different abilities or cultural backgrounds. The more we respect this reality of varying contexts, be more robust but also flexible our system will become.

Prescriptiveness vs Flexibility and Exploration

Design systems are built to improve consistency and efficiency across teams and products. But while the focus on modularity and implementation is indeed improving consistency, this consistency comes at a price. Once established, design patterns seem to be cast in stone. This is because our components are mostly documented in a prescriptive way. This is how the component looks and behaves. And this is how it has to be used. It’s sink or swim. As Ethan notes, this prescriptiveness limits our design systems because it stifles creativity. What we should be looking for instead is to create systems that put design principles over specification and allow for exploration and the playful application of patterns within useful constraints.

Process and People

But regardless of how well-conceived our design system is, it is important to remember that it is a tool that is primarily meant to support people in making better work together. Ideally, a design system can foster collaboration and create a shared language. This will only work, however, if the system fits the processes of the organization and the way people work – and if we recognize that humans and the interactions between them are a core component of every design system. As Ethan emphasizes, it is only then that we can design systems that support the work that we want to do.

-

This is the 61st post of my 100 days of writing series. You can find a list of all posts here.

Over 120 years ago, an Italian engineer, sociologist, economist, and philosopher named Vilfredo Pareto made an astonishing discovery. He was looking at the distribution of land in Italy, when he observed that approximately 80 % of the land was owned by only 20 % of the population. When he looked at the data from other countries, to his very surprise, the same distribution applied. This observation, that in many systems 80 % of the outcome is created by 20 % of the causes, has become known as the Pareto principle (or 80/20 rule).

Over the years, it became clear that the Pareto principle doesn’t only apply to wealth distributions but that many other natural phenomena follow such a pattern.

In the NBA, 80 % of the points are scored by 20 % of the top players. According to Microsoft, 80 % of system crashes are caused by 20 % of the bugs. 20% of drivers cause 80% of all traffic accidents. And for many companies, 80 % of the profits are generated by 20 % of clients. Even if the distribution isn’t strictly 80 to 20 all the time, the general rule – that most results come from a small minority of causes – still applies to so many things, from internet traffic to student grades to general productivity.

What if we apply the Pareto principle to our design and code work? I don’t have any numbers to back this up but it matches pretty well with my experience: 80 % of a design is often done after 20 % of the time. Bringing your design to 95 % or even 98 % will then take considerably more effort. If you know that, you can purposefully direct your efforts to the things that really count instead of wasting time polishing things that might not be worth the trouble.

Or take design systems or websites as an example. If you have a bunch of components, there will always be a small number of components that are being used all the time. On almost every page of a website, for example. Other components, however, will only be used sparingly. This means that not all components are equally important. Improving the components that are being used more often will have a much greater effect on the overall quality of a system. Identify those important components. Nurture them and make them work really well. At the same time, pay close attention to which elements might be of lower importance and value – and maybe even get rid of them.

But be careful: Using the 80/20 principle can also be a trap. If everyone around you is only investing the 20 % to be good enough, you won’t stand out if you simply do the same. 80 % is not enough. Often, it takes unreasonable effort to make something truly special, and going the extra mile is worth it – you just have to choose carefully where you want to put your energy.

-

This is the 60th post of my 100 days of writing series. You can find a list of all posts here.

Una Kravets has written an excellent article about a feature that has been released with Chrome 85: The @property syntax of the Properties and Values API. The Properties and Values API is part of CSS Houdini, the next generation of additions to CSS allowing developers to extend the language directly at the engine level. With the @property syntax, you can declare a variable including a type, an initial value, and even control inheritance. This is how it looks like:

@property --colorPrimary {
  syntax: "<color>";
  initial-value: magenta;
  inherits: false;
}

The initial value ensures that if someone tries to give the --colorPrimary an invalid value that doesn’t match the type specified by syntax, like “20px” or “border-box”, there is still a fallback.

But there is more. The new @property syntax fixes a fundamental problem of custom properties: You could not animate them. While it was possible to animate a property that used a custom property, it wasn’t possible to animate the custom property itself because the custom property was read as a string.

Animating a background property, for example, would work:

button {
  --color: green;
  background: var(--color);
  transition: background .4s ease;
}

button:hover {
	--color: blue;
}

But not if you wanted to apply the transition to the custom property, --color:

button {
  --color: green;
  background: var(--color);
  transition: --color .4s ease;
}

button:hover {
	--color: blue;
}

With the new @property syntax, this now changes, because if you define a type (like length, number, percentage, color, and many more) for the custom property, the browser now knows how to transition it. The prime example that Una shows is that it is now possible to animate something that couldn’t be animated before: Gradients.

See the Pen Gradient Transitions with @property by Matthias Ott (@matthiasott) on CodePen.

When I played around with the feature myself, however, I noticed that using relative units like rems with a type of length did not work properly when I tried to calculate a font-size in Chrome 85. It worked well when I used an absolute length in px, though. Maybe I’m also overlooking something here – and if I am, please tell me – but it seems as if the new feature still needs a few more iterations until it fully works as expected.

See the Pen @property Custom Property Test: rem font-size by Matthias Ott (@matthiasott) on CodePen.

Once browser support has gotten better, the @property syntax might make many things around custom properties much more convenient. In particular when creating animations, the possibility to transition the computed value of the custom property will come in handy.

-

This is the 59th post of my 100 days of writing series. You can find a list of all posts here.

It doesn’t happen every day that a new image format comes along. So it’s not surprising that people are excited that Chrome 85 has been released with support for the new AVIF format. AVIF (AV1 Image File Format) is an open image format based on the AV1 video format that was developed as a modern alternative to JPEG. And it is indeed impressive: The compression is far superior, so you end up with files that are about 50 % smaller than JPEGs and AVIF even significantly outperforms WebP. Great news for web performance!

But that’s not all. AVIF also supports alpha transparency, lossless or lossy compression, a color depth of up to 12 bit, high dynamic range (HDR), any color space, like ICC profiles and wide color gamut, and image sequences like in animated GIFs.

If you want to learn more about how good AVIF performs compared to JPEG and WebP, Jake Archibald has written an excellent article in which he takes a closer look at different use cases. And there is an equally interesting post on the Netflix Technology Blog. Overall, the results are stunning.

Here’s a quick comparison between JPG and AVIF at the same file size:

Using AVIF Today

To make use of the many advantages of AVIF, you don’t have to wait until all browsers support it. By using the picture element, you can use AVIF and provide other image formats as a fallback:

<picture>  
  <source srcset="usps.avif" type="image/avif">
  <source srcset="usps.webp" type="image/webp">  
  <img alt="We Deliver For You" src="usps.jpg">
</picture>

That being said, Firefox already supports AVIF behind a flag (media.av1.enabled) and the outlook for Safari seems to be positive because Apple was also involved in the development of the AV1 video codec as a founding member of the Alliance for Open Media. There is also a polyfill for AVIF that uses a service worker to detect all fetch requests for AVIF files and decode them on the fly.

How to Make AVIF Files

So how do you create AVIF files? Image editing software like Photoshop doesn’t support it yet, so we have to rely on conversion tools or use encoders to create our AVIF files.

Squoosh

Squoosh, an image compression web app by Google, now supports AVIF and you can drag and drop PNGs or JPGs into the UI and adjust the settings accordingly. This is great if you just want to explore the new image format or want to carefully optimize only a few images. Manually converting images doesn’t scale that well, though. If you want to convert a larger number of files at once, encoders are a better, and faster choice. At least if the command line is your friend.

libavif

Libavif is the official library to encode and decode AVIF. If you are on a Mac, you can install it with Homebrew:

brew install joedrago/repo/avifenc

The command to convert JPGs or PNGs to AVIF is straightforward:

avifenc [options] input.[jpg|jpeg|png|y4m] output.avif

If you want an overview of the syntax and available options, use avifenc --help.

cavif

Another encoder is cavif, written in pure Rust by Kornel Lesiński, who is also responsible for ImageOptim. You can build it from source or download the latest version and install it. If you are using a Mac, you can symlink the binary into usr/local/bin and then start converting images by running:

cavif image.png

Or, if you also want to adjust the quality:

cavif --quality 60 image.png

Cloudflare Workers

As Chris Coyier reports, Codepen now also supports AVIF. Image files that are stored in Codepen’s Assets Hosting go through a Cloudflare Worker that does all the conversions and now also generates AVIF. So if your site uses Cloudflare, this might be an interesting option, too. And I guess other CDNs and conversion services will follow, soon.

The Next Big (Small) Thing

Overall, AVIF is a compelling package: Powerful compression at decent image quality, support for HDR and wide color gamut, as well as transparency. And all that in an open format that is backed by industry giants like Google, Netflix, Apple, Amazon, or Microsoft. Why should you care about AVIF? Because AVIF could well become the most popular image format on the Web.

-

This is the 58th post of my 100 days of writing series. You can find a list of all posts here.

Martha Curtis had a dream. She wanted to become a violinist. She had been playing the violin since she was nine and excelled at it. But there was a problem. A huge problem. Martha had begun suffering from seizures at age three and a half. She was diagnosed with epilepsy and even though she was on medication, the seizures continued. In her twenties, now a student at Eastman School of Music, Martha had seizures on stage. Up to five per month. Music was her life, but she realized that no orchestra would let her play if she was regularly collapsing on stage. So she sought help.

At Cleveland Clinic, neurologists located the origin of her epilepsy in the right temporal lobe, from where a constant storm of abnormal electrical activity was spreading into other regions of her brain. The doctors suggested surgery. There was one problem, however: The right temporal lobe is the region of the brain where musical memory seems to be stored. So Martha had to make a decision: Live with the seizures that were worsening and would make it impossible to have a musical career. Or, undergo surgery at the risk of losing what had kept her alive: Music.

After three surgeries in which her doctors removed close to 50 percent of her right temporal lobe, including the entire hippocampus, Martha was finally seizure-free. Then, she picked up the violin. She could play as if nothing had happened. Her musical abilities were intact and her memory and concentration even had improved. Her doctors concluded that her brain must have been damaged when she was still a toddler and because she had started to play an instrument at an early age, her brain seemingly adapted to the damage, storing musical memories in other regions than the right temporal lobe.

Cognition, attention, learning, memory, language, motor skills, emotions, thought, reasoning, or the mind: From whichever angle you look at it, the human brain is endlessly fascinating. One of the most fascinating abilities is its ability to adapt, change, and reorganize. And this ability is not limited to a few synapses rewiring a tiny bit. Until the 1990s, many scientists believed that the structure of the human brain was mostly defined by our genes and that the brain was more or less immutable after early childhood. Today we know that nothing could be farther from the truth. Our genes are simply not capable of describing the 100 trillion neurons of the adult brain. So we are born half-baked and the final structure and wiring of the brain are gradually formed by learning and experience. Up until old age, the brain is able to grow new neurons and constantly forms new connections that become stronger with use. The brain adapts to what is needed to survive. This is called neuroplasticity.

The amazing thing about neuroplasticity: To a certain extent, we have control over it. For one, you can choose to do something over and over again, and your brain will adapt to the new requirements. This is how we learn and change our habits. And, as researchers have found, by actively focussing attention, we can increase the effect an action has on the structure of our brains. But what is even more astonishing: Just thinking of a specific action has the same effect on your brain circuitry like actually performing the action. Your brain doesn’t distinguish between a real and an imagined action. It fires the exact same neurons. We can use the power of our minds to shape the physical structure of the brain.

Focussed attention can increase the chances of recovery for stroke patients and can even cure behavioral disorders that were previously thought to be incurable. In his book “The Mind and the Brain: Neuroplasticity and the Power of Mental Force”, Jeffrey M. Schwartz talks about how he successfully treated people who suffered from obsessive-compulsive disorder (OCD) with a self-treatment approach that included mindfulness training. The patients, who, for example, experienced an urge to repeatedly wash their hands, practiced paying attention to the moment a compulsive behavior would arise and then tried to refocus their attention on another fulfilling, productive activity for at least 15 minutes. Over time, many were able to successfully “rewire” their brains, significantly decreasing the amount and severity of compulsive habits and injuries. In his book, Schwartz offers many more examples of stunning research about the brain and the power of directed mental force. And while I’m not yet sold on his idea that the mind even is a physical force like gravity or electromagnetism, he still offers much food for thought about how we can use our mind – and mindfulness – to shape the workings of our brains.

Just like with the observable universe, even after years of research, we are only scratching the surface of understanding how our brains work. But what researchers have found so far, suggests that the brain is much more malleable than we thought.

Our brains aren’t just the result of our genes and other influences that are predetermined or out of our control. To a large extent, we can decide which thoughts, experiences, and skills we want to admit to our brains. Maybe it is time to become better at mindfully directing our thoughts and attention. Because the things we do and think define who we become.

-

This is the 57th post of my 100 days of writing series. You can find a list of all posts here.

Layout on the Web is all about flexibility. That elements adjust their dimensions to the size of their content, be it texts of varying length or images of different sizes, is a welcome feature, especially in times of Responsive Web Design because this flexibility makes building responsive layouts possible in the first place. Sometimes, though, we need an element with a fixed aspect ratio, for example, if we want to embed a video via an iframe or to show images cropped to a fixed aspect ratio, regardless of their original dimensions. In such cases, the infamous vertical padding hack has become our method of choice. It goes a little something like this:

.aspect-ratio-hack {
  position: relative;
  height: 0;
  padding-top: 56.25%;
    
  .inner {
	  position: absolute;
	  top: 0;
	  right: 0;
	  bottom: 0;
	  left: 0;
  }
}

In CSS, you can’t simply set the height of an element in relation to its width. Yet this would be needed to define an aspect ratio for an element. If you set a value for vertical padding in percent, though, it is always calculated with respect to the current width of the element. And that is exactly what we harness with the vertical padding hack: If we want to maintain an aspect ratio of 16:9, for example, we set the padding-top of the outer container to 56.25% (because 100 % / 16 * 9 = 56.25 %) and the height to 0. Now, our container has the right dimensions but because its height is 0, the content wouldn’t be visible. That’s why we use an .inner element to wrap the content and set its position to absolute. The inner element is pulled out of the document flow and we can now set its top, right, bottom, and left positions to 0 so that it completely fills the space of its parent. The outer element has itself a position of relative. This way, we make sure that the absolute position of the inner element is calculated based on the outer element because for elements with position: absolute, the browser always looks for the closest ancestor that is not statically positioned to determine the position.

And that’s it! Our element has a fixed aspect ratio. But as clever as this technique is, it still feels like a dirty hack. We are using padding to set the height of an element with height: 0 and are combining it with an additional wrapper that is absolutely positioned. If that is not a layout hack, I don’t know what is.

Over time, people came up with many variations of the vertical padding hack. But although setting the aspect ratio with data-attributes or custom properties (CSS variables) might be a bit more modern approaches, all those solutions are still hacks.

A Slightly Better Hack

The most sophisticated version of the padding hack might be what Chris Coyier calls the pseudo-element tactic. In the example above, we have set a fixed aspect ratio. But what if there is too much content inside our element, for example, a truckload of text that might fit into the container on larger screens but will overflow on smaller viewports?

Because we defined a fixed height, our container can’t grow accordingly. Essentially, what we want to achieve instead is something like a min-aspect-ratio. The trick is to apply the padding to a pseudo-element instead of the element itself. This way, the content can still make our element grow but it has at least the height of the pseudo-element – which we float out of the way:

.aspect-ratio-hack-better {
  &::before {
    content: "";
    padding-top: 56.25%;
    float: left;
  }
  
  &::after {
    clear: left;
    content: " ";
    display: table;
  }
}

A Look Into The Future: aspect-ratio

But wouldn’t it be nice – and more intuitive for beginners – to have a way to set the aspect ratio in CSS without any hacks? This is exactly what the CSS Working Group proposed last year: a new CSS property named aspect-ratio. The property, which still has to be implemented by browser vendors, will let you define a simple ratio like 16 / 9.

.aspect-ratio {
  aspect-ratio: 16 / 9;
}

If you want to play around with aspect-ratio, you can do so in Chrome Canary with the Experimental Web Platform Features flag set. And as Chris Coyier notes in his excellent article on CSS-Tricks, aspect-ratio does support overflowing content and can be overridden by setting min- and max-width or height, respectively, for example. aspect-ratio will also let an element expand if it breaks out of the aspect ratio, but you can also constrain the height to the aspect ratio by adding min-height: 0.

Setting the aspect ratio of an element will remain a hack for the foreseeable future, but with the aspect-ratio property, a much more accessible and straightforward solution is just around the corner.

In the meantime, here is a Codepen for you to tinker with.

See the Pen Apect Ratio Playground by Matthias Ott (@matthiasott) on CodePen.

-

This is the 56th post of my 100 days of writing series. You can find a list of all posts here.

The spacing between individual elements of a website and, in particular, the vertical spacing, has been a regular matter of debate between web designers and developers. Designers insist that what they see in the browser doesn’t look at all like the layout they originally designed. Developers respond that all the margins in the style sheets exactly match the margins in the layout. So who is right? The tricky thing is: In a way, they are both right.

Let’s take this simple example of three text blocks underneath each other:

In her design tool of choice, the designer defines a spacing of 12 and 36 pixels, respectively. But the final result in the browser looks more like this:

In case you can’t tell the difference, here is the text block overlaid over the original design.

This doesn’t look right. And indeed: When the designer measures the spacings, they appear much larger than in the original layout.

Why is that? Did the developer simply ignore the designer’s layout and approximate the margins off the top of his head?

No. Instead, the problem which – at least in my experience – many designers and developers still don’t know about, results from a difference in how many design tools and web browsers handle line-height or, to be more precise, leading.

In typography, leading is a measure for the space between adjacent lines of text. The word leading derives from lead strips that were put between set lines of metal type to increase the line spacing of a text block. That’s also why it is pronounced “ledding” and not “leeding”.

Leading Goes Digital

When computers entered the scene and freed fonts from their physical constraints, early software tools borrowed from the world printed typography. In the first version of Photoshop, for example, which was released in 1990, users could define a value for leading which would then be added to the font size.

In later years, more and more desktop publishing tools allowed people to set leading not in addition to the base font size but as an absolute value and the term leading became synonymous with the distance from one baseline to the next. Many tools also started calling it line-height. One thing remained, however: The extra space to increase the line height was still added below the lines.

Leading ≠ Leading

This was about to change early after the Web was invented in 1989. When Bert Bos and Håkon Wium Lie drafted the first proposals for CSS, they were, at first, still following the “old” ways of the print world. font-leading: 2pt, anyone? But soon they would decide to make a logical but also radical change. With the new line-height property, which they introduced with CSS level 1, the extra space added to increase the line height was not added below a line of text, but above and below the line. Thus, half-leading was born.

In his fabulous post Getting to the bottom of line height in Figma, Marcin Wichary explains as to why the creators of CSS decided to make that change:

In the world of print or early programs, a text box only needed to hold the text inside it. The web asked it to do more. “I was aware half-leading wasn’t a traditional typographic concept,” mentioned Bert Bos, who worked on CSS1 in 1995 and 1996. "But the problem I had with adding leading only below the lines was what happened to a paragraph when you put a background behind it or a border around it.”

If leading appeared only at the bottom of such a box, that box would feel bottom-heavy and would require additional work to look good. Half-leading offered a way out of this new problem.

In a way, half-leading can be regarded as a truly native feature of the Web. Just as adding leading below a line of text arose from the physicality of the printed medium, so did half-leading reflect the requirements of the new, inherently flexible medium that was the Web. Whether we like it or not, half-leading is part of the material we are working with. It is part of the Web’s Grain.

For many years, web design tools did not support half-leading, though, and as a consequence, many teams had long-winded discussions as to why layouts differed so much between the screen design and the browser. On top of that, not everyone knew about this intricate technical detail, which frequently leads to tensions between designers and developers. Because, obviously, they were both right:

Luckily, first tools like Sketch and Figma have added support for half-leading recently. So at least this controversy might soon be a thing of the past.

Yet there is another detail about how browsers handle fonts that makes vertical alignment and spacing difficult: Fonts have different base line-heights. Depending on which font you use, using a font size of, say, 2rem (32px) and the default line-height, will result in line boxes with totally different heights.

You can mitigate this effect a bit by setting the line-height to 100 %, which, in this case, means 100 % of the font size:

Yet you will still end up with different spacings if you apply equal margins at the top and bottom, for example, if you want to position a piece of text vertically in a button. This is because for each font the position of the baseline can differ. To work around this, you will have to use hacks like applying different margins at the top or bottom of the text. This, however, does in turn not work for fallback fonts which might be used if a web font doesn’t load or is blocked by the user, or if you are using a system font stack.

Leveraging the Void: Leading-trim

Challenges like this are the reason why the CSS Working Group is currently working on new CSS properties that will drastically improve control over the positioning of and spacing between lines of text. For an overview of the current efforts, watch this talk by Elika J. Etemad (aka fantasai) on “CSS Line Layout and Vertical Rhythm” from last year’s CSS Day.

One of the new properties introduced in CSS Inline Layout Module Level 3 is leading-trim. As Ethan Wang outlined in a detailed post lately, leading-trim will allow you to trim off all the extra spacing above or below your text.

And all it takes are two lines of CSS.

h1 { 
 text-edge: cap alphabetic;
 leading-trim: both;
}

With the text-edge property, we will be able to set the over and under edges of our inline box, in this case to the top of capital letters (cap) and the alphabetic baseline, which usually sits at the bottom of the “m”. With leading-trim: both, we then strip out the spacing above the cap height and below the alphabetic baseline. Now we can vertically align the text with more precision – regardless of the font and differing baselines in the respective font files.

Exciting! But also keep in mind that human perception can often not be described in (even) numbers. To place an object in the optical center, you have to place it slightly above the geometric center, for example. And, if we used a word that includes a “g” or “y” in the example above, we might have to adjust the spacing again. So always trust your eye more than you trust the measuring stick. Or, to quote Marcin Wichary again:

-

This is the 55th post of my 100 days of writing series. You can find a list of all posts here.

Images from the printing press and lead strips above are by Flickr user mitternacht, slightly color-corrected and cropped. Used under Creative Commons Attribution-NonCommercial 2.0 Generic (CC BY-NC 2.0).

The dilemma with debt is that it is easily incurred but, inevitably, there comes a time when you will have to pay it back. The problem with design debt is that it is even easier to amass it. Design debt? Yes, like technical debt but for designers.

Tight deadlines, feature creep, competing agencies, changing teams, or simply having different designers working on a project: There are many reasons why design debt accumulates. And we’ve all been there. A quickly defined new button style, another headline variant, a few images that don’t fit the corporate style that well, a new typeface (only for this one project), a less-than-ideal interaction pattern, or simply wrong assumptions: Keeping the design language of a product, company, or brand consistent is hard work. And making sloppy and hasty decisions now can lead to a lot of accumulated design clutter later. This makes it harder to create a consistent brand experience and will reduce the perceived quality and appeal of your interface and even increase the cost for future projects.

Design debt can’t be avoided completely, but when you know that it’s there, you can at least try to reduce it. Create a design system. Avoid rushed solutions and make conscious design decisions instead. Ask yourself what the long-term consequences of variants and additions might be and also discuss this with your team. But also understand that just like music, great design isn’t always monotonous and predictable but needs moments of surprise, playfulness, and fresh perspectives. Creating and maintaining a design that is both consistent and versatile is a balancing act that requires zooming out a bit from time to time to see the bigger picture and evaluating if you are still on track.

-

This is the 54th post of my 100 days of writing series. You can find a list of all posts here.

How do you feel about your work at the moment? Do you enjoy what you are doing? Do you feel excited about it? Does it give you a sense of accomplishment and significance? Do you feel valued and are part of a great team? Do you enjoy your role as a leader or the choices you have at your job? Chances are that the one or other might be true for you and, depending on how much you value certain aspects of your work, you might either be happy or unhappy with what you are doing at the moment. In fact, many people are dissatisfied with their career choices and jobs, which makes it as important as ever to create (remote) work environments and teams in which people enjoy what they are doing, get to live up to their full potential, and, most importantly, are willing to take risks and try out new things. But how?

Researchers have studied what it takes to create fulfilling work environments and it all comes down to a few basic human needs. Core needs that we all value and try to meet at different levels, but which are all essential to make us feel valued and satisfied. There are a few different models that try to describe those needs, one of which is Paloma Medina’s BICEPS framework. Lara Hogan talked about this list of core needs in the latest episode of Matt Mullenweg’s podcast Distributed, which I highly recommend.

BICEPS consists of six core needs that are most important for humans at work:

Belonging

As humans, we want to be part of a group, a tribe, a family. We need that feeling of friendship and closeness with others to feel safe and comfortable.

Improvement/Progress

We all want to grow, improve, and make progress toward a meaningful goal, both personally and as a group.

Choice

What would life be without at least a feeling of choice? We want to be in control and make our own, autonomous decisions which, ideally, bring about real change.

Equality/Fairness

We want to be treated fairly but also demand the same for others. Access to information and resources should be equal for every member of the group.

Predictability

We need the certainty that resources, time, and information will be available in the future and that the challenges ahead of us are, to a certain degree, manageable.

Significance

And lastly, we want to be recognized for our work. We seek status and want to feel valued, important, needed, or respected.

Paying attention to those core needs when managing a team or a company can help us be more socially sensitive and understand team dynamics much better. But it also helps us to understand our own motivations much better. After all, we aren’t rational decision-makers. Much of our behavior is the result of complex emotions and social motivations. Understanding this is the first step to making others feel valued and, ultimately, satisfied with their work.

-

This is the 53rd post of my 100 days of writing series. You can find a list of all posts here.

When it became increasingly clear that running in-person workshops would not be possible for the foreseeable future, the XDI team, which I am a part of, started to work on online versions of our Adobe XD workshops for beginners and advanced users. The resulting workshops are a nice mix of tutorial-style explanation parts and hands-on exercises in XD. One small but crucial element to the whole experience is music. Music is playing while people are waiting for the workshop sessions to start, but also throughout the sessions when everyone is busy designing and prototyping with the software.

After my first online workshop, a little detail surfaced: In the workshop, I started and stopped the music with the default play button on the Touch Bar of my Macbook Pro. This resulted in the Music App (the software formerly known as iTunes) starting playback at full volume and stopping abruptly, however. Wouldn’t it be much nicer to be able to fade the music in and out? At least this would make for a much smoother experience for the participants. I surfed the World Wide Web for a solution and indeed found one that would work without the need for an audio mixer.

With the help of Automator, we can smoothly fade music in and out and even control this behavior via a keyboard shortcut or the Touch Bar (if you happen to have one). Here is how it works:

Step 1: Set up an Automator Workflow

First, open Automator and create a new “Quick Action”.

Configure the workflow so that it doesn’t receive any input, select an appropriate icon, and pick a color. This will also be the color of the button in the Touch Bar, so pick a bright color that will help you find the button more easily when you are sweating like hell in the workshop.

Now, find “Run Apple Script” in the list of actions and double-click the action so that it appears in the window on the right.

Copy and paste the following code into the textarea, which I found in an answer on StackExchange:

set current_application to (path to frontmost application as Unicode text)
tell application "System Events"
	if process "Music" exists then
		tell application "Music"
			set current_volume to the sound volume
			set del to 3 / current_volume
			if (player state is playing) then
				repeat
					repeat with i from current_volume to 0 by -1
						set the sound volume to i
						delay del
					end repeat
					pause
					set the sound volume to current_volume
					exit repeat
				end repeat
			else
				set the sound volume to 0
				play
				repeat with j from 0 to current_volume by 1
					set the sound volume to j
					delay del
				end repeat
			end if
		end tell
		tell application current_application
			activate
		end tell
	end if
end tell

Save your Quick Action under a recognizable name like “Fade-In-Out-Music”. I am sure you will find an even better name than this. 😉

Now, open Music app – notice that the Music app has to be running for this whole workflow to work! – and then try if the Automator script works by hitting the play button. In Automator, that is.

The music should now fade in and out within 3 seconds. If you want to change the speed, you can change the number in line 6 (set del to 3 / current_volume) in the code snippet above.

Step 2: Define a Touch Bar Action

The last step is to configure the Touch Bar so that you can quickly fade your music in and out.

Choose Apple menu 🍏 > System Preferences, click Keyboard, then select Keyboard, and click Customize Control Strip. Look for the Quick Actions button and drag it into one of the spots in the control strip. You could, for example, replace Siri.

Click Done to save your settings.

Perfect! Now, once you touch the Quick Actions button, you can hit the new green button to fade your music in and out. Note that you might have to confirm once that Automator should be allowed to control the Music app.

In case you don’t have a Touch Bar, you can also define a shortcut in System Preferences > Keyboard > Shortcuts > Services:

And that’s it. You are now able to fade music in and out like a pro in your workshops or other online sessions. Do you know of any other nice tricks for doing live demos or online workshops? Let me know.

-

This is the 52nd post of my 100 days of writing series. You can find a list of all posts here.

When it comes to structuring CSS, there is no shortage of different naming conventions, methodologies, and architectures. Be it BEM, OOCSS, SMACSS, ITCSS, or CUBE CSS – over the last years, many different approaches to managing modular CSS have emerged. Some are offering strategies on how to split CSS into smaller, more manageable pieces, while others focus more on naming conventions for classes. Sometimes, it can be hard to grasp where the differences or advantages of certain methodologies lie, yet in the end, they all aim at the same: Providing structure and consistency, also known as “avoiding a mess”, when you are working in a team or with your present and future self.

No wonder there isn’t a new project where I don’t start to think about the structure of my CSS a bit and, over time, the way I organize and write CSS has changed a lot. The biggest change came when we all started to write CSS for components. But also preprocessors like Sass have clearly left their mark.

In this post, I will share my current take on CSS structure. It does not religiously follow any particular methodology, although people familiar with Harry Roberts’ ITCSS (“Inverted Triangle CSS”) will definitely recognize parts of his methodology. If you haven’t yet looked at ITCSS, I highly recommend it. What I like most, is the pragmatic, real-life approach and the principle of structuring your CSS in a way that gets ever more specific and explicit the farther down you go in the structure. This allows you to focus on the high-level styles first and makes it easier to deal with the cascade, inheritance, and selector specificity while keeping the number of classes – and the specificity! – as low as possible. There are, however, a few differences, and this is also what I’d suggest to anyone setting up their own structure: Take any methodology with a grain of salt and freely adjust it to your needs and the way you work.

The Folder Structure

This is how my folder structure currently looks like:

/scss/
├── 1-settings
├── 2-design-tokens
├── 3-tools
├── 4-generic
├── 5-elements
├── 6-skeleton
├── 7-components
├── 8-utilities
├── _shame.scss
└── main.scss

Let’s break it down a bit.

Settings

The first folder, 1-settings, is for all general project settings, so for the most basic high-level configuration. This might be a collection of global variables – either as Sass variables or custom properties.

├── 1-settings
│   └── _global.scss

Design Tokens

The second folder is for all styles regarding the visual vocabulary of the site. At this level, we are still not generating any CSS output. It is where we define variables for the typography, colors, spacing, media-queries, or any other attributes which you will use throughout the design. For these visual design attributes, the term design tokens has taken hold. Those design tokens could even be coming from your design system as a single source of truth.

├── 2-design-tokens
│   ├── _colors.scss
│   ├── _fonts.scss
│   ├── _media-queries.scss
│   ├── _spacing.scss
│   └── _typography.scss

Tools

The tools folder is where your global Sass mixins and functions live. Maybe you want to manipulate colors with blend modes or set the aspect ratio for a video container? Or clear your float, for example. I am not a heavy user of mixins myself, but I know many people who love them, so this is where to put them.

├── 3-tools
│   ├── _aspect-ratio.scss
│   ├── _blend-modes.scss
│   ├── _center.scss
│   ├── _clearfix.scss
│   └── _gradients.scss

Generic

Just like in ITCSS, the generic folder is the first one that actually produces CSS. It contains global box-sizing rules, CSS resets, or print styles – anything that should be set right at the beginning of your CSS but isn’t yet project-specific.

├── 4-generic
│   ├── _box-sizing.scss
│   ├── _normalize.scss
│   └── _print.scss

Elements

Now that the most basic things are set up, we can start to style the building blocks of our front-end: Raw HTML Elements. Mostly without classes, we are now redefining the basic browser styles of headlines, buttons, links, lists, etc. and can make sure that all components in our design are using the same consistent base.

├── 5-elements
│   ├── _forms.scss
│   ├── _headings.scss
│   ├── _images.scss
│   ├── _links.scss
│   └── _lists.scss
│   ├── ...

Skeleton

Any modern web project that is built with components also comes with the need for a higher-level structure in which all the components can live: Wrappers, containers, grids, and all kinds of reusable objects that provide layout patterns. This is the skeleton of your site.

├── 6-skeleton
│   ├── _grid.scss
│   ├── _layouts.scss
│   └── _objects.scss

Components

The beating heart of the project. This is where we design the components of the UI. In a few recent projects, I sometimes distinguished between larger modules and smaller components, but you can also nest components into each other and do without the additional distinction. Use prefixes, if you like, and also a naming convention like BEM can make a lot of sense. I have recently settled on a BEM-like but more simplified naming convention: Just use the simplest but most descriptive class name possible and separate elements within other elements with a simple dash, like .card and .card-content. Sometimes – for example, when I work with Fractal – the CSS for individual components might also live in another folder, together with the HTML and JavaScript code. In this case, the components folder might be empty, or contain references via @import.

├── 7-components
│   ├── _accordion.scss
│   ├── _card.scss
│   ├── _hero.scss
│   ├── _pan-galactic-gargle-blaster.scss
│   └── ...

Utilities

Another folder? Yes, but this is definitely the last one. The utilities folder contains utility and helper classes and, most importantly, states and modifiers like .is-active or .visually-hidden. Those styles override the styles in the previous layers and are often set via JavaScript. I really like the suggestion by Andy Bell in his CUBE CSS methodology to use data-attributes to change the state of components, which is also useful in terms of the higher specificity.

├── 8-utilities
│   ├── _modifiers.scss
│   └── _states.scss

_shame.scss

This file, which is another idea by Harry Roberts, is a place for all the shameful CSS solutions like quick fixes and hacky things that might solve a problem for the time being but should be solved properly later. Make sure to document all those nasty hacks with comments, though: Why did you solve it this way? Do you already have an idea on how to solve it better? What is needed to solve it? And so on…

Putting it all together

Finally, the main.scss file is where all the individual files are combined. I prefer to explicitly import each file in a new line instead of importing whole folders because I have more control over the source order. But this is only my personal preference, of course.

@charset "UTF-8";

// 1. Settings
@import 
	"1-settings/global";
  
// 2. Design Tokens
@import
  "2-design-tokens/colors",
  "2-design-tokens/fonts",
  "2-design-tokens/media-queries",
  "2-design-tokens/spacing",
  "2-design-tokens/typography";
...

And that’s it. A structure like this has served me well in recent projects because it keeps everything tidy. The resulting CSS is also much cleaner and it is easier to find the right piece of code when you have to make changes or do bugfixes.

I asked on Twitter the other day which CSS methodology you all prefer and the results were, as was to be expected, mixed:

Web developers and designers of the interwebs! What is your favorite…

✨CSS methodology✨?

—and why?

— Matthias Ott (@m_ott) August 10, 2020

People all like to use their own flavor of CSS, which is great. If you use a methodology or folder structure that you would like to share, write a post about it and I’ll happily link to it here. It would be interesting to see how you structure your CSS.

For future reference, here’s the whole folder structure again:

/scss/
├── 1-settings
│   └── _global.scss
├── 2-design-tokens
│   ├── _colors.scss
│   ├── _fonts.scss
│   ├── _media-queries.scss
│   ├── _spacing.scss
│   └── _typography.scss
├── 3-tools
│   ├── _aspect-ratio.scss
│   ├── _blend-modes.scss
│   ├── _center.scss
│   ├── _clearfix.scss
│   └── _gradients.scss
├── 4-generic
│   ├── _box-sizing.scss
│   ├── _font-face.scss
│   ├── _normalize.scss
│   └── _print.scss
├── 5-elements
│   ├── _forms.scss
│   ├── _headings.scss
│   ├── _images.scss
│   ├── _links.scss
│   ├── _lists.scss
│   └── ...
├── 6-skeleton
│   ├── _grid.scss
│   ├── _layouts.scss
│   └── _objects.scss
├── 7-components
│   ├── _accordion.scss
│   ├── _card.scss
│   ├── _hero.scss
│   ├── _pan-galactic-gargle-blaster.scss
│   └── ...
├── 8-utilities
│   ├── _modifiers.scss
│   └── _states.scss
├── _shame.scss
└── main.scss

-

This is the 51st post of my 100 days of writing series. You can find a list of all posts here.

This is post number 50 of my 100-days-of-writing challenge. It’s halftime! Time for me to look at how this little (?!?) experiment worked out so far and what I might have learned or experienced since I started back in May.

First of all, the obvious: Writing a post every day is a lot of work. Most people don’t sit down at their desks, write for half an hour and end up with a well-written, interesting post. At least that’s not how it works for me. So publishing a post every day is time-consuming and also costs a lot of energy. Something I realized pretty quickly is that I need at least a three-step process to finish a piece: First of all, a phase of thinking about what to write, then the writing phase, and lastly the most important phase: editing. It is challenging to compress all those steps into one session. So what worked well for me was thinking about a topic over the day, writing the draft in the evening (with maybe a bit of pre-editing), and then doing a final edit with a clear brain the next morning. This requires, however, that you have time for all three tasks throughout the day. And with a family at home in the office, client work, and workshops, this can get a bit difficult. So after a few posts, I decided to not write over the weekend, except for Sunday evening and I gave myself permission to publish two posts on the same day from time to time to catch up if I missed publishing the day before. I’m cheating a bit, I know, but at the same time I defined the rule to still write something every day, which I did.

Another thing I noticed: The idea that you could simply put out smaller posts doesn’t work at all for me. Why is that? Because writing a shorter piece will actually be more work and much more challenging than writing a longer text. If, for example, you want to convey an idea in only two paragraphs and tell a story, too, you only have so many words and sentences at your disposal. This means that, at least if you want to keep the quality of your posts at a certain level, every word counts and you’ll spend a considerable amount of time editing your post until it “works”. As a result, many of my posts turned out to be much longer than I had expected. Not as long as many of my previous articles, but still long enough to make me wonder if the posts are still “snackable” enough.

But now to the things that worked fairly well. First of all, it is true: When you write every day, you’ll start to think constantly about what to write about. And what is even more valuable: You start to notice things, thoughts, and connections throughout the day that might be an interesting topic for a post. Naturally, there are days when you immediately have an idea about what to write about, and then there are other days when ideas don’t come that easy. On such days, it worked well for me to have a constant stream of input like articles, podcasts, or books.

I also got faster at writing and I feel like I am editing a bit less. English is my second language (actually, it is my third – sorry for forgetting about you, Latin) and I still feel like a bloody beginner. Although I have started to use words like bloody, which, of course, I hear in Stephen Fry’s voice as I write them. But I also have the feeling that I am using the dictionary less often than before. And if I do, it is very likely because I know that there is a word that might be a better fit for the occasion – excuse me: the intended purpose – that isn’t yet part of my active vocabulary.

Many of my first 50 posts were circulating around topics that I have been thinking about constantly over the last few months. Design, CSS, JavaScript, fear, workflows, ideas, inclusive design, service design, progressive enhancement, Milton Glaser, wide gamut color spaces, and other advice I feel confident enough to give based on my still limited experience. So one step at a time, I mostly emptied my quick drafts folder in iA Writer. Looking back, though, the majority of posts wasn’t that practical or filled with hands-on advice. And this is something that, after having covered all the inspirational topics at length, I’ll plan to do more in the next 50 posts. If you have a topic you would love to read about from a UX designer who codes interfaces for the Web, let me know. Here’s to the next 50/100 posts.

Stay tuned, I assume, the real words come after halftime.

-

This is the 50th post of my 100 days of writing series. You can find a list of all posts here.

In 1963, the people at NASA needed a building. And not just any building. It had to be large enough to be able to assemble the enormous space vehicles NASA designed as part of their massive effort to send astronauts to the Moon. The building that was completed in 1966 allowed for the vertical assembly of rockets like the Saturn V, and it is to this date the largest single-story building in the world. Located at Kennedy Space Center in Florida, the “Vehicle Assembly Building” (VAB) is 160 meters tall, 218 meters long, and 160 meters wide, with a volume 3.75 times that of the Empire State Building, and built to withstand hurricanes. The building is a vast and complex system that includes five overhead cranes used to pick up the heaviest elements of rockets and to place them carefully into position ahead of launch. It also has the largest doors in the world, through which the rockets roll to the launch pads.

Yet, after the Vehicle Assembly Building was completed, it had a surprise in store: It creates its own weather. The building is so vast that, on very humid days, rain clouds form below the ceiling and about 10,000 tons of air conditioning equipment are needed to control the moisture inside. And so it only takes one hour to completely replace the air in the building. Although, rumor has it that the folks at NASA often just leave the doors open…

That a building can have its own weather is not only a good story to start a blog post with, but it also teaches us something about the nature of complex systems: They come with unintended consequences and unexpected behavior. “The larger the system, the greater the probability of unexpected failure,” John Gall wrote in General Systemantics, his seminal book about how systems work – and how they fail. In the book, which can be borrowed from the Internet Archive, Gall offered many principles of systems design, especially with regards to complex systems. One of those principles has become known as Gall’s Law:

He might have a point here: Many of the complex systems around us that work, weren’t designed from scratch. They evolved from a simpler system, a basic set of rules and conventions. Nation-states, companies, the World Wide Web – it would have been impossible to design them in all their complexity without failing miserably. And history has seen countless failed attempts at designing complex systems, from Le Corbusier’s radically geometric ideas for urban planning to the utopia that is Brasilia to the sinking of the Titanic.

So when you set out to design a system, whether it is a business, a team, its workflows, a website, or a design system, it is good to remember Gall’s Law. A complex system designed from scratch never works. Start with the simplest system you can come up with and enhance it incrementally. Don’t overspecify, but leave enough room so that connections and structures can evolve and grow over time. Loose systems last longer and work better. Lastly, be aware that your system might fail at any time. At least, anything that can go wrong will go wrong, right? So also ask yourself: How well does it fail?

Designing a simple system is much harder than designing a complex system. But at least you might end up with a system that actually works.

-

This is the 49th post of my 100 days of writing series. You can find a list of all posts here.

According to James P. Carse, there are at least two types of games: Finite games and infinite games. Finite games have a clear beginning and end, a distinct set of rules and boundaries, and we play them for one purpose: to win. Take any match of chess, tennis, football, or Scrabble as an example. Infinite games are different. We don’t play them to win, because they don’t have an end. We play them for the joy of playing in itself and with the purpose of continuing the play. Life itself is such an infinite game, but so are businesses, relationships, careers, or the Web.

Looking at your life, or any endeavor, as an infinite game completely changes your perspective. As you want to keep playing the game, you start to look to the future, think about practical solutions to problems, constantly look around for opportunities, and invest in learning to be prepared for the unknown. But most importantly, you realize that the struggle, the process of creation and growth, is not only an essential part of the game, it is actually the reward for playing it.

-

This is the 48th post of my 100 days of writing series. You can find a list of all posts here.

What is the right strategy to achieve greatness and succeed in a specific domain? If you believe the predominant narrative in many efficiency-oriented societies today, the answer is clear: Focus on one thing early in life to have a head start and invest at least the famous 10,000 hours of practice to become a master at it. Excellence and ingenuity, the story goes, are a result of hyperspecialization, grit, and relentless focus. Except this might actually not be true.

In “Range,” David Epstein tells a different story: Neither is an early head start and narrow specialization necessary to achieve greatness, as he demonstrates with several examples from Roger Federer, who played many different sports like skiing, basketball, and soccer as a child until settling for a career in tennis, to the “figlie di coro,” the virtuoso musicians of eighteenth-century Venice, who played not only the violin but also several other instruments like the cello, oboe, lute, mandolin, harpsichord, and “viola d’amore”. Nor is hyperspecialization the primary source of creativity, innovative ideas, and scientific breakthroughs later in life. From Vincent Van Gogh to Django Reinhardt to several inventors and Nobel laureates, the book is full of gripping stories and thought-provoking research showing that mental meandering, personal experimentation, and cross-disciplinary thinking are sources of power, creativity, and true innovation.

Range is a powerful reminder that there is a place for the generalists, the curios polymaths, among us. That it is okay, also for your children, to go broad and try different paths until you find what really fits you – and who you really are. That when you face a “wicked” problem, diverse experience beyond the boundaries of a specific field is a huge advantage because it allows you to think outside the box. And that having range can be invaluable in connecting seemingly unrelated disciplines and concepts in new ways.

Like many other domains, the web industry is becoming more and more specialized. And many of us seem to believe that only by becoming specialists ourselves, we can keep up with the increasing complexity and diversity of the Web and its countless technologies. We invent ever more specific positions and job titles, read ever more specific books, and go to ever more specific conferences. And so you have to decide: Are you a designer or a developer? Front-end or back-end? Front of the front-end or back of the front-end? CSS or JavaScript? Angular or React? And the gaps between the disciplines are growing.

Yet, many of us out there are allrounders who love to tinker, prototype, experiment, and build. Many of us are interested in the most diverse topics and feel most at home at the interfaces between design, technology, and the arts. And, as David Epstein shows, the more a domain specializes, the more it depends on generalists who see the bigger picture and make connections specialists are unable to see. Research suggests that broad individuals can even be more valuable than a diverse group of specialists. So the next time someone calls you a “Jack of all trades, master of none,” gift them a copy of Range.

Being a generalist is not a sign of weakness – it is a sign of strength. And, with job titles like Front-end Designer emerging, it seems as if the industry is slowly recognizing this. So embrace your seemingly unimportant and inefficient interests. Paint, dance, code, run, read, write, sing, play, and dabble. And let nobody tell you that a designer shouldn’t write production code or a developer can’t also be a brilliant writer. If you are a generalist, be a generalist. It is who you are.

-

This is the 47th post of my 100 days of writing series. You can find a list of all posts here.

One evening in the late 1970s, an engineer from Kyoto was riding home on the Shinkansen, when he recognized the man sitting next to him playing around with his LCD calculator, punching buttons in boredom. The engineer, who worked at a toy and gaming company, had an idea: What if commuters could kill their time with a portable device that was both a watch and a gaming device? The engineer went to work and, after its release in 1980, the product that resulted from his idea became a huge success. Its name: Nintendo Game and Watch.

Not too much is known about the life of Gunpei Yokoi, the designer and engineer behind many of Nintendo’s most successful products. To control a game called “Donkey Kong” on the Game and Watch, Yokoi invented the D-Pad, the four-way directional control that can be found on almost all modern game consoles and controllers. He went on to produce games like Metroid and the Super Mario franchise and, in 1989, Nintendo introduced the product that would become Yokoi’s greatest success: The Game Boy.

Both the Game and Watch and the Game Boy were innovative products but there was something about them that one wouldn’t necessarily expect from such breakthrough devices: When it came to their hardware, they weren’t cutting-edge. The LCD screens used in both devices, for example, were already cheap and prevalent at the time. While competitors were outdoing each other with the latest hardware features like color displays and computing power, Nintendo focused on providing great gameplay with cheap and readily available technology. Gunpei Yokoi called this philosophy “lateral thinking with withered technology”.

Using cheap and readily available technology and combining it in new ways was a stroke of genius. Hardware-wise, Nintendo could not compete with larger competitors at the time. But in Yokoi‘s view, this wasn’t that much of a problem. As David Epstein writes in his book “Range,” Yokoi was sure that once users were playing a game with the gameplay good enough to be fully drawn in, they wouldn’t care at all about technical details like screen resolution or colors. And thus, the seeming disadvantage of using cheap technology turned into a huge advantage: The Game Boy was affordable, durable, portable, and played for hours on AA batteries. And because developers were already familiar with the underlying technology, they could easily build new games for the platform. By using “old” technology, Yokoi removed barriers to entry for both developers and users. As a result, with more than 118 million units sold, the Game Boy became the most successful game console of the 20th century.

I feel like we could use a bit more of Yokoi’s philosophy on the Web. With all the craze about the newest and dopest tech, it is easy to mistake using the latest technology for progress and innovation. It is, however, important to remember that technology is only a means to an end and that there is an alternative route that can be equally, if not more, successful. A route that puts the user and the experience first. A route of inventing new products not by using the latest technology available but by applying and combining existing technology in new ways and contexts.

The Web now consists of an ever-growing number of different frameworks, methodologies, screen sizes, devices, browsers, and connection speeds. “Lateral thinking with withered technology” – progressively enhanced – might actually be an ideal philosophy for building accessible, performant, resilient, and original experiences for a wide audience of users on the Web.

-

This is the 46th post of my 100 days of writing series. You can find a list of all posts here.

I used to dream of a magical machine. It was about as big as a microwave, all silver metal (with rivets, of course), and it had little knobs, lamps, and indicators everywhere. On the left, there were two buttons: One was green and the other one red. On the right, the machine had a tiny slot. Whenever a person pressed one of the two buttons, the machine would start rattling and hissing, all of the little lamps would start blinking and all the indicators would start, well, indicating. After a few seconds, a small slip of paper, just like the one you find inside a fortune cookie, would emerge from the slot on the right of the machine. On it: An idea. But not any idea. A brilliant, life-changing idea. Or, if you had decided to press the red button, a horridly bad idea. You would only be able to use the machine once a day and, naturally, most people would use the green button almost all of the time.

It’s not hard to see why the image of such an idea-generating machine is so alluring: Generating good ideas is one of the hardest things to do. People outside of the creative industry often say: “Oh, it must be so hard to come up with new ideas every day!” But coming up with ideas, in general, is not the problem. The hard thing is to identify the ideas that work. Although we are all able to envision possible futures, nobody can be sure if an idea will actually prove to be valuable in the future. Only in hindsight do we know which ideas were great ideas in the first place.

Great ideas also don’t come to you in a flash of genius. You have to generate them. Research suggests that the first step to generate good ideas is to come up with a lot of ideas. If you generate about 10 to 15 ideas, you have a good chance of having generated a few good ones. What often happens, though, is that we tend to fall in love with the first idea that comes to mind. You also might have heard people say that the first idea is generally the best. But that is simply not true. First ideas are the most obvious ideas and often the most unoriginal and outdated. They might be based on a solution you already came up with long ago and that you now use instead of thinking about the real problem, for example. Or, it is an idea that many others would also come up with as their first idea. So when you start to evaluate which ideas are the most promising, try to be objective and generate as much insight into how and why an idea might work as possible. For example, by building quick prototypes. Researcher Justin M. Berg also found in an intriguing study that when we evaluate and rank our ideas by their potential creativity, it is not our favorite idea that will be the best one, but actually the second on the list. While the favorite idea might indeed work, the idea that participants thought was their second best, often proved to be more original and, ultimately, more successful. So if we were to build an idea machine, would it spit out the first or the second idea on the list?

The most interesting question, though: Would the machine generate all those ideas from combining seemingly unrelated knowledge from different domains? I would hope so. Because, as David Epstein brings out brilliantly in his latest book “Range”, the most groundbreaking and innovative ideas are often the ones that transcend the boundaries of one specific domain and ingeniously combine different concepts in new, previously unthinkable ways.

-

This is the 45th post of my 100 days of writing series. You can find a list of all posts here.

Derek Sivers just published a new book. It is called “HELL YEAH OR NO” and you can get it on Derek’s website. Having enjoyed Derek’s blog articles and podcast a lot, buying his book, which also includes an audio version, was a no-brainer for me. Derek is a musician, producer, circus performer, and entrepreneur, who, as a musician in New York City, founded the mail-order company CD Baby to distribute his and his friends’ music. It grew into a successful online business. In 2007, he decided to sell CD Baby and since then, he has been writing and speaking about entrepreneurship, creativity, and learning.

The new book is a collection of ideas and approaches to life he collected on his website over the years. And it is full of advice that is often so simple yet hits the nail on the head in a charming, pragmatic, and thoughtful way.

Just to give you two examples:

First, take the title idea of the book, “HELL YEAH OR NO.” We all tend to say yes to far too many things. And before we know it, we are so busy that when a real opportunity comes our way, we don’t have the time and mind to react and will miss an opportunity we would have been excited about. So Derek suggests that unless you are feeling “Hell yeah, that would be awesome!” about something, say no. It makes the decision much easier and you can make sure that once a great opportunity arrives, you can give it your full attention.

Equally intriguing is this other idea from the book: Some people are more present-focused, while others are more future-focused. Present-focused people only live in the present moment and for today and, for example, are playful, impulsive, and sensual. They can get fully immersed in the moment and lose track of time. Future-focused people, on the other hand, see the present more as a stepping stone for their future selves. They can see their future goals and delay gratification to reach them and “live in their minds, picturing other selves, scenarios, and possible futures.” Think about yourself and the people near and dear to you: Who is more present-focused and who is more future-focused? In the end, as Derek points out, both mindsets are necessary.

-

This is the 44th post of my 100 days of writing series. You can find a list of all posts here.

Ethan Marcotte wrote this on Twitter on Monday:

Inclusive design has come a long way. Of course, we still need to do much, much better. Even in 2020, the vast majority of websites still isn’t accessible. But at least, there seems to be a raised awareness for the topic within the web community. In the last few years, several books, articles, talks, and even whole conferences around inclusive design have certainly left their mark. Many of us now know that the privilege of building websites comes with the responsibility to build websites for everyone and, in this way, to provide access to technology for everyone.

Access to technology for everyone doesn’t come easy, though. As Ethan points out, “in the old days”, websites were highly inaccessible. The Flash era didn’t do much to improve accessibility on the Web either. Screens readers can scan linear, static HTML, but the dynamic, constantly changing nature of Flash sites made it almost impossible to optimize a Flash site so that a screen reader user would have a valuable experience. Besides that, Flash websites often also needed a lot of bandwidth and at least a decent CPU to run smoothly. And because you basically could do anything in a Flash movie, people did everything: There were no rules, no standards, no patterns, no fallbacks.

The progress we have nevertheless seen over the last two decades is the result of an ever-growing number of people pushing hard against the status quo. And this is not only true for accessibility, but also other essential building blocks of a modern, inclusive Web: Web standards, usability, performance, security, interoperability, and robustness. The Web of today is in many ways so much more mature than the Web of the early 2000s. And the progress in all of those areas makes the Web more inclusive already.

Enhance!

One of the most useful strategies – and philosophies – to build inclusive experiences for the Web is progressive enhancement. Coined in 2003 by Steven Champeon and Nick Finck, it describes the idea that instead of building exclusive websites for latest browsers and devices, it is much smarter to build a basic experience first which is then progressively enhanced (aha!) to provide a richer, more advanced experience as opportunity allows. That way, you make sure that your product is usable by people with any kind of device, on any kind of network connection, and with any kind of assistive technology.

Jeremy Keith likes to break progressive enhancement down into three steps that are as powerful as easy to remember:

• Identify core functionality.
• Make that functionality available using the simplest possible technology.
• Enhance!

Sounds straightforward, right? Yet, wherever I look, I can’t escape the feeling that this approach is still, even after almost 20 years, more of an exception rather than the rule. Yes, I know a lot of people who know what progressive enhancement means and also practice it. They start with structured content, or at least with semantic HTML, add CSS that works well in older browsers, sprinkle in all the new layout goodness for modern browsers, and, in the end, they enhance all of this with JavaScript – including better accessibility support. But I have also worked with even more people who have no idea what progressive enhancement even means. They might have heard of the term but also often mistake it for graceful degradation. And who can blame them? The complexity of the modern Web is breathtaking and the things one could learn and incorporate into their practice endless. But that’s exactly why learning about progressive enhancement would be so valuable for those people: Progressive enhancement is not yet another technology or passing fad. It is a lasting strategy, a principle, to deal with complexity because it lets you build inclusive, resilient experiences that work across different contexts and that will continue to work, once the next fancy JavaScript framework enters the scene – and vanishes again.

But why don’t more people practice progressive enhancement? Is it only because they don’t know better? This might, in fact, be the primary reason. On top of that, especially many JavaScript developers seem to believe that it is not possible or necessary to build modern websites and applications that way. All they know is their hammer and so they just can’t imagine how one could possibly build a product like Hey! without megabytes of client-side logic, hot module replacement, and virtual DOMs. Meanwhile, they introduce huge amounts of technical debt and continue to build exclusive experiences that remind me a lot of the Flash era. Even progress bars are making a comeback. Can you tell which way the wind is blowing?

In my experience, it is also quite hard to change the culture and processes of agencies and web development studios. Many designers don’t know about progressive enhancement either and modern design tools also don’t support the layered approach of progressive enhancement. Imagine what a difference it would make if a designer could turn off a web font in her design tool or even switch off all the styles to see nothing but the underlying semantic structure of her layout. For now, the only design tool that can do such things, is the browser. And this is why I will continue to advocate for more interdisciplinary collaboration within teams and more prototyping. Because in order to practice progressive enhancement well, every member of the team has to be able to make well-informed decisions. If a designer never sees a design in its most basic form, how can she possibly improve this state of the system?

Some look at progressive enhancement like a thing from the past of which the old guard just can’t let go. But to me, progressive enhancement is the future of the Web. It is the basis for building resilient, performant, interoperable, secure, usable, accessible, and thus inclusive experiences. Not only for the Web of today but for the ever-growing complexity of an ever-changing and ever-evolving Web.

If you want to learn more about progressive enhancement, read those two books to get started:

Aaron Gustafson’s Adaptive Web Design: Crafting Rich Experiences with Progressive Enhancement in invaluable and explains the core idea as well as many examples very well. You can even read the first edition for free – and then buy the second edition!

Resilient Web Design by Jeremy Keith is a delightful journey through the history of the Web that brilliantly explains what it means to build for the Web and why progressive enhancement is at the core of creating resilient, future-proof experiences. It is a free online book.

-

This is the 43rd post of my 100 days of writing series. You can find a list of all posts here.

It is clearly their fault.

The clients just don’t get design.
The designers only care about how it looks.
The developers have no sense for aesthetics.
CSS is broken.
The users are just too stupid.

It is clearly their fault. Is it, though?

Whenever we struggle or fail, our first instinct is often to blame others or external factors beyond our control. Psychologists have a name for that: Self-serving bias. When we exhibit the self-serving bias, it is primarily to boost our self-esteem. We take credit for personal success to feel better and more confident and at the same time try to preserve our confidence by denying that we might also be responsible for personal failure.

The self-serving bias is a bias, though. So it would be fatal to simply accept it and keep on blaming external factors. Because we might be mistaken. In fact, we often are. And this keeps us from identifying the real problems and changing our behavior accordingly. Take the statement “the client just doesn’t get design“, for example. It might be true that the client has a hard time understanding your design or that she has no eye for great typography. But if you have to change your design against your will or the project even fails, blaming the client conceals the true problem: That you failed to communicate the intention of your design or the intricacies and importance of good typography. Maybe you were not voicing your opinion loud enough. Maybe you were too complacent or not optimistic enough. Or maybe you also work in an environment, where designers don’t present and explain their work in front of the client by themselves. Whatever it is, though, it is very likely to happen again if you hide behind the self-serving bias and don’t acknowledge the fact that something is wrong.

What if it is actually not their fault?

What if clients could get design? What if better collaboration between designers and developers would improve mutual understanding? What if CSS isn’t broken but you simply don’t know it good enough yet? What if users are just the way they are and, in reality, your design just does not cut the mustard yet?

What if we actually could change all of that?

-

This is the 42nd post of my 100 days of writing series. You can find a list of all posts here.

Jeremy Keith and the team at Clearleft have started a new podcast. In each episode, they are looking at a different theme related to design, development, and beyond. The first episode covered design systems and was already very worthwhile. But I especially enjoyed the latest episode about a topic that has become a bit of a hyped buzzword over the last few years: Service design.

Rich with anecdotes and stories, the episode started with an investigation: What is service design, anyway? This was when I realized that I had always assumed to know what service design is, but – maybe like a few other people, too – I hadn’t really thought about where it differs from, let’s say, user experience design. Because it is tricky: Depending on how you define service design, it can actually be quite hard to distinguish it from other fields. User experience design? Customer experience design? Digital service design? Where do all these terms overlap and what, in the end, constitutes service design? Or, in Jeremy’s words: “Maybe I should draw a diagram.”

At its core, service design is the design of every aspect of a customer journey, including every possible touchpoint, physical products, and also human interactions, for example, with service personnel. This sounds like service design is literally everything. And it reminds me a lot of the charming video of Don Norman talking about the term “User Experience”:

So where is the difference between user experience design and service design, then? The answer lies in the respective names: User experience design is all about the user. Who is she? What are her needs, wants, and problems? All the research and all the consecutive design work are focussed on creating a good experience for the people who are using the product – or service. Service design goes one layer deeper though. Think about what is necessary for a good service: Imagine you are sitting in a café. You order an espresso and a chocolate cake. In order for both things to arrive at your table in great quality and in time, a friendly waiter is not enough. From the person operating the coffee machine to the quality of the coffee beans to the people in the kitchen and how well they work together – everything about the service, including the things a customer can’t see, has to be well-orchestrated and carefully organized.

While user experience design focuses primarily on the experience of using the product or service, service design focuses primarily on the design of the service in the background – with all the people and processes involved – which makes a good user experience possible in the first place. An often-used metaphor in service design is that of frontstage vs. backstage: Depending on whether a component of a service is happening in front of or behind the curtain, it may be visible to the user or not. Yet underlying structures, processes, technologies, principles, corporate culture, and the “experience of the employee” ultimately define the quality of the service. This does not only make a lot of sense but it also makes me want to delve into service design a bit deeper in the future.

Lou Downe’s 15 Principles of Good Service Design might be a good starting point.

-

This is the 41st post of my 100 days of writing series. You can find a list of all posts here.

Problems come in two flavors. There are the problems we know how to solve, or at least know that there is a solution to them. Like mathematical equations, for example, or beating another chess player in five moves. For those problems, the mission is clear. And then, there are “wicked” problems. Wicked problems are problems that don’t have an immediate, obvious solution to them. They are complex, messy, full of unknown unknowns, and thus difficult to solve, often even unsolvable. Solutions to wicked problems are also not right or wrong, but rather good or bad. Wicked problems include all kinds of economic, political and societal issues, healthcare, the COVID-19 crisis, climate change, urban development, education, poverty, or social justice. But also: Design.

Design is a wicked problem because we have to deal with the complexity of changing contexts, unpredictable user behavior, differing stakeholder interests, and new technologies and materials all the time. But more importantly, design is a wicked problem because at the very moment we start, we have no idea how an appropriate solution might look like. Be it a music streaming service, a corporate website, or an interface for an elective stove – neither do we know upfront how the final solution has to look like, nor does a “right” solution exist. The solution can be a good or bad solution. But which one it will be in the end, will be determined by the process and the decisions we make along the way.

Too many teams and agencies, though, approach design with a technical rationality that just doesn’t fit the true nature of design as a wicked problem. They plan project timelines with distinct phases, work in linear workflows with static layouts, and hope to increase the efficiency of their processes over time. Yet, how can you become efficient at solving problems that are messy and different every time? Once you truly understand that design is a wicked problem, it becomes obvious that we have to approach design differently. Design is not chess. Truly “efficient” design is a result of a more flexible approach that lets us explore and evaluate different solutions, that leaves room for the emotional, irrational, surprising aspects of good design, and that lets us constantly redefine the problem space once we have learned more about our problem. Because if design is a wicked problem, we only have found a solution when we have successfully defined the problem.

-

This is the 40th post of my 100 days of writing series. You can find a list of all posts here.

Although you should not mess with scrolling unless it is really necessary, scrolling an element into view is something that is needed from time to time. In my case, I recently wanted to scroll to the top of a table after a user clicked on the pagination underneath the table. One way to scroll to an element is to use the good old anchor link. While this is by far the most reliable and resilient option to scroll an element into view, it is not always possible and you have to rely on a bit of JavaScript instead. For a long time, the most reliable way to do this was to use jQuery and scroll the body to the top offset of the element you want to scroll into view:

$('html, body').scrollTop($(element).offset().top);

If you want to have a smooth scroll animation as well, you could use jQuery’s animate() function like so:

$('html, body').animate({
    scrollTop: $(element).offset().top
}, 500);

Here is a Codepen for this example:

See the Pen Scroll Into View – with jQuery by Matthias Ott (@matthiasott) on CodePen.

A Native, Modern Solution

While you could still do it that way, times have changed and modern browsers now come with native behaviors that can provide better alternatives to jQuery or other third-party scripts. This lets you save one dependency and, in the case of animate(), you might even end up with superior browser performance.

One way to scroll an element into view with native browser APIs is to rewrite the jQuery solution above so that it only uses element properties available in the browser:

// Get the size and position of our element in the viewport
var rect = element.getBoundingClientRect();
// The top offset of our element is the top position of the 
// element in the viewport plus the amount the body is scrolled
var offsetTop = rect.top + document.body.scrollTop;
// Now we can scroll the window to this position
window.scrollTo(0, offsetTop);

As you can see, we have achieved the same result with only three lines of code and both Element.getBoundingClientRect() and Window.scrollTo() have full browser support. But one thing is still missing: The animation. There are two ways we can add smooth scrolling to this solution. The first is to use the native CSS feature scroll-behavior:

html {
  scroll-behavior: smooth;
}

Again, have a look at the Codepen for this example:

See the Pen Scroll Into View – with CSS scroll-behavior: smooth by Matthias Ott (@matthiasott) on CodePen.

Nice! Still no need to mess around with JavaScript animations and we have a robust, progressively enhanced solution. Setting scroll-behavior to smooth will also work for anchor links, by the way. There is only one caveat: Some browsers, like Internet Explorer and Safari, don’t support scroll-behavior yet.

So if you want to support those browsers, too, you might want to use element.scrollIntoView instead:

element.scrollIntoView({ behavior: 'smooth' });

Browser support for scrollIntoView is good, but a few browsers like – you guessed it – IE and Safari don’t support the smooth behavior option. But fear not, there is a polyfill available that adds this functionality to those browsers.

Play around with this Codepen if you like:

See the Pen Scroll Into View – with element.scrollIntoView by Matthias Ott (@matthiasott) on CodePen.

Scroll Into View With GSAP

There is one more interesting option to achieve our scroll into view, and that is using the Greensock Animation Platform, aka GSAP, a JavaScript animation library. Let’s say you want to use hardware-accelerated animations in other corners of your site, too, then it can be a good idea to use GSAP to handle the scrolling as well. For one, you can stick to one solution and don’t have to jump from GSAP to element.scrollIntoView and back, but you will also be able to use a timeline in GSAP and easily combine the scroll animation with other animations.

The scroll position of the window can be animated in Greensock with the help of the ScrollToPlugin:

gsap.to(window, {duration: 0.75, scrollTo: element});

Another advantage of using Greensock is that you have more control over the animation timing and the easing functions, meaning the style of animation, and can make your animation really smooth and fine-tune it to your needs.

gsap.to(window, {
    duration: 1.2,  ease: "power4.inOut", scrollTo: element
});

Here, we are using a slightly slower animation with a nice, soft easing curve. Play around with this Codepen to try how the animation feels. If you are unsure which easing functions are available in GSAP, try the Ease Visualizer.

See the Pen Scroll Into View – with Greensock (GSAP) by Matthias Ott (@matthiasott) on CodePen.

What about A11y?

Depending on how much you scroll around, scroll around, scroll up, scroll up, and scroll down on the site, you will have to make sure that keyboard users don’t get lost. If you change the scroll position via JavaScript, keyboard focus might still not be updated. So when the user starts to navigate again, the site jumps back to where it was before you triggered the scrolling. Heather Migliorisi has written a nice post for CSS-Tricks about what to look for to make sure you build an accessible solution.

Another problem can be that people with a vestibular disorder can get sick when a site moves around too fast. And while those people can opt-out of playing video games that could become dangerous for them, visiting your site should not trigger motion sickness or an epileptic fit. One solution with good browser support is the prefers-reduced-motion media query (1, 2):

html {
  scroll-behavior: smooth;
}

@media (prefers-reduced-motion) {
  html {
	  scroll-behavior: auto;
	}
}

If you want the learn more about designing web animations for motion sensitivity, Val Head has written an excellent post for A List Apart.

And that’s it for today. If you have found other or even better ways to scroll an element into view, let me know. And if you found this post interesting, share it with your friends.

-

This is the 39th post of my 100 days of writing series. You can find a list of all posts here.

Much like every other weekend, I spent several hours cleaning the apartment this Sunday. Although I enjoyed the result of it, I had always looked at cleaning as a tedious task. Yet, I have come to enjoy it over the last few years. This is because I have started to listen to talks, podcasts, and audiobooks while I’m emptying the dishwasher, vacuuming the floor, or scrubbing the toilet. The combination of doing a physical task over and over again, while opening your mind to the thoughts and stories of others, is an intriguing combination for me. It helps me relax and clear my head of the things that occupy my thinking over the rest of the week. I now enjoy it so much that I even forget time while I’m cleaning and am already looking forward to the next weekend, once I am done.

What am I listening to? I really don’t care as long as it seems to provide a fresh perspective on a topic I’m interested in or is about something entirely new. The latest podcasts and books I listened to include Tim Ferriss’ Tribe of Mentors, Ted Chiang’s Exhalation, a collection of short stories, Carmine Gallo’s Talk Like TED, Haruki Murakami’s What I Talk About When I Talk About Running, and interviews with Jenna Levin, Tea Uglow, Derek Sivers, and many more.

To some people, listening to all those interviews and books might appear to be a useless pastime. But I have long believed that there is no such thing as useless knowledge. For one, you simply can’t consume only useful content. How would someone even know what qualifies as “useful” over a longer period of time? But more importantly, new ideas are born from combining existing ideas in new ways. So the more you know, the larger the possibility that two seemingly unrelated ideas connect. What is better than broadening your mind by absorbing the experiences, habits, and dreams of others, then? (Okay, travel might be. But that’s not so easy at the moment – in particular, while vacuuming.)

So I try to read, watch, listen to, and observe as many things as possible, and don’t worry if something isn’t useful at this very moment or for a current project. Your next idea might be hidden in an interview with a physician or a short story about time travel. You never know. So stay curious. What seems useless today might turn out to be useful tomorrow.

-

This is the 38th post of my 100 days of writing series. You can find a list of all posts here.

I knew it would happen again. The fear. The tunnel vision. The blackout.

Only a few seconds left. I don’t want to be here.

“Next is Matthias, who will play the first movement of Mozart’s Piano Sonata No. 11 for us.”

Applause!

I can’t think straight. The tunnel vision is here now. What if it happens again? It will happen again, for sure. But I have to go.

I walk over to the piano. It feels like I’m dreaming. My piano teacher smiles at me. He is great. Patient, caring, and relaxed. “It will all work well, Matthias. You’ll see. Good luck!” His voice is calming.

I cast a glance at the audience. I search for my family. There they are. My grandmother is smiling blissfully at me.

I start playing. My hands are shaking and are reminding me of what is going to happen. For the first bars, it works quite well. I can hear my own play but it sounds muted. Everything is disconnected. Am I still in control? Then, the first wrong note. Did they notice? Another one. This is the passage I just managed to play through a few days ago. It will happen again. And because I play everything by memory, I won’t have the notes as my lifeline. There it is. Now. The blackout.

Everything is gone. No notes. Only emptiness. My heart is in my mouth. Okay, calm down. Try to remember. Just start the last passage again. Come on. But I can’t. It’s gone. I’m paralyzed. What. I…

~

I can’t recall how many piano recitals I had during the ten years I played the piano. But in my memory, I had a blackout in almost every one of them. I was terrified of playing in front of an audience.

In hindsight, I simply wasn’t prepared well enough. If I had practiced more before a concert, I surely would have been able to play through the fear. At least that is what I have learned in the meantime: Preparation is everything. But tell that to a fourteen-year-old who would rather play football with his friends or change the boot screen of Windows 95 in logo.sys. In my head, I was the guy who just could not perform well in front of an audience. How could a little more preparation change that?

~

This week, I successfully finished my first fully remote workshop for Adobe on designing and prototyping with Adobe XD. Over the last few years, I have now run dozens of workshops, gave a few occasional talks in front of up to 100 people, was part of live webinars with hundreds of people watching, and taught hundreds of students in my Interface Prototyping seminar. With every lecture, workshop, and talk, I became a little bit more confident. I am still nervous every single time, though, and I’m sure this won’t ever go away. But I know now that I am not alone in this and that if I’m prepared and know my material, it is going to go well.

But more importantly, I know today that no matter how well-prepared I am, it might still happen that something goes wrong. Yet, I will always make it out of the arena alive. So I take a deep breath and focus again. There are also a few “hacks” and helpful advice I received which helped me a lot:

• People in the audience are generally on your side. If you struggle, they will empathize with you. Especially if you smile and are genuine and honest. 🤗
• Nervousness is also a good sign: It shows that you are taking the challenge seriously and that you and your body recognize how special the situation is. If you acknowledge this and transform it into focus, nervousness can actually be helpful to identify the moments you need to focus.
• So if you are nervous, also be brutally honest with yourself: Are you prepared enough or is there anything else that you could do to be better prepared still? Often, this helps to reduce anxiety further.
• What happens in your body when you are nervous and anxious is actually similar to moments when you feel excitement. So try to embrace your anxiety and transform this energy into excitement. This is a special moment, so you have every reason to be excited!
• Nobody knows your agenda and what you want to say. So don’t worry if you forget something or say something that you know could be explained better.
• Our bodies and postures influence our emotions and our thinking. Changing your body position changes your body chemistry and how you feel. If you do a power posture right before an event, for example, you will feel more confident. If you force yourself to smile, you will feel more relaxed and happy. Try it, it works.
• There is no alternative to being vulnerable out there. So show up.
• The moments you leave your comfort zone and are most afraid often are the moments you learn and grow the most. Embrace the fear and learn to live with it.

-

This is the 37th post of my 100 days of writing series. You can find a list of all posts here.

The COVID-19 crisis has temporarily shifted our attention away from the most pressing and life-threatening of all challenges: Climate change. But while we – at least in Europe and other parts of the world with responsible leadership – are on a flattening curve, the issue of the rapidly accelerating climate crisis is surfacing again. The CO2 in Earth’s atmosphere is nearing levels of 15 million years ago, Siberia saw a record-setting hat wave with up to 38 °C, Arctic sea ice coverage is the second-lowest on record, and 2020 is on course of becoming the hottest year ever.

The more you read up on the topic, the more you realize that the current trajectory points to the elimination of humanity. This might sound pessimistic or overly alarmist but it really is the path we are on of we don’t change how we produce and consume energy as a species. Radically. Given that, despite all the clapping at the Paris conference, emissions are still rising and earth’s nations are far from taking joint action, it is easy to fall into a doomsday depression, though. What can we do anyway? We are all dead already. Humanity won’t make it.

But that would be giving in to exactly the complacency that brought us into this situation in the first place. And it would also strip us from the last chance we have. Every action we take now will mitigate the consequences of global warming over the next decades and centuries. So it is important to hear about the things that are already changing. That many companies and governments are already working on finding solutions and that renewable electricity is increasingly cheaper than any new power capacity based on fossil fuels, for example.

In an interesting conversation with TED’s Chris Anderson, Al Gore gives many more reasons to be optimistic: We are already at the cusp of a beginning transformation of manufacturing, transportation and agriculture and a generation of young leaders is pressing for much-needed change. It is up to each and every one of us to do their part in pulling this off and preserving our planet for future generations – one of which might be the next generation, already.

-

This is the 36th post of my 100 days of writing series. You can find a list of all posts here.

As we gain more and more experience in building digital products, we tend to think ever so often that we already know what a good solution looks like and how people will use our design. But that’s not true. Far too often, we are assuming that things work in a certain way or that users will understand our intentions – but we’re wrong. A classic case of the Curse of Knowledge.

But, as Ida Aalen explained in a great talk at CSS Day, this often also works the other way round: Things that experts consider too hard to understand for users, actually work quite well when put to the test. Ultimately, when we base decisions on assumptions and our own experience and opinions alone, they will always be heavily biased. The only way to really know if a solution is valid is to test it.

So don’t assume that people will get how your nice carousel interface works. Test it with a prototype. Don’t assume that your API responses will be fast enough to provide a great experience. Test it with a prototype. Don’t assume that your typography is easy to read. Test it with a prototype – on real devices. Only by validating your design you will be able to tell if you’re really building the right thing.

-

This is the 35th post of my 100 days of writing series. You can find a list of all posts here.

Remember that thing you wanted to learn? You know what I mean. That thing that keeps on nagging in the back of your head. That thing that comes to mind now and then and reminds you that there are so many things that you could explore. You know it would be interesting and, almost certainly, fun to learn it. But somehow, you never started.

Learning to draw. Learning to sing. Learning to write. Learning to debate. Learning to speak in public. Learning to say no. Learning to design. Learning to code. Learning to fly.

There are so many opportunities to learn out there. Yet most of the time, we seem to learn only the things that are really necessary at this very moment. Suddenly, learning something becomes essential for survival. When there are no excuses and no alternatives, learning something and staying at it is suddenly much easier.

So if you want to learn something, create necessity. Start a small project that presents you with real challenges and problems to solve. Sign up for a course, book a workshop, set yourself a deadline. Find something that excites your curiosity and is endlessly interesting but also lets you work hands-on and solve real problems as you go. You’ll discover that it is now much easier to overcome the first hurdle of learning something: Getting started. And you’ll discover that only by having to solve real problems, you’ll go deep and learn by experience – which is where true learning happens.

Necessity is the ultimate teacher.

-

This is the 34th post of my 100 days of writing series. You can find a list of all posts here.

Ethan Marcotte just wrote a great piece about design systems and how the promise that design systems would hugely improve collaboration between designers and developers never really materialized. Many teams are still working in silos, which means there is a clear separation between design and development teams. And, as Ethan points out, while our tools might have become better in supporting collaboration within the respective fields, many of them still fall short of closing the gap between the disciplines. There are a few exceptions to this rule, of course. Some design tools let designers pull in data from JSON files or APIs into their prototypes, for example, with plugins like Data Populator for Sketch and Adobe XD. Other tools like Framer or Supernova Studio tightly integrate visual design and prototyping features with production-ready code. Yet these tools are very much focused on certain technologies and frameworks and are therefore still limited to specific use-cases and projects. Not every project is built with React, for example.

Design systems shine in providing consistency and reliability. This alone makes them a tool worth investing in. But why do they often fail to provide the communicative link that closes the gap between design and development? What else could provide that link? And yet another interesting question: Do companies and teams even understand why close communication is the way to go in the first place? After all, change will only occur when there is enough understanding but also pain and pressure to leave the seemingly safe harbor of the status quo.

Designing and Making

If you want to build great products and services, designing and making really should be inseparable. The closer designers and engineers work together, the more they can work with and around the constraints of the material and come up with solutions that are thoroughly designed and engineered down to the last detail. This works because designers are less likely to design solutions that don’t respect underlying technologies, while engineers at the same time develop a deeper understanding of the importance of creating work that combines great engineering with the subtle nuances and design details that create great experiences.

Many organizations realize that a lot of their products don’t come out as expected and that collaboration and the flow of information between design and engineering needs to be improved. Yet their answer often seems to be to increase the complexity of the systems between us. They put stringent processes in place, require more documentation, or establish a sophisticated design system to save the day. Meanwhile, designing and making are still separated.

People over Processes

I get that we need a certain level of consistency and professionalism. And that it is human nature to prefer solutions that provide safety. But when it comes to collaboration, tools alone won’t save us. The most vital factor of good team collaboration is and always will be: People. How good they understand each other and their respective fields of expertise. How much they listen and try to understand each other’s perspectives. How much they learn from, inspire, and challenge each other. How much they trust and rely on each other. And how much they share common values and goals. When it comes to ingenuity and collaboration, a design system will only take you so far if you only see it as a tool. Yes, a design system could foster collaboration. And it could improve mutual understanding. But a design system in itself will not make up for poor team dynamics and interactions.

So instead of relying on processes and tools to fix team communications for us, we should mix our teams, remove the separations between departments, bust the silos. Smaller teams communicate better and often arrive at outstanding solutions much faster, especially if interdisciplinary team members know their talents well and supplement each other. The flexibility of a small team will also make it easier to deal with uncertainty and complexity – a much-needed skill in today’s fast-changing world of technology.

Complex vs Simple

We still need systems that enable communication, of course. But instead of trying to build complex systems from scratch, it might be smarter to first focus on establishing workflows and processes that reduce the friction to communicate and are as simple as possible. Always remember Gall’s law:

Ask yourself: What is the simplest way to communicate? What is the simplest way to document our work? What is the simplest way to make changes to our product? What is the simplest way to test our assumptions and develop new ideas together? What is the simplest way to combine designing and making? Building a lot of prototypes in a small, interdisciplinary team can be one answer to those questions. Slowly building up a design system based on shared practices could be another one. And there are certainly many more.

With DevOps and DesignOps, we are already addressing the challenge of working and communicating within the separate teams. Maybe it is time to focus on “TeamOps” next.

-

This is the 33rd post of my 100 days of writing series. You can find a list of all posts here.

The kids wanted pancakes. But there was only one egg left. Usually, I use four eggs to make pancakes. But the kids wanted pancakes. So I made pancakes. With only one egg.

They turned out delicious.

Sometimes, one egg is enough.

Sometimes, you should just try although the conditions seem less than ideal.

-

This is the 32nd post of my 100 days of writing series. You can find a list of all posts here.

For me, 2020 started with a few posts about writing. I had read and listened to a lot of material on writing and wanted to share some of the things I had learned about how other writers approach writing as a craft, a process, and a passion. So I wrote posts about shitty first drafts, about not caring too much about what others say, and about the difference between Diamond Polishers and Vomit Drafters.

There are still a few shitty drafts left in my drafts folder, so I will definitely share more thoughts on writing from time to time. Yet, while I wrote a lot about the process in general, writing about my very own process is still not so easy. Mostly, because I don’t have one, at least not a very strict one. There is, though, one simple but extremely effective piece of advice which I was just reminded of by a wonderful interview with writer Roxane Gay:

When you are done with your text, read it out loud.

For me, this has become one of the most effective techniques to check how well a text works. I do it every single time. Reading a text out loud will surface all the tiny details that you tend to overlook when you read it quietly. Maybe you misspelled a word, or a sentence is too long or overly complicated. Or, it doesn’t make any sense at all. Is everything comprehensible, are the transitions working, and do the pauses between paragraphs feel right? You will recognize so much more once you read your text out loud. Because you shift your perspective a bit and actually hear how your text might sound in the head of a reader. You can totally use your news anchor voice for this, or your Jony Ive voice, if you happen to have one, too. And ideally, you even read your text with the rhythm and emphasis you intended. If the kids are asleep or you don’t want to wake up the sleeping dog, maybe turn down the volume a bit. But read your text so that you can hear your voice. I can almost guarantee you that it will improve the quality of every piece you write.

-

This is the 31st post of my 100 days of writing series. You can find a list of all posts here.

As a child, teenager, and student, I used to play a lot of football (or soccer, for my American friends). I only played in a club for about two years and had to quit the team because of an injured knee, but I always loved playing with my friends during my leisure time. Spending a whole afternoon running up and down a badly mowed pitch was pure bliss. So many bad plays, so many bad passes, so many untrained bodies. But also so much passion, energy, and dedication. And the joy when one play or goal suddenly turned out to be a work of art. When a brilliant pass was played. When I tried a bicycle kick and somehow volleyed the ball into the net. (Yes, this really did happen at times. And it also hurt almost every time, especially as I got older and started to miss the ball more often…)

I played for that joy. For those moments of intuitive flow. But there is also one thing I learned from playing football: If you want something too hard, it won’t happen. On some days, I would walk over to the pitch full of energy and ready to play a good match. Scoring some goals, doing many precise and some surprising passes, and helping the team win with a great performance. I really wanted it! But on those days, it often just didn’t work, somehow. As much as I tried, many passes were just a bit off. Instead of going in, the ball hit the post – or (almost) the sky. Putting in more effort only resulted in more frustration.

Something was missing on those days: relaxation. If you want to be at your best, going for 100 percent often won’t help. You need the right level of relaxation and ease to avoid frustration and early fatigue. You need the right level of relaxation to keep a clear mind and have focus and confidence and to leave room for intuition. In a recent interview, Hugh Jackman talked about the 85 percent rule: The rule says that sprinters and other athletes perform best when they are at 85 percent of their maximum performance capacity. At 100 percent, your muscles might be over-stressed too fast and the risk of injury grows exponentially. But more importantly, at full speed, “technique and form go out the window”. So by scaling back a bit, you can actually be faster and maintain your speed longer.

I experience the same in other areas of life and work. When there is a tight deadline, for example, you will achieve the most not by stressing out, pushing harder, and running at full speed but by actually going at a fast but steady rate that keeps you in a position where you are still able to focus and make conscious decisions. 85 percent is still really fast. But it is not so fast that you’ll be unable to see the forest for the trees.

-

This is the 30th post of my 100 days of writing series. You can find a list of all posts here.

Sarah Drasner just published a fabulous article, In Defense of a Fussy Website, in which she makes the case that we should all design and build websites again that are a joy to visit. Sites with those little details that make you smile, with small delights and touches that really make users stay.

Sarah is so right: The Web is becoming more and more homogenous and unimaginative. The websites of today are primarily built with efficiency and usefulness in mind, but in turn, they often lack the creativity, playfulness, and dedication that make a site stand out and a joy to interact with.

What happened to the rampant playfulness of the early web and the Flash era? Back in the late 90s and early 2000s, the visual language of the Web was still developing but also so refreshing. Almost every website – even though a fair amount looked quite questionable by today’s standards – had their very own character and distinct charm to it. Now, almost all websites look the same. How did we end up here?

In the search for answers, it makes sense to take a look back at the history of a related profession that once faced a similar challenge: graphic design. After the iconic graphic designer Milton Glaser died this Friday, I listened to a few interviews he gave over the last years. At one point, he talked about how he perceived the state of graphic design earlier in his career, in the late 1960s. After the constructivists and modernists had dominated the visual language of design for several decades, everyone was striving to create design that was rational, functional, and formalistic. Design that was aimed at accomplishing a specific goal. Design that was promotional and persuasive. For him, this wasn’t enough. He wanted to create design work that would also speak to the other, the emotional part of the brain. Design that would tell a story and create affection, just like art. Affection not only for the work itself but also for the world at large.

According to Milton Glaser, “the most corrosive thing about the relationship between design and the public has been the idea that design is a manifestation of promotion and advertising.” And the marketing people, who came to dominate the landscape, were looking only into the past, trying to collect metrics that would reduce uncertainty and risk. As a result, design had become merely a means to an end.

It seems to me that the same can be said of today’s Web: Websites are primarily seen as functional software, built to fulfill a business objective and to reach quantifiable goals. The field of user experience is obsessed with KPIs, jobs-to-be-done, optimized user flows, and conversion rates. And in quest of ever more efficient processes – and in the spirit of true modernists –, design and development teams try to standardize solutions into reusable templates and components, streamlined pattern libraries, and scalable design systems. Don’t get me wrong: The establishment of design systems, of all the professionalization that has happened in the web design community at large, is a great thing. It’s an important advancement of a still very young profession. But maybe we are now at a point, where we must acknowledge that it is time for us to take the next step. We know how to design and build sites that have sufficient function and form. And, although we fall short in this regard, building performant and accessible sites should be perfectly doable by now, too. But this isn’t enough. We have to go beyond that. We have to take risks, tell stories, do the fussy work, and create affection to do work that does not only meet standards but exceeds expectations and surprises. We have to go deep and use our imagination. Not only for ourselves, but for the people who get to use our sites. And for the next generation of designers, developers, and creators on the Web – all those people who might fall in love with the Web, just like we did.

Who could explain it better than, once more, Milton Glaser in an interview with Debbie Millman:

In early life, […] we wanted to be professional, and we wanted our work to look professional. And we wanted it to have that veneer and that sense of authority that we saw around us. And it was all we really wanted to do. We got out of school and we wanted to have your work look like these marvelously put together, slick, effortless things that were in the world and you admired the people who could do that. And then, at a certain point you reach a professional level and your work looks like that and you realize: It’s not enough! That nearly getting to a point where your work looks good enough to be called professional, is only the starting point. I use the same metaphor for learning how to draw. When you start to learn how to draw you are so overwhelmed with the difficulty of making things look like what they are. You know, you have a cup and a saucer and you try to make it sit on the page and look like a cup and a saucer. And you almost die trying to control your nerve endings so that the object looks like it’s supposed to. And you spend years doing that. And finally, you get to the point where you can actually draw something that looks like what you’re drawing. And then, you discover: That’s not the point. That being able to make a drawing that looks like its subject is nothing. That it is only the starting point. Now you have to ask yourself: What can I do? A good drawing? Or an expressive drawing? Or a drawing that means something? Because the ability simply to make it accurate is a low-level ability. Even though it has taken you years to get to that point. And then to discover, it’s not very relevant. But there is no other way to get there.

The same is true of your own work. You sort of strive to make it look good, and make it look good as your peers’, and make it look as good as the other things in the art directors annual, and so on. Then, at a certain point, if you continue and persevere you realize it is not good enough. You have got to go beyond that level in order to engage that other thing, which is true expressive content. True meaning.

-

This is the 29th post of my 100 days of writing series. You can find a list of all posts here.

Milton Glaser, one of the greatest graphic designers of our time, passed away this Friday on his 91st birthday in New York City. Well known for his 1977 “I ❤️ NY” logo and his Bob Dylan poster with psychedelic hair, Glaser changed the visual culture in the 1960s and 70s with his brightly colored, expressive designs and “brought wit, whimsy, narrative and skilled drawing to commercial art at a time when advertising was dominated by the severe strictures of modernism”, as William Grimes writes in his obituary for the New York Times. Glaser designed over 400 posters in his lifetime, was a founder of New York magazine, a strong believer in the power of drawing, and in the obligation to pass on your experience through teaching. In case you want to learn more about him and his work, there is a lovely short film by Hillman Curtis, the documentary “To Inform and Delight”, his illuminating TED talk, and a wonderful interview with Debbie Millman.

In 2001, Milton Glaser put together a list of 10 things he had learned about work and life. The list is available as an essay on his website. But as the site is not optimized for mobile and the text not structured with semantic HTML, I’ll quote it here in its entirety.

Ten Things I Have Learned

1. You Can Only Work for People That You Like.

   This is a curious rule and it took me a long time to learn because in fact at the beginning of my practice I felt the opposite. Professionalism required that you didn’t particularly like the people that you worked for or at least maintained an arms length relationship to them, which meant that I never had lunch with a client or saw them socially. Then some years ago I realized that the opposite was true. I discovered that all the work I had done that was meaningful and significant came out of an affectionate relationship with a client. And I am not talking about professionalism; I am talking about affection. I am talking about a client and you sharing some common ground. That in fact your view of life is someway congruent with the client, otherwise it is a bitter and hopeless struggle.

2. If You Have a Choice Never Have a Job.

   One night I was sitting in my car outside Columbia University where my wife Shirley was studying Anthropology. While I was waiting I was listening to the radio and heard an interviewer ask ‘Now that you have reached 75 have you any advice for our audience about how to prepare for your old age?’ An irritated voice said ‘Why is everyone asking me about old age these days?’ I recognized the voice as John Cage. I am sure that many of you know who he was – the composer and philosopher who influenced people like Jasper Johns and Merce Cunningham as well as the music world in general. I knew him slightly and admired his contribution to our times. ‘You know, I do know how to prepare for old age’ he said. ‘Never have a job, because if you have a job someday someone will take it away from you and then you will be unprepared for your old age. For me, it has always been the same ever since the age of 12. I wake up in the morning and I try to figure out how am I going to put bread on the table today? It is the same at 75, I wake up every morning and I think how am I going to put bread on the table today? I am exceedingly well prepared for my old age’ he said.

3. Some People Are Toxic. Avoid Them.

   This is a subtext of number one. There was in the sixties a man named Fritz Perls who was a gestalt therapist. Gestalt therapy derives from art history, it proposes you must understand the ‘whole’ before you can understand the details. What you have to look at is the entire culture, the entire family and community and so on. Perls proposed that in all relationships people could be either toxic or nourishing towards one another. It is not necessarily true that the same person will be toxic or nourishing in every relationship, but the combination of any two people in a relationship produces toxic or nourishing consequences. And the important thing that I can tell you is that there is a test to determine whether someone is toxic or nourishing in your relationship with them. Here is the test: You have spent some time with this person, either you have a drink or go for dinner or you go to a ball game. It doesn’t matter very much but at the end of that time you observe whether you are more energized or less energized. Whether you are tired or whether you are exhilarated. If you are more tired then you have been poisoned. If you have more energy you have been nourished. The test is almost infallible and I suggest that you use it for the rest of your life.

4. Professionalism Is Not Enough or the Good Is the Enemy of the Great.

   Early in my career I wanted to be professional, that was my complete aspiration in my early life because professionals seemed to know everything - not to mention they got paid for it. Later I discovered after working for a while that professionalism itself was a limitation. After all, what professionalism means in most cases is diminishing risks. So if you want to get your car fixed you go to a mechanic who knows how to deal with transmission problems in the same way each time. I suppose if you needed brain surgery you wouldn’t want the doctor to fool around and invent a new way of connecting your nerve endings. Please do it in the way that has worked in the past.Unfortunately in our field, in the so-called creative – I hate that word because it is misused so often. I also hate the fact that it is used as a noun. Can you imagine calling someone a creative? Anyhow, when you are doing something in a recurring way to diminish risk or doing it in the same way as you have done it before, it is clear why professionalism is not enough. After all, what is required in our field, more than anything else, is the continuous transgression. Professionalism does not allow for that because transgression has to encompass the possibility of failure and if you are professional your instinct is not to fail, it is to repeat success. So professionalism as a lifetime aspiration is a limited goal.

5. Less Is Not Necessarily More.

   Being a child of modernism I have heard this mantra all my life. Less is more. One morning upon awakening I realized that it was total nonsense, it is an absurd proposition and also fairly meaningless. But it sounds great because it contains within it a paradox that is resistant to understanding. But it simply does not obtain when you think about the visual of the history of the world. If you look at a Persian rug, you cannot say that less is more because you realize that every part of that rug, every change of colour, every shift in form is absolutely essential for its aesthetic success. You cannot prove to me that a solid blue rug is in any way superior. That also goes for the work of Gaudi, Persian miniatures, art nouveau and everything else. However, I have an alternative to the proposition that I believe is more appropriate. ‘Just enough is more.’

6. Style Is Not to Be Trusted.

   I think this idea first occurred to me when I was looking at a marvelous etching of a bull by Picasso. It was an illustration for a story by Balzac called The Hidden Masterpiece. I am sure that you all know it. It is a bull that is expressed in 12 different styles going from very naturalistic version of a bull to an absolutely reductive single line abstraction and everything else along the way. What is clear just from looking at this single print is that style is irrelevant. In every one of these cases, from extreme abstraction to acute naturalism they are extraordinary regardless of the style. It’s absurd to be loyal to a style. It does not deserve your loyalty. I must say that for old design professionals it is a problem because the field is driven by economic consideration more than anything else. Style change is usually linked to economic factors, as all of you know who have read Marx. Also fatigue occurs when people see too much of the same thing too often. So every ten years or so there is a stylistic shift and things are made to look different. Typefaces go in and out of style and the visual system shifts a little bit. If you are around for a long time as a designer, you have an essential problem of what to do. I mean, after all, you have developed a vocabulary, a form that is your own. It is one of the ways that you distinguish yourself from your peers, and establish your identity in the field. How you maintain your own belief system and preferences becomes a real balancing act. The question of whether you pursue change or whether you maintain your own distinct form becomes difficult. We have all seen the work of illustrious practitioners that suddenly look old-fashioned or, more precisely, belonging to another moment in time. And there are sad stories such as the one about Cassandre, arguably the greatest graphic designer of the twentieth century, who couldn’t make a living at the end of his life and committed suicide.But the point is that anybody who is in this for the long haul has to decide how to respond to change in the zeitgeist. What is it that people now expect that they formerly didn’t want? And how to respond to that desire in a way that doesn’t change your sense of integrity and purpose.

7. How You Live Changes Your Brain.

   The brain is the most responsive organ of the body. Actually it is the organ that is most susceptible to change and regeneration of all the organs in the body. I have a friend named Gerald Edelman who was a great scholar of brain studies and he says that the analogy of the brain to a computer is pathetic. The brain is actually more like an overgrown garden that is constantly growing and throwing off seeds, regenerating and so on. And he believes that the brain is susceptible, in a way that we are not fully conscious of, to almost every experience of our life and every encounter we have. I was fascinated by a story in a newspaper a few years ago about the search for perfect pitch. A group of scientists decided that they were going to find out why certain people have perfect pitch. You know certain people hear a note precisely and are able to replicate it at exactly the right pitch. Some people have relative pitch; perfect pitch is rare even among musicians. The scientists discovered – I don’t know how - that among people with perfect pitch the brain was different. Certain lobes of the brain had undergone some change or deformation that was always present with those who had perfect pitch. This was interesting enough in itself. But then they discovered something even more fascinating. If you took a bunch of kids and taught them to play the violin at the age of 4 or 5 after a couple of years some of them developed perfect pitch, and in all of those cases their brain structure had changed. Well what could that mean for the rest of us? We tend to believe that the mind affects the body and the body affects the mind, although we do not generally believe that everything we do affects the brain. I am convinced that if someone was to yell at me from across the street my brain could be affected and my life might changed. That is why your mother always said, ‘Don’t hang out with those bad kids.’ Mama was right. Thought changes our life and our behavior. I also believe that drawing works in the same way. I am a great advocate of drawing, not in order to become an illustrator, but because I believe drawing changes the brain in the same way as the search to create the right note changes the brain of a violinist. Drawing also makes you attentive. It makes you pay attention to what you are looking at, which is not so easy.

8. Doubt Is Better Than Certainty.

   Everyone always talks about confidence in believing what you do. I remember once going to a class in yoga where the teacher said that, spirituality speaking, if you believed that you had achieved enlightenment you have merely arrived at your limitation. I think that is also true in a practical sense. Deeply held beliefs of any kind prevent you from being open to experience, which is why I find all firmly held ideological positions questionable. It makes me nervous when someone believes too deeply or too much. I think that being skeptical and questioning all deeply held beliefs is essential. Of course we must know the difference between skepticism and cynicism because cynicism is as much a restriction of one’s openness to the world as passionate belief is. They are sort of twins. And then in a very real way, solving any problem is more important than being right. There is a significant sense of self-righteousness in both the art and design world. Perhaps it begins at school. Art school often begins with the Ayn Rand model of the single personality resisting the ideas of the surrounding culture. The theory of the avant garde is that as an individual you can transform the world, which is true up to a point. One of the signs of a damaged ego is absolute certainty.Schools encourage the idea of not compromising and defending your work at all costs. Well, the issue at work is usually all about the nature of compromise. You just have to know what to compromise. Blind pursuit of your own ends which excludes the possibility that others may be right does not allow for the fact that in design we are always dealing with a triad – the client, the audience and you. Ideally, making everyone win through acts of accommodation is desirable. But self-righteousness is often the enemy. Self-righteousness and narcissism generally come out of some sort of childhood trauma, which we do not have to go into. It is a consistently difficult thing in human affairs. Some years ago I read a most remarkable thing about love, that also applies to the nature of co-existing with others. It was a quotation from Iris Murdoch in her obituary. It read ‘Love is the extremely difficult realization that something other than oneself is real.’ Isn’t that fantastic! The best insight on the subject of love that one can imagine.

9. On Aging.

   Last year someone gave me a charming book by Roger Rosenblatt called ‘Ageing Gracefully’ I got it on my birthday. I did not appreciate the title at the time but it contains a series of rules for ageing gracefully. The first rule is the best. Rule number one is that ‘it doesn’t matter.’ ‘It doesn’t matter what you think. Follow this rule and it will add decades to your life. It does not matter if you are late or early, if you are here or there, if you said it or didn’t say it, if you are clever or if you were stupid. If you were having a bad hair day or a no hair day or if your boss looks at you cockeyed or your boyfriend or girlfriend looks at you cockeyed, if you are cockeyed. If you don’t get that promotion or prize or house or if you do – it doesn’t matter.’ Wisdom at last. Then I heard a marvelous joke that seemed related to rule number 10. A butcher was opening his market one morning and as he did a rabbit popped his head through the door. The butcher was surprised when the rabbit inquired ‘Got any cabbage?’ The butcher said ‘This is a meat market – we sell meat, not vegetables.’ The rabbit hopped off. The next day the butcher is opening the shop and sure enough the rabbit pops his head round and says ‘You got any cabbage?’ The butcher now irritated says ‘Listen you little rodent I told you yesterday we sell meat, we do not sell vegetables and the next time you come here I am going to grab you by the throat and nail those floppy ears to the floor.’ The rabbit disappeared hastily and nothing happened for a week. Then one morning the rabbit popped his head around the corner and said ‘Got any nails?’ The butcher said ‘No.’ The rabbit said ‘Ok. Got any cabbage?’

10. Tell the Truth.

    The rabbit joke is relevant because it occurred to me that looking for a cabbage in a butcher’s shop might be like looking for ethics in the design field. It may not be the most obvious place to find either. It’s interesting to observe that in the new AIGA’s code of ethics there is a significant amount of useful information about appropriate behavior towards clients and other designers, but not a word about a designer’s relationship to the public. We expect a butcher to sell us eatable meat and that he doesn’t misrepresent his wares. I remember reading that during the Stalin years in Russia that everything labelled veal was actually chicken. I can’t imagine what everything labelled chicken was. We can accept certain kinds of misrepresentation, such as fudging about the amount of fat in his hamburger but once a butcher knowingly sells us spoiled meat we go elsewhere. As a designer, do we have less responsibility to our public than a butcher? Everyone interested in licensing our field might note that the reason licensing has been invented is to protect the public not designers or clients. ‘Do no harm’ is an admonition to doctors concerning their relationship to their patients, not to their fellow practitioners or the drug companies. If we were licensed, telling the truth might become more central to what we do.

-

This is the 28th post of my 100 days of writing series. You can find a list of all posts here.

If you have kids, you think a lot about how the world might look like when they grow up.

At the moment, the world is being transformed on so many levels and so rapidly that, as Seth Godin argues, we might be in the middle of a change that is as big as the change that marked the end of modernity. This new era we are heading into is, for one, characterized by the ubiquity of connection and communication. Everyone and everything can and will be connected and communication is everywhere. With this comes the synchronization of culture and information – but also the ubiquity of opportunity.

At the same time, we are about to witness a transformation of work, where computers and robots will take over all tasks that can be described and translated into repeatable processes. Infinitely trainable, infinitely patient, and, soon enough, infinitely cheap. Ubiquitous robotics. A development that will not only make a great number of jobs obsolete but also raises questions of ethics.

Finally, and by far the most terrifying of all challenges that lie ahead of us, because it is both irreversible and ubiquitous: climate change. The result of local pollution and economic growth becoming a global, ubiquitous problem fueled by more and more humans on the planet and a lack of innovative energy technologies and political inaction as a result of competing interests, lobbyism, greed, and fear.

The Web plays a crucial role in facing all of those challenges. Because the Web, just like the Internet as its underlying structure, is ubiquitous and therefore provides the only layer of communication infrastructure that is able to spread ideas and discussions to the global level and scale solutions to the necessary extent. Without the Web working as needed, we will never reach global political consensus as a result of raised awareness and global pressure. The Web is the ubiquitous medium for the new Age of Ubiquity.

To fulfill this function, the Web needs to be accessible, though. Not only in the sense of providing access for everyone, but on the most basic level: The Web needs to be accessible to everyone who wants to participate, who wants to share their knowledge with the world, who is not satisfied with the status quo and ready to change culture and society. Yet instead, we are currently building a Web of superficial distractions that is becoming less and less accessible to future generations. Generations who critically depend on the Web as an open platform.

The Web of today is a Web of the pros. It restricts access to creation with artificial, technological barriers to entry for those with the most open-minded and fresh ideas. It is accessible mostly to those who feel comfortable with the tools and processes they can master. And by that, I mean designers and developers and capital, yes, but also Big Tech. Google, Microsoft, Facebook, Amazon, and Apple not only nurture their very own frameworks and distribution platforms, but they are even on the cusp of taking over the physical infrastructure of the Web. Don’t play by their rules? Access denied.

My son wants to build robots and games. He draws, he writes, and he is full of ideas and hope. One day soon, he will want to build his first website. So might my daughter in a few years. Using the Web will be the most natural thing for them. I hope their Web will still allow them to also create and participate. I hope that they will fall in love with the Web as an accessible and open platform like I did. And I hope that they, and so many others of their generation, will still be able to use the Web to make a change. It is our job to preserve this gleam of hope for them.

-

This is the 27th post of my 100 days of writing series. You can find a list of all posts here.

Do you know the feeling when you know an album so well that you always anticipate the next bar of a song and when the song ends, you can already hear the first beats of the next song playing in your head? The best albums are the ones, where it might take quite a while to get to know the music that well, but even when you seem to know every line and every note, you are still surprised and delighted by new facets every time you listen to it. What a joy!

Real satisfaction comes from going deep into something. From listening to music over and over again. From being deeply immersed in reading. From exploring a topic that interests us not only on the surface by reading a summary, but digging deep into the rabbit hole until we unearth the truly fascinating details. From understanding how something works at its core.

That’s also when we create our best work: When we know something so well that we are able to not only apply our knowledge and use our skills intuitively without much thinking, but also know when to playfully and consciously improvise or vary to create something new. Mastery comes from going deep into something.

Far too often, we only scratch the surface. We try to take shortcuts to understanding and mastery. Take any topic you like: Writing, playing an instrument, drawing, learning a language, astrophysics, medicine, cooking, interaction design, typography, and, of course, HTML, CSS, or JavaScript. Try to master it by only scratching the surface, and you will utterly fail. It’s easy to dismiss it as being overly complicated or “broken” then. Yet, in the end, you just didn’t go deep enough. There are no shortcuts. There is no silver bullet. Go deep.

-

This is the 26th post of my 100 days of writing series. You can find a list of all posts here.

Tim Ferriss just released the audiobook of his book “Tribe of Mentors”. The book contains the answers to 11 questions he sent out to hundreds of the world’s “top performers” from across all possible fields of expertise. In the introduction, which you can also listen to in Tim’s latest podcast episode, he talks about how the book came into being and mentions a question he regularly uses to start any kind of project. It is a question that leads to asking many other good questions:

Whenever we start a new endeavor, we often convince ourselves that things need to be hard, that they need to be sophisticated and at a certain expert-level. Whether it is strategy, design, or development, we tend to believe that something is only worthy of our attention and time if it is expert enough. Otherwise, we feel like cheaters who take the easy way out instead of using the advanced process that real professionals use. This often leads to more work and hardships in the process than necessary and consumes a lot of time and energy that we could use for more important pieces of the puzzle instead.

If it were easy, how would we simplify the checkout flow for our visitors? If it were easy, how would a person who relies on assistive technology navigate our user interface? If it were easy, would we really create layouts for all page types in four different viewport sizes? If it were easy, would we still build this website as a client-side React app? If it were easy, how would a prototype look like to test this idea we have?

Making something easy and crystal clear is hard. But asking the right questions upfront can be more productive than trying to make up for wrong decisions by stressing out later on. Asking “What would this look like if it were easy?” is such a right question. It frees you from the obligation to do things “as we have always done them” and lets you think about a problem in new and unusual ways so you can reframe it and create something truly unique.

-

This is the 25th post of my 100 days of writing series. You can find a list of all posts here.

Writing HTML is hard. At least writing semantically sound, valid HTML is. This might come as a surprise to those who only scratch the surface of what HTML really can do. What can be so hard about a few elements, right? At least it isn’t an object-oriented, multi-paradigm programming language. But as soon as you start to dig deeper you realize that there is a lot to get wrong in HTML.

For one, HTML now contains hundreds of elements. This alone can make it hard to find the right element for the job. But also if you know all the vocabulary, there are many more things to consider. For example, which elements are allowed to be nested within other elements or which attributes a certain element can have. Not to forget accessibility: If we use semantically correct elements, we make sure that our content will be understood by assistive technologies like screenreaders and that our interfaces are usable for everyone. Using a native button element instead of a div when you need a button will not only impress your friends but also add standard styles and accessibility features like focus and additional keyboard events.

So there are a lot of reasons why you should write semantic, valid, accessible HTML. But how do you make sure that your code is error-free? If you are working on a larger team or with a team of content managers, it can be a challenge to maintain a high standard, especially if different team members have a different experience level with HTML.

You can, and this would definitely be the best solution, set up a thorough testing environment where each HTML or accessibility error is flagged immediately. Truth be told, we are far from testing being a priority – or even a sphere of knowledge – for many developers and clients. Also, when you are in an earlier phase of a project, and you are, for example, still prototyping in HTML or building basic HTML templates, you might not yet have an automated testing solution in place.

So how can you still make sure that your HTML is valid? Testing your HTML manually with the W3C Markup Validation Service would be another option. But this can be tedious, too. Wouldn’t it be nice to be able to see HTML errors directly in the browser? This is where CSS comes in. By the very nature of CSS, you are able to filter for elements in the most remote corners of the DOM. And, as it turns out, you can also use it to, at least visually, validate your code by highlighting elements that contain errors.

Adam Argyle posted an example of how this can look like on Twitter the other day:

/* CSS */
:is(ul, ol) > *:not(li) {
  outline: 2px dotted red;
}

In this case, the selector matches all elements that are inside of lists but not a list item li and displays them with a red outline. An outline makes sense because, other than using border, it does not change the size of the box of the element. Adam uses the new :is() pseudo-class, which still has limited browser support. But you could easily write it without :is():

/* CSS */
ul > *:not(li), ol > *:not(li) {
    outline: 2px dotted red;
}

This technique can be used for many more useful things, for example, detecting images without an alt attribute:

/* CSS */
img:not([alt]) { ... }

As a general rule, images should always have an alt attribute to be accessible. When the attribute is set, a screen reader will read the alternative text. And when it is empty, the screen reader will ignore the image. If there is no alt attribute at all, though, the screen reader will read the src attribute instead. Not very useful in most cases.

Ire Aderinokun has written a great post about many more use cases for listing HTML with CSS, like checking for empty interactive elements, unlabelled form elements, or faulty or missing link targets:

/* CSS */
a:not([href]),
a[href="#"],
a[href=""],
a[href*="javascript:void(0)"] { … }

She even created a Chrome extension that combines many of those selectors into a style sheet that you can apply to any web page to check the HTML for accessibility issues.

And there are many more interesting things you could do. For example, checking for the previously mentioned div buttons from hell:

/* CSS */
div[role="button"] { 
  text-decoration: blink; 
  /* Don't actually use blink here, it's a joke. */
}

Or, if you don’t shy away from using gigantonormous selectors, you could check if a span only contains the allowed “phrasing content”, or if some div lover put a lovely div in your span:

/* CSS */
span > :not(abbr):not(audio):not(b):not(bdo):not(br):not(button):not(canvas):not(cite):not(code):not(command):not(data):not(datalist):not(dfn):not(em):not(embed):not(i):not(iframe):not(img):not(input):not(kbd):not(keygen):not(label):not(mark):not(math):not(meter):not(noscript):not(object):not(output):not(picture):not(progress):not(q):not(ruby):not(samp):not(script):not(select):not(small):not(span):not(strong):not(sub):not(sup):not(svg):not(textarea):not(time):not(var):not(video):not(wbr) {
  outline: 3px dashed red;
}

Using CSS to debug all of your code covering all possible ways HTML in which elements could be misused would certainly be overkill. But depending on your project, this technique could still be quite useful to work against the most common and most severe mistakes like missing links or alt attributes. One could even think of having a default debug.css file that contains a standard set of the most useful rules. I think I’ll try that in one of the next projects.

-

This is the 24th post of my 100 days of writing series. You can find a list of all posts here.

It is one of the most emotional and finest moments in “The Last Dance”, Netflix’s documentary series about Michael Jordan and the Chicago Bulls of the Nineties: The interviewer asks Michael Jordan if he thinks that the intensity at which he played the game has come at the expense of being perceived as a nice guy. Jordan looks a bit surprised and uncomfortable, he smiles, then pulls the corners of his mouth down, he blinks nervously. Then, he says:

Michael Jordan was, as his former teammate B. J. Armstrong puts it, “difficult to be around if you didn’t truly love the game of basketball.“ While being a loving son, husband, and father, Jordan showed a different side on the court. He was a heavy trash-talker, a bully, and even got into fights with teammates and, of course, opponents. He wanted to win at all costs and he knew that in order to win, he had to be a leader. For him, this meant “pulling people along” and being a tyrant at times. It was his mentality.

Steve Jobs talked a lot of trash, too. As Apple CEO, he was known for being cruel at times, yelling at employees and board members, and insulting business partners and, of course, the competition. People he didn’t like were most likely “bozos” to him and work he didn’t like was “a piece of shit”. Jobs was as unpleasant as a boss as he was successful.

So, do you have to be a tyrant to be a successful leader? There are still many people who believe this to be true. For them, strong leadership indeed means being authoritarian, controlling, harsh, and unforgiving. What those people don’t understand, though, is that they won’t be successful simply by being a tyrant. Many people, when confronted with authoritarian leadership, will react with resistance. People want to be in control of their lives and make their own decisions. So if you’re a tyrant, many people will push back – and ultimately, you’ll lose them.

But why were Jordan and Jobs still so successful then? At least, they both had a close circle of people who trusted and respected them and would go through fire and water for them. One answer to this question lies in the rest of the response Michael Jordan gave in the interview:

Michael Jordan might have been demanding, but he also demanded the same from himself. He wasn’t only the greatest player who ever played the game, but he also led by example, laser-focused on his goal of winning (yet) another championship. This inspired his teammates and provided them with a vision, a glimpse into the future, and thus a sense of purpose.

The same was true for Steve Jobs. He was known for meticulously preparing and practicing his presentations and walking the extra mile to get the details of a product right. And while he demanded a lot from the people working with him, he was also a strong communicator who believed in challenging ideas together. Believe it or not, he was even able to change his opinion. And most importantly: Many people who worked with him had the sense of working on something larger than themselves.

Both Jordan and Jobs were great leaders not because of but in spite of their tempered nature and demanding mentality. They might have deemed it necessary to be a tyrant at times, but what ultimately drove their success was that they provided people with a vision and a sense of purpose. Being a tyrant might be a strategy that can fix things in the short term and push people to get work done. But in the long term, being a tyrant isn’t that smart, because it undermines your authority and creates an environment of mistrust, frustration, and fear. So unless you are the next Michael Jordan or the next Steve Jobs (and chances are, you aren’t), you better abstain from becoming a tyrant. Instead, create a safe space for people to thrive. Trust them, help them excel and get better, create a sense of purpose – and inspire.

-

This is the 23rd post of my 100 days of writing series. You can find a list of all posts here.

One of the things I’ve been thinking a lot about is how to know when something is ready. A website, an article, a song, a painting – whatever it is, how do you know that it is ripe for publication?

There are many answers to that question and maybe everyone of us has their own answer. When it is complete. When there nothing more to add. When there is nothing more to remove. When I’m tired of looking at it. When it sparkles.

Today, I listened to an interview with Derek Sivers and he gave an answer I’ve found to be true for me as well. Never wait until it’s “ready”:

-

This is the 22nd post of my 100 days of writing series. You can find a list of all posts here.

How many connections are there in a team of two? One, of course. In a team of three? Three, of course. A team of four? Six. A team of five? Ten, already. What about a team of ten people? A team of ten has 66 connections. Yes, sixty-six.

This basic concept of network theory – that the number of connections between nodes in a network increases exponentially – is the basis for Metcalfe’s Law, which states that the impact and usefulness of a network increase significantly the more users it has. Metcalfe’s Law is often illustrated with the example of a fax machine: One single fax machine in itself is useless, but as soon as other people also own fax machines, the value of each machine increases.

Metcalfe’s Law is a blessing when you look at it from the perspective of networks like Twitter or the internet at large. The more users the more useful the network becomes. But in the example above, when we’re looking at a high number of team members, Metcalfe’s Law can actually lead to the opposite. When a team grows, more communication is necessary. In a team of three, it is no problem when everyone is constantly exchanging information with all the other team members. In a team of ten, this becomes basically impossible.

This perfectly illustrates why you can’t simply throw more people at a problem to solve it faster. And there is another challenge: People are not machines. By increasing the team size, you also amplify a complex web of human relations, different personality types, varying goals, experience levels, and skillsets. Managing teams is a challenge and the bigger the team gets, the more difficult this becomes. On top of that, when people have to spend ever more time with being part-time project managers, leaders, communicators, and coordinators, it reduces the time they can devote to products and users. Often, the result is a decline in quality and craftsmanship.

Over the last few years, the role of design within businesses has shifted. Many organizations have come to understand that design has business value and that design maturity is a competitive advantage. As a consequence, they have grown their design teams or started building up an in-house design team in the first place. With their teams evolving, for many organizations questions of how to best organize design teams arise. As a consequence, the practice of Design Operations, or DesignOps, has received more and more attention.

Other than DevOps, which focuses more on the tooling and processes that facilitate great developer experience, DesignOps has a much broader scope: It is now often defined as everything about design work that isn’t designing per se. So it is not only workflows and software, but all the work that you have to do around design to be able to scale design teams while staying effective and maintaining quality.

As Kevin M. Hoffmann points out in his An Event Apart talk on the topic, there is no one right way to do DesignOps. What you have to do to improve the workflows, processes, collaboration, and team culture highly depends on your company, products, and ultimately your team. He suggests that before you define any measures, you should first focus on the values of your company or team. What is it that you can agree on and that defines how you work and what you believe in? Only then, you can go on and ask more operational questions like:

• How do we want to work together?
• How do we know what our design team is working on?
• Does the team work well with other colleagues from development or marketing?
• Does the team have clear goals?
• Are there regular feedback sessions – and how many do we really need?
• Is the team producing work of high quality that meets your standards and is in line with your values?
• How do you find and hire new talent?
• How do you make sure they thrive in your organization?

If you want to learn more about DesignOps, Kevin M. Hoffmann’s talk is a great starting point. What I really like about it is that he focuses not so much on efficiency, which is the darling of many managers and also the main focus of methodologies like agile (“velocity!”), but instead on what should be at the heart of good design and thus DesignOps: People producing outstanding work together. So instead of increasing the speed in which your design teams work, for example, he encourages us to actually give people more time because they will do better work then.

In their effort to improve the operations of their design teams, many organizations put a lot of weight on workflows, tools, and defining processes. Of course, having a clear structure in your team can be of advantage and well-defined workflows can increase productivity, especially when it comes to repetitive tasks. But design work also has a “liberal arts” component to it. To come to innovative solutions, teams need to have a safe space to explore different paths, to think outside the box, to challenge assumptions, and to continuously improve the details of their work. Many of those aspects often go unnoticed if the person in charge of defining workflows focuses too much on efficiency and operations alone.

Finally, to build a strong design team we also need to establish a strong team culture. As Daniel Coyle writes in The Culture Code: The Secrets of Highly Successful Groups, this is best done by building a place where people feel safe and be vulnerable together to establish trust, and by providing a sense of purpose. Only then are teams able to reach their full potential. We should keep that in mind when we continue to think about how we can shape the future of our design teams together.

More about DesignOps:

• “What is Design Ops, and Why Do I Care?” by Kevin M. Hoffman—An Event Apart
• DesignOps 101
• DesignOps Handbook
• A universal theory for DesignOps
• DesignOps, A UX matters column by Janet M. Six
• Mapping Design Operations
• Defining DesignOps — my first 6 months as a DesignOps Manager
• DesignOps: the questions you’re probably asking yourself now

-

This is the 21st post of my 100 days of writing series. You can find a list of all posts here.

There are books that you read once and never open again. There are even more books that you start to read and somehow never finish. I have a lot of them. And there are book with a lot of images in them, so there is not so much to read. I have a lot of them, too. But then, there are a few books which tend to pay you a visit from time to time. Because you are reminded of them, or you walk by and see them sitting on the shelf – and somehow, you just can’t help but start reading a bit. I have such a book that I love coming back to at the moment.

It’s by James Victore and it’s called “Feck Perfuction”.

James Victore is an artist, art director, and designer from New York City who is known for speaking his mind and creating expressive, rebellious pieces, often including rough, bold calligraphy. Feck Perfuction is his manifesto for having “a fucking opinion“ and making things that are wildly creative. Against normalcy, against assimilation, and against Feck Perfuction is a collection of 77 lessons learned, of dangerous ideas, thoughtful, thought-provoking, and challenging. Yet also full of wisdom, humor, optimism, possibility, and confidence. Each lesson is short and snackable, and many are illustrated with collages, drawings, and his signature brush lettering. The main lesson of the book – though definitely not the only one of this nature – is that perfection is not only a myth, it actually often holds us back from starting and finishing our best work:

On its surface, perfectionism seems like it would be a professional advantage, a creative accelerator. But really, as a driver, it hits the brakes more often than the gas. Perfectionism stops you from starting projects—or even relationships – because you are not ready. It stops you from finishing projects because they are never quite right. “When it’s perfect!” Is our defense, but this habitual overthinking leaves us stymied, unable to get over ourselves and just move.

Should you strive for excellence? Of course. Pay attention to details? Yes. But never let “perfect” stop progress. You know what’s better than perfect? Done. Done is better than perfect.

-

This is the 20th post of my 100 days of writing series. You can find a list of all posts here.

Back in design school, I spent days – weeks even – trying to crack the secret code of a given topic. Typography? Once I know all the rules and all the typefaces, I’ll be a well-versed typographer. Logo design? Once I have looked at enough logos to understand what the essence of logo design is, I’ll be able to design great logos myself. Flash? Once I've fully understood all the concepts and methods of ActionScript, I’ll have mastered Flash for good.

Except that there is no secret code. There is only cutting your teeth. There is only doing. There is only practice. There is only learning what you have to learn to get the job done. There is no right or wrong. There is only what works and what doesn’t.

-

This is the 19th post of my 100 days of writing series. You can find a list of all posts here.

There was this strange sound. Clack, clack, clack! Was it coming from the tires? Clack, clack, clack! Just a few minutes after we hit the Autobahn to drive back home all the way across Germany. Clack, clack, clack! Maybe I’ll better have a look. I pulled over and stopped at the filling station. I was lucky: There was a mechanic from the ADAC, the German automobile association, just filling up his car. I walked over and asked him if he could have a look at the wheels I had just changed a few hours before. “Well, these are the wrong bolts.” He looked worried. “This could have killed you.” It turned out that I had used the longer bolts from the steel rims of the winter tires to tighten up the summer tires. But because they didn’t fit, they had started to come loose. A few more kilometers and a white Golf I with two students on the way back to their parents would have lost a tire at 80 miles an hour. And all of this because of one small human error.

When we design systems, we want them to be fail-safe. We want them to be as resilient as possible. To make a system resilient, we often focus on the design of technical aspects like durability, reliability, and security. We try to build it from individual parts that are as simple as possible to reduce complexity and, thus, the possibility of technical failure. We try to add in redundancies so that when one component of the system fails, another one can take over so that the whole system keeps running. This is also the reason why we often use a decentralized approach to structure our system. All of this because we know that a resilient system has to be able to respond to change and therefore has to be as adaptable and agile as possible.

But what we often overlook are ourselves. Humans. In our love for technological solutions, we forget that humans will have to work with a system. Humans who architect, use, maintain, change, and enhance the system. Humans with different skillsets and levels of knowledge. Humans who make mistakes.

Humans are significant components of every system. Sometimes, they are the predominant elements in the system. Sometimes, for example in a team, humans even constitute the entire system itself. Be it a spacecraft, a hospital, or a pattern library for a website – if the system is truly resilient, it doesn’t allow for an individual human to become the single point of failure.

-

This is the 18th post of my 100 days of writing series. You can find a list of all posts here.

My father likes to say: “Man gewöhnt sich an jeden Scheiß,“ which translates to something along the lines of “eventually, any shit grows on you.“ He often uses it jokingly and with a wink, yet there is much truth to it. As human beings, we are extremely good at growing accustomed to our current situation and the things that are happening around us, both good and bad. Even in the worst circumstances, we are still looking for something positive and for reasons to not change. We post-rationalize our decisions so that we perceive them as better than they really are. We start to like things better once we own them. We like to think that we, more than others, deserve the things and status we have earned. And once we have grown accustomed to it, we don’t want to give up what we have, even though we might not have wanted all those things in the first place or are worse off adhering to the past.

Somewhere along the way, we often forget how it was to not have those things we now take for granted. And we also forget that many people don’t have what we have. That it is a privilege to have access to clean water, food, electricity, and education, for example. That it is a privilege to own a computer or a smartphone that is connected to the internet with a fast data plan. And that is is a privilege to be able to design and code for the Web and publish your work without fear of being bullied, harassed, censored, arrested, imprisoned, or killed.

We all live in our very own little bubbles and circles of influence and often forget that our collective responsibility is much greater than our narrow perspectives, opinions, and world views. This is why we have to work hard every day to continually improve the world around us – and the Web – for those who are less privileged. Building inclusive, safe, performant, and welcoming spaces does not come easy, though, and is a constant battle against constraints of money, opposing opinions, and our own complacency to speak up and turn words into action.

The first step in making meaningful progress is to realize that we, the creators of the Web, are very much in the minority and that in order to create lasting change, we have to step down from our ivory tower and look at the world not as we perceive it but as it really is. In the West, we have to leave our predominantly white and male teams behind and hire for diversity. Not because we want to create same-ness or comply with a quota, but because only by embracing our differences, we will be able to reach everyone and create groundbreaking innovation. We have to get away from our high-resolution screens attached to high-end machines with 8-core processors behind fiber internet connections. Not because we shouldn’t use the best tools available to be “productive”, but because people in the real world don’t care if a product looks stunning and works well on your machine. People want the best experiences we can offer them, even if the majority of people don’t have access to vast computing powers. We also have to realize that, while we might be able to provide for a family with our work, others, like the many content moderators fact-checking social media, are less privileged. And some of them will be the first to be removed to increase productivity in the age of Machine Learning and AI.

There is a challenge ahead of us that is larger than anything we have encountered before. And, although most of us might not be responsible for and profiting from the climate breakdown, it will take each and every one of us to mitigate the impacts of climate change by changing and invoking change ourselves. The Web might be the most powerful tool mankind has ever invented and it will play a crucial role in shaping our future. But only if it stops to be a Web of the privileged.

-

This is the 17th post of my 100 days of writing series. You can find a list of all posts here.

Today I learned! Jeremy Keith wrote about an interesting detail about CSS custom properties, also known as CSS variables, that he learned from Lea Verou: They don’t support the Cascade when a value is invalid. Or, as Lea writes in her article Hybrid positioning with CSS variables and max():

Jeremy goes on to explain that this is the reason why using the color() function will fall back successfully if you use it like this:

/* CSS */
p {
  background-color: red;
  background-color: color(display-p3 1 0 0);
}

But it will fail if you use a custom property like so:

/* CSS */
:root {
  --myvariable: color(display-p3 1 0 0);
}
p {
  background-color: red;
  background-color: var(--myvariable);
}

What happens is that the browser first figures out the cascade and then looks at the custom properties. If a property is invalid “at computed-value time”, there is no fallback value because the browser has already thrown away the other values. So in the example above, the browser will not display the red background-color, but instead unset it.

A lot of people are switching from Sass to using CSS custom properties these days. And unless you still have to support IE11, you can totally do that because browser support is solid. So it will only be a matter of time until using CSS variables will have be the new normal. Knowing that they fail all that gracefully is an important thing to know, though. Especially if you are using them to use features that are only supported by a few browsers, like the new color functions color(), lab(), or lch().

But what can you do? Do we have to wait and skip using custom properties for values that might fail? Not really. As I wrote in my recent post about the new color functions coming to CSS, you could use supports() to check for support before setting the properties:

/* CSS */
:root {
  --myvariable: red;
}

@supports (color: color(display-p3 1 0 0)) {
  :root {
    --myvariable: color(display-p3 1 0 0);
  }
}

p {
  background-color: var(--myvariable);
}

Another option would be to use a media-query like color-gamut. But if you want to set many values at once in one ruleset, supports() might be the better solution. Sara Soueidan recently wrote about how she defines Global and Component Style Settings with CSS Variables . In such a case, you could rely on a feature query using supports() to set all the custom properties for supporting browsers.

/* CSS */
:root {
  /* UI Colors */
  --color--primary: rgb(217,0,189);
  --color--secondary: rgb(242,199,0);
}
    
@supports (color: lch(50% 132 334)) {
  :root {
     /* UI Colors for browsers that support LCH colors */
     --color--primary: lch(50% 132 334);
     --color--secondary: lch(82% 132 86);
  }
}

-

This is the 16th post of my 100 days of writing series. You can find a list of all posts here.

It’s been over a year now that, after reading an article by Ethan Marcotte, I wrote about why we all need to do better to make the Web truly inclusive. Ethan had shared the results of WebAIM’s 2019 study covering the state of accessibility on the Web and the results were devastating: 97.8 % of the sites had detectable WCAG 2 failures. The study seemed to be a wake-up call and over the following year, accessibility as a topic received much more attention than in previous years – at least that was my perception. But in February 2020, the next WebAIM study showed the exact opposite: Instead of making the Web more accessible, we actually managed to make the Web even more inaccessible. Now, 98.1 % of the sites had detectable accessibility issues.

As I wrote back then, nobody builds inaccessible websites on purpose. Mostly, it is still a lack of awareness. But this lack of awareness reveals a problem that runs much deeper: It shows a lack of diversity within the teams that build those websites. As Olu Niyiawosusi writes in her great article “Building the Woke Web: Web Accessibility, Inclusion & Social Justice” for A List Apart:

Hiring inclusively creates teams full of people who aren’t like you or each other. And those kinds of teams build better products, bring better ideas to the table, and better reflect the user base of the majority of products. It is important to remember that diversity isn’t just about race or hiring women; there are neurodiverse people, people with physical disabilities, people of other genders, people from various backgrounds, and many other marginalizations than could be listed here.

One of the sites that I’m working on has to be WCAG-compliant by the end of September to comply with the European Accessibility Act. We are currently working on improving the codebase and we will also do extensive accessibility testing over the next months. But one thing bothers me already: While it is great to have the budget to test for compliance with accessibility guidelines, there is currently no time and budget planned for doing accessibility tests with real end-users who, for example, are using assistive technology to access the Web. Also, we don’t have anyone on the team who could add their experience as a person with access requirements. And this is exactly the problem that many teams face. On that note: I will try to share as many experiences from this project as possible. Maybe it will help other teams avoid some of the errors we made and will run into.

Building the inclusive Web will take a long time, obviously, and it requires all of us to understand that inclusive, accessible, and performant websites and apps must not be a “nice-to-have” anymore. Building inclusive products is a requirement and if our work isn’t accessible, it’s not done yet. Testing for compliance is a good start, but going forward, we will also have to include the voices of the people who depend on our solutions. And ultimately, there is no better way to do this than to hire them.

-

This is the 15th post of my 100 days of writing series. You can find a list of all posts here.

“Just be authentic!” I’m sure you’ve heard that advice before. Maybe you also know some people, who proudly proclaim that they always like to be authentic and always openly tell people what they are thinking.

There is only one problem with being authentic: It can be highly disrespectful, overly selfish, hurtful even, and, in the end, counterproductive. Don’t get me wrong. I am not talking about feeling comfortable and being relaxed and confident. I am talking showing your “true self”, your true character, and always being open about what you really think or how you feel inside. What, Matthias? But isn’t it a person’s right to follow their natural instincts and just be “authentic”?

When you are happy and have a positive story to share, there is nothing wrong with being authentic, of course. But imagine anyone who got out the wrong side of the bed, who is bored, tired, angry, pissed off, or simply a selfish jerk, would always show that. A client would angrily hang up on you in a business call, a public speaker would openly show discomfort and fear, a workshop host would act totally uninterested and indifferent to the people in the room, and a guest at your birthday party would tell everyone that he doesn’t really “like anyone but you in here.”

Being authentic is often understood as being truthful. But as Mark Bowden illustrates in his great TEDxToronto talk on body language and the importance of being inauthentic, while it might be more honest (and easy) to follow your gut instincts, it is counterproductive if you are trying to communicate with the people around you. And in a professional setting, it can even be highly disrespectful of the people you are interacting with. If, for example, people paid and came to see you speak, it would be disrespectful of their time and attention to not even try to make them feel comfortable and create a positive experience. It is the hallmark of the professional that she shows up and gives her best, whatever obstacles might be in her way. And this includes leaving your comfort zone and being a little bit inauthentic whenever it is needed. You owe it to yourself, to the people around you, and to the story you want to tell.

-

This is the 14th post of my 100 days of writing series. You can find a list of all posts here.

My late grandmother was born in 1913. When she was my age, she had already lived through the Great Depression, the Spanish flu pandemic, hyperinflation, the fall of the Weimar Republic, two world wars, and, with the Nazi regime and the Holocaust, the darkest chapter in German history. She had also witnessed the birth of radio, television, passenger aviation, mass-produced cars, and the modern computer – although the last invention wasn’t on anyone’s radar yet. Whenever I hear someone saying that we are living “in crazy times,” I think of her and how it must have been to live back in those crazy times. The first half of the 20th century was an era of radical transformation. Politically, economically, and technologically so many things changed in such a profound way that over the course of just three centuries the way of life was completely turned upside down for millions of people.

A few days ago, Tim O’Reilly published a long-form essay titled “Welcome to the 21st Century” in which he argues that the current situation, and in particular the COVID-19 pandemic, might mark a point in time that, similar to the assassination of Austrian Archduke Ferdinand in 1914, once more triggers such fundamental changes that the world won’t ever be the same again:

We are entering the century of being blindsided by things that we have been warned about for decades but never took seriously enough to prepare for, the century of lurching from crisis to crisis until, at last, we shake ourselves from the illusion that our world will go back to the comfortable way it was and begin the process of rebuilding our society from the ground up. […] Our comfortable “American century” of conspicuous consumer consumption, global tourism, and ever-increasing stock and home prices may be gone forever.

Especially the greatest challenge of them all, anthropogenic climate change, will bring even more natural disasters, pandemics, economic and political instability, conflict, and forced migration. This sounds terrifying but it is a fact that we will have to prepare for. The question is: How can we even plan and budget for so many unknown and uncertain futures? According to O’Reilly, scenario planning can be the answer. In scenario planning, you don’t make static plans but instead imagine a wide range of possible future scenarios – even if they seem most unlikely – and then look for data points, for indicators, which of those scenarios might indeed become reality. By making plans that hold up for a wide range of unknown futures, you increase the likelihood of being prepared.

What if there is no back to normal? What if there will be even more surveillance and, for example, quarantine enforced by sensors? What if remote work is the new normal and offices are never the primary work location again? What if the value of the commercial real-estate sector crashes? What if the school schedule as we knew it never resumes? What if government services go online, becoming as available, effective, and easy-to-use as the best consumer applications? O’Reilly envisions many possible futures, and indeed many of those futures don’t even seem that unlikely. Yet, we aren’t prepared.

Going forward, we will have to decide how we want to prepare for the shifts ahead of us. Scenario planning suggests that you come up with a “robust strategy”. Robust in this case doesn’t mean “rigid” but instead being flexible, adaptable, and also “resilient” and therefore well-prepared for a range of possible outcomes.

Preparing for constantly emerging and evolving technologies? Coping with uncertainty and unknown futures? I don’t know about you, but all of this sounds like scenario planning could also be a darn useful strategy for building digital products and the Web in general. In many of our projects, we would be well advised to imagine a broader range of possible futures instead of making rigid plans. And by prototyping, making, and testing, we would get the data points we need to evaluate which outcomes might be more likely. This would then help us to come up with a robust, resilient strategy that we could use as a basis for action and for layering tactics on top that allow us to react to the current situation. That seems like something worth exploring…

-

This is the 13th post of my 100 days of writing series. You can find a list of all posts here.

Life is full of risks. The risk to make a wrong decision. The risk to lose. The risk to fail. The risk to mention too many risks in the first paragraph of a blog post.

There are some risks that most of us understandably want to reduce as much as possible. The risk to die, for example.

Then, there are also risks worth taking. Why are they “worth” it? Not because there is no risk involved at all, but because the return, the utility, outweighs the potential damage. But because we are risk-averse beings, we overestimate potential losses and also the risk of losing in itself. Consequently, we often shy away to take even the smallest risks. Publishing that blog post? Singing a song at a birthday party? Speaking in front of people? This all can seem quite risky. But is it, really?

Risk can never be eliminated completely. So instead of not doing the things that include some risk, why not accept the risk and try to evaluate more closely? Just because something seems like it has a high possibility of failure, doesn’t mean it is not worth trying, for example. If the potential return is huge, ask yourself: What is the worst that could possibly happen? If “the worst” isn’t actually that bad, then maybe the risk is still worth taking.

We have to make many decisions every day, and if we can’t eliminate risk, the best strategy might be to balance the risks in ways that keep the big upside while reducing the downside.

-

This is the twelfth post of my 100 days of writing series. You can find a list of all posts here.

Joschi Kuphal shared an amazing video on Twitter this morning. It is a documentary about an exercise that the school teacher, lecturer, and diversity trainer Jane Elliot devised in response to the assassination of Martin Luther King, Jr. in 1968. The exercise is called “Blue Eyes–Brown Eyes” and in it, Elliot uses the eye color of students to separate them into two groups: One with blue eyes and one with brown eyes. The group with the blue-eyed students – which turn out to be predominantly white – are then treated as being inferior throughout the exercise to make them feel the effects of racism and discrimination. The exercise received much public attention, especially in the 1970s and 1980s, and although scientific studies showed no evidence for long-term effects to reduce racism, the immediate effects of the exercise are obvious and fascinating to watch:

https://www.youtube.com/watch?v=jPZEJHJPwIw

-

This is the eleventh post of my 100 days of writing series. You can find a list of all posts here.

One of the reasons for Apple’s success in the years when they invented breakthrough products like the iPod, the iPhone, and the iPad, was the way they created their products. At the heart of the design process was the design studio where lots of models and prototypes of everything the team had in the works would always be on display. As Walter Isaacson describes in his biography of Steve Jobs, always being able to see the current state of the designs allowed Apple’s CEO and his chief design officer Jony Ive to see and feel a model and also see things in relationship to each other. Not only did they design the products as such, but they also constantly invented tools and experimented with processes that would make new solutions at the often-quoted intersection of technology and liberal arts possible. Walking through the studio, you would see CAD workstations, molding machines to create foam models, and a robot-controlled spray-painting chamber to make the models look more real. In close exchange with engineering, the design team was constantly making tangible things. This way, the team was able to better assess the quality of a design, refine it down to its essence, and work on the details that make a product stand out.

The whole studio was built around the idea that designing and making should be inseparable. An idea that Jony Ive and the designers at Apple shared with other industrial designers, like Charles and Ray Eames, for example. In such an environment, the design isn’t created merely based on groupthink or by ticking off checklists of required features. By making designing and making inseparable, the designers form the product in a constant conversation with creatie ideas, materials, and constraints. They give the product room to evolve and themselves the permission to learn and grow.

Now think about how you are designing your products. If you work in a company that is a bit like many I’ve seen over the years, chances are that designing and making are sharply separated, especially if you are designing digital products. Contrary to what is being preached and how many innovative people already work, many teams still work in silos. A concept team might create requirements, a sitemap, and wireframes. The design team might design static images aka layouts (albeit in different screen sizes). And the developers then build the product based on all those specifications. I’ve written in detail about this before, but I still don’t see a lot of change happening, except for everyone now working with components and pattern libraries – which is indeed a kind of progress. But are designers really making tangible things? So few of them are working with HTML, CSS, and JavaScript, the material the Web is made of. So few of them are building interactive prototypes, although we have a wealth of tools that now come with powerful prototyping capabilities. But most importantly, the whole process does still not honor the fact that designing and making should be inseparable.

Have you ever watched a child having an idea and manically getting to work to make it come alive? They don’t care about the medium. They don’t care if making something requires a drawing, written text, singing, or dirt from the garden. They just make. How about we re-learn to do that, too? So instead of starting with a visual layout, or how something looks, why not start with making something?

-

This is the tenth post of my 100 days of writing series. You can find a list of all posts here.

I love shortcuts. Not only keyboard shortcuts but also those in real life: When there is the opportunity to solve a problem quicker and more easily by taking a different path. Such a shortcut might be a new technique that you discovered or a new tool that makes your life easier. Such a shortcut might be possible through automation or a clever hack. And sometimes, such a shortcut might be that you do things a bit differently than they have been done before, for example by leaving out the unnecessary stuff.

Beware of pseudo-shortcuts, though. Pseudo-shortcuts are shortcuts that might seem like a quick solution for the pressing problem at hand, but in reality, they are more of a shoddy trick. Cutting back on research and user testing, for instance. Or not telling a client about a seemingly tiny detail you decided to leave out. Or promising a new hire great opportunities for personal development and growth, when in reality you already know that they might end up doing the same boring tasks for months on end. Pseudo-shortcuts like these usually come back at you with a vengeance, just like a boomerang. Instead of saving money on research and testing, you end up designing and developing the wrong product. Instead of saving some time and getting clearance, your client asks about the tiny detail – because it somehow mattered to them – and gets upset. Instead of having a passionate, happy team member, you will very soon have to invest money again into finding a new employee.

So whenever something feels like a shortcut, watch out. Ask yourself: Is this a real, valuable improvement and therefore a valid shortcut? Then fine, go on. Or is it a pseudo-shortcut that will most likely backfire? Then just don’t do it. Answer this question honestly and it will certainly improve the quality and consistency of everything you do.

-

This is the ninth post of my 100 days of writing series. You can find a list of all posts here.

Run the Jewels released “RTJ4” today, two days ahead of schedule because of recent events in the US. It is available on the streaming services, but also as a free download again. You can combine the download with a donation that will go to the National Lawyers Guild Mass Defense Fund, a network of lawyers, legal workers, and law students providing legal support for political activists, protesters, and movements for social change.

Naturally, I spent the evening listening to the album. Both musically and lyrically, Killer Mike’s and El-P’s long-awaited fourth album is their greatest yet. The duo is arguably the best hip-hop has to offer at the moment. The combination of El-P’s powerful, multi-faceted, raw but masterfully produced beats and woke, punch-you-in-the-face lyrics full of rage makes for a unique combination. Andrew Barker puts it best in his review for Variety when he calls the music “ever mutating and nodding to hip-hop’s roots while gazing steadily forward”. Jon Dolan writes for Rolling Stone: “The lyrics are designed to shake even the most self-regardingly woke of us out of our complacency. […] The music bounces as much as it brays, with an elastic flow and deep history.”

Lately, people have been sharing the ten albums that defined their musical taste on Twitter. I haven’t participated yet. But this album is where it all leads to for me.

-

This is the eighth post of my 100 days of writing series. You can find a list of all posts here.

Color on the Web has seen many iterations. When I started to fall in love with the Web in the late nineties, every self-respecting web designer was using web-safe colors. Although it can be argued that they never really worked, because colors still looked different on different screens, web-safe colors were at least the attempt to achieve consistency in a time where it was worth mentioning in ads that a monitor was able to display “millions of colors“.

Today, we are using not only the hex notation and rgb() in CSS but also rgba() to control transparency. Our displays have grown to be much more accurate in how they display color. And in recent years, so-called wide gamut displays have become increasingly popular. While the old lowest common denominator was the tiny sRGB color space, many modern displays are able to reproduce a much larger color gamut, resulting in more vivid, vibrant colors. Once primarily used in prepress workflows to reproduce the full range of printable colors, wide gamut displays can now be found in both pro and consumer monitors, laptops, and even tablets and smartphones. The DCI-P3 color space, originally designed as a standard for digital movie projection for the film industry, made its debut in a consumer computer in September 2015 in Apple’s iMac. A year later, both Apple and Samsung released their first flagship phones with P3 wide gamut display.

Now, support for these wider color spaces is finally coming to the Web. In case you want to dig deeper, Lea Verou has written a brilliant article on the upcoming changes. The CSS 4 Color specification includes, among other things, lab() and lch(). LCH is a color space designed to cover the entire spectrum of human vision, so it is even larger than P3. Safari already supports it, Chrome is going to support it soon, and Firefox is considering implementation. With the lch() color function and support for the P3 color space in our devices, we will therefore soon have access to about 50% more colors than with sRGB. Another advantage is that LCH, which stands for “Lightness, Chroma, Hue”, is perceptually uniform. So when you define two colors that share the same lightness, the two colors will indeed be perceived as being equally bright by the human eye, which can also be useful if you want to create an accessible color palette.

Here is how you write a color with the new lch() function, in the new commaless syntax:

/* CSS / Sass */
lch(50% 73 327)

The first value stands for the lightness of the color and is written as a percentage ranging from 0 to 100. The second value, chroma, is a number that describes how vibrant and saturated the color is. It starts at 0 but is theoretically unbound, so how high it can be set depends on the color gamut of the monitor. Usually, it doesn’t exceed 230, though. The third value ranging from 0 to 360.

If you want to also use an optional alpha channel, you can do so with the new notation that uses a slash:

/* CSS / Sass */
lch(50% 73 327 / 75%)

Lea Verou also made a neat LCH Color Picker. Have a look at it and play around with the values a bit. For best results, use Safari on a machine with a wide gamut display.

CSS 4 Color also adds a new color() function, which can be used to specify a color in a certain color space, like P3, for example:

/* CSS / Sass */
color(display-p3 1 0 0.331)

Here, the color function is used to first define the color space and then set the color with three values ranging from 0 to 1 which represent the red, green, and blue channels. Ollie Williams nicely explains the new color() function as well as LCH in his post over at CSS-Tricks.

As you can see, a lot is going on at the moment in terms of how we can write colors in CSS. And while a few of those features might not yet be ready for prime time in all browsers, we can already make use of them in supporting browsers using progressive enhancement. We can, for example, use the new color-gamut media query to write specific CSS only for devices that support a certain color space.

/* CSS / Sass */
@media (color-gamut: p3) {
  .main {
    background-color: color(display-p3 1 0 0.331);
  }
}

Another option would be to check for support using @supports:

/* CSS / Sass */
/* sRGB color. */
:root {
    --bright-green: rgb(0, 255, 0);
}

/* Display-P3 color, when supported. */
@supports (color: color(display-p3 1 1 1)) {
    :root {
        --bright-green: color(display-p3 0 1 0);
    }
}

header {
    color: var(--bright-green);
}

So while Safari is currently the only browser with full support for lch() and color() there really is no need to wait until the other vendors have added support. I for one will look into how I can update the colors of my site a bit over the next days to make my site ready for this next, exciting era of color on the World Wide (Gamut) Web.

A few more links (I’ll probably add some more over time):

• Wide Gamut Color in CSS with Display-P3
• Improving Color on the Web
• Responsive Color with Media Queries

-

This is the seventh post of my 100 days of writing series. You can find a list of all posts here.

Let’s talk about web fonts. More specifically, about a mistake I have seen developers make in several projects for different agencies: Embedding a web font in the wrong way. In each of the cases, the service they were using was Fonts.com, and given the service’s popularity, this quick tip might come in handy for some people.

So what’s the problem? When you download a font for self-hosting, it often comes with some demo CSS, so that you see how you can use the web font in your project. Fonts.com does that, too. Here is how that CSS code looks like, for example:

/* CSS / Sass */
@font-face {
  font-family: "DIN Next LT W01 Regular";
  src: url("Fonts/936930ba-a8da-4765-9e89-0f35cdff223f.eot?#iefix");
  src: url("Fonts/936930ba-a8da-4765-9e89-0f35cdff223f.eot?#iefix")
      format("eot"),
    url("Fonts/6b4d4830-9c7d-43d2-b5d3-c73f739561b9.woff2") format("woff2"),
    url("Fonts/ccf25ada-6d2a-4133-95dc-deb039e22999.woff") format("woff"),
    url("Fonts/126195b4-2fa0-4b95-b5cf-ad9bf10193f0.ttf") format("truetype"),
    url("Fonts/58fc798b-98f9-4485-8d2b-7b93a71ee2a6.svg#58fc798b-98f9-4485-8d2b-7b93a71ee2a6") format("svg");;
}

@font-face {
  font-family: "DIN Next LT W01 Bold";
  src: url("Fonts/fa5ed46b-792d-4f47-894e-fa587cf4e1cf.eot?#iefix");
  src: url("Fonts/fa5ed46b-792d-4f47-894e-fa587cf4e1cf.eot?#iefix")
      format("eot"),
    url("Fonts/03008527-67bd-478e-98e3-3b56dd9a6520.woff2") format("woff2"),
    url("Fonts/557f817d-9c25-4a23-baaf-a3cf84a7cd7c.woff") format("woff"),
    url("Fonts/92ed1479-1d40-4a94-8baf-6abd88b17afa.ttf") format("truetype"),
    url("Fonts/03008527-67bd-4485-8d2b-7b93a71ee2a6.svg#03008527-67bd-4485-8d2b-7b93a71ee2a6") format("svg");;
}

First of all, you might not need the older file formats EOT, SVG, and even TTF. Modern browsers all understand WOFF of WOFF2, so let’s get rid of the rest.

/* CSS / Sass */
@font-face {
  font-family: "DIN Next LT W01 Regular";
  src: url("Fonts/6b4d4830-9c7d-43d2-b5d3-c73f739561b9.woff2") format("woff2"),
    url("Fonts/ccf25ada-6d2a-4133-95dc-deb039e22999.woff") format("woff");
}

@font-face {
  font-family: "DIN Next LT W01 Bold";
  src: url("Fonts/03008527-67bd-478e-98e3-3b56dd9a6520.woff2") format("woff2"),
    url("Fonts/557f817d-9c25-4a23-baaf-a3cf84a7cd7c.woff") format("woff");
}

Much better already. Also make sure that WOFF2 comes before WOFF so that browsers which support the 30 % smaller WOFF2 format will use it.

But back to the initial problem. When you wanted to use the fonts defined in the code above, you would reference the font-family from the @font-face rule like so:

/* CSS / Sass */
p {
	font-family: "DIN Next LT W01 Regular", sans-serif;
}

strong {
	font-family: "DIN Next LT W01 Bold", sans-serif;
}

Can you see the problem? No? There are actually two problems this creates. The first one is that by only using a separate font-family for each font-weight, you are creating faux-bold text. In the example above, the browser will artificially add an extra bit of “boldness” to all text that is marked up with strong. That’s clearly not what we want, so I have seen people simply adding a font-weight rule to their code:

/* CSS / Sass */
p {
	font-family: "DIN Next LT W01 Regular", sans-serif;
	font-weight: normal;
}

strong {
	font-family: "DIN Next LT W01 Bold", sans-serif;
	font-weight: normal;
}

Problem solved! Well, no, not really. Now our strong text will be rendered with the bold font without any additional weight – but only if the web font successfully loads. When the download fails (or a user uses a content blocker to block web fonts from loading) our strong text suddenly isn’t bold at all. It is as normal-looking as the rest of the text.

And there’s another problem. Sometimes, people don’t even bother to use the right font-family for elements that should have bold text or are rendered in bold via the browsers default styles.

/* CSS / Sass */
body {
	font-family: "DIN Next LT W01 Regular", sans-serif;
	font-weight: normal;
}

strong {
	font-weight: bold;
}

It might not be immediately visible to the untrained eye, but any seasoned designer or typographer will see the difference. Strong is now faux-bold again. Because the regular weight is used for the whole body, the strong element will get the bold font of the family. But in this case, the family is "DIN Next LT W01 Regular" and a bold font does not exist. So the browser will faux-bolden the text. Not only does this change the contrast and letterforms of the typeface and thus look clunky and unprofessional, it even can create this:

There is one simple solution to all of those problems: Properly define a font-family with different font-weights and font-styles in your @font-face declarations. Instead of using a font-family for each font, use the same family name for all fonts and tell the browser which weight (and style) it is:

/* CSS / Sass */
@font-face {
  font-family: "DIN Next LT W01";
  src: url("Fonts/6b4d4830-9c7d-43d2-b5d3-c73f739561b9.woff2") format("woff2"),
    url("Fonts/ccf25ada-6d2a-4133-95dc-deb039e22999.woff") format("woff");
    font-weight: 400;
    font-style: normal;
}

@font-face {
  font-family: "DIN Next LT W01";
  src: url("Fonts/03008527-67bd-478e-98e3-3b56dd9a6520.woff2") format("woff2"),
    url("Fonts/557f817d-9c25-4a23-baaf-a3cf84a7cd7c.woff") format("woff");
    font-weight: 700;
    font-style: normal;
}

And that’s it! Now, your strong text – or also your headlines, if you like – will use the bold font-weight and also have the correct fallback font in case the web font doesn’t load. The same goes for italic or cursive fonts.

Unless you are using a JavaScript-based web font loading strategy, you might also add font-display: swap to the code. By that you opt-in to so-called FOUT (Flash of Unstyled Text) on browsers with support for font-display. So while the site loads, the fallback font is shown first, and as soon as the web font has been downloaded, the fallback font is swapped with the new one.

/* CSS / Sass */
@font-face {
  font-family: "DIN Next LT W01";
  src: url("Fonts/6b4d4830-9c7d-43d2-b5d3-c73f739561b9.woff2") format("woff2"),
    url("Fonts/ccf25ada-6d2a-4133-95dc-deb039e22999.woff") format("woff");
    font-weight: 400;
    font-style: normal;
    font-display: swap;
}

@font-face {
  font-family: "DIN Next LT W01";
  src: url("Fonts/03008527-67bd-478e-98e3-3b56dd9a6520.woff2") format("woff2"),
    url("Fonts/557f817d-9c25-4a23-baaf-a3cf84a7cd7c.woff") format("woff");
    font-weight: 700;
    font-style: normal;
    font-display: swap;
}

Done.

Final remark: There might be one situation in which using faux-bold text might actually be useful and justified. If you are using a two-stage font loading strategy as Zach Leatherman did for CSS-Tricks. It basically means that you are splitting your web fonts into a smaller chunk and a larger lazy-loaded chunk, for example by loading the regular version of the font first and showing the faux-bold text to your users until the real bold font-weight arrives. By that, you can mitigate text movement across the page a bit as soon as your web fonts are loaded and the text reflows.

–

This is the sixth post of my 100 days of writing series. You can find a list of all posts here.

Nature changes.
Culture changes.
Technologies change.
Societies change.
Markets change.
We change.

Change is everywhere around us. All the time. Inevitably. Change is a constant. The only problem with this is that human beings generally don’t like change that much. We are even afraid of it. So once something seems to work well for us, we stick to it. Food, tools, habits, whatever it is: We rather play it safe than to risk being worse off after a change. Try a new shampoo brand? Na, the old shampoo smells so nice and familiar. Try a new JavaScript framework? Uhm, you never know which one is worth learning anyway so let’s stick with the one we are already using.

There are many explanations for why we avoid change. For one, we are loss-averse. We tend to rather avoid a potential loss than to acquire an equivalent gain. So unless the benefits of a change substantially outweigh the risk of potential losses, we rather don’t make any change at all. But our preference to stick with the status quo can’t be explained with loss aversion alone. It goes much deeper. When asked to choose the color of a new car, for example, people tend to pick the color they already own. Cognitive scientists call this bias the status quo bias.

That’s why it might be so hard for some companies and markets to respond when a technological shift occurs and suddenly a new competitor appears who does things a bit differently. It might be the reason the ice companies weren’t the ones inventing the household refrigerator, which would ultimately replace the entire ice industry. It might be the reason Microsoft’s Steve Ballmer laughed at the iPhone because it had no keyboard and the managers at Nokia probably did the same before they sank into insignificance. And it might be the reason German car manufacturers laughed at the idea that electric cars would be the future.

If we want to be able to keep playing the infinite game we are playing, we need to be ready and willing to adapt to change. By highlighting the costs of inaction. By reducing uncertainty, for example through building prototypes and testing. And also by not trying to change everything at once, but by splitting it up into smaller, gradual changes that are easier to process and getting used to. Let’s try to hone that skill – we will need it going forward.

–

This is the fifth post of my 100 days of writing series. You can find a list of all posts here.

It is 1995. A 13-year old boy in Germany is playing basketball in his room. The walls are plastered with posters. Michael Jordan (life-sized), Scottie Pippen, Dennis Rodman, Shaq, Charles Barkley, Patrick Ewing, Sean Kemp, David Robinson, and many more are all watching him play. He dreams of moving to the US one day, this great country full of opportunities, culture, skyscrapers, and Coca-Cola. A country that had overcome slavery, ended racial segregation, defeated Nazi Germany, and landed a man on the moon.

I finally visited the US for the first time in my life in 2018, when my family and I went to see my sister and her family in Harlem, New York. And I was both amazed and shocked at the same time. Amazed by the sheer scale of the city, the enormous vibrance, and the cultural richness that surrounded me. What a beautiful place to be.

But I was also shocked by how obvious it was that this society is in a constant state of fear. Shocked by how obvious it was that late-stage capitalism has pushed gentrification and social inequality to the extreme, leaving so many people behind. And shocked how obvious the structural racism in this country really is. I experienced it first-hand when I crossed Malcolm X Boulevard the very first morning to get a can of coffee at the grocery store across the street. All of a sudden, a guy came up to me yelling that I should “get my ass outta Harlem” or he would beat the shit out of me. I decided to quickly go into the grocery store instead. The other day, we saw a guy on Broadway verbally attacking and insulting two women wearing a hijab. Both incidents were nothing compared to what black people in America have had to endure for decades. America isn’t that beautiful for many people.

Today, after yet another black man has been killed by a police officer, the US is on fire. Again. Many people are angry. And rightfully so. But although the US seems to be a broken country at the moment, I have always admired the strength and resilience with which US citizens have fought for justice and to bring about positive change. The country has always had a strong civil society. That’s what gives me hope that change is still possible and that the US somehow finds a way out of this. Just listen to this speech by Michael Render aka Killer Mike and you’ll know what I mean.

Racism isn’t only an American problem, though. All across Europe, refugees are being attacked and racist parties, who are willing to let human beings die on the Mediterranean Sea, are on the rise. We must not let them take control. Fighting racism is a constant struggle and each and everyone of us has to do their part. By speaking up when someone casually says something that is clearly racist – because some things are not okay to say. By helping people who are in need of help. By showing racists that they are wrong and in the minority. And by voting. Because every voice counts.

–

This is the fourth post of my 100 days of writing series. You can find a list of all posts here.

Ask any business owner or manager what could be improved about the operations of their company and they will very likely tell you that they are working on “improving efficiency”. They are switching from waterfall to agile to improve efficiency. They are tracking tasks and measuring progress to improve efficiency. They are trying to establish repeatable processes and are experimenting with automation to improve efficiency. In a world where everything is becoming a commodity, efficiency is the latest craze.

At the same time, we naturally want to provide the best quality possible. And this is where it gets tricky. Because in pursuit of efficiency, people tend to give far too much weight to the number of tasks that can be accomplished in the shortest amount of time. Yet to create a product of high quality, the number of features and the speed of execution are secondary. What really makes a product great is meticulous attention to detail.

The details that make a product great are often invisible if you don’t pay close attention. But although they might not be obvious, those details add up to create an overall perception of quality and they will make a product more useful, longer-lasting, or, for example, more energy-efficient. In other words, caring about the details ultimately makes all the difference. But because a focus on efficiency favors measurable quick wins over long-term thinking, taking the time to get the details right is one of the things that is readily dismissed as a waste of resources. “We don’t have time for unnecessary details.” The end result is a product that has all the features the client or the team came up with but which lacks focus and vision.

But even if you know how important attention to detail is and are willing to walk the extra mile, there is a second challenge: Which details should you focus on? Which are the ones worth pursuing and which are a waste of time? You’ll never know for sure, of course, but there are two things that can help you make a decision. The first one is having a clear goal. You can also call it a vision, a mission, or principles. What matters is that it is not a “task” or a “to do” but really a set of overarching principles that everyone agreed upon and which can serve as a compass when you are uncertain. When you know where you’re going, every task is just a step towards your goal. It can be as simple as to agree that “we will at all times provide an inclusive user experience” or “our product is and will always be the fastest on the market” or “user experience, even over developer experience” or “we must not tolerate hate speech on our platform”. If someone then wants you to compromise on those guiding principles, you can remind them that this would undermine what your product stands for and you’ll be able to confidently make a decision that doesn’t favor the quick hack over building a valuable, resilient product.

The second tool at your disposal is to always be willing to learn and gradually improve. Nobody gets it right the first time, but if you didn’t allocate some time and budget for course corrections, you will never know which details aren’t working yet. Consequently, your product will never succeed in the long run. Even the world-famous designs by Charles and Ray Eames underwent several rounds of prototyping and improvement until, for example, the feet of the steel constructions stopped cracking and breaking off. So don’t skip your research, build prototypes, test, and iterate.

But remember: This is not about perfection. Perfection might not exist. But attention to detail surely does.

–

This is the third post of my 100 days of writing series. You can find a list of all posts here.

Type specimens are as old as printed typography. They were originally designed by printers and type foundries as documents that would show typefaces in use across different applications and with all available weights and styles, so that potential customers could evaluate a typeface’s inherent qualities and stylistic capabilities. Type specimens have become an integral part of our visual culture and the history of graphic design. Just look at the gorgeous examples that can be found in the Internet Archive.

So in times when glyphs made from type metal were far too expensive to buy them just to try out a typeface, printed specimens were an indispensable part of the distribution process. But also later, when the digital distribution of fonts became the new normal, the printed specimen remained an invaluable source of inspiration and the go-to resource for typographers and students in search of the right typeface for the job. I still remember the joy that came with finally buying my own yellow FontBook. It still has a special place in the typography section of my bookshelf, although I open it very rarely these days.

In recent years, however, there has been a shift happening. The advent of web fonts not only allowed font lovers to easily find and try fonts online. But also the type foundries were now able to react accordingly to the shift in the marketplace. So more and more type foundries added type specimens to their websites. Fast forward to today and the digital type specimen is not a misfit anymore. New releases by foundries are often accompanied by increasingly stunning digital type specimens that, thanks to animations and interactive features, take the genre to new heights – and newfound glory. Just take a look at the type specimens of Grilli Type’s GT Zirkon and GT America, Sharp’s Trois Mille, or Klim Type’s Söhne Collection. You’ll also find other great examples in this collection by John D. Jameson.

Now, Mark Boulton has started a new research and design project about type specimens: typespecimens is a collection of beautiful examples as well as a blog. You can also sign up for a weekly newsletter. But Mark will not only curate a list of digital type specimens of the highest quality. Part of the project is also to explore how typeface designers and foundries can provide font users with delightful and useful specimens: “What is the best way to present glyphs? What do designers want to actually do with a specimen? How important is the typeface's back story?”

I’m very much looking forward to what he comes up with and all the great specimens that will be added over time. If you happen to know a beautiful example, I’m sure he would appreciate a short message.

–

This is the second post of my 100 days of writing series. You can find a list of all posts here.

A few weeks ago, my son came up to me and asked if I wanted to guess which song he was about to clap. I agreed, sure that it couldn’t be so hard to guess. But as soon as he started, I didn’t have the slightest idea which song he was clapping. He became a bit frustrated and insisted that I should try harder. I tried again, but I was as clueless as before. Then he revealed the song. I don’t recall which song it was, but I remember it was some well-known children's song. Why had it been so hard to guess the song? I mean, I get that all the claps sounded the same – but shouldn’t I still be able to recognize the melody of a song from a clapped rhythm?

What I experienced first-hand with my son, has been described by a Stanford University graduate student in psychology named Elizabeth Newton in 1990. Newton studied a simple game: She divided people into two groups, tappers and listeners. The tappers were given the task to tap out well-known songs, and the listeners were told to guess the songs. Before the experiment started, Newton asked the tappers, how many of their songs would be guessed correctly. They predicted 50 %. After the 120 songs were tapped out, the success ratio was sobering: 2.5 %. Only three out of the 120 songs were guessed correctly. Why?

Try tapping or clapping out a song yourself. (And don’t pick “We Will Rock You”, of course.) Once you start, you’ll immediately hear the melody of the song in your head, sometimes even with instruments or vocals. This makes us think that it can’t be so hard for others to guess the song. We might even be confident that we are fairly talented tappers, yay! Meanwhile, the listener will only hear tock, tock, tock tock tock, tock, tock tock…

When you have an advance in knowledge over someone else, it can be difficult to recognize this gap and act accordingly. This phenomenon – that we falsely assume that others have the background to understand – is called the curse of knowledge.

The curse of knowledge is a cognitive bias that can be observed whenever people want to convey information. The readers of your article, the students in your class, the participants of your workshop, the listeners of your podcast, the people at your next meetup, the clients in your conference call, the users of your interface – they all don’t know what you know and are therefore missing context. Always. And while you are confidently talking and explaining like a pro, people actually don’t understand you as well as you would hope.

To overcome the curse of knowledge, it is first of all important to start with a beginner's mind: Remember how you felt as a beginner. What were the things that others assumed you would know? What might be hard to grasp for a beginner listening to you today? It is extremely hard to remember what it’s like to not know something, but it is necessary. Take terms like font-weight, leading, descender, bleed, overprinting, function, loop, closure, easing, friction, but also design system, Design Thinking, framework, ES Module, React, Vue, and so on: Our world is full of things that were once hard to understand. And the more abstract the concepts are, the larger the effect of the curse of knowledge will be. So remember to explain those things when they are crucial to understanding what you want to convey. Making something as easy and simple as possible is hard but it is key to communicating effectively. This requires that we go deep into a topic, that we understand it at its core to extract the essence – and then tell a story. Because stories make it easier to tell and understand even complex topics more easily.

Working against the curse of knowledge also requires us to understand the people we want to communicate with as good as possible. The people we create for might not only not know (and, in all honesty, don’t care) what a hamburger menu, a web font, or an accordion is, they will also have their own set of unique experiences, expectations, and specialist knowledge. Far too often, designers and developers dismiss those facts and assume that people will understand what is put in front of them. When people don’t get it, they are either dismissed as being DAUs (dumbest assumable users) or “clients who just don’t get design”. In reality, it is part of our job to recognize and overcome the curse of knowledge. So whatever it is you are about to create today: Think about how the curse of knowledge might cloud your judgment and do what is necessary to make your creation better. Often, all it takes is creating a quick draft or building a prototype to create a shared understanding and to better see where information imbalances exist.

–

This is the first post of my 100 days of writing series. You can find a list of all posts here.

So, I haven’t written in a while. Or, to be more precise: I haven’t finished a written piece in a while. That is not because I didn’t write at all, but in the current situation, I simply decided to prioritize family and work over writing, which is still kind of a hobby for me. I started a few posts from time to time but then didn’t take the time to edit and finish them. This bugs me.

I genuinely love to write. Thinking about what to write is interesting already but when you start to put your thoughts on, well, virtual paper, something amazing happens. Just like with design work, the end result is never what you expected it to be when you started the piece. The act of writing is always exciting and surprising. Especially when you try to let the words just pour out. It sounds like a platitude, but the older I get, the more I realize how true it is: The journey really is the reward.

In some of my previous posts on this site, I wrote about what I learned from reading and listening to books and podcasts on writing. One of the first pieces of advice was to just start writing. Regardless of whether you are in the mood or not. Regardless of whether you think you have something to write about. If you want to be a better writer – write. But somehow, I did not practice what I preach. I’ll change that today.

Starting today, I will post a shorter – or sometimes maybe even longer – piece on this site for 100 days. I have no idea what I will write about yet. Some posts will surely be about the Web, about design, and about coding. But others might also be about an observation I made that day or something I learned or enjoyed. I might share insights from books and podcasts or also a chocolate cake recipe. We’ll see.

What will I learn from this? Will my writing improve? Will I think more about what to write? Will I make it a habit? Will you enjoy what you read? Will I fail? I don’t know. All I know is that I already like the idea of writing more and seeing where this leads me. I’m actually excited! Let’s do this. I’ll see you tomorrow.

P.S. If you want me to write about a particular topic, just drop me a note or write me on my twttr.

Posts I wrote thus far

• Day 1: The Curse of Knowledge
• Day 2: Digital Type Specimens
• Day 3: The Details
• Day 4: The Beautiful
• Day 5: Change and the Status Quo
• Day 6: The Right Way to Use fonts.com Web Fonts
• Day 7: World Wide Gamut Web
• Day 8: Fuck it, why wait?
• Day 9: The Shortcut Boomerang
• Day 10: Designing and Making
• Day 11: Blue Eyes, Brown Eyes
• Day 12: Balancing Risk
• Day 13: Welcome to the 21st Century
• Day 14: The Importance of Being Inauthentic
• Day 15: Building the Inclusive Web Together
• Day 16: CSS Custom Properties Fail Without Fallback
• Day 17: The Web of Privilege
• Day 18: Resilient Systems vs Humans
• Day 19: There Is No Secret Code Day 20: Feck Perfuction
• Day 21: Smooth Operations
• Day 22: Release
• Day 23: Becoming a Tyrant
• Day 24: Debugging HTML With Advanced CSS Selectors
• Day 25: What Would This Look Like If It Were Easy?
• Day 26: Go Deep
• Day 27: The Web in the Age of Ubiquity
• Day 28: Milton Glaser – Ten Things I Have Learned
• Day 29: Fussy Web, True Meaning.
• Day 30: 85 Percent
• Day 31: Thoughts on Writing: Read It Out Loud
• Day 32: One Egg
• Day 33: TeamOps
• Day 34: Necessity Is the Ultimate Teacher
• Day 35: Don’t Assume, Validate.
• Day 36: The New Urgency of Climate Change
• Day 37: Fear
• Day 38: Useless Is Useful
• Day 39: Scrolling Elements Into View
• Day 40: Wicked Design
• Day 41: Always at Your Service
• Day 42: Their Fault
• Day 43: Progressive
• Day 44: Hell Yeah or No
• Day 45: The Idea Machine
• Day 46: Lateral Thinking With Withered Technology
• Day 47: Range
• Day 48: Finite and Infinite Games
• Day 49: Gall’s Law
• Day 50: Halftime
• Day 51: How I Structure My CSS (for Now)
• Day 52: Fading Music in and Out in an Online Workshop (On a Mac)
• Day 53: BICEPS: Six Core Needs for Humans at Work
• Day 54: Design Debt
• Day 55: The Thing With Leading in CSS
• Day 56: Aspect Ratio in CSS: Hacks and a New Property
• Day 57: Your Brain Is Plastic
• Day 58: AVIF: A New Image Format
• Day 59: CSS Custom Properties With @property
• Day 60: Design and the 80/20 Principle
• Day 61: On the Design Systems Between Us
• Day 62: :focus-visible Is Here
• Day 63: Painting With the Web
• Day 64: Better Options