The Best UX is No User Interface at All

We have to anticipate how the user is going to think or react and everyone is different. Well designed systems can get us close to intuitive. .Even a perfect UI would be less than ideal. The ideal is to have no middleman at all. No translation layer. Historically speaking, this hasn’t been possible because we can’t "speak" to computers.

Website Sameness™

Here's captain obvious (yours truly) with an extra special observation for you:

It came across as (particularly trite) commentary about Website Sameness™. I suppose it was. I was looking at lots of sites as I was putting together The Power of Serverless. I was actually finding it funny how obtuse the navigation often is on a SaaS sites. Products? Solutions? Which one is for me? Do I need to buy a product and a solution? Sometimes they make me feel dumb, like I'm not informed enough to be a customer. What's the harm is just telling me exactly what your thing does?

But anyway, people commenting on Website Sameness™ has plenty of history onto itself. (more…)

Sketching in the Browser

Mark Dalgleish details how his team at seek tried to build a library of React components that could then be translated into Sketch documents. Why is that important though? Well, Mark describes the problems that his team faced like this:

...most design systems still have a fundamental flaw. Designers and developers continue to work in entirely different mediums. As a result, without constant, manual effort to keep them in sync, our code and design assets are constantly drifting further and further apart.

For companies working with design systems, it seems our industry is stuck with design tools that are essentially built for the wrong medium—completely unable to feed our development work back into the next round of design.

Mark then describes how his team went ahead and open-sourced html-sketchapp-cli, a command line tool for converting HTML documents into Sketch components. The idea is that this will ultimately save everyone from having to effectively copy and paste styles from the React components back to Sketch and vice-versa.

Looks like this is the second major stab at the React to Sketch. The last one that went around was AirBnB's React We normally think of the end result of design tooling being the code, so it's fascinating to see people finding newfound value in moving the other direction.

Recreating the GitHub Contribution Graph with CSS Grid Layout

Ire Aderinokun sets out to build the GitHub contribution graph — that’s the table with lots of green squares indicating how much you’ve contributed to a project – with CSS Grid:

As I always find while working with CSS Grid Layout, I end up with far less CSS than I would have using almost any other method. In this case, the layout-related part of my CSS ended up being less than 30 lines, with only 15 declarations!

I’m so excited about posts like this because it shows just how much fun CSS Grid can be. Likewise, Jules Forrest has been making a number of brilliant experiments on this front where she reimagines complex print layouts or even peculiar menu designs.

JavaScript, I love you, you’re perfect, now change

Those of us who celebrate Christmas or Hannukkah probably have strong memories of the excitement of December. Do you remember the months leading up to Christmas, when your imagination exploded with ideas, answers to the big question "What do you want for Christmas?" As a kid, because you aren't bogged down by adult responsibility and even the bounds of reality, the list could range anywhere from "legos" to "a trip to the moon" (which is seeming like will be more likely in years to come).

Thinking outside of an accepted base premise—the confines of what we know something to be—can be a useful mental exercise. I love JavaScript, for instance, but what if, like Christmas as a kid, I could just decide what it could be? There are small tweaks to the syntax that would not change my life, but make it just that much better. Let's take a look.

As my coworker and friend Brian Holt says,

Get out your paintbrushes! Today, we're bikeshedding!


Aspect Ratios with SVG

I quite like this little trick from Noam Rosenthal:

.aspectRatioSizer {
  display: grid;
.aspectRatioSizer > * {
  grid-area: 1 / 1 / 2 / 2;

<div class="aspectRatioSizer">
  <svg viewBox="0 0 7 2"></svg>
    Content goes here

Two things going on there:

  1. As soon as you give a <svg> a viewBox, it goes full-width, but only as tall as the implied aspect ratio in the viewBox value. The viewBox value is essentially "top, left, width, height" for the coordinate system interally to the SVG, but it has the side-effect of sizing the element itself when it has no height of its own. That's what is used to "push" the parent element into an apsect ratio as well. The parent will still stretch if it has to (e.g. more content than fits), which is good.
  2. CSS Grid is used to place both elements on top of each other, and the source order keeps the content on top.

A Site About Serverless Technology

I know some of you have a visceral and negative feeling toward the word serverless. I felt that way at first too, but I'm kinda over it. Even if it's not a perfect word, it's done a good job of encapsulating a movement into a single word. That movement is far more than I'm qualified to explain.

But I do very much think it's worth knowing about. Developers of all sorts can take advantage of it, but I'm particularly fascinated about what it can do to extend the front-end developer toolbelt.


Designer-Oriented Styles

James Kyle:

Components are a designer’s bread and butter. Designers have been building design systems with some model of “component” for a really long time. As the web has matured, from Atomic Design to Sketch Symbols, “components” (in some form or another) have asserted themselves as a best practice for web designers ...

Designers don’t care about selectors or #TheCascade. They might make use of it since it’s available, but #TheCascade never comes up in the design thought process.

(Okay okay... most designers. You're special. But we both knew that already.)

I think James makes strong points here. I'm, predictably, in the camp in which I like CSS. I don't find it particularly hard or troublesome. Yet, I don't think in CSS when designing. Much easier to think (and work) in components, nesting them as needed. If the developer flow matched that, that's cool.

I also agree with Sarah Federman who chimed in on Twitter:

It seems a bit premature to look at the current landscape of component CSS tooling at say that it's designer-friendly.

The whole conversation is worth reading, ending with:

Tooling that treats component design as an interface with the code is where it's at/going to be. Hopefully, designers will be more empowered to create component styles when we can meet them closer to their comfort zone.

Building a Good Download… Button?

The semantics inherent in HTML elements tell us what we’re supposed to use them for. Need a heading? You’ll want a heading element. Want a paragraph? Our trusty friend <p></p> is here, loyal as ever. Want a download? Well, you’re going to want... hmm.

What best describes a download? Is it a triggered action, and therefore should be in the domain of the <button></button> element? Or is it a destination, and therefore best described using an <a></a> element?


Boilerform: A Follow-Up

When Chris wrote his idea for a Boilerform, I had already been thinking about starting a new project. I’d just decided to put my front-end boilerplate to bed, and wanted something new to think about. Chris’ idea struck a chord with me immediately, so I got enthusiastically involved in the comments like an excitable puppy. That excitement led me to go ahead and build out the initial version of Boilerform, which you can check out here.