 My 10-year-old niece was recently given a class assignment to create a poster. The topic was to raise awareness for endangered species. She and her friends formed a group quickly adjusting to our collective virtual reality. They co-created this poster, edited, commented, shared links with each other. They used online web-based design tools to do this on their Chromebooks and they created a piece of art as a nod to the dodo. Sadly, we can't bring the dodo back. But I was really excited and surprised to see how, in today's world, that just kind of worked. I promised myself that I will not use the phrase New Normal. So without using it, I'll make the point that the web superpowers on desktop are even more relevant today. The reach, freedom, easy link sharing, safety that users have always loved, amplified by new capabilities like windowing, system access, and web assembly are making it easier to bring creative and productive experiences to the desktop, to large screen devices, whether you're an aspiring student or a professional designer. And what's even more exciting is that these desktop experiences are coming to Chrome OS. Chrome OS has had a particularly exciting growth here. Unit sales have grown from 127% year over year, while the rest of the US notebook category has increased 40% year on year. It's quickly becoming the laptop OS of choice. It's affordable, it's capable, and it works just like the web. PWAs on Chromebooks, like Clipchamp, the video editing software that allows you to compress, record, edit your videos, has seen that since they shipped the PWA quite recently, they're already seeing that those users are retaining three times more than the average. Another vector design app, Gravit Designer, has taken advantages, advanced web capabilities like file system access, and they're experimenting with local font access within their PWA, making the web app almost indistinguishable from their native app. In fact, they plan to make the PWA the primary experience across all desktop OSes in the future. And it's not just the design and creativity space, but whether it's media, social, you name it, and those categories of web apps are available on Chromebooks for anyone to use. But there's one app in particular that I want to shine a bright spotlight on today, and that's Adobe Spark. Spark makes it easy and fun for anyone to turn their ideas into beautiful visual stories and social content that make an impact and it's been pushing the boundaries on Chromebooks. I'm really excited that we have BEM Jones Bay lead software developer at Adobe Spark to talk about it, the motivations, the learnings, and what future projects are in store for Spark. So without further ado, welcome BEM. Thank you, Marshall. I'm really happy to be here. BEM, I know the story really well, but I want us to start at the beginning. Tell us about Spark. How did it come about? Happily. So we started working on Spark about six years ago as a startup inside of Adobe. While we decided on native apps as the mobile solution, we saw the web as an ideal fit for the desktop experience. It took time to get product market fit, but we succeeded, got more resources, launched experiences on Android, and greatly increased the capabilities of the web app. We recently optimized the web app to be a PWA, installable on Chromebooks and in any modern desktop browser. We're all really excited about that recent PWA launch. I know you and I have talked about the importance of Chrome OS to Spark, especially in the classroom, so can you tell us a little bit more about that? Yeah, sure. One of our foundational goals is to empower the next generation of digital creativity. So education is an important market for us. We have 30 million teachers and students using Spark around the world, and Chromebooks are used widely in education. The best part about the web app and now the PWA is that it works everywhere on desktop, from teachers sharing URLs with students to the student easily accessing the link when they're at home. The frictionless and seamless experience is a big draw for us, especially in these times. We were also excited about increased distribution via the Play Store and the ability to have OEMs pre-install Spark on their Chromebooks. All of this gave us a strong business case to do the work needed to have a good Chromebook PWA experience. That's great. We've seen that sometimes finding the right use case in an audience market fit for PWAs can lead to business impact. It makes it so much easier to track how much your users love your service when you can track things like installs and engagement, but it isn't easy. So what were some of the challenges Spark faced while building this PWA? Yeah, you're right. It really wasn't entirely easy. So as far as challenges, I think it's best if we start at the beginning. So we use the core PWA checklist as a reference. You bring up a great point because the core PWA checklist is one that folks just shouldn't miss. There's a short link up there. Do go check it out. If you're just looking to build a PWA, I want to use one as a reference to optimize your current experience, but thanks for bringing that up, Ben. I think not a lot of people know we've updated it and it's important to use that as a starting point. Thanks for bringing that up. I definitely forget that sometimes not everyone is on the same page when we're talking about these things. So yeah, most of the requirements listed there really seem fairly straightforward to us, but a couple of them stood out as challenges. Offline support and performance. So for offline support, we thought that we had to make our entire app usable when the user is offline, which would be a major effort given that it was never designed with that in mind. After some research, we got more clarity. The goal of that requirement is to make it seem more like a native application. There are native applications that only work with an internet connection, but when you launch them offline, they will still launch and tell you what the problem is. While it's ideal to give users as much functionality as possible when offline, the minimum requirement is that the user doesn't see a dyno. Yeah, I know. As much as we love the dyno and other extinct species, you don't want to see that when you're trying to get work done. For sure. It really takes you out of the app experience. So we ended up designing a very nice message that's displayed to users when they launch Spark and are offline. It still probably won't make you completely happy, but you'll know that the app hasn't crashed and it gives you an idea of what you might do to fix the problem. In addition, it keeps you in our app experience by speaking with our voice. So to be clear, this is only the beginning. We definitely will be working to build an even better offline experience. And I really love this message because it tells your users that you care. It's in your own voice. And you make an important point that it doesn't have to be the full offline functionality to start with. You can take small steps to get there. I'm glad that you have that plan in mind. What about performance? I know that's a big one. Yeah, performance. Yeah, that's a lot of work. So, I mean, if we go back to the beginning, our Lighthouse performance score was pretty bad. And we knew we had to improve that to get a native feel. So we set a goal of getting a performance score of 80 on desktop, which is pretty ambitious. Once that goal was set, though, the biggest challenge was figuring out where to start and how to keep it sustainable. So the first step we took was to make sure we had good automated metrics. So when doing that, we looked at both field and lab metrics. So field metrics directly reflect the performance as experienced by real users. This allows you to know if the improvements you are making are actually leading to a better user experience. So our field measurement system uses a combination of New Relic and a custom performance monitoring system. Our custom system is built using performance observer and the user timing API and records data to Splunk. We then created dashboards in Splunk like the one you see here to monitor these metrics. So field metrics really giving you a flavor of the real user experience and you're able to see whether the work you're doing is actually making a difference. What about lab metrics? How do you track those? So yeah, lab metrics are the best way to test the performance of features during development. And they are invaluable for catching performance regressions before they happen. We primarily use Lighthouse for lab measurement. It does an excellent job at presenting performance metrics in an easy to understand and actionable format. We then have automated runs of Lighthouse that enforce a performance budget on our PRs and our CI environments. This makes it much harder for performance regressions to make it to production. With all of these metrics in our tool belt, we were able to make a lot of meaningful performance improvements and reach our performance goal. While, you know, this is of course a lab metric, we also saw some improvement in our field metrics as well. We love that score. Not just in line with what you had in mind, but you surpassed the goal of 80 you'd set out for Spark. So you have a robust performance measurement and tracking system in place. How are you going to keep up this momentum? That's the hard part. Yeah, definitely. You know, I think the next step for us is to integrate Core Web Vitals into our field measurement suite. If they had been around when we started our project, we definitely would have used them. We like the fact that like Lighthouse, Core Web Vitals give you a simple set of actionable metrics. And they're integrated everywhere now. The search console, page speed insights, and New Relic, all measure them out of the box. And we can always use the Web Vitals library to integrate into custom systems like our custom monitoring. The rest of the day is actually focused on performance sessions and Core Web Vitals in particular, so folks should definitely check them out. I can't emphasize enough how important it is to keep performance front and center as you're looking to optimize any Web experience. And I'm glad that Adobe is doing just that. There are many new advanced Web capabilities that allow you to build native-like Web experiences. What are some of those that you're looking into? So, yeah, we're definitely interested in those. I'd say probably the primary, first one I thought of is link capturing, because right now, if you install the Spark PWA on your Chromebook, you launch the application from your desktop, and that's great. I mean, it works wonderfully. However, if you're browsing the Web and you come across a link to Spark, that link won't launch the installed PWA. It will just open a browser tab. When we have link capturing, we'll make it so the link will open and then install PWA. I believe this is a game changer for the user experience. So, you know, yeah, another one, and then going on, another one that comes to mind is the file system access API. This will fix a big gap for content creation apps like Spark, allowing seamless access to a user's local content. I know that Spark isn't the only Adobe team that's excited about this API. Speaking of things that many teams at Adobe are excited about, the big one is WebAssembly. We have a lot of technology implemented in native languages like C++. WebAssembly will allow us to bring this technology to the web to enable even better creative possibilities. And I mentioned this at the beginning. Some of this work is actually just amplifying the existing benefits and advantages of being on the web. If you want to learn more about the new capabilities and how that fits in this world of next level web applications, do catch PJ McClarking's talk tomorrow. You heard in the keynote that PWAs are now listable in the Play Store. Ben, when can we expect to see Spark there? So, from our conversations, it's pretty clear that Chromebook users look for apps either in the browser or in the Play Store. And we want to be where our users are looking for us. Our experience with the Play Store on Android has been positive. So, while I can't give any specific timelines, we are excited to see how being in the Play Store for Chrome OS impacts user acquisition and engagement for our web application. And I'm glad that you're taking your time to do this because it's important that the web app is high quality. It meets the performance benchmarks for doing trusted web activity and listing in the Play Store. So, we can't wait to see this Spark PWA in the Play Store. If I could summarize this journey, really, it was from a great desktop web app you added basic installs and then offline. You have a focus and performance, which is really great. And then now you're looking at advanced web capabilities and then, of course, discoverability, making sure wherever users might be looking for Spark, they find it. So, thank you very much, Ben, for sharing this journey and the story with us. I've learned a lot and I hope our audience has as well. Thank you very much and take care. It's been great talking to you too. Thank you for having me and I'm looking forward to our next conversation.