Tags: action

177

sparkline

Sunday, July 8th, 2018

Brutalist Web Design

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.

Sunday, June 17th, 2018

Telepresence - daverupert.com

Dave is liking the word “telepresence”:

On social media we broadcast our presence and thoughts over radio and wire and I likewise consume your projections as they echo back to me. We commune over TCP/IP.

Just wait until he discovers the related neologism coined by Ted Nelson.

Tuesday, May 22nd, 2018

Easy Toggle State

I think about 90% of the JavaScript I’ve ever written was some DOM scripting to handle the situation of “when the user triggers an event on this element, do something to this other element.” Toggles, lightboxes, accordions, tabs, tooltips …they’re all basically following the same underlying pattern. So it makes sense to me to see this pattern abstracted into a little library.

Thursday, May 3rd, 2018

The Wisdom and/or Madness of Crowds

The latest explainer/game from Nicky Case is an absolutely brilliant interactive piece on small world networks.

Saturday, April 28th, 2018

alphagov/accessible-autocomplete: An autocomplete component, built to be accessible.

If you’re looking for an accessible standalone autocomplete script, this one from GDS looks very good (similar to Lea’s awesomplete).

Sunday, April 15th, 2018

Eclipse

A delightful bit of creative JavaScript from Cameron.

Friday, March 30th, 2018

Focusing on Focus Styles | CSS-Tricks

A deep dive into the :focus pseudo-class and why it’s important.

Tuesday, March 27th, 2018

Designing Button States - Cloud Four

The canonical example in just about every pattern library is documenting button variations. Here, Tyler shows how even this seemingly simple pattern takes a lot of thought.

Wednesday, March 21st, 2018

Vox Product Accessibility Guidelines

Accessibility isn’t a checklist …but this checklist is a pretty damn good starting point. I really like that it’s organised by audience: designers, engineers, project managers, QA, and editorial. You can use this list as a starting point for creating your own—tick whichever items you want to include, and a handy copy/paste-able version will be generated for you.

Wednesday, March 7th, 2018

Parallax scrolling with CSS variables | basicScroll

Don’t let the title fool you—this isn’t just for parallax scrolling (thank goodness!)—it’s for triggering any CSS updates based on scroll position. Using CSS custom properties makes a lot of sense. The JavaScript/CSS bridge enabled by custom properties is kind of their superpower. (That’s one of the reasons why I don’t like calling them “CSS variables” which makes them sound like Sass variables—they’re so much more than that!)

Friday, March 2nd, 2018

Notifications

Heydon keeps on delivering the goods. This time, he looks at making on-screen notification messages accessible using ARIA’s live regions.

As ever, structuring content is paramount, even where it pertains to dynamic events inside realtime web applications.

Thursday, March 1st, 2018

Your Interactive Makes Me Sick - Features - Source: An OpenNews project

Browsers have had consistent scrolling behavior for years, even across vendors and platforms. There’s an established set of physics, and if you muck with the physics, you can assume you’re making some people sick.

Guidelines to consider before adding swooshy parallax effects:

  1. Respect the Physics
  2. Remember that We Call Them “Readers”
  3. Ask for Consent

Given all the work that goes into a powerful piece of journalism—research, interviews, writing, fact-checking, editing, design, coding, testing—is it really in our best interests to end up with a finished product that some people literally can’t bear to scroll through?

Sunday, February 11th, 2018

Seva Zaikov - Single Page Application Is Not a Silver Bullet

Harsh (but fair) assessment of the performance costs of doing everything on the client side.

No one’s coming. It’s up to us. – Dan Hon – Medium

A terrific piece by Dan Hon on our collective responsibility. This bit, in particular, resonated with me: it’s something I’ve been thinking about a lot lately:

We are better and stronger when we are together than when we are apart. If you’re a technologist, consider this question: what are the pros and cons of unionizing? As the product of a linked network, consider the question: what is gained and who gains from preventing humans from linking up in this way?

Wednesday, January 31st, 2018

Stimulus 1.0: A modest JavaScript framework for the HTML you already have

All our applications have server-side rendered HTML at their core, then add sprinkles of JavaScript to make them sparkle.

Yup!—I’m definitely liking the sound of this Stimulus JavaScript framework.

It’s designed to read as a progressive enhancement when you look at the HTML it’s addressing.

Tuesday, January 9th, 2018

The Origin of Stimulus

I really like the look of this markup-driven JavaScript library from the same people who brought us the pjax library Turbolinks.

The philosophy behind these tools matches my own philosophy (which I think is one of the most important factors in choosing a tool that works for you, not against you).

Saturday, December 23rd, 2017

Ubiquity and consistency

I keep thinking about this post from Baldur Bjarnason, Over-engineering is under-engineering. It took me a while to get my head around what he was saying, but now that (I think) I understand it, I find it to be very astute.

Let’s take a single interface element, say, a dropdown menu. This is the example Laura uses in her article for 24 Ways called Accessibility Through Semantic HTML. You’ve got two choices, broadly speaking:

  1. Use the HTML select element.
  2. Create your own dropdown widget using JavaScript (working with divs and spans).

The advantage of the first choice is that it’s lightweight, it works everywhere, and the browser does all the hard work for you.

But…

You don’t get complete control. Because the browser is doing the heavy lifting, you can’t craft the details of the dropdown to look identical on different browser/OS combinations.

That’s where the second option comes in. By scripting your own dropdown, you get complete control over the appearance and behaviour of the widget. The disadvantage is that, because you’re now doing all the work instead of the browser, it’s up to you to do all the work—that means lots of JavaScript, thinking about edge cases, and making the whole thing accessible.

This is the point that Baldur makes: no matter how much you over-engineer your own custom solution, there’ll always be something that falls between the cracks. So, ironically, the over-engineered solution—when compared to the simple under-engineered native browser solution—ends up being under-engineered.

Is it worth it? Rian Rietveld asks:

It is impossible to style select option. But is that really necessary? Is it worth abandoning the native browser behavior for a complete rewrite in JavaScript of the functionality?

The answer, as ever, is it depends. It depends on your priorities. If your priority is having consistent control over the details, then foregoing native browser functionality in favour of scripting everything yourself aligns with your goals.

But I’m reminded of something that Eric often says:

The web does not value consistency. The web values ubiquity.

Ubiquity; universality; accessibility—however you want to label it, it’s what lies at the heart of the World Wide Web. It’s the idea that anyone should be able to access a resource, regardless of technical or personal constraints. It’s an admirable goal, and what’s even more admirable is that the web succeeds in this goal! But sometimes something’s gotta give, and that something is control. Rian again:

The days that a website must be pixel perfect and must look the same in every browser are over. There are so many devices these days, that an identical design for all is not doable. Or we must take a huge effort for custom form elements design.

So far I’ve only been looking at the micro scale of a single interface element, but this tension between ubiquity and consistency plays out at larger scales too. Take page navigations. That’s literally what browsers do. Click on a link, and the browser fetches that URL, displaying progress at it goes. The alternative, as exemplified by single page apps, is to do all of that for yourself using JavaScript: figure out the routing, show some kind of progress, load some JSON, parse it, convert it into HTML, and update the DOM.

Personally, I tend to go for the first option. Partly that’s because I like to apply the rule of least power, but mostly it’s because I’m very lazy (I also have qualms about sending a whole lotta JavaScript down the wire just so the end user gets to do something that their browser would do for them anyway). But I get it. I understand why others might wish for greater control, even if it comes with a price tag of fragility.

I think Jake’s navigation transitions proposal is fascinating. What if there were a browser-native way to get more control over how page navigations happen? I reckon that would cover the justification of 90% of single page apps.

That’s a great way of examining these kinds of decisions and questioning how this tension could be resolved. If people are frustrated by the lack of control in browser-native navigations, let’s figure out a way to give them more control. If people are frustrated by the lack of styling for select elements, maybe we should figure out a way of giving them more control over styling.

Hang on though. I feel like I’ve painted a divisive picture, like you have to make a choice between ubiquity or consistency. But the rather wonderful truth is that, on the web, you can have your cake and eat it. That’s what I was getting at with the three-step approach I describe in Resilient Web Design:

  1. Identify core functionality.
  2. Make that functionality available using the simplest possible technology.
  3. Enhance!

Like, say…

  1. The user needs to select an item from a list of options.
  2. Use a select element.
  3. Use JavaScript to replace that native element with a widget of your own devising.

Or…

  1. The user needs to navigate to another page.
  2. Use an a element with an href attribute.
  3. Use JavaScript to intercept that click, add a nice transition, and pull in the content using Ajax.

The pushback I get from people in the control/consistency camp is that this sounds like more work. It kinda is. But honestly, in my experience, it’s not that much more work. Also, and I realise I’m contradicting the part where I said I’m lazy, but that’s why it’s called work. This is our job. It’s not about what we prefer; it’s about serving the needs of the people who use what we build.

Anyway, if I were to rephrase my three-step process in terms of under-engineering and over-engineering, it might look something like this:

  1. Start with user needs.
  2. Build an under-engineered solution—one that might not offer you much control, but that works for everyone.
  3. Layer on a more over-engineered solution—one that might not work for everyone, but that offers you more control.

Ubiquity, then consistency.

Thursday, December 21st, 2017

the bullet hole misconception

The transcript of a terrific talk on the humane use of technology.

Instead of using technology to replace people, we should use it to augment ourselves to do things that were previously impossible, to help us make our lives better. That is the sweet spot of our technology. We have to accept human behaviour the way it is, not the way we would wish it to be.

Explorable Explanations

A collection of interactive lessons—games that teach—featuring the work of Bret Victor, Nicky Case, and more (the site is put together by Nicky Case).

Thursday, December 7th, 2017

The User Experience of Design Systems

When you start a redesign process for a company, it’s very easy to briefly look at all their products (apps, websites, newsletters, etc) and first of all make fun of how bad it all looks, and then design this one single design system for everything. However, once you start diving into why those decisions were made, they often reveal local knowledge that your design system doesn’t solve.

In this talk transcript, Rune Madsen enumerates the reasons for his informed scepticism towards design systems:

  1. The first concern, which is also the main argument of this talk, is that humans – especially designers and engineers – are obsessed with creating systems of order. This is not really driven by a demand from users, so they often tend to benefit the designer, not the user.
  2. My second concern relates to what I believe design systems is doing to our digital experience. We’ve always had trends in graphic design (Swiss design, Flat UI, etc), but I’m getting increasingly concerned that this broad adoption of design systems is creating a design monoculture that really narrows the idea of what digital products can be.
  3. My third concern is that with all this talk about design systems, there’s very little talk about the real problem in digital design, which is processes and tools. Designers love making design manuals, but any design system will completely and utterly fail if it doesn’t help people in the organization produce faster and better products.