User Interface – Mapping Variable Inputs to UI Elements

automationuser interfacexhtmlxmlxslt

Background

Developing a system for creating eBooks. The data is highly normalized. The eBook designs are packaged as "themes." The themes can be configured with options for: fonts, colours, some layout, and thematic elements (such as squares for bullet lists could become circles, hexagons, or arrows).

The options are tightly coupled to the theme. For example, one theme might only allow the user to select certain fonts, while another theme might not have any thematic elements at all, while all themes might provide options for changing the page number layout, theme colours, and content for the header/footer.

Creating eBooks is one example of the general class of problem:

The output depends on configurable options; the available options depend on a particular constraint set.

Problem

When a new constraint set (e.g., eBook theme) is created by a developer, the configurable options must be exposed as user interface elements. The user interface elements could be mapped to the options using a descriptive language, or XML. For example:

<group id=”page-number”>
  <group id=”text-attribute”>
    <string name=”UserInputPage” default=”# / ##” id=”ui-page” />
    <colour name=”UserColourPrimary” id=”ui-colour-primary” />
    <select name=”UserSelectBullet” id=”ui-bullet”>
      <option id=”ui-select-square” />
      <option id=”ui-select-circle” />
    </select>
    <integer name="UserRandomSeed" min="1" max="50" id="ui-random-seed" />
  </group>
</group>
<text language="en">
  <!-- Tab name -->
  <ref id=”page-number”>Page Number</text>
  <!-- Group name -->
  <ref id=”text-attribute”>Text Attributes</text>
  <!-- Display name for select options -->
  <ref id=”ui-select-square”>Square</text>
  <ref id=”ui-select-circle”>Circle</text>
</text>

The underlying theme implementation (whether PHP, Lua, Java, or C++) would define, expose, and use variables such as:

UserInputPage
UserColourPrimary
UserSelectBullet

Using XSLT, it would be reasonably trivial to convert the above map into sensible UI widgets that correspond to the variable definition in the XML.

By creating this map, developers need not explicitly create the user interface, nor worry about either its layout or menu structure. The developer creates a map of the software's input variables and the computer automatically generates the UI. The UI, in this case will be XHTML, but could be XUL or any other representation.

Comparison

Frameworks such as JavaServer Faces are similar to this idea; JSF and ADF issues include:

  • Too complex with too much overhead.
  • Often tied to specific implementation languages.
  • The inputs are bound too closely to their final representation.

For example:

<h:inputText value="#{helloBean.name}" ... />
<af:selectOneRadio value="#{bindings.x.hints.inputValue} layout="vertical" />

Vertical "selectOneRadio" radio button inputs should not be hard-coded throughout the application. Instead, the final UI representation should be based on intelligent defaults. In the XML example from the problem section, the UI should generate two radio buttons because there are two inputs in the select item. Three items would generate a drop-down. One item would create a checkbox.

Similarly, the <string> could generate any of:

Also similarly, the <integer> could generate a slider or a simple input field. Validation would be performed elsewhere.

With HTML, the final look and feel of the item would be driven by CSS, just as with JSF.

Related

Somewhat related:

Question

What approach would you take to create such a variable map definition that can then generate UI code?

Best Answer

First off, I would agree that most of the solutions that are already available look very complex and tied to concrete implementations. Although you are essentially going to be re-inventing the wheel, I don't think it is an overly difficult wheel to re-invent and I think that the benefits you will gain over time from having a nice, clean, simple solution will definitely justify the up-front investment.

My approach would be as follows:

  • Themes should be able to produce their own metadata files. I was going to suggest that JSON would be just as good as XML for these files, but on reflection I think XML would be the better option. Either way, you wouldn't be editing them manually, so what matters is convenience for the theme programmer.

  • I would write a separate validator to validate both theme metadata files and the config that the UI generator creates.

  • I would then identify the different kinds of controls you are going to need and build those into the specifications of the theme metadata file. This is where some flexible thinking comes into play. I would have options like "boolean", which will get rendered as a checkbox but for lists I would provide "radio" and "dropdown" options, because sometimes a set of radio buttons is more appropriate than a drop down list and vice versa. I would also provide a "regex" option so that the UI can carry out some basic validation where necessary. Things like page number formatting I would implement by including a list of tokens with a field description, which the UI displays to the user so that the user knows they can use those tokens in the field. For example, the page format field might be a string field, max 30 characters and provides the [page_no] and [total_pages] tokens to be included in the config. So the theme metadata file would be fairly flexible, with elements containing optional parameters, validation info, option lists, etc.

  • The resulting theme config files would use the same format (eg. XML) and, as mentioned, should be able to be validated by a stand-alone tool. (I realise that's an implementation detail, but it would be the first place I would start, as I would be running this tool constantly during development as both it and the theme metadata format evolved).

Rendering the UI based on this kind of file wouldn't be all that hard on any platform, assuming a single, vertically formatted scrollable page. I think the key to making this work is being creative around the definition of the theme metadata files and not boxing one's thinking into one paradigm or another.

Related Topic