To give an update on the Active Wizard Enhancements we were working on last month, we recently finished up all development and testing of the Flex-based checkin/checkout interface against Documentum. We delivered to our client this week, but I wanted to share some of the challenges we ran into, specifically related to running an application using Flash.
Archive for the 'Flex' Category
One of our current Active Wizard clients is making the move from the classic ActiveFlow component of the Active Wizard to the new Flex-based ActiveFlow component, for filling out their forms. The Flex ActiveFlow is based on our AWLite product and as mentioned in a previous post, allows for a streamlined interface that is more user-friendly and intuitive.
Back in 2007, we started offering a presentation for clients, “What’s Next for Documentum?” The presentation focused on what mature Documentum clients are doing “next”. Typically, mature customers:
- have an existing production install of Documentum
- have implemented tools “out of the box” with some or extensive customizations
- have had some success
- ….and are looking for “What do I do Next?”
This post will share new, innovative or just different items we see our clients doing or considering for Documentum as well as links to other posts that depict their choices.
Documentum Upgrade – When?
When to upgrade is a difficult decision for many clients. Many existing Documentum clients are on paid support (version 5.3 or before) this year given reduced budgets, the cost of the upgrade, the effort of the upgrade combined with the difficulty of upgrading their application that either is unsupported or would require re-write to leverage the new Documentum interface.
For an overall upgrade understanding – try our Documentum Upgrade Planning Guide.
Look throughout blog.tsgrp.com for many posts including upgrade alternatives, extends versus modifies in 6.5, understanding the impact of WDK development, migration, clone or in-place upgrade, high volume server, common upgrade questions, and upgrading your application now to make upgrading Documentum easier later
External Users – Extending capabilities beyond the firewall
We have seen a push to add additional third parties or external users to Documentum. Typically this would be a related party responsible for creating of Documents. Interfaces are somewhat different in that, while they can create/approve documents, the interface should limit the third party from only seeing documents or completing a limited set of functions.
SharePoint – 2010 increases pressure on Documentum
SharePoint continues to be a major influence at the bulk of our clients. SharePoint users can be very vocal in their desire to “dump Documentum”. Clients struggle with wanting to satisfy SharePoint users but understand that a typical SharePoint environment focuses on collaboration with collaboration being very different from the current Documentum installation. Providing the scale, image and records management and maintaining indexing consistency are all requirements of most ECM systems and something that SharePoint 2007 can’t always accomplish. As Microsoft releases SharePoint 2010 with more robust ECM features, we would anticipate that this pressure would increase.
Look throughout blog.tsgrp.com for many posts including SharePoint Myths, SharePoint – Adding ECM Structure and Active Wizard/SharePoint Integration. Also, look for OpenMigrate to have continued support for a SharePoint source as well as the upcoming release to support an SharePoint target.
Documentum Software Audit – Managing Licenses
While this is not new in 2010, we but have steadily seen an increase in EMC Software Audits since 2005 with a big increase in the 4th quarter of 2009. Clients are getting better at documenting system usage and working with their sales reps to actively manage their license and maintenance costs.
Consumer Interface – Continued Focus
Multiple clients are continuing to look to push content out of Documentum for consumers. Whether tied to fault tolerance, performance, upgrade prep or licensing, many have developed strategies to push released content either with SCS or OpenMigrate to an external DataBase and file store.
Non Webtop Interfaces – Less Training – better Performance
Similar to the consumer interface, we are seeing more “non-Webtop” interfaces begin to proliferate at clients. Initially this was focused on image, workflow or improving Documentum search within Webtop. Recently, typical Webtop installations are looking to move certain users, like the consumers mentioned above, off of Documentum Webtop. This could involve just approvers (both internal and external) or offering a simpler author interface.
Lucene – FAST/Verity Replacement and DSS
Many clients are tired of “waiting for Documentum Search Services (DSS)” and have begun to deploy Lucene internally for either a cached consumer repository or Documentum itself.
Look for a post here on one client’s comparison of FAST to Lucene given their content and search scenarios.
CenterStage, Cloud, CMIS, Fatwire – what do these mean?
We have seen clients considering CenterStage, utilizing the cloud (ex: Amazon EC2), the upcoming CMIS specification as well as concern about recent Fatwire alliance. Most of our clients are taking a “wait and see” approach given the economy and some concern about being early adopters rather than followers. We’ve seen this same approach with the upgrade decision as well.
Other “what’s next” items include of Adobe Flex to create a better user interface, form and workflow enhancements, browser based annotation services and other items that will be posted here In the coming months . If you are looking for our 2007 “What’s Next” presentation, a Screencam with sound is still available on our site.
Clients who use the Active Wizard for forms and workflow systems often wonder if third party users or other users outside Documentum can participate in the form creation process. With our new Active Wizard Lite (AWLite) product, it is now possible for non-Documentum users can easily fill out dynamic Active Wizard forms!
We’ve seen the following scenarios over the past few months:
Anonymous External Users
One of our current Active Wizard clients is now using AWLite for filling out building permit application forms. Any user with internet access can fill out an Active Wizard form through AWLite on the client’s website. The potential user base is unknown, so it makes sense to fill out this form outside Documentum. Since AWLite simply uses a file system and SQL database to store form data, the client does not need to grant anonymous access to Documentum.
Third Party Form Creation
Another Active Wizard client gathers data and supporting documents from an external third party agency to create forms. Without Active Wizard Lite, communication bounces back and forth in order to gather the necessary data to create the form. With AWLite, however, the third party users can simply fill out the form outside Documentum. OpenMigrate is then used to move the data from the AWLite environment to Documentum, where the Active Wizard users can review the form, make any necessary changes and start the workflow:
Overall, TSG is very exited about our new Active Wizard Lite offering. Benefits of using AWLite include:
- Small back-end footprint – AWLite does not rely on Documentum. AWLite can simply use a server file system and a SQL-compliant database to store form data. This back-end architecture is much easier to setup and maintain, and can be achieved using entirely Open Source software.
- Licensing – in both of the cases above it did not make sense to add Documentum user licenses for the users creating forms. By using AWLite, the clients avoid needing additional licenses, while also avoiding anonymous access to Documentum.
- Next-generation interface – AWLite uses our next-generation user interface based on Adobe Flex. The flex interface is easy to use, interactive, and cross-browser compatible. Plus, AWLite behaves more like a desktop application – for example, server communication does not involve page refreshes and field validations happen in real time.
To see Active Wizard Lite in action, check out the Active Wizard Lite demo in the TSG Learning Zone!
At the end of the day, Flex is Flash; an HTML or JSP page will have a swf file embedded in it and the Flash Player plug-in will be used to render it. Until now, most of our Flex and Flash projects have consisted of either small components within a page, or the entire page itself. In both cases the default “wmode” parameter value has always been used: “window.” Integrating the WYSIWYG control within our Flex component required using a different wmode value: opaque.
In order to integrate the WYSIWYG control into our Flex component we had to use iframes and this is what necessitated the use of the opaque wmode value. A quick Google search for “Flex iframes” turns up quite an interesting selection. One of the top hits is a project on Google Code called flex-iframe. We actually wound up using this component as it’s quite robust and works well. However, the first hit is an article titled “Don’t Use IFrames for HTML in Flex” and lists reasons why using iframes and Flex/Flash is a bad idea. One of the reasons is specifically because it requires the use of the opaque wmode value and lists the following three reasons:
- Speed: There is no big surprise here, but when you force Flash to composite the HTML layers above and below, you are adding additional processor load.
- Accessibility: wmode makes your movie invisible to screen readers
- Inconsistent Performance
So what did we end up doing? Several things:
- To address the performance issue we wound up not embedding FCK in our form multiple times. Instead we embedded a simple html page that we updated when the user changed content. The WYSIWYG only appears when the user clicks in the html area, via a modal popup.
- The scrolling issue fix was easy to implement, however, thinking of it took a bit of time. We initially tried some of the suggested fixes posted on the JIRA page, but they didn’t seem to work us. Since the issue only affected the UI while the user was scrolling the page, we decided to simply disable “live scrolling.” That is, the user can move the scrollbar normally but the rest of the UI won’t update until the user lets go of the scrollbar.