I was at the party of the Chrome Dev Summit and Miguel Casas-Sanchez on the Chrome team came up to me and said “Hey Paul, I have a demo for you”. Once I saw it, I had to get it into my talk. That API was the Shape Detection API that is currently in the WICG in an incubation and experimentation phase and is a nice incremental addition to the platform.
I like Web Components. It has taken a long time to get here but things are moving in the correct direction with Safari shipping Shadow DOM and now landing support for Custom Elements. I’ve been thinking a lot recently about Web Components, that is custom elements, template, Shadow DOM and CSS variables, specifically I have been focusing some of my thoughts on custom element space and how this can play out on the web in the future because I believe there are lots of interesting possibilities with how the usage of them will evolve over time.
Autofill has a chequered history filled with what I believe is a mild case of FUD. Chrome for the longest time decided to ignore autocomplete=off on forms and fields because we believed that autocomplete provides a huge amount of value for users especially in the context of mobile. One of the problems is that is incredibly hard to measure how impactful autocomplete is to your site. There aren’t really any events that happens when “autocomplete” occurs, so how do you measure what you tell has happened?
It was my eldest son’s birthday the other day, and it was late in the evening on said Birthday and I thought “I will give my son the gift of learning how to program”. It worked as I expected, he looked at me, wrinkled his nose, and got back to playing Fifa sitting next to me whilst I smashed out a terrible game on the amazing microbit. My quick summary is that I think it is an amazing litle device for quickly starting programming and getting into programming with hardware.
In my trials and tribulations to detect when a field has been autofilled, I need to create a shim for monitorEvents so that I can see the event life-cycle of that element and ultimately try to debug it. One thing that I found is that monitorEvents requires an element but for what I am doing I know that there will be an element with an id at some point but I don’t know when it will be created.
I’ve recently started researching autofill and what hints that browsers give to developers that they have automatically filled in a form field on the users behalf. Blink and WebKit browsers have a special CSS pseudo class that you can look at (more in another post), but firefox doesn’t. There must be some event!!! Chrome DevTools has a handy helper function called monitorEvents, you call it with an element as an argument and it will then log to the console all the events that happen on that element.
Many of you know that I am passionate about inter-app communications, specifically the action of sharing. One of the things that I have encouraged anyone who wants to do the next version of Web Intents to do is focus on a very small and specific use case. Well Good News Everybody. Matt Giuca on the Chrome team has been working on a simple API (Web Share) that has the potential to connect websites with native apps and also and it is in Chrome Dev Channel on Android to test.
Owen Campbell-Moore, one of Chrome’s PM’s for Progressive Web Apps and new APIs asked the following question, and instantly Surma (that is the only name we know for him) said “Sockets” @owencm Network connections. Like writing an SSH client as a PWA. — Surma (@DasSurma) August 12, 2016 I also threw in my two pennies, and Marcos Ceres asked for use-cases. @annevk @Paul_Kinlan @DasSurma @owencm I'd still be interested in a good list of fun things that people want to build but can't.
Do we need a browser in the future?
I wrote about screen recording from Android a little while ago and whilst it is cool, I didn’t document anything of the process that I had to get it into the device frame and make the screen recordings look all “profesh”. The process in the past was pretty cumbersome, I would grab the screen recording using my script and then use Screenflow to overlay the video on the device frame and then do export that out to the mp4 followed by a quick bit of GIF hakery.
Wrinkles, Crinkles and lumpy bits.
Entering usernames, emails, identifiers and passwords is a massive pain for users. It’s even worse on mobile as the use has to fiddle around with. Browsers have done a number of things over the years to help with this problem. We started with enhancing autofill across browsers by making it more intelligent, more secure but more importantly synchronised across browsers (so that if you enter data on your desktop it is available instantly on your mobile).
TL;DR - Went well. Lots to learn.
If there is no one around to read your tweet, does it make a difference?
This is a test. It might not look like much but I have integrated WebTorrent streaming in to my blog and bit torrent URLs so that I can distribute content across the web without relying on my site. It does use the WebSeed BEP so that it always has an unchocked seed (my site). I am going to start experimenting a little more with this to see how to measure analytics etc.
Service Worker gives you control. Service Worker offers me as a developer great power and flexibility when creating sites and managing how I can make them fast and resilient to network issues. Because of the flexibility that the Service Worker API offers in terms of control over the network there are a lot of choices that you have to make when managing and this could be daunting the first time that you start to play with the API.
TL;DR - Here is a demo Code Our team has built a lot of Progressive Web Apps recently to demonstrate how we think they can be built: Airhorner, Voice Memos, Guitar Tuner, SVG-OMG are a few that spring to mind. One thing that is common across all of these sites is that they have no server component to store and synchronise data. We built these sites as examples and reference implementations of the types of experiences that we can deliver on the web, they were never intended to be full “Apps” that you would build as a business.
Feel free to ignore.
A question came up the other day in the office: “Everyone keeps saying Web Intents died because of the UX, but no one has actually said what the issues were”. I looked back over a bunch of my notes and blog posts and it’s correct, I don’t think we documented the holistic set of UX issues that we faced. Wide array of actions and data types We never optimized for the user intent and all were treated equally: Sharing == Viewing == Picking == Editing == Any other intent, and this caused a number of issues.
Web Push is great, however if the user already has an app installed that does Push notifications the developer needs to reasonably be able to stop either the app or the web sites notification. However there is no shared ID between site and app (for obvious reasons). There are a couple of strategies that we are experimenting with right now. One of strategy is to try and launch an app and if it is not installed use the web experience.