Best practices

A/B testing can't tell you why a change is better

I think this is a good example of the is-ought problem in philosophy, transplanted into the world of software development:

A/B testing is a great way of finding out what happens when you introduce a change. But it can’t tell you why.

The problem is that, in a data-driven environment, decisions ultimately come down to whether something works or not. But just because something works, doesn’t mean it’s a good thing.

If I were trying to convince you to buy a product, or use a service, one way I could accomplish that would be to literally put a gun to your head. It would work. Except it’s not exactly a good solution, is it? But if we were to judge by the numbers (100% of people threatened with a gun did what we wanted), it would appear to be the right solution.

Tags: 

Web Form Conundrum: disabled or readonly?

Web forms are complex beasts. There are a lot of field types to remember, each with dozens of attributes. It’s hard to know which is the right way to go, especially when presented with a choice between two seemingly similar options for disallowing a field to be edited: disabled and readonly.

TL;DR: If you really need it, which you probably don’t, readonly is what you want.

[…]

The Key Difference

So why do we have two attributes that do the same thing? Unfortunately this is where developers often get confused: the user experience is the same, but the mechanics are quite different.

Fields marked as readonly are collected along with all of the normal field values in a form submission (“successful controls” in the spec). The only difference between a readonly field and a regular field is the user experience.

Fields marked as disabled are ignored when collecting values from the form. In a traditional form submission, the action page would never receive values for a disabled field, regardless of whether it has a name attribute.

Tags: 

But sometimes links look like buttons (and buttons look like links)

In Resilient Web Design Jeremy Keith discusses the idea of material honesty. He says that “one material should not be used as a substitute for another, otherwise the end result is deceptive”.

Making a link look like a button is materially dishonest. It tells users that links and buttons are the same when they’re not.

In Buttons In Design Systems Nathan Curtis says that we should distinguish links from buttons because “button behaviours bring a whole host of distinct considerations from your simple anchor tag”.

For example, we can open a link in a new tab, copy the address or bookmark it for later. All of which we can’t do with buttons.

Tags: 

How to determine which, if any CSS rules are unused on a site

So this is a really interesting way to determine which, if any CSS rules are unused in a stylesheet, site-wide:

Part of this story could certainly be about deleting CSS that is determined to be “unused” in a project. I know there is incredible demand for this kind of tooling. I feel like there are some developers damn near frothing at the mouth to blast their CSS through some kind of fancy tool to strip away anything unneeded.

[…]

Here’s how one company I heard from was doing it:

  1. They injected a script onto the page for some subset of users.
  2. The script would look at the CSSOM and find every single selector in the CSS for that page.
  3. It would also run a querySelectorAll(“*”) and find every single DOM node on that page.
  4. It would compare those two sets and find all selectors that seemed to be unused.
  5. In order to get the best results, it would fire this script after a random amount of seconds, on a random set of users, in a random set of conditions. Even with this, it needed a lot of data over a long period of time.
  6. After that had run for long enough, there was a set of CSS selectors that seemed likely to be unused.
  7. To be sure, unique background images were applied to all those selectors.
  8. After applying those and waiting for another length of time, the server logs were checked to make sure those images were never accessed. If they were, that selector was used, and would have to stay.
    Ultimately, the unused selectors could safely be deleted from the CSS.

Whew! That’s an awful lot of work to remove some CSS.

But as you can imagine, it’s fairly safe. Imagine just checking one page’s CSS coverage. You’ll definitely find a bunch of unused CSS. One page, in one specific state, is not representative of your entire website.

Tags: 

Why we do what we do

I think this sums up why I’m so impassioned about web development:

I don’t get excited about frameworks or languages—I get excited about potential; about playing my part in building a more inclusive web.

I care about making something that works well for someone that has only ever known the web by way of a five-year-old Android device, because that’s what they have—someone who might feel like they’re being left behind by the web a little more every day. I want to build something better for them.

Tags: 

Coding CSS for Context

Dave Rupert recently tweeted asking a question that I see quite often:

CSS

.some-context .thing { /* special rules and overrides */ } 

Does that go in thing.css or some-context.css?

Then, Harry Roberts discussed this concept further in his article of CSS Code Smells Revisited.

Harry uses a practical example of .thing being a .button. (Well, actually, a .btn but whatever. And yes, I just “well, actuallied” myself. It’s preemptive mansplaining.)

You’ll have the standard button that appears throughout your application. And then you have this variation in modal dialogs.

Instinctively, we start writing .modal .button. Hence, Dave’s question of where to put this particular bit of code. It’s interesting to note that the results of Dave’s survey indicated that a slim majority of people prefer that this bit of code live in with the modal CSS and not with the button CSS.

Harry indicated that it should live with the button CSS. And I agree with him. We’re styling a button! It should be in with the buttons.

[…]

One thing you have to worry about is components becoming too complex. Yes, the modal has a button. It could also have inputs and headings and all sorts of things. Over my career, I’ve noticed useful boundaries and tend not to create components with deep hierarchies.

Identifying The Thing

Going back to our thing that we’re trying to style: the button. Yes, right now, we’re styling a button in a modal dialog. Is this the only place that this exists? Right now, quite possibly. Will it always be the only place it exists? If your project is constantly in flux, then not likely.

Here’s what’s important:

  • We want to identify that this is a variation on our button.
  • We want to indicate the purpose of this button style.
  • We want to avoid tying the code to a particular context that could change.

Going with .button--modal, for example, now identifies it as a variation. But fails on the other two points: It indicates its context and doesn’t say what it’s trying to do other than be in a particular place on the page.

So, why is the button in the modal different than regular buttons? (If you’re the designer, ask yourself this. If you’re not the designer, ask them this.) You might get something like, “It needs to be green to draw attention to the fact that it’s a primary action.” Or maybe something like, “the button is smaller because we don’t have as much room.”

This helps you come up with a name like .button--primary or .button--compact.

Either of those names satisfy the three points I mentioned above.

  • It identifies itself as a variation using the BEM double hyphen.
  • It indicates its purpose through the variation name.
  • It hasn’t tied itself to a specific context.

That last point, to me, is the most important. As a designer, I might end up using these styles on a new page that hasn’t been thought up yet. I might want to use a primary button style on a form that isn’t in a modal dialog. I might want to use a compact button in a sidebar where I don’t have a lot of room.

And as Harry also mentioned, by keeping all our button styles in one place, we have the ability to see patterns emerge across an entire project.

Three months down the line, do we suddenly find ourselves with 30 button styles and need to reduce the complexity of our UI? That can be harder to do if button styles are strewn throughout the codebase, hidden within other contexts.

Tags: 

Pages