Web UI Design: Compound Views and Menus

Container View

There is a need to have a view independent of any specific entity (unlike entity master views) that would server as a container for layouting its components. The components in this case could be anything including entity masters and centres.

Some most essential characteristics of container views are:

• Can be integrated into a menu.

• May contain other container views and simple masters (even several if needed).

• There should be an API for programatic interaction with embedded components. For example, there should be a way to list the embedded simple master views and check their state.

The last item above suggests that like simple entity masters, a container view should also have explicit support for EDIT and VIEW states. However, in case of a container view the state should be calculated by interrogating its embedded components. If at least one component is in state EDIT then the container should also report state EDIT. Otherwise, state VIEW.

Container's support for state makes it well suited for integration with a menu where navigation between menu items should be governed by the state of the current view. If it is EDIT then switching to any other menu item should be prohibited. The user should be informed of the reason for not being able to switch by a toast with a relevant message.

Tab View

Tab view is a component designed to hold two or more container views, where each tab corresponds to a separate container. The tabs should be thought of as a "horizontal menu", where switching between tabs is governed by exact same rules -- the state of the current view. A tab view component should be implemented using polymer tabs, and should also support the notion of EDIT and VIEW state.

In general, the EDIT and VIEW state should have a compositional or hierarchical nature. This way any component may always obtain its state by querying subcomponents.

The tab view should not be overused. At this stage its main application is to provide a convenient representation for entity centres, where selection parameters and the actual search result should be placed on different tabs.

Like actions and menu items, tabs should have scoped names and API to programatically active a tab by its name.

Menu and Menu Items

A menu consists of "actionable" and "group" items. Group items have no separate views. Therefore, tapping them only leads to expanding/collapsing of the underlying menu items.

An actionable item is always associated with some view, which could be a container view, a tab view or a simple master. Therefore, tapping an actionable item would always result in a component loading (either from a remote resource or stored locally).

Switching between menu items is governed by two factors:

1. The sate of the current view.

   If the sate of the current view, and there always is a current view due to the fact that the top most menu item gets activated automatically if no other item was activated programmatically, is in sate EDIT then switching to any other menu item is prohibited.

2. Security settings for current user.

   Access to menu items should be controlled by a base-user of the currently logged in user. As part of Swing UI, inaccessible menu items would not even be presented to the user (i.e. they where invisible).

   Such approach was deemed to be very convenient as it provided a way to customise application menu for different groups of users that share the same base-user.

Scope and naming

Each menu has its scope. All items of the same menu should be provided with unique names by using Java API. These names then would be used to access menu items programmatically at the client side using JavaScript API.

Menu item state

The notion of state for a menu item is really applicable only for "actionable" items, but should also be supported for "group" items.

For group items the state should always read VIEW. For an actionable item the state is driven by the associated with it view.