Hello.

Mastodon's cross-instance following is clunky. I propose a solution using the web+follow URL scheme, like mailto, to streamline following users on ActivityPub platforms. A user's home instance registers as a handler for web+follow. Clicking a web+follow link opens the home instance, redirecting to a /follow request on the target instance. This page uses a meta refresh tag to redirect to /resolve-app, which redirects back to web+follow: with the user's ID. This triggers the registered handler (if available), creating a seamless follow experience within the user's preferred app. If no handler is installed, the user remains on the target instance's follow page, preserving existing functionality.

Custom URL schemes can enhance web app functionality by handling specific URLs, but detecting scheme support is tricky. Several methods exist, including click handlers, navigation handlers (Blink), and server-side redirects with meta refresh. While the server-side approach offers the most robust solution, it introduces complexity. A key challenge is the limited user understanding of custom schemes, leading to a preference for standard HTTPS URLs. This post explores a common pattern for custom scheme usage, involving detecting navigation failures and presenting alternative UI. The pattern addresses the issue of handling custom schemes like web+follow for Mastodon, aiming to improve user experience. While custom schemes are valuable developer tools, user preference for HTTPS URLs persists. Despite this, custom schemes empower developers to guide users to preferred apps or sites while gracefully handling cases where no suitable option exists. This approach also opens possibilities for other applications, like rebuilding web intents.

I accidentally discovered that Twitter has implemented PWA shortcuts, a feature that allows websites and web apps to provide users with quick access to common actions. This is a great step towards bridging the gap between web and native applications, allowing websites to provide a more app-like experience.

This post introduces a simple yet effective approach to improve offline user experience on the web using Service Workers. Instead of a browser's default offline page, this method displays a custom offline page when the network is unavailable. The provided JavaScript code caches essential offline assets and intercepts navigation requests. If a request fails due to network issues, it serves a pre-cached 'offline.html' page, ensuring a smoother experience for users. This strategy enhances user perception of web applications, especially in areas with unreliable internet connectivity. A key improvement mentioned is the use of Navigation Preload, which optimizes the loading process by not waiting for the Service Worker to boot up for all requests.

I've been exploring Chrome's Shape Detection API and its potential, even creating a QR code detector with a JS polyfill. While I appreciate the API, I'm more impressed by libraries like Jeeliz, which offer faster face detection and broader cross-platform compatibility via WebGL and WASM. This tech allows for augmented reality experiences without large app downloads and data harvesting. There are numerous practical applications for this technology, from text selection and translation to product search and accessibility features. I believe the web is ideal for such experiences, and although I appreciate the native Shape Detection API, its inconsistencies across platforms raise questions about the need for native implementations when web-based solutions using WebGL and WASM can offer better consistency and reach.

The implementation of GDPR consent across the industry is flawed and confusing. Many consent mechanisms offer choices that seem meaningless, as users often can't discern the actual impact of their selection. For example, the difference between accepting all cookies and using only necessary cookies is often unclear, both in terms of functionality and verifiability.

This post discusses the importance of using push notifications responsibly in Progressive Web Apps (PWAs). It highlights the negative impact of intrusive notification prompts and emphasizes the need for providing context and respecting user preferences. The post links to a helpful article and video by Thomas Steiner that provides further guidance on best practices for web push notifications, including avoiding immediate prompts and clearly communicating the value and frequency of notifications.

My QRCode scanner app in China ran into an issue offline: the camera wouldn't start due to a Google Analytics request hanging in the onload event. This highlighted a broader problem of render-blocking third-party assets. If these assets (like scripts) are critical, a slow or failed connection can prevent the page from rendering for over a minute while the browser waits for a timeout. This results in a blank screen for the user. This post explores the impact of render-blocking third-party resources on performance and how optimizing their integration can drastically improve the user experience, particularly in unreliable network conditions.

This blog post discusses the evolution of Progressive Web Apps (PWAs) since their inception in 2015. While PWAs offer numerous benefits like offline functionality, push notifications, and installability, the author observes that adoption hasn't been universal. Many developers and businesses misunderstand PWAs, sometimes treating them as separate products or focusing on single features like push notifications. The post argues that the focus should shift from "apps" to user experience. It proposes a set of principles for modern web experiences: discoverable, safe, fast, smooth, reliable, and meaningful. These principles aim to guide developers towards building better web experiences that naturally embody the core values of PWAs, benefiting both users and businesses.

Web design faces several persistent challenges. Tooling is complex and constantly evolving, making it difficult for designers to keep up. Demonstrating the value of design process to non-designers remains a hurdle. Cross-browser compatibility, especially for older browsers like IE11, continues to hinder progress. Responsive design, while desired, is still difficult to implement effectively across all devices and contexts, and existing tools aren't always adequate. Ultimately, the core issues boil down to process, tools, and achieving recognition for the value of design.

In Chrome 68, the Add to Homescreen banner will no longer automatically appear, even if the site meets the criteria. Instead, developers have control over prompting users. Listen for the beforeinstallprompt event, then present a custom button or UI element to trigger installation when appropriate. This change aims to reduce annoying prompts and give developers more control over the user experience. While potentially impacting install rates initially, it empowers developers to prompt users strategically. Chrome is exploring ambient badging as a less intrusive way to indicate installability.

I recently had the pleasure of attending and thoroughly enjoying a live stream hosted by This Dot, featuring browser representatives from Brave, Beaker, Edge, Chrome, and Mozilla. They discussed recent updates and the future direction of browsers. Key highlights included Beaker Browser's innovative work on the distributed web, Edge's significant updates like Service Worker support and WebP integration, Mozilla's focus on Web Assembly, and Brave's progress with BAT. My team at Google is focused on Discovery, Speed & Reliability, UI Responsiveness, UX, Security, and Privacy. We're working to improve how developers build sites for headless services, optimizing for speed and reliability using metrics like TTI and FID, improving UI responsiveness with techniques like FLIP and Houdini, prioritizing user experience, and addressing security and privacy concerns in light of Intelligent Tracking Prevention and GDPR. It was also exciting to see a shared interest in bringing back Web Intents.

Measuring the impact of autofill is crucial. In WebKit/Blink browsers, the -webkit-autofill pseudo-class helps track autofill, but it's not supported in Firefox. I've found a workaround in Firefox using the input event, checking for the absence of keyboard interaction. Ideally, a standardized :autofill pseudo-class and a dedicated onautocomplete event would simplify this process, allowing developers to measure and manage autofill effectively.

Tired of typing in usernames and passwords? So are your users. Autofill helps, but the Credential Management API gives developers more control. It lets you securely store and retrieve user credentials, simplifying logins with just a couple of taps. This Chrome-only API allows access to a PasswordCredential object, rather than raw passwords. It works with other improvements like proper autofill fields (email, username, new-password, current-password) and offers a potential future where landing and login pages are obsolete. Imagine a web where users stay logged in seamlessly, only re-authenticating when necessary. This post covers how to implement the API, including a demo and sample code. Plus, explore how it might combine with the Web Payment Request API to streamline e-commerce.

TL;DR - Went well. Lots to learn.

I'm still passionate about making web apps easily discoverable and interlinked, even though Web Intents didn't take off as I'd hoped. We web developers boast about the power of the URL, but we're not leveraging it effectively for inter-app linking, which is hindering the web's potential. Recent experiences building a QR code reader and seeing how other apps integrate them highlighted this issue. The web's strength is its zero-install nature, allowing instant access to functionality. However, many web apps erect barriers like landing pages and login forms, negating this advantage. These barriers act like app store install pages, killing the linkability and ease of use that makes the web great. While capturing user data is important, we need to prioritize frictionless usage, perhaps by adopting concepts like "tourist" or "shadow" user accounts. Native apps are exploring app constellations, while we on the web already have the tools but aren't utilizing them effectively. We must allow users instant access if we want truly linkable web apps.

Deep App Links: Changes have come to Chrome and this is my summary of what's happened, why and how to manage the change

I've been working on making html5rocks.com more mobile-friendly, focusing on reducing "Time to first read". The main culprit was the Table of Contents (ToC). My initial experiment with an offscreen ToC using CSS had cross-browser inconsistencies. Now, using existing JS, the ToC is fixed to the footer and toggled into view. I'm still exploring pure CSS solutions. Initially, I favored a small scrollable ToC at the bottom, but Paul Lewis suggested a full-screen ToC, which proved better. It minimizes distractions and clutter, provides more screen space for a readable, easily navigable ToC with larger touch targets and subtle hierarchy, even for long lists. The before/after screenshots demonstrate the improvement.

Many Chrome Web Store users complain that some listed "apps" are just links. While technically true in some cases, the point of the Web Store is to help users discover web apps, new and old. Listing your existing web app is encouraged! It exposes your app to a wider audience. Some users expect a different experience when installing from the store, but for many, it's their first encounter with your app. The key is to get users to your app's core functionality quickly. Prioritize a direct login or, even better, use OpenID for seamless account creation. Don't make users land on a generic product page; they've already chosen to use your app. Speedy access is key. Check out the Diary.com app for an example of a smooth OpenID sign-in process.

This post explains AJAX (Asynchronous JavaScript and XML) and its use in .NET. AJAX allows web pages to update small sections without reloading the entire page, improving user experience. Traditional ASP.NET (1.x) struggles with this as it's designed to reload entire pages. However, .NET's flexible request pipeline allows plugins/HTTPHandlers to manage AJAX requests, enabling developers to execute specific methods within a page. The post lists several .NET AJAX frameworks, including AjaxPro, Arshad.NET, and AjaxAspects, and points readers to ajaxpatterns.org for more options.

I'm curious why social bookmarking services like Simpy, Shadows, and del.icio.us prioritize a user's tags over a global view. When clicking a tag, I'd rather see globally relevant tagged pages than just those from a single user. A single user's tagging habits aren't as useful as seeing the broader community's perspective on a topic. Ideally, these services would offer a toggle between user-specific and global tag views.

I'm changing the focus of AJAXTag. Instead of just giving users related information, I want to let readers explore and discover connections themselves. I'll create an interactive version of my blog, allowing users to generate an OPML file of related data. This is inspired by Memorandum, but focuses on user exploration within areas of interest. What are your thoughts?

I've added Wikipedia document retrieval to my application, but there's a design flaw. Tags currently operate in isolation, unaware of each other's related Wikipedia articles. This can lead to duplicate content in the "related articles" section. To fix this, I need to implement a system that allows tags to share information and avoid redundancy, ultimately improving the user experience. Check out the current version here: http://www.kinlan.co.uk/AjaxExperiments/AjaxTag2

This is the fifth installment in my series on the AJAXTagger's failures. A major issue is its lack of intuitiveness. Users couldn't understand its purpose or how to use it without a demo. While it significantly reduced my tagging time, the next version needs improvements. I'm looking for feedback on how to make it more user-friendly, including better visual cues, a clearer UI, and improved documentation. Email me or comment with your suggestions!

I'm considering redesigning my blog and like the single-post focus of penandthink.com/niggle. However, my blog has frequent posts, so I'm unsure if that style would work. I'm asking readers whether they prefer a blog with a single featured post or a list of recent posts (like my current design showing the last 30). Feedback can be sent to paul.kinlan@gmail.com.