Tags: enhancement

258

sparkline

Sunday, January 7th, 2018

Tuesday, January 2nd, 2018

Robust Client-Side JavaScript – A Developer’s Guide · molily

This is a terrific resource on writing client-side JavaScript without making too many assumptions.

It starts by covering some of the same topics as Resilient Web Design—fault tolerance, Postel’s law, progressive enhancement—but then goes deep, deep, deep into the specifics of applying that to JavaScript.

And the whole thing is available here for free under a Creative Commons licence!

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.

Friday, December 15th, 2017

Webconf.asia - Workshop The Progressive Web

I’m giving a workshop in Hong Kong on February 21st. If you’re in the area, I’d love to see you there. If you know anyone in Hong Kong, please spread the word.

This workshop will teach you how to think in a progressive way. Together we’ll peel back the layers of the web and build upwards, creating experiences that work for everyone. From URL design to Progressive Web Apps, this journey will cover each stage of technological advancement.

Friday, December 1st, 2017

Cascading Web Design with Feature Queries ◆ 24 ways

24 Ways is back! Yay! This year’s edition kicks off with a great article by Hui Jing on using @supports:

Chances are, the latest features will not ship across all browsers at the same time. But you know what? That’s perfectly fine. If we accept this as a feature of the web, instead of a bug, we’ve just opened up a lot more web design possibilities.

Tuesday, November 28th, 2017

i is=”the walrus”

In which Brian takes a long winding route through an explanation of why the is attribute for custom elements is dead before he demonstrates the correct way to use web components:

<!-- instead of writing this -->
<input type="radio" is="x-radio">

<!-- you write this -->
<x-radio>
<input type="radio">
</x-radio>

Sadly, none of the showcase examples I’ve seen for web components do this.

Tuesday, November 7th, 2017

Collapsible Sections

The latest edition of Heydon’s Inclusive Components is absolutely fantastic! The pattern itself—toggling sections of content—is quite straightforward, but then there’s a masterclass in how to create a web component that still allows the content to be accessible in older browsers. The key, as ever, is progressive enhancement:

Whether implemented through web components or not, progressive enhancement not only ensures the interface is well-structured and robust. As we’ve seen here, it can also simplify the editorial process. This makes developing the application and its content more inclusive.

Tuesday, October 31st, 2017

Netflix functions without client-side React, and it’s a good thing - JakeArchibald.com

A great bucketload of common sense from Jake:

Rather than copying bad examples from the history of native apps, where everything is delivered in one big lump, we should be doing a little with a little, then getting a little more and doing a little more, repeating until complete. Think about the things users are going to do when they first arrive, and deliver that. Especially consider those most-likely to arrive with empty caches.

And here’s a good way of thinking about that:

I’m a fan of progressive enhancement as it puts you in this mindset. Continually do as much as you can with what you’ve got.

All too often, saying “use the right tool for the job” is interpreted as “don’t use that tool!” but as Jake reminds us, the sign of a really good tool is its ability to adapt instead of demanding rigid usage:

Netflix uses React on the client and server, but they identified that the client-side portion wasn’t needed for the first interaction, so they leaned on what the browser can already do, and deferred client-side React. The story isn’t that they’re abandoning React, it’s that they’re able to defer it on the client until it’s was needed. React folks should be championing this as a feature.

Thursday, October 19th, 2017

Building a CSS-only image gallery (with fallbacks)

A great step-by-step walkthrough of building a really nice image gallery without any JavaScript.

The end result is really impressive but there’s still the drawback that the browser history will be updated every time you click on an image thumbnail (because the functionality relies on ID attributes referenced via :target). Depending on your use-case, that may or may not be desirable.

Monday, September 25th, 2017

Network Information API

It looks like this is landing in Chrome. The navigator.connection.type property will allow us to progressively enhance based on connection type:

A web application that makes use of a service worker to cache resources during installation might have different bundles of assets that it might cache: a list of crucial assets that are cached unconditionally, and a bundle of larger, optional assets that are only cached ahead of time when navigator.connection.type is 'ethernet' or 'wifi'.

There are potential security issues around fingerprinting that are addressed in this document.

Thursday, September 14th, 2017

Basic grid layout with fallbacks using feature queries

A really nice example of progressive enhancement: creating a layout with inline-block, then flexbox, then Grid.

Friday, August 4th, 2017

CSS: Current, Soon, Someday (Web Directions Code 2017) // Speaker Deck

Oh, how I wish I could’ve been at Web Directions Code in Melbourne to see this amazing presentation by Charlotte. I can’t quite get over how many amazing knowledge bombs she managed to drop in just 20 minutes!

Tuesday, July 25th, 2017

Progressively Enhancing CSS Layout: From Floats To Flexbox To Grid – Smashing Magazine

A great example of progressive enhancement in action.

You can perfectly use CSS grid layout today if you don’t expect exactly the same appearance in every single browser, which isn’t possible to achieve nowadays anyway. I’m well aware that this decision isn’t always up to us developers, but I believe that our clients are willing to accept those differences if they understand the benefits (future-proof design, better accessibility and better performance). On top of that, I believe that our clients and users have — thanks to responsive design — already learned that websites don’t look the same in every device and browser.

Thursday, July 6th, 2017

Your Site—Any Site—Should be a PWA | Aaron Gustafson

Tell it, brother!

PWAs don’t require you use a particular JavaScript framework or any JavaScript framework at all. You don’t need to be building a Single Page App either.

Wednesday, July 5th, 2017

Is it really safe to start using CSS Grid Layout?

Rachel uncovers a great phrase for dealing with older browsers:

It isn’t your fault, but it is your problem.

She points to multiple ways of using CSS Grid today while still providing a decent experience for older browsers.

Crucially, there’s one message that hasn’t changed in fifteen years:

Websites do not need to look the same in every browser.

It’s crazy that there are still designers and developers who haven’t internalised this. And before anyone starts claiming that the problem is with the clients and the bosses, Rachel has plenty of advice for talking with them too.

Your job is to learn about new things, and advise your client or your boss in the best way to achieve their business goals through your use of the available technology. You can only do that if you have learned about the new things. You can then advise them which compromises are worth making.

Wednesday, June 7th, 2017

A day without Javascript

Charlie conducts an experiment by living without JavaScript for a day.

So how was it? Well, with just a few minutes of sans-javascript life under my belt, my first impression was “Holy shit, things are fast without javascript”. There’s no ads. There’s no video loading at random times. There’s no sudden interrupts by “DO YOU WANT TO FUCKING SUBSCRIBE?” modals.

As you might expect, lots of sites just don’t work, but there are plenty of sites that work just fine—Google search, Amazon, Wikipedia, BBC News, The New York Times. Not bad!

This has made me appreciate the number of large sites that make the effort to build robust sites that work for everybody. But even on those sites that are progressively enhanced, it’s a sad indictment of things that they can be so slow on the multi-core hyperpowerful Mac that I use every day, but immediately become fast when JavaScript is disabled.

Friday, May 26th, 2017

traintimes.org.uk performance notes

I love, love, *love, traintimes.org.uk—partly because it’s so useful, but also because it’s so fast. I know public transport is the clichéd use-case when it comes to talking about web performance, but in this case it’s genuine: I use the site on trains and in airports.

Matthew gives a blow-by-blow account of the performance optimisations he’s made for the site, including a service worker. The whole thing is a masterclass in performance and progressive enhancement. I’m so glad he took the time to share this!

Monday, May 1st, 2017

Springer Nature frontend playbook: house style guide

I like it when organisations share their in-house coding styles. This one from Springer Nature not only has guides for HTML, CSS, and JavaScript, but it also has a good primer on progressive enhancement.

Friday, April 28th, 2017

A Case for Progressive Web Applications in 2017

If your company is or is planning on doing business in emerging markets, architecting your web applications for performance through progressive enhancements is one easy way to drastically improve accessibility, retention, and user experience.

This article uses “progressive enhancement” and “progressive web app” interchangeably, which would be true in an ideal world. This is the first of a three part series, and it sounds like it will indeed document how to take an existing site and enhance it into a progressive web app—a strategy I much prefer to creating a separate silo that only works for a subset of devices (the app-shell model being pushed by Google).

Thursday, April 20th, 2017

The work I like. — Ethan Marcotte

Ethan’s been thinking about the trends he’s noticed in the work he’s doing:

  • prototypes over mockups,
  • preserving patterns at scale, and
  • thinking about a design’s layers.

On that last point…

The web’s evolution has never been charted along a straight line: it’s simultaneously getting slower and faster, with devices new and old coming online every day.

That’s why I’ve realized just how much I like designing in layers. I love looking at the design of a page, a pattern, whatever, and thinking about how it’ll change if, say, fonts aren’t available, or JavaScript doesn’t work, or if someone doesn’t see the design as you and I might, and is having the page read aloud to them.