Beyond Progressive Web Apps

Web & native live happily ever after

After this year’s Google I/O event, Jeremy took a closer look. In his aptly named article “Regressive Web Apps” he couldn’t help but notice the latest development that seems to pull the plug on URLs. If you haven’t read it yet, do it now.

Two things come to mind.

  1. URLs are great.
  2. Seams are great too.

I completely agree with Jeremy, that’s the bottom line. So we are done? Not entirely.

Getting rid of the benefits of the web is wrong

On top of the overall agreement, I have a tiny issue. The address bar consumes space in my browser. On devices that fit in one’s pocket, screen estate is precious. Browser makers thought about that, so these days the address bar hides and reappears in accordance to the user’s scrolling behavior. That changes the height of the viewport, which may cause annoyance when a website does stuff based on the vh unit. From viewport-sized typography to background images with background-size: cover or contain. If only the address bar behaved more like an overlay, we wouldn’t have those issues. Hold that thought, we’ll get back to that in a moment.

Let me assure you, I like all the features that come with the address bar. Which leaves me in need of being able to access those features. Consequently, I would like to be in charge of showing and hiding the address bar. And no manifest file should stop me from doing that. Why does it contain a display property in the first place? We should not make a choice on behalf of the user. The user should be able to do all the things. Display the URL? Go ahead. Immerse in a fullscreen experience? Be my guest.

Being able to do everything …

… the address bar has to offer, without having to stare at it. Open a new tab. Reload the current tab. Navigate the history. Enter a new URL. Display, copy or bookmark the current URL. The list goes on. To reiterate, not having the address bar in plain sight means we need to give the user the possibility to access it. How to reveal it with no visual cue on the screen? The user could pull the address bar into view, maybe by swiping from the top edge of the screen.

This is where things collide with existing functionality. Swiping from the top is already tied to the OS, not the current app. Well, this is how things are today, we can find ways to make it work. Not just for URLs, who says there is no common ground for a slide-from-top menu that works for both apps and URLs. All implementation details aside, browsers can only go so far, the operating system must be designed to take care of those needs.

BrowserOS to the rescue

When I first saw Palm’s WebOS I was delighted. It did not last. Firefox OS was another exciting step in the right direction. Too soon. Technology wasn’t ready. Users were less than ready. But at some point, despite all the money being made in App Stores, we will have a (mobile) operating system that no longer needs to distinguish between web and native. Think about it, installed apps and URLs living side by side, in harmony. I’ve never used ChromeOS, but there could be similarities. The browser should be something that no longer needs to be launched. Being able to choose your favorite browser continues to be important. Once the browser is woven into the OS, we will simply choose the OS we like the most.

Having a BrowserOS in place, we no longer need criteria for Progressive Web Apps. Whatever you want to open, a website, a “web app,” an app, BrowserOS should simply open it for you. Hopefully without making too many assumptions when doing so.

The (hypothetical) state of web-versus-native on Android.
The mockup on the right hand side shows a hypothetical Chrome browser on Android, where the address bar functionality slides in from the top. The screenshot on the left is a reminder that web and native already found a friendly way to coexist: The App Overview. BTW, only one of the three, i.e., Amazon Kindle, is an installed app.

Okay, full disclosure: I do not like apps. With every new mobile phone, first I have to install three to four additional apps. Then disable over a dozen of the preinstalled ones. (As a finishing touch, I disable all notifications, so once again I agree with Jeremy, but that goes beyond the scope of this article.)

So yes, I still use some apps. To give you an idea, I use the alarm for waking up, the camera for taking pictures, Kindle for reading, and Google Maps for navigation. Not to forget a File Manager and a Password Manager. Turns out my mobile phone is also a phone, so I have apps for phone calls and text messaging. Everything else lives inside the browser. My list of frequently used web apps opened URLs includes Gmail, YouTube, Twitter and various news sites.

Way to go, browser

Right now I don’t know which way the folks over at Google/Android are heading with their latest development. Bleak scenarios aside, I can still imagine ways to settle the web vs. native dispute. It could be a long and bumpy road until we get there. If the destination is worth it, I don’t mind.