Does Configurator 4.0 (or Configurator 3) support the creation of HTML5-based panels?
I received the following email from Adobe:
Photoshop CC, starting in the middle of 2014, will remove support for Flash-based extensions. All other Creative Cloud products have already marked Flash-based panel support as deprecated at this time, meaning no future enhancements or bug fixes will be coming for Flash-based extensions.
The current version of Photoshop CC already includes support for a new type of HTML5 based panel. We are currently working on a new version of Adobe Extension Builder designed specifically to support the creation of these HTML5 based panels. You can download a free preview here: http://labs.adobe.com/technologies/extensionbuilder3/.
Details about developing HTML5 extensions for Photoshop as well as for other Creative Cloud products are available in the Extension Builder pre-release program here: https://adobeformscentral.com/?f=6V6IgvE0yLQQ7bgadxNXaw . You can also join the Photoshop developers' prerelease program for details specific to Photoshop. If you're interested, please let me know and I will get you setup.
Will the panels created by Configurator 4.0 work in PS CC after the middle of 2014 when support for Flash-based extensions is removed from Photoshop CC? For that matter, will the panels created in Configurator 3.0 work in PS CC after the middle of 2014?
According to John Nack, configurator is pretty much dead: http://blogs.adobe.com/jnack/2013/09/build-html5-based-extension-for-p hotoshop-more.html#comments I think it might be wise posting your panels on the Adobe Echange to show that it is useful for you.
I'm afriad that supporting HTML5 panels would involve essentially a complete rewrite of Configurator and it's a massive amount of work. If we can see that lots and lots of panels are being created by Configurator then that would hopefully provide justification and revisiting the decision to stop any further work on Configurator. We need to see usage of Configurator and the best way to do that is to submit your panels (free or paid) to Adobe Exchange. You can create an account for free here:
Remember you can also sell panels by setting up an account with our payment vendor FastSpring, there is a link in the Account page on Adobe Exchange.
I hope that helps.
Jonathan Ferman | Product Manager
I don't think you're ever going to see "lots and lots of panels" because people are essentially creating these panels for themselves or close friends or business associates. They are tailored to very specific needs and application workflows. They aren't necessarily intended for the masses and subsequently don't show up on Adobe Exchange. Switching to the HTML5 platform for panel development will mean that many, perhaps most, people using Configurator will no longer be able to make these custom panels since Extension Builder 3 is really intended only for those with software development skills, and once support for Flash-based panels is removed from Adobe applications, people that have created Configurator panels will no longer be able to use the ones they have already created. So while you many never see that "lots and lots of panels are being created by Configurator," you may be hearing from lots and lots of users of Configurator once Adobe stops supporting the panels they have created.
I'm curious why the support for Configurator panels needs to be removed from Adobe applications? That's sort of like saying that Photoshop is no longer going to open images created 5 years ago because Adobe decided to change the specification for the PSD format and will no longer support the older format. There may be advantages to HTML5-based panels, but I think it's wrong for Adobe to abandon support for panels that were created using Adobe software.
For the life so me, I don't see the sense in the decision to hobble Photoshop by deliberately withdrawing support for configurator based flash panels. I fully understand that configuratior will no longer be maintained or updated but, as it already exists and many people use it, where is the sense in deliberately breaking Photoshop so configurator based panels can no longer be used there? This seems like madness to me!
Over the last few days, I've been grappling with the learning curve required to use the extension builder, and it's something I'm determined to do, in time.
I'd like to say that my quest for teaching myself how to use extension builder was something I have a burning desire to do, but in reality that's really not the case at all. I've had no choice in this, simply because I know that if I build my next panel in Configurator, six months down the line that panel will be no use at all, because by then Photoshop will have been deliberately broken, in terms of flash panels, and I'll no longer be able to use them there!
Let me make it clear, amidst the fog of sparse and foggy tutorials about exstention builder, I see great potential for HTML5 based panels, but for me, and other non-coders out there, it really is just potential, and not something we can simply pick up and use today.
Configurator, on the other hand, clunky as it is, gives everyone the ability to put really effective and functional panels together in a few minutes, after viewing a few basic tutorials... Panels that can be easily made to access tools, scripts, actions, and (just about) everything else. We can include the download of remote files, server based video, and a whole host of other tricks, via a simple drag-and-drop environment, ideally suited to us creatives, to us lowly non-coders.
The HTML5 route is fine with me, as long as that includes a configurator based interface (optional, maybe), which enables anyone used to configuratior to use it in the same/a similar way to the way we use configurator.
The more I think about this, and the more I struggle up my EB learning curve, the more I get this niggling thought that somehow, someone is on a mission here to make Photoshop panel design the sole preserve of 'The Coders', and inaccessible to photoshop creatives who haven't been initiated into such hallowed halls! and who don't know the secret handshake! I appreciate that HTML5 panels are 'Way cool!', but that in itself is no reason to rob Photoshop of the ability to engage with the 'not so cool' technology of configurator panels.
In many respects, I suppose scripting (which I use in my configurator panels) is a great deal 'cooler' than actions, but no one at Adobe have ever broken (sorry, 'updated') Photoshop so that it can no longer access actions, leaving users with no other option than to use scripts!
I'm not making an appeal here, I'm saying, categorically, that robbing PS of the ability to talk to configurator panels is a very poor commercial decision, and I truly think it's the first time I've seen a software company wind back the clock in terms of an applications features.
Yes, let's have HTML5 panels... They sound fantastic... But let's keep the ability to use their less erudite, not so cool configurator counterparts. To do any other is to make many remarkably useful existing panels and extensions unavailable to Photoshop users.
It's been quoted that the reason for pulling configurator extension support is the fact that not enough has been made of them by the Photoshop community, and not enough of these extensions have been shared or made available to the wider public. That is certainly a valid point, but it has to be pointed out that many configurator panels are machine-specific, and the fact that these panels are not shareable does not mean that their creators are not teaching other photoshop users and students how to make them! The fact of the matter is that all of these extensions and panels can be made useable by all, if we bundle machine-specific presets and resources with them which, once again, we can do via configurator.
Come on, Adobe, don't be so short-sighted here, shuffle maintenance of configurator off into that darkened room where all Labs projects go, but leave the ability for Photoshop to use them!
I'm currently putting together a watercolour panel which will be very useful for all of my students... Given my current level of EB knowledge, this may never see the light of day.
I agree with AnthonyK that for most of us, our panels are made for our own workflow and not something that we write for the purpose of sharing publicly. I share some of my panels with participants in the automation workshops I've taught - but otherwise just use them myself. Just like my Actions, and even scripts that I've either mashed together myself, or hired script writers to create for me.
Basing useage on the number of publicly shared panels doesn't make sense - basing it on the number of downloads of Configurator and of publicly available panels would be the more accurate way to judge the level of usage. Those downloading Configurator are building panels - very likely to help their own workflow. Those downloading publicly available panels are taking advantage of the panels that others have made and may not be dreating their own.
I don't know anything about whether there is a reason to move from Flash to HTML5 panels for Adobe - but I assume there is, or they wouldn't be doing so. What I would hope is that Adobe can invest the resources, from the billions of dollars in annual sales, to create a product that allows us non-coders to continue to build custom panels in a manner that is as least as easy as with Configurator, and that has at least as many features.
This measuring of useage on the number of publicly shared files reminds me of something Kodak did in the 1990's. I worked as a consultant for them at the time, and they went from having one Law Enforcement Representative in the US to 14 in a period of a few years. Management realized that they needed to measure the return on this investment so they created specific SKUs for law enforcement products - they had special law enforcement film (it was the same as their standard film but different packaging), they had specialized packaging for their digital cameras, etc. These products were only available through a small handful of dealers, and the prices were higher than the consumer counterparts. So, law enforcement agencies were being asked to purchase only through specific dealers and to pay higher prices, which of course, they didn't (although they were buying Kodak products). Kodak management didn't see the law enforcement SKU numbers that they thought that they should and they eliminated their support. They measured sales the wrong way and lost a large amount of the law enforcement market over the following years. I hope Adobe will understand that many of us who download Configurator are using it and finding it an important part of our workflow - but we're simply not sharing our panels publicly.
I'm one of the devlopers who build Configurator 1 and 2. I like the idea Configuator represent, which help direct users redesign their UI/workflow without help from programmers.
I don't like to see it gone. So I just wonder maybe we can turn it into a community grow product just like many other open source projects doing.
I'm not sure how far I can go, and I can't promise what I can build for now. Since I'm still a full time worker and don't have much spare time on a hoby project. I'll try to build a prototype in the next few months. I consider this is a very interesting jounery.
The first step is collect some ideas, and I'll investigate some exists SDK or frameworks like TideSDK and Joint.js
I have setup a project home page on bitbucket.org https://bitbucket.org/zwang/uidesigner/wiki/Home
z.wang, I did play around with Configurator 2, I think, but didn't presue it too far, as it seemed limited in dealing with extendscript, which is what I mainly create, when I want to automate something. I would agree with the above comments about most panels/scripts that I create are for either personal use or use at my work and just distributed to my co-workers, as it is geared for our work flow. I'm reluctant to spend time learning to create things that will become obsolete - sometimes within one version of PS.
I landed here because Configurator 4 panels don't seem to work properly in Photoshop CC - certain operations become laggy and non-responsive. Switching between layers or channels take up to a full second.
In 14.1 I was able to restore normal operation by removing the panel and re-exporting it. But 14.2 is no go. A google search revealed others with the same problem.
So that's it, then. I suppose there's no point in looking for a fix.
about some background:
The customizable panel is a feature supported by photohsop SDK, its public available. I guess.
So anyone can create a tool to build panel, just need follow the interface defined by SDK.
You can use any HTML editor you like, even using a simple text editor to write some html, and deploy it as a customized panel.
And what the Configurator doing is generate a XML file which includes widget layout information, and use a SWF panel template to load this layout information and show it.
So, in theory, the Configurator generated XML layout file can be converted to a HTML panel.