Jessman5 on Twitter: “I made a poster from @adactio’s talk about Resilience. :) This took me way too long…”
I love this illustration that Jess made of my Resilience talk at the Render conference.
Journal 2305 Articles 63 Links 5873 Notes 2353
I love this illustration that Jess made of my Resilience talk at the Render conference.
Ariel and Lisa have redesigned the excellent Spacehack site and it’s looking stellar!
There were plenty of talks about building for the web at this year’s Google I/O event. That makes a nice change from previous years when the web barely got a look in and you’d be forgiven for thinking that Google I/O was an event for Android app developers.
This year’s event showed just how big Google is, and how it doesn’t have one party line when it comes to the web and native. At the same time as there were talks on Service Workers and performance for the web, there was also an unveiling of Android Instant Apps—a full-frontal assault on the web. If you thought it was annoying when websites door-slammed you with intrusive prompts to install their app, just wait until they don’t need to ask you anymore.
I've been "Maybe I'll go Android" for awhile but today's announcement of http:// links getting hijacked into apps got me all like Nope.— Dave Rupert (@davatron5000) May 18, 2016
Peter has looked a bit closer at Android Instant Apps and I think he’s as puzzled as I am. Either they are sandboxed to have similar permission models to the web (in which case, why not just use the web?) or they allow more access to native APIs in which case they’re a security nightmare waiting to happen. I’m guessing it’s probably the former.
A lot of those points are shared by good native apps, but the first and last points in that list are key features of the web: being responsive and linkable.
Alas many of the current examples of so-called Progressive Web Apps are anything but. Flipkart and The Washington Post have made Progressive Web Apps that are getting lots of good press from Google, but are mobile-only.
I’m getting very concerned that the success criterion for Progressive Web Apps is changing from “best practices on the web” to “feels like native.” That certainly seems to be how many of the current crop of Progressive Web Apps are approaching the architecture of their sites. I think that’s why the app-shell model is the one that so many people are settling on.
Personally, I’m not a fan of the app-shell model. I feel that it prioritises exactly the wrong stuff—the interface is rendered quickly while the content has to wait. It feels weirdly like a hangover from Appcache. I also notice it being used as a get-out-of-jail-free card, much like the ol’ “Single Page App” descriptor; “Ah, I can’t do progressive enhancement because I’m building an app shell/SPA, you see.”
But whatever. That’s just, like, my opinion, man. Other people can build their app-shelled SPAs and meanwhile I’m free to build websites that work everywhere, and still get to use all the great technologies that power Progressive Web Apps. That’s one of the reasons why I’ve been quite excited about them—all the technologies and methodologies they promote match perfectly with my progressive enhancement approach: responsive design, Service Workers, good performance, and all that good stuff.
For example, I’ve seen people use a meta viewport declaration to disable pinch-zooming on their sites. As justification they point to the fact that you can’t pinch-zoom in most native apps, therefore this web-based app should also prohibit that action. The inability to pinch-zoom in native apps is a bug. By also removing that functionality from web products, people are reproducing unnecessary bugs. It feels like a cargo-cult approach to building for the web: slavishly copy whatever native is doing …because everyone knows that native apps are superior to websites, right?
Here’s another example of the cargo-cult imitation of native. In your manifest JSON file, you can declare a
display property. You can set it to
fullscreen. If you set it to
fullscreen then, when the site is launched from the home screen, it won’t display the address bar. If you set the
display property to
browser, the address bar will be visible on launch. Now, personally I like to expose those kind of seams:
The idea of “seamlessness” as a desirable trait in what we design is one that bothers me. Technology has seams. By hiding those seams, we may think we are helping the end user, but we are also making a conscience choice to deceive them (or at least restrict what they can do).
Other people disagree. They think it makes more sense to hide the URL. They have a genuine concern that users will be confused by launching a website from the home screen in a browser (presumably because the user’s particular form of amnesia caused them to forget how that icon ended up on their home screen in the first place).
Fair enough. We’ll agree to differ. They can set their
display property how they want, and I can set my
display property how I want. It’s a big web after all. There’s no one right or wrong way to do this. That’s why there are multiple options for the values.
Or, at least, that was the situation until recently…
Remember when I wrote about how Chrome on Android will show an “add to home screen” prompt if your Progressive Web App fulfils a few criteria?
Well, those goalposts have moved. There is now a new criterion:
Chrome developers have decided that displaying URLs is not “best practice”. It was filed as a bug.
I’m somewhat flabbergasted by this. The killer feature of the web—URLs—are being treated as something undesirable because they aren’t part of native apps. That’s not a failure of the web; that’s a failure of native apps.
Now, don’t get me wrong. I’m not saying that everyone should be setting their
display property to
browser. That would be far too prescriptive. I’m saying that it should be a choice. It should depend on the website. It should depend on the expectations of the users of that particular website. To declare that all users of all websites will be confused by seeing a URL is so presumptuous and arrogant that it beggars belief.
I wouldn’t even have noticed this change of policy if it weren’t for the newly-released Lighthouse tool for testing Progressive Web Apps. The Session gets a good score but under “Best Practices” there was a red mark against the site for having
display: browser. Turns out that’s the official party line from Chrome.
Just to clarify: you can have a site that has literally no HTML or turns away entire classes of devices, yet officially follows “best practices” and gets rewarded with an “add to home screen” prompt. But if you have a blazingly fast responsive site that works offline, you get nothing simply because you don’t want to hide URLs from your users:
I want people to be able to copy URLs. I want people to be able to hack URLs. I’m not ashamed of my URLs …I’m downright proud.
The app manifest declares properties of the app, but the
displayproperty isn’t about the app; it’s about how the app’s developer wants it to be shown. Do they want to proudly declare that this app is on the web and of the web? Then they’ll add the URL bar. Do they want to conceal that this is actually a web app in order to look more like “native” apps? Then they’ll hide the URL bar.
I think there’s something to that, but digging deeper, developers and designers don’t make decisions like that in isolation. They’re generally thinking about what’s best for users. So, yes, absolutely, different apps will have different
display properties, but that shouldn’t be down to the belief system of the developer; it should be down to the needs of the users …the specific needs of the specific users of that specific app. For the Chrome team to come down on one side or the other and arbitrarily declare that one decision is “correct” for every single Progressive Web App that is ever going to be built …that’s a political decision. It kinda feels like an abuse of power to me. Withholding the “add to home screen” prompt like that has a whiff of blackmail about it.
The other factors that contribute to the “add to home screen” prompt are pretty uncontroversial:
This isn’t the first time that Chrome developers have made a move against the address bar. It’s starting to grind me down.
Up until now I’ve been a big fan of Progressive Web Apps. I understood them to be combining the best of the web (responsiveness, linkability) with the best of native (installable, connectivity independent). Now I see that balance shifting towards the native end of the scale at the expense of the web’s best features. I’d love to see that balance restored with a little less emphasis on the “Apps” and a little more emphasis on the “Web.” Now that would be progressive.
Hmmm …I think Jeffrey might have just given me my new job title.
I am shocked and disgusted by this arbitrary decision by the Chrome team. If your Progressive Web App doesn’t set its manifest to obscure its URL, you get punished by missing out on the add to home screen prompt.
Strongly disagree with Lighthouse wanting “Manifest’s display property set to standalone/fullscreen to allow launching without address bar.”
A typically superb article by Aaron. Here, he breaks down a resilient approach to building for the web by examining the multiple ways you could add a button to a page. There’s a larger lesson here too:
We don’t control where our web-based products go or how our users access them. All we can do is imagine as many less-than-perfect scenarios as possible and do our best to ensure our creations will continue to do what they’re supposed to do. One of the easiest ways to do that is to be aware of and limit our dependencies.
Unfollowing people on Twitter who think their Game Of Thrones spoilers are oh-so-clever.
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?
I’ll be speaking to students in Vasilis’s class for Communication and Multimedia Design in Amsterdam right before CSS Day. There are (free) tickets available if you’re around. I’ll be talking about digital preservation and long-term thinking on the web.
This meetup is, like all other Icons Meetups, free to attend for everyone. For students and lecturers of CMD Amsterdam, of course. But also for all professional (digital) designers who want to be inspired.
A fascinating thought experiment from Ted Chiang:
So let’s imagine a world in which Chinese characters were never invented in the first place. Given such a void, the alphabet might have spread east from India in a way that it couldn’t in our history, but, to keep this from being an Indo-Eurocentric thought experiment, let’s suppose that the ancient Chinese invented their own phonetic system of writing, something like the modern Bopomofo, some thirty-two hundred years ago. What might the consequences be?
Bidding farewell to Boston after a thoroughly lovely week.
I’ve been poking around at Google’s information on “instant apps” since they announced it at Google I/O. My initial impressions mirror Peter’s.
Either they allow access to more device APIs (which could be a massive security hole) or else they’re more or less websites.