Building Plugins for Adobe Photoshop and XD using the Unified Extensibility Platform

Transcript

Awesome. Hello, everyone. And I’m super glad that you are interested in building plugins for Adobe Photoshop and XD using UXD. I’m super excited to dig into this. We’ve got a lot to cover. So we’re going to this is going to be kind of a whirlwind tour about how you can build plugins, leverage plugins, to increase and improve your workflow using both Photoshop and XD. My name is Keri Schatz. I am the principal product manager for UXP. And I really focus on making sure that UXP meets the needs of our internal and our external developers and ensuring that that platform continues to mature and really provide great extensibility options. So with that, I’m going to dig straight in. And if anyone would like to give me the thumbs up that that everything is coming through loud and clear, that would be welcome. But I’m going to switch over to some presentation here. So I wanted to cover really quickly. Some are our agenda. We’re building why would you want to build plugins and for whom would you want to build those plugins, what the platform is, how to get started, a very quick overview to the structure of a plugin, what your next steps are. And then I am always happy to answer any questions that you might have about the platform. Please feel free to drop them in the chat or in the Q&A. We have some moderators in the chat who will take care of collating everything. But we will, unless something horrible is happening, like suddenly you can’t hear me. We’ll try and hold off the Q&A until the end. But super excited to dig straight in. So why build plugins and for whom might you build those plugins? There’s several categories that we find that plugins tend to fall within. And this tends to be a pattern regardless of whether or not you’re building for XD or for Photoshop, what extensibility solution you’re using, even if you’re building for an app like InDesign, which may not have UXP yet. They tend to fall in some of these categories. So productivity is a big one. We fully realize that there are repetitive tasks that you might want to automate. There might be product feature gaps that you want to cover and improve. Or maybe you’re adding something entirely new to a product to improve your productivity. Alternatively, you might be part of a team. And you might say that that team needs to have some consistency, say with some shared design, some template, some functionality, some functionality. Some shared linting against your design to make sure that you’re following team standards. And all of this can really, really improve your creative velocity and ensure that you’re not spending time on the mundane, repetitive tasks, but you’re able to actually create, which is part of why we’re doing all of this. There’s also the idea of artifact management. So this includes things such as importing and exporting to asset management systems. For example, you might have photography that has to be exported to a repository in your company, or video, audio, those kinds of things. And so you might build a plugin that integrates that into the product. We also often see plugins being built to help with rendition generation for handoff to say designers or to developers. And the same thing is true for code. Perhaps you have a specific framework that you need to develop against, you have a design system that specifies some code that should be built when it sees a certain design. Or maybe you even have metadata that you want to ensure has to be part of your document and your renditions and your output. Plugins are a really, really good solution to this, especially if you’re working in a team or a company. But even if you’re just a single developer or a single individual, these can be valuable. And last but not least, inspiration. Plugins can do things faster, perhaps, than a user could ever imagine. And so plugins that generate art, or allow you to iterate and experiment with randomness and other techniques, maybe AI and machine learning. This really gives you a platform to test, play and imagine. And so you can imagine building a plugin that might generate fractals. And that plugin is maybe something that only applies to you for a few designs, but it still is the end result that matters. And so plugins can really deliver a lot of functionality here. Who might you want to be delivering a plugin to? And so we see three kind of tiers. There’s, of course, you as the user, who might also happen to be a developer. And this includes things such as bespoke workflows, where you work perhaps differently than anyone else on your team, or you have a very specific way that you like to do your workflows. You can build plugins to help that go forward. You also have this concept of inspiration and experimentation, where maybe you want to continue to do your own kind of art styles and things like that. And so just you is a perfectly valid target for building a plugin. You might also have your team that you want to build a plugin for. This ensures that you can create consistent team workflows or have a set of requirements that your document or your photograph or your video must validate against. And what’s cool about UXP is it makes it really easy to distribute these to your team, just using local resources like a shared file storage, email, and so on. And so you can install those kinds of things. You can install those plugins locally, share them with your team, and there’s no complicated process you have to go through to get a plugin shared. And last but not least, you might want to share things with the world. This includes ideas that anyone can benefit. Maybe through your process of building a plugin for you, for your team, you found a process that would really impact a lot of developers and a lot of creatives and a lot of users, a lot of people doing video, photography, those kinds of things. There’s a great way to share this to the world. And for that, we provide a marketplace that enables easy discovery, quick acquisition, simple installation, and the like. There are lots of really great examples out there in the marketplace today. And some of these are available for everyone. And then some of these examples on the screen here are internal use to Adobe or other teams. So I just wanted to cover a couple of them really quickly. We have Spectrum for Adobe XD. This is available on the XD marketplace today. It helps designers follow the Adobe Spectrum design language. And this was a tool that our design team built to make that process easier rather than just having a design library where you drag components onto the canvas. That’s great for buttons. But when you have complex components, such as dialogues and color pickers and other things, sometimes it’s easier to have a plugin that can build that infrastructure out for you entirely on the canvas. And then as you make changes, that plugin can relay things out so that the padding and the metrics and the margins continue to stay consistent. Adobe has also built several plugins to make it easier to build really cool interactive presentations in XD, do whiteboarding in XD, do quick mockups in XD. And we’ve made these available to the community for your use to the world. The third plugin on the screen is one called Journey. And this is an internal only plugin. But it shows an example of a team that has built a plugin that helps them in their own workflows. And this ensures that they can easily build consistent user journeys and personas and marketing material in presentations. But it fits the team’s design language perfectly. So you can use plugins that may not be available in the marketplace, but they can still have tremendous value for your team. There’s some really great third party plugins out there that are available to the world that people have developed and said, this would be useful for everyone. Arranger for XD lets you quickly change and arrange how elements appear on your document. Stark is great for checking accessibility. And then we also have many, many other ones, icons for design, rename it, UI faces. There’s a whole host of plugins out there. But there’s always room for more, especially for creative ideas, for new services and the like. Okay, so let’s get into what is the Unified Extensibility Platform. Before we go and tell you what UXP is, I do want to give you a quick history lesson as to what the extensibility history has been like in the past. I’m not going to go into real great depth here. But I do just want to say that extensibility has been a feature in Adobe’s products for quite some time. And we started off with C++, for example. But we also quickly graduated to things that looked a lot like JavaScript, because that’s a lot easier for developers and scriptors, creatives who may not be developers to understand. And there’s a lot of power here. But extend script, which was the language that we actually went with way back when, was JavaScript from 1999. And so, developers need a little bit more modern of a development environment. And so over time, Flash and ActionScript became a thing. Typings and ActionScript was a slightly more modern language. And this also started to improve what developers could do. For example, in extend script land, you could not have persistent UI. But with Flash and ActionScript, you can indeed have persistent panel based UI. So there’s a lot of powerful capabilities. But of course, as we’re talking about Flash, there was a letter at one time. And so Flash quickly died away. And we released CEP, which we call the Common Extensibility Platform. And this was essentially bundling a Chrome browser inside of your plugins inside of our applications, which led to a lot of flexibility. It also led to modern JavaScript. However, it also came with performance issues. Because you can imagine 10 tabs open in your browser, 20 tabs, 30 tabs, we all know how that feels. Whereas, you don’t want that inside of your Photoshop app or inside of InDesign or what have you. And Adobe is great at using or drinking our own champagne, so to speak. And so even if a user had no plugins installed, there were still features, you know, maybe 10 to 20 that were dependent on the user. And so we built a new plugin called the Bond CEP, which meant slow start at times, memory hogging, not a great experience. And so this is why UXP was built. It is a modern environment using a fast-performing JavaScript engine, which means you can use today’s development tool chains like Webpack, React. We provide a set of built-in rich UI widgets called the Spectrum UXP. And this makes it super easy to build plugins that look well designed, fit in with the UI, and they’re all built in. And so this is why UXP is so easy to build. It’s a simple design, fit in with the applications without having to go to a lot of work to replicate that look and feel. It’s also standards inspired. But it is absolutely critical to understand that UXP is not a browser. Unlike CEP, which was essentially a full-form browser put inside of a panel, inside of our hosting applications, UXP is different. It’s closer to React Native than it is to a full browser. So this means we understand a subset of HTML, a subset of CSS, and our APIs take inspiration from browsers and Node, but it’s not a full implementation of. This enables us to be much more lightweight. It enables us to have tighter integration with our products and improve startup time and improve memory use. But it’s also a JavaScript environment. So we provide a set of common APIs, file I.O., networking, those kinds of things, a subset of the HTML5 DOM API, just enough to work with React and other common frameworks or vanilla JavaScript, if you prefer that. And we also expose the magic of the host application. So this can be Photoshop’s APIs or XD’s APIs. And UXP as the common platform will give you the ability to show great UI. It’ll give you the ability to write files and talk to the network. But it’s really those applications where the magic lies, where we want to be able to create shapes in XD and modify layers in Photoshop. And so UXP makes that possible. UXP is also a marketplace. And so we provide a lot of functionality that I’m not going to go into a whole lot of depth here, but it enables quick discovery, quick acquisition of plugins. We do have a review process if you distribute through the marketplace. So this enables developer or users, your targets, to trust plugins that you are developing. But there is one key thing that I want to call out. Increased privacy, because we’re distributing through a marketplace, is also a thing. So UXP, unlike some of the previous environments, is significantly sandboxed to respect the user privacy and to help users actually know what they’re installing. So users need to trust that the plugin is doing what it says it does. So sometimes there are indeed access requests to certain resources, like access to arbitrary files and things like that. The user does have to grant access to those things. Okay. So that sets the context a little bit. Let’s actually dig in and get started. And getting started is super easy. You need to have either Photoshop or XD installed. In XD, you can immediately start developing plugins. In Photoshop, there is a preference that you need to set. This is under preferences, plugins, developer mode. Pick that box, restart Photoshop. And you can then start to build plugins. Then you need to install the UXP developer tools. This is available inside the Creative Cloud application. I’ll show you what that looks like. But this tool lets you create plugins, test them, debug them, package them. And so it’s your all in one stop for managing your plugin workspace and really going forward with your plugin development. And then you can create a plugin. Inside the UXP developer tools, you can create a plugin from the menu, provide a little bit of metadata, load that plugin, go to Photoshop or XD, and you can indeed see your plugin in action. And so I’m going to demo that for you really quickly just so that you get a feel for what these look like. So over here, actually, let me get the Creative Cloud application. So this is the Creative Cloud desktop application that we have. And we have, this is the marketplace. So you can see all sorts of the plugins that are available. I would encourage you to check this out, get ideas, etc. There’s some really amazing ones to go pick. But make sure to go under the app section and you can download, for example, the Creative Cloud desktop application. And download, for example, Photoshop, or you could download Adobe XD and install those. But the UXP developer tool also happens to be the one that you’ll need to make sure that you install. Without the UXP developer tools, you cannot load your own custom plugins as you develop them in the product. So this is an absolutely critical feature that you must have. So let me go to the developer tools. I’ve already installed it. And so this is what it looks like when you have a large workspace. Not every developer’s workspace will be quite this busy, but I have a lot of examples here. But creating a plugin is easy. I can just click Create plugin. I can give a little bit of metadata here. I can give a unique ID. You don’t need to go to the console to get an ID until you intend to ship to the marketplace. If you’re just distributing for yourself or for teams, you can come up with any ID you want. But they do need to be unique across your team or across your own use. Pick an application, set a version, and then we even have some templates that will get you quickly started. And then once you select a template, you can select a folder and get all that pre-populated. So it’s really easy to get a plugin created. And I’ve already created one. So I’m going to come down here. We’ve got these down here. And it’s really easy to then get these plugins loaded into the application. So I’m going to come over here to this triple dot menu, action menu. And I can click Load. And you can see that it’s told me that the plugin load is successful. And so I’m going to hop over to Photoshop. And bear with me for a second as I drag all of this over. So I have Photoshop open here. And this is the panel that it created from that plugin. So this is a little bit of a plugin that is freshly created. And you can see that it’s got some very basic UI. I can click a button, and it populates layers. And those layers are coming from the layers within my document. So if I change this, for example, to test and click populate layers again, you can see it’s reading my current document. And similarly, I can do the very same thing in XD where I can load a plugin in XD, see that result in XD. What’s cool with Photoshop is that it’s got a little bit of a plugin. And so what I can do is, the plugin is here. And what you can do is, your XP plugins here are fully, you know, they fully interact with the docable environment. And you can have as many panels as you might choose. XD, however, has a slightly more limited user interface in that plugins are always tied to the left-hand side. And there’s a list of plugins initially. And then there is the plugin panel itself. And so this is a rendering of that UI, which means you can only have one plugin panel. visible at any given time. Hey, Carrie, can you? Yes. I think with a lot of this, there’s some fragmentation going on on the screen. Now it’s fine, though. Oh, sorry. It’s refreshed. But some of the window was doing weird stuff. Maybe now it’s fine. Oh, no. Okay. So it happens again. And then I’ll try and go a little bit slower with with with moving windows around. Maybe a pause after you move stuff should help. Yes. Okay. Thank you for letting me know. The developer tool, it really makes it possible for you to not just load plugins, but it really makes the development process easier as well. So loading plugins is not the only thing that’s possible, I can click in here and I can reload a plugin, I could watch that plugin so that as I make changes to the plugin, it automatically refreshes. Or I can even go in here and debug. And that debugging process is really, really easy. Yes. And hopefully this is coming through. That debugging process lets me have a Chrome developer debugging tool open. So it should be hopefully very familiar to you, I can inspect elements, I can view the source of the plugin, I can look at the console, and I can even go it goes so far as debugging. So there’s a lot of functionality here that this UXP developer tool wraps around for you, and makes it really super fast to develop for. Okay, with all that said, I’m going to hop back to my presentation really quickly. And talk really quickly about the structure of a plugin. A plugin structure consists of just a few small files. In fact, you can get by with maybe two files and a couple of icons. If you’re just doing it for yourself, you don’t even need the icons. You need a manifest. And this is just what describes what the plugins name is the versions, any icons, how panels are defined, and whether or not your plugin is going to show panels or commands, and commands are just menu items, they don’t have other UI to show. Then you have a main entry point, a JavaScript file or an HTML file that initializes your application, your plugin. And this also wires up your entry points to link back to what you’ve defined in the manifest. So if you have a command and a panel in your manifest, then your main file and your JavaScript file will also export something of the same name so that you can link those together. And then you also have your various other assets and code, icons, images, other JavaScript code, other libraries. The bigger your plugin gets, the more I suggest using a bundler like webpack, because that’s going to simplify your development, your distribution process. So I’ve already briefly mentioned what kind of entry points there are, there’s commands, and there’s panels. Commands are invoked by the user from an application menu. This is typically the plugins menu in both Photoshop and XD. And you can have as many of these as you want, zero or more. These may render no UI whatsoever, they may just impact the document, or they may display a modal dialogue, which asks for more information before you complete the operation. You can also have panels in your plugin. And like I mentioned, in XD, these are persistent UI rendered in a single sidebar in XD or in a movable dockable panel in Photoshop. These can respond to changes in a document or to my own user actions. And you can have zero or more panels in your plugin. Now for Photoshop, that means if my plugin has three panels, they can all be visible at once. For XD, that means the user can switch between those three at any time. So what does that actually look like in practice? So I’m going to bring up Visual Studio Code. This is the XD sample that gets created. And there’s really only two files here that we have to worry about. There’s a manifest on the left, which includes things such as the name of my plugin, some of my icons, and an entry point. And this actually happens to be a slightly older version of the manifest, but the point is the same between the Photoshop and the XD manifest. If I bring the Photoshop version over, you can see that this version of the manifest, it does say it’s version four. So entry points and things are a little bit different. But similar idea, it describes the icons and in fact, which icons go with which theme, and it describes the entry points. So there’s a panel here, and its ID is called vanilla. And the biggest, most important thing when you’re building a plugin is to make sure that this ID maps to your code. So when you’re creating a plugin, a command or panel, there will be a step where you say that, hey, I’m implementing the vanilla panel, or I’m implementing a do this command command. So let me hop back to the XD example. And as you can see in my JavaScript, I’ve got various steps here. I’m creating a panel. And you can see here some of the HTML that I’m using. And this is just this is an early sample. So you can now use HTML files instead of embedding that in your JavaScript if you so choose. This is an earlier sample. So it has the HTML directly embedded. But you can see it looks very much like HTML you might be familiar with. That can be a little bit that can catch you out occasionally in that we don’t support every possible browser feature. So keep that in mind as you’re building a plugin. But down here, we export a panel called enlarge rectangle. And if we go and look over here to our manifest, let me get this bigger, this this samples entry point is indeed called enlarge rectangle. So you just need to make sure that these match. That’s what what we use to know that that things in your manifest to your JavaScript file are connected. And then there’s a show and an update command for XD. And so our show command just goes through and creates this panel. And this update can listen to changes in the document. So if I switch to XD briefly, and I don’t know how visible this will be, I apologize, I can’t make XD any larger. But I’ve got an object here, and I don’t have it selected. And you can see that the plugin says, please select a rectangle. Okay, once I select the rectangle, the UI updates to reflect the changes. And now it can actually do some work. So I can click Apply. And in this case, it’s a real simple operation. All it does is it adds in a parameter in those input fields to the selected rectangles width and height. And so the bulk of this plugin is really three lines of code, they’ll get the selection, increase the width and height. For Photoshop, the bulk of that plug that plugin is literally a very basic UI layer. So you can have CSS and some HTML. But there is just literally a require Photoshop app, get my app document layers, layers dot map to get the layer names out of it. So I can talk to Photoshop with a very easy, limited API at this point, the Photoshop API is still maturing. So there’s there’s thing there’s improvements coming down the pipe here. There’s a lot of things that you can do here to actually play around. And I would just encourage you to actually play download an app, download a sample, and just start experimenting. So that’s where the watch feature, for example, in this comes in really handy. So if I switch to watching a plugin, and I start making some changes and save them, I can quickly do that and see my changes immediately without having to restart Photoshop. Okay, time is definitely short. And I want to leave a couple of room for some questions. So what are some of the next steps? So maybe this is what your appetite as to what you might want to build. We have documentation out there and samples that I would encourage you to go read. There is documentation for Photoshop, and there’s documentation for XD. The common stuff is the same and file IO networking and the like. But Photoshop and XD document manipulation API’s are different. So it’ll be good to catch those. There are lots of samples you can clone and play with as well. I also encourage you to connect with us. There’s a creative cloud developer forum. We also where you can get support if you have questions. We publish regularly on the Adobe tech blog about new improvements and changes to the platform, or you can subscribe to our newsletter. Change the extension to CCX. You can share that with your team right then and there. Or you can provide that to us on the marketplace, go through the process and share that with the world. And with that, I want to I know, I think we’ve got just a couple minutes left. I want to turn that over to Aaron. Is there any questions that came up that we want to have answered? And then we’ll go to the next question. What is the next step for HTML DOM when I, for instance, build a plugin with UXP and Vue.js? Video was partially supported. You do have the ability to render back video. I believe it doesn’t play back audio at the moment. Audio tags are not currently supported. As I said before, HTML or UXP is not a full browser. So it’s being built over the last four years. So there are definitely things that we’re missing, but that we look to add into the future. We’ll also be looking at adding things, for example, like some limited use of web views, which will provide some escape patches for the future. And then we’ll be looking at the other ones, which will provide some support for functionality that UXP proper does not support. So hopefully that answers your question. For Vue.js, there is a mechanism. I would check the tech blog because I believe, if I remember right, there’s a posting that talks about how to get Vue.js working. And so you can make that work. But again, it is limited to the subset of the HTML5 API that UXP supports. Other questions? Yes. Let’s see. There was a good one from Matthew Newman. I know that Workfront recently implemented plugins for XD and Photoshop. Did those use the plugin framework, this plugin framework, meaning I guess UXP, or did they require custom changes outside of this plugin framework? That’s a great question. And I unfortunately do not know the answer to that. I would have to follow up with you to get that. Let’s see. Will other apps outside of Photoshop and XD soon support this plugin framework, meaning UXP? Which apps and when? This is a frequently asked question. I know we don’t actually know. Yeah, so that is largely based upon the product teams. We have Photoshop and XD out there now. I know there are product teams like Premiere Pro that are actively looking at it. Premiere Pro is probably going to be the next one that makes that publicly available. I just don’t have firm grasp on the timing. But hopefully soon. And then it’ll continue to roll out as product teams have the bandwidth to take things on. Building a brand new API surface is the hard part. We are already integrated in InDesign and Illustrator as the core platform. But it’s that API layer, that magic that lets you integrate with the product. That’s the hard part. And that takes a lot of work to rebuild. I think I answered earlier a little bit about the UXP didn’t really have signing. Yes, you can include UXP in the admin console packages if you’re an enterprise admin. And then this person says, oh, JM says, sorry if I’m unclear. I mean, will there be a web view that you can use on top of the HTML subset? The other frequently asked question. Yeah, so that is one thing that we are slowly bringing out. There’s all sorts of issues that we have to address in terms of security. But also in terms of how it interacts with the hosting application. What we don’t want to do is get back in a world where you have 20 plugins, all of which are using web views and slowing down the user’s machine. But there’s also things like what does it mean to have a web view open that has focus? How does XD then get access to keyboard shortcuts? So there’s a lot of user interaction stuff that we’re figuring out. So we’re going to start by delivering web views in modal dialogue for remote content. This solves a subset of the issues. So it lets you say, let me show an experience that I have on my server, render that out in a web view in a modal dialogue. Modal dialogues have less issues when it comes to working with the rest of the users. And then we will slowly improve that over time so that we can get web views and panels that are persistent and that can render things like local content. So there’s still a lot of fuzziness and TBD around here. But it is something we are definitely working towards. We still encourage to do your UI and things outside of that web view as much as possible just because you get that native look and feel and performance. Any other questions? I’m hearing silence. Okay. So I’m going to assume then that there are no more questions. As always, feel free to ask any questions you have in the chat. I’m hearing silence. Okay. So I’m going to assume then that there are no more questions. As always, feel free to get ahold of in contact with me or with any of us. I’m happy to talk to you. We’re available on Twitter, email shots at Adobe.com. So definitely reach out. Stay in contact. If you’re having pain points, let us know. I’m always interested in chatting with you and making sure that UXP really does meet the needs of the developer community. So with that, thank you for coming. Really, really great to see you all here and excited to see what you build. Thanks very much.