Table of contents
We see "Personalization" in the majority of applications and services that we use today - from Google's iGoogle
to the functional preferences of this Wiki. Application personalization can provide users with function and features specific to their needs and help facilitate ease of use. In this section, we discuss the best practices for providing user personalization in Domino Web applications. We recommend that you have a firm understanding of the Web Browser Client Environment
, and general Domino Web development practices.
Lotus Notes Client developers are familiar with the practice of creating a preference document, either unique to the application, user community, or a specific user, that facilitates functional personalization of the given application. This is typically accomplished via Profile document
. As we look to expand our Domino applications to the Web browser and mobile client environments, we must consider the known [Domino HTTP Task] caching issues that surround profile documents
, and look to a more multi-client friendly personalization architectures.
To facilitate such functional requirements, we can architect our Domino applications so that they use user profile and preference documents. These documents, which are keyed to the application, user community, or to specific users, contain information that facilitates application personalization.
Due to the known issues with profile documents
and applications delivered via the [Domino HTTP Task], the alternate usage of Notes documents to maintain profile document-like information can require additional resource usage and "chattiness" between (for example) the Web browser client and Domino applications.
To alleviate costly round-trips to the Domino server to confirm application and user preferences (via runtime lookups to Notes documents acting as profile documents), we can use the local client environment, via HTTP cookies, to locally access user and application preferences.
We can architect and design our Domino Web applications to store user profile and preference document data in HTTP cookies. These same applications can use the local HTTP cookie data throughout the session (or future sessions) with the Domino server. The lack of HTTP cookie data or otherwise missing or logically outdated data can trigger the recreation or updates of the local HTTP cookies.
By using HTTP cookies and a profile stored in a Domino database, you can get a robust tool for handling personalization. For example, you can use a WebQueryOpen Web to store a document in a profile database and store that document's unique document ID in the user's HTTP cookie. The beauty of this approach is that you can start gathering preference information on the user, even before they have registered.
If you have a shopping basket or a favorites feature, you simply add a child document to the user's profile in the profile database, using the unique document ID from the user's HTTP cookie. When the user needs to register, you can POST this information to the user's profile in the profile database, using the unique document ID. During registration, be sure to request the user's e-mail address and a password.
If for any reason a user loses their HTTP cookie, you can ask them to log in. This would not be Domino authentication, but the "Login" form would perform the following actions:
- Look up their profile in the profile database, in a view sorted by e-mail address.
- Verify the password.
- Reset the unique document ID back in the user's HTTP cookie.
This development methodology and applied technique not only addresses the aforementioned "chattiness", but can also streamline and enhance the user experience.
We invite you to add more of Domino personalization techniques or best practices here.