Just the fields please Ma’am

In the previous post we looked at how Mitopia® auto-generates the GUI appropriate for examining and navigating a collection of nodes, in this post we will begin to look at how the GUI to display and handle the content of a given node is auto-generated.

The most critical component of the GUI renderer’s control set is the existence of a control type that is capable of performing ontological field discovery and layout through the DataModels abstraction.  We will refer to this control type as the Data Model View Control (DMVC).  A DMVC is created by Mitopia’s AutoUI package when any request to display data occurs.  The DMVC is set to a rectangular size as determined by the available UI display area.  The DMVC is then ‘linked’ to the data record in the collection that it is to display.  From that point on, all GUI creation and handling is automatic by the GUI renderer through discovery of the fields within the record linked using the DataModels abstraction and API.


The screen shot above illustrates the initial appearance of the DMVC when showing a Country record.  The DMVC has represented the various sub-structures it discovered within the Country record as tabbed panels.  As can be seen , not all tabs will fit into the available screen space so the last tab spot is replaced by a popup menu from which the user is in the process of selecting from the full list of sub-structures.  Note also that the DMVC is displaying the inherited fields of Datum along with the initial fields declared in Country in the first tab panel labelled by the type name Country.  The DMVC shows sub-structures inherited or directly declared in Country as tabs on the top line.  The ‘notes’ and ‘location’ sub-structures are part of the Datum type and hence show as tabs on the top line.  If these values had not been sub-structures in Datum, but directly declared, they would have been displayed directly in the first ‘Country’ tab, and this would have been confusing visually for the user.  For this reason (and others), these fields were organized in sub-structures with easily recognizable names so that the user would not have to see them for every record displayed, and yet could quickly locate them in a known place when needed.  Thus we see that the visual layout of the data in the DMVC is a significant driver on the organization of fields into sub-structures in the Carmot ontology.  This same layout philosophy drove the choice of all the other sub-structures of Country as can be seen from the popup menu selections in the screen shot.


The tabs for ‘actor’ and ‘entity’ are particularly interesting in this regard.  During the ontology development, it became obvious that having the fields of Actor and Entity (see screen shot to the left) displayed on the front tab of every Actor-derived type was confusing for most users.  To avoid this, it was desirable to move these fields to a separate tab.  Thus the declarations of the types Actor and Entity had to be modified as shown in the listing below:


As can be seen from the listing, by moving all the fields of Actor into a sub-structure ‘actor’, and those of Entity in a sub-structure ‘entity’, we obtain the desired result in the GUI, which is to move all these inherited fields out of the first tab display content for all descendant types.  Obviously, this is a tradeoff since if we choose to move all inherited fields into other tabs then there will be nothing much displayed in the initial tab most of the time.  However, we are guaranteed that the ‘essential’ fields of Datum will be displayed in all cases so regardless of type we will see all the fields down to ‘symbology’ on the front tab and this is enough to get at least an idea of what the record describes.  The logic with any renderer DMVC should use for layout of fields at any level of structure nesting, is as follows:

  1. Display all direct fields of a type on the front tab for the structure
  2. Display all sub-structures or ‘@@’ fields (in the order they are encountered) as additional tabs.  If a sub-structure starts with an ‘_’ character, the renderer may optionally choose to not display a separate tab, but instead display the structure contents directly within the parent tab as peers of the structure field itself.  This convention allows additional ontology control over GUI layout.
  3. If there are no sub-structures, do not create any tabbed panels
  4. If not all direct fields fit into a given tab panel, create numbered sub-panels.

As implied by the rules above, this logic should be repeated for every level of sub-structure nesting discovered within a type by stacking tabbed panels within each other.  The screen shot above illustrates the display after selecting the “People” tab of a Country.   As you can see, choosing the “People” tab results in displaying the fields of that sub-structure within the tab area but since there are additional sub-structures within ‘people’, a second row of tabs is created to handle this.  In this case the second row of tabs uses an alternate rectangular appearance rather than the rounded tabs found at the first level.


By comparing the Carmot declaration for the sub-structure ‘people’ within the type Country given in the listing above, it should be obvious how the repeated application of the simple logic for tabbed panel creation results in the display shown in the screen shot.  Note that all the directly declared fields of the sub-structure may not fit into the display area for the tab so the algorithm may be forced to create another numbered set of sub-tabs to allow all fields to be displayed.  Other renderer plugins adopt different solutions to this problem.  This is illustrated for ‘government’ where the result of selecting the “3” sub-sub-tab would be to display the following:


Within any given tab panel, the fields are laid out according to their field type using visual representations and strategies as described in the subsequent sections.

Obviously, the layout strategy described above is just one of many possible strategies, indeed the small numeric popup at the top right of the DMVC can be used to dynamically modify the number of columns that should be used within any given tab to represent fields.  The fewer columns used, the more sub-sub-tabs may be required to display all the fields, but the more text it is possible to display at any given time.  Conversely making too many columns prevents the correct layout of certain fields and should only be allowed by the renderer if there is sufficient screen real estate to display data correctly in the number of columns selected.

If the fields of a sub-type can be fully displayed within the parental tab then the layout algorithm might choose to display the sub-type within the parent tab as a ‘bordered’ view for example.  Another possible layout strategy would be to view the DMVC rectangle as a scrolling ‘window’ onto the equivalent of a printed listing of the various fields and sub-fields.  This strategy has the advantage of simplicity of layout computation and might be appropriate for printed reports or in less capable GUI environments (e.g., the web), but for large and deeply nested structures, this scrolling approach leads to loss of context and can be very slow to navigate.  As a matter of fact, another registered Mitopia® GUI web renderer uses this exact strategy to represent data.  Many other layout strategies are possible, all based on sub-division or scrolling of the available visual rectangle for the DMVC.  One huge advantage of the dynamic DMVC approach to GUI layout is that new decisions will happen as the enclosing window is resized as a result of additional screen real estate becoming available, the GUI is this much more adaptive to the current visual environment.  For example, one can zoom the GUI window to fill a large (e.g., 30”) screen to see more fields at once as in the screen shot below.


Furthermore, as can be seen from the screen shot, allocated field display size can be changed dynamically depending on how much data/text is actually in the field for the record concerned, that is the layout of any given type will vary dynamically for each different record displayed in order to make best use of available screen real estate.  Regardless of the particular layout strategy utilized by the renderer within the DMVC, the operation is identical since all fields and layout hints are discovered dynamically through the DataModels abstraction layer.

We will explore GUI auto-generation in more detail in future posts.