Earlier this year, we posted about HPI Search compared to Documentum Webtop and D2 as well as our thoughts around some of the technical issues with D2. For this post, we thought we’d take a closer look at the options for search with D2 as compared to HPI.
Both D2 and HPI are highly configurable interfaces. In the examples and video below, we’ve configured both systems for the purposes of the discussion here, but there are many ways to configure both tools.
D2 Workspaces
Before diving into the D2 search component, it’s important to understand how D2 workspaces work. Essentially, an administrator can expose a set of widgets to a certain workspace. For example, the “HR” workspace could look a lot different than the “Policy & Claim” workspace. Then, in the D2 configuration tool, the administrator can restrict workspaces based on group membership in Documentum. For the purposes of our discussion of search, this means that the administrator can target certain document types and search widgets for a given workspace.
D2 – Search Widget Options
As described from the search overview post mentioned above, D2 ships with a few different types of search widgets. To recap:
- Quick Search – can be configured to be full text search or search against specific properties
- Search Form – Performs a search using a pre-configured form
- Advanced Search – Similar to Webtop “Build a Search”
While these search options are a welcome addition above what was present in Webtop, there are still a few issues we see with the D2 setup. More on these in the video later in this post.
- Advanced Search – as mentioned many times on the TSG blog, we feel that the “build a search” interfaces are too complex for most users. See the video below for more details.
- Search Forms: Simple, yes; Powerful, maybe? – These Search Forms are probably the most comparable type of search when looking at D2 vs. HPI. In both cases, the administrator configures a simple form to place in front of the user. In the case of D2, creating a simple search form is certainly possible and works well within the D2 interface (ignoring the workspace overload section discussed below). However, once you start trying to make these search forms more powerful, the complexity of configuring the widget in D2 increases quickly. Some examples:
- When configuring the search form, you must define DQL or xPlore settings to run the query on the back end. In either case, you pull in values entered by the user by utilizing the convention – $value(my_attribute). However, there’s no way to include an attribute only if it’s populated by the user in the form. This leads to one of two scenarios: 1) simplify the form by making all fields required or 2) perform some configuration acrobatics to handle the case where a value is blank. D2 allows you to configure “defaults” for fields not filled out by the user. This means that for a string field, for example, you could provide a default of ‘%’ and configure a LIKE search on that particular attribute.
- Date fields are simple to configure if you want to only search on a single date. However, the configuration complexity goes up if you want to configure a date range search, and goes up significantly if you want to mimic HPI’s Proximity Date Search.
- Saved Searches – From what we’ve seen in D2, only searches created with the Advanced Search tool can be included in the Saved Searches section. Additionally, the interface to add a saved search is somewhat cumbersome. See the video below for more details.
- Search Column Preferences – While it’s possible for the user to change their column preferences for search results, the process for doing this is cumbersome since the user must decide on the columns to view before executing the search.
- Refining Searches – while this is a minor thing, we’ve always been advocates of keeping the search criteria visible to the user after executing a search and displaying the results. In D2, it’s possible to get back to the search criteria, but the method to do this is not apparent. More in the video below.
Workspace Overload
If your workspace only deals with a small number of types, the D2 configuration should largely be fine for your needs. However, if you have many different types, it is very difficult to get a clean search interface to fit in one workspace. If keeping a clean interface is paramount, a user would have one “Search Form” type widget containing his / her most often utilized search, with the rest of searching on other types falling to the user-unfriendly “Advanced Search” widget. More in the video below.
D2 vs. HPI
Check out the video below that overviews the topics discussed above and compares D2’s approach to HPI:
Summary
Overall, we feel that while D2’s interface can be configured to be streamlined for a given business purpose, HPI still does a better job at making search both powerful and easy for users to learn and use over time. D2 also comes with a separate per-user license cost to implement, whereas HPI is free to TSG clients, who have access to all source code.
