Snippets

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.

Motion Path is a CSS module that allows authors to animate any graphical object along a custom path.

The idea is that when you want to animate an element moving along a path, you previously only had animating translation, position, etc. at your disposal, which wasn’t ideal and only allowed for simple movements. With offset-path you can define a specific path of any shape you want. You then animate it along that path by animating offset-distance, and can choose to rotate it at any point using offset-rotate.

The term brutalism is often associated with Brutalist Architecture, however it can apply to other forms of construction, such as web design.

[…]

The term brutalism is derived from the French béton brut, meaning “raw concrete”. Although most brutalist buildings are made from concrete, we’re more interested in the term raw. Concrete brutalist buildings often reflect back the forms used to make them, and their overall design tends to adhere to the concept of truth to materials.

A website’s materials aren’t HTML tags, CSS, or JavaScript code. Rather, they are its content and the context in which it’s consumed. A website is for a visitor, using a browser, running on a computer [or mobile device] to read, watch, listen, or perhaps to interact. A website that embraces Brutalist Web Design is raw in its focus on content, and prioritization of the website visitor.

Brutalist Web Design is honest about what a website is and what it isn’t. A website is not a magazine, though it might have magazine-like articles. A website is not an application, although you might use it to purchase products or interact with other people. A website is not a database, although it might be driven by one.

They list the following principles:

• Content is readable on all reasonable screens and devices.
• Only hyperlinks and buttons respond to clicks.
• Hyperlinks are underlined and buttons look like buttons.
• The back button works as expected.
• View content by scrolling.
• Decoration when needed and no unrelated content.
• Performance is a feature.

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.