Intro
XPages is a new feature in IBM Lotus Domino 8.5 for developing web applications. XPages can reduce the cost of maintenance, enable quicker development, and a make it easier to present a more compelling user interface for Lotus Domino web applications. This article introduces a simple CRM application for managing sales leads for the fictional Zeta Bank company. This same scenario was the basis for many
composite application collateral. We will first explain why XPages was selected as the appropriate technology to create a compelling web application on a Domino base. Next, we show you the final solution suggesting what is possible and what will be covered in this article. The last section will focus on the application design, highlighting some of the key concepts used to make this application compelling, functional and efficient.
Business Scenario
A large number of companies are looking to XPages to create compelling web applications on a Domino base. Many of these have existing applications and are looking to convert for one of two main reasons.
In the first case a company's application may currently be targeted at the rich client and there is a business need to offer that application to a thin client solution. It may be that it is now going to extend beyond the firewall into their customer's space. Or it may be that they want to increase their access internally to users without the Notes Client. Or it may be that they have been acquired (or acquired another company) that needs access to the application, but does not have an existing Notes client infrastructure. Or it may be that they need to start the increasing number of mobile devices used by their user base. All of these circumstances may have been possible in previous versions of Domino but the cost of development may have been too high or the skill set may have been absent.
The second case is when a company already has a Domino web application served up to the thin client based on the previously available features. Although this still works and is supported, the company is evaluating a switch to XPages in order to reduce the cost of maintenance, enable quicker development, and a make it easier to present a more compelling user interface.
In order to produce a sample that addressed these cases we decided to first start with a rich client Notes application. The chosen application is a simple CRM application for managing sales leads for the fictional Zeta Bank company. The functionality is spread across four separate Notes applications. The first is the core database that is used to do the primary tracking of sale leads and company information. The second is based on the discussion database template and was used to track discussions about individual sales leads. The third is based on the document library template and is used to track the status of the contract finalizing a lead. Lastly is a names and address book that is used to combine the contact information for the sales reps, company contacts, and opportunity leaders. Relationships are maintained between these databases by using the company and lead names as keys for categories. So, in addition to supplying a web front end to our applications, we also want to provide some integration between the applications. We want them to appear as a visual whole, and that the workflow moves between them easily without having to search, browse or
cut and paste keys or information from one to another to find the appropriate entries.
This use case will, hopefully, be familiar to many of you. But every company does have its differences. In order to work out the suitability of XPages to your own application lets look at some simple criteria we used to evaluate our case and how we determined if XPages was the right direction to go in.
Thin Client Access Required. XPages is a thin client technology. Unlike Notes forms, which can be constructed so that they can be used in both the rich client and web client, XPages can only be viewed with a web client. Most mobile clients support the use of web apps through a XHTML compliant browser. XPages are fully XHTML compliant and for this criteria mobile clients also count as thin clients. Although XPages do not provide a rich client solution, they can be developed without perturbing an existing rich client solution. So if you need both thin
k and rich clients, but are happy with your existing rich client, or are willing to support parallel development, that does not rule out XPages. If, however, it is a requirement that you have "develop once, run both rich and thin", then XPages is not currently an option.
Current Assets and Business Logic Easily Surfaced. XPages can effortless display data stored in Notes documents or displayed with Notes views. It can activate business logic in Notes agents, Web Services, and field formulas on forms. If your application uses these technologies for its data and logic then it is an easy port to XPages. If your application uses more complicated technologies then a deeper evaluation is needed. Some technologies like using relational databases for data, accessing platform DLLs, .NET or ActiveX components are not impossible, but more work is required to make them XPage accessible. As a general rule of thumb, most of the "glue" in an XPage application is Javascript, and if the technology you use is able to be accessed from Javascript, then you will be able to integrate it with an XPage based application.
Different Data Sources Linked by Common Keys. Because XPages are generally agnostic to their back end data source, they are an excellent technology for integrating applications. If this is part of your use case you also need to evaluate if there are common keys that can be used to link the two data sets together. For example if you have a ordering system, an account management system, and an inventory control system, you will need common points between them. For example a component product ID that is used on order and inventory or a common customer number that is used for orders and accounting. Even if the different systems uses different, but consistent, identifiers, as long as there is a way to "convert" the key for one application into a valid key for another application, then they can still be integrated.
Integrated Process but not Integrated Applications. As above, in addition to thin client access, the benefits of integrating your process can be a value proposition for moving your application basis to XPages. I
n order to realize this value the applications you are integrating must be part of a common process. If they are completely disparate (e.g. an inventory management system and a travel booking system) you may gain some value from co-locating the two applications if they are frequently used sequentially. However it is not as high value a reason for moving to XPages as removing the need to cut and paste,
search or flip between existing applications.
In the case of the Lead Manager, it scores highly for all of these criteria and is an excellent example of where moving to XPages will provide a great value for the company. An application does not need to get "full marks" on the list in order for it to be worth moving to XPages. But the list can be used as a tool to evaluate suitability or be a guide to what you choose to port and when
.
Application Walkthrough
As mentioned above, the rich client application consists of four separate databases. The users uses the application by bringing up each database in a tab and moving between them.
For the web design of our application we wanted, firstly to make use of the OneUI layout. This is the UI used by Connections, Quickr, and the new XPage templates in Domino. Consistent UI between applications makes users more comfortable with using the application, requires less training time, and leverages a tested, flexible and extensible User Interface design specifically developed to make web application more efficient.
So, following this format, we have a header area that shows the current major area of the application that you are currently using: Sales Leads, Company List, or Contracts, and allows you to switch between them. Beneath this the title of the current area is repeated for clarity. A search bar is given, plus in the left hand column a categorization selection area, and several filters. This allows you to quickly customize the main data view of your sales leads to quickly find what you need without having to page through all the data. And, since the objective of this page is to pick a lead quickly before diving on it, the right hand column contains a list of leads that you have recently worked with. Many times if you are coming back to previous work, you can jump right ahead and pick it from near the top of the list.
Once you've picked a lead you are then brought to the lead details screen. This page groups in the upper half of the page all of the information directly relating to this sales lead. It can be edited in place and updated by going into edit mode. Beneath this is presented various additional information relating to the lead organized in tabs.
In the first tab is the information sheet for the company. This is an XPage custom control that was created to render data from the document describing the company in the core database. It's used here by directing it's data source via a calculated value derived from the data in the lead document.
The Contracts tab and the Discussions tab both present views of information relating to this lead from the legal and discussion databases. The data sources are from those separate databases, but similar to the company info, the category which they are sorted by is calculated, based on the data in the lead document.
Lastly is the Contact tab. This displays contact information for the lead. If you notice, the UI presented here is quite different. This is the existing web UI from the pre-XPage application. You do not have to upgrade all of your applications at once to XPages technology. This is an example where the older UI is being used in the context of an XPage. The URL to the old UI is calculated and loaded within an IFRAME tag on the page. This same technique can be used to include web pages from any other application; including ones built on other technologies.
Application Design
One of the main objectives of converting our rich client application to XPages was to not just give it a thin client front end, but to make that front end look modern and compelling. There are several features that XPages provide that make this easy.
Any and all design elements can have virtually every last detail set to values of your choice. Color, thickness, placement, background, ... you name it. This is powerful, but it can get quickly complicated keeping a consistent look and feel to all of your elements if you have to set each manually. To resolve this, you can promote a selection of styling to a cascading style sheet page (CSS). Once added to the project (and the page) your design element can just refer to the predefined style on that style sheet. This also provides a common place where you can make a single change, and it will affect all design elements that refer to it. This makes it very easy to make global UI changes very simply.
The style sheets in your application can be grouped together into a Theme. This is a XPage unique concept for maintaining all sorts of values that affect the look and feel of your application. You can specify a theme to be used for your application when designing it. You can even make this a computed value if, for example, you wanted to support "skinning" and allow different users to use your application with a different style. A theme can be set on the server to apply to all applications as well, for giving all of your applications a common look and feel.
Lotus supplies, with Domino, two themes: webstandard and OneUI. You can use these as is for the basis of your application styling. Or you can copy them and modify them to include what you want. The best, however, is to do both! You can set a theme to have the ability to inherit from another theme. There will always be unique styling that you want to apply to any application. The structure that we used in the Lead Manager was to create an application specific theme, but to have that theme, itself, inherit from the Lotus provided "oneui" theme. Where we could use the styling defined in the OneUI theme. For additional UI elements that were not covered by that, we added them to our application specific theme. This way we could modify things for our application by altering our application's theme. To retain the ability to make site-wide adjustments, but also inherit new updates to the OneUI theme, an additional theme was inserted between the two. This corporate theme allowed us to migrate theme elements from our application to an area where they could be shared by other applications. Yet when a new release of the OneUI theme is produced, we can update that on the server and get all of those benefits without having to do a complicated merge.
When it comes to the style of the application itself, several design iterations were gone through. Web applications and rich client applications are quite different. A rich client distinguishes between selection and activation. A typical user action would be to select a sales lead in a view, look at the preview for details, select another, and so on until the desired one was found. Then a double click activates the item and navigates you to the details. Although this would have been possible to implement, it would have been seen as unusual for a web application. Users of web applications are familiar with a single click performing the activation. Selection is usually done by browsing to where you wish to be and then activating the document.
Another example of a big difference between web applications and rich client applications is how a multiplicity of records is dealt with. In a rich client, there is no problem bringing up a view with thousands of records in it. Twisties can collapse and expand areas quickly, and the scroll bar can be used to hone in on particular sections. Again, although these things could be done with a web application, they would not be familiar and would have a performance impact. A more usual metaphor is the pager, which allows you to skip to different pages of information. But even this can be cumbersome, requiring many seeks and refreshes to hone in on your data like you would use a scroll bar. So, to solve the "discoverability" problem it was decided to supply the user with a variety of filters.
In the top of the left hand column (1) is a navigator like control. This allows you to specify the categorization of the data. This corresponds directly to the view used to display the main data. From this the user can determine the primary means that the data is displayed and the columns presented.
Directly under this are a number of twisties (2). Each of these presents different categories that data has been organized into. But instead of affecting the order in which they are displayed, these act as filters. For example when a Status of New is selected, only documents that have a status of new are displayed in the view. These are additive so that if additional constraints are supplied, they apply cumulatively. For example after selecting that the user wants to see New leads, they can then choose to see New leads from 3B Llamawranglers.
The filters chosen are repeated above the view in a status bar like control (3). This allows you to understand, at a glance, what is constraining the view. Additionally you can choose to clear that selection from the status bar. Allowing you to easily reset the view to the maximum data.
Lastly a search bar is provided (4). From the drop down you can select a specific field to search by, or if you leave "All" selected, it will do a full text search on your database.
Together these give the powerful ability to zoom into the data of interest without a large number of round trips to the server while the user pages through the data.
Conclusion
The business scenario, existing rich client applications and new web application have been introduced. We have discussed the areas which are important to make this a compelling, functional and efficient Lotus Domino web application. At this time, you should download the sample, deploy it on a Lotus Domino 8.5 server and explore what has been discussed. There will be further articles published using the Lead Manager XPages sample to demonstrate and discuss deeper details of the architecture and implementation. The sample is distributed on OpenNTF.org with sources allowing you to understand the architecture and review the implementation.