Do you (the Adobe folks) have ideas about how the Persistent UI would be exposed to plugins at this point, that you could share with us?
Seems like a persistent UI panel would be openable and closeable at any point, and would co-exist somehow with whatever other built-in and plugin UI panels were showing. (The UX for this I don’t have a strong opinion about.)
I’d assume the persistent UI panel (let’s call it a PIP) would receive UI events like “opening”, “opened”, “closing”, “closed”, etc., corresponding to events that any toolkit (like React or Vue (yay!)) would need.
Then, when open, it could receive “selection changed” and “properties changed” events, the latter for when the selection hasn’t changed, but one or more properties in the selection have changed. (E.g., a font size on selected text.) (The idea being that a panel could cache what it needs about the current selection, and only update that cache when the selection itself has changed.)
Of course, if Xd doesn’t know or want to keep track of changes (e.g., another plugin has run and make some unknown set of changes), it could always just send a “selection changed” event, meaning “I can’t tell you what happened–go and figure it out for yourself as you need.”
Forgive me if this is all obvious or unwanted or inappropriate–I’m just hoping we can work towards a common goal. And I wanted to get other developer’s ideas here as well.
Definitely not unwanted or inappropriate! We’re happy to discuss this with the community.
We’re actively exploring non-blocking user interface concepts right now (equivalent to persistent UI). I don’t have anything concrete to share regarding the actual look and feel there beyond that we are thinking about a wide variety of potential experiences. The initial (“MVP”) release of any non-blocking UI is likely to be a much simpler version of where we want to go long term, and not the final version by any means. XD’s really not had to worry about plugins in their own panels before, and so this is going to be something that evolves over time.
How a plugin is notified that is now visible (or not) is something we have to determine. It might be similar to how menus are handled now—that is, a callback is triggered in your code and your app can respond appropriately. Or, an event might be sent instead. Once we settle on the final L&F, we’ll have a better sense of the notification pattern. One way or the other, though, the plugin would have to know when it has visible UI.
The document notification event system is also something that we’re actively exploring. I can’t say for sure, but it will probably be something of the sort of “hey, plugin, something changed… go figure out what”. There’s pros and cons to that, of course. Pro is that it’s fast to trigger and the plugin only needs to worry about a single event (no need for batching). The cons of course include having to figure out what actually changed (time consuming, requires tree diffing, etc.). Regardless of what events are available, the plugin will be able to respond to changes in the document and update its own UI accordingly.
If you’ve got any specific use cases in mind, please, let us know! These will help guide our direction in this space.
1 Like
If I understand the context correctly, persistent UIs would essentially be plugins that can display within the main canvas area and interact with artboards and objects?
If so, my software startup (diff) is heavily targeting plugins for Adobe XD, one use case that comes to mind is the ability to allow designers to click an object in the artboard and go directly to all the current comments against an object or see all of its uses in a web application.
Quick mockup
There are many different kinds of UI that we’re considering for XD. What you’re talking about here is “on-canvas UI”, which is something we’re planning to build out (although panels / floating windows will come likely first).
Of course, any and all ideas and use cases for on-canvas UI are more than welcome, because we want to ensure we build something that meets the community’s needs! So bring on the ideas! Your idea in particular sounds like a fantastic use case, but we imagine others, such as custom tools, on-canvas property modification, highlighting of problem content (however you define that) etc.
1 Like
That’s actually really interesting, if I understand correctly then on-canvas UI would be focused on the interaction and manipulation of content on a screen?
Would this enable something like identifying that some selection or group looks like it might be a button and trying to help an adobe XD user clone a version for a responsive UI or improve accessibility?
Also do you envision providing any eventing mechanism in Adobe xd for real-time feedback to assist designers?
@kerrishotts my suggestion and is something I waited to long for Adobe to implement.
I called it right click menu. https://i.ytimg.com/vi/8MrjMy3N6vo/maxresdefault.jpg
I think adding features to the rigth click is somehting thagt MAYA does it better than any other software.
Also called context menu. Maya keeps the rigth click context/selection/select tool as the primary menu and we can add shortcuts to the rigth click also based on the context or outside the context.
Just an idea.
EDIT:
If I am not mistaken ZBursh also allows it.
@igcorreia Plugin panels are mostly here (see recent announcements and github examples). The right click menu (called context menu) could be a separate feature request.
1 Like
A non UI blocking dialog as a possible entry point, with a possible position outside of the panel or with the panel closed(external toast). A use case would be, notifications from a plugin. Also, the ability to add a dot/indicator to the plugin icon(PS) or line(XD) for new activity.
1 Like
