Hello.

This blog post lists various web apps I've generated using Repl.it and WebSim, along with their code. Repl.it apps include tools like an image analyzer, time zone tracker, and a blood pressure tracker. WebSim creations include a 3D globe and gravity simulators. I discuss my preference for Postgres over sqlite, especially with Repl.it's tendency to overwrite sqlite databases upon deployment.

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.

The Web Share Target API is now available as an origin trial in Chrome, bridging the gap between web and native apps. Previously, only native apps could register as share targets, limiting the web's ability to seamlessly integrate with system-level sharing functionalities. This new API empowers installed web apps to receive shared content, opening up exciting possibilities for web developers. The API's potential is highlighted by Twitter's early adoption and my own experimentation with a custom manifest.json file. While file support is still pending, the future looks bright for effortless content sharing between web and native environments.

This blog post reminisces about Apple's promotion of web apps for iPhone before the App Store became dominant. It highlights the now-defunct /webapps/ directory on Apple's website, which showcased various web apps. While many of these web apps remain functional, the post acknowledges that the App Store addressed key challenges for developers and users, such as discoverability, search functionality, and streamlined payments. It also mentions how Apple started to redirect the /webapps/ directory to /iphone/ around 2013.

I've created a Progressive Web App using FFMPEG.js that applies device frames to Android screen recordings. I've also streamlined the ffmpeg.js build process. This opens up exciting possibilities for building powerful web apps for audio and video manipulation. Many existing web-based video tools are outdated and ad-heavy. I'm interested in creating smaller, focused PWAs, each performing a specific task efficiently. I'm planning to build several apps based on this, such as video trimming, format conversion, watermarking, resizing, and splicing. The codebase from my Device Frames project provides a good starting point. I invite others to collaborate on this effort.

This post explores how to use Android Intents to detect if a native app is installed. This technique is useful for web apps that also have a native app version, especially for managing push notifications. It allows developers to seamlessly redirect users to the app if it's installed or fall back to the web experience. The method involves creating a special intent URL that opens the app if present, or redirects to a specific URL with a hash fragment. By monitoring the hash change in the browser, the web app can detect if the app launch failed and proceed with web-based push notification registration. While helpful, this approach highlights the complexity of managing push notifications across web and native apps, reinforcing the argument for web-only solutions.

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.

Does the discovery problem of app stores, search and everywhere else only affect those who don't or can't market?

How do you find ideas for web apps and why is it important to build apps that push the platform?

It might be a hard sell, but there are number of advantages to using the web.

A spent a while living just with web apps. Here is my report.

Maybe? :)

AppCache, while crucial for offline web apps, has significant issues. One major problem arises when integrating with APIs like registerProtocolHandler or registerContentHandler, which use query parameters. AppCache caches each unique URI, including query strings, separately. This is fine online, but offline, only previously cached URIs with specific query strings will work. Updating the app cache also causes every unique URL stored in the app cache group to be re-downloaded, even if they're not in the current manifest, potentially leading to server overload. This post highlights these issues and calls for better documentation and patterns for offline app development.

Badgemator is a web app that simplifies the process of creating badges for your Chrome Web Store listing. It generates a single script tag that you can embed on your website. This tag displays a badge to Chrome users who haven't installed your app, encouraging them to visit your store listing. Badgemator automatically fetches your logo and other details, and you can customize the badge's appearance with CSS. The project is open source, and contributions are welcome!

Hey everyone, I've been playing with the dev channel of Chrome and discovered something huge: background pages for web apps! This means your web app can now run even when the browser is closed, or even after system start-up. It's crazy powerful. You enable this by adding the "background" permission to your app manifest and then using a simple window.open() call with a special third parameter. The background page's state can be toggled with window.close(). Communication between the background page and your app is done using SharedWorkers. Oh, and Appmator now supports this too!

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 blog post introduces Omni Launch, a Chrome extension I built that lets you quickly launch installed web apps directly from the URL bar. Just type "go", followed by a TAB or SPACE, and then the app name. The extension searches your installed apps and provides suggestions as you type. I also explained the development process, which only took about 20 minutes, including setting up the manifest, hooking up event listeners for omnibox input changes and selections, and using the Management API to fetch and launch apps. The code is available on GitHub.

I've created Appmator, a tool to help developers get their web apps into the Chrome Web Store quickly. Just enter your app's URL, and Appmator generates a zip file ready for upload. Appmator is available in the Chrome Web Store and is built using some cool technologies like webfonts, Modernizr, jszip, and more. Source code is available on GitHub.

Just got back from a whirlwind tour of Europe for the Google Developer Days! We hit Munich, Moscow, and Prague, and it was an amazing experience. I gave talks on Chrome Extensions and building great Web Apps (except in Munich, where a local engineer rocked it). The slides are online: Chrome Extensions (needs experimental mode in Chrome dev channel) and Web Apps. I'll post the code on GitHub soon. Met tons of enthusiastic developers working on incredible projects – everything from protein sequencers to automatic app builders. So much innovation happening! (Side note: bring business cards, folks!) Prague was a particular highlight. Check out some photos from my trip!

I had a great time speaking at the Berlin GTUG, despite the unexpectedly hot weather. I presented on Web Apps, highlighting the differences between native and web apps, key principles of good app design, and some of the exciting new possibilities with HTML5, CSS3, and WebSockets. I wish I'd had more time to delve into frameworks for building great apps and do some live coding. Chris Chabot also gave a fantastic talk about Buzz. The venue, BetaHaus, was excellent, and I was impressed by everyone's English fluency. Thanks to all who attended!