Jonathan Snook's Blog, page 17

Make the right things easy

When I was at Shopify, I started using a motto:

Make the right things easy and the wrong things hard.

People are lazy. I’m really lazy. Sometimes I’ll drop something on the floor and think to myself, maybe I should just leave it there. No, don’t be lazy, I say to myself, and I pick it up. Maybe. Sometimes. Anyways. Point is, if I have an easy way to do something, I’ll usually take it.

When we established the product front-end team at Shopify, how could we make things easier for developers to do the right thing? Copying and pasting code from one page to another was commonplace but was prone to errors and often was missing key elements or classes that needed to be in place for things to look and work properly.

We needed to do more than create a CSS file. We needed to create documentation. We needed to create an api that could be easily consumed.

Having these things in place made it easy to do the right thing.

The flip side to that is to also make the wrong things hard. Linting tools, for example, make it difficult to commit code that doesn’t fit company guidelines.

At Xero, as another example, different teams use different front-end tech stacks. In order to help the company coalesce around a single front-end framework, I recommended the design systems team (known as UX Engineering) build out front-end components in one framework. This way, doing the right thing is easy: the components are ready to go. Doing the wrong thing ends up being a lot of work since complex interactions would need to be written from scratch in whatever framework they chose.

In your team, how can you make it easier for your team to do the right thing? How can you make it harder for them to do the wrong thing?

Are you Single?

I find it interesting when two (or more) people can say something but the way that something is interpreted can be quite different.

Nearly four years ago, Harry Roberts wrote about applying the single responsibility principle to CSS.

Within the article, Harry explains how defining too many properties on a class selector may make it difficult to re-use that class in other contexts, thereby requiring either duplicate CSS properties or overrides to achieve our goals.

He starts with a design of a promotional link like so:

.promo {
display: block;
padding: 20px;
margin-bottom: 20px;
background-color: #09f;
color: #fff;
text-shadow: 0 0 1px rgba(0,0,0,0.25);
border-radius: 4px;
}

It’s a full-width button, lovingly styled.

However, that single class is doing multiple things at once. But what if you wanted a similar promo link but wanted it inline? How do you solve that problem? Here’s his solution:

.island {
display: block;
padding: 20px;
margin-bottom: 20px;
}

.promo {
background-color: #09f;
color: #fff;
text-shadow: 0 0 1px rgba(0,0,0,0.25);
border-radius: 4px;
}

Boom! The promo class can be used in both inline and block contexts. The island class creates the block context.

In the HTML, we can now handle the two scenarios we want:

<a href="http://snook.ca/archives/html_and_css......" class="island promo">Buy Now!</a>
<h2>You should <span class="promo">Buy Now!</span></h2>


Breaking it down

In this case, the CSS has been broken down into two use cases and we have two CSS classes that serve this purpose. Excellent!

But wait, there’s more. There are a bunch of things that I might want to set consistent margin and padding to including inline-block and flex items. Maybe I should break things down even further?

.block {
display: block;
}

.spacing {
padding: 20px;
margin-bottom: 20px;
}

.promo {
background-color: #09f;
color: #fff;
text-shadow: 0 0 1px rgba(0,0,0,0.25);
border-radius: 4px;
}


<a href="http://snook.ca/archives/html_and_css......" class="block spacing promo">Buy Now!</a>
<h2 class="spacing">You should
<span class="promo">Buy Now!</span></h2>

As a project gets more complex, there are going to other ways to break down classes into smaller and smaller components. Which, ultimately, leads you to Atomic CSS, where each class has a very discreet purpose with, usually, just a single property.

<a href="http://snook.ca/archives/html_and_css......" class="D(b) P(20px) Mb(20px) Bgc(#09f) C(#fff) Bdrs(4px) Tsh(light)">Buy Now!</a>
<h2 class="P(20px) Mb(20px)">You should
<span class="Bgc(#09f) C(#fff) Bdrs(4px) Tsh(light)">Buy Now!</span></h2>

Which one is following the single responsibility theory?

Get Smacked

On the other end of the spectrum, is SMACSS. I advocate creating interface components that are independent of the content it’s trying to style.

Did you notice how there’s something that is made to look like something you can click on (the block link) but the other context was just inline text?

This whole scenario is made up but follow along here. If this were a design I received, I’d be going back to the designer and saying, why is it a link here but not there?

In other words, what’s the purpose of this style? It’s a button. Or a link meant to look like a button. In any case, calling it ‘promo’ is limiting. I’m probably going to want buttons all over the place. Or, if I don’t, at some point, I might. Therefore, I create a button style:

.button {
padding: 20px;
background-color: #09f;
color: #fff;
text-shadow: 0 0 1px rgba(0,0,0,0.25);
border-radius: 4px;
}

.button-full {
display: block;
margin-bottom: 20px;
}

This is very similar to what Harry had originally written but with different names. Also, I moved the CSS properties around. I want the padding on the button in both contexts but only when it’s full-width do I want it to have the extra margin on the bottom.

The naming convention I used was on purpose. They both start with button. One is the core module name and then the other can be layered on top of it.

Where I apply the single responsibility theory is in saying that an HTML should only have one module applied to it. Island and promo on the same element? Nope. But button and button-full? Climb aboard!

This narrow example gives me pretty much the same results that Harry did but with a bit more consideration added as to why things have been split up the way they have.

It’s one of the reasons that I continue to stick with the categorization that I originally defined in the book, with layouts, modules, states, and themes. There are patterns that reveal themselves in each of these categories.

Which way?

I’m not sure Harry expected to have his example nitpicked and there might’ve been a degree of pointlessness in my doing so. What’s the point of all this then?

There’s no right or wrong here.

Whether you use Harry’s approach, Atomic CSS, or SMACSS, could depend on any number of factors including comfort level and what you’re willing to trade off. Each could be argued as having or not having applied the single responsibility principle to their project.

Knowing which approach you want to take and how to break up your CSS comes from experience. You start to get a feel for where to draw the lines between which properties should go with which classes based on what was painful the last time you built a site.

Like driving a car

I remember when I first started learning to drive. Behind the wheel, there was so much to think about. I’d change my focus from the road, to the street signs, to the lights, to the cars, to the speedometer. It was all so very overwhelming and stressful.

Over time, things get easier. Eventually, I could sense how fast the car was going. I didn’t have to look at the speedometer every 30 seconds. The street signs began to fade into the surroundings.

Some days, I drive from one place to another and can’t remember the journey because I was thinking about something else. Driving is mostly muscle memory now.

・・・

I remember when I first started to do conference talks. My very first talk was about JavaScript at WebVisions back in 2006. I couldn’t tell you what anybody in the audience looked like. I don’t think I looked up from my slides the entire time. It was all so very overwhelming and stressful.

Over time, things got easier. Eventually, I could slow myself down or speed up based on how much time I had left. I could have internal dialogs while continuing to speak on the material I was presenting. I could evaluate myself while presenting. I could do this because the actual presenting of the material has become very familiar.

That’s not to say I’m a fantastic speaker. I recognize where I still have room to improve in my talks. But there’s a level of ease that comes that wasn’t there 10 years ago.

・・・

Someone says, “oh I could never get on stage and present a talk!” And as cliché as it sounds, if I can do it, you can do it. It might be overwhelming at first. It might be scary. But in time, it’ll get easier.

Staffing a Design Systems Team

A couple really good posts lately on the idea of what it means to have a Design Systems Team.

Most recently, Kaelig blogged about Design Systems Ops. This would be a role within the company that bridges the gap between design systems team and engineering.

“A Design Systems Ops is a person […] who needs to get into the designers’ shoes, and have a feel what their are trying to conceptualize. At the same time, Design Systems Ops need to understand the engineering requirements and define methods that will help shipping and scaling the Design System.”

This description is similar to an article I wrote on Design Engineering, which talks of front-end devs who sit between design and engineering, be they front-end application developer or backend developers.

What it comes down to is the composition of a Design Systems team. This team will need to have multiple roles:

1. Designer

The role of the designer on the team is to design the components and patterns but more importantly, their job is to work with all of the designers across the organization to ensure that the patterns are thought through and that any shared assets like Sketch files or PSDs are usable for the entire company. They also work with the rest of the design systems team to make sure the designs don’t lose anything in the transition into code.

2. Design Engineer

To steal the role title from my own article, the Design Engineer implements the code into HTML, CSS, and maybe even JavaScript. They work with the designer to prototype interactions. They ensure functionality and accessibility is addressed within the front-end code that is written.

3. Engineer

At Shopify, we wanted to build out an “API”. Specifically, we wanted to build Rails helpers to allow devs across the company to easily use the front-end code without having to just copy/paste from somewhere else, which can introduce errors. The Design Engineers didn’t have the required skill set to build out performant Rails code. As a result, having someone on the team to do this was hugely beneficial. This person may be the Design Systems Ops role that Kaelig outlines.

Depending on your hiring, you may have front-end developers who can do design engineering and engineering. You may have designers who can do design and design engineering. With large organizations, greater specialization occurs.

At both Shopify and Xero, I advocated for a dedicated Design Systems Team to shepherd the Pattern Library. Like Nathan Curtis says, “a system isn’t a project with an end, it’s the origin story of a living and evolving product that’ll serve other products.”

As organizations grow, and the influx of designers move from agencies into large teams, we’re going to continue to see the need to build and maintain design systems teams.

Much ado about Twitter

I’ve been on Twitter for close to 10 years now. That’s a long time. Nearly as long as my first marriage lasted. Much like that marriage, the shine on the service has dulled and, well, it’s not much fun anymore.

What is it about Twitter that has made it a less exciting place than 5 years ago and much less than 10 years ago?

Negativity

Negative emotions can be subtle and vile things. A complaint here, a jibe there. It’s hard to notice but they bubble and fester and infect those around us. After awhile, you look around and everybody seems to be in a mood.

From #Gamergate to #Blacklivesmatter to the current US election—all very serious and important matters—it can be overwhelming. It can make the world feel dire and dismal, when in reality, for the most part, things are actually pretty awesome.

How can we improve the experience?

Curation

One key technique that I’ve been using is careful curation. I curate in a few different ways:

I don’t follow brands.
I turn off retweets for some people. For whatever reason, some people retweet one kind of content but their original content is fine.
I use Tweetbot’s keyword filters to hide topics that I no longer want to hear about.
I mute people for a short time if I find they’re ranting.
I mute people forever if I still want to maintain the appearance of a relationship, even though I don’t want to hear what they have to say.
I unfollow people that consistently don’t post content that I value.

Some of this might seem mean or closed-minded but for me, it’s more about what I use Twitter for. I want to hear about people’s personal lives and about the work that they’re doing. If I go to a conference, I expect the same thing. Imagine going to a web conference and having people talking about the election, or about uprisings, or about anything other than the web. Yes, the topics are important. No, that doesn’t mean that is what I want to hear at that particular time.

Harder to find

One of the other facets of Twitter is how easy you can be to find. If you have a non-private account, your tweets can make you a target, both for vitriol and for spam. Neither of which makes the platform much fun.

Turning your account private provides some level of protection but at the expense of forcing you to confirm every new person who wants to follow you. You might want people to easily follow you and be able to retweet your content. You just want to have a bit more control over how people discover you.

How do you get back to a small, curated community that makes everyone feel safe?

There are two facets to being harder to find:

Having the user account be harder to find, and
Having the tweets be harder to find.

Right now, a person can only make their tweets harder to find by turning their account private. There’s nothing a person can do to make their account harder to find—except maybe changing their handle on a regular basis and providing no profile information in which to identify who they are, a tedious task.

One approach that might help maintain tighter community circles within Twitter is to allow users to opt out of both tweet and people search. In all other ways, the account is public.

What this does is force follower growth to occur through word-of-mouth. This word-of-mouth can happen literally or via likes and retweets. It can also happen by broadcasting the handle in community channels. For example, I can include a link to my account from my web site. I’m encouraging people who care about web design and development to interact with me. Public search doesn’t necessarily encourage that.

Positivity

Who knows if any of these changes would work. For me, I’ve made a concerted effort to be positive in what I put out into the world. Sometimes I’ll fail but I hope, more often than not, your day will be a little bit better having read something I’ve written.

Why I Value Truly Responsive Web Design

In my post about values, I mentioned how determining your values can help you evaluate how you work with companies, teams, and people.

The first on my list of values was that I value a truly responsive web design. But why?

Nate Abele alluded to a bunch of them in his comment on the original post.

What do I mean by truly responsive?

By truly responsive, I mean that the design is fluid at all resolutions and that breakpoints are used to manage the points in which a design breaks.

By truly responsive, I mean that a similar experience is provided for on all devices.

By truly responsive, I mean that similar content and functionality is provided for on all devices.

I believe that a truly responsive experience can be achieved for web sites and for web applications.

This can be hard work because it requires a lot of consideration and testing to get it right. One of the pitfalls of most design processes is that little consideration goes into all the conditions in which content can live.

For example, at Xero, we’re going through the process of figuring out how to make the app responsive and evaluating each of the components. The design work before now had compositions in Sketch for two viewports: desktop in landscape mode and phone in portrait mode. We’re just now looking at what it looks like on a phone in landscape. But also looking at all the different resolutions of phones, phablets, tablets, and desktops.

So, why do I believe in a truly responsive approach? There are certainly reasons why you might not want to. Here are a few that I’ve heard:

Designing for iPhone, iPad, and Desktop covers most use cases and the site or application will likely still be usable on everything in between.
People don’t use the site or application on the phone. Or, similar to that argument, it doesn’t make sense for users to use the application on the phone.
The users would be better off if we created a tailored experience for each device.

Of course, the flip side to those:

Things will fall through the cracks. We make assumptions in our work—which is a perfectly natural things to do—that can fail under conditions we didn’t consider. This is why cross device testing is important.
A conference organizer recently told me of someone buying a ticket on a Playstation. Why? No idea. Users will use what they have available to them. I love that we made the push at Shopify to go truly responsive because I use the mobile site now more than I use the native app. Feature parity becomes a given. The work doesn’t need to be duplicated or triplicated for every platform. Which leads to…
Creating a splintered experience creates disparity between cross device experiences because they’ll naturally be out of sync. Things worsen when one experience no longer gets the resources within an organization to maintain that experience.

Also, as Nate mentions, I believe the user ultimately benefits from this. They receive a better experience; a consistent mental model of the application, no matter what device they’re on; and feature parity.

Does it result in less redundant work? Possibly. There’s certainly more work in the beginning than creating a single experience for a single device. But I believe that a modular approach with responsive container queries can reduce the burden of work in developing a multi-page, complex application.

And that’s why I believe in building a truly responsive site or application.

Aligning Your Values

I read a good book recently called Managing Oneself by Peter Drucker. Originally published in 1999, the short book is a quick and easy read.

In it, Drucker asks 5 questions targeted to knowledge workers and their careers.

What are my strengths?
How do I perform?
What are my values?
Where do I belong?
What should I contribute?

The book posits that these are the questions you should be asking yourself to best direct your career.

The third question, what are my values, was the most useful to me. In this case, values is not a synonym for ethics. There’s no objective right or wrong here. For my career, it’s about the values I have for how a product should be designed and built.

For example, here are things that I value:

A website can be designed and built to be truly responsive.
Design should be obvious and straightforward.
Accessibility and usability and performance are all intertwined and require consideration.
The user should be the customer and the product should be designed for them.

Each of those have more nuance in their thinking.

With these values in hand, I can determine whether my values align with the teams and organizations I work within. If they do, great. If they don’t, then I’m at a crossroads.

At Yahoo!, for example, when I noticed that the work I was doing was more about the advertisers and less about the user, I left. I was drawn to Shopify and Xero because it aligned better with a business model that I value.

It’s important to clarify that these values aren’t right or wrong. They’re just different. I can see why a company might want to build a niche product on a niche platform. Or why a company might choose to use advertising to drive their revenue model. It might just not be what I want to do.

The Great Japanese KitKat Taste Test

I recently made a trip to Japan and for some inexplicable reason, I decided to buy every flavour I could find. By the time I came home, I had 12 different kinds to try.

My household decided to do a taste test to see which ones were the best. Maybe surprisingly, there was some variation in what people liked.

Here are the results:

Flavour
L (Aged 8)
H (Aged 12)
J (Aged 41)





Dark Chocolate
Yum
Yum
Yum


Wa-ichigo (Strawberry)
Yum
Yum
Party in my mouth


Wasabi
No
No
Hell no


Rum Raisin
Yum
Ok
Ok


Cheesecake
No
Ok
Ok


Purple Sweet Potato
Yum
Yum
Yum


Sweet Potato
Yum
Ok
Ok


Hojicha Tea
No
No
Ok


Sakura Match
Ok
Yum
Yum


Green Tea
No
Yum
Yum


Uji Matcha
Ok
Yum
Yum


Red Bean
Ok
Yum
Yum

My youngest clearly has more discerning tastes. Which, if you’ve ever seen him at dinner time, discerning is a polite way of putting it.

As for me, I’d like a few more boxes of the Wa-ichigo flavour. Time to plan another trip back to Japan.

Will Change

Dealing with CSS performance can be quite interesting. Various factors, like what properties we use, can have detrimental effects on the usability of a page.

I noticed that my site, as simple as it is, was having a bit of an issue with the fixed background that I’ve had. The scroll performance just wasn’t as smooth as I wanted it to be. I don’t remember this ever being an issue when I first built the site but browsers change.

I decided to switch the fixed background to a static background and all was right with the world. I doubt anybody even noticed the change.

Of course, not every performance issue is so easy and inconsequential to fix. Issues like box-shadow or scroll-jacking are often considered required on a project to achieve a designed experience.

With more CSS features comes more complexity comes more possibility of introducing performance issues. Browsers recognized that certain CSS features needed to be handled differently in order to be more performant.

For example, transforms—especially in 3D space—could be offloaded to a GPU to be rendered more quickly. It is for this reason that it was discovered that if we force an element into 3D space using translateZ, even if we’re not actually moving it anywhere, we could get the performance gains we desired.

By abusing a property in this way, an expectation is created between browser developers and web developers—and not a good expectation. It’s like using floats for layout. We’re using a feature in a way for which it was never intended.

Browser developers decided to introduce a new property that more directly dealt with the performance issues while also making expectations clearer for web developers.

CSS now has a will-change property that allows us to tell the browser what things are likely to change and thus provide a hint to the browser that it should optimize these things.

The will-change property is normally used by specifying what CSS property is likely to change on this particular element.

.modal {
will-change: transform;
}

In this case, the transform may or may not actually ever be applied to the modal but we’re trying to tell the browser that maybe it will.

In applying this property, however, there’s an interesting side effect.

If we were doing a transform:translateZ(0), the element would create a new stacking context and in some browsers, it’ll put the layer into its own rendering pipeline. Thus, giving us the performance increase we so desire.

Therefore, by applying will-change: transform, the browser will force the new stacking context regardless of whether the transform has been applied or not.

The key thing to note here is that will-change will only create a new stacking context if the property would also create a new stacking context. Since the transform property creates a new stacking context, will-change: transform creates a new stacking context.

If you did will-change: display then no new stacking context would be created because no display property value would create a new stacking context.

Let’s look at another example: opacity. An opacity with a value of 1 doesn’t create a new stacking context but a value less than 1 (like 0.9) does. When will-change is applied, then a new stacking context is always created.

Browser support

Not all browsers have will-change implemented yet. Therefore, due to the behaviour of it creating a new stacking context, you’ll need to specify a CSS property that does create a new stacking context to achieve similar rendering results.

Chances are, if you’re playing with layering elements on a page, you’re already using position and z-index to achieve the proper stacking order and therefore may not ever run into this rather interesting side effect of the will-change property.

User Generated Content in a Classy World

Chris Coyier recently wrote of his issues with using classes in content and I agree with his main point entirely:

Content, like this very article you’re reading, might sit in a database and thus be spat out into a template. The content is unlikely to change but the template can go through many revisions. Knowing how many classes you have and where they are used throughout your content can be difficult.

In some cases, like for us web developers who maintain our own sites through a content management system (CMS) like WordPress, adding classes is an easy way to maintain and establish special styling throughout our sites. But you have to remember what those classes are and how to use them.

The way I visualize content is like it is part of a module.

Here’s how the template looks:

<div class="article">
<h1>Page Title</h1>
<div class="article-content">
{{content}}
</div>
</div>


Kinda BEM, All SMACSS

The module then includes everything that might appear in {{content}}. That means that our CSS might look something like this:

.article-content h2 { … }
.article-content p { … }
.article-content ul { … }
.article-content li { … }

For those who’ve gone all-in on the BEM naming convention and approach, this might feel uncomfortable. We’re using descendent selectors instead of applying classes to the content.

In SMACSS, I never dictate that everything must have a class. If the HTML is predictable, using child selectors in this way can save you from having to add classes to everything. (Not that I ever use that as a reason to do something. The “Don’t Repeat Yourself” (DRY) movement can sometimes take things to the extreme with very little gain.)

In this way, including the article content as part of the article module makes sense and using descendent selectors sits right at home, if you’re using SMACSS.

Element styles

The alternative approach I often see is where people will style their content as the default element style and override for the rest of the page.

h2 { … }
p { … }
ul { … }
li { … }

.sidebar > h2 { … }
.modal > h2 { … }

There’s nothing inherently wrong with this approach, either. Just recognize that by over styling elements, you run the risk of needing to unstyle for everywhere else. Thereby, creating more CSS than you might normally need to.

Embedded Objects

In an ideal world, a CMS would allow you to define and embed “objects” inside the content. An object has some complexity to it. For example, a pull quote might have a byline. A photo might have a caption and a credit. Or maybe it’s even more complex than that.

The problem is that rarely have I seen a CMS that handles this well. Having a large text box isn’t conducive to embedding complex objects in it. Art directing—as many people try to do with a big WYSIWYG text box—with a collection of objects isn’t straightforward. Nor is it easy to design an interface to enable powerful art direction.

The other problem is that giving the power of art direction at the content level often results in many scenarios, like various screen sizes and layouts, being ignored. They’re ignored because it’s difficult to raise awareness for these scenarios inside of a content creation tool. It slows people down.

This is a really hard problem. It’s why we try to separate content from presentation: it alleviates the user from having to think through all the ways in which their content might be used.

Forcing users to use interfaces to create structured content allows more freedom to change the styling underneath that structured content, knowing that the content doesn’t need to be revisited.

No one right way

As I like to say, in web design, the answer is usually “it depends”.

If your content is simple, embedding classes inside your content may introduce technical debt that’s difficult to clean up as your site evolves.

If your content is complex, trying to style everything embedded in the content as one behemoth piece will be difficult as there just aren’t enough HTML elements to differentiate all the possible objects. (Hey, maybe Web Components could save the day here; I haven’t done any tests to see how feasible this might be.)