![\"\"](\"https://www.aaron-gustafson.com/i/posts/2023-10-09/widgets-promotion.gif\")
I just hit “publish” on Accessibility Assistant for Figma v52 and I wanted to share some details on why this is a monumental release for us.
\nWe’re in the process of a major overhaul to this plugin. There was a lot of infrastructural work to do to modernize the plugin and set the stage for a host of new features to make designers more productive when it comes to making their designs more accessible. This release incorporates a lot of that foundational work, notably:
\nWe also fixed bugs related to duplicating layers. You can now copy layers and the annotations will go along for the ride, becoming a new Annotation Set. Similarly, you can now duplicate pages and the annotations — which are page-bound — will be re-generated. It’s worth noting that this may take some time on particularly large pages.
\nThis release has been a long time coming, but I’m incredibly proud of the team that’s been working so diligently on this, particularly Ashish Singh from HCL and Michael Fairchild, Scott O’Hara, and Ben Truelove from Microsoft. Their attention to detail and encyclopedic knowledge of accessibility has been instrumental in getting this project to the place that it is.
\nAnd there’s more to come!
\n","social_text":"I just hit “publish” on Accessibility Assistant for Figma v52 and I wanted to share some details on why this is a monumental release for us.","url":"https://www.aaron-gustafson.com/notebook/accessibility-assistant-for-figma-v52/","tags":["accessibility","design","inclusive design","Microsoft","user experience","WAI-ARIA"],"date_published":"2026-02-20T23:27:28Z"},{"id":"https://www.aaron-gustafson.com/notebook/links/accessibility-training-at-microsoft/","title":"🔗 Accessibility Training at Microsoft","content_html":"At Microsoft, we’ve invested a lot into accessibility upskilling across the company. And now we’ve made our Accessibility Fundamentals learning path freely available to the world to take, either on MS Learn or within another learning environment via its SCORM (Sharable Content Object Reference Model) course package.
\n","social_text":"Microsoft’s #Accessibility Fundamentals learning path is now free for everyone","url":"https://www.aaron-gustafson.com/notebook/links/accessibility-training-at-microsoft/","external_url":"https://blogs.microsoft.com/accessibility/accessibility-training-at-microsoft/","tags":["accessibility","Microsoft"],"date_published":"2024-04-30T20:24:04Z"},{"id":"https://www.aaron-gustafson.com/notebook/widgets/","title":"✍🏻 Widgets!","summary":"I finally had a chance to put the work I did on a widgets proposal for PWAs into practice on my own site. It’s pretty exciting!","content_html":"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 spent some time talking to Kathryn of Assembling Inclusion about the Microsoft AI for Accessibility grant program, the different projects that have been funded, and the future direction of the program.
\n","url":"https://anchor.fm/assemblinginclusion/episodes/025-Microsoft-AI-for-Accessibility-e1suib4","tags":["accessibility","Microsoft","inclusive design","AI/ML","inclusion"],"date_published":"2023-01-01T00:00:00Z"},{"id":"https://www.aaron-gustafson.com/publications/articles/welcoming-progressive-web-apps-to-microsoft-edge-and-windows-10/","title":"đź“„ Welcoming Progressive Web Apps to Microsoft Edge and Windows 10","content_html":"Some of my Microsoft colleagues and I did a run-down of how we are supporting Progressive Web Apps in Windows.
\n","url":"https://blogs.windows.com/msedgedev/2018/02/06/welcoming-progressive-web-apps-edge-windows-10/","tags":["progressive web apps","Microsoft","browsers"],"date_published":"2018-02-06T00:00:00Z"},{"id":"https://www.aaron-gustafson.com/notebook/progressive-web-apps-and-the-windows-ecosystem/","title":"✍🏻 Progressive Web Apps and the Windows Ecosystem","summary":"I had the great pleasure of delivering this talk about Microsoft’s strategy towards Progressive Web Apps at the Build conference.","content_html":"I 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/what-would-you-do-with-10kb/","title":"✍🏻 What Would You Do With 10kB?","summary":"I’m thrilled to announce that the 10k Apart contest is back and brings with it a handful of new challenges.","content_html":"Sixteen years ago, Stewart Butterfield conceived of a contest that would test the mettle of any web designer: The 5k. The idea was that entrants would build an entire site in 5kB of code or less. Its aim was to force us to get creative by putting a bounding box on what we could do:
\n\n\nBetween servers and bandwidth, clients and users, HTML and the DOM, browsers and platforms, our conscience and our ego, we’re left in a very small space to find highly optimal solutions. Since the space we have to explore is so small, we have to look harder, get more creative; and that’s what makes it all interesting.
\n
The 5k contest ran from 2000 until 2002. In 2010, An Event Apart and Microsoft revived the idea with an updated limit and a new name: 10k Apart. Staying true to its roots, this new incarnation, which ran for two years, continued to push designers and developers to get creative within a pretty extreme (though slightly expanded) limit while incorporating new goodies like HTML5 and responsive design.
\nI’m thrilled to announce that the 10k Apart contest is back and brings with it a handful of new challenges:
\nAs with previous editions, your entry should use web standards and work in all modern browsers. You can use HTML, CSS, and JavaScript features and APIs that don’t have across-the-board support as long as you do so in keeping with the progressive enhancement philosophy. In other words, your entry can’t depend on that technology or feature in order to be usable.
\nAll of this may sound like a tall order, but it’s entirely possible. In fact, the site we built for the contest also abides by these rules. My colleagues and I will touch on some of the techniques we used (and concessions we made) in building the site in future posts.
\nIf you’ve read this far, you might be wondering What’s in it for me? Well, bragging rights, of course, but we’ve got some awesome prizes too! We’re giving away $10,000 to the top three entries, plus tickets to An Event Apart, complete collections of A Book Apart titles, and copies of my book too. Complete details of the prizes are over on the contest site.
\nWe’ve lined up an amazing group to judge the entires this year too: Rachel Andrew, Lara Hogan, Mat Marquis, Heydon Pickering, Jen Simmons, and Sara Soueidan will all be putting your entry through its paces and peering under the hood at your code. There’s also a People’s Choice award which will be based on votes you cast. Voting will open October 1st and run through October 14th.
\nThe contest opened Monday and we will accept entries until 5pm Pacific Time on September 30th. Everything you should need to know about the contest, eligibility, etc. is up on the 10k Apart site, but if you have additional questions, you can always reach out.
\nI can’t wait to see what you come up with! Happy coding!
\n","url":"https://www.aaron-gustafson.com/notebook/what-would-you-do-with-10kb/","tags":["web design","accessibility","Microsoft","performance","progressive enhancement"],"date_published":"2016-08-17T18:48:27Z"},{"id":"https://www.aaron-gustafson.com/notebook/collected-reactions-to-build/","title":"✍🏻 Collected Reactions to //build/","summary":"I may work for Microsoft, but I don’t know everything that’s going on across the company. It’s big and I don’t have that kind of time.","content_html":"I may work for Microsoft, but I don’t know everything that’s going on across the company. It’s big and I don’t have that kind of time.
\nAnyway Build, the Microsoft conference, is going on right now and as you’d expect, there are a ton of new announcements. I’ve watched a few of the talks virtualy and am particularly excited about the new browser (whose name has finally been revealed): Microsoft Edge. I’m also very interested to see where things go with HoloLens.
\nOne graphic that cropped up that blew my mind was this one talking about where Windows 10 is going:
\n![\"The](\"https://news.microsoft.com/build2015/assets/photos/build720150428_web.png\")
You’ve often heard me discuss experience as a continuum. Microsoft is living it.
\nIf you didn’t watch the streaming talks and want to hear about what was announced from some independent sources, I’d recommend reading these:
\nI will continue adding to this list as new & interesting pieces come out.
\n","url":"https://www.aaron-gustafson.com/notebook/collected-reactions-to-build/","tags":["Microsoft","web design","Android"],"date_published":"2015-04-30T14:53:11Z"},{"id":"https://www.aaron-gustafson.com/notebook/talking-with-microsoft-about-ienext/","title":"✍🏻 Talking with Microsoft about IE.next","summary":"You may recall that the DOM Scripting and Microsoft task forces, in collaboration with JS Ninjas, had been compiling a list of issues, needs, and wants for IE .next over the last few months (a list many of you contributed to as well…","content_html":"You may recall that the DOM Scripting and Microsoft task forces, in collaboration with JS Ninjas, had been compiling a list of issues, needs, and wants for IE.next over the last few months (a list many of you contributed to as well, via your feedback). The list was to focus on what we wanted to see happen in terms of JavaScript support (as IE7 didn’t get much of an update in that area), but when it came down to it, there were other areas we really felt needed some love.
\nLast week, our groups voted for what we each saw as priorities and those votes were tallied to create a final list for me to present in Redmond. Though there is obviously a great deal more we want to see in IE.next, we felt several things were critical and wanted to focus on those as a starting point.
\nTied for first place, in order of priority, were some sort of fast, arbitrary node-matching API and better error reporting. In the realm of DOM Scripting, node-matching is key (just look at the number of scripts out there performing node matching based on CSS selectors, etc.), so being able to tap into a native XPath implementation (which we generally favored over the Selectors API) would greatly improve the speed of script execution. As for the error reporting, perhaps Justin Palmer (of JS Ninjas) said it best:
\n\n\nWe could possibly find ways to fix all the other problems if we could tell what the hell was breaking and why. Without better error reporting, the remaining stuff on that list is just giving us a bigger gun to shoot ourselves in the foot with.
\n
Next up in our list was a desire for mutable DOM prototypes. This would address the issues that arise from IE’s implementation of DOM objects in JavaScript, where elements of the core DOM are not derived from the standard Object prototype. While not technically a standards-support issue, this request does not conflict with standards and it does provide JavaScript developers with the ability to address some of the issues the IE team may not be able to address themselves in the next release. As Andrew Dupont (another Ninja) remarked, I think it’s reasonable to ask that a DOM implementation in JavaScript behave like it’s part of JavaScript.
Next up was a biggie: bring IE’s event system in line with the W3C event model. This has been an issue for a lot of developers and the code to equalize the two event systems makes up a significant chunk of all of the major JS libraries. Getting IE to implement the W3C event system would be a real boon for standards support and would drop the size of many libraries considerably.
\nFinally, the last of our top 5 was not a JS issue, but rather a CSS one: implement generated content. I don’t know that I really need to get into the reasons why this would be really nice to have.
\nTwo “honorable mentions” were included in the list as well: fixing the issues with getAttribute() and setAttribute() and starting to implement some of the features of JS 1.7 (such as block-scope variables using let, etc.).
Not willing to let the IE team off that easy, the document presented also highlighted several other issues which really need addressing including (among others)
\nz-index);button element, labels, and the disabled attribute);object;q element (which should be a breeze once generated content is enabled); andalt being used for a tooltip, cite not being supported on q and blockquote, and summary not being supported on tables).In Redmond, I met with Pete LePage, a Product Manager at Microsoft Web Platform and Tools, and several other key members on the IE team. We discussed the list and its implications in great detail for nearly two hours. While I am not at liberty to discuss all of the details of the meeting, I can say for certain that the group I met with was keenly aware of the issues we brought up and are eager to address them. One team member even said that he could have easily guessed our top 5.
\nThe one concern they have—especially with regard to the event model and getAttribute()/setAttribute()—is that any adjustments they make to bring IE in line with the standards not “break the web” for the large number of sites using the proprietary IE event model, etc. We discussed this particular topic at length as it is a valid concern and I’m happy to say that I think we’re close to a solution on that front.
I came away from this meeting with a real sense of hope about where IE is going and am really encouraged by their willingness to engage the standards community (and web developers as a whole) in dialog like this. We did not resolve every issue in our two-hour talk, but I was assured that this was only the first of many steps toward improving IE.next. The IE team wants to continue this conversation and to continue to elicit feedback from the web community as a whole as things progress.
\n","url":"https://www.aaron-gustafson.com/notebook/talking-with-microsoft-about-ienext/","tags":["Microsoft","web standards","browsers"],"date_published":"2007-02-04T18:49:50Z"}]}