Rule Maker is an application used to author
rule.dwd documents. There are two distinct implementations of this application:
- Rule Maker (a web application)
- Rule Maker Dev (a command line tool)
The diagram below outlines the actions enabled by RM and RM Dev.
To understand the rationale for these two implementations, it is important to understand strategic goals and workflow requirements.
Authoring rules is a complex and demanding task. The process takes places across multiple contexts, requiring consultation of a source text, mental processing, and expression within the application.
To enable all the actions required there are a few options:
All in one Application
A text editor that surfaces a rule authoring interface, command line tooling, and can display rule source files.
A desktop app that supports only a rule authoring interface. external applications are required to view source texts and access command line tooling.
A web app intended for non-technical users to simply author rules.
A web app intended for non-technical users, plus additional dev functionality, including dev functionality, when run locally.
Next its important to consider strategic objectives.
- This is a general purpose piece of software, intended to be flexible, and adapted to specific scenarios.
- This is a novel approach to rule authoring. As such, removing barriers to entry and getting users hands-on is a priority.
- Building a dev community is a crucial element of success. Creating an app that lends itself to plug-ins and add ons is required.
- Stakeholders want easy access to application for review, etc.
Given these factors, there is strong reasons to build Rule Maker as a web app. However, it is also clear that when running in a dev environment, a user can gain additional functionality. In addition to be able to edit
rule-template documents to customize the authoring environment, the user may also pull up the RM DEV command line tooling, using the graphical editor to author rules, while using the command line to conduct test. Reference their source text, inputting information into the graphical editor, and testing from the command line, the user has a rich, multi window experience. In a sense, this is the full IDE experience, just spread across windows.
Not every step in th authorship process is supported in application. The following diagram indicates which areas of a rule authoring workflow are supported within the Rule Maker application.
Rule Maker is comprised of 3 distinct function areas:
- on-boarding/learning module (may not be linked in app, but may exist as a distinct application)
- rule editor
Each of these is comprised of further sub-features, each requiring their own design process. The next section outlines the general research methodologies used across the application.