Updating existing Domino web applications in 2014

I was recently asked to update on old web application to improve the user experience and bring a "fresh and functional" new front end, making use of the latest development tools available in IBM Domino. This is a web application, not a website. The reason I make that statement is that the system revolves around processes, workflows, data and forms. It's a working environment and not simply a site that provides information. The system is BIG, with 20 odd databases, hundreds of forms and views, dozens of agents, subforms, shared fields, script libraries, pages etc... You get the idea. The development took around two years of incremental builds to reach the current release which has remained stable with small updates now for the last 4 or 5 years.

It was originally built in Notes/Domino 7 and uses many old style Domino web development techniques. These include pass-through HTML, Javascript and CSS libraries (attached or pasted into pages), html header fields, computed fields which generate HTML, Lotusscript agents performing background tasks and also generating reports and exports, subforms for common html and the list goes on. Now there are a lot of features in the current system that required a lot of coding, work arounds and hacks. For example the code to handle the view navigation was hand crafted using Javascript, CSS and AJAX. The structure of the forms was built using pass-through HTML, embedded standard design elements, CSS, code attached to individual fields, code attached to the form itself. Basically there's code everywhere!

So 8 years down the line the system is being used in a good number of companies, has been constantly supported and updated where needed and the bugs ironed out! The problem is the world has changed in that time and the system needs to move with those changes. As is the case with most systems built over 4 or 5 years ago, it was designed for installation on a server at a customer site. It wasn't designed with the idea that one day we would want to host multiple instances of this in a "cloud" environment for lots of companies or that we might want to throw out a lot of the UI and replace it in the future, however that is the case in both instances now!

So I set out my objective:

To provide a richer but simpler design by utilising the feature rich tools now available, removing as many hacks and as much surplus code as possible by using out of the box design components. But still make use of the investment already made in the product by not re-developing the entire system and re-using as much of the existing design as appropriate. The user interface needs to be familiar to people using sites such as Facebook and other social media. It should follow current trends in respect to layouts and design and if possible use standard CSS frameworks. Importantly it needs to provide mobile/tablet access to specific elements of the system if not the entire system.

So a few months ago I started to investigate what I could use to make this happen. Clearly in Domino using Xpages was the obvious choice as it provides many of the features I need out of the box. In addition I wanted to make the layouts standard and simple to maintain so the use of a responsive CSS framework such as Bootstrap or Foundation seemed like a plausible solution. But here lies the problem, I have little experience in Xpage development (although I understand quite a bit I've never used it in a project!) and I have never used either of these frameworks. Now that in itself isn't a big problem as long as you have the time available to learn the technology and best practices, something that can take months or years, time I simply do not have right now.

As I dug deeper into the work involved I realised that rather a lot of the design in the existing system could not simply be re-used. The existing page layouts currently in subforms could not be easily transferred into Xpages or Custom Controls due the use of pass-through HTML, computed fields, embedded elements and code in HTML Headers etc... Pretty much most of the existing code that generates front end would need to be re-developed if I want to use Xpages and/or a CSS Framework. I would have to create new Xpages for every form and view I wanted to keep and since just 1 of the 20+ databases has 97 forms and over 100 user views, that became an unrealistic proposition. I chatted with Paul Withers and also discussed some of the issues with the community on Twitter and it became apparent that even experienced Xpage developers are not tackling moving large scale systems to an exclusive Xpages design due to the effort required.

So the conclusion I have reached is that I should look at using Xpages to add functionality to the system but not replace existing functionality. For example the development of the mobile interface might well be done in Xpages using existing functionality found in the Extension Library (Thanks to the gang at OpenNTF who put that together!). The use of a CSS Framework and replacing existing forms/views with Xpages will have to be out on the back burner sadly, unless I can find a simple and quick way to do it.