This article is about Oriam's real-life experience of porting its Clinical Trials Management System, EC1-TrialManager, to the Web. The product, initially designed as a PowerBuilder/Oracle client/server application, contained more than 300 screens.

The Goals
The main objectives were:

- From a business perspective:
• No regression whatsoever between the Web and the original rich client/server application.
• Provide new functionalities on the Web.
• Build a flexible application that can be marketed with optional modules.
• Address the security needs of the laboratories that are conducting studies in many countries and allow internal and external personnel collaborate through the Web.
• Minimize the costs of implementing and updating the software.

- From a technical/architecture perspective:
• Security with access control based on roles.
• Performance from usage of an optimized components kernel.
• Supportability from separating the business and technical components.

Among the different design considerations, a number of questions had to be resolved to make sure the entire solution would be consistent with a set of common rules, knowing that the port would involve several technical teams:
• What type of interface (basic, rich) did we want to provide to end users?
• How should we enrich the end-user interface with toolbars, tree views, in-transaction tabs, editable dropdown lists, sorting headers, calendars, and row selectors, while keeping the screen intuitive and easy-to-navigate?
• How should we drive the user through the application with a fully controlled "work space" without the standard interface (menu bars and toolbars) of Internet Explorer?
• How to make the best use of pop-ups?
• How to guarantee the user's context integrity when he logs back into the application, typically after a network incident?
• When a form is opened in a page for data entry, block the possibility of navigatong to another page without saving or closing the form.
• Warn the user when a session timeout is going to occur to let him save his work and avoid any black hole syndrome.
• How to provide contextual help?
• How to provide a "server push" alert to warn the user of an incoming message?
• How to provide customers with a mechanism that will let them easily integrate new custom screens for their users?
• Control the validity of the data as early as possible after entry to avoid any productivity loss by having to reload screens.
• Be sure to dissociate the technical components processing from the business logic used to build the page document.
• Reduce the number of exchanges between the browser and the page server as much as possible to maintain a consistently high level of performance.

A debugging and tuning tool pack was provided to all the developers to maintain consistency through the technical cycle. It consisted of:

• Client trace window.
• JSP trace writer.
• PowerBuilder components tracing and profiling methods.
• Database audit tables.

Application Screens Re-Engineered for a Rich Thin Client Application
Version Checking
Version consistency control between the server application and the client cached scripts.

This is done when the user initially logs into the system by verifying the version stored in the thin Web client context and the current one referenced by the application.

This mechanism must typically be added when migrating from client/server to a thin Web client.

While in the application, the end user can activate various functions via pop-ups. In Figure 1 the user can check the build version level by typing <Ctrl B>, this would typically happen during an exchange with technical support asking for troubleshooting information. Pop-ups when correctly used can become productivity and user-friendly tools.

Master/detail offers efficient navigation to essential research data.

Figure 2 offers many form opening options categorized by the various buttons. A tree view is also available for action. Selecting the desired forms will activate the required components, off line for now. Notice that the forms aren't open (the related components are offline and de-activated) so the tree view items are enabled.

In Figure 3 the form is now open (the related components are activated and online) and so the tree view items aren't available as long as the form isn't saved or closed. The user's workplace is locked until the user validates or cancels his data entry.

The purpose of this screen shown in Figure 4 is to be able to select an item from the tree view on the right and copy/paste it to the tree view on the left. This is an essential productivity tool for users who want to build a new patient visits schedule from existing ones.

The purpose of the "error box" in Figure 5 is to display many messages at the same time avoiding the typical cascade of pop-up windows. In this example, the validity of the visit schedule is tested and two "warning" messages are generated inside the box. There could have been more like "information" or "stop" error levels.

In Figure 6, you may notice two DataWindows on the same page in the lower-right frame to provide an attractive data display. Selecting a new value in the uppermost field (the patient number) will refresh the rest of the screen with corresponding data.