Articles by

Robin Rendle

Even though we mentioned it earlier, I thought this outstanding post by Addy Osmani all about the performance concerns of JavaScript was still worth digging into a little more.

In that post, Addy touches on all aspects of perf work and how we can fix some of the most egregious issues, from setting up a budget to “Time-to-Interactive” measurements and auditing your JavaScript bundles.

(more…)

Framer X is a brand new app that’s about to be released and this quick demo reel takes us on a tour through some of the changes to the previous app—it all looks super exciting.

As a designer, I’m most interested in the prototyping tools and being able to quickly explore complex scene transitions between one state and another. But as a developer, I’m interested in how it all ties into React. The website describes it like so:

Use actual React in your projects to create interactive components from scratch. Want more control? Create custom UI in the properties panel for your components.

I can imagine a wonderful near-future where it’s possible to tie Framer X into a design system so that folks on a team can use all the real life React components without having to worry if they’re up-to-date or not.

Several years ago, there was a big push by designers to increase the font-size of websites and I feel like we’re living in another era of accessibility improvements where a fresh batch of designers are pushing for even larger text sizing today. Take this post by Christian Miller, for example, where he writes:

The majority of websites are still anywhere in the range of 15–18px. We’re starting to see some sites adopt larger body text at around 20px or even greater on smaller desktop displays, but not enough in my opinion.

Christian attributes this to all sorts of different things, but I particularly like this bit:

Unfortunately, it’s a common mistake to purposefully design a website in a way to avoid scrolling. To the detriment of design, body text size is reduced to either reduce scrolling, or condense the layout in order to fit other elements in and around the copy.

Scrolling is a natural, established pattern on the web—people expect to have to scroll. Even when it isn’t possible, people will attempt scrolling to see if a page offers more beyond what’s initially in the viewport. Readability is more important than the amount of scrolling required—good content won’t prevent users from scrolling.

I would only push back a little bit on the advice — that legibility isn’t always tied to the font-size of a block of text. A lot of the time it has to do with contrast instead — whether the typeface is easy to read and whether it is clearly visible against the background. Overall, though, there’s a lot of great advice for designers both new and old in this post.

This is a wondrous little project by Wenting Zhang that showcases a series of variable fonts and lets you manipulate their settings to see the results. It’s interesting that there’s so many tools like this that have been released over the past couple of months, such as v-fonts, Axis-Praxis and Wakamai Fondue just to name a few.

In this wacky and satirical post, Heydon Pickering describes a wild new technology called Cascading Style Sheets that solves a lot of the problems you might bump into when styling things with JavaScript:

A good sign that a technology is not fit for purpose is how much we have to rely on workarounds and best practices to get by. Another sign is just how much code we have to write in order to get simple things done. When it comes to styling, JavaScript is that technology.

CSS solves JavaScript’s styling problems, and elegantly. The question is: are you willing to embrace the change, or are you married to an inferior methodology?

Yes, this is a funny post but the topic of CSS-in-JS is hot and quite active. We recently shared a video of Bruce Lawson's excellent talk on the subject and published a roundup of chatter about it as it relates to React. Chris also linked the conversation back to the age-old question of how we deal with unused CSS.

Here’s a nifty post by Diana Mounter all about the design systems team at GitHub that details how the team was formed, the problems they've faced and how they've adapted along the way:

When I started working at GitHub in late 2015, I noticed that there were many undocumented patterns, I had to write a lot of new CSS to implement designs, and that there weren’t obvious underlying systems connecting all the pieces together. I knew things could be better and I was enthusiastic about making improvements—I quickly discovered that I wasn’t the only one that felt this way. There were several folks working on efforts to improve things, but weren’t working together. With support from design leads, a group of us started to meet regularly to discuss improvements to Primer and prioritize work—this was the beginnings of the design systems team.

This whole post had me nodding furiously along to every word but there was one point that I particularly made note of: the part where Diana mentions how her team decided to make “the status of styles more obvious” in order to communicate changes to the rest of the team.

Lately, I’ve noticed how design systems can demonstrate the status of a project, which is super neat. Communicating these large changes to the codebase early and frequently, over-communicating almost, is probably a good idea when a design systems team is just getting started.

Mark this down as one of the strangest things I’ve seen in a good long while. Nicholas Jitkoff has made a tool called itty.bitty that creates websites with all of the assets being contained within their own link. You can create a website without any HTML or CSS resources at all because it’s all been base64 encoded into the URL itself.

(more…)