Navigator Concept

The central component within the current OpenMDM application for browsing the test projects, tests and measurement results and all associated meta data is the navigator which organizes all this data in a tree structure. This approach is suitable as many one-to-many relations exist in the test domain: One project contains multiple tests, each test consists of several test steps which lead to various measurement results.

As with the constant growing of the data the tree becomes more and more complex and confusing. To master the amount of data some features have been combined in a navigator toolbar:

The history feature is very powerful. The user can move to another node, view or change some details and be certain that he can quickly return to the previous node. This is possible out-of-the-box without needing to tag or place the node into the shopping basket.

In large trees the alphabetic and typed sort functionality can leverage the effort to find a special node, given that the name or the type respectively are known.

Sadly the buttons for the two sort actions have quite similar icons and thus are easy to confuse with each other.

The currently applied filters and the fact that filters are active are hidden behind a toolbar button. The user can not be sure without checking whether the navigator displays all potentially available data.

As another consequence quick changes of the filter parameters are impossible.

Furthermore the filter configuration dialog has some weaknesses concerning appearance and user interaction:

Too many vertical lines distract the user.

Unnecessary titled and untitled borders only add visual clutter to the dialog.

The filter value has to be entered in a textfield labeled 'Sample' (german: 'Muster'). The user would expect this to be an example expressing the syntax to be used. But then a non-editable label should be used for this informational text.

Before entering search patterns into the textfield it has to be cleared because the hint text is not realized as a placeholder but written into the textfield. This has to be done every time the dialog is opened which is quite tedious.

When entering filter patterns then wildcards supported but their usage is enforced. If only a substring of the node name is known, this string has to be enclosed with special characters (*) to allow multiple random characters before and after and thus produce a reasonable result.

No summary of the currently applied filters is presented. In order to find out all filters which are actually applied all types have to be checked.

Adapting a filter pattern for a given type means removing and typing it again which is quite annoying for the user.

In contrast to this clearing all filters at once is supported by an extra button in the configuration dialog.

The global search is the fastest way to get to the node of interest.

Even though it is a commonly used feature it is hidden behind a toolbar button.

The usage of wildcards is again enforced if only a substring of the node name can be entered.

The user can specify if he wants to apply a breadth-first search algorithm. But the dialog does not express what not checking this option means.

In order to fasten the search the corresponding dialog allows to restrict the search to the sub-tree below the currently selected node.

The number of nodes matching a certain search pattern is not indicated. The user has to click through all hits.

The dialog allows to jump to the next hit. But no jumping back is supported. Furthermore when all matching nodes have been visited the search cannot be restarted from the top. Instead the search dialog needs to be closed, reopened and the search pattern entered again.

When a node in the navigator tree is expanded then for all child nodes, even for leafs a plus icon is displayed making the user believe that also those nodes can be expanded. It is quite annoying for the user to find out which nodes are really expandable.

A highly sophisticated search module has been created for the OpenMDM 4 application.

It allows to load predefined search configurations, thereby distinguishing between system wide and private ones and those imported from the file system. Search configurations can be saved and saved with another name and deleted if no longer used.

In order to start a search the user has to specify which type of data sets he is interested in. This restricts the amount of available search categories (e.g. Project) and search attributes (e.g. Name) therein. For each attribute a pattern can be defined which must be matched or may not be matched, depending on the given operator. A dialog can be opened which lists all available values which have been found in the database for this attribute, which helps the user to enter meaningful values. The search result is presented in a table whose columns are generated from the defined search attributes. But the user can also manually exclude a search attribute.

Allows to load predefined search definitions. Thereby the user can differentiate between system-wide available searches, his own saved searches and search definition files available from the file system.

Current search specifications can be saved and saved with another name.

Delete current search (file) function can easily be confused with remove search attributes or clear search values function.

A confirmation dialog prevents the user from accidentally deleting saved search files.

User can clear search mask entries via context menu action.

User has to actively start search via toolbar button, context menu or Enter key.

After deleting all search attributes a reload of the saved search attributes is not possible. The search module needs to be closed and reopened.

Execution time and number of hits are indicated.

User can stop a long-running search.

Attributes can be ordered manually in search definition but not in result table.

Result table does not show the whole entity (e.g. test) but only those attributes (as columns) which were defined in the search mask. To get more information either the attributes of the searched entity need to be added as search attributes or the item of the result table needs to be added to the 'Shopping basket' and selected in the navigator tree. Then finally the item can be investigated in the 'Details' view which might also need to be opened first.

All possible values of a certain search argument are listed in a dialog, available via click on the cell in the untitled column.

Search attributes can be manually excluded from result table, so that no column is created for them.

Multiple similar named search drivers confuse the user. He does not know which one to choose.

A facet is a filter widget representing one category according to which the data of interest can be filtered. Usually the category correlates with an attribute of the data e.g. zip code when filtering addresses, but might also be an attribute of a related entity e.g. total population of the city. All distinct values of this attribute which can be found in the database are displayed in the facet along with the amount of occurrences.

The value in combination with the amount of occurrences is henceforth referred to as a facet item. When the number of facet items is too high then they need to be grouped and organized in a tree structure. For example all test engineers can be grouped according to the departments they work in or all production sites in Germany can be assembled under a node of this very name, which, along with other country nodes is placed under a Europe node. Dates and number values need to be gathered under nodes which express date and number ranges respectively. Thereby parent nodes aggregate the data set counts of their children.

A default facet item (e.g. named Others) has always to be available collecting all the values which cannot be assigned to a specific item e.g. because no value is given. Therefore checking the default option is a good way to find incomplete or outlier data sets.

By selecting a facet item the user can reduce the total amount of data to those data sets which match the selected value in the facet category. Multi selection can be applied by checking two or more facet items. The result set then contains all data sets which match one of the selected values. Selections are propagated to the opened facets on the right invoking a recalculation of the occurrence amounts.

Facet items with an occurrence count of zero are grayed out as they do not contribute to the data filtering and therefore should not distract the user.

For the same reason the widgets in the facet header are displayed transparent when they are not used. They become opaque as soon and as long as the cursor is hovered above the facet header or one of its widgets gains focus.

One of those widgets is a filter textfield which allows to filter the facet items. Entered text is matched against the facet item names. Thereby wildcards are supported but not enforced i.e. there is no need to add a wildcard character (*), but it does not harm either. In order not to loose the context the whole paths from the matching nodes to the root node have to remain visible. The nodes which only provide context are grayed out.

The facet toolbar features the following buttons:

The Facet Chooser is an animated panel which can slide into view when needed and shrink to a minimum size when the user shifts his attention to other parts of the application.

The Facet Chooser lists all facets available for data drill down.

For each facet a clickable link is provided stating the facet’s unique name. When the user clicks on it, the link is removed from the Facet Chooser and the corresponding facet is opened on the very right of all facets. Facet links may also be displayed in a tree view in order to group them hierarchically. Note that only leaf nodes would be available as facets, root and intermediate nodes would serve only to structure them.

The Facet Chooser is placed on the left side of the facet container. To let the panel expand to the right no click is needed - simply hovering with the cursor above the panel is enough. As long as the cursor stays above it, the panel remains in this expanded state. In order to keep the Facet Chooser from minimizing again, it can be pinned by clicking the corresponding toggle button in the panel header. Clicking the toggle button again reactivates the default behaviour.

Additionally the panel header contains a filter textfield allowing to reduce the amount of facet links displayed. Wildcards are supported, but not necessary. The filter is case-insensitive.

All widgets in the panel header are displayed slightly transparent by default. They become opaque as soon and as long as the cursor is hovered above the panel header or one of the widgets gains focus. Thus the widgets remain available but do not distract the user’s eye as long as they are not actively used.

The toolbar above the result table provides quick access to features commonly used when working with tables in the OpenMDM application. These features are convenient even if no facets are used.

A filter textfield allows to enter the name (or parts of it) or the unique id of a data set. This is a first suggestion, presuming that all data sets provide a name attribute. It may also be useful to allow filtering for vehicle ids - this has to be discussed with the application end users. User tests revealed that also date values like Today and Yesterday as well as workbench and production series ids, clerk names or V-numbers are search candidates. In any case the textfield should learn the search terms and suggest them automatically when the user begins to retype them.

When clicking the ClearAll button in the toolbar the filter textfields in the toolbar and in the facets are cleared as well as all facet item selections. All currently opened facets remain open but do not apply any filter and therefore the result table lists all data sets.

The Search Configuration Chooser is an extended, filterable combobox which allows to load and save facet component and table compositions. This comprises the opened facets, their order, facet item selections for each facet and the toolbar filter textfield entry, as well as the table state (order of the columns, column sort state, visible and hidden columns, column widths). At least one system wide default composition will always be provided. The default compositions will be negotiated with the OpenMDM application end users. Compositions can be switched by simply selecting another item in the combobox. A special menu entry serves for saving the current facet component and table composition. Please refer to the Appendix for more information.

Another toolbar button allows to export the result table content. It is desired to allow different data formats such as ATFX.

Finally an options button hides all rarely used features like managing or publishing saved layouts for a user group.

The result table will provide a filter row (right below the table header) so that the table can be filtered according to each column separately with type specific filter widgets. For example a column displaying date values will provide a filter widget allowing to enter a time period which the data sets have to meet in order to be kept in the table. The specification of those widgets is out of scope of this document.

Via double click on a row in the table a separate details view for this data set is opened. If such a view is already opened for the data set then it is moved to the front. This makes the history functionality obsolete. For all data sets which are of interest detail views can be opened which themselves serve as bookmarks.

When closing the application the currently applied facet component and table composition shall be stored and reapplied on the next restart.

The facet filter mechanism can be enhanced even more by supporting OR, AND and NOT concatenation of facet items within one facet. Multiple visualizations and interaction concepts are thinkable, such as:

The new concept implements the strengths of the navigator and search module of the current application, omits their weaknesses and moreover provides several benefits:

One interaction pattern can be used for both exploration of and search for data. Thereby all possible values with their occurrences are presented to the user immediately and still he can drill down and filter for a special entry. The user will never have to guess which data formats apply.

Furthermore outliers and missing data values can be identified very quickly. As indicated special facet items are reserved for this.

As each facet can provide a tree view of facet items, the user can combine as many 'navigators' as he wishes. He only needs to add further facets if he needs them to shrink down the number of items in the result table.

As outlined above, the parts of the user interface currently not needed are made transparent - they are still one mouse click away but do not distract the user from his goal. Other, less often used functionalities are hidden behind option buttons.

Facet item trees inside the facets will not get very large and are sorted alphabetically by default so that there is no need for a sort by type or creation date.

Wildcards are supported, but not enforced.

As the amounts of matching data sets are indicated with every facet item the facet component also allows statistical analysis. Managers could use the OpenMDM application to evaluate e.g. which tests were executed on a certain unit, which unit was involved in which test project, which tests were created but not yet ordered by colleagues XYZ or UVW, how many tests were executed on workbench ABC today, how many tests are included in project MNO or how many tests are ordered but not yet executed.