Snippets

The Pale King, the late David Foster Wallace’s final novel, was published in 2011. It’s about IRS employees in Peoria, Illinois

And it’s incredibly boring.

I’m not being cruel — The Pale King contains an intricate description of a traffic jam, a long list of tax forms, and an entire chapter devoted to mundane office tasks. As Michael Pietsch, the book’s editor notes, “David set out to write a novel about some of the hardest subjects in the world — sadness and boredom.”

Defending boring UX is a slightly easier task. I just want to get you excited about the invisible, unsung work required to build useful and understandable digital products that truly satisfy user needs.

Boring defined

Boring user experience is clear and straightforward content, design, and code that solves key pain points. No surprise. No delight. It’s the non-design of IA Writer or the simple poetry of plain language.

Unboring is an error message that requires a PhD to unpack or Microsoft Word’s everything-plus-the-kitchen-sink approach to software.

[…]

Boring UX emerged in 2012 with the launch of GOV.UK, a government site that proved straightforward digital design can improve the lives of millions of people. As the jury who awarded the site Design of the Year 2013 put it, “It may not look particularly exciting or pretty, but that is not the point. This is design in the raw, providing vital services and information in the simplest, most logical way possible.”

[…]

Boring doesn’t always save lives, but it usually improves them. The titans of the web — Wikipedia, Reddit, Google, Amazon, Dropbox, GitHub — look boring when compared to Snapchat, The Outline, or Bejeweled. But boring companies have millions of repeat users because their products actually work.

[…]

“Only when a product is functional, reliable, and usable can users appreciate the delightful, pleasurable, or enjoyable aspects of the experience,” notes Fessenden. In other words, boring underpins delight — and sometimes boring is delightful. Popular apps like Pocket and Instapaper, along with Safari’s reader view, turn exciting into boring by rescuing content from the evil clutches of hyperactive design and indestructible retargeting ads.

[…]

If you’re truly user-centric, admit that the most meaningful life stuff happens beyond the borders of tiny glowing rectangles. UX folks are brokers and intermediaries, not rock stars or ninjas. Your job is to swallow some boredom so people can live better lives.

And if that sounds a bit dreary, remember the words of David Wallace in The Pale King: “If you are immune to boredom, there is literally nothing you cannot accomplish.”

I understand that it’s tough to get people excited about boring tools and approaches, especially invisible things like semantic HTML, edge cases, and truncation. But without foundational, behind-the-scenes work, products and features can break in terrible ways. Just ask Karen McGrane. She’s an accomplished digital strategist who has spent the past few years warning the UX community that truncation is not a content strategy. But people continue to ignore her, even though she’s written not one, but two great books.

Why? Because solving for truncation is low glory work. To be blunt, it’s a pain in the ass. But Karen is right. And when truncation fails, it can be far more painful:

Apple has a history of stunting the web’s progress on its platforms. On iOS, Apple doesn’t allow fully independent third-party browsers, requiring all apps to leverage its Safari browser when rendering web-based content. While browsers like Chrome and Opera are available in the App Store, they must use Apple’s Safari browser behind the scenes to render web pages, rather than their own. That means Apple has a monopoly on how iPhone and iPad users access the web. To push developers toward building native apps on iOS rather than using web technologies, Apple ignores popular parts of the open web specification that other browsers implement, to its own benefit.

A technology called WebRTC, for example, allows video calling in a web browser without additional software. It powers tools like Google Meet. But Apple was incredibly slow to implement the specification, leaving out key pieces of functionality, and the technology didn’t work when embedded inside apps.

Apple also handicapped an emerging standard called Progressive Web Apps (PWAs) — which, like Electron, allows developers to build native-like apps for both desktop and mobile — by partially implementing it in a way that makes it too inconsistent to rely on. PWA doesn’t have the same problem if users open apps in Chrome or Firefox, but iPhone and iPad users can’t install third-party browsers, which makes PWA-based technology a non-starter.

[…]

Apple’s subtle, anti-competitive practices don’t look terrible in isolation, but together they form a clear strategy: Make it so painful to build with web-based technology on Apple platforms that developers won’t bother. Now that the App Store is not accepting apps built using Electron, developers will likely find creative ways to work around it, but Apple is setting up for a continual cat-and-mouse game as it plans to exert more control over which apps can run on the platform in the future.

The file-mapping configuration setting consists of a map from the destination path of the file to scaffold to a set of properties that control how the file should be scaffolded.

The available properties are as follows:

• mode: One of “replace”, “append” or “skip”.
• path: The path to the source file to write over the destination file.
• prepend: The path to the source file to prepend to the destination file, which must always be a scaffold file provided by some other project.
• append: Like prepend, but appends content rather than prepends.
• overwrite: If false, prevents a replace from happening if the destination already exists.

The mode may be inferred from the other properties. If the mode is not specified, then the following defaults will be supplied:

• replace: Selected if a path property is present, or if the entry’s value is a string rather than a property set.
• append: Selected if a prepend or append property is present.
• skip: Selected if the entry’s value is a boolean false.

Examples:

"file-mapping": {
  "[web-root]/sites/default/default.settings.php": {
    "mode": "replace",
    "path": "assets/sites/default/default.settings.php",
    "overwrite": true
  },
  "[web-root]/sites/default/settings.php": {
    "mode": "replace",
    "path": "assets/sites/default/settings.php",
    "overwrite": false
  },
  "[web-root]/robots.txt": {
    "mode": "append",
    "prepend": "assets/robots-prequel.txt",
    "append": "assets/robots-append.txt"
  },
  "[web-root]/.htaccess": {
    "mode": "skip",
  }
}

Given the recent demise of Presto and EdgeHTML rendering engines, and dominant market share growth for Chrome (and its Chromium engine), can we make a case for browser engine diversity in a decreasingly diverse browser engine world? In this talk, we’ll talk about web compatibility, interoperability, the web standards process, and hopefully conclude that we should care about these things in 2019.

Great answer by Michael_B on Stack Overflow:

Short Answer

If the goal is to create a grid with equal height rows, where the tallest cell in the grid sets the height for all rows, here’s a quick and simple solution:

• Set the container to grid-auto-rows: 1fr

---

How it works

Grid Layout provides a unit for establishing flexible lengths in a grid container. This is the fr unit. It is designed to distribute free space in the container and is somewhat analogous to the flex-grow property in flexbox.

If you set all rows in a grid container to 1fr, let’s say like this:

grid-auto-rows: 1fr;

… then all rows will be equal height.

It doesn’t really make sense off-the-bat because fr is supposed to distribute free space. And if several rows have content with different heights, then when the space is distributed, some rows would be proportionally smaller and taller.

Except, buried deep in the grid spec is this little nugget:

7.2.3. Flexible Lengths: the fr unit

…

When the available space is infinite (which happens when the grid container’s width or height is indefinite), flex-sized (fr) grid tracks are sized to their contents while retaining their respective proportions.

The used size of each flex-sized grid track is computed by determining the max-content size of each flex-sized grid track and dividing that size by the respective flex factor to determine a “hypothetical 1fr size”.

The maximum of those is used as the resolved 1fr length (the flex fraction), which is then multiplied by each grid track’s flex factor to determine its final size.

So, if I’m reading this correctly, when dealing with a dynamically-sized grid (e.g., the height is indefinite), grid tracks (rows, in this case) are sized to their contents.

The height of each row is determined by the tallest (max-content) grid item.

The maximum height of those rows becomes the length of 1fr.

That’s how 1fr creates equal height rows in a grid container.

---

Why flexbox isn’t an option

As noted in the question, equal height rows are not possible with flexbox.

Flex items can be equal height on the same row, but not across multiple rows.

This behavior is defined in the flexbox spec:

6. Flex Lines

In a multi-line flex container, the cross size of each line is the minimum size necessary to contain the flex items on the line.

In other words, when there are multiple lines in a row-based flex container, the height of each line (the “cross size”) is the minimum height necessary to contain the flex items on the line.

Walking down an aisle in a library, I no more than glance at the vast majority of books shelved on either side of me. Only a madman would suggest that my disregard of these books should sanction their pages being torn out. Nonetheless, because research has shown that visitors don’t read the average Web page in full, and because the “success” of a page is more easily measured by user action than cognition, we are often encouraged to marginalize our writing in favor of visual signifiers or action cues.

Sure, most people will “bounce” your content, but if you really have something to say, don’t alienate the people who are willing to give your writing a chance. Good typography does justice to your words, and good wording does justice to your ideas. If readers are comfortable reading your type, then they will more likely be comfortable with what you are writing about.

One of the reasons I care so much about the web platform remaining open and accessible to new people who want to publish on and build things for the web is because of the route I took to get here.

As mentioned earlier, the W3C is celebrating their anniversary by inviting people to share stories of how they became involved in the web. In that spirit (and perhaps to encourage Smashing readers to share their stories), here is mine.

I had never intended to work with computers. I intended to become a dancer and singer, and I left school at 16 to go to dance college. My father is a programmer, however, so we were fairly unusual at the time as we had a computer in the house by 1985 when I was 10.

As a child, I liked typing in the code of “choose your own adventure” games, which appeared in books and magazines. I liked spotting the strings of text which would then show up in the game I would later play (usually, once my dad had fixed it up) on our Amstrad CPC464. I liked to visit the computer lab at Newcastle University, see the huge computers, and talk to the women who worked on them. Perhaps most importantly (and despite my arty interests), I never grew up thinking I couldn’t use computers. I just wasn’t especially interested.

[…]

Then I became pregnant with my daughter and had to leave the theatre. I was good at crewing and loved the theatre, but it was heavy and sometimes dangerous work with unsociable hours — not really a job for someone with a baby. I didn’t know what I would do, but I could type so I thought that perhaps I could type up essays for people. I was upsold to a computer — having gone into PC World looking for a wordprocessor. It was a Packard Bell 486 with a built-in 640×480 screen — a terrible machine that would allow me to either get the sound card working or the modem, but not both at once. I chose the modem and this is where my web story really begins. Even getting this modem working and getting the computer onto the Internet was something of a challenge and, once I did, I went looking for information about… babies.

I didn’t know anything about babies. All my friends were men who worked backstage in theatre. I had no support network, no family around me to help, and so I logged onto ParentsPlace and found people who didn’t mind my questions and were happy to help. At the time, there obviously was no Facebook. This meant that if you wanted to share photos and stories, you built a website. So among the forums about childbirth and toddler tantrums, there were people teaching each other HTML and sharing sets of graphics along with the code to place them. It was like typing out those “choose your own adventure” books again. I was amazed that I didn’t need anyone to fix my code — it just worked!

[…]

Before long, people would pay me to build them a website, and I felt that I should repay at least in some way for all of the questions I had asked. So, I started to answer questions in the forums. That was how it seemed to work. People would learn and move one step up the ladder, the new people would come in with the same questions and the people a step ahead would answer — all the while asking their own questions of those further along. I loved this. I could never have afforded lessons, but I had time. I could help others, and in return, people helped me.

[…]

I became interested in web standards essentially because it made no sense to me that we would have to build the same website twice — in order that it would work in both browsers.