The User Interface

Among the many client-side components of the Veriquant Framework is a base user interface, a browser-like slate, which developers can use or ignore. Its power is best realized when used with the Framework’s EAV/CR component.

A tree control running down the left side of the slate forms the foundation of the Veriquant Framework user interface. From here data of all kinds is searched, displayed, linked, navigated, referenced, edited and otherwise acted upon. This tree intersperses many object types on a single surface in a way that maps the relationships between them. For instance, the tree could present a list of patients, and indented under the patients it displays lists of claims associated with those patients, and indented under the claims, service lines. Each node on the tree is labeled by its role name and representative values from that node. In a very small surface area, the tree provides a tidy and intelligible map of diverse data (possibly many indentations deep), with each node on that map representing more detail below the surface. Once the map is laid out (usually by the user opening up selected branches under certain nodes), any node on any branch can be accessed directly from the same surface, without burrowing, reburrowing, or unburrowing (backing out) through layers of windows.

This is why our clients love our tree. Without it, each list type would have to be presented as a complete grid in its own right, with its own set of column headers, either on separate windows or nested on the same window, with child column headers confusingly arranged under parent column headers or tucked away under multiple tabs and thus on multiple surfaces. Even then there is only so much branching that such an approach—necessarily hardwired—could practically accommodate. There are cases where nested grids are appropriate—and the Veriquant Framework uses them in selected cases—but there is nothing like having a tree undergird the entire application user interface. There is no other way to represent so much so clearly, so flexibly, so directly, so accessibly and so comprehensively on one map surface.

Flexibility is a huge asset afforded by the tree. Because the underlying architecture is based on a graph of nodes, tree behavior and available branching and navigation is determined by metadata settings and database nodes, by not hardwired program code. This opens the way for navigation along any legal path and to any indentation depth, impossible with other standard user interface data access controls.

Data list items are brought to the tree by (1) using the query tool, resulting in one or more items appearing on the tree, (2) navigation from one entity to attached entities, (3) creating new items, and (4) by programmatic output from reports or other processes. The fourth method means that a user can send to the tree individual items or entire categories of items from grid-based reports, meaning that any report item can be drilled to its ultimate detail and context. The fourth method also means that processes other than reports can place entire categories of items on the tree, such as rejected insurance claims. Once an item is on the tree, all associated details and links are immediately available. This is a powerful use of a powerful device.

From any node on the tree, context menus provide navigation choices to related nodes, creation choices for new related nodes, custom process invocation choices, and so on.

Because of its EAV/CR component, a single search grid affords access to all entities, whether qualified or not qualified by their immediate hierarchical context. The grid columns include a label, an operator (such as equal to, greater than, begins with, ends with, contains, is null, is not null), and a value. Rows in this grid represent each attribute item assigned to a logical table (object type). Rows of individual attributes can be duplicated such that two or more search criteria can be assigned to a single attribute type, as in declaring a range of values. The underlying search manager determines the user’s intended criteria nesting logic automatically in most cases, but also allows the user to specify her own criteria logic tree. Query results are sent, with appropriate labels, directly to the slate tree. Conventional applications would compel the user to initiate direct searches to a few fixed types and then drill from there to neighboring entities, usually by means of layers of windows. Not so here.

Again because of its EAV/CR component, creation, display, and editing of all entity types is possible by a basic editing grid, with columns including a label, value, value description, updated (or created) by, and update date and time—this for all entity types. Programmers do not need to design fixed screens for each entity type, nor do users need to learn scores of screens to get their work done.

Developers not utilizing the Framework’s EAV/CR component nor its base application slate can still use the Framework’s rich grid management metadata to specify in data, rather than in code, the columns, column order, column behavior, column captions, column width, data bindings, code-to-description translations, column input tools (combo boxes, ellipsis, etc.), sort order, grouping logic and more.