1. rule-makertable-editor-ui

Rule Editor Layout

Rule Assembly Workflow

Rules Emerge from Human Relationships

In the Oughtomation paper, a rule is defined within specific terms. From figure 2 an important conceptual distinction is described.

Figure 2: Six types of normative data which may be communicated.

NORMATIVE DATA	DECISION	PROPOSITION	PREROGATIVE
MUST, MAY and SHOULD	Empirical Statements	Declarative Statements	Imperative Statements
GENERAL CONTEXT	Deduce from evidence that this system of rules is ‘in effect” for this jurisdiction and time.	Describe a system of rules.	Acknowledge a system of rules.
PARTICULAR CIRCUMSTANCE	Deduce from evidence that this rule is ‘applicable’ to these facts.	Describe a rule.	Acknowledge a rule.

From this it is clear that a rule that enters an Oughtomation specification network is a description of a rule based upon “some type of agreement, authority, resolve or preference.” To this end an author using RM is tasked with describing an agreement that exists within a complex, dynamic rule system, emerging from living human relationships. These agreements are often described in formal legal documents, but may be documented in other ways such as meeting notes, a transcript of a conversation, a photograph, a note scribbled on a napkin, or any number of other methods.

No matter the form of the document, the core authorship mechanic remains constant. An author, examines a document and describes a rule as normative data using a logic table. It is clear that before a rule exists within an Oughtomation network, it first exist in a form that is embedded within a human readable artifact.

This is further evidenced by the fact that one of the core pieces of metadata in the rule schema (XRS) document is a rule-url field. This field is intended to ensure there is always reference to the rule’s originating document. However, this choice also provides an important insight into the mechanics of an authorship process.

When an author decides to describe a complex and animate rule system based on living relationships, they may not know things such as:

• how many rule.xalgo documents will be required to fully express this rule
• how this description will be best be represented as a logic table
• how many structured natural language sentences will be required
• what data tables will be required for rule evaluation

Dynamic IDE Assembly

To this end, an authorship process begins with examination of a source document and rule(s) are derived from careful and concerted description efforts. Annotation, isolation of clauses, etc. are all valuable tools that will aid the author in this effort. More important to the core mechanics of XRM Dev, an author must be able to create rules, and edit logic table while examining a source document.

Understanding this dynamic give important clues to the nature of the IDE environment. Crucially, an author must be able to view more than one rule.xalgo document at once. They must be able to use the multi-plane environment to view a single source document while switching between the assembly and testing panels of multiple rule documents.

Coming to this realization makes me think back to a piece of advice Don Kelly has repeatedly given: “RM is a text editor”. This comment has taken on further meaning. RM is a text editor, and therefore, it should be able to open a text document. However given the limited dev capacity, this is not the primary objective. The focus of the reference implementation must be on the assembly of logic tables and description of metadata. However recognizing that these element are derived from a document provides important insights about how top level controls such as creating a new document, and opening existing documents are handled.

In summary, it will eventually be useful to conceptualize RM as a specific kind of note taking application. However, the ability to view source documents must not be the priority at this point. Yet even without this feature, conceptualizing the application with this workflow in mind will improve usability. Even if authors open a source document in another application, they will still be able to enjoy the kind of functionality they are looking for in a rule assemble environment, even if they lack the ability to view that document directly in rm application.

This means a file browser to the left will be required. Within this module is a new rule button. This means that each pane need to display the file name and offer pane controls. See Split Pane for more details.

Tabs

The IDE environment is comprised of four tabs:

• Rule Assembly
  • Rule Metadata
  • Logic Table
• Raw Text
• Testing
• Settings

Layout

Concerted effort went into thinking about where each element sits within the window. Not only must the layout provide intuitive placement of the different elements, it must also do so effectively, even with reduced horizontal dimensions (since the split screen will limit the x dimension of the panel).

Layout Requirements	–	–
have all the pages accessible via a submenu even when multiple panes are open	have all table controls accessible even when all panes are open	display maximum amount of table information given t once the other two requirements have been fulfilled

because the application is multipane, it is imperative that controls and sub-navigation are accessible when even when half of the screen is occupied by another pane. This means that the sub-navigation must be located on the left hand side. There are too many tabs for it to be located below the navigation, since when the screen is split, tabs are lost.

Similarly this puts a width constraint on the logic table control panel. Being located on the top means there is clear differentiation between the different submenus. Per application standards, these controls must consist of both an icon and a label, for maximum accessibility. However, this requires that the labels are as concise as possible, so that important control information is not hidden It’s width must be as small as possible so that controls are accessible even withe reduced x dimensions.

Multipane

The author may split the screen horizontally to access multiple instances of the IDE interface.

Essential actions

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.

1. add and remove columns/rows
2. reorder columns/rows
3. edit structured natural language sentences
4. 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.

1. Control Panel The control panel holds controls for logic state selection, and table/ row manipulation controls
2. Table/Row Displays the labels for the table/row
3. Sentence Controls This section displays the structured natural language sentences and provides a control to bring up editing modal
4. 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.

---