Tags: universal

Fundamentals matter | Go Make Things

I really enjoyed Laurie’s talk in Berlin a few weeks back. I must blog my thoughts on it.

But I must admit that something didn’t sit quite right about the mocking tone he took on the matter of “the fundamentals” (whatever that may mean). Chris shares my misgivings:

Those websites that don’t load on slow connections, or break completely when a JS file fails to load, or don’t work for people with visual or physical impairments?

That’s not an issue of time. It’s an issue of fundamentals.

I think I agree with Laurie that there’s basically no such thing as fundamental technologies (and if there is such a thing, the goalposts are constantly moving). But I agree with Chris with that there is such a thing as fundamental concepts. On the web, for example, accessibility is a core principle of its design that should, in my opinion, be fundamental.

This, basically:

Do I wanna see teenagers building frivolous websites? Absolutely. But when people are getting paid well to build our digital world, they have a responsibility to ensure the right to engage with that world for everyone.

What is the Web? - Jim Nielsen’s Blog

“Be linkable and accessible to any client” is a provocative test for whether something is “of the web”.

The web is something different - daverupert.com

The web is so much bigger than the little boxes we try to put it in. The web is good at many things and not great (yet) at others. The web is a snowball rolling down hill, absorbing other technologies along the way. The web is an interactive window across space and time, a near instant connection to anyone on the planet. The web is something different. I wish we’d see the web more for itself, not defined by its nearest neighbor or navel-gazing over some hypothetical pathway we could have gone down decades ago.

I was really looking forward to speaking at An Event Apart this year. I was going to be on the line-up for Seattle, Boston, and Minneapolis; three cities I really like.

At the start of the year, I decided to get a head-start on my new talk so I wouldn’t be too stressed out when the first event approached. I spent most of January and February going through the chaotic process of assembling a semi-coherent presentation out of a katamari of vague thoughts.

I was making good progress. Then The Situation happened. One by one, the in-person editions of An Event Apart were cancelled (quite rightly). But my talk preparation hasn’t been in vain. I’ll be presenting my talk at an online edition of An Event Apart on Monday, August 17th.

You should attend. Not for my talk, but for Ire’s talk on Future-Proof CSS which sounds like it was made for me:

In this talk, we’ll cover how to write CSS that stands the test of time. From progressive enhancement techniques to accessibility considerations, we’ll learn how to write CSS for 100 years in the future (and, of course, today).

My talk will be about design principles …kinda. As usual, it will be quite a rambling affair. At this point I almost take pride in evoking a reaction of “where’s he going with this?” during the first ten minutes of a talk.

When I do actually get around to the point of the talk—design principles—I ask whether it’s possible to have such a thing as universal principles. After all, the whole point of design principles is that they’re specific to an endeavour, whether that’s a company, an organisation, or a product.

I think that some principles are, if not universal, then at least very widely applicable. I’ve written before about two of my favourites: the robustness principle and the principle of least power:

There’s no shortage of principles, laws, and rules out there, and I find many of them very useful, but if I had to pick just two that are particularly applicable to my work, they would be the robustness principle and the rule of least of power.

What’s interesting about both of those principles is that they are imperative. They tell you how to act:

Be conservative in what you send, be liberal in what you accept.

Choose the least powerful language suitable for a given purpose.

Other princples are imperative, but they tell you what not to do. Take the razors of Occam and Hanlon, for example:

Entities are not to be multiplied without necessity.

Never attribute to malice that which is adequately explained by stupidity.

But these imperative principles are exceptions. The vast majority of “universal” principles take the form of laws that are observations. They describe the state of the world without providing any actions to take.

There’s Hofstadter’s Law, for example:

It always takes longer than you expect, even when you take into account Hofstadter’s Law.

Or Clarke’s third law:

Any sufficiently advanced technology is indistinguishable from magic.

By themselves, these observational laws are interesting but they leave it up to you to decide on a course of action. On the other hand, imperative principles tell you what to do but don’t tell you why.

It strikes me that it could be fun (and useful) to pair up observational and imperative principles:

Because of observation A, apply action B.

For example:

Because of Murphy’s Law, apply the principle of least power.

Or in its full form:

Because anything that can go wrong will go wrong, choose the least powerful language suitable for a given purpose.

I feel like the Jevons paradox is another observational principle that should inform our work on the web:

The Jevons paradox occurs when technological progress increases the efficiency with which a resource is used, but the rate of consumption of that resource rises because of increasing demand.

For example, even though devices, browsers, and networks are much, much better now than they were, say, ten years ago, that doesn’t mean that websites have become better or faster. Instead, it’s precisely because there’s more power available that people think nothing of throwing megabytes of JavaScript at users. See Scott’s theory that 5G Will Definitely Make the Web Slower, Maybe:

JavaScript size has ballooned as networks have improved.

This problem would be addressed if web developers were more conservative in what they sent. The robustness principle in action.

Because of the Jevons paradox, apply the robustness principle.

Admittedly, the expanded version of that is far too verbose:

Because technological progress increases the efficiency with which a resource is used, but the rate of consumption of that resource rises because of increasing demand, be conservative in what you send, be liberal in what you accept.

I’m sure there are more and better pairings to be made: an observational principle to tell you why you should take action, and an imperative principle to tell you what action you should take.

BBC - Future Media Standards & Guidelines - Accessibility Guidelines v2.0

A timely reminder:

The minimum dependency for a web site should be an internet connection and the ability to parse HTML.

Dear Developer, The Web Isn’t About You | sonniesedge.co.uk

This is absolutely brilliant!

Forgive my excitement, but this transcript of Charlie’s talk is so, so good—an equal mix of history and practical advice. Once you’ve read it, share it. I want everyone to have the pleasure of reading this inspiring piece!

It is this flirty declarative nature makes HTML so incredibly robust. Just look at this video. It shows me pulling chunks out of the Amazon homepage as I browse it, while the page continues to run.

Let’s just stop and think about that, because we take it for granted. I’m pulling chunks of code out of a running computer application, AND IT IS STILL WORKING.

Just how… INCREDIBLE is that? Can you imagine pulling random chunks of code out of the memory of your iPhone or Windows laptop, and still expecting it to work? Of course not! But with HTML, it’s a given.

Why the Web Will Win || Matthew Ström: designer & developer

The first 22 years of the web platform were revolutionary. The open, accessible, and feature-rich applications that exist on the platform continue to drive the global economy. The next 5 years look like they’ll be filled with more innovation and growth than ever.

The web will be the platform of the Next Big Thing. Not just as the distribution network many see it as today; the web platform will deliver the most innovative experiences. They’ll be innovative not just for how they use new technology, but also because of how easy it will be for new users to experience.

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.

Progressive Progressive Web Apps - Tales of a Developer Advocate by Paul Kinlan

Paul goes into detail describing how he built a progressive web app that’s actually progressive (in the sense of “enhancement”). Most of the stuff about sharing code between server and client goes over my head, but I understood enough to get these points:

• the “app shell” model is not the only—or even the best—way of building a progressive web app, and
• always, always, always render from the server first.

What I’ve learned about motor impairment

James gives—if you’ll pardon the pun— hands-on advice on making sites that consider motor impairment:

• Don’t assume keyboard access is all you need
• • Auto complete/Autofill
• • Show me my password
• Allow for fine motor control issues
• • Don’t autoplay videos
• • Avoid hover-only controls
• • Infinite scrolling considerations
• Be mindful of touch
• • Avoid small hit targets
• • Provide alternate controls for touch gestures

Far from being a niche concern, visitors with some form of motor impairment likely make up a significant percentage of your users. I would encourage you to test your website or application with your less dominant hand. Is it still easy to use?

Isomorphic rendering on the JAM Stack

Phil describes the process of implementing the holy grail of web architecture (which perhaps isn’t as difficult as everyone seems to think it is):

I have been experimenting with something that seemed obvious to me for a while. A web development model which gives a pre-rendered, ready-to-consume, straight-into-the-eyeballs web page at every URL of a site. One which, once loaded, then behaves like a client-side, single page app.

Now that’s resilient web design!

Server Side React

Remy wants to be able to apply progressive enhancement to React: server-side and client-side rendering, sharing the same codebase. He succeeded, but…

In my opinion, an individual or a team starting out, or without the will, aren’t going to use progressive enhancement in their approach to applying server side rendering to a React app. I don’t believe this is by choice, I think it’s simply because React lends itself so strongly to client-side, that I can see how it’s easy to oversee how you could start on the server and progressive enhance upwards to a rich client side experience.

I’m hopeful that future iterations of React will make this a smoother option.

ZEIT – Next.js

I haven’t made a website with React, but if and when I do, this Node.js framework looks like it aligns nicely with my priorities. It’s all about the universal JavaScript (the artist formerly known as isomorphic JavaScript).

React Isomorphic Demo

It is possible to use React without relying completely on client-side JavaScript to render all your content—though it’s certainly not the default way most tutorials teach React. This ongoing tutorial aims to redress that imbalance.

Besides the main benefit of server rendering giving faster page loads, it also enables large amounts of the site to run without JavaScript. There are many reasons why you would want this, but my personal reasons are that it allows you to completely drop support JavaScript in older browsers, but still have the site function.

Accessibility Matters: Meet Our New Book, “Inclusive Design Patterns” (Pre-Release) – Smashing Magazine

I think it’s a safe bet that this new book by Heydon will be absolutely brilliant.

It’s a handbook with valuable, time-saving techniques that will help you avoid hacky workarounds and solve common issues effectively.

marmelab/universal.css: The only CSS you will ever need

Ensure that your class names never go out of sync with your style declarations with this one simple trick:

Take any CSS rule you want to apply, replace : by -, and dots by -dot-, and you get the name of the corresponding universal css classname.

The only thing missing is immutability, so I would suggest also putting !important after each declaration in the CSS. Voila! No more specificity battles.

Building Web Apps for Everyone - O’Reilly Media

Here’s a fantastic and free little book by Adam Scott. It’s nice and short, covering progressive enhancement, universal JavaScript, accessibility, and inclusive forms.

Download it now and watch this space for more titles around building inclusive web apps, collaboration, and maintaining privacy and security.

Did I mention that it’s free?

Progressive Enhancement Makes Me Sad | HeydonWorks

Well, I’m convinced.

Microsoft’s Radical Bet On A New Type Of Design Thinking

On universal design: “We’re reframing disability as an opportunity.”

One day someone will write a history of the Internet, in which that great series of tubes will emerge as one long chain of inventions not just geared to helping people connect in more ways, but rather, to help more and more types of people communicate just as nimbly as anyone else.

Universal React ◆ 24 ways

I have no hands-on experience with React, but this tutorial by Jack Franklin looks like a great place to start. Before the tutorial begins he succinctly and clearly outlines the perfect architecture for building on the web today:

• The user visits www.yoursite.com and the server executes your JavaScript to generate the HTML it needs to render the page.
• In the background, the client-side JavaScript is executed and takes over the duty of rendering the page.
• The next time a user clicks, rather than being sent to the server, the client-side app is in control.
• If the user doesn’t have JavaScript enabled, each click on a link goes to the server and they get the server-rendered content again.

YES!!!

Y’know, I had a chance to chat briefly with Jack at the Edge conference in London and I congratulated him on the launch of a Go Cardless site that used exactly this technique. He told me that the decision to flip the switch and make it act as a single page app came right at the end of the project. I think that points to a crucial mindset that’s reiterated here:

Now we’ll build the React application entirely on the server, before adding the client-side JavaScript right at the end.