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.
In front-end development, there are often times when I know that I don’t know something. I might know enough to know what CSS to search for, but I have absolutely no idea how to use it or what the right syntax is. Somehow, in my head, there appears to be a filing cabinet that’s entirely empty, and when I try to look something up, all I find is an almost illegible sticky note instead.
One topic like this (which is an area I’ve sort of always known about but never really understood) is how auto margins and flexbox interact with one another.
The other night, Amit Patel mentioned that you can set script tags in HTML to
display: block with CSS and then edit that code inline with the
contentEditable attribute. This means that you can then see it all update live in the browser as you type. Shortly after, Marius Gundersen replied that you can do this with the style tag as well.
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.
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.
Prototyping animations and interactions is vital for a number of reasons: they can make your interface feel deceptively fast, they can help focus the user on a specific task, and they can provide a better sense of the current state of your application. Is data being loaded? Is something now unclickable? How long do they have to wait until they can perform an action?