A lot of users and customers are anxiously awaiting updates of BookBarcode, IndexMatic, and other Indiscripts' tools that still refuse to properly work in InDesign CC. “Why does it take so long to have my favorite script running in my new environment?”, they ask…
This morning I received an email that summarizes the growing misunderstanding: “Many of my peers and contacts have ignored Adobe's latest brain child and are sticking with the older version. I am therefore wondering if you have stopped your support for InDesign for the same reason.” Many Indiscripts fans also say they love(d) my products but now feel stuck. To top it off, I promised updates or fixes for several months—or even years for certain products.
So what is this all about?
• Indiscripts products are based on two technical layers, ExtendScript and ScriptUI. The former allows the script to interact with InDesign and provides the essential functionalities (what the script actually does). The latter allows you to interact with the script and provides what we programmers call the “User Interface” (UI) based on dialogs, buttons, and so on.
• From InDesign CS4 to now, including CC, the ExtendScript layer has remained extremely stable. That is, the main code of each script (Wordalizer, BookBarcode, IndexMatic, etc.) is quite safe and only requires some slight adjustments when a new version of InDesign is coming. In terms of scripting architecture InDesign is arguably the most accomplished application among the Creative suite and cloud.
• But, something ironic and unfortunate happened with Creative Cloud: the ScriptUI layer has been heavily altered. At the very beginning ScriptUI was something of a bridge between our scripts and your Operating System. Dialogs, buttons, listboxes, or user events were simply rendered and processed by the OS. There were boring bugs in that bridge but, at least, programmers could step in and circumvent issues in a predictable way. CC introduced a new paradigm: ScriptUI is now a bridge between our scripts and some internal Adobe brick (Drover) that fully manages the look-and-feel of UI components.
So what? Isn't it cool to have pretty OS-independent ScriptUI interfaces that fit the new skin of CC apps?
• Yes it is, but ScriptUI CC does not work very well, to say the least. It does not seem that Adobe has considered a priority to maintain the historical features of ScriptUI. At the launch of Creative Cloud in June 2013 script developers have been taken aback and alerted Adobe. From then, the dev team has very gradually restored, or reconnected, lost functionalities. However, many of us still expect the return of ScriptUI fonts or the fixing of very serious bugs in the UI event loop!
• On several occasions I was advised to simply give up ScriptUI and use a new technology to offer sexy interfaces for my scripts. As far as I can see, going towards Flash/Flex wouldn't have been a choice for the future! My colleagues tell me I'm stubborn. Well, I only ask Adobe that ScriptUI works as expected. This technology is a minimum for those who create process-oriented scripts. It should be the best option for those who focus on ExtendScript and do not consider that “programming is just having fun in making UI.”
• Also, my policy is to provide—whenever possible—backward-compatible scripts. User feedback shows InDesign CS4 is still at work on many workflows! In this context, converting all my products into HTML5 extension panels doesn't seem relevant to me.
Then, going back to the original question, my answer is: Indiscripts definitely plans to have its products CC-compliant. In fact, under the hood—at the processing level—they already are! The whole problem is that the surface layer, ScriptUI, is not yet fully operational in CC. And this does not depend on me :(
Thank you all for your understanding.