Since the very first version of IG Coder, there has been a base user interface (UI) with a background, a navbar along the top and a body container. As I men-tioned in Section 5.2, IG Coder uses Bootstrap for styling the interface (specifically, React-Bootstrap which wraps Bootstrap components in React components). These reusable components make it easy to compose a user interface with a consistent style, so that I can focus on functionality.
Thus, I created UI for each feature as part of implementing it. This means I never made drawings of what the user interface for the prototype should look like. While I had some ideas about the user interface in mind, I only made some small notes
14https://git-scm.com/
15https://jsdoc.app/
in my implementation log and spent very little time planning the user interface.
Figure 5.2 shows the page listing all statements. For this page I thought the most practical solution to display the list would be a table. This would allow me to add columns if more information needed to be displayed for each statement, and this turned out to be useful since I added the "Status" column much later. While this page shows the list of test statements, it is intended to represent a specific document (i.e., policy or regulation) containing a chronological list of statements.
This page also contains the "Load file" and "Save file" buttons, since they pertain to the document as a whole.
Figure 5.2:IG Coder: List of test statements
Figure 5.3:IG Coder: Uncoded entry
In Figure 5.3 we see the entry page (in IG Coder, an entry represents an institu-tional statement, as described in the data model specification). It shows the raw statement, which is read-only but allows the statement to be rephrased after click-ing the "Rephrased" bar. When no codclick-ing exists for the entry, a new codclick-ing can be started by creating a new root node, which has three possible types.
Figure 5.4:IG Coder: After creating a root node
Figure 5.4 shows the entry page after clicking the "Regulative" button in the pre-vious figure. Creating a Statement node of regulative or constitutive kind auto-matically creates Component child nodes for its mandatory components. This is where the D3 tree visualization comes in. The tree is an SVG graphic made of SVG circles, lines and text boxes, and is generated as well as styled by D3 code. This means Bootstrap cannot be relied on for styling the tree. This page also contains a button "Clear tree", which upon confirmation deletes the coding.
Figure 5.5:IG Coder: Statement editor
The next figure, Figure 5.5, shows the result of clicking on the Regulative State-ment node in the previous figure. When clicking on any node, this dialogue box (hereafter referred to as a node editor) appears on top of the entry page. In the editor, both kinds of Statement node display a grid of their child nodes, where op-tional components are absent by default but can be created and deleted. Clicking on a child node takes you directly to that node’s editor.
All node editors have a question mark in the upper half, which when hovered over displays a block of help text in the blank area below it. Furthermore, the upper bar shows the node type and component type if applicable as well as a number of controls depending on the node type. Nodes of all types can be marked as Negated, and most node types can be labelled with a Context type (of IG 2.0’s Context Taxonomy).
Figure 5.6:IG Coder: Component editor
Figure 5.6 shows the node editor of the Component node of type Attributes in the tree from Figure 5.4. Component, Junction and Property nodes can all have text content, which the four text fields are for. The full statement is shown in a read-only field, and text can be selected and then dragged or copied into the text fields.
Figure 5.7:IG Coder: Junction editor
Moving on, Figure 5.7 shows the node editor of a Junction node, which is not pictured in Figure 5.4. A Junction node represents the logical combination of its two children, and thus two empty slots for child nodes are shown. Only one text field is available, and the upper bar allows its logical operator to be set.
Figure 5.8:IG Coder: Fully coded statement
Finally, Figure 5.8 shows the tree representation of the fully coded example state-ment. Activation Conditions (Cac) and Execution Constraints (Cex) have text la-bels by default when no constraints have been coded. Nodes outlined in red are marked as Negated. Hovering over any node in the tree displays a tooltip contain-ing node type, component type if applicable and text content if applicable. For Property nodes (purple), dashed lines mean the Property is functionally indepen-dent from its parent node. A Property node can be set to functionally depenindepen-dent on its parent node, in which case the line to its parent node becomes solid, and back. The Property editor is not shown among these images, because it is very similar to the Component editor.
I reiterate that using Bootstrap made it easy to have a consistent style across the app. I only had to ensure the D3 tree visualization fit in as well as being easy to read. The user experience (UX) could certainly be improved as I am not a UX designer, but that is a matter for the future.