Visual Design
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.
Grid Labels
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.
Editor Actions
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
Sentence Elements
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:
- Determiner
- 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.
Field Requirements
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
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.
Labels
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.
Progressive Disclosure
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
Hover states the text is darkened, and the underline is increased to 2 pixels.
Active States
A background is added to the fields along with darker text.
Ideas
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
drop down
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.
the
| 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 |