![\"\"](\"https://www.aaron-gustafson.com/i/posts/2023-10-09/widgets-promotion.gif\")
It was a long time coming, but I finally had a chance to put the work I did on a widgets proposal for PWAs into practice on my own site. I’m pretty excited about it!
\nI had the original idea for “projections” way back in 2019. Inspired by OS X’s Dashboard Widgets and Adobe AIR, I’d begun to wonder if it might be possible to project a component from a website into those kinds of surfaces. Rather than building a bespoke widget that connected to an API, I thought it made sense to leverage an installed PWA to manage those “projections.” I shared the idea at TPAC that year and got some interest from a broad range of folks, but didn’t have much time to work on the details until a few years later.
\nIn the intervening time, I kept working through the concept in my head. I mean in an ideal world, the widget would just be a responsive web page, right? But if that were the case, what happens when every widget loads the entirety of React to render their stock ticker? That seemed like a performance nightmare.
\nIn my gut, I felt like the right way to build things would be to have a standard library of widget templates and to enable devs to flow data into them via a Service Worker. Alex Russell suggested I model the APIs on how Notifications are handled (since they serve a similar function) and I was off to the races.
\nI drafted a substantial proposal for my vision of how PWA widgets should work. Key aspects included:
\niframe);After continuing to gently push on this idea with colleagues across Microsoft (and beyond), I discovered that the Windows 11 team was looking to open up the new Widget Dashboard to third-party applications. I saw this as an opportunity to turn my idea into a reality. After working my way into the conversation, I made a solid case for why PWAs needed to be a part of that story and… it worked! (It no doubt helped that companies including Meta, Twitter, and Hulu were all invested in PWA as a means of delivering apps for Windows.)
\nWhile the timeline for implementation didn’t allow us to tackle the entirety of my proposal, we did carve out the pieces that made for a compelling MVP. This allowed us to show what’s possible, see how folks use it, and plan for future investment in the space.
\nSadly, it meant tabling two features I really loved:
\nI’m sincerely hopeful these two features eventually make their way to us as I think they truly unlock the power of the widget platform. Perhaps, with enough uptake on the current implementation, we can revisit these in the not-too-distant future.
\nTo test things out, I decided to build two widgets for this site:
\nBoth are largely the same in terms of their setup: They display a list of linked titles from this site.
\nGiven that they were going to be largely identical, I made a single “feed” template for use in both widgets. The templating tech I used is called Adaptive Cards, which is what Windows 11 uses for rendering.
\nAdaptive Card templates are relatively straightforward JSON:
\n{\n \"type\": \"AdaptiveCard\",\n \"$schema\": \"http://adaptivecards.io/schemas/adaptive-card.json\",\n \"version\": \"1.6\",\n \"body\": [\n {\n \"$data\": \"${take(items,5)}\",\n \"type\": \"Container\",\n \"items\": [\n {\n \"type\": \"TextBlock\",\n \"text\": \"[${title}](${url})\",\n \"wrap\": true,\n \"weight\": \"Bolder\",\n \"spacing\": \"Padding\",\n \"height\": \"stretch\"\n }\n ],\n \"height\": \"stretch\"\n }\n ],\n \"backgroundImage\": {\n \"url\": \"https://www.aaron-gustafson.com/i/background-logo.png\",\n \"verticalAlignment\": \"Bottom\",\n \"horizontalAlignment\": \"Center\"\n }\n}What this structure does is:
\nitems from the data being fed into the template (more on that in a moment);item and\ntitle and url keys from the item object)The way Adaptive Cards work is that they flow JSON data into a template and render that. The variable names in the template map directly to the incoming data structure, so are totally up to you to define. As these particular widgets are feed-driven and this site already supports JSONFeed, I set up the widgets to flow the appropriate feed into each and used the keys that were already there. For reference, here’s a sample JSONFeed item:
{\n \"id\": \"…\",\n \"title\": \"…\",\n \"summary\": \"…\",\n \"content_html\": \"…\",\n \"url\": \"…\",\n \"tags\": [],\n \"date_published\": \"…\"\n}If you want to tinker with Adaptive Cards and make your own, you can do so with their Designer tool.
\nWith a basic template created, the next step was to set up the two widgets in my Manifest. As they both function largely the same, I’ll just focus on the definition for one of them.
\nFirst off, defining widgets in the Manifest is done via the widgets member, which is an array (much like icons and shortcuts). Each widget is represented as an object in that array. Here is the definition for the “latest posts” widget:
{\n \"name\": \"Latest Posts\",\n \"short_name\": \"Posts\",\n \"tag\": \"feed-posts\",\n \"description\": \"The latest posts from Aaron Gustafson’s blog\",\n \"template\": \"feed\",\n \"ms_ac_template\": \"/w/feed.ac.json\",\n \"data\": \"/feeds/latest-posts.json\",\n \"type\": \"application/json\",\n \"auth\": false,\n \"update\": 21600,\n \"icons\": [\n {\n \"src\": \"/i/icons/webicon-rss.png\",\n \"type\": \"image/png\",\n \"sizes\": \"120x120\"\n }\n ],\n \"screenshots\": [\n {\n \"src\": \"/i/screenshots/widget-posts.png\",\n \"sizes\": \"387x387\",\n \"label\": \"The latest posts widget\"\n }\n ]\n}Breaking this down:
\nname and short_name act much like these keys in the root of the Manifest as well as in shortcuts: The name value is used as the name for the widget unless there’s not enough room, in which case short_name is used.tag as analogous to class in HTML sense. It’s a way of labeling a widget so you can easily reference it later. Each widget instance will have a unique id created by the widget service, but that instance (or all instances, if the widget supports multiple instances) can be accessed via the tag. But more on that later.description key is used for marketing the widget within a host OS or digital storefront. It should accurately (and briefly) describe what the widget does.template key is not currently used in the Windows 11 implementation but refers to the expected standard library widget template provided by the system. As a template library is not currently available, the ms_ac_template value is used to provide a URL to get the custom Adaptive Card (hence “ac”) template. The “ms_” prefix is there because it’s expected that this would be a Microsoft-proprietary property. It follows the guidance for extending the Manifest.data and type keys define the path to the data that should be fed into the template for rendering by the widget host and the MIME of the data format it’s in. The Windows 11 implementation currently only accepts JSON data, but the design of widgets is set up to allow for this to eventually extend to other standardized formats like RSS, iCal, vCard, and such.update is an optional configuration member allowing you to set how often you’d like the widget to update, in seconds. Developers currently need to add the logic for implementing this into their Service Worker, but this setup allows the configuration to remain independent of the JavaScript code, making it easier to maintain.icons and screenshots allow us to define how the widget shows up in the widget host and how it is promoted for install.When someone installs my site as a PWA, the information about the available widgets gets ingested by the browser. The browser then determines, based on the provided values and its knowledge of the available widget service(s) on the device, which widgets should be offered. On Windows 11, this information is routed into the AppXManifest that governs how apps are represented in Windows. The Windows 11 widget service can then read in the details about the available widgets and offer them for users to install.
\n
As I mentioned earlier, all of the plumbing for widgets is done within a Service Worker and is modeled on the Notifications API. I’m not going to exhaustively detail how it all works, but I’ll give you enough detail to get you started.
\nFirst off, widgets are exposed via the self.widgets interface. Most importantly, this interface lets you access and update any instances of a widget connected to your PWA.
When a user chooses to install a widget, that emits a “widgetinstall” event in your Service Worker. You use that to kickoff the widget lifecycle by gathering the template and data needed to instantiate the widget:
\nself.addEventListener(\"widgetinstall\", (event) => {\n console.log(`Installing ${event.widget.tag}`);\n event.waitUntil(initializeWidget(event.widget));\n});The event argument comes in with details of the specific widget being instantiated (as event.widget). In the code above, you can see I’ve logged the widget’s tag value to the console. I pass the widget information over to my initializeWidget() function and it updates the widget with the latest data and, if necessary, sets up a Periodic Background Sync:
async function initializeWidget(widget) {\n await updateWidget(widget);\n await registerPeriodicSync(widget);\n return;\n}The code for my updateWidget() function is as follows:
async function updateWidget(widget) {\n const template = await (await fetch(widget.definition.msAcTemplate)).text();\n const data = await (await fetch(widget.definition.data)).text();\n\n try {\n await self.widgets.updateByTag(widget.definition.tag, { template, data });\n } catch (e) {\n console.log(`Couldn’t update the widget ${tag}`, e);\n }\n return;\n}This function does the following:
\nself.widgets.updateByTag() method to push the template and data to the widget service to update any widget instances connected to the widget’s tag.As I mentioned, I also have code in place to take advantage of Periodic Background Sync if/when it’s available and the browser allows my site to do it:
\nasync function registerPeriodicSync(widget) {\n let tag = widget.definition.tag;\n if (\"update\" in widget.definition) {\n registration.periodicSync.getTags().then((tags) => {\n // only one registration per tag\n if (!tags.includes(tag)) {\n periodicSync.register(tag, {\n minInterval: widget.definition.update,\n });\n }\n });\n }\n return;\n}This function also receives the widget details and:
\ndefinition (from the Manifest) includes an update member. If it has one, it…tag value and a minimum interval equal to the update requested.The update member, as you may recall, is the frequency (in seconds) you’d ideally like the widget to be updated. In reality, you’re at the mercy of the browser as to when (or even if) your sync will run, but that’s totally cool as there are other ways to update widgets as well.1
When a user uninstalls a widget, your Service Worker will receive a “widgetuninstall” event. Much like the “widgetinstall” event, the argument contains details about that widget which you can use to clean up after yourself:
\nself.addEventListener(\"widgetuninstall\", (event) => {\n console.log(`Uninstalling ${event.widget.tag}`);\n event.waitUntil(uninstallWidget(event.widget));\n});Your application may have different cleanup needs, but this is a great time to clean up any unneeded Periodic Sync registrations. Just be sure to check the length of the widget’s instances array (widget.instances) to make sure you’re dealing with the last instance of a given widget before you unregister the sync:
async function uninstallWidget(widget) {\n if (widget.instances.length === 1 && \"update\" in widget.definition) {\n await self.registration.periodicSync.unregister(widget.definition.tag);\n }\n return;\n}Widget platforms may periodically freeze your widget(s) to save resources. For example, they may do this when widgets are not visible. To keep your widgets up to date, they will periodically issue a “widgetresume” event. If you’ve modeled your approach on the one I’ve outlined above, you can route this event right through to your updateWidget() function:
self.addEventListener(\"widgetresume\", (event) => {\n console.log(`Resuming ${event.widget.tag}`);\n event.waitUntil(updateWidget(event.widget));\n});While I don’t want to get too into the weeds here, I do want to mention that widgets can have predefined user actions as well. These actions result in “widget click” events being sent back to the Service Worker so you can respond to them:
\nself.addEventListener(\"widgetclick\", (event) => {\n const widget = event.widget;\n const action = event.action;\n switch (action) {\n // Custom Actions\n case \"refresh\":\n event.waitUntil(updateWidget(widget));\n break;\n }\n});For a great example of how a widget can integrate actions, you should check out the demo PWAmp project. Their Service Worker widget code is worth a read.
\nWith all of these pieces in place, I was excited to see my site showing up in the Widget Dashboard in Windows 11.
\n![\"\"](\"https://www.aaron-gustafson.com/i/posts/2023-10-09/widgets-in-windows.jpg\")
You can view the full source code on GitHub:
\nI’m quite hopeful this will be the first of many places PWA-driven widgets will appear. If you’s like to see them supported elsewhere, be sure to tell your browser and OS vendor(s) of choice. The more they hear from their user base that this feature is needed, the more likely we are to see it get implemented in more places.
\nIn wiring this all up, I ran into a few current bugs I wanted to flag so you can avoid them:
\nicons member won’t accept SVG images. This should eventually be fixed, but it was keeping my widgets from appearing as installable.screenshots members can’t be incredibly large. I’m told you should provide square screenshots no larger than 500px ×500px.Have you checked out Server Events? ↩︎
\nI had the great pleasure of delivering a talk about Microsoft’s strategy towards Progressive Web Apps at Build. You can view the slides or watch the recording of this talk, but what follows is a distillation of my talk, taken from my notes and slides.
\nI’m here to talk to you about Progressive Web Apps, but before we really tuck into that, I wanna give a shout out to an app that’s really impressed me. This is Expense Manager by the folks at Vaadin:
\nI do a lot of traveling and it’s helpful when I can easily track my expenses. Their app is simple but refined in this regard. It’s snappy and provides a great overall UX; it’s also cross platform, which is nice since I often jump between different OSes across mobile and desktop.
\nThe experience on the desktop version of their app is obviously a little better because I’ve got more real estate for viewing my expenses, but the same attention to detail has clearly been paid to the experience in both form factors, which is nice to see.
\nOh, and a little secret here… it’s a web app. In fact it’s a Progressive Web App. You should really play around with it yourself and kick the tires a bit to see how it’s made.
\nNow that we’ve seen one in action, I want to start by clarifying what a Progressive Web App is, just so I’m sure we’re all on the same page before we go down this rabbit hole. As a point of clarification, you’ll hear me use the terms Progressive Web App and PWA interchangeably.
\nSo what is a Progressive Web App? Let’s ignore the first part of this term for a moment—progressive—I promise I’ll circle back to it shortly. Now the term “web app” may sound like something you can put your finger on, right? It’s software, on the Web, you use to complete a task. Like an expense manager, but it can be any website or property, really.
\nAnd so it is with Progressive Web Apps too.
\n![\"\"](\"https://www.aaron-gustafson.com/i/posts/2017-05-24/04.png\")
“Web apps” in this context can be any website type—a newspapers, games, books, shopping sites—it really doesn’t matter what the content or purpose of the website is, the “web app” moniker is applicable to all of them. The term could just have easily been progressive web site and it may be helpful to think of it as such. It doesn’t need to be a single page app. You don’t need to be running everything client side. There are no particular requirements for the type of PWA you are developing.
\nEssentially, a PWA is a website that is capable of being promoted to being an installed app. It gets many of the benefits of being an app (some of which I will cover shortly), but also has all of the benefits of being a website too. If you’ve looked at or developed a Hosted Web App(HWA), which Microsoft introduced with Windows 10, PWAs are very\nsimilar. In fact, if you’ve built an HWA, it shouldn’t be too difficult for you to convert it into a PWA and, in doing so, you’ll get a ton of extra goodies for free… but I’m getting ahead of myself.
\nHere’s a quick comparison of the Twitter app and Twitter Lite, as seen on an Android device:
\nYou’ll notice that from a quality, polish, and user experience perspective, they are nearly indistinguishable. And this is just the first iteration of Twitter Lite. It launched last month. The only real difference is that one was built using Web technologies and lives at a URL.
\nThough the “progressive web apps” moniker was coined by Frances Berriman in 2015 and has quickly become a buzzword in our industry, it’s important to recognize that this idea of the Web as app is not new.
\nBack in 2007, Adobe introduced Apollo, later renamed the Adobe Integrated Runtime (a.k.a. Adobe AIR). This technology enabled designers and developers to build apps in Flash or using Web technologies—HTML, CSS and JavaScript. It was pretty revolutionary for the time, supporting drag & drop, menu bar integration, file management, and more.
\nIn 2009, Palm debuted webOS with the Palm Pre. All software for webOS was built using web technologies. Sadly, as an operating system in the handset space, it failed to catch on, but LG has licensed webOS for use in smart TVs and is experimenting with it for IoT devices and smartwatches.
\nSince that time, more OSes have begun embracing Web technologies as a means of building applications. Windows 8 allowed Windows Store apps to be written in HTML, CSS, and JavaScript. And Firefox OS and Chromium/Chrome OS are fundamentally tied to to the Web stack.
\nCountless tools have followed Adobe’s lead as well, enabling designers and developers to use their Web skills to build applications for the vast majority of operating systems out there. React Native, Ionic, Electron, PhoneGap, Appcelerator… the list goes on and on. Obviously there’s something to the idea of building software using Web technologies. Progressive Web Apps are a brilliant way of accomplishing this in a standardized, consistent, way.
\nGoogle’s Alex Russell defined 10 characteristics he believes define this new breed of Web application:
\nLet’s tuck into the installable piece first since this is the bit that really sets a PWA apart from a standard website. Now many might view this as a continuation of the competition between Web and traditional app development. I don’t think of the two as being competitive, so much as being choices. We should choose our development approach based on the needs of our project, team, budget, etc. It’s good to have options and both approaches have their strengths.
\n\n\n\n
Web vs. Platform-specific
\nWeb *or* Platform-specific?
\nIt depends.
Often Web tech gets dismissed for not having the capabilities of apps. That’s changing rather rapidly. A visit to whatwebcando.today will give you a run-down of what your browser supports; you might be surprised with what you’ll learn about your browser’s capabilities. And if the end user experience is really good, does it matter what the underlying technology is?
\nWell, it might…
\nIn the Web vs. apps discussion, time to market is an aspect that isn’t often discussed. With a traditional web and app approach, each platform is typically built atop a core API. The apps are designed and developed independently, using different toolsets and languages and requiring different skills from the development team. And even in instances where they are all created using a single tool, the timeline needs to be padded in order to account for submission to each app store. That can cause delays in getting your product in front of users. It can also delay your delivery of critical updates.
\n![\"\"](\"https://www.aaron-gustafson.com/i/posts/2017-05-24/06.png\")
Contrast that with building your software as a web-based product with the characteristics of a PWA. Using this approach, you can build it once and deploy it everywhere… even to platforms that don’t support PWAs! And if you opt to submit your app to the various app stores, you could likely get away with a a one-time submission because updates will be seamless from there on out—it is the Web after all.
\n![\"\"](\"https://www.aaron-gustafson.com/i/posts/2017-05-24/07.png\")
Now that we’ve talked about install ability—the “app” bit, if you will—let’s circle back to that first principle of Progressive Web Apps: progressive. It must be important, after all it is literally the first word in this approach. “Progressive” in this context refers to progressive enhancement. In case you’re unfamiliar with the idea, I’ll provide a quick analogy; I’m a huge music and movie fan, so we’ll focus on sound for this analogy.
\nBack in the early days of recording, we only had a single speaker (or horn, back in the Victrola days) to relay the sound to our ears. Round about the 1930s, modern two-channel stereophonic sound was invented to solve a cinematic problem: in early “talkies” a single channel of sound was delivered through multiple speakers, which sometimes led to a weird situation where a performer would be on one side of the screen, but their voice would be coming from the other side (the speaker near you). Stereo sound allowed the actor’s voice to follow them in a much more natural way. Even with this advancement, though, stereo recordings could still be listened to on a single speaker by combining the channels.
\nOver time, stereophonic sound gave way to quadrophonic (or “surround”) sound and we kept adding more channels… and more channels, creating more and more immersive experiences. But even though a recording might sound best in 16.2 or 22.21 channels of sound, movies, television, and music mastered for complete immersion can still be appreciated on a single, mono bluetooth speaker or on your mobile device (which is basically in mono when you’re viewing it in landscape mode). That is progressive enhancement.
\nProgressive enhancement is concerned with honoring the core purpose of an experience—in software’s case the core purpose of a project and the core tasks a user will want to accomplish using it. The core experience should always be available, regardless of device or browser being used or the capabilities or limitations of that device… or of the user. It doesn’t mean you can’t create a better experience for folks who can benefit from that, but you never do that to the exclusion of your users.
\nAnd yes, that means having an experience that works when JavaScript doesn’t. But that’s a whole other talk…
\nWith progressive enhancement, we build the baseline experience and then enhance it as we are able to. In practical terms, progressive enhancement ensures people can use your product, regardless of
\n![\"\"](\"https://www.aaron-gustafson.com/i/posts/2017-05-24/09.png\")
Let me walk you through a very basic example of progressive enhancement in practice as I think it will illustrate this point.
\nHere we have an email input field:
\n<input type=\"email\" name=\"email\" id=\"email\" required aria-required=\"true\" />The “email” field type was introduced in HTML5, so older browsers may not support it. Those that don’t will provide the default input type—a text field—to users. That’s totally fine—it’s all we had for more than a dozen years before HTML5 came along! But even if a user’s device does support email fields, it’s implementation may vary. Based on how a browser answers the following questions, users will end up with different experiences:
Moving on to the required attribute—another HTML5 introduction—some browsers will use it for input validation, some won’t know what to do with it. Those that implement this feature may block form submission if the field is left empty, but some won’t do anything with that info even if they know the field is empty!
Finally, there’s the aria-required attribute. This is a part of the ARIA (Accessible Rich Internet Applications) spec and is used to inform assistive technology if the field is required. But it’s possible the browser may not support the attribute or that the assistive tech being used may not do anything with that information even if the browser does expose it.
In terms of experience of this field, it improves incrementally along a path like this:
\n![\"\"](\"https://www.aaron-gustafson.com/i/posts/2017-05-24/10.png\")
Now think about that for a second—this incredible variety of experience is created by one HTML element when you add three specific attributes to it. And the experienced is enhanced—progressively—as the browser’s and operating system’s capabilities increase. Amazing!
\nAs I mentioned, progressive enhancement ensures people can use your product, no matter what. You could just as easily swap in “PWA” for “progressive enhancement” in that statement. After all, PWAs give you network awareness and independence, they can be used to lower the overall cost of using your product for your for users through smart caching, they enable access to platform APIs on certain platforms, and they provide more ways for your product to get discovered (e.g., search, store, links). Those are some impressive progressive enhancement bona fides.
\nAdditionally, the two technical lynchpins of PWA—Web App Manifest and Service Worker—are ignored if they aren’t supported. Products you build using them will continue to work really well, even in their absence. They are, by definition, progressive enhancements too.
\nNow I’ve mentioned Service Worker a few times, so it probably makes sense to do a little sidebar here to explain what Service Workers are. A Service Worker is a proxy spawned by JavaScript that can handle a variety of tasks involving the network. They can
\nNote: At this point in the presentation, I passed the mic to my colleague Jeff Burtoft to give a quick demo of Service Worker in practice.
\nNow that we’ve covered the groundwork of PWAs, I want to discuss where they fit in the Windows ecosystem. As I mentioned earlier, Windows has a history of supporting Web tech, but it even predates Windows 8. Back in Windows 7 we began supporting pinned sites. They enabled developers to customize a sticky tab in the taskbar that provided quick access to key tasks, a customizable browser UI, and more. Then, in Windows 8, packaged apps could be completely written in HTML, CSS, and JavaScript. In Windows 10 we introduced Hosted Web Apps, which enabled your wholly web-based product to be distributed and installed via the Windows Store. And now we are in the process of taking our support of the Web to the next level with Progressive Web Apps.
\nIn terms of the work necessary to make this happen, the Edge team has already landed Fetch API support. Fetch is the powerful successor to XMLHttpRequest that is a critical underpinning of Service Worker. As I mentioned, Hosted Web Apps arrived with Windows 10 and they provide a secure, discrete container for Web apps within Windows that will also be used with PWAs. Additionally, WinRT provides programmatic access to OS internals like the calendar, contacts, Cortana, and more via JavaScript.
\nOur engineering effort around Service Worker kicked off about a year ago and we’re making great progress in bringing PWAs to Edge and Windows. Support for PWAs will become available to Windows Insiders early this summer. Initially, Service Worker, the Cache API, and the Push API will be behind a feature flag.
\nOnce PWAs are fully supported, they will use the same container technology currently in use for Hosted Web Apps. As I mentioned, it’s an established container with excellent performance and a ton of benefits:
\nOn Windows, Progressive Web Apps are essentially Hosted Web Apps, evolved. In fact, you could build your PWA and ship it as an HWA today and when the remainder of the PWA stack lands, it will automatically transform into a full-fledged PWA (another benefit of the Web for distribution).
\nNow that we’ve seen how PWAs operate within Windows, I want to take a few minutes to talk about how users will find your PWAs. As part of our initial move to support Progressive Web Apps, we will be enabling users to discover and install them from within the store and in Bing search results.
\n![\"\"](\"https://www.aaron-gustafson.com/i/posts/2017-05-24/11.jpg\")
Now you may be wondering, with all of the awesomeness the Web has to offer, why does it make sense for PWAs to reside in app stores? There are numerous reasons:
\nPWAs can get into the Windows Store in one of two ways. The first is through active submission. Using a tool like the open source utility PWA Builder, you can generate the necessary app wrappers used by the various app stores and manually submit your PWA.
\nNote: I invited Jeff back up on stage to walk through building a PWA and submitting it to the Windows Store using PWA Builder.
\nObviously we want Windows users to have access to as many quality PWAs as possible, but we recognize that not all development teams have the time to submit and maintain their apps in the Store. To address this, we’ve developed an approach to enable their apps to be easily discovered in the Store too. For lack of a better term, we’re currently calling this process “passive ingestion”.
\n![\"\"](\"https://www.aaron-gustafson.com/i/posts/2017-05-24/12.png\")
We are already using the Bing Crawler to identify PWAs on the Web for our PWA research. The Web App Manifest is a proactive signal from developers that a given website should be considered an app; we’re listening to that signal and evaluating those sites as candidates for the Store. Once we identify quality PWAs, we’ll automatically generate the APPX wrapper format used by the Windows Store and assemble a Store entry based on metadata about the app provided in the Web App Manifest.
\nWe completely understand that some of you may not want your products automatically added to the Store and we respect that.\nBy adding these 2 lines to your site’s robots.txt file, the Bing Crawler will ignore your Web App Manifest, opting your site out of this process:
User-agent: bingbot\nDisallow: /manifest.jsonWe are working on a set of criteria that will help us separate quality PWAs from sites that simply appear PWA-like. It’s still early days, but our consideration of what constitutes a “quality” PWA hinges on the following:
\nOnce in the Store, we’ll notify developers of their draft Store entry and they will be able to claim their apps to take complete control of their Store presence. Regardless, whether they got their by passive ingestion or my manual submission, the Web App Manifest will provide the basic set of information used for the app in the Store: name, description, icons, and screenshots. We’re also actively working with others in the W3C to introduce support for app categories and IARC ratings.
\nPWAs will appear alongside other apps in the Store, with no differentiation. From a users’ perspective, a PWA will just be another app. They will install just like any other app. They will have settings just like any other app. They will uninstall just like any other app. They will also be shareable via URL or the Store. PWAs will be first-class apps on Windows.
\nPhew… that was a lot to take in. At this point, you might have some questions. Here are a few I imagine you’re wrestling with.
\nShould I forget everything I know and start building a Progressive Web App?
\nNo. Progressive Web Apps are just one more way you can build a high-quality app experience.
\nWill Microsoft drop support for my favorite programming language in favor of Progressive Web Apps?
\nNo. We are committed to supporting a breadth of language options when it comes to developing apps.
\nAre Progressive Web Apps the right choice for my project?
\nMaybe. When evaluating app development in relation to Progressive Web Apps, here are some of the questions I recommend asking…
\nIn other words, the choice between PWA and a platform-specific app should be evaluated on a case-by-case basis. For example…
\nShould I consider Progressive Web Apps as a solid option when developing software for Windows?
\nDefinitely.
\nYou probably have more questions. I’ll do my best to answer them in the comments.
\nSlides from this talk are available on Slideshare.
\nA video recording of this presentation (including Jeff’s demos) is available on Channel 9.
\nNote: I no longer use “native” in the context of apps and platforms, but it remains in quoted material.
\nCrazy as it sounds, 22.2 is actually the standard used by Ultra-High Definition (UHD) television. ↩︎
\nWhether at home or at work, the web plays an increasingly critical role in our daily lives. As we have become more dependent on accessing the tools it powers, we’ve also struggled to overcome some of its limitations—network connectivity, for instance.
\nAt Microsoft, we’ve long been interested in the power of the web for software development and we are even more excited for the future possibilities offered by progressive web apps (PWAs). In this session, I discuss what PWAs are, how they can be integrated into the development process of modern websites, the advantages and disadvantages of PWAs vs. native development, and what opportunities they present when installed alongside native apps in Windows.
\n","social_text":"In this session, I discuss what PWAs are, how they can be integrated into the development process of modern websites, the advantages and disadvantages of PWAs vs. native development, and what opportunities they present when installed alongside native apps in Windows.","url":"https://www.aaron-gustafson.com/speaking-engagements/progressive-web-apps-and-the-windows-ecosystem/","tags":["progressive web apps","progressive enhancement","Windows","Microsoft"],"image":"https://www.aaron-gustafson.com/undefined","date_published":"2017-05-10T13:00:00Z"},{"id":"https://www.aaron-gustafson.com/notebook/mac-like-special-characters-in-windows/","title":"✍🏻 Mac-like Special Characters in Windows","summary":"I love the way OS X/macOS handles special characters and was looking to implement something similar on Windows. Here’s how I did it.","content_html":"I am a bit of a geek for proper punctuation: Em dashes… en dashes… curly quotes… ellipses… I love them all! Prior to 2007, I was a long-time Windows user and was a master of the Alt + numeric code system of entering special characters on that operating system.1 For nearly a decade, however, I’ve been writing and developing on a Mac and I absolutely love how much easier it is to use special characters. When I started setting up my new Surface Book, I began searching for a way to bring Mac-like special character entry to Windows 10.
\nDisclaimer: I take absolutely no credit for the code you see below. I will give full credit to the sources as I discuss each. I just wanted to bring it all into one place so it’ll save you a few hours of research to get everything working.
\nDavid Nagel’s solid article on mapping keystrokes in Windows, I introduced me to AutoHotKey. It’s an incredibly powerful program that’s like the lovechild of TextExpander and Quicksilver.
\nIn his article, David walks through the process of getting set up with AutoHotKey:
\n.ahk file (New > AutoHotKey Script in Windows Explorer) and name it whatever you like.2AutoHotKey is completely scriptable and adding shortcuts is relatively straightforward. There are a few reserved characters, but once you understand what they are it’s pretty easy to get going very quickly. Here’s Dave’s intro example:
\n!-::–\n!+-::—In AutoHotKey scripting, “!” stands in for Alt and “+” stands in for Shift. So, to translate:
\nWith these two examples, I was able to jump right in and map many of the most common shortcuts I use while writing. Before I got too far, however, I realized I really needed accents, umlauts, and the like. I searched some more and eventually discovered a post in the AutoHotKey forum archive by “Veil” from way back in 2008.
\nVeil broke his solution into two parts, but I’ve combined them here to make it easier for your to copy into your AutoHotKey script file. This code has provided everything I’ve needed so far, so Veil—wherever you are—thank you!
\n#UseHook\n!VKC0SC029::Return \t; grave -> the grave ` accent gave some probs, used the virtualkey + scancode instead\n!e::Return \t; acute\n!i::Return ; circumflex\n!t::Return \t; tilde\n!u::Return ; umlaut\n\n; 1 2 3 4 5 6 7 8 9 1\n; 0\n; r g G a A c C t T u U\n*a::diacritic(\"a\",\"à,À,á,Á,â,Â,ã,Ã,ä,Ä\")\n*e::diacritic(\"e\",\"è,È,é,É,ê,Ê,e,E,ë,Ë\")\n*i::diacritic(\"i\",\"ì,Ì,í,Í,î,Î,i,I,ï,Ï\")\n*o::diacritic(\"o\",\"ò,Ò,ó,Ó,ô,Ô,õ,Õ,ö,Ö\")\n*u::diacritic(\"u\",\"ù,Ù,ú,Ú,û,Û,u,U,ü,Ü\")\n*n::diacritic(\"n\",\"n,N,n,N,n,N,ñ,Ñ,n,N\")\n*y::diacritic(\"y\",\"y,Y,y,Y,y,Y,y,Y,ÿ,Ÿ\")\n\ndiacritic(regular,accentedCharacters) {\n StringSplit, char, accentedCharacters, `,\n graveOption := char1\n graveShiftOption := char2\n acuteOption := char3\n acuteShiftOption := char4\n circumflexOption := char5\n circumflexShiftOption := char6\n tildeOption := char7\n tildeShiftOption := char8\n umlautOption := char9\n umlautShiftOption := char10\n\n if (A_PriorHotKey = \"!VKC0SC029\" && A_TimeSincePriorHotkey < 2000) {\n if (GetKeyState(\"Shift\")) {\n SendInput % graveShiftOption\n } else {\n SendInput % graveOption\n }\n } else if (A_PriorHotKey = \"!e\" && A_TimeSincePriorHotkey < 2000) {\n if (GetKeyState(\"Shift\")) {\n SendInput % acuteShiftOption\n } else {\n SendInput % acuteOption\n }\n } else if (A_PriorHotKey = \"!i\" && A_TimeSincePriorHotkey < 2000) {\n if (GetKeyState(\"Shift\")) {\n SendInput % circumflexShiftOption\n } else {\n SendInput % circumflexOption\n }\n } else if (A_PriorHotKey = \"!t\" && A_TimeSincePriorHotkey < 2000) {\n if (GetKeyState(\"Shift\")) {\n SendInput % tildeShiftOption\n } else {\n SendInput % tildeOption\n }\n } else if (A_PriorHotKey = \"!u\" && A_TimeSincePriorHotkey < 2000) {\n if (GetKeyState(\"Shift\")) {\n SendInput % umlautShiftOption\n } else {\n SendInput % umlautOption\n }\n } else {\n if (GetKeyState(\"Shift\") or GetKeyState(\"Capslock\",\"T\")) {\n SendInput % \"+\" regular\n } else {\n SendInput % regular\n }\n }\n}\n\n;\n; Alt + Shift + key\n;\n*!1::altShift(\"¡\",\"/\")\n*!2::altShift(\"€\",\"™\")\n*!3::altShift(\"£\",\"‹\")\n*!4::altShift(\"¢\",\"›\")\n*!5::altShift(\"8\",\"fi\")\n*!6::altShift(\"§\",\"fl\")\n*!7::altShift(\"¶\",\"‡\")\n*!8::altShift(\"•\",\"°\")\n*!9::altShift(\"ª\",\"·\")\n*!0::altShift(\"º\",\"‚\")\n\n*!a::altShift(\"å\",\"Å\")\n*!b::altShift(\"integral\",\"i\")\n*!c::altShift(\"ç\",\"Ç\")\n*!d::altShift(\"partial difference\",\"Î\")\n*!e::altShift(\"´\",\"‰\")\n*!f::altShift(\"ƒ\",\"Ï\")\n*!g::altShift(\"©\",\"Ì\")\n*!h::altShift(\"overdot\",\"Ó\")\n*!i::altShift(\"^\",\"È\")\n*!j::altShift(\"delta\",\"Ô\")\n*!k::altShift(\"°\",\"Apple\")\n*!l::altShift(\"¬\",\"Ò\")\n*!m::altShift(\"µ\",\"˜\")\n*!n::altShift(\"~\",\"ˆ\")\n*!o::altShift(\"ø\",\"Ø\")\n*!p::altShift(\"pi\",\"Pi\")\n*!q::altShift(\"œ\",\"Œ\")\n*!r::altShift(\"®\",\"Â\")\n*!s::altShift(\"ß\",\"Í\")\n;*!t::altShift(\"†\",\"Ê\")\n*!u::altShift(\"¨\",\"Ë\")\n*!v::altShift(\"v\",\"lozenge\")\n*!w::altShift(\"epsilon\",\"„\")\n*!x::altShift(\"approximately equal\",\"Ù\")\n*!y::altShift(\"¥\",\"Á\")\n*!z::altShift(\"Omega\",\"Û\")\n\n*!-::altShift(\"–\",\"—\")\n*!=::altShift(\"!=\",\"±\")\n*![::altShift(\"“\",\"”\")\n*!]::altShift(\"‘\",\"’\")\n*!`;::altShift(\"…\",\"Ú\")\n*!'::altShift(\"æ\",\"Æ\")\n*!\\::altShift(\"«\",\"»\")\n*!,::altShift(\"<=\",\"¯\")\n*!.::altShift(\">=\",\"breve\")\n*!/::altShift(\"÷\",\"¿\")\n\naltShift(accented,accentedShift) {\n if (!GetKeyState(\"Shift\")) {\n SendInput % accented\n } else {\n SendInput % accentedShift\n }\n}\n\n; Fix for some CTRL + stuff that may not work\n; TODO - Add more as we find them\n^a::Send ^{end}^+{home}\n^o::WinMenuSelectItem, A, , File, OpenThe last thing you’ll want to do is add your .ahk file to Windows’ startup items. Dave covered that in his piece as well:
shell:startup (⊞ Win + R opens the Run dialog or you can type ”Run“ in the Cortana Search Box)Once you’ve followed those steps, you’re done. You can update your .ahk scripts needed and just double click it to replace the instance that’s currently running.
If, like me (and Dave and Jonathan and Dan), you’re using Windows after a long time in Mac land and you’re a typography nerd, hopefully you’ll find this helpful. And if you come up with any improvements to the character mapping, please share!
\nI actually memorized a ton of the codes, much to my amazement. I still remember a few, but I am thankful to have reclaimed a bit of that memory space over the last few years. ↩︎
\nIf you shun the mouse, you can create a text file in your favorite editor and name it with the .ahk extension, but you might run into character encoding issues. I created mine in VS Code as UTF-8, but had to open the file in Notepad and re-save it again to get it to actually work. I never figured out the exact issue, but I thought I’d give you a heads-up. ↩︎
Today is a momentous day.
\nAfter spending years of griping about IE6’s staying power and lamenting Microsoft’s earlier decision to advocate against upgrading to IE7 (a decision they didn’t stick with, thankfully), Microsoft has turned a new leaf today, announcing that they will be pushing updates to IE to anyone who takes part in their Windows Update service.
\nWhat does this mean? Well, it means that grandma will be upgraded to IE8 if she’s still on Windows XP or IE9 if she’s on Vista or Windows 7.
\nCorporations (and individuals) still have the ability to opt-out of these updates, but this move should put an end to upgrades that haven’t happened purely because users didn’t know how to upgrade to a new version of IE. As Microsoft’s own Peter Laudati so eloquently put it, “Upgrade Your Parents Browser Weekend” is now officially obsolete.
\n","url":"https://www.aaron-gustafson.com/notebook/an-end-to-aging-ie-installs/","tags":["browsers","Windows"],"date_published":"2011-12-15T19:34:06Z"}]}