Design for General Purpose

Developers across industries have a need for a distributed, general-purpose method that enables any person to author, publish, discover, fetch, scrutinize, prioritize and optionally automate rules on digital networks at scale and with speed. The Xalgorithms Foundation has created a general purpose free/libre/open method called DWDS. With nearly a decade spent developing the system specifications, entering the implementation phase of the project marks a major milestone. I took this as an opportunity to both design the interface of the rule maker application, as well as to help the organization asses priorities and orient the implementation of the application in a strategic manner.

Rule Maker enables users to author rules in tabular expression.This enables anyone to author rules that can be used across digital networks, in any language, no matter their level of technical ability. This innovative approach introduced challenges across the design process. Not only did the specification introduce novel mechanics, it also required a general purpose approach which rendered many common approaches such as the use of personas non-applicable. To take a successful human-centered approach, I realized a recursive process of research, iteration, and prototyping was needed.

1. Research is broken into two categories: validation and workflow analysis.
   • Validation is focused on assessing user actions within the existing rm design specifications.
   • Work flow analysis examines the application within an expanded context, looking at authorship processes both in and outside the application that influence the rule making process.
2. Iteration is informed by the validation testing to improve the existing actions supported in the application.
3. Prototyping involves crafting interfaces which can be used to conduct rule authoring actions. Interfaces can be used to enable user testing at various scales. Prototyping can happen in production and pre-production interfaces, which can take the form of anything from paper prototypes to production class screens.

With this approach, and with the help of many converstaions with colleagues, I was able to chart the required in-application activities. This required both understanding the authorship process, and the constraints of the application. Authoring a rule is a process that requires a deep interrogation of a source text and reflection on meaning, intention, and outcome. Only some actions involved in this process are supported in application: much happening in the mind of the author. While these mental actions may be complimented by the application, charting this distinction helped focus the design process, ensuring support of application functionality.

With this information, It was possible to begin formulating user flows, and designing an application to accommodate these. The end result is a high fidelity mock up. You can click through the prototype below to get a sense of how the application would work. This design process is on going and testing and iteration continues.

The method of authorship is the most striking characteristic of the Rule Maker application. However, given Rule Maker's status as one of three applications comprising a node, it was clear that I needed to understand how and why all three applications would be implemented across use-cases. To explore this questions, I developed distinct narratives and mapped the implementation process and interplay between the three applications that comprise a node.

The common thread across all stories was the developer. The developer had to play a central role in integrating DWDS with other pieces of software to meet their goals. It became clear that the innovative features of Rule Maker would not benefit any rule authors if the application was not designed with developer implication as a primary concern. This insight helped to create two poles of focus for the project, ensuring that both the developer implementing Rule Maker, and the author writing rules were considered. With this framework in mind it was possible to being charting what developer accommodations were needed. The following graphics maps out the relationship between between developer actions and core actions.

The key insight from this exploration was the idea of the rule template. A successful general purpose technology is one that is not only flexible, but is also easily modified to fit specific use-cases. A template allows developers to dynamically generate specific Rule Maker interfaces by allowing the fields of application to be defined by a template.json document.

"item.classification": {
    "label": "Procduct Code",
    "description": "Choose what kind of product this rule is about.",
    "type": "array",
    "options": [
        {"label": "Pencil or Pen Grips", "unspsc-code": "44121707"}, 
        {"label": "Colored Pencils", "unspsc-code": "44121707"}, 
        {"label": "Wooden Pencils", "unspsc-code": "44121706"}, 
        {"label": "Mechanical Pencils", "unspsc-code": "44121705"}
    ]
}

Considering the needs of developers and rule authors, shaped the design of the Rule Maker application by mandating:

1. A simple modular interface
2. Support for developer implementation

The result is a focused application designed to easily be adapted to specific use-cases.