Link tags: em

1411

sparkline

No To Spy Pixels

Almost no-one has given informed constent to being tracked through spy pixels in emails, and yet the practice is endemic. This is wrong. It needs to change.

Why you should never use px to set font-size in CSS - Josh Collinsworth blog

Reminder:

em and rem work with the user’s font size; px completely overrides it.

Remix and the Alternate Timeline of Web Development - Jim Nielsen’s Blog

It sounds like Remix takes a sensible approach to progressive enhancement.

BBC World TV News interview of Ariel Waldman for the NASA Artemis I launch! - YouTube

This is so cool—Ariel was on BBC World TV News live during the Artemis launch!

BBC World TV News interview of Ariel Waldman for the NASA Artemis I launch!

Craft — PaulStamatiou.com

I often use the word quality when referring to apps, products and services I hold in a high regard but another word that often comes up in this context is craft. Craft, as in something that is handcrafted where something someone spent a lot of time on and maybe even embedded their own personal touches and personality in it. Often something handcrafted feels more premium.

Jack Rusher ☞ Classic HCI demos

At Clarity last week, I had the great pleasure of introducing and interviewing Linda Dong who spoke about Apple’s Human Interface Guidelines. I loved the way she looked at the history of the HIG from 1977 onwards. This collection of videos is just what I need to keep spelunking into the interfaces of the past:

A curated collection of HCI demo videos produced during the golden age from 1983-2002.

The IndieWeb for Everyone | Max Böck

Spot-on analysis by Max:

Generally speaking: The more independence a technology gives you, the higher its barrier for adoption.

I really hope that this when smart folks start putting their skills towards making the ideas of the indie web more widely available:

I think we’re at a special moment right now. People have been fed up with social media and its various problems (surveillance capitalism, erosion of mental health, active destruction of democracy, bla bla bla) for quite a while now. But it needs a special bang to get a critical mass of users to actually pack up their stuff and move.

Towards Growing Peaches Online - by Claire L. Evans

A beautiful meditation on Christopher Alexander by Claire L. Evans.

Programming Portals

A terrific piece by Maggie Appleton that starts with a comparison of graphical user interfaces and command line tools—which reminds me of the trade-offs between seamless and seamful design—and then moves into a proposed paradigm for declarative design tools:

Small, scoped areas within a graphical interface that allow users to read and write simple programmes

Why We’re Breaking Up with CSS-in-JS | Brad Frost

I’ve seen the pendulum swing back and forth many times over my years building on the web. I too feel like there’s something in the air right now, and people are finally acknowledging that most single page apps are crap.

But Brad makes the interesting point that, because they were incubated when profligate client-side JavaScript was all the rage, web components may have ended up inheriting the wrong mindset:

So now the world of web components has egg on its face because the zeitgeist at the time of its design didn’t have such a strong focus on SSR/HTML-first/ progressive enhancement. Had web components been designed in the current zeitgeist, things would almost certainly be different.

Two JavaScripts

There are two JavaScripts.

One for the server - where you can go wild.

One for the client - that should be thoughtful and careful.

Yes! This! I’m always astounded to see devs apply the same mindset to backend and frontend development, just because it happens to be in the same language. I don’t care what you use on your own machine or your own web server, but once you’re sending something down the wire to end users, you need to prioritise their needs over your own.

It’s the JavaScript on the client side that’s the problem. What’s given to the visitor.

I’d ask you, if you’re still reading, that you consider a separation of JavaScript between client and server. If you’re a dev, consider the payload, your bundle and work to reduce the cost to your visitor. Heck, think progressive enhancement.

The Web’s Next Transition | Epic Web Dev by Kent C. Dodds

The primary benefit of Progressive Enhancement is not that “your app works without JavaScript” (though that’s a nice side-benefit) but rather that the mental model is drastically simpler.

I think that’s the primary benefit to developers. The primary benefit to users is that what you build will faster and more resilient.

Anyway, this is a really good deep dive into different architectural choices for building on the web. Although I was surprised by this assertion in the first paragraph:

The most popular architecture employed by web developers today is the Single Page App (SPA)

Citation needed. Single Page Apps do indeed dominate the discussion, but I don’t think that necessarily matches the day-to-day reality.

Progressively enhance for a more resilient web :: jjenzz

I realised, progressive enhancement isn’t only about supporting that 1%. It’s about testing your app without JavaScript to ensure 100% of your users have a more performant, usable, available, and resilient experience.

A really good explanation of progressive enhancement as an approach to building anything on the web:

Progressive enhancement does not mean you need to provide the exact same UI without JavaScript. The enhanced experience should be better and it should do more, otherwise the enhanced experience is not needed at all. It enhances a degraded experience that also allows the user to accomplish their goal. For example, entering a postal code manually into a text box might be the degraded experience, and the progressively enhanced experience would prefill the text box based on Geolocation data.

Bunny Fonts | Explore Faster & GDPR friendly Fonts

A drop-in replacement for Google Fonts without the tracking …but really, you should be self-hosting your font files.

Descriptive engineering: not just for post-mortems – Dan Slimmon

I wrote a while back about descriptive and prescriptive design systems—and a follow-up post—but I didn’t realise there was such a thing as descriptive and prescriptive engineering.

Fermented Code: Modelling the Microbial Through Miso - Serpentine Galleries

Y’know, I started reading this great piece by Claire L. Evans thinking about its connections to systems thinking, but I ended up thinking more about prototyping. And microbes.

Malleable Systems Collective

Modern computing is far too rigid. Applications can only function in preset ways determined by some far away team. Software is trapped in hermetically sealed silos and is rewritten many times over rather than recomposed.

This community catalogs and experiments with malleable software and systems that reset the balance of power via several essential principles…

I’ll be adding those principles to my collection.

Data Design Language

I like this approach to offering a design system. It seems less prescriptive than many:

Designed not as a rule set, but rather a toolbox, the Data Design Language includes a chart library, design guidelines, colour and typographic style specifications with usability guidance for internationalization (i18n) and accessibility (a11y), all reflecting our data design principles.

Your design system contribution practice is doomed to fail by Amy Hupe, content designer.

This is a great analysis by Amy of the conflicting priorities tugging at design systems.

No matter how hard we work to foster these socialist ideals, like community, collaboration, and contribution, it feels as though we’re always being dragged to a default culture of individualism.