Web UI Design: Entity Centres
The sketches below represent a general outlook of the Web UI based Entity Centres. The main difference to the Swing UI based counterpart is in placing selection criteria and result on different tabs.
There are two types of selection criteria -- single or range. Singe selection criteria are used for specifying search constraints for properties of String and Entity types. They may accept one or more constraint values (e.g. autocompleter may accept more then one value).
In addition to the values that can be entered into a corresponding editor, single criteria provide support for expressing negation and missing values. These are called "meta-values", because they cannot be entered into the criteria editors as values. In order to enter them, users can use a configuration dialog as depicted in the figure below.
Range selection criteria are related to numeric properties, which includes date properties. These criteria consist of left and right bounds that are also ofter referred to as "from" and "to" bounds. Similar as for single criteria, they may have meta-values that allow providing additional constraint information for the search.
Several discussions took place with regard to responsive design of Entity Grid Inspector (EGI), which in the Swing UI was represented as a table. The general consensus is that the table representation (not covered in the Google Material Design) is still preferred for Desktop representation due to convenient inclusion of aggregated values such as totals and averages. The table design should be as close as possible to the general concepts of the Google Material Design (e.g. avoid vertical and horizontal lines to separate rows that leads to information overload; instead, row background alternation with sufficient space between columns would provide a much nicer flat-like design).
However, when the screen or window size is not wide enough to accommodate the tabular representation then EGI needs to transform its representation into a something that does not require horizontal scrolling that interferes with typical reading patterns.
The Google Material Design offers three possible alternatives -- lists, grids and cards. Out of these three, cards provide the most adequate approach as they are specifically designed to represent uniquely related data (such as properties of the same entity), and are typically an entry point to more complex and detailed information (such as Entity Master). Also, due to the fact that entities represent mainly textual information, lists and grids are not really applicable, while cards are optimised for displaying text and facilitating reading comprehension.
A reasonable example of the table design with transformation into cards is provided here. Unfortunately, it is not what's needed for EGI, but could be used for an inspiration.
In case of narrow windows and devices such as tablets and mobiles, the table representation should be transformed into cards-based representation.
The following sketches represent a cards-based approach to EGI design. It has several noticeable features:
- Entity actions at the top get grouped as drop down in case there were more than one action.
- Summary action appears in front of the export action, which when clicked brings up a summary dialog containing Entity Master totals.
- Instance specific actions get expended if they can all fit onto a horizontal toolbar at the bottom of every card. Otherwise, they should stay grouped as triple dot button.
- Each cards should have a header, where entity key and description are displayed. This mens that these properties should not be included into the body of the card. In case of composite entities it is best to include the composite members into the body of the cards.
- Each card should display only a limited number of properties (e.g. two rows with two properties per row). In case more properties are present, tapping on the card's header should expend the card vertically to reveal all specified properties.
- Only vertical scrolling should be supported, which means that information should nicely fit horizontally avoiding the need to to scroll horizontally.
