Blue Fish: What is your official title and responsibilities at Documentum?
John: My title is Director, Application Architects. My team consists of user experience designers and product designers. Our responsibilities are to work with product management and developers within Documentum to define functionality and behavior of Documentum products that have a user experience. We also look to rationalize functionality across products so that all products do things in a consistent, understandable way.
Blue Fish: How long have you been with Documentum, and specifically in this role?
John: I have been working with Documentum technology for 11 years and I have been with Documentum for over 6 years. I joined engineering in this role about 3 years ago. Before joining engineering I was in consulting at Documentum and prior to that I was a principal at a document management consulting firm, WMI, that Documentum acquired.
Blue Fish: What are the goals of WebPublisher 5?
John: Our primary goal in developing WebPublisher 5 was to get onto the WDK platform and leverage the Webtop user interface. In doing that, we had several objectives:
- maintain current functionality from previous versions of WebPublisher
- make it very easy to migrate from previous installations of WebPublisher to WebPublisher 5
- increase performance
- ensure it interoperates with other Webtop-based applications
Blue Fish: What new functionality is included in WP5?
John: While we have a long list of desired new functionality, the amount of net-new WCM functions is relatively light in this release as most of our effort has been focused on migrating to the new WDK framework and increasing performance. However, we were able to get a couple of new functions that we think will be of great benefit: link management and taxonomy support.
For link management in this release we will automatically link objects together when they are assembled in the WebPublisher Editor and we will allow users to manually link objects together through a relationships page. When promoting an object (either individually or within a change set) that has links we can automatically promote linked objects. We will also inform users when moving, renaming, or deleting objects if there are linked objects that may be affected.
For taxonomy (or categorization) support, we will allow users to create taxonomy structures and link objects to those structures. This structure can be exported to the web site to drive menus on the web site, other navigation mechanisms, or just to help search. We build the taxonomy model based on our Content Intelligence Server (CIS) model, so in subsequent releases of WebPublisher we will add support for automatic categorization or workflow-based categorization.
Blue Fish: What are you most excited about in this new version?
John: I think that our users will appreciate the Webtop-based user experience when doing web content management. They will have access to different views (like our simple streamline view or more powerful “classic” view) and will have very easy ways to navigate around the system. Also, by basing the product on Webtop, as it continues to add usability improvements and additional functionality, WebPublisher users will be able to take advantage of them immediately.
For our users with global content management requirements, WebPublisher 5 is completely Unicode, which will allow users to enter values in properties or content in any language, regardless of the language on their own machine, the language of the application server box, or the docbase server. This will make setting up a global environment much simpler and adding or translating content will be very straightforward.
In addition to the user experience and multi-lingual improvements, we have also made dramatic improvements in performance, but I’ll talk about that more later.
Blue Fish: Have there been any improvements in the WebPublisher Editor in WP5?
John: We completely re-wrote the Editor in this version from the older AWT-based technology to a Swing-based architecture. It provides a much faster, less memory-intensive, and more modern-looking editor. We kept the same Content XML/Rules file/XSL stylesheet setup underneath for continuing compatibility. All current widgets and files will be supported unchanged. The Editor is also fully Unicode-compliant, so any language can be entered in the widgets (or even combine languages in the same widget).
We have enhanced some of the widgets as well. Users can copy & paste from Word, for example, into the content widget and all the formatting (including tables) is retained. Users can also drop into “text” mode in the content widget, add any html code they want, and then go back to WYSIWYG mode. We have also improved the “repeatdef” widget, which allows users to enter a variable number of elements or groups of elements, to support nesting, so it can more accurately represent XML structures.
Finally, we have introduced a custom widget framework into the Editor so customers and/or partners can add their own widgets into the Editor. We will ship with a sample or two to get you started.
Blue Fish: Will there be any enhancements to WebCache functionality tied to the release of WP5?
John: The functional enhancements to Webcache are pretty limited, but we did a lot of work on performance. We can pass multiple objects to WebCache in one call at it publishes them in a single action. Webcache also takes advantage of the method server that is now part of Content Server 5 to eliminate the “ramp-up” performance lag there was each time a publish event happened.
Blue Fish: Can WP5 integrate with an application server for previewing content?
John: We did not make any changes to the web view functionality in WebPublisher 5 from previous versions of WebPublisher since we want to stay application server-neutral, but since we are on the WDK framework and have implemented all our logic as business objects, a customer/partner can easily extend our OOTB web view logic to include their own based on a specific app server.
Blue Fish: Some people complained that the old WP GUI was sluggish. Are there performance improvements to the GUI in WP5?
John: We have made significant strides in improving the performance of WebPublisher 5. In consultation with our performance and scalability group within Engineering, we established performance goals from the beginning before we wrote a single line of WebPublisher 5 code. We focused on three areas of performance:
- Response time – the duration between the time a user initiates a function to the time they can continue working
- Latency – the duration between the time a user initiates a function to the time a function is done
- Throughput – how performance is affected when multiple objects are acted upon at the same time or multiple users are on the system concurrently.
We have built an asynchronous framework within WebPublisher to allow for offloading time-intensive operations to a background process while allowing the user to continue working.
We do performance and load testing on each build and we are very pleased with the results so far. Most operations will have a response time in the <3 second range (regardless of the number of items selected) and latency in some cases is an order of magnitude better than prior versions of WebPublisher.
To give one brief example, promoting a change set with 10 files attached in our latest WebPublisher 5 build has a response time of 3 seconds and a latency of 13 seconds – this means the user can continue working after less than 3 seconds and the system will inform them in 13 seconds that all files are promoted and published to the web site.
Blue Fish: What are the main advantages that WDK-based WP5 has over rightsite-based WebPublisher?
John: Well, we get a lot of benefits just being on best-in-class application servers that can manage memory and performance in optimal ways. This will allow us to support many more users in the same application server footprint compared to previous versions. As I mentioned above, in general the performance of a WDK-based application in much superior to a RightSite-based application, and the ability to spawn background processing (something that was not possible in RS) provides even better performance.
I also think our customers and partners will enjoy being able to customize any aspect of WebPublisher by using a standard set of tools and methodology.
Finally, the WDK framework allows for much more flexible role support. We will continue to ship our four default roles we have always shipped with WebPublisher: Administrator, Site Developer, Content Manager, and Author, but users will have the option of either altering the functionality associated with our roles or they can make their own roles with unique combinations of functions.
Blue Fish: Your team was one of the first internally to use WDK. What were some of the things you learned from that experience?
John: I turned to Chee Wong, our Principal Engineer for WebPublisher, for his comments:
“The experience so far has been positive. A few things that we learned from using WDK:
- The out-of-the-box UI controls are extensive in breadth and depth. There are “attribute” controls that are Data-Dictionary aware, which means that the controls would provide the constraints and apply the necessary validations as specified in the Data-Dictionary.
- Web Form technology (the lowest technology layer of WDK) seems like a good fit to build web-based UI; it facilitates nicely the separation of UI from application/business logic and a VB like event-driven programming model.
- The design of the framework is well structured, layered and thought out; it provides a very simple and flexible application/component configuration model. In conjunction with the web form technology, the framework facilitates and encourages reuse at the control as well as at the component layers.
- The functionality of the framework and infrastructure are extensive: state management, navigation management, client-side event handling, menu/action system, messaging service, tracing, i18n support, branding (skin) engine, etc. are all provided OOTB.
- The dynamic HTML based control framework allows us to present a much more sophisticated experience to the user than we were previously able to do.”
In addition, he had a couple of things to be aware of:
- “A developer would probably need the “toolkit” version of WDK in order to extensively customize the components (you don’t need it for the controls).
- Because the framework and infrastructure is very flexible, rich and extensive, the learning curve can be a bit steep in the beginning. But be patient with it and you’ll be rewarded by the benefits (that I mentioned before) that it brings to the web application development lifecycle.”
Blue Fish: What is the upgrade path like for existing applications using WebPublisher? How rapidly do you think that users will switch over to using the new one?
John: We kept the same underlying object model in this version of WebPublisher 5. This means that existing site cabinets, folders, objects, templates, rules files, stylesheets, workflows, and lifecycles will work exactly as before. We did change a couple of things to match with the Webtop way of doing things (e.g. changing our “favorites” to Webtop “Subscriptions”) but we provide upgrade scripts to do the conversion.
The upgrade path should be straightforward and we are placing special emphasis on upgrading from prior versions of WebPublisher in both our system testing group as well as with customers and partners in our beta program. The only known part of a WebPublisher 4.x system that is not completely compatible is any customizations to the RightSite user interface. To address this point we will be publishing a document as part of the documentation set for WebPublisher 5 that lists out common RightSite customizations and their equivalents in WDK/Webtop.
Blue Fish: In the past there have been issues with content created in non-WebPublisher clients being inaccessible via WebPublisher. Are there limitations to using WebPublisher in a multi-client environment where some users use WebPublisher 5 and others use Desktop Client or Webtop?
John: No. We spent quite a bit of time making sure that Webtop and WebPublisher interoperate. In WebPublisher if you select a non-WebPublisher cabinet, the system will behave as if you are in Webtop with the standard (or customized) content management functions available. If you select a WebPublisher object, then the WebPublisher content managements functions will be available.
We also added functionality in the server to support the reverse scenario – we tag all WebPublisher content with a WebPublisher “application code”. This will ensure that non-WebPublisher applications can view (but not accidentally edit) a document under WebPublisher control. This interoperability feature can be disabled by the customer if they wish.
Blue Fish: Is there internationalization support in the xml editor applet, both for creating multi-byte content and for internationalizing the applet and its components?
John: Yes. One of the key benefits of moving to a swing-based editor is the full internationalization support of entered content. The content will be encoded and stored in UTF-8 automatically. You can mix and match languages of different code pages on the same document, if you wish.
In fact, this is true throughout WebPublisher 5 – you can view and update properties in any language you wish regardless of the operating system language of your desktop, the application server machine or the docbase machine.
Blue Fish: What are the new controls available in the xml editor applet? Is there better support for performing docbase lookups for relating content (such as a better image picker than existed in Web Publisher 4.x)?
John: We did not add any new controls to the Editor in WebPublisher 5, but we did carry forward the “xselector” introduced in the latter versions of WebPublisher 4.x that allow for pre-compiled queries to be used with a more interactive query approach.
Also, as I mentioned earlier, any customer or partner can add their own widgets or extend the ones we ship to meet their specific needs.
Blue Fish: Does DCTM have a recommended approach/pattern for deploying dynamic content created via WebPublisher? What is the strategy for keeping code (Java/COM) and content (JSP/ASP) in sync throughout the publishing process to WIP, Staging, and Active sites?
John: I asked Chee Wong, our Principal Engineer, for his thoughts on this question as well:
“I would break the process into two phases: development and deployment. In the development phase, the source code is best managed and developed in their native environment: source code management system and IDE. However, the developer could utilize Web Publisher to provide or periodical refresh the content part of WIP sites. In this method the “target” or the “output” path (for COM objects, java classes or jar files) of the IDE will point to the same WIP sites.
Once the development phase is completed, the “target” or “output” artifacts could be synchronized back to docbases using Web Publisher and deployed out to the staging or active web sites. Also the developer can also establish relationships among content and code (COM objects, java classes or jar files) either via change sets or the new link management functionality in order to ensure the integrity of the web sites.”
Blue Fish: What can we expect to see in future versions of WebPublisher?
John: We are looking forward to increasing the usability, performance, and functionality of future versions of WebPublisher. There are several specific enhancements that we have targeted for future versions, including re-publishing changes to XML content templates and continued improvements in the WebPublisher Editor. We also are looking forward to enhancing our new features introduced in this version, link management and taxonomy support. You can also expect integrations with collaboration functionality, portlets, and better workflow management.
Blue Fish: Anything else you would like to add?
John: The whole product team is excited to be getting this updated version of WebPublisher to our customers soon. We think our customers will enjoy the improved user experience, performance, and flexibility of the new product. Developers will now have the ability to extend any aspect of the application or Editor to meet specific customer needs.
Thanks for letting me talk to your user community about WebPublisher 5.
