Snippets

In September of 2019, Zach Leatherman tweeted

Which has a better First Meaningful Paint time?

1. a raw 8.5MB HTML file with the full text of every single one of my 27,506 tweets
2. a client rendered React site with exactly one tweet on it

(Spoiler: @____lighthouse reports 8.5MB of HTML wins by about 200ms)

Take a moment to wrap your head around that.

It’s perceivably faster to load 8.5 megabytes of HTML than it is to load a single tweet with a client-side React app.

[…]

Real companies can and do build apps with HTML first

The folks at Basecamp just released a new email product, Hey, that tries to address a lot of the stuff that people find frustrating about email.

Neither product is really my cup of tea, but what I find super interesting is how Hey is built.

It’s core is server-rendered HTML. Basecamp is a Ruby on Rails shop (their CTO created Rails). Almost every view in the app is created on a server.

Then, they sprinkle just a little vanilla JS on top to turn things up to 11.

Basecamp uses a project they open sourced called Turbolinks. This JavaScript plugin intercepts link clicks and progressively enhances a server-side app into a single-page app (or SPA) by fetching additional pages with Ajax and only replacing the stuff that needs updating.

By using this approach, if the JS fails or isn’t supported, the app still loads and works and gives people the full experience. It also means you don’t have to wait for the full JS package to load before you can start using the app.

You still get the benefits of faster page loading that SPAs sometimes give you, but you don’t have to maintain two code bases or do complicated server-to-client hand offs (“rehydration” as they call it in the React world).

We have had Grid Layout in browsers for two years. Long enough for us to start to find the edges, and discover things we really wish it could do. The biggest missing feature from Level 1 was subgrid, which has become the main feature for Level 2 of the specification. In this talk I’ll introduce subgrid, with use cases, example code and some thoughts on where we might see Grid going in the future.

[…]

Resources

The following resources were mentioned during the presentation or are useful additional information.

• Grid Level 2 Specification
• CSS Grid Level 2: Here Comes Subgrid
• Grid by Example
• MDN Guide to subgrid
• Digging Into The Display Property: Box Generation
• More accessible markup with display contents
• Chrome Bug: Implement subgrid
• Firefox Bug: Implement layout support for subgrid
• Edge UserVoice: Implement subgrid
• Chrome Status Stats

Slides and code examples can be found in the source link.

As time goes on I find myself increasingly annoyed with login forms. As password managers like 1Password (which is what I use) and Chrome’s password manager (which I also sorta use) become more popular, it’s important for websites to be aware of how users go about logging into their sites.

Let’s walk through some login patterns and why I think they’re not ideal. And then let’s look at some better ways of tackling login. TL;DR; create login forms that are simple, linkable, predictable, and play nicely with password managers.

[…]

I think this may have started with Slack, but I’m seeing other digital products like Notion (which I love by the way) send users a temporary password to their email in order to login. I can appreciate the cleverness of this pattern as it avoids the rigamarole of users having to remember yet another password and building out all the “Forgot password” flow stuff. But.

• This pattern is incredibly tedious. 1. Enter email into login form. 2. Open new tab or switch programs. 3. Open your inbox. 4. Find message from service (if you don’t get distracted by other emails first). 5. Open message. 6. Copy gobbledygook password. 7. Go back to website. 8. Paste in gobbledygook password. 9. Submit login form. Holy shit.
• This doesn’t work at all with password managers, which is incredibly annoying as I want to lean on password managers to, uh, manage my passwords. With the advent of design systems we talk a lot about consistency. But it’s not just about creating consistency within your own ecosystem, it’s about being consistent with the rest of the internet.

[…]

Shopify (another service I love) annoyingly splits its login across three separate screens. Again, I can appreciate the intention here: they’re not trying to overload a user with too much info at once. And while I agree with this pattern for certain contexts (like in an e-commerce flow you typically see billing information, shipping method and address, credit card info, etc chunked out into discrete steps), this is overkill for what’s essentially a three-field form.

• Adds unnecessary steps to login – Again this is a three-field form, but now users have to slog through three screens to log in. This no doubt slows users down.
• Doesn’t work with password managers – While they sort of work, password managers are only able to fill in the one field on the page.

Do

So what should web designers do instead? I think having a boring old predictable login form is just fine. Here’s Harvest:

Simple, concise, predictable. Works with password managers. Good stuff. Here’s some considerations:

• Have a dedicated page for login – Customer support people can direct people to a URL (domain.com/login) rather than having to spell out a bunch of instructions on where to find the login form on the page. Password managers can store that login page and with a click of a button open that page and pre-fill the form.
• Expose all required fields – If you need to enter your last name in order to log in, expose that field!
• Keep all fields on one page – login should be a swift process, not an unnecessary slog through multiple pages.
• Don’t get fancy – There may be something to the whole magic link thing and other inventive login patterns, but I think it’s important to recognize how users are used to logging in across the internet. Lean into that boring, predictable settled science.

My mom is an O.G. console cowgirl, a real-life hidden figure. Working for Ma Bell in the early ’70s, she was responsible for administrating some of the most powerful computers then in the country, the ones that drove our telephone systems. “I’m one of only seven people who know how to program these,” I remember her once bragging as she swept her hand across a clean room the size of an aircraft hanger filled to the ceiling with blinking, whirring mainframes.

But Sally Brownlee isn’t so good with computers anymore. Last March, she was hit by a car while walking her dog. Everyone survived, but Wally lives with another family now (he’s happy; I hear they have a beach house), and as for Mom, who suffered permanent brain damage, she’s not the same in innumerable ways. But in no way is the change more quantifiable to me than when I watch her stares uncomprehendingly at the keyboard of her laptop, or try and fail to use her iPad for the umpteenth time. This woman’s technical expertise launched a billion phone calls, yet now, she is routinely thwarted by what many hail as one of the most accessible UIs on the planet.

[…]

[T]he older we get, the more we act like we’re cognitively disabled: Again, according to Nielsen, people’s ability to use websites effectively declines 0.8% every year over the age of 25.

“It happens naturally,” [Lisa Seeman, a member of IBM Accessibility Research and the editor of the World Wide Web Consortium’s standards for making designs for individuals with cognitive disabilities] explains. “We get older, and even without having something like dementia, we become less capable of figuring new things out.” And this isn’t true only for seniors. Cognitive ability is a spectrum, not a binary switch: It goes down when you’re stressed, tired, depressed, hungry, or in pain. “Everybody has the same cognitive impairments when they’re stressed or depressed,” Seeman says.

In other words, cognitive accessibility isn’t just relevant for people with brain damage, like my mother. It’s relevant to everyone, from people with migraines to neophytes in emerging markets who don’t have software translated yet into their local languages.

[…]

So what’s the answer? A system-level toggle you flip to tell software you’re cognitively disabled, which then dumbs down your interfaces accordingly? Nothing so gauche, laughs Seeman. Where the industry needs to go, she says, is dynamic UIs: Interfaces that aren’t built on an assumption of computer literacy but adjust to a user’s capabilities in real time. “What we need are interfaces that meet the user where they already are,” she says.

Leaflet is the leading open-source JavaScript library for mobile-friendly interactive maps. Weighing just about 38 KB of JS, it has all the mapping features most developers ever need.

Leaflet is designed with simplicity, performance and usability in mind. It works efficiently across all major desktop and mobile platforms, can be extended with lots of plugins, has a beautiful, easy to use and well-documented API and a simple, readable source code that is a joy to contribute to.

A is blind, and has been since birth. He’s always used a screen reader, and always used a computer. He’s a programmer, and he’s better prepared to use the web than most of the others on this list.

B fell down a hill while running to close his car windows in the rain, and fractured multiple fingers. He’s trying to surf the web with his left hand and the keyboard.

C has a blood cancer. She’s been on chemo for a few months and, despite being an MD, is finding it harder and harder to remember things, read, or have a conversation. It’s called chemo brain. She’s frustrated because she’s becoming more and more reliant on her smart phone for taking notes and keeping track of things at the same time that it’s getting harder and harder for her to use.

See the source for the rest.

Cookie notices are usually pretty generic and dry, so I really noticed how human and honest this sounded.