147 dead properties and counting.
Wednesday, March 20th, 2019
Thursday, February 7th, 2019
Transcript of Tim Berners-Lee’s talk to the LCS 35th Anniversary celebrations, Cambridge Massachusetts, 1999/April/14
Twenty years ago—when the web was just a decade old—Tim Berners-Lee gave this talk, looking backwards and forwards.
For me the fundamental Web is the Web of people. It’s not the Web of machines talking to each other; it’s not the network of machines talking to each other. It’s not the Web of documents. Remember when machines talked to each other over some protocol, two machines are talking on behalf of two people.
Sunday, January 13th, 2019
You know what I like? Print stylesheets!
I mean, I’m not a huge fan of trying to get the damn things to work consistently—thanks, browsers—but I love the fact that they exist (athough I’ve come across a worrying number of web developers who weren’t aware of their existence). Print stylesheets are one more example of the assumption-puncturing nature of the web: don’t assume that everyone will be reading your content on a screen. News articles, blog posts, recipes, lyrics …there are many situations where a well-considered print stylesheet can make all the difference to the overall experience.
You know what I don’t like? QR codes!
It’s not because they’re ugly, or because they’ve been over-used by the advertising industry in completely inapropriate ways. No, I don’t like QR codes because they aren’t an open standard. Still, I must grudgingly admit that they’re a convenient way of providing a shortcut to a URL (albeit a completely opaque one—you never know if it’s actually going to take you to the URL it promises or to a Rick Astley video). And now that the parsing of QR codes is built into iOS without the need for any additional application, the barrier to usage is lower than ever.
So much as I might grit my teeth, QR codes and print stylesheets make for good bedfellows.
I picked up a handy tip from a Smashing Magazine article about print stylesheets a few years back. You can the combination of a
@media print and generated content to provide a QR code for the URL of the page being printed out. Google’s Chart API provides a really handy shortcut for generating QR codes:
For now, I’ve got the QR code generation happening on The Session for individual discussions, events, recordings, sessions, and tunes. For the tunes, there’s also a separate URL for each setting of a tune, specifically for printing out. I’ve added a QR code there too.
I’ve been thinking about another potential use for QR codes. I’m preparing a new talk for An Event Apart Seattle. The talk is going to be quite practical—for a change—and I’m going to be encouraging people to visit some URLs. It might be fun to include the biggest possible QR code on a slide.
I’d better generate the images before Google shuts down that API.
Thursday, October 4th, 2018
I like the robustness that comes with declarative languages. I also like the power that comes with imperative languages. Best of all, I like having the choice.
audio elements, for example. If you want, you can embed a video or audio file into a web page using a straightforward declaration in HTML.
<audio src="..." controls><!-- fallback goes here --></audio>
Client-side form validation is another good example. For most us, the HTML attributes—
type, etc.—are probably enough most of the time.
<input type="email" required />
<input type="geolocation" />
(And just in case you’re thinking of the fallback—which would be for the
input element to be rendered as though its
type value were
text—and you think it’s ludicrous to expect users with non-supporting browsers to enter latitude and longitude coordinates by hand, I direct your attention to
input type="color": in non-supporting browsers, it’s rendered as
input type="text" and users are expected to enter colour values by hand.)
Anyway, that’s just one example. Like I said, it’s not that I’m in favour of declarative solutions instead of imperative ones; I strongly favour the choice offered by providing declarative solutions as well as imperative ones.
cache APIs, for example. But I think we should be careful that it doesn’t become the only way of exposing new browser features. I think that, wherever possible, the design pattern of exposing new features declaratively and imperatively offers the best of the both worlds—ease of use for the simple use cases, and power for the more complex use cases.
This is a rather beautiful piece of writing by Tom (especially the William Gibson bit at the end). This got me right in the feels:
Web 2.0 really, truly, is over. The public APIs, feeds to be consumed in a platform of your choice, services that had value beyond their own walls, mashups that merged content and services into new things… have all been replaced with heavyweight websites to ensure a consistent, single experience, no out-of-context content, and maximising the views of advertising. That’s it: back to single-serving websites for single-serving use cases.
A shame. A thing I had always loved about the internet was its juxtapositions, the way it supported so many use-cases all at once. At its heart, a fundamental one: it was a medium which you could both read and write to. From that flow others: it’s not only work and play that coexisted on it, but the real and the fictional; the useful and the useless; the human and the machine.
Thursday, August 16th, 2018
A step-by-step guide to wrapping up a self-contained bit of functionality (a camera, in this case) into a web component.
Mind you, it would be nice if there were some thought given to fallbacks, like say:
<simple-camera> <input type="file" accept="image/*"> </simple-camera>
Saturday, June 16th, 2018
An even-handed assessment of the benefits and dangers of machine learning.
Tuesday, June 5th, 2018
A thorough explanation of the history and inner workings of Cross-Origin Resource Sharing.
Like tales of a mythical sea beast, every developer has a story to tell about the day CORS seized upon one of their web requests, dragging it down into the inexorable depths, never to be seen again.
Thursday, May 3rd, 2018
It is very disheartening to read misinformation like this:
A progressive web app is an enhanced version of a Single Page App (SPA) with a native app feel.
To quote from The Last Jedi, “Impressive. Everything you just said in that sentence is wrong.”
But once you get over that bit of misinformation at the start, the rest of this article is a good run-down of planning and building a progressive web app using one possible architectural choice—the app shell model. Other choices are available.
Tuesday, May 1st, 2018
What’s new in Microsoft Edge in the Windows 10 April 2018 Update - Microsoft Edge Dev BlogMicrosoft Edge Dev Blog
Service workers, push notifications, and variable fonts are now shipping in Edge.
Tuesday, April 3rd, 2018
Designing Progressive Web Apps by Jason Grigsby
Jason wants to talk about a situation you might find yourself in. You’re in a room and in walks the boss, who says “We need a progressive web app.” Now everyone is asking themselves “What is a progressive web app?” Or maybe “How does the CEO even know about progressive web apps?”
Well, trade publications are covering progressive web apps. Lots of stats and case studies are being published. When executives see this kind of information, they don’t want to get left out. Jason keeps track of this stuff at PWA Stats.
Answering the question “What is a progressive web app?” is harder than it should be. The phrase was coined by Frances Berriman and Alex Russell. They listed ten characteristics that defined progressive web apps. The “linkable” and “progressive” characteristics are the really interesting and new characteristics. We’ve had technologies before (like Adobe Air) that tried to make app-like experiences, but they weren’t really of the web. Progressive web apps are different.
Despite this list of ten characteristics, even people who are shipping progressive web apps find it hard to define the damn thing. The definition on Google’s developer site keeps changing. They reduced the characteristics from ten to six. Then it became “reliable, fast, and engaging.” What does that mean? Craigslist is reliable, fast, and engaging—does that mean it’s a progressive web app.
The technical definition is useful (kudos to me, says Jason):
- service worker
- manifest file
If you don’t have those three things, it’s not a progressive web app.
We should definitely use HTTPS if we want make life harder for the NSA. Also browser makers are making APIs available only under HTTPS. By July, Chrome will mark HTTP sites as insecure. Every site should be under HTTPS.
Service workers are where the power is. They act as a proxy. They allow us to say what we want to cache, what we want to go out to the network for; things that native apps have been able to do for a while. With progressive web apps we can cache the app shell and go to the network for content. Service workers can provide a real performance boost.
A manifest file is simply a JSON file. It’s short and clear. It lists information about the app: icons, colours, etc.
Once you provide those three things, you get benefits. Chrome and Opera on Android will prompt to add the app to the home screen.
So that’s what’s required for progressive web apps, but there’s more to them than that (in the same way there’s more to responsive web design than the three requirements in the baseline definition).
The hype around progressive web apps can be a bit of a turn-off. It certainly was for Jason. When he investigated the technologies, he wondered “What’s the big deal?” But then he was on a panel at a marketing conference, and everyone was talking about progressive web apps. People’s expectations of what you could do on the web really hadn’t caught up with what we can do now, and the phrase “progressive web app” gives us a way to encapsulate that. As Frances says, the name isn’t for us; it’s for our boss or marketer.
Jason references my post about using the right language for the right audience.
Should you have a progressive web app? Well, if you have a website, then the answer is almost certainly “Yes!” If you make money from that website, the answer is definitely “Yes!”
But there’s a lot of FUD around progressive web apps. It brings up the tired native vs. web battle. Remember though that not 100% of your users or customers have your app installed. And it’s getting harder to convince people to install apps. The average number of apps installed per month is zero. But your website is often a customer’s first interaction with your company. A better web experience can only benefit you.
Often, people say “The web can’t do…” but a lot of the time that information is out of date. There are articles out there with outdated information. One article said that progressive web apps couldn’t access the camera, location, or the fingerprint sensor. Yet look at Instagram’s progressive web app: it accesses the camera. And just about every website wants access to your location these days. And Jason knows you can use your fingerprint to buy things on the web because he accidentally bought socks when he was trying to take a screenshot of the J.Crew website on his iPhone. So the author of that article was just plain wrong. The web can do much more than we think it can.
Another common objection is “iOS doesn’t support progressive web apps”. Well, as of last week that is no longer true. But even when that was still true, people who had implemented progressive web apps were seeing increased conversion even on iOS. That’s probably because, if you’ve got the mindset for building a progressive web app, you’re thinking deeply about performance. In many ways, progressive web apps are a trojan horse for performance.
These are the things that people think about when it comes to progressive web apps:
- Making it feel like a app
- Installation and discovery
- Offline mode
- Push notifications
- Beyond progressive web app
Making it feel like a app
What is an app anyway? Nobody can define it. Once again, Jason references my posts on this topic (how “app” is like “obscenity” or “brunch”).
A lot of people think that “app-like” means making it look native. But that’s a trap. Which operating system will you choose to emulate? Also, those design systems change over time. You should define your own design. Make it an exceptional experience regardless of OS.
It makes more sense to talk in terms of goals…
Goal: a more immersive experience.
Possible solution: removing the browser chrome and going fullscreen?
You can define this in the manifest file. But as you remove the browser chrome, you start to lose things that people rely on: the back button, the address bar. Now you have to provide that functionality. If you move to a fullscreen application you need to implement sharing, printing, and the back button (and managing browser history is not simple). Remember that not every customer will add your progressive web app to their home screen. Some will have browser chrome; some won’t.
Goal: a fast fluid experience.
Possible solution: use an app shell model.
You want smooth pages that don’t jump around as the content loads in. The app shell makes things seem faster because something is available instantly—it’s perceived performance. Basically you’re building a single page application. That’s a major transition. But thankfully, you don’t have to do it! Progressive web apps don’t have to be single page apps.
Goal: an app with personality.
Possible solution: Animated transitions and other bits of UI polish.
Really, it’s all about delight.
Installation and discovery
In your manifest file you can declare a background colour for the startup screen. You can also declare a theme colour—it’s like you’re skinning the browser chrome.
You can examine the manifest files for a site in Chrome’s dev tools.
Once you’ve got a progressive web app, some mobile browsers will start prompting users to add it to their home screen. Firefox on Android displays a little explainer the first time you visit a progressive web app. Chrome and Opera have add-to-homescreen banners which are a bit more intrusive. The question of when they show up keeps changing. They use a heuristic to decide this. The heuristic has been changed a few times already. One thing you should consider is suppressing the banner until it’s an optimal time. Flipkart do this: they only allow it on the order confirmation page—the act of buying something makes it really likely that someone will add the progressive web app to their home screen.
What about app stores? We don’t need them for progressive web apps—they’re on the web. But Microsoft is going to start adding progressive web apps to their app store. They’ve built a site called PWA Builder to help you with your progressive web app.
On the Android side, there’s Trusted Web Activity which is kind of like PhoneGap—it allows you to get a progressive web app into the Android app store.
But remember, your progressive web app is your website so all the normal web marketing still applies.
A lot of organisations say they have no need for offline functionality. But everyone has a need for some offline capability. At the very least, you can provide a fallback page, like Trivago’s offline maze game.
You can cache content that has been recently viewed. This is what Jason does on the Cloud Four site. They didn’t want to make any assumptions about what people might want, so they only cache pages as people browse around the site.
If you display cached information, you might want to display how stale the information is e.g. for currency exchange rates.
Another option is to let people choose what they want to keep offline. The Financial Times does this. They also pre-cache the daily edition.
If you have an interactive application, you could queue tasks and then carry them out when there’s a connection.
Or, like Slack does, don’t let people write something if they’re offline. That’s better than letting someone write something and then losing it.
Workbox is a handy library for providing offline functionality.
There are third-party push notification services that take care of a lot of this for you. Jason has used OneSignal.
Remember that people are really annoyed by push notifications. Don’t ask for permission immediately. Don’t ask someone to marry you on a first date. On Cloud Four’s blog, they only prompt after the user has read an article.
Twitter’s progressive web app does this really well. It’s so important that you do this well: if a user says “no” to your push notification permission request, you will never be able to ask them again. There used to be three options on Chrome: allow, block, or close. Now there are just two: allow or block.
Beyond progressive web apps
There are a lot of APIs that aren’t technically part of progressive web apps but get bundled in with them. Like the Credentials Management API or the Payment Request API (which is converging with ApplePay).
So how should you plan your progressive web app launch? Remember it’s progressive. You can keep adding features. Each step along the way, you’re providing value to people.
Start with some planning and definition. Get everyone in a room and get a common definition of what the ideal progressive web app would look like. Remember there’s a continuum of features for all five of the things that Jason has outlined here.
Benchmark your existing site. It will help you later on.
Assess your current website. Is the site reasonably fast? Is it responsive? Fix those usability issues first.
Next, do the baseline. Switch to HTTPS. Add a manifest file. Add a service worker. Apart from the HTTPS switch, this can all be done on the front end. Don’t wait for all three: ship each one when they’re ready.
Then do front-end additions: pre-caching pages, for example.
Finally, there are the larger initiatives (with more complex APIs). This is where your initial benchmarking really pays off. You can demonstrate the value of what you’re proposing.
Every step on the path to a progressive web app makes sense on its own. Figure out where you want to go and start that journey.
Tuesday, February 13th, 2018
XML 1.0 was released on February 10th, 1998. I remember the hype around XML at the time—it was our saviour, the chosen one, prophesied to bring balance to data exchange. Things didn’t quite work out that way, but still…
Twenty years later, it seems obvious that the most important thing about XML is that it was the first. The first data format that anyone could pack anything up into, send across the network to anywhere, and unpack on the other end, without asking anyone’s permission or paying for software, or for the receiver to have to pay attention to what the producer thought they’d produced it for or what it meant.
Friday, January 26th, 2018
Chris has set up a whole site dedicated to someone-else’s-server sites with links to resources and services (APIs), along with ideas of what you could build in this way.
Tuesday, January 16th, 2018
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.
Friday, December 29th, 2017
Three technologies that Ada is excited about:
- a service: IndieAuth,
- a front end library: Comlink,
- a pattern: APIs as Web Components.
Monday, June 12th, 2017
The transcript of Josh’s fantastic talk on machine learning, voice, data, APIs, and all the other tools of algorithmic design:
The design and presentation of data is just as important as the underlying algorithm. Algorithmic interfaces are a huge part of our future, and getting their design right is critical—and very, very hard to do.
Josh put together ten design principles for conceiving, designing, and managing data-driven products. I’ve added them to my collection.
- Favor accuracy over speed
- Allow for ambiguity
- Add human judgment
- Advocate sunshine
- Embrace multiple systems
- Make it easy to contribute (accurate) data
- Root out bias and bad assumptions
- Give people control over their data
- Be loyal to the user
- Take responsibility
Tuesday, May 23rd, 2017
Got questions about the security of service workers? This document probably has the answer.
Tuesday, January 3rd, 2017
Paul takes a look at the year ahead on the web and likes what he sees. There’s plenty of new browser features and APIs of course, but more interesting:
The web reaching more people as they come online with Mobile. There is still a huge amount of potential and growth in India, Indonesia, China, Thailand, Vietnam, all of Africa. You name it, mobile is growing massively still and the web is accessible on all of these devices.
Friday, December 30th, 2016
This document provides Best Practices related to the publication and usage of data on the Web designed to help support a self-sustaining ecosystem. Data should be discoverable and understandable by humans and machines.
Monday, December 19th, 2016
A run-down of all the functionality that you get in browsers these days. One small quibble with the title: most of the features and APIs described here aren’t limited to mobile browsers. Still, this is a great reminder that you probably don’t need to create a native app to get the most out of a mobile device.