A step-by-step guide to implementing drag’n’drop, and image previews with the Filereader API. No libraries or frameworks were harmed in the making of this article.
Tuesday, January 16th, 2018
Sunday, January 7th, 2018
Tuesday, January 2nd, 2018
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:
- Use the HTML
The advantage of the first choice is that it’s lightweight, it works everywhere, and the browser does all the hard work for you.
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.
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:
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.
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:
- Identify core functionality.
- Make that functionality available using the simplest possible technology.
- The user needs to select an item from a list of options.
- Use a
- The user needs to navigate to another page.
- Use an
aelement with an
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:
- Start with user needs.
- Build an under-engineered solution—one that might not offer you much control, but that works for everyone.
- 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
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.
Thursday, December 14th, 2017
This looks interesting—a new book by Dean Hume all about progressive web apps. A few chapters are available to download.
Friday, December 1st, 2017
24 Ways is back! Yay! This year’s edition kicks off with a great article by Hui Jing on using
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
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.
Thursday, November 23rd, 2017
Here’s a nice one-sentence definition for the marketing folk:
A Progressive Web App is a regular website following a progressive enhancement strategy to deliver native-like user experiences by using modern Web standards.
But if you’re talking to developers, I implore you to concretely define a Progressive Web App as the combination of HTTPS, a service worker, and a Web App Manifest.
Wednesday, November 15th, 2017
What is a Progressive Web App?
It seems like any new field goes through an inevitable growth spurt that involves “defining the damn thing.” For the first few years of the IA Summit, every second presentation seemed to be about defining what Information Architecture actually is. See also: UX. See also: Content Strategy.
Now it seems to be happening with Progressive Web Apps …which is odd, considering the damn thing is defined damn well.
Regardless of the specifics of the name, what I like about Progressive Web Apps is that they have a clear definition. It reminds me of Responsive Web Design. Whatever you think of that name, it comes with a clear list of requirements:
- A fluid layout,
- Fluid images, and
- Media queries.
Likewise, Progressive Web Apps consist of:
- A service worker, and
- A Web App Manifest.
There’s more you can do in addition to that (just as there’s plenty more you can do on a responsive site), but the core definition is nice and clear.
Except, for some reason, that clarity is being lost.
Here’s a post by Ben Halpern called What the heck is a “Progressive Web App”? Seriously.
I have a really hard time describing what a progressive web app actually is.
He points to Google’s intro to Progressive Web Apps:
Progressive Web Apps are user experiences that have the reach of the web, and are:
- Reliable - Load instantly and never show the downasaur, even in uncertain network conditions.
- Fast - Respond quickly to user interactions with silky smooth animations and no janky scrolling.
- Engaging - Feel like a natural app on the device, with an immersive user experience.
Those are great descriptions of the benefits of Progressive Web Apps. Perfect material for convincing your clients or your boss. But that appears on
developers.google.com …surely it would be more beneficial for that audience to know the technologies that comprise Progressive Web Apps?
Ben Halpern again:
Google’s continued use of the term “quality” in describing things leaves me with a ton of confusion. It really seems like they want PWA to be a general term that doesn’t imply any particular implementation, and have it be focused around the user experience, but all I see over the web is confusion as to what they mean by these things. My website is already “engaging” and “immersive”, does that mean it’s a PWA?
I think it’s important to use the right language for the right audience.
If you’re talking to the business people, tell them about the return on investment you get from Progressive Web Apps.
If you’re talking to the marketing people, tell them about the experiential benefits of Progressive Web Apps.
But if you’re talking to developers, tell them that a Progressive Web App is a website served over HTTPS with a service worker and manifest file.
Tuesday, November 7th, 2017
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.
Monday, November 6th, 2017
Installing Progressive Web Apps
It used to literally say “add to home screen.”
Now it simply says “add.”
I vaguely remember there being some talk of changing the labelling, but I could’ve sworn it was going to change to “install”. I’ve got to be honest, just having the word “add” doesn’t seem to provide much context. Based on the quick’n’dirty usability testing I did with some co-workers, it just made things confusing. “Add what?” “What am I adding?”
Additionally, the prompt appeared immediately on the first visit to the site. I thought there was supposed to be an added “engagement” metric in order for the prompt to appear; that the user needs to visit the site more than once.
You’d think I’d be happy that users will be presented with the home-screen prompt immediately, but based on the behaviour I saw, I’m not sure it’s a good thing. Here’s what I observed:
- The user types the URL
archive.dconstruct.orginto the address bar.
- The site loads.
- The home-screen prompt slides up from the bottom of the screen.
- The user immediately moves to dismiss the prompt (cue me interjecting “Don’t close that!”).
This behaviour is entirely unsurprising for three reasons:
- We web designers and web developers have trained users to dismiss overlays and pop-ups if they actually want to get to the content. Nobody’s going to bother to actually read the prompt if there’s a 99% chance it’s going to say “Sign up to our newsletter!” or “Take our survey!”.
- Because the prompt now appears on the first visit, no trust has been established between the user and the site. If the prompt only appeared on later visits (or later navigations during the first visit) perhaps it would stand a greater chance of survival.
It’s still possible to add a Progressive Web App to the home screen, but the option to do that is hidden behind the mysterious three-dots-vertically-stacked icon (I propose we call this the shish kebab icon to distinguish it from the equally impenetrable hamburger icon).
I was chatting with Andreas from Mozilla at the View Source conference last week, and he was filling me in on how Firefox on Android does the add-to-homescreen flow. Instead of a one-time prompt, they’ve added a persistent icon above the “line of death” (the icon is a combination of a house and a plus symbol).
When a Firefox 58 user arrives on a website that is served over HTTPS and has a valid manifest, a subtle badge will appear in the address bar: when tapped, an “Add to Home screen” confirmation dialog will slide in, through which the web app can be added to the Android home screen.
This kind of badging also has issues (without the explicit text “add to home screen”, the user doesn’t know what the icon does), but I think a more persistently visible option like this works better than the a one-time prompt.
Firefox is following the lead of the badging approach pioneered by the Samsung Internet browser. It provides a plus symbol that, when pressed, reveals the options to add to home screen or simply bookmark.
I don’t think Chrome for Android has any plans for this kind of badging, but they are working on letting the site authors provide their own prompts. I’m not sure this is such a good idea, given our history of abusing pop-ups and overlays.
Sadly, I feel that any solution that relies on an unrequested overlay is doomed. That’s on us. The way we’ve turned browsing the web—especially on mobile—into a frustrating chore of dismissing unwanted overlays is a classic tragedy of the commons. We blew it. Users don’t trust unrequested overlays, and I can’t blame them.
For what it’s worth, my opinion is that ambient badging is a better user experience than one-time prompts. That opinion is informed by a meagre amount of testing though. I’d love to hear from anyone who’s been doing more detailed usability testing of both approaches. I assume that Google, Mozilla, and Samsung are doing this kind of testing, and it would be really great to see the data from that (hint, hint).
But it might well be that ambient badging is just too subtle to even be noticed by the user.
On one end of the scale you’ve got the intrusiveness of an add-to-home-screen prompt, but on the other end of the scale you’ve got the discoverability problem of a subtle badge icon. I wonder if there might be a compromise solution—maybe a badge icon that pulses or glows on the first or second visit?
Of course that would also need to be thoroughly tested.
Tuesday, October 31st, 2017
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.
Sunday, October 22nd, 2017
Pattern Libraries, Performance, and Progressive Web Apps
Ever since its founding in 2005, Clearleft has been laser-focused on user experience design.
Recently we’ve been doing a lot of strategic design work—the really in-depth long-term engagements that begin with research and continue through to design consultancy and collaboration. That means we’ve got availability for front-end development work. Whether it’s consultancy or production work you’re looking for, this could be a good opportunity for us to work together.
There are three particular areas of front-end expertise we’re obsessed with…
We caught the design systems bug years ago, way back when Natalie started pioneering pattern libraries as our primary deliverable (or pattern portfolios, as we called them then). This approach has proven effective time and time again. We’ve spent years now refining our workflow and thinking around modular design. Fractal is the natural expression of this obsession. Danielle and Mark have been working flat-out on version 2. They’re very eager to share everything they’ve learned along the way …and help others put together solid pattern libraries.
Thinking about it, it’s no surprise that we’re crazy about performance at Clearleft. Like I said, our focus on user experience, and when it comes to user experience on the web, nothing but nothing is more important than performance. The good news is that the majority of performance fixes can be done on the front end—images, scripts, fonts …it’s remarkable how much a good front-end overhaul can make to the bottom line. That’s what Graham has been obsessing over.
Progressive Web Apps
Over the years I’ve found myself getting swept up in exciting new technologies on the web. When Clearleft first formed, my head was deep into DOM Scripting and Ajax. Half a decade later it was HTML5. Now it’s service workers. I honestly think it’s a technology that could be as revolutionary as Ajax or HTML5 (maybe I should write a book to that effect).
I’ve been talking about service workers at conferences this year, and I can’t hide my excitement:
There’s endless possibilities of what you can do with this technology. It’s very powerful.
Combine a service worker with a web app manifest and you’ve got yourself a Progressive Web App. It’s not just a great marketing term—it’s an opportunity for the web to truly excel at delivering the kind of user experiences previously only associated with native apps.
I’m very very keen to work with companies and organisations that want to harness the power of service workers and Progressive Web Apps. If that’s you, get in touch.
Whether it’s pattern libraries, performance, or Progressive Web Apps, we’ve got the skills and expertise to share with you.
Thursday, October 19th, 2017
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
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
There are potential security issues around fingerprinting that are addressed in this document.
Saturday, September 23rd, 2017
There’s a lot of misinformation on the internet as to how to build a PWA and how “appy” and SPA-y one must be.
This simply isn’t true. Disappointingly, It is what most of the documentation, blog posts and public discourse seem to imply.
I’m so, so happy to see some pushback against the misinformation that progressive web apps automatically imply client-side rendered single page apps built from scratch. There’s so much value to be had in turbo-charging an existing site into a progressive web app.
But what we don’t need is yet another TLA like Alien Web Apps.
Friday, September 22nd, 2017
You can use
navigator.storage.estimate() to get a (vague) idea of how much space is available on a device for your service worker caches.
Tuesday, September 19th, 2017
Two of my favourite things together at last: pattern libraries and service workers. Infusion is a tool for generating pattern libraries that also work offline.
Thinking about it, it makes total sense that a pattern library should be a progressive web app.
Sunday, September 17th, 2017
There are some great service worker optimisation tips in these slides.