It’s a while since I looked at new web developments. But an idea that was quickly spreading in our team provided me with the perfect reason to have another look at some. The emerging web (browser) feature that we looked at and that we used to realize a small prototype with is called Web Push. At the time I am writing this it essentially works on Chrome on Android (and Firefox, Opera, but…). Sadly not on Safari and especially not on the mobile Safari, which seems it misses ages in recent web developments. This first blog post will explain the idea and the flow. As I am traveling the upcoming days, I will likely have time to write a more detailed and technical post about this soon (I love to work out of airports).
The idea is very simple (which is why I love it) and Web Push is the perfect candidate for solving it.
Ever been at a tech conference and had to stand in line for your cappuccino? Wouldn’t it be great to visit a simple web site, order the coffee and be notified when it’s ready for pickup? You could continue talking with that person, sit longer in that session or simply relax on a sofa while you wait and *not* stand in line.
Would you install an app for ordering coffee? Nope. Apps are so 80’s. Would you scan a QR code / tap and NFC tag / open a simple URL in your browser for that? Definitely ore likely. And that exactly is possible with the right browser today already: you visit a web page, you agree to receive notifications, and then on the server side when some state occurs (like coffee is ready) we can push this info to your browser (even if closed) and it will display a notifcation in the status bar.
- The customer is informed about the possibility to order coffee and be notified when it is ready at the bar via a flyer. The might be a QR code on it, an NFC tag or a simple short URL. Once the URL is entered and the (secure) web page is opened, the list of coffee bars available is shown.
- The customer selects the nearest bar, or the bar with the smallest current waiting time. The next screen shows the products that are available at this coffee bar – like espresso, cappuccino, etc. One more tap brings the customer to the …
- … summary screen where the only typing happens (once, as we save the input box): the customer has to tell us for whom the order is. This is the name that he’ll find on the cup later on. The customer now presses the big order now button. If web push is possible with his system the browser will ask for permussion to show notifications. Once granted, the order is submitted.
- The order confirmation screen will repeat the current active order. That page *only* needs to stay open, if the customer’s browser did not support web push. In this case we’ll inform the customer via server to client messaging via socket.io. This screen will also tell the customer which rough waiting time he has to expect. It’s the number of minutes he’ll likely have to wait and a simple approximation done by the barista which controls the barista order screen.
- Over at the bar, the barista now sees a new order that just came in. He or she will work on the new orders as they come in an also choose the waiting time as he or she sees fit. Once an order is ready, it can be marked done.
Now, two routes are possible. If the order confirmation screen was left open, that screen will show that the order is ready. This is a feature that works regardless of the browser that is being used – on iOS/Android and with all browsers that we know of. This is 6a, the fallback notification channel via server to client messaging.
6b is the fancy way. If the browser supports web push, we’ve informed our customer via a notice before. The customer can now close the browser tab, switch to another app or lock his phone and put it into his pocket. As we’ve shared the push subscription with our server, we can now notify the browser via web push notifications. The notification will be present on the lock screen and system status bar and can be pulled open to reveal the details.
Up next, I’ll write a more technical post about how this all works. Notifications, Push (=Web Push), Service Workers, and Web Install Banners will be some topics that we learnt lot’s about with this experiment and we’ll share what we’ve learnt. It’s also amazing how much really bad and outdated information we’ve found online, so we have a good reason to share this.