The Oughtomation Paper by Joseph Potvin et al specifies an:
"end-to-end design for human-centred digitally-assisted project management with a general-purpose request-response method, [by which], anyone will be able to publish, discover, fetch, scrutinize, prioritize and have the capability to mobilize normative data on digital networks with precision, simplicity, scale, volume and speed, and with deference to prerogatives, agreements and preferences."
This application is one of three core reference implementations that comprise the Oughtomation Method. Rule maker(RM) is responsible for the the description, maintenance, assembly, and publication of normative data within the Oughtomation specification. To this end, Rule Maker is concerned with "the imperative prerogative arising from social or institutional spheres which empowers a person in the ‘rule maker’ role to compose statutes, contracts, specifications, policies, treaties and other relational structures among two or more parties, " Potvin writes. Crucially, this indicates that RM plays an interfacial role, at the edge of the network, facilitating the description of institutional, social and ecological prerogative into normative data that may be transmitted across the network. This is accomplished through the authorship of logic tables, and the description of accompanying metadata.
From this the core actions of the application can be derived. RM must facilitate the authorship of logic tables, the description of required metadata, and the publication of this data to digital networks.
The design of this application has been guided by the both the technical specification of the Oughtomation paper, but also the design virtues that informed the research methodology of this document. In addition to these design virtues, the philosophy of general purpose software, and two core product design principles guided this project in ways that compliment and make specific the core design virtues.
RM is general purpose software. This poses design challenges because the full range of use cases is not known. However, this imposes important constraints that prioritize flexibility. Throughout this applications are choices that were made to embrace flexibility. Understanding these choices is critical, because they impose certain technical requirements. Primarily:
Beyond these three examples, the framework of general purpose software is a core concept that has informed the entire design process of this application. See accessibility for more information about how these ideas inform the visual design of this applications.
there are guiding design principals from the forthcoming Oughtomation paper that can provide a grounding for the development of a brand. The following 4 design virtues became key points of orientation.
Complimenting and making specific the design virtues are are two core principles of product design that guide thinking within this application. These principles are focused on usability
Having functional controls located correctly for application use is one of the most import elements of a functional UI. Two primary principles will guide this effort:
Throughout the following sections these ideas will guide the thinking that supports the design decision of this application's UI. These principles both compliment and stem from
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.
|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:
rule.xalgodocuments will be required to fully express this rule
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
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.
The IDE environment is comprised of four tabs:
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).
|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.
The author may split the screen horizontally to access multiple instances of the IDE interface.
This application conforms to Xalgorithms Brand Standards. While not using the Xalgorithms Material Components, the atomic components comprising this application must be styled according to these specifications.
See Brand Guidelines for full brand documentation
Throughout the application there a number of elements that must conform to standards. I will quickly layout a few universal rules that apply throughout the application