As we have been mentioning her in other posts, due to the purchase Documentum by OpenText, many clients are looking at ways to reduce the risk of an unknown Documentum future. This post will look into the risk of the most popular Documentum interface, Webtop.
If you were to peer over the shoulder of someone using Documentum’s Webtop, you shouldn’t be surprised to see the exact same interface today as you would have seen nearly 10 years ago. Years ago, Webtop was going to be replaced with a variety of interfaces before Documentum bought D2. Rather than Webtop users getting D2 or xCP as an upgrade to their purchased Webtop licenses, Documentum pursued a greedy strategy of Webtop users having to “buy” new versions of D2 or xCP (and now Project Horizon). When Documentum was in it’s “hot stage”, many clients added customizations to Webtop to meet critical business needs. Faced with a purchase cost of D2 and redoing customizations, many clients have opted to keep Webtop (and their extensive customizations) and keep the aging interface.
Incremental updates over the last decade have done little to improve some of the biggest issues users struggle with, and with the recent acquisition of Documentum by OpenText, we aren’t expecting any significant changes. As many customers are looking to remove the risk associated with this aging platform, potential Webtop replacements should ideally solve some of these on-going struggles and risks that include:
1.) Outdated Webtop UX (Risk of User Adoption and Perception)
Over the past decade, the typical enterprise application user base has become increasingly web savvy. Users outside of the workplace have been treated to vastly superior user interfaces and experiences, raising the bar significantly for IT to deliver compelling solutions that are user friendly. It would be easy to call out every User Experience issue a current Webtop user has to endure, but in reality that would be an unfair exercise. When the core application has existed for nearly a decade, without significant investment in the application code base, any application should start to show its age. As businesses are pushed to accommodate a more mobile workforce, users expect access to the tools required to do their job, regardless of the device they are using. This is far more than just saying an application works on a mobile device (try opening up Webtop on your phone) – at minimum, making sure that users are not handicapped for having a modern secure browser. For users on modern browsers, their first interaction with Webtop (and perception of it’s age) is most likely the below popup:

2.) UCF (Java Applet for File Transfer) (Risk of User Support Issues)
While Webtop does support a normal HTTP file transfer (buried in the product and only available with configuration changes), the default method for downloading and uploading files is UCF (Unified Client Facilities). Documentum Administrators need no further explanation, but this architecture of using a java applet creates all sorts of dependencies from both the Java Runtime and Network Connectivity side. When working well, there is no issue, but when upgrading browsers, networks, PCs, or Java it is not uncommon to find UCF as the culprit of an issue and can generate a variety and large volume of different user support calls. Documentum announced that they are finally dropping of UCF for a Java free content transfer as one of the small updates to Webtop this year at EMC World/Momentum.
3.) Feature Overload (Risk of User Confusion)
When a product comes with such a hefty price tag as Documentum, the expectation is that the solution needs to be extremely feature rich to justify the expenditure. One of the most common UX traps Webtop falls into is attempting to be everything to everyone. Webtop as a one size fits all front-end has a lot of features that are not relevant to their user base. For many implementations we see, unused features are left available to users because removing them takes customization and additional cost to implement and maintain through upgrades. Most quality modern applications (or at least well-maintained applications) are created from the ground-up to emphasize configuration over customization. Webtop, given the older technology, has become very difficult to change for most clients, forcing them to sift through countless menus to find key functionality buried within the application. Giving users all of these features creates a dichotomy of governance vs free reign. With a standard out of box install of Webtop, generally users are allowed to create folders, sub folders move documents and create a similar mess one would see in a Sharepoint or network drive. It is only with customization, and much configuration to remove features and options to enforce proper governance and procedures.
4.) Advanced Search (Risk of User Confusion)
Webtop’s advanced search is just that, advanced. The average end users are often overwhelmed with the configuration of the search screen. There is a section for full text, a section for Object Type, a section for Non-Date Properties, Date Properties, File Size, Hidden Documents, Current or All Versions. While this is theoretically a powerful tool, it is information overload for a basic user. See our comparison of Webtop search to other alternatives. Effective enterprise solutions need to accommodate a larger array of end users. If a user is unable to easily use a tool’s core functionality that is supposed to make their lives easier, they simply won’t. This will cause spikes in user complaints and lower adoption of solutions – potentially pushing users outside of the solution and increasing the governance risk to a company. We often find users need a search that is somewhere between Webtop’s simple and advance searches. Generally there are a few key attributes needed to identify a document or small group of documents. We see our clients either customize the advanced search screen to display only those attributes, or seek an alternate search interface / portal which can make those searches more straightforward.
5.) Diminishing Support (Risk of Long-term Support – particularly for customizations)
Documentum, no wait EMC, no wait Dell, no wait OpenText support… needless to say, navigating this support maze is notoriously slow to get answers. As OpenText hasn’t officially taken over the support of these legacy products, it doesn’t look promising given the track record. Anyone who has worked through a Documentum case can commiserate on the process. You log your case and then within a day or so you get a call or email from a case manager. They will watch you reproduce the issue then request logs, traces, and all files involved. Often times several days go by and then ask for more logs or traces to buy time for their global distributed support team to investigate. When an issue is clearly a problem with Webtop and not a customization, we often open a case, but frequently we are able to find a workaround before Documentum support does.
As previously mentioned, any application that has been around as long as Webtop, can succumb to a variety of pitfalls. The real question is, at what point does an enterprise IT organization need to face the cold hard truth that the writing is on the wall for Webtop. If IT doesn’t make the right decisions, the users will begin to move outside of the system themselves, greatly increasing risk to a company. Removing outdated user interfaces is a great first step and beginning to reduce the risk of an unknown future for Documentum. Choosing a UI that can sit on top of any number of content management systems or exploring ways to begin to move content out of Documentum is the place to start.
Christine says
In regards to item number 2; UCF transfer and a client java dependency is alive and well in Webtop 6.8.2. What was removed was the applet that deployed and helped operate the UCF code. It was replaced with a browser helper object for IE and a plug-in for Chrome. The Chrome plug-in worked well for me ootb, however, the BHO was an entirely different story and took several calls with support to review my computer registry, IE settings, and my client Java install. We eventually got it working on my PC. (Note: there are now two exe files that need to download and run in order to install UCF on the client machine.) Unfortunately, we are having very little luck in getting it to run on another PC. The new content transfer install definitely needs more field testing. On the plus side, changing the configuration to HTTP transfer worked like a charm, but now Documentum Application Connector doesn’t work since it needs the 6.8.2 UCF files. (sad face)
Alvaro de Andres says
I would really like to know if EMC really stated that there would be a “java free” transfer, because as far as I know, that was supposed to land on Webtop 6.8.2 (tip: webtop 7.2 and a half) but what we got instead was the UCF removed from the browser to the users’ computer (instead of what mostly everyone expected, a HTML5 transfer mode)
jesus garcia says
It reminds me of the dark times of Desktop Client when you had to visit 5 users/day because the COM component with the customized properties page did not download, and then you had to delete folders, unregister and register dll, play around with the registry looking for a clsid…
Then we thought that with a web-based client that pain was all over… But ucf time-outs took the baton, showing up random and capriciously, making 10 year old experts look like newbies…