Link tags: action

208

sparkline

What would have happened if we never fixed the ozone hole?

We may not live in the best of all possible worlds, but we have dodged some bullets:

In the annals of environmental history, humanity’s response to the ozone crisis stands out as a rare success story. During the 1970s and ‘80s, evidence started to mount that certain household chemicals used in refrigerators, air conditioners, and aerosol cans like hairspray were eating a giant hole in Earth’s ozone layer, which prevents harmful ultraviolet radiation from reaching the surface. Facing the terrifying prospect of a future without any atmospheric sunscreen at all, in the late 1980s nations came together to sign the Montreal Protocol, a global treaty to phase out so-called ozone-depleting substances like chlorofluorocarbons.

But if things hadn’t turned out that way—if the scientific evidence linking man-made chemicals to ozone depletion wasn’t strong enough, or if ozone deniers (yes, there were ozone deniers) successfully stymied the Montreal Protocol—the world might look very different.

Tabs in HTML?

I’ve been having some really interesting chats with Brian about tabs, markup, progressive enhancement and accessibility. Here’s a braindump of his current thinking which is well worth perusing.

Whatever Happened to UI Affordances? – Terence Eden’s Blog

Flat, minimalist, clean, material - whatever you want to call it - is an annoying antipattern. Computers are here to make life easier for humans. Removing affordances is just a nasty thing to do to your users.

Let’s talk about failure

Denise shares a cautionary tale of service design gone wrong.

I helped pioneer UX design. What I see today horrifies me

Jesse has his Oppenheimer moment, with much wailing and gnashing of teeth.

What got lost along the way was a view of UX as something deeper and more significant than a step in the software delivery pipeline: an approach that grounds product design in a broad contextual understanding of the problem and goes beyond the line-item requirements of individual components. Also lost along the way were many of the more holistic and exploratory practices that enabled UX to deliver that kind of foundational value.

Cameras and Lenses – Bartosz Ciechanowski

This is a truly wonderful web page! It’s an explanation from first principles of how cameras and lenses work.

At its most basic, it uses words which you can read in any browser. It also uses images so if your browser supports images, you get that enhancement. And it uses interactive JavaScript widgets so that you get that layer of richness if your browser supports the technology.

Then you realise that every post ever published on this personal site is equally in-depth and uses the same content-first progressive enhancement approach.

Static sites, slack and scrollytelling. | Clearleft

Cassie’s enthusiasm for fun and interesting SVG animation shines through in her writing!

The Great Distractor — Centre for Media, Technology and Democracy

James has penned a sweeping arc from the The Mechanical Turk, Sesame Street, and Teletubbies to Instagram, Facebook, and YouTube.

Painting With the Web · Matthias Ott – User Experience Designer

By using static wireframes and static layouts, by separating design and development, we are often limiting our ability to have that creative dialogue with the Web and its materials. We are limiting our potential for playful exploration and for creating surprising and novel solutions. And, most importantly, we are limiting our ability to make conscious, well-informed decisions going forward. By adding more and more layers of abstraction, we are breaking the feedback loop of the creative process.

Van11y: Accessibility and Vanilla JavaScript - ES2015

Van11y (for Vanilla-Accessibility) is a collection of accessible scripts for rich interfaces elements, built using progressive enhancement and customisable.

Boring by default

More on battling entropy:

Ever needed to change “just a small thing” on an old page you build years ago? I recently had the pleasure and the simple task of changing some colors in CSS lead to a whole day of me wrangling with old deprecated Grunt tasks and trying to get the build task running.

The solution:

That’s why starting with HTML, CSS and JavaScript without the need to ever compile anything on your local machine is a good idea. Changing some colors on such a page would indeed only take minutes and not a whole day.

I like this mindset:

Be boring by default and enhance on the way.

Cheating Entropy with Native Web Technologies - Jim Nielsen’s Weblog

This post really highlights one of the biggest issues with the convoluted build tools used for “modern” web development. If you return to a project after any length of time, this is what awaits:

I find entropy staring me back in the face: library updates, breaking API changes, refactored mental models, and possible downright obsolescence. An incredible amount of effort will be required to make a simple change, test it, and get it live.

Always bet on HTML:

Take a moment and think about this super power: if you write vanilla HTML, CSS, and JS, all you have to do is put that code in a web browser and it runs. Edit a file, refresh the page, you’ve got a feedback cycle. As soon as you introduce tooling, as soon as you introduce an abstraction not native to the browser, you may have to invent the universe for a feedback cycle.

Maintainability matters—if not for you, then for future you.

The more I author code as it will be run by the browser the easier it will be to maintain that code over time, despite its perceived inferior developer ergonomics (remember, developer experience encompasses both the present and the future, i.e. “how simple are the ergonomics to build this now and maintain it into the future?) I don’t mind typing some extra characters now if it means I don’t have to learn/relearn, setup, configure, integrate, update, maintain, and inevitably troubleshoot a build tool or framework later.

15 years of Clearleft

Ah, look at this beautiful timeline that Cassie designed and built—so many beautiful little touches! It covers the fifteen years(!) of Clearleft so far.

But you can also contribute to it …by looking ahead to the next fifteen years:

Let’s imagine it’s 2035…

How do you hope the practice of design will have changed for the better?

Fill out an online postcard with your hopes for the future.

MSEdgeExplainers/explainer.md at main · MicrosoftEdge/MSEdgeExplainers

This is great! Ideas for allowing more styling of form controls. I agree with the goals 100% and I like the look of the proposed solutions too.

The team behind this are looking for feedback so be sure to share your thoughts (I’ll probably formulate mine into a blog post).

4 Design Patterns That Violate “Back” Button Expectations – 59% of Sites Get It Wrong - Articles - Baymard Institute

Some interesting research in here around user expecations with the back button:

Generally, we’ve observed that if a new view is sufficiently different visually, or if a new view conceptually feels like a new page, it will be perceived as one — regardless of whether it technically is a new page or not. This has consequences for how a site should handle common product-finding and -exploration elements like overlays, filtering, and sorting. For example, if users click a link and 70% of the view changes to something new, most will perceive this to be a new page, even if it’s technically still the same page, just with a new view loaded in.

An Introduction To Stimulus.js — Smashing Magazine

An intro to Stimulus, the lightweight JavaScript library from Basecamp that takes a progressive enhancement approach, as seen with HEY.

One aspect I really like about the approach Stimulus encourages, is I can focus on sending HTML down the wire to my users, which is then jazzed up a little with JavaScript.

I’ve always been a fan of using the first few milliseconds of a user’s attention getting what I have to share with them — in front of them. Then worrying setting up the interaction layer while the user can start processing what they’re seeing.

Furthermore, if the JavaScript were to fail for whatever reason, the user can still see the content and interact with it without JavaScript.

This Website Will Self-destruct

You can send me messages using the form below. If I go 24 hours without receiving a message, I’ll permanently self-destruct, and everything will be wiped from my database.

Designing for Progressive Disclosure by Steven Hoober

Progressive disclosure interface patterns categorised and evaluated:

  • popups,
  • drawers,
  • mouseover popups (just say no!),
  • accordions,
  • tabs,
  • new pages,
  • scrolling,
  • scrolling sideways.

I really like the hypertext history invoked in this article.

The piece finishes with a great note on the MacNamara fallacy:

Everyone thinks metrics let us measure results. But, actually, they don’t. They measure only what they are measuring. Engagement, for example, is not something that can be measured, so we use an analogue for it. Time on page. Or clicks.

We often end up measuring what is quick, cheap, and easy to measure. Therefore, few organizations regularly conduct usability testing or customer-satisfaction surveys, but lots use analytics.

Even today, organizations often use clicks as a measure of engagement. So, all too often, they design user interfaces to generate clicks, so the system can measure them.

Home | SofaConf 2020

You don’t want to miss this! A five-day online conference with a different theme each day:

  1. Monday: Product Strategy
  2. Tuesday: Research
  3. Wednesday: Service Design
  4. Thursday: Content Strategy
  5. Friday: Interaction Design

Speakers include Amy Hupe, Kelly Goto, Kristina Halvorson, Lou Downe, Leisa Reichelt and many more still to be announce, all for ludicrously cheap ticket prices.

I know it sounds like I’m blowing my own trumpet because this is a Clearleft event, but I had nothing to do with it. The trumpets of my talented co-workers should be blasting in harmonious chorus.

(It’s a truly lovely website too!)

The 3 Laws of Serverless - Burke Holland

“Serverless”, is a buzzword. We can’t seem to agree on what it actaully means, so it ends up meaning nothing at all. Much like “cloud” or “dynamic” or “synergy”. You just wait for the right time in a meeting to drop it, walk to the board and draw a Venn Diagram, and then just sit back and wait for your well-deserved promotion.

That’s very true, and I do not like the term “serverless” for the rather obvious reason that it’s all about servers (someone else’s servers, that is). But these three principles are handy for figuring out if you’re building with in a serverlessy kind of way:

  1. You have no knowledge of the underlying system where your code runs.
  2. Scaling is an intrinsic attribute of the technology; so much so that it just happens automatically.
  3. You only pay for what you use.

Abstraction; scale; consumption.