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.
The URI is a handy thing, it’s kind of like a Command Line Interface. A URI lets you target a site or an app and pass it data and then see a result in some form. Nearly everyone will know and understand that to load a web page we enter http:// or more recently (and more importantly) https://, but Apps can also be targeted directly with a custom form of the ‘https’ prefix called a custom scheme.
I was writing about Service Discovery the other day and I have some thoughts about how we can do inter-app communication on the web more effectively than what we can today. Interactions between web and web, web and apps and apps and web is something that many of you may know that I am passionate about, but it is incredibly hard and using the intent syntax in Android is a great start but has huge problems because it is not portable.