The PWA revolution
Installation, notifications, and offline access: discover what a PWA can bring to your project and the limits to test before making your choice.
Sur cette page4 sections
Find the email, click the link, reopen the site, look for the client area. For an occasional visit, that's fine. For a service used regularly on a phone, you quickly understand why someone eventually asks "don't you have an app?".
A PWA, or Progressive Web App, can satisfy part of this need. It remains a web service, but you can give it access similar to an app, notably with an icon on the home screen and a dedicated window on compatible devices.
What I like about this approach is that we can build on the existing service, instead of assuming that the request for an icon forces us to rebuild the entire project.
Installation doesn't look the same everywhere: devices and browsers have their own capabilities. The MDN documentation details these differences. We therefore test the user journey on the relevant phones, rather than preparing a single screenshot and assuming everyone will see the same thing.
And we take care of the client area itself. Adding an icon to a tedious form doesn't suddenly make it pleasant to use. The buttons still need to be accessible, and the user needs to find what they came for.
For a booking, the difference is easy to see. Reviewing a confirmation already received without signal can be practical. Booking a new slot requires knowing current availability; the phone cannot guess it from yesterday's information.
We can also allow a request to be prepared offline and sent later. But the screen must show what is happening. "Request pending" and "booking confirmed" must not look the same, otherwise the client arrives convinced they are expected when no one has received their request.
In any case, the user must accept them and their environment must support them. On iPhone and iPad, WebKit introduced Web Push for web apps added to the home screen starting with version 16.4. Visiting a page in the browser does not automatically mean installing an app that can notify you.
For important information, we keep another way to notify the client if this option is missing. The service must remain understandable even for someone who doesn't want to authorise everything on their phone.
To choose, I like to start with a frequent action: checking a file, tracking a request, finding a booking. We make it work correctly and see if the approach meets the usage. If a function requires phone integration that the web handles poorly, we look into a native app. This potential transition requires work; it's not just a button to toggle.
If your clients are asking for an app, we can look together at what they are really missing. Sometimes, a well-thought-out PWA will suffice. Sometimes not. But we will have started by making their lives easier, rather than by choosing which store we want to appear in.
A PWA, or Progressive Web App, can satisfy part of this need. It remains a web service, but you can give it access similar to an app, notably with an icon on the home screen and a dedicated window on compatible devices.
What I like about this approach is that we can build on the existing service, instead of assuming that the request for an icon forces us to rebuild the entire project.
The same service with a more direct entry point
Imagine a space where your clients track their bookings. If they return often, having it at their fingertips saves them from searching for the link every time. The shortcut has a very practical benefit, even if the underlying operation remains that of a web service.Installation doesn't look the same everywhere: devices and browsers have their own capabilities. The MDN documentation details these differences. We therefore test the user journey on the relevant phones, rather than preparing a single screenshot and assuming everyone will see the same thing.
And we take care of the client area itself. Adding an icon to a tedious form doesn't suddenly make it pleasant to use. The buttons still need to be accessible, and the user needs to find what they came for.
On the train, the page can stay but the signal might not
Offline mode is often presented as a magical property of PWAs. In reality, it has to be prepared: we decide what to keep on the device and what needs to reach the server. Service workers and caching allow us to build this functionality.For a booking, the difference is easy to see. Reviewing a confirmation already received without signal can be practical. Booking a new slot requires knowing current availability; the phone cannot guess it from yesterday's information.
We can also allow a request to be prepared offline and sent later. But the screen must show what is happening. "Request pending" and "booking confirmed" must not look the same, otherwise the client arrives convinced they are expected when no one has received their request.
One useful notification is better than ten invitations to return
Being notified that a request has been accepted is useful. Receiving a message simply because you haven't opened the service for three days, personally, just makes me want to turn off notifications.In any case, the user must accept them and their environment must support them. On iPhone and iPad, WebKit introduced Web Push for web apps added to the home screen starting with version 16.4. Visiting a page in the browser does not automatically mean installing an app that can notify you.
For important information, we keep another way to notify the client if this option is missing. The service must remain understandable even for someone who doesn't want to authorise everything on their phone.
Start with what people will actually use
A PWA can allow working on a common web base rather than immediately multiplying interfaces. This can simplify a project, but there are still screens to adapt, devices to test, and functionality to maintain. Store access is yet another undertaking, with its own rules and validations.To choose, I like to start with a frequent action: checking a file, tracking a request, finding a booking. We make it work correctly and see if the approach meets the usage. If a function requires phone integration that the web handles poorly, we look into a native app. This potential transition requires work; it's not just a button to toggle.
If your clients are asking for an app, we can look together at what they are really missing. Sometimes, a well-thought-out PWA will suffice. Sometimes not. But we will have started by making their lives easier, rather than by choosing which store we want to appear in.
