A rchive Date
[ 11-11-2000 ]
Category
[ Information Technologies ]
sub-Categoy
[ Lotus ]
|
[iNotes Web Access Is General
It's a product that exploits the Dynamic HTML [DHTML] capabilities of Internet Explorer to provide a very usable and enjoyable Web mail and information management experience within a browser without resorting to Java applets or ActiveX controls for its sophisticated UI [user interface]. It leverages and builds on the Domino server extensions added by QuickPlace to support more complex Web page generation. And it uses HTML elements to build its UI.
What were the goals of this project in general and specifically, what were the technological goals?
We wanted to exploit the rich HTML and XML Document Object Model within Internet Explorer 5 to build a very visually appealing and usable Web application that might be used together with the Notes client—perhaps only when roaming or traveling—or at the other extreme, might be the only client for those users looking exclusively for rich mail and PIM capabilities on the Web.
We didn't want to be constrained by the current Notes client user interface, but to bring a fresh new Domino mail and C&S experience to the Web, incorporating the rich calendar views, visual appeal, and the ease of use of Lotus Organizer. And we wanted to innovate further in this area.
We also wanted to address the current shortcomings of our existing Notes Webmail template, by delivering a superior and more enjoyable end-user experience; and it was important to be fully compatible with the existing Domino mail schema and allow Notes client access using this template.
Additionally, we wanted to leverage the work done by the QuickPlace group to deliver this application to the market quickly. And of course we wanted to leverage Domino Off-Line Services (DOLS) to allow this application to run off-line.
Tell us about the development history a little? What has been your role?
I was with the Lotus Organizer development team since Lotus first acquired it in early 1992. A couple of years back, I led an effort called Lotus Organizer Web Calendar that peaked my interest in Web development. During that time, Microsoft was touting the rich capabilities they were putting into IE, and I was very interested in exploring this to see if it really was possible to build a "rich" Windows-application-like PIM using these technologies. In other words, I wanted to kick the tires of this new development environment to see what really could be done.
But it was only after Organizer 5.0, where I was lead architect, and then helping out on the Notes client's editor team until after R5 shipped that I finally had time to prototype a Web PIM that exploited leading-edge browser technologies. From the start, it used Domino as the Web server. And I soon found out that the R5 mail applets were retrieving data from the Domino server in XML format. This was exposed to all developers in 5.0.2, and it became another cornerstone for my prototype. IE 5 has an XML HTML element (known as an XML island) that let me do what the applets were doing with DHTML.
As I took the prototype around to various development teams to try to get a real development effort underway, I found a lot of interest at Iris. Steve Beckhardt and Mussie Shore were particularly interested in building such a rich application within a browser that implemented mail and PIM features. They were very impressed with what I was able to accomplish within the prototype and asked me to come over to Iris to do this project. The early team was comprised of a mixture of developers from the Lotus Organizer team and from Iris.
That's the history. My official role on the product has been lead architect. I had a big role in building the team and preaching the "vision." Our development team is still a fairly small team, but one which is doing a super job in this space.
What was it like to set out to build a kind of product that hadn't been built before?
It was definitely exciting and very challenging. It also requires a fair amount of thinking "outside the box" and persistence to get over roadblocks. The biggest lesson I've learned is that a good prototype is critical when you're trying to do something radically different. It's important to not only help figure out how to best solve certain technical problems, but also to reinforce that your vision is really attainable. There's the old expression, "a picture is worth a thousand words." Well, a "working prototype" is essential to communicate your vision to others. It then takes a great team of engineers and a lot of hard work and dedication to actually bring it to market in a timely manner.
What were some of the architectural challenges you faced and how did you address them?
One challenge was putting together a development environment that would allow many developers to work on the product at the same time. iNotes Web Access has quite a broad set of features and so needs a team of developers to work on the single "template" at the same time. Doing this from within Domino Designer would have made the template a bottleneck.
Another challenge was to allow writing maintainable code that didn't incur a performance penalty. Some of the keys to writing maintainable code are to use descriptive identifiers and to comment the code well. However, since JavaScript is an interpreted language, both of these characteristics of maintainable code incurs a larger download and execution penalty.
In both these cases, it turns out that the QuickPlace team had encountered these same challenges and come up with the tools to overcome them. When I found this out, we were able to take their tools and enhance them a bit to meet our needs. To solve the first challenge, we use text-based files that describe the contents of our template. This allows us to use traditional development tools to write and maintain all our client-side JavaScript code. For the second challenge, we use an obfuscator to strip all the comments and remap large identifiers to very minimal character names. This is critical to get client-side performance and helps reduce the load on the server as well.
Let's talk about the technologies being used in a little more detail. Were there considerations in relating iNotes Web Access to our existing technologies that affected how you designed and developed it?
Definitely. As I mentioned earlier, we leveraged the tools the QuickPlace team first put together, and extended the server in a manner very consistent with what they had done. Also, the XML work by the Domino server team is an integral part of how we retrieve data from the server within our views.
How does iNotes Web Access relate to Domino/Notes technology? How do they work together?
iNotes Web Access consists of both client-side code—HTML pages and lots of JavaScript code that is downloaded to the browser as it's needed—and server-side code within the Domino Web server, which pieces together the many subforms and handles the HTTP requests triggered by various user actions. All the client-side code is stored within forms and subforms, which are located within a single database that is shared by all users on the same server. So iNotes Web Access is now an integral part of the Domino server and was built using existing Domino technology.
You mentioned Domino Off-Line Services (DOLS). How is DOLS technology being used?
DOLS is an integral part of the product. With most Web-based applications, you are limited to using them only when you are on-line. DOLS allows iNotes Web Access to be fully usable when off-line. There are very few things, such as Group calendars, that will not be available to you when you are off-line. You'll even be able to send mail, but the message will not be delivered until the next time you go on-line or use the DOLS client application (Lotus iNotes Sync Manager) to synchronize.
And your use of Dynamic HTML?
Dynamic HTML is actually a term that encompasses several browser technologies. It encompasses HTML, XML, CSS (Cascading Style Sheets), JavaScript, the HTML and XML DOM (Document Object Model) and the browser event model. These technologies together allow you to build very "dynamic" Web pages. All the pages in iNotes Web Access make extensive use of these technologies.
Are there really no ActiveX components or Java applets being used within the iNotes UI?
Almost. Besides the core ActiveX components, such as the rich text editor, which are already part of IE 5, the only additional ActiveX component we use is our custom upload control, which allows a much more Windows-like experience manipulating attachments. If you opt to go off-line with DOLS, DOLS uses a small ActiveX component as well to communicate the off-line state and interact with the Lotus iNotes Sync Manager.
If you're used to Windows 32 applications, you're used to a rich UI. Typically browsers provide a much less robust UI to work with. What were your goals in terms of the UI and how did you create a rich UI for iNotes Web Access?
My goal with iNotes Web Access was to give users the experience they would expect from a well-written Windows application. The goal was never to be constrained to say what typical Web pages look like. When you develop a Windows application UI, you have a set of standard controls that you can piece together to build various screens. When you consider implementing a rich UI within a browser, the equivalent to standard controls are HTML elements—such as the DIV, SPAN, TABLE, and INPUT elements. With earlier versions of Windows, the set of standard controls were much fewer than what is available today. The better Windows applications, in order to provide a better experience for users, built a library of "custom controls" using standard Windows APIs and the existing base set of controls. With iNotes Web Access, we have done exactly this. We have built a whole set of "custom components" by piecing together HTML elements and programming them with JavaScript and the HTML DOM. We are then able to use these in various places in our UI to make it much more usable.
So you start with the base HTML elements and then build larger more interesting components and screens with these. Windows programs employ an event driven programming model and so do browser pages. With Internet Explorer, it's also possible to influence the tab order between input elements, and add keyboard mnemonics and accelerators. Many of these improvements are within core HTML 4.0, which means in the future this will become a standard supported by all future browsers. In fact, we expect future browsers providing more rich capabilities and Web sites to provide more robust interfaces as a result.
Any details or examples of how you coped with the challenges the browsers presented?
We found that trying to build a UI on Netscape that parallels what we have done in Internet Explorer is very difficult. There are many HTML layout differences between Navigator and Explorer. Navigator also has performance issues with certain HTML constructs such as nested tables. Further, Navigator doesn't support XML islands, or the ability to add "onclick" handlers to any HTML element. So, for Navigator, we use a more server-intensive approach to build the view HTML and provide more "traditional" HTML mechanisms for selecting entries in a view.
The only way we found we could support Navigator without compromising our goals was to build a very different set of pages for Navigator. To provide an optimal experience on Netscape 4.7, we actually exploit the LAYER tag in specific situations as well.
How did you make the trade-offs when forced to choose between implementing a feature as it is done in the Notes client, versus implementing it in perhaps a new way?
We would take a close look at how the UI is implemented in Notes, Organizer, Windows, and a few competitive products; and then we analyzed what we liked and disliked about the various approaches. We'd keep in mind that the Notes UI in the past has been limited to what is possible within the construction capabilities offered in Domino Designer. Since we are exclusively using pass-thru HTML, we are not constrained in this manner. We are able to take advantage of whatever is available within Internet Explorer 5. We gave our UI designer a lot of freedom to innovate in this area, with the constraint that we had to maintain a compatible NSF storage schema. Certain UI decisions are also based on various performance or scalability implications. For example, we don't automatically display everyone's freetime when you click on the Schedule tab. We require an explicit click on the Find Freetime button.
Our team is composed of a mixture of people who have used Notes for many years and those who are very new to using the Notes client. Some of the liveliest debates within our team have been on various UI issues. Our overriding decision maker is usability. I strongly believe we have made decisions that make our interface more usable. We've also conducted several usability tests from which we've garnered good feedback and we plan to do even more testing down the road.
Over time, iNotes Web Access will replace the existing Webmail template. How is iNotes Web Access different from the current Webmail template?
Our template is actually built using the existing Mail50Ex.ntf as the starting point. This is how we are able to offer support for the traditional Notes client as well. We add certain new iNotes Web Access specific design elements to this template to support our UI. However, almost all of our design elements reside in a shared forms database that is pointed to by our mail template.
As far as features we support with our template in comparison to what the present Webmail template supports, the key additional features we are supporting today (or planning to support prior to ship) include:
- Unread marks
- Rich view management UI
- Jump to (or Quick Find) within a view
- Spell checking messages
- Helper controls to select dates, times, and to set durations
- Much improved support for attachments, including unlimited number of attachments and drag-and-drop files into the attachment control
- Very rich and usable calendar views, including double-click a date to create an entry
- Group calendar features
- Rich contact management UI
- Alarm notification
- Rich calendar printing that generates PDF files
- A Notebook capability (Notes Journal equivalent)
- Mail preferences that let you specify whether new mail will be on top or on the bottom and a check for new mail button
- Dynamic resizing of windows
- An out-of-office auto reply feature and work-hour/off-hour differentiation
- A Gantt-like view for tasks
- Customizable Welcome page
- Context sensitive help
- Secure log off
Most all of these were on the list of the most requested features that were not in Webmail, so we know they're important to users.
Are there any features in the current Webmail template that iNotes Web Access doesn't provide?
The only one that comes to mind is the support for managing mail rules. Any existing server-based rules that you may presently have in your mail file will still work, but our initial release will not provide a way to create new rules or edit existing ones. Why? We don't believe this is a feature that the majority of users take advantage of, so it wasn't as high on our priority list for features we wanted to make sure we had in our first release. However, the Out of Office agent was considered very important and is something that will be part of the initial product.
[Editor's note: For more details, you can check out the iNotes Web Access/Webmail feature comparison.]
What were the most difficult challenges in developing iNotes Web Access?
A few things come to mind. The first is our virtual list (or view) component. It is our most complex client-side component. Views are a big part of Notes, and bringing rich view management to a browser is a very unique feature we have. Traditional Web pages break up large lists into multiple pages. This new view component allows the user to manipulate all the documents in the view from the same page. Portions of the view are retrieved from the server in an XML format and incorporated into the virtual list as needed. You can even adjust the column width by dragging the column border. This is really cool.
Lastly, a big part of being a good PIM is to support rich calendar printouts. I've always been disappointed with the printing capabilities within a browser. PDF files have become a de facto standard for superior quality printing on the Web. The IRS [United States Internal Revenue Service] uses this format to make tax forms available to the public and just about every company uses this format to provide rich, printable forms for customers to fill out. Generating such form-quality printouts within HTML is just not feasible today. Hence, we have moved the rich calendar printing code in the Notes client over to the server and modified it to generate PDF files. This brings the richest possible calendar print formats to iNotes Web Access users.
From your perspective, what are some of the coolest technical achievements in iNotes Web Access?
I think there are a lot of cool features in the product. The view component and PDF printouts I just mentioned would both qualify. However, another really cool feature are our calendar views. As you traverse through dates using the next or previous arrows in the view header or the date navigator over on the left side of the page, the entire page isn't reloaded; rather the calendar is updated entirely by client-side code and only the data that belongs in the range of dates displayed is retrieved from the server. The month view also limits each calendar entry to a single line and adds ellipsis to indicate there is more information to be displayed. Resizing the window also readjusts the default dimensions of each cell.
Other cool features are multiple-selection and right-click menus within the view component, our tab control, which displays the different tab panels without a server round-trip. The ability to spell check mail messages is really cool as well. A lot of these features are pretty mundane and nothing out of the ordinary to most Windows application users, but the fact that these are available from a Web page makes it unique.
Let's talk about two critical areas: performance and security. What are your goals for performance? How did performance play into the development of the product?
There are really two aspects to performance—client-side performance and server-side scalability. Of course, we are striving to be the best we can be in both these areas. But there are trade-offs. The user experience is the primary goal, but there can be performance costs for a rich UI. Servers and clients will continue to get faster at a dizzying pace. A good UI already taking advantage of cutting-edge technology and poised to take even more advantage of technology on the horizon is the proper investment to make.
That said, we are quite conscious of both client-side performance and server-side scalability, and I can talk a little about what we are doing in both these areas. There are several things that impact client performance, including paying attention to things like:
- The number of total bytes downloaded from the server to the browser for the page
- The complexity of server-side formulas and logic to generate the page
- The total number of files that comprise the page
- The HTML and client-side logic needed to generate the page
To boost client performance, we strive to separate our "code" from the "data" as best we can. In this manner, most of our code is broken up into external script files, which are downloaded once and then very efficiently cached within the browser's temporary Internet files folder. Our JavaScript code is also obfuscated as I mentioned earlier to minimize page size and boost performance. We also make extensive use of cascading style sheets to reduce the size of the HTML and minimize the sizes of bitmaps on the page. We also try to minimize the need to reload the entire page in many situations, often just getting the new data necessary and building the HTML with client-side code.
Factors impacting server-side scalability include things like:
- The amount of disk access required to generate a page
- The amount of server-side computation required to generate a page
- The amount of contention among server threads processing separate requests
- The number of requests received from each user
To boost server-side scalability, we employ lots of server-side caching of forms and subforms that are shared across all users on the same server. Traditional Domino Web applications have form and subforms in each and every end user database that are not cachable across multiple users. Further, many of our static external files within a Web page are set up to be very efficiently cached by the browser. This should reduce the amount of requests to the server as a user continues to use the application. Lastly, we will be employing key caching of certain data constructs to minimize the computation required to generate subsequent pages and boost both client and server-side performance.
How did you maintain performance while achieving your other goals?
As I said, it's a trade-off and it's very tough sometimes. Often we implement certain features such as updating server-side unread marks or auto refreshing a view after manipulating a document in the view, and initially we might not consider how it might be done in a more efficient way. The users beta testing our product should know that there is much room for improvement here and in several other areas before we will call this first release done.
Using multiple windows within the UI is not only for usability reasons, but also benefits performance. We will also strategically use hidden frames to make some server-side change without having to totally regenerate our UI from the server. There are several client-side "tricks" we use to try to boost performance and scalability.
There are also certain DOM manipulation techniques that are more efficient than others. We have tried hard to generate DHTML in as efficient a mechanism as possible. Frankly, we have thus far spent most of our energy implementing lots of functionality. We are now about to buckle down and really concentrate on fine-tuning the application for performance and scalability.
What about security? What were the security issues?
The Domino Web server already has a suite of security options. We recommend that you employ at least session-level security within your Web mail servers, but we don't require it. If you opt to use basic authentication, you should know that the browser window caches the username and password, so subsequent access to the same mail file from the same window will not result in an authentication challenge. We offer a log off action that will actually log off the server session as well as try to close the browser window. Internet Explorer further has a security related preference to "Empty Temporary Internet Files folder when browser is closed." This setting in conjunction with closing the browser windows provides a little more security.
Like Webmail, we are also unable to read encrypted mail from the browser as we would need access to your private key, which is presently stored in your Notes ID file. Look for us to do more in this area in the future.
Looking beyond the first release, can you give us a sense of where the product is heading?
We'll continue to add more features. We'll probably add support for managing mail rules, editing calendar entries directly within calendar views, and various drag-and-drop capabilities throughout the product. We'll also look towards exploiting newer Web technologies, and of course we'll support more platforms as well as the next generation of browsers.
About Jason
Jason Dumont is the Director of Client Strategy & the iNotes Client within Lotus Product Management. In his previous role he was the Senior Manager of the ISV Development Team and was responsible for the strategy and direction of Notes and Domino as a platform for third-party developers. Jason has been with Lotus since 1991, where his first job consisted of sharing a cube with another worker while they stuffed form letters into envelopes. Glamorous, huh? Jason has a great deal of experience with the Notes and Domino application development environment and has been responsible for the creation of the R4 and R5 versions of the Notes and Domino Application Development Best Practices Guide and Inside Notes, documentation about Notes/Domino architecture.
A frequent speaker at business and technical conferences around the world, Jason holds BS degrees in English and Philosophy from the University of Connecticut. He also spent the better portion of the late 80s and early 90s playing drums in a number of professional touring rock bands. More recently he has been enjoying the return of the NFL season with his wife, Gwen.
About Vinod
Vinod Seraphin has spent the last year as a Software Architect within the Web Applications team at Iris Associates. He was previously with Lotus for eight years, where most recently, he was the Software Architect for Lotus Organizer. He has had key development roles within the Lotus Organizer development team since 1992. A portion of his final year at Lotus was actually spent at Iris, where he was on loan to the Notes client editor team to help fix ship-critical bugs for R5. Prior to Lotus, Vinod worked on a spreadsheet product at Access Technology and office automation products at Data General.
Vinod has an MS in Computer Information Systems from Boston University and a BS in Computer Science and Engineering from MIT. He also is an avid professional sports fan and enjoys softball, skiing, traveling, and spending quality time with his daughters, Audrey and Maddie.]
|