Put yourself in the shoes of the average IT user in a business department. Armed with little IT knowledge the user will make a choice based on what he sees – the user interface. Therefore software vendors sell ‘cool’ GUI looks with little solid architecture underneath. The long-term issues of maintaining enterprise applications are mostly ignored.
For Web-based document applications, Adobe owns two of the most popular plug-ins on the Internet: PDF and Flash. One can only admire them for having had the perspective to make these plug-ins free of charge and thus promote widespread use. Being free does not mean that using them saves the business money. There are several independent (which I am not despite trying) experts who see the problems of hard-coding for i.e. FLEX applications. I have pointed to their blogs in my previous posts. I on my part have long argued against hard-coded PDF (with or without the use of XML) documents. Using XML makes neither PDF nor Flash/FLEX any less complicated. The programmer has one more layer of interfacing to consider and is even further from the user, while files sizes, required bandwidth and CPU needs immediately quintuple!
For these FLASHy GUI applications a horde of programmers creates a singular hard-coded construct. Yes, I admit that today more tools are available to administer some functions but not for example the GUI in Java, AJAX or FLEX. It is like programming any other graphics environment. To compete with Papyrus many vendors renamed their control files or tables to ‘repository’. Can they define object types freely in all their features like in Papyrus? You better find out what RIA and repository means for them.
As a matter of verifyable fact, Adobe LifeCycle with FLEX does not make an application more FLEXible, but the GUI can be used in the browser. Adobe for example flogs the benefits of using the same form in PDF and FLEX, which I see of little to no value. A FLEX GUI would be dynamic while PDF does can not produce a dynamic document. It is a static page presentation language. There is however something going on within Adobe to enable PDF dynamical formatting by adding some proprietary XML. That this enhancement process is owned by a vendor makes Acrobat/PDF by definition as proprietary as Papyrus and not a standard.
Well, we could have added some triangle brackets to DOCDEF and PQL so we could call it an XML standard. But as this hurts the business by making applications slower and more CPU and network intensive we refrained. Dumping XML as a transport format for Flash GUI definitions in Papyrus EYE substantially improved performance on server and in the Flash plug-in.
ISIS Papyrus delivers such applications since 1998 using its Papyrus Client with the DOCDEF language to create dynamic documents. We are many years ahead of Adobe. ISIS Papyrus invented the Internet correspondence market that was soon overrun by vendors with hardocded Java frontends, odd XML editors or using Word as an editor. Analysts promote the use of ’standard’ tools such as InDesign for creating dynamic documents. It shows that they do not understand what correspondence means because InDesign has no means to create dynamically assembled documents and all document logic and data embedding has to be hand-coded.
Creating, deploying, administering and maintaining applications is where the real cost is and it is hidden behind the ‘free’ plug-ins Acrobat and Flash. Enterprise size installations of other products can easily be half a million dollars (or a lot more) in software products and possibly another million dollars in implementation coding for a sizeable installation with several hundred documents. These are my estimates and prone to error. If you have numbers that prove different I am interested to hear them. I will publish them here. The real crunch comes however with maintaining these applications. Any change in screen presentation, data interfacing, and business logic will most likely be again an expensive coding/testing exercise in most other products. An average ISIS Papyrus installation can also be half a million but it will be 250k to implement at most. The business then has total control over the application without needing programmers. With Papyrus the definitions are in the repository with maybe some scripting.
Papyrus offers definable data population into a form, allows entered data to be validated, enables digital signatures (as well as SmartCard and Biometric authentication since 2003) and rights management, and certainly allows web services to be integrated since many years. We have dynamic paginating documents in true WYSIWYG that PDF will not have for some time for Acrobat. We only generate the PDF when the dynamic pagination has been completed based on the data input and document interaction with the user. Yes, Papyrus is not dependent on FLEX but its Papyrus EYE technology is at least as powerful, but more flexible and does not require any programming.
Those vendor’s claims of full batch (structured), on-demand and interactive functionality should be considered with caution. The functionality is compared to ISIS Papyrus is limited. You might ask whether analyst studies would not show the differences. Many comparison studies do not look at the products. Gartner and Forrester just send out EXCEL sheets to fill out. That is it. No true assessment.
So could Papyrus not also possibly be all smoke and mirrors? Sure. Which is why we always propose to do a Proof of Concept installation to verify feasability before buying anything. But as always dear vendors, I am willing to do an independently assessed heads-on comparison of product functions and long-term impact ANYTIME with ANYONE.