Web UI Design: Entity Masters
Everything in TG is modelled by means of fractal objects -- an entity and its companion. This includes entities that model both nouns and verbs in the target domain. So, objects like Work Activity and Purchase Order, but also processes like Purchase Order Authorisation and Issuing of Part to a Work Order are modelled as entities. Each entity may have its own Entity Master through which it gets created and modified. Basically, entity masters represent the main way to organise a UI for users to modify the state of an information system. Therefore, it is very important to understand all of the building blocks for constructing Entity Masters and the ways to interact between them at the client side, and also them and corresponding web resources.
- Kinds of Entity Masters
- Simple Entity Master
- Compound Entity Master
- Multistep Entity Master
- Entity Master Actions
- Property action affordance
- Entity action affordance
- When actions should not be executed?
There are two kinds of Entity Master, each operating in their well defined and very specific way.
Simple Entity Masters should be used to represent an entity without dependent entities or a dependent entity itself. For example, a majority of table code entities have no dependent entities and can be conveniently represented using a Simple Entity Master (e.g. entity Address or Rego).
At the same time simple dependent entities can also be represented using Simple Entity Masters. For example, WaDirectCharge is an entity that attains its meaning strictly in the context of some WorkActivity, has no dependent entities and can be conveniently represented as a Simple Entity Master. However, in this case the master should carry the information about a corresponding master entity (Work Activity in this case). This information is critical for both validation and persistence of dependent entities.
Simple Entity Masters could be displayed either in a modal or normal way. The modal way usually has a very specific purpose of either providing a quick preview of some entity or create a simple entity ad-hoc, or provide data for some action (and thus execute that action). A Simple Entity Master in a dialog form should only have two buttons -- CANCEL and OK -- and should always be displayed in the EDIT state. The OK button should correspond to action Save with appropriately defined POST-SAVE action. The CANCEL button, should simply close the dialog and fire the POST-CANCEL event.
Compound Entity Master should be used to represent complex entities -- those that have a master role in one-2-one and one-2-many associations. Such masters are equipped with a menu that provides a way to navigate between their compound parts. The depth of the menu should be limited to one, consisting of the top level and the level below at the maximum. This constraint will ensure simplicity of the navigation system from the user perspective under assumption that it should always be possible to arrange Entity Master menu in this way.
The way to represent one-2-one association should be as per Swing UI, where a separate menu entry is associated with panel with located on it editors for properties of the dependent entity. It can be thought of as an embedded simple master, provisioning for standard and custom actions.
The one-2-many association should be represented by a Custom Entity Centre with ability to edit and add new dependent entity instances by invoking a corresponding Simple Entity Master in a dialog mode.
The Multistep Entity Masters should represent a wizard like approach to data entry, where information gets entered page by page (step by step). There are two possible ways to implement Multistep Entity Masters:
-
Multi entity approach where each page has a separate entity behind (persistent or most likely functional) with its own web-resource and a companion object. Pressing button
Nextshould result in a POST request to a corresponding web-resource to "execute" (save) a presented entity instance. If such execution is successful, the client navigates to the next page, which gets associated with a returned entity instance of a different type. Otherwise an error is presented to the user and the current page does not change. The process continues until the last page results in a successful POST request. -
Single entity approach where a single entity instance get its properties populated at different steps of the Multistep Entity Master (i.e. on different pages). Actuation of the
Nextbutton on every page should result in a POST request to the same entity specific web-resource. But, each time the entity instance would have more of its properties populated. Basically, is page in the Multistep Entity Master represents a set of logically grouped properties of the same entity instance that should be entered at the same time.
All actions on Entity Masters regardless of whether this is a Simple or a Compound Master belong to two categories:
-
Entity related -- the semantics of such actions pertains to an entity as a whole; for example, action Authorise semantically is related to an entity, even though the underlying change really just updates its single property
status; actions in this category should only be enabled when Entity Master is in stateVIEW. This is required to make sure that all entity changes are persisted. Often, the post-action of such actions should lead to invocation of a standard actionRefreshto make sure that the latest data is displayed to the user. -
Property related -- the semantics of such actions pertains to a single property modification; such actions should only be enabled when Entity Master is in EDIT state; as good example of such action is ad-hoc creation of new value to be assigned to a specific property; there should always be a visual cue that associates action with a specific property such as a button that is located next to a property editor.
It is proposed that a single property related action should be represented by using icon buttons, located immediately to the right of a property editor. In case of Polymer this should be a paper-icon-button.
There could be a situation where more than one property action is required. In such cases a paper-menu-button should be used, which basically looks like a paper-icon-button, but invokes a dropdown menu with a selection of actions to perform.
While designing the user interaction, the use of a single action should be preferred over the use of menu-button. This ensures simpler and more functional (usable) UX.
Action API should provide a way to specify upon what Entity Master state a property action becomes enabled. From the layout perspective, the action icon button should considered as an extension of the widget (e.g. an input) that represents a corresponding property. This basically means that when calculating the width for placing a property editor, the icon button width should also be taken into account as depicted on the image below.
Icon buttons are a good approach as they are based on SVG with transparent background. This makes them very light weight, almost translucent, and thus not "jumping into the face".
Entity actions should be located at the bottom of the page, beneath all property editors and other property related widgets. It is proposed that entity actions be represented by a raised button such as a paper-button. Although, the use of icons on raised buttons is permitted, a simple text with a nice ink effect should be preferred.
If at all possible the buttons should be aligned vertically on a single line. The width of all buttons should be the same. If not all buttons can be fit to a single horizontal line, for example, due to a narrow window or screen, then those action buttons that do not fit on the right should wrap to a new line.
Similar as for property actions, Action API should provide a way to specify upon what Entity Master state an entity action should become enabled. The default actions such as Save and Edit have this information embedded and there should be no way to change it.
Under normal circumstances an Entity Master should be in one of two states -- EDIT or VIEW. Actions become enabled or disabled according to their definition based on these states.
However, there could be a situation where transition from one state to another might take longer than few milliseconds, and during this period the buttons that would become disabled in the destination state could still be pressed by the user.
Therefore, it is important to prevent action execution until the state is undetermined. The client side implementation of actions should take this into account and provide a generic behaviour whereby their execution is prevented for an undetermined master state.