This application must successfully allow the user to accomplish their desired actions, and nothing more. In order to prioritize effective authoring, the required actions must first be defined.
- add and remove columns/rows
- reorder columns/rows
- edit structured natural language sentences
- select logic states
With just these simple actions, a huge amount can be accomplished. By focusing on these very limited actions, I can ensure these key areas are carefully considered and preform to maximum effect.
Bounded Action Areas
Having bounded action areas can greatly reduced the complexity of the control table panel. To this end, the control table is divided into four areas that each contain only one type of important information.
- Control Panel The control panel holds controls for logic state selection, and table/ row manipulation controls
- Table/Row Displays the labels for the table/row
- Sentence Controls This section displays the structured natural language sentences and provides a control to bring up editing modal
- Logic State Displays the logic state of row and column as well as allowing for basic logic state selection.
This is a huge improvement. Previous iterations had controls mixed throughout the different areas. The result was confusing with fewer opportunities for well defined control actions. With controls separated, not only is the layout more straightforward, this process has allowed each control to considered in a more complete manner.
Progressive Disclosure & Contextual Actions
An important tool for managing informational complexity is to hide actions until they can be performed. Brandon Walkin writes further about this.
In practices, this means that all column and row actions are hidden within their sub-menu until selected. Furthermore, these menus can be simplified by relying on column and row selection. By clicking on the row or column label, the entire row/column can be selected, giving the author the option to reorder or delete their selection. Without selection, these options are hidden.
The rows should be label for easy orientation. However, given the distinct nature of
Input Conditions and
Output Assertions, the two should be labeled in a way that distinguishes the two. To accomplished this,
Input Conditinos are labeled numerically (123...) and
Output Assertions are labeled using lowercase roman numerals (i ii iii...). This is important so that the
1 and an uppercase
I are not mistaken for the same numeral, making the author think that the two statements need to be connected. The
scenario columns are label alphabetically (A B C...) following convention established by existing spreadsheet editors.
Hover and Selection States
A key piece of successful logic state icons is the ability to select. Not only is this a crucial part of the authoring process, but also provides an opportunity to create another layer of of accessibility.
Hover states are a key piece that help indicate functionality, but can also be used to help further aid visually impaired people distinguish between pieces of information.
Change color. Even if the user has trouble seeing color, there is a value change, meaning the outline gets darker. This is noticeable but is not perfect.
Rows And Columns
Selecting a row or column allows the author to edit this element. Using the numeric or alphabetic label, the author can select the entire row or column. From here they are given the option to delete or reorder. These controls appear in the left hand control panel. At the same time, the row or column label appears in the control panel indicating which row or column is being edited.
Having the left hand control panel allows for a great deal of flexibility. My preference is to allow the author to reorder rows and columns by dragging and dropping actions. However, this will likely be difficult to execute. If this proves to be the case, the left hand control panel provides plenty of room for additional controls to be added for any element.
Logic State Selection
Selecting a logic state will enable options in the control panel. The logic state icon will be populated if one has already been selected. Additionally the coordinates will also populate the control panel ensuring clear orientation. The selected logic state will be highlighted with a blue outline and light blue background. Hover state will be just the blue outline.
There are multiple ways to select the desired logic state. The author may click to select the element. Upon selection, they may click again to cycle through the logic states.
Alternatively, the author may select the logic state icon from the control panel the reveal a pallet of logic state icons.
Having the logic state icon pallet separated from the control table is crucial for legibility. Upon testing selection in table, I found that no matter the shape of the modal, or background treatment (even darkening the rest of the table, with only the logic state icon pallet in focus) that there was too much visual information. Having the pallet in the control panel requires more mouse movement, but this trade off is worth it for the much improved clarity.
Sentence Constructor Modal
The sentence construction modal is one of the most important elements of the applications. Structured natural language sentences, allow authors to describe rules as normative data. See a full explanation of how this accomplished in the Oughtomation Paper.
A sentence is constructed by the author entering strings into the following fields:
- Subject Noun*
- Past participle*
- Auxiliary Verb
- Object Descriptor*
- object Noun or Verb
The fields marked with asterisks are required. Each field may only appear once. The sequence of the fields must retain controls for reordering
Domain Experts as Authors
When thinking about the creation of a interface, it is important to note that the application is intended to facilitate:
"the management of semantics in the hands of people who have the prerogative, motivation, domain knowledge and socio-cultural familiarity to tailor the expression of each sentence of each rule, who are motivated to make a genuine effort to provide a faithful reproduction of the full normative intent of the original rule with minimal distortion."
This underscore the importance of making the sentence construction accessible to all authors. This is challenging particularly for new users. Although the mechanic eliminates many of the barriers to creating rules transmitted on digital networks, the interface is not obvious to novice users.
Importantly, using labels to describe the inputs is not an ideal solution. Describing different parts of speech utilizes technical terminology in a way that may make even native speakers unsure of what's required. As Joseph Potvin has suggested, labels should be secondary, with an emphasis placed on practical examples. By leading with examples, and allowing authors to discover sentence patterns for themselves is the most feasible way to ensure domain experts themselves have the ability to author rules.
From the previous two sections, some requirements can be defined. To facilitate the authorship process each field must:
- indicate if a field is required
- allow the author to reorder sentence elements
- present examples
- function within a window with minimal horizontal dimensions
With the constraints a clear picture emerges.
Examples populate the fields as hints. Crucially the labels are beneath the input, so that the author see the example for being presented with a technical explanation. additionally, there is a refresh button that will allow the author to cycle through examples.
Given the limited space, and the fact that the labels for the parts of speech are given lower priority than textual examples, the labels are condensed to abbreviations. To give additional distinction, each field has a differently color underline.
When the author clicks on the bottom label, full label information is revealed along with control options. Input controls enable reordering and removal of non required fields.
Adding Removed Fields
If a field is removed, a button will appear at the end of the sentence allowing the author to add that field
Hover states the text is darkened, and the underline is increased to 2 pixels.
A background is added to the fields along with darker text.
Default Logic State Icons
|Context||User Need||Design Requirements|
|A user is authoring rules using the table editor||They need to be able to easily distinguish between the different logic states when selecting, but also be able to see the macro pattern that emerges from the table when complete||Have multiple forms of visual redundancy to make the logic state clear. this means using shape, color, and label in combinationt|
|Correct balance between high contrast for easy logic identification vs having a ui that is not straining/tiring on the eyes is crucial|
The icons indicating the quaternary logic state are one of the most important UI elements. Legibility, and at-a-glance comprehension are crucial for effective rule authoring and review.
The greatest challenges facing an author is the density of information presented on the table editor tab. Fortunately significant research exists in this area. UX Matter states that "The greater the density of information on a page and the greater the distance between highlighted visual elements, the more this type of color-coding improves user performance. Because color is such an effective visual cue, its use can also reduce eye scanning movements and, thus, visual fatigue.
However it is also important to not that color alone is not sufficient. W3 mandates that "Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element."
In order to ensure the maximum accessibility of this information, three layers of redundancy are required. These are label, shape, and color.
The labels for the default logic state icons are defined in Joseph Potvin's forthcoming Oughtomation paper. They are as follows
Labels | -- | -- | -- | -- 00 | 01 | 10 | 11
How do we choose the colors. There are a few important constraints. First the logic being represented is quaternary. That means we need 4 distinct, highly contrasting colors. These means we can make use of a square color wheel constraints. However, this color scheme also needs to be conformant with the brand guidelines. Using the main blue as the square base we get the following scheme.
For consistency across the icons, I want to use the same white text for all labels. This requires tooling the color. Adjusting slightly for w3 contrast guidelines we are left with the following color scheme. This conceptually embodies the meaning behind quaternary logic, wile also creating maximum color contrast between logic states.
This color scheme drive the rest of the color use across the application, providing the primary base colors used for accent, warning, etc.
Through iteration of shapes. Joseph Potvin suggested the following shapes.
These shapes have an intuitive relationship with the logic state they represent.
Applied to the Icon shapes described by Joseph Potvin, the result is as follows. Particularly in the case of
11 the shapes convey that another step is needed, passing a piece of decision making along to human eyes.
All Together Now
Combining all of these decision the result is as follows:
And in the context of the layout the logic state icons have strong contrast, are readable at a glance, and do not fatigue the eyes.
Custom Logic State Icons
Icons are a property of the rule template. They are useful because they may convey specific information that would be difficult to decipher without the correct iconogrpahic representation. For example, someone may be authoring rules within the tradition of formal logic. Without the corresponding logical symbols, the axiomatic statements may be incomprehensible.
In the settings tab there is an option to select if the author wants to use the custom icons contained within the rule template, or to select their own templates.
have a paint bucket type method that allows you to select the logic icon that you want to use from a top menu
have multi click options
have hot keys that determine the logic state you'd like to input
doesn't work well, because the
This could be implemented in a control bar with column and row actions and the state selection tools all located there
The division between the sentences and the logic grid should allow for resizing.
|Context||User Need||Design Requirement|
|A user is authoring a rule using the table editor||User need to select and add logic states to the table. They must be able to select their tasks quickly and easily, as well as correct mistakes||Input condition, output assertion and row controls, including adding rows/columns, removing rows/columns and reordering.|
|Selection of logic states within the table|
|Ability to describe coordinates of logic state using row and column labels|