• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

Dion Almaer

Software, Development, Products

  • @dalmaer
  • LinkedIn
  • Medium
  • RSS
  • Show Search
Hide Search

Archives for July 2021

Time to Embrace Escape Hatches on the Web Platform?

July 27, 2021

Progressive Web Apps aren’t reaching their potential at scale. I just spoke about how I think it’s important for the Web to push on its own vision as a platform, but as a universal app platform (one of the key segments, along with content and commerce) it isn’t hitting the mark, mainly on mobile. What if we rethink the web platform, and embrace the “progressive” quality to allow for escape hatches on top of web standards as an interop layer for maximal reach?

The default mode of evolution on the web is deliberate. This gives us a nice eventual consistency across multiple implementations, but  there are times in which it is held back too much and at those times I think it is important for us to break out of the mold, branch off and prove value, while always looking to merge back in the future. We are at one of those times, and here is why our current situation isn’t working for users and developers (and thus the platform).

User Expectations

People go to app stores to find apps. On desktop, the browser as a virtual machine kinda works, and there is enough real estate for the browser chrome to be a feature not just a bug. On mobile that isn’t the case. And expecting users to understand Add to Home Screen is swimming upstream. And of course, there are plenty of uncanny valley situations when using a PWA. It doesn’t come across when you migrate devices. It doesn’t show up across an ecosystem (e.g. widgets, watches, notifications on some platforms, etc).

Developer Expectations

As a developer, knowing that I can’t hit the user bar already has me thinking about how far I can go. I sure as hell don’t want to rewrite a mobile app to target multiple platforms, and LOVE the idea of not reinventing the wheel, but I need to not be locked out of key platform capabilities and user flows.

Add to that the notion of FOMO. When iOS and Android release their new SDKs, how long will it take for me to get access via a web standard feature? Can I risk being locked out of $SOME_COOL_NEW_FEATURE?

Support :focus-visible, Safari, you toilet.

— Heydon (@heydonworks) July 27, 2021

And will Apple ever implement what I need? They have shown, through action, that they have a different vision for the Web, one that is much more focused on the content Web. Given their business and app strategy, it isn’t being evil, it makes sense. They want developers building on their native stack and offering experiences that are differentiated.

We have all tried to push on this for some time, but maybe it’s time for a different tact. Instead of slowly doing all we can to change the calculus for Apple to implement something (e.g. finding ways for their internal teams to request a feature, or getting adoption of something so that it works poorly or slowly, such as YouTube supporting Web Components) let’s think different.

Web as an Interop Layer

It’s interesting to look at iMessage and SMS as another path. The SMS standard acts as an interop layer, where you are able to text between iOS and Android. It doesn’t have all of the fancy features… but it allows for fast iterations when each platform is talking to another device on it’s own system.

This is far from perfect. How frustrating is it to react to a text on iOS, but because someone on the thread is on Android, you get another text with: Liked “repeat of the message”. I see this and conspiracy theories start up in my head…. Surely you could write the Regex to see the pattern and just show the reaction on that message :/

And then there is Spotify and podcasts. Originally, you were very much locked in, but recently Spotify supported RSS and your ability to monetize your own way if you wish. If you can offer choice to developers where they can get different levels of integration based on the direction they go (doing extra work for a platform vs. open standards) that is a real trade off with real choice. Once again though, far from perfect, and I am frustrated with Spotify sucking up “exclusives”, and shoving podcasts down my throat in the app when I just use it for music.

What would this look like for the Web? The standards (and really the implementation of them… which is why compat efforts will always be so important) are the interop layer that gives you the base level functionality and allows you to reach every user with a device that implements a web client. We use progressive enhancement as always to do the right thing to make the experience work as well as it can for the given device and modalities and browser and version that a user is browsing your site with.

But we progressively enhance further, breaking out of the sandbox as needed. The starting point is on getting browser vendors onboard, but if to bogged down you aren’t stuck. We lean into Capacitor type approaches, letting you reach to native when needed, and getting you into the stores that don’t support you with a simple URL. Platforms can give you extras and you can choose to put in the extra work to enhance to them if the ROI is there. We learn from this evolution and always push to eventually bake it into the standards. Just like how I wish that reactions get baked into new versions of texting standards, and how chat apps could eventually get interop (fun fact: I used to be an IRC admin for the University of Minnesota!)

What does this look like?

Let’s say I build an image editor application. On ChromeOS the web is the app platform, so I want my users to be able to double click on the PNG file on their desktop and have it launch and load in the PWA. If this feature isn’t fully implemented on other browsers, give me a way to do it on ChromeOS first. It’s OK!

Now let’s say we want to bring this editor to mobile and are frustrated at the lack of support for *simple* features such as access to a file system. If one OS isn’t getting you what you need, we break off and have a wrapper API that bridges through the native SDK. We have polyfills where we can, and clean ways to use enhanced APIs that don’t break the web experience when we can’t. We can even embrace the fact that the app install step is a nod that the user cares about this experience.

Trust is important. The ephemeral nature of the web is key, and I’m all for leveling the field, but we also need user signals that don’t make UX of an API awful.

Let’s take the image editor example and say that we want to add rich font support and we want to be able to access your local system fonts. If you meet with the security and privacy team first they may point out that a web site knowing which fonts you have is just what finger printing folks would love to see. Instead, what if we protect users and when you sign in we ask users to choose which fonts they want to share…. Like sharing images via a picker vs granting access to your camera roll. You nod for a bit, and then you think through that UX.

Wait, how do I know which fonts I want to use in the future? In my editor I want users to be able to play with their design and quickly flip through fonts to see how they look with the content I have?

Now imagine that this image editor is from Adobe, and picture the user…. Logging into creative cloud which they pay for, and seeing this? Does this keep them safe? Or does it result in closing the web app and just switching to native?

We have this working now!

After many years deep into building an enterprise app development company, I've come to the conclusion that the average developer has no clue what technologies are actually being used at scale inside of large orgs

— Max Lynch (@maxlynch) July 27, 2021

We a history of this evolution. On desktop with Electron, and a huge number of mobile apps embed WebViews, use custom bridges, and use products such as Capacitor.

And we are seeing success stories, particularly within certain verticals such as enterprise and publishing. I remember meeting with a huge media company in Latin America who switched from their native apps to using web + native where needed. It wasn’t just useful for their general ROI, all of their metrics went up and to the right:

  • Positive App Store ratings increased by 25%
  • App size was reduced by 70%
  • Crashes reduced by about 80%
  • Engagement increased.

But how? Well, context matters. They had a large web team and small native teams and this resulted in native always being far behind in features and the overall quality not being the best. You don’t get platform leverage for free. You still need native skills but a core group could watch over some of that and the feature teams could run faster.

And now when this years SDK comes out, they can bridge over to it and access that new branch of evolution.

Let’s consider how to keep up the pace and deliver on user and developer expectations by offering progressive enhancement down to the underlying platform vis escape hatches, and do it in a way that learns from the past (e.g. MS universal apps) allowing us to be constantly merging improvements into main, which are the web standards that we hold dear.

Progressing Web Apps

July 20, 2021

Alex wrote primarily about the role of the App Store in his opus on the pursuit of appiness. It has a lot of deep thinking, and I particularly like how Alex takes apart the distinct pieces that make up the App Store experience, as I find they often get glommed together:

  1. Security screens to prevent malign developer behavior on overpowered native platforms
  2. Discovery mechanisms to help users find content, e.g., search
  3. App distribution tools; i.e., a CDN for binaries
  4. Low-friction payment clearing houses

The topic of app stores and their role is top of mind for the industry right now, and it is appropriate to think about the role of the Open Web here, and how important the web can be as an open distribution tool for apps (and the other vectors).

We have had the opportunity to learn a lot from the rise of mobile, but I have been found myself thinking about the vision for the web as it relates to apps. Instead of solely taking mobile apps, and rendering them at the end of URLs, do we have a vision for, dare I say it, Webby Apps?

From General Purpose to Purpose Built

The Web evolves in a particular manner, due to its openness and the value in being able to keep rendering most content as time moves on. As capabilities have grown, it has been able to move from the world of linked documents to rich experiences. We now have a strong general purpose platform that can be used to build a massive variety of experiences. This is a great thing, and it enables experimentation at the edges.

However, it also tends to get us into some trouble. We see countless debates on how $MY_STACK is the ideal one for all jobs on the Web. What if we could give various approaches space, and think about how to drive purpose build stacks that offer the holotypes that make sense for the type of experience you are trying to deliver?

When you look at two examples on mobile: Apps vs. Games, the most popular tooling differs a lot. Sure, you can choose to build a game using the framework of choice for the host platform, and you could make an app using Unity…. But it doesn’t normally make sense. What is the web’s equivalent here?

The spectrum of Apps and Content

We have a spectrum rather than strict categorization, but I do think that we can find generally smart choices for experiences on this spectrum.

Starting to see richer content tools

At one end we have the content web. The one that publishers and content creators thrive on with the rich capabilities that we offers through the document structure that kicked it all off. I love this Web, and think it is a treasure in that you can own your home on the Internet, and you can build a connection with your audience as they visit you at your domain. There is a lot of innovation in the content creation space, and Google is diving in on how the Web can play a strong role thanks to Paul Bakaus and team!

On the other end we have rich productivity apps, which rival any desktop and mobile host experience. I still remember working on the Bespin code editor, partly to see what the Web could do…. And now we see suites of products that allow you to work with media such as image and video editing.

There is a huge range of experiences in between, which often gets us into some trouble as we may throw out some babies with bath water.

Fast, Rich, Dynamic Commerce

Ilya talking about XR experiences where you can “try on” shoes.

Let’s take commerce, if we go all in on a rich app shell experience that comes all in with a loading indicator…. we may have lost the users that tapped or clicked wanting to quickly see a product. Amortizing the loading cost (which may be just fine with the type of web app that sits pinned on tab one or two all day) becomes a bouncer. But if we build a web site that doesn’t have the type of rich UI that users expect from a delightful retail experience, then you may lose them out the other door. Fortunately, we have middle road options that allow you to start fast and feel rich.

Jason Miller details the Islands Architecture, which can be perfect at delivering a fast content experience that progressively loads richer interactions.

Commerce experiences are deceptively dynamic. There was a period of time where the AMP team thought commerce could be good fit, as speed is so important to conversion. However, the core of commerce is dynamic. You may serve very different content depending on who the users is, based on their preferences, usage, and various attributes about their session.

Within a page such as product details, there is plenty of content that you want to cache aggressively, and different pieces can have very different staleness. Pricing is very dynamic and you want it up to date. Reviews? If a new review comes in a millisecond before you load the page, it’s OK not to show it.

Reaching for Webby Apps

And this gets us to webby apps. We have spent the last decade catching the Web up to mobile, and we have more to do. We needed browsers to scale down to mobile. We needed APIs that work for mobile use cases. We need ways to get into AppStores. There was and will always be so much to do here.

Some may argue that using web technology as a single way to build for multiple platforms is “enough”, and I will have more to say on some of this in an upcoming post on breaking through the Web platform and having more escape hatches, but the Web can offer so much more here. Gmail didn’t feel like Eudora or Outlook at the end of a URL. It felt web-like. What is the vision for the web ~five years from now and how experiences can feel different here vs. uncanny versions?

I often hear “reach” used as a rational for investing in the Web. The Web is ubiquitous. Don’t you want an addressable market of $ENTIRE_INTERNET? I think this is only partially right. You could probably make the case that building a simple productivity tool and putting it in the iOS App Store gives you access to a large enough market, and one that has large wallets. Where this breaks down though IMO is sharing.

I have been working with a friend who is building an exciting space repetition learning system, called Active Recall. When building something like this, you can think in an app-y way and make it a personal data store of your knowledge, and have simple ways to share content that you have to build.

But, as soon as you think about what a truly webby version could be, you see something quite different. When content is addressable, the notion of sharing and people are first class citizens. When I share a deck of content on CSS topics, I know that you will be able to see them even if you have never installed the app. I can share the content on social and know that anyone out there can see it!

And not only can humans see the content, the programmable web, with the Google bot and others are able to index and help people find it.

I don’t just want a web that is akin to binary blobs at the end of URLs, but they happen to use JavaScript and CSS and HTML. I want a web that thrives on the connectivity that ubiquity, and allows for experiences that transcend the siloed app systems.

I think of use cases like the commerce ones we mention, and I legitimately see how the Web can offer an overall experience that is better than an app for each store that you want. We can compose and bring things together.

I can’t wait to see us truly Progress Webby Apps.

Josh, my 11 year old 🙂

Primary Sidebar

Twitter

My Tweets

Recent Posts

  • Piece Together Your Platform with Lego Blocks, Sets, and Kits
  • ai-hints.json: how the ecosystem will help the bots
  • The Pursuit of Taller Hills: Lessons from Football and Product Management
  • Building a modern design system in layers
  • Google A/I/O 2023: In Person Matters

Follow

  • LinkedIn
  • Medium
  • RSS
  • Twitter

Tags

3d Touch 2016 Active Recall Adaptive Design Agile Amazon Echo Android Android Development Apple Application Apps Artificial Intelligence Autocorrect blog Bots Brain Calendar Career Advice Cloud Computing Coding Cognitive Bias Commerce Communication Companies Conference Consciousness Cooking Cricket Cross Platform Deadline Delivery Design Design Systems Desktop Developer Advocacy Developer Experience Developer Platform Developer Productivity Developer Relations Developers Developer Tools Development Distributed Teams Documentation DX Ecosystem Education Energy Engineering Engineering Mangement Entrepreneurship Exercise Family Fitness Football Founders Future GenAI Gender Equality Google Google Developer Google IO Habits Health Hill Climbing HR Integrations JavaScript Jobs Jquery Kids Stories Kotlin Language Leadership Learning LLMs Lottery Machine Learning Management Messaging Metrics Micro Learning Microservices Microsoft Mobile Mobile App Development Mobile Apps Mobile Web Moving On NPM Open Source Organization Organization Design Pair Programming Paren Parenting Path Performance Platform Platform Thinking Politics Product Design Product Development Productivity Product Management Product Metrics Programming Progress Progressive Enhancement Progressive Web App Project Management Psychology Push Notifications pwa QA Rails React Reactive Remix Remote Working Resilience Ruby on Rails Screentime Self Improvement Service Worker Sharing Economy Shipping Shopify Short Story Silicon Valley Slack Soccer Software Software Development Spaced Repetition Speaking Startup Steve Jobs Study Teaching Team Building Tech Tech Ecosystems Technical Writing Technology Tools Transportation TV Series Twitter Typescript Uber UI Unknown User Experience User Testing UX vitals Voice Walmart Web Web Components Web Development Web Extensions Web Frameworks Web Performance Web Platform WWDC Yarn

Subscribe via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Archives

  • August 2023
  • June 2023
  • May 2023
  • March 2023
  • February 2023
  • January 2023
  • September 2022
  • June 2022
  • May 2022
  • April 2022
  • March 2022
  • February 2022
  • November 2021
  • August 2021
  • July 2021
  • February 2021
  • January 2021
  • May 2020
  • April 2020
  • October 2019
  • August 2019
  • July 2019
  • June 2019
  • April 2019
  • March 2019
  • January 2019
  • October 2018
  • August 2018
  • July 2018
  • May 2018
  • February 2018
  • December 2017
  • November 2017
  • September 2017
  • August 2017
  • July 2017
  • May 2017
  • April 2017
  • March 2017
  • February 2017
  • January 2017
  • December 2016
  • November 2016
  • October 2016
  • September 2016
  • August 2016
  • July 2016
  • June 2016
  • May 2016
  • April 2016
  • March 2016
  • February 2016
  • January 2016
  • December 2015
  • November 2015
  • October 2015
  • September 2015
  • August 2015
  • July 2015
  • June 2015
  • May 2015
  • April 2015
  • March 2015
  • February 2015
  • January 2015
  • December 2014
  • November 2014
  • October 2014
  • September 2014
  • August 2014
  • July 2014
  • June 2014
  • May 2014
  • April 2014
  • March 2014
  • February 2014
  • December 2013
  • November 2013
  • October 2013
  • September 2013
  • August 2013
  • July 2013
  • June 2013
  • May 2013
  • April 2013
  • March 2013
  • February 2013
  • December 2012
  • November 2012
  • October 2012
  • September 2012
  • August 2012

Search

Subscribe

RSS feed RSS - Posts

The right thing to do, is the right thing to do.

The right thing to do, is the right thing to do.

Dion Almaer

Copyright © 2023 · Log in

 

Loading Comments...