What is Papyrus EYE? And how did we get there?

When I designed the Papyrus Objects concepts in 1997, it was one of my criteria to keep the presentation of information seperate from the functional logic. I guess it is much in line what is called the MVC or model-view-control pattern of OO programming. But it was not my main concern. I did see at the time that there were the business objects in the WebRepository that represent the metadata models of business and the functional objects that were needed to control the application. It was immediately obvious that the control part of the application was related to business process.

How would we present then the business objects to the user? I have to admit that this has been the toughest and most difficult part of developing the Papyrus Platform. First and foremost because we were way ahead of available technology. Everyone wanted us to code DDE, COM, and later .NET programming interfaces so they could hack into our functionality and code their own GUIS. I refused and still do. Today when all the buzz is SOA and messaging interfaces I have been proven right.

So we developed the Papyrus Desktop. It never turned into something that I was very satisfied with, despite being a fantastic, flexible do-it-all environment, but it was quirky and unusual. I was unhappy because it was too slow to respond to our customers needs. That had to do with programming and users not knowing what they want. Users only know what they DO NOT WANT once they see it. So we would do projects, define user interfaces and expand our desktop to support them and then the business users would always reject it. We always delivered … not always on time, but we delivered.

Obviously when we started to hack into our standard product in those late stages of a project there is no way to stick to a three month quality cycle as is normal with our products. Therefore the Desktop and Papyrus Client acquired a reputation for being buggy which was highly unfair (but understandable from a user perspective) as we changed it to satisfy those users.

in 2000 we started to do those web projects with WebArchive using modules and scripts running in Apache or IIS and even early WebSphere (till today a dreadful product!). Soon everyone – business users, IT and our consultants – were complaining about HTML and Javascript work. We had dreadful problems with IIS and Apache versions being incompatible and even with Apache that was incompatible between operating systems. We added the HTTP interface to our kernel program because I had decided at the time that I wanted Desktop and browser applications to be compatible and to some extent we did that with simple screen layouts using the same GUI view definitions in the WebRepository.

We needed our own stable technology to make the web compatible with Papyrus and thus created the Papyrus WebPortal, our own deeply integrated HTTPS server in 2002. Over the next years we worked with a variety of technologies such as Ajax, OpenLaszlo, and others depending on what customers wanted in the Portal.

Then I decided that a huge step forward was needed and we defined what was called XUI or eXtendeable User Interface. A library of GUI objects managed in the repository and presented via Flash code or QT. We started to develop kernel side functionality in PQL (Papyrus Query Language) in 2006 to make the creation of XUI user interfaces even simpler and faster. We did our first projects and inhouse applications.

By 2007 we knew that we were on to something big, because everyone (Adobe with FLEX and others) were beginning to market RIA or Rich Internet Applications built on Flash, Ajax or Java toolkits to run in the browser. But it is all pure programming on the server side, while with Papyrus we were doing a definable and manageable set of GUI components deployed under full version-control from the WebRepository.

As we did our first demoes and were able to present to customers Web GUIs in a few days where we had taken months of Desktop coding before we decided to make this a new mainstay of our Papyrus Platform by naming it independently of the Portal. Annemarie Pucher (CEO of ISIS Papyrus Software) suggested to name it Papyrus EYE with me suggesting the Egyptian Udjat – the eye of Horus – Symbol we now use as logo. There are still some customers who see the Flash Frontend as a problem but that will change as Adobe pushes forward. We are anyway not dependent on it as we run in our own QT based desktop also as a Plug-In in the browser and we can implement EYE also in Ajax with not too much effort.

We were always more concerned with core technology than fancy and flashy frontends and to some extent that was a drawback but pays off today. We have less legacy problems in Papyrus now. Powerful user interfaces are the key to user-friendlyness but only if they are not hard-coded and forced on the user. We are using the Papyrus EYE technology at this time to define a new Desktop layout that is very generic and provides the business user with simple OO navigation and search as well as full customizable context layouts.

If you will join us at the ISIS Papyrus Open House in April and May you will be very surprised.


Welcome to my ISIS Papyrus Info Blog

Welcome to the ISIS Papyrus Information Blog.

I decided to keep it seperate from my general blog on information technology so that my personal position and the corporate line at ISIS Papyrus Software are not confused. As much as I try to live my corporate life according to my convictions, there is a corporate line of business that is not just mine alone and I guess that is good.

Regards, Max J. Pucher

Chief Architect ISIS Papyrus Software