Dynamic Decision Trees

Abstract

Knowledge comes in various forms: scientific, artistic, legal, and many others. For most non-computer scientists, it is far easier to express their knowledge in text than in programming code. The dynamic decision tree system is a system for supporting the authoring of expertise in text form and navigation via an interface that limits the cognitive load on the reader. Specifically, as the reader answers questions, relevant tree nodes appear and irrelevant ones disappear. Searching by a keyword can help to navigate the tree. Database calls bring in information from external datasets. Links bring in other decision trees as well as websites. This paper describes the reader interface, the authoring interface, the related state-of-the-art work, the implementation, and case studies.

1. Introduction

People invent rules all the time. There are laws, rules for medical diagnosis, techniques for computing lengths in trigonometry, and debate arguments, to name a few. Historically, computer scientists developed expert systems to encode such rules [1]. The problem with such systems was that they were challenging to author for non-programmers, and they generally had a text-only reader interface [2]. Modern systems require “knowledge engineers” (alongside subject matter experts) to author expert systems using various shells, programming languages, and specialized software [3]. State-of-the-art knowledge-based systems such as MangoApps https://www.mangoapps.com/ (Issaquah, WA, USA, accessed on 11 August 2024), HelpJuice https://helpjuice.com/ (Washington, DC, USA, accessed on 11 August 2024) and FreshWorks https://freshworks.com (San Mateo, CA, USA, accessed on 11 August 2024) are primarily used for customer support and ticket tracking rather than complex decision-making. They generally require dedicated technical support [4,5,6].

Target Audience and Contributions:

The dynamic decision tree system is aimed at using non-programming domain experts (e.g., negotiators, doctors, policy makers) as authors and people without domain expertise as readers. The technical contributions are:

• Support for a simple-to-author text description of the expert system for domain experts who are non-programmers. The text source code is also easy to maintain because authors can use standard text editors.
• The text description is highly functional, allowing for callouts to other dynamic decision trees, to websites, and to databases.
• The reader interface guides the reader through questions starting at the root of the decision tree. The interface makes visible to the reader only those nodes that are still possible based on the answers to those questions, thus limiting the cognitive load to the reader.

At a theoretical level, one can ask which kinds of knowledge should be encoded in human-designed rules rather than being inferred by large language model-style machine learning. The general answer, we believe, is that dynamic decision trees enjoy a comparative advantage in settings, where there are many variables and where each variable can take one or more values. We re-visit this assertion in the conclusion. Let us start by showing the functionality of dynamic decision trees.

Plan of the Paper

We first show how readers and authors interact with the system in Section 2 as well as the user interface guidelines we followed; we present special authoring commands in Section 3, a case study in Section 4, closely related work in Section 5, and functionality comparisons with similar systems in Section 6.

To see how to interact with the system both as a reader and writer, please see the site http://ec2-3-95-178-149.compute-1.amazonaws.com:8080/ (accessed 15 April 2024). Click on a radio button corresponding to an application you are interested in, and then click "Submit" to explore. Alternatively, you can create text for an application of your choice in the format described here below, paste that text into the window, and hit “Submit”.

2. Dynamic Decision Trees in Action

A decision tree is conventionally (e.g., in patents) represented as a diagram. In this case, a very primitive decision tree starts by posing the question of whether a reader is happy. If the reader says “yes”, then the reader arrives at the decision tree node “Then great”. Otherwise, if the reader says “meh”, then they are told to “get a lollipop”, and if that helps (the “yes” branch from the lollipop diamond), they are again told “Then great”; otherwise, they are told to “get more lollipops”. If the answer to the original question is “no”, then the reader is told to “see a psychologist” (a “shrink” in English slang).

In our system, decision trees are authored in a certain text format. Here is the same decision flowchart as an authored text file.

• Are you happy?
• --if yes, Then great
• --if meh, Then get a lollipop. Did that help?
• ----if a lot, Then great
• ----if a little, Then get another one
• --if no, Then see a shrink

In this format, a question q ends with a question mark and is prefixed with k hyphens, where k is an even number 0 or greater. Such a question q must be followed by at least one non-question or a question preceded by $k+2$ hyphens.

Thus, two hyphens indicate a level in the tree. This means that if the reader is at the fourth level of the tree, the syntax for that line begins with eight hyphens.

All questions must end with a question mark, and all non-questions must not. Each line after question q begins with “if X”. When the reader views the box containing question q, “X” is shown to the reader in the box’s drop-down menu corresponding to the current question q. If readers select X, they view the new box containing a question or possible conclusion in addition to the previous box containing question q.

The decision tree is displayed to reader users as a flowchart that unfolds as the user selects answers to decision questions as shown in Figure 1, Figure 2, Figure 3 and Figure 4. When the reader does not know the answer, the reader can choose “NotSure”, which results in arrows pointing to all possible child nodes, as we see in Figure 5.

2.1. Searching

In addition to answering questions, a reader can search for keyword phrases and select from among the boxes that contain that phrase. Each box represents one node. There are three categories of nodes to choose from:

(i)

Boxes in the tree so far (already visited nodes).

(ii)

Boxes reachable from the current tree (nodes reachable from visited nodes).

(iii)

Other boxes (neither reachable nor visited nodes).

Searching can help readers find a path to a desirable destination node. This could be useful in a legal argument, for example, where a reader wants to frame strategies that result in an admission by a witness. If exactly one box in the larger decision tree contains the keyword, the system immediately displays the box containing the keyword. Otherwise, as in the example of Figure 6, we see the results of searching for the word “great” in our example application.

2.2. User Interface Guidelines Followed

While our interface is far from flashy, our design follows common principles of user interface design [7], as we discuss here below:

• Consistency and standards: The decision tree adheres to the principle of consistency, using similar colors, shapes, and layouts across all nodes. This helps readers navigate through the interface without surprises.
• Visibility of system status: The decision tree clearly indicates the current step in the process and offers alternative paths forward in the form of possible answers to the current question, thus asking readers to make local decisions in modifying the current state of their search. Readers can navigate non-locally by using the "Search" function.
• User control and freedom: The UI allows readers to select their choices through drop-downs, checkboxes, text input, and radio buttons. So, readers control their navigation through the decision tree.
• Labeling and instruction clarity: The question boxes pose questions and offer pull-downs that are entirely standard. The zoom capability and the instructions within the search box are self-contained. Our philosophy has been to eliminate the need for instructions by making the choices clear.

There are several aesthetic improvements that we plan for future work.

• Color coding: Using a color-coding scheme to differentiate between decision points and outcomes could help users better understand the flow through the tree.
• Visual cues: Implementing visual cues such as highlighting the current step and allowing selective zooming are among the enhancements we are considering.
• Dynamic box layouts: Resizing and repositioning boxes based on the number of boxes displayed and the amount of text in each box could minimize the need for users to scroll both within the page and within each box.

Other areas of improvement include enhancements for the visually impaired. The current design relies heavily on visual elements like drop-downs and radio buttons, which pose challenges to screen readers. Furthermore, because the content and structure are not presented in a linear manner, screen readers will have trouble determining what to read. We currently envision three enhancements in future work:

• Eliminate dependency on the mouse: It should be possible to manipulate the system entirely from the keyboard.
• Screen reader compatibility: To enable a screen reader to help a visually impaired person navigate through a dynamic decision tree, it would be essential to ensure that all elements, such as drop-downs and buttons, are labeled with descriptive text that screen readers can interpret. This includes ensuring that the order of elements in the DOM (Document Object Model) matches the logical flow of the decision tree.
• An alternative enhancement for the visually impaired is to support a purely voice-controlled interface.

3. Authoring a Dynamic Decision Tree

The following authoring commands allow authors to include hyperlinks, references to other dynamic decision trees and databases, and input and output to databases. As mentioned in the introduction, you can test this functionality by placing text into the box and clicking “Submit” at this website: http://ec2-3-95-178-149.compute-1.amazonaws.com:8080/ (accessed on 15 April 2024).

• Hyperlinks: If the authored text contains the keyword DOCUMENT, the system converts everything after “DOCUMENT:” into a clickable hyperlink. For the command to work as intended, all text after “DOCUMENT:” must be a valid URL. For example, if the author wrote “If Yes, Check out this link: DOCUMENT: https://apple.com, the current node would contain “Check out this link: DOCUMENT: https://apple.com”, where “https://apple.com” is a hyperlink to the URL “https://apple.com”.
• Reducing repetition in authoring: When constructing decision trees, authors may find that they have to repeat subtrees. For example, if two sequences of answers lead to the same diagnosis, the treatment options to present to a patient may be the same. Repeating text is both time-consuming and may result in inconsistencies if that text is changed in one place but not in another. The DECISIONTREE command solves this by allowing authors to repeat subtrees without rewriting them multiple times. The subtree is first stored in a text file in the text format of a complete dynamic decision tree. To insert a subtree into the larger decision tree, authors can use the DECISIONTREE command in the line followed by the URL of the subtree’s text file. The system then extracts the subtree text file from the link in the node and combines the decision tree from the link with the current one, forming a larger decision tree. When the reader clicks “show next”, they can continue interacting with the linked subtree as if it was a part of the original decision tree. See the box at the beginning of Section 4, as well as Figure 7 and Figure 8 for an example.
• Collecting data from the reader: If the author’s line contains the keyword INPUT, the system displays a message to input a number to the reader. The prompt message is the substring after the first colon following the INPUT keyword and before the next special keyword. The system waits until something is input. Pressing “cancel” or the escape key prompts the reader to input a value again. Only by pressing the “OK” button can the reader avoid recording an input value. That in turn may cause an error later if a query that should include the reader’s input is executed. The author can set up several inputs, each having a distinct name. Names can be individualized by adding any characters after an INPUT keyword and before a following semicolon. For example, if the author’s line is “INPUT123: Enter a number:”, the reader is prompted to “Enter a number:” and the value the reader enters is stored in a dictionary of inputs with the key-value pair “INPUT123” and the reader-entered value. See the box at the beginning of Section 4 and Figure 9 for an example.
• Accessing a database: Suppose the author’s line contains the keyword QUERY. In that case, the system passes the substring between “QUERY:” and the following RETURN keyword into the back end, along with the dictionary of inputs mentioned above. The system then replaces all instances of dictionary keys (e.g., INPUT123) in the query with their corresponding values. Finally, the system executes a SQLite query, which can include any inputs previously received from the reader. For example, if the author’s line is “QUERY: SELECT (INPUT1 * INPUT2)", the system passes the string “SELECT (INPUT1 * INPUT2)” into the back end. Then, “INPUT1” and “INPUT2” in the query are replaced with their corresponding values, and the query is executed. See the box at the beginning of Section 4 and Figure 10 for an example.
• If the author’s line contains the keyword RETURN, the system displays a message with “RETURN:”. Note that this command applies only when using the QUERY command. If a return message includes the keyword RESULT, the RESULT keyword is replaced by the query results. The system then displays the author’s return message, including the query results. For example, the line “QUERY: SELECT (1 + 1) RETURN: The answer is RESULT” shows the reader “The answer is 2” in the current node.

The following steps reflect how the system receives user inputs, executes queries, and returns a message to the user based on query results:

• User Input Handling: If the line contains the keyword “INPUT”, the user is prompted to input a string, and the user input is stored. Note that one line can contain multiple “INPUT” keywords, in which case the system prompts the user for an input multiple times and stores each input.
• Query Extraction: If the line contains the keywords “QUERY” and “RETURN”, The substring between “QUERY:” and “RETURN:”, along with any previous user inputs, is passed into the back end.
• Query Processing: If the query contains an “INPUT” keyword, the system replaces each input keyword with the user’s corresponding input.
• Query Execution: The back end executes the query substring as an SQLite query and stores the result as a string.
• Return Message Processing: The return message is defined as the substring after “RETURN”. If the return message contains the keyword “RESULT”, the query result replaces the keyword “RESULT”.
• Final Output: The user sees the updated return message in the current node.

User input and database query functionality are demonstrated in a case study on home appraisal, explained in Appendix A. The software architecture enabling our system’s functionality for authors and readers is detailed in Appendix B.

4. Fully Functional Dynamic Decision Tree: Case Study

Let us explore a decision tree that asks the reader basic questions and uses all of the special authoring commands above. You can access this decision tree by clicking the “Test Input” radio button on our site.

• Are you happy?
• --if yes, Then great
• --if meh, Then get a lollipop. did that help?
• ----if a lot, Then great
• ----if a little, Then get another one
• --if no, Would any of these topics cheer you up: NYU, myeloma, Apple?
• ----if interested in NYU, DOCUMENT: https://www.nyu.edu
• ----if interested in myeloma, DECISIONTREE: https://elliot2878.github.io/decision_tree.github.io/myeloma.txt
• ----if interested in Apple, Which category of Apple products are you interested in?
• ------if interested in iPhone, QUERY: SELECT product_name FROM apple_products WHERE category = ‘iPhone’ RETURN: Which of the following iPhones are you interested in: RESULT?
• --------If iPhone 15 Pro, QUERY: SELECT product_link FROM apple_products WHERE product_name = ‘iPhone 15 Pro’ RETURN: You can find this product here: DOCUMENT: RESULT
• --------If iPhone 15, QUERY: SELECT product_link FROM apple_products WHERE product_name = ‘iPhone 15’ RETURN: You can find this product here: DOCUMENT: RESULT
• --------If iPhone 14, QUERY: SELECT product_link FROM apple_products WHERE product_name = ‘iPhone 14’ RETURN: You can find this product here: DOCUMENT: RESULT
• --------If iPhone 13, QUERY: SELECT product_link FROM apple_products WHERE product_name = ‘iPhone 13’ RETURN: You can find this product here: DOCUMENT: RESULT
• ------if interested in iPad, QUERY: SELECT product_name FROM apple_products WHERE category = ‘iPad’ RETURN: Which of the following iPads are you interested in: RESULT?
• --------if iPad Pro, QUERY: SELECT product_link FROM apple_products WHERE product_name = ‘iPad Pro’ RETURN: You can find this product here: DOCUMENT: RESULT
• --------if iPad Air, QUERY: SELECT product_link FROM apple_products WHERE product_name = ‘iPad Air’ RETURN: You can find this product here: DOCUMENT: RESULT
• --------if iPad (10th Generation), QUERY: SELECT product_link FROM apple_products WHERE product_name = ‘iPad (10th Generation)’ RETURN: You can find this product here: DOCUMENT: RESULT
• --------if iPad (9th Generation), QUERY: SELECT product_link FROM apple_products WHERE product_name = ‘iPad (9th Generation)’ RETURN: You can find this product here: DOCUMENT: RESULT
• --------if iPad Mini, QUERY: SELECT product_link FROM apple_products WHERE product_name = ‘iPad Mini’ RETURN: You can find this product here: DOCUMENT: RESULT
• ------if interested in Mac, QUERY: SELECT product_name FROM apple_products WHERE category = ‘Mac’ RETURN: Which of the following Macs are you interested in: RESULT?
• --------if Mac Pro, QUERY: SELECT product_link FROM apple_products WHERE product_name = ‘Mac Pro’ RETURN: You can find this product here: DOCUMENT: RESULT
• --------if Mac Studio, QUERY: SELECT product_link FROM apple_products WHERE product_name = ‘Mac Studio’ RETURN: You can find this product here: DOCUMENT: RESULT
• --------if Mac Mini, QUERY: SELECT product_link FROM apple_products WHERE product_name = ‘Mac Mini’ RETURN: You can find this product here: DOCUMENT: RESULT
• --------if iMac, QUERY: SELECT product_link FROM apple_products WHERE product_name = ‘iMac’ RETURN: You can find this product here: DOCUMENT: RESULT
• --------if Mac MacBook Pro 16, QUERY: SELECT product_link FROM apple_products WHERE product_name = ‘MacBook Pro 16’ RETURN: You can find this product here: DOCUMENT: RESULT
• --------if Mac MacBook Pro 14, QUERY: SELECT product_link FROM apple_products WHERE product_name = ‘MacBook Pro 14’ RETURN: You can find this product here: DOCUMENT: RESULT
• --------if Mac MacBook Air M1, QUERY: SELECT product_link FROM apple_products WHERE product_name = ‘MacBook Air M1’ RETURN: You can find this product here: DOCUMENT: RESULT
• --------if MacBook Air 13-inch M2, QUERY: SELECT product_link FROM apple_products WHERE product_name = ‘MacBook Air 13-inch M2’ RETURN: You can find this product here: DOCUMENT: RESULT
• --------if MacBook Air 15-inch M2, QUERY: SELECT product_link FROM apple_products WHERE product_name = ‘MacBook Air 15-inch M2’ RETURN: You can find this product here: DOCUMENT: RESULT
• ------if interested in Apple Watch, INPUT1: Enter the name of the Apple Watch you are interested in. Your options are ‘‘Apple Watch Series 9’’, ‘‘Apple Watch Ultra 2’’, or ‘‘Apple Watch SE’’ QUERY: SELECT product_link FROM apple_products WHERE lower(product_name) = lower(INPUT1) RETURN: You can find this product here: DOCUMENT: RESULT

The figures below show how readers might interact with the tree.

If the reader selects “not interested” to “Are you happy?” and the reader is “interested in myeloma”, they reach the node represented by the following authored text:

• DECISIONTREE: https://elliot2878.github.io/decision_tree.github.io/myeloma.txt

By selecting “show next”, the reader can interact with the correctly formatted decision tree in the hyperlink after “DECISIONTREE:” as if it was a subtree in the larger decision tree.

By answering that they are not happy but are interested in Apple, a reader can select their favorite Apple product in the drop-down and view links to their chosen Apple product on Apple’s website. Authoring these capabilities begins in the Python back end. By executing an SQLite query in the back end, the author creates a table called “apple_products”, with columns “category”, “product”, and “link”. The author then populates the table with all of the Apple products [8] included in the decision tree text file below (e.g., iPhone 15 Pro, Mac Studio, Apple Watch SE) along with their corresponding links and categories. Once the table is created and populated, the rest of the decision tree can be developed with simple text authoring.

If the reader indicates an interest in iPhones, for example, the node corresponding to that choice has the following text:

• QUERY: SELECT product_name FROM apple_products WHERE category = ‘iPhone’ RETURN: Which of the following iPhones are you interested in: RESULT?

This line can be split into two parts:

1.

QUERY: SELECT product_name FROM apple_products WHERE category = ‘iPhone’

Because the “QUERY” keyword appears, the system automatically passes the substring after “QUERY:” and before the following RETURN keyword into the back end. The system executes the query, resulting in “‘iPhone 15 Pro’, ‘iPhone 15’, ‘iPhone 14’, ‘iPhone 13”’.

2.

RETURN: Which of the following iPhones are you interested in: RESULT?

The return message, defined as the substring after “RETURN:”, is also passed into the back end. Once the query is executed, the string result of the query replaces the “RESULT” keyword in the return message. If the author wanted to return the exact query result to the reader, they would end the line with “RETURN: RESULT”.

In this case, the return message is converted from “Which of the following iPhones are you interested in: RESULT?” to “Which of the following iPhones are you interested in: ‘iPhone 15 Pro’, ‘iPhone 15’, ‘iPhone 14’, ‘iPhone 13’?”. The new box representing a node is created and shown to the reader, containing the modified return message. After the reader indicates they are interested in iPhones, they can select one of the current iPhone models in the drop-down. If they select iPhone 15, for example, the author’s line corresponding to the current node reads,

• QUERY: SELECT product_link FROM apple_products WHERE product_name = ‘iPhone 15’ RETURN: You can find this product here: DOCUMENT: RESULT

This line can also be split into two parts:

• 1. QUERY: SELECT product_link FROM apple_products WHERE product_name = ‘iPhone 15’

This part executes a simple query that results in “https://www.apple.com/iphone-15/”.

• 2. RETURN: You can find this product here: DOCUMENT: RESULT

After the query is executed, the query results replace the RESULT keyword in the back end, and then the modified return message is passed to the front-end. The modified return message is “You can find this product here: DOCUMENT: https://www.apple.com/iphone-15/”. The system’s front-end then detects the DOCUMENT keyword and converts the text following “DOCUMENT:” into a hyperlink. Finally, the reader sees “You can find this product here: DOCUMENT: https://www.apple.com/iphone-15/” in the current node, and the URL is a clickable hyperlink.

• INPUT1: Enter the name of the Apple Watch you are interested in. Your options are ‘‘Apple Watch Series 9’’, ‘‘Apple Watch Ultra 2’’, or ‘‘Apple Watch SE’’ QUERY: SELECT product_link FROM apple_products WHERE product_name = INPUT1 RETURN: You can find this product here: DOCUMENT: RESULT

This line can be split into three parts:

• 1. INPUT1: Enter the name of the Apple Watch you are interested in. Your options are ‘‘Apple Watch Series 9’’, ‘‘Apple Watch Ultra 2’’, or ‘‘Apple Watch SE’’

When the INPUT keyword is detected, the system prompts the reader to input a value. The user sees the substring after the first colon that follows “INPUT” and before the next keyword. (If no subsequent keyword is found, the prompt message ends at the end of the author’s line.) Here, the reader sees the prompt: “Enter the name of the Apple Watch you are interested in. Your options are “Apple Watch Series 9”, “Apple Watch Ultra 2”, or “Apple Watch SE””. The reader then enters a value.

Note that the author can write any string between “INPUT” and its following colon. This allows the system to store a unique key-value pair for each user input, so that keys may be referenced within queries of descendant nodes. This functionality is further demonstrated through a case study in Appendix A.

• 2. QUERY: SELECT product_link FROM apple_products WHERE product_name = INPUT1

The system replaces all instances of input keys with their corresponding values. Here, “INPUT1” is replaced with the user’s input string. The query is then executed and its results are stored.

If the reader inputs the value “Apple Watch SE”, for example, the query becomes “SELECT product_link FROM apple_products WHERE product_name = ‘Apple Watch SE’". The query is then executed, resulting in the plain text URL for the Apple Watch SE. In this case, the URL would be “https://www.apple.com/apple-watch-se/”.

• 3. ‘‘RETURN: You can find this product here: DOCUMENT: RESULT’’

The final part of the line works similarly to the previous examples. “RESULT” is replaced with the plain text URL from the query result, such as “https://www.apple.com/apple-watch-se/”, and the DOCUMENT keyword converts the URL to a valid hyperlink. The reader then displays “You can find this product here: DOCUMENT: https://www.apple.com/apple-watch-se/” in the current node.

5. Related Work

This section first considers the uses of decision trees in various fields. Then, it describes some other decision-making software tools that provide at least some of the features we seek: (i) easy to author, (ii) limited cognitive load on the reader, and (iii) capable of conveying expertise.

5.1. Uses of Decision Trees

Many researchers use decision trees for analysis in specific fields. For instance, the VIBEX (VIBration EXpert) system helps factory operators diagnose the causes of abnormal vibrations in rotating machinery [9]. In reverse engineering, Dugerdil and Sennhauser developed a new execution trace format and a tool to generate decision trees for each use case scenario, analyzing these trees to identify possible variants from the main scenario [10]. Other researchers use decision tree analysis to propose a formal procedure to accelerate decision making for urban sustainability [11]. Medical researchers introduced a decision tree approach to diagnose congestive heart failure [12]. Education researchers propose using decision tree models to analyze student data [13].

Thibault Schrepel proposes utilizing a decision tree system as part of a larger analysis in antitrust law [14]. His paper aims to assist antitrust agencies in creating a decision tree-based antitrust compliance API for market participants. This includes developing an open-access prototype that automates compliance with citation 102 of the TFEU. Specifically, after tracing the answers to a series of questions in the decision tree, users can determine whether they comply with citation 102 of the Treaty on the Functioning of the European Union (TFEU). This provision of EU competition law is designed to prevent companies from abusing a dominant position within the internal market.

Thus, decision trees are used for all kinds of specific applications. This makes sense because they are easily understandable and are excellent at encoding rules. That is why it is helpful to have a tool to encode them easily and navigate them in a cognitively intuitive way.

Tree-based systems are often extended to forests for the purposes of machine learning, e.g., [15,16]. Such systems are not directly comparable with ours because dynamic decision trees are primarily concerned with expressing rules and strategies rather than inferring a model from data.

5.2. Interactive Decision Tree Tools

The following tools ask readers to make evaluations based on specific categories; then, the tools make a recommendation by combining those ratings. The decision-making tool Protagonist (accessed 11 August 2024) [17] assists readers in making real-world evaluations. Protagonist offers a set of options and a set of categories that are pertinent to those options. For each category, readers evaluate each option from 1 to 10 in that category. Readers may optionally weigh each category from 1 to 10. (By default, each category is assigned the minimum weight.) Then, Protagonist calculates a weighted sum for each option and recommends the highest weighted option.

For example, in the “buy a house” decision process shown in Figure 11, Protagonist asks readers to rate features they like or dislike about the house. These properties include short-term affordability, desirable location, etc.

Once the reader has rated the categories of each home, the reader may weight each category. After entering “Analysis” mode, Protagonist recommends a house based on the reader’s preferences, as shown in Figure 12.

In the Figure 11 above, home 2 is recommended. In the case that a prospective author chooses their own topic, they must create categories they deem important. Readers would then evaluate each option within each category and assign a weight to each category.

The tool Best Decision (accessed 11 August 2024) [18] offers decision-making services for pre-selected topics. Similar to Protagonist, Best Decision allows readers to rank categories on a scale of 1–5. Best Decision then recommends a conclusion based on the reader’s preferences.

As shown in Figure 13 above, Best Decision offers decision-making services to help readers find a laptop. The reader begins by indicating the laptop models they are considering.

Next, as seen in Figure 14, the reader ranks the listed features based on importance from 1 to 5. The reader can also add features that the reader deems important in the decision-making process.

As shown in the Figure 15 and Figure 16, Best Decision then recommends a laptop for readers to buy based on their preferences. This process works for a variety of pre-selected and author-created decision topics.

In contrast to Protagonist and Best Decision, Zingtree (accessed 11 August 2024) utilizes a decision tree structure [19]. For example, in Figure 17, the system begins by assisting users in selecting iPhone models and then presents this decision tree in a question-and-answer format. If the user clicks on “iPhone is running slowly”, Zingtree displays the corresponding solution for this issue and then asks whether the provided solution is helpful.

Zingtree supports integration with various systems, apps, and websites. Zingtree authors can present information to users that is stored in a Google Sheet using a “webhook”. Zingtree can perform mathematical operations for users as shown in Figure 18.

One distinction between Zingtree and our dynamic decision tree system lies in reader navigation. Zingtree does not display the relevant part of the decision tree structure to readers, nor does it permit readers to jump to a specified node, other than the previous or the first node. By contrast, our system’s search functionality offers readers the ability to navigate far from the current node.

Yonyx (accessed 11 August 2024) is quite similar to Zingtree [20]. Yonyx supports API calls to read and write data from various applications, as well as mathematical operations. Figure 19 shows the Yonyx system in action for a health insurance fee estimator.

Yonyx has a graphical authoring interface that incorporates search functionality. Authors can search the entire tree using various parameters; e.g., authors can use them to find nodes containing specific text. However, Yonyx does not allow readers to search within a decision tree.

5.3. Analytical Hierarchy Process

Other decision aids work in a bottom-up manner using a weighted quantitative approach. A prominent technology is called an analytic hierarchy process (AHP) [21]. The idea is to come to a decision by evaluating several criteria about each alternative through pairwise comparisons. AHP calculates weights for each criterion based on user responses and then calculates a weighted sum for each option. For example, to choose a car, one might evaluate different alternative car models based on criteria such as fuel economy, resale value, price, comfort, and roominess. An AHP assigns a weight to each criterion and arrives at a numerical score for each model type. As another example, Dey shows a quantitative method for managing construction risks using AHPs [22].

Thus, AHPs are bottom-up approaches for breaking down the considerations leading to a decision. By contrast, dynamic decision trees, when used for a product choice as in the example of purchasing Apple products in Section 4, gather selection criteria and then choose relevant products that the reader can evaluate as a whole. In environments where tradeoffs should be considered, AHPs are better. In environments where users are still uncertain but can express basic requirements to narrow the choices, dynamic decision trees enjoy a comparative advantage. Dynamic decision trees also enjoy a comparative advantage when expressing strategies, as in a legal argument.

5.4. Decision Tree Drawing Tools

Some software systems, such as Miro, Diagrams, and Creately, (accessed 11 August 2024) allow users to draw and edit decision trees [23,24,25]. However, these decision trees are not interactive. Users simply view the entire decision tree structure at once. For small decision trees, this works well, as we can see in Figure 20, Figure 21 and Figure 22. However, this may result in a high cognitive load and navigation troubles to the reader when viewing larger decision trees.

6. Functionality Comparison with State of the Art Systems

Dynamic decision trees differ in their authoring interface from the above systems by allowing a simple text input. Dynamic decision trees extend the functionality of these services by offering functionalities like a search for readers. This enables dynamic decision trees to provide roadmaps to end with a possibly desirable or undesirable conclusion. For example, in a legal context, a dynamic decision tree could provide a line of questioning that might lead a witness to admit to some guilty act. The database functionality allows access to large collections of data (e.g., about housing, as we show in Appendix A).

We will now explore two use cases requiring expertise: trigonometry and debate arguments. We start with trigonometry.

Find the value of a in the triangle below (note: image not drawn to scale).

In the problem above, one is given the length of the hypotenuse and the angle between the hypotenuse and a leg. One must use the cosine function to find the adjacent leg.

$$\begin{array}{cc}\hfill & \hfill cos\left({32}^{\circ }\right)={\displaystyle \frac{a}{20}}\hfill \\ \hfill \iff & \hfill a=20cos\left({32}^{\circ }\right)\hfill \end{array}$$

Suppose that someone understood the question but did not know how to solve this problem. Our trigonometry decision tree (Figure 23 and Figure 24) could assist in solving this problem. The text file for this decision tree can be found in Appendix C.

The leaf box in this subtree provides a formula and an example to help the user solve the problem. Here is the text:

• Calculate the length of the leg by multiplying the hypotenuse length by the cosine of the given angle (Ex: If Hypotenuse = 5, angle = 60, find Adjacent side: Adjacent = 5 ∗ cos(60) = 2.5).

A reader thus learns that $a=20cos\left({32}^{\circ }\right)$, which can be approximated if necessary. Such information can easily be encoded in a dynamic decision tree by a subject matter expert without programming experience.

Decision trees can also be used to encode debate arguments but also to arrive at a desired goal as the debate evolves. That is, party A in a debate could benefit from using a decision tree to track opponent B’s arguments and then respond. For example, consider the question of whether technology makes people more antisocial and more lonely. The decision tree we created can be used to argue that technology does not create that result. The text file for this decision tree can be found in Appendix D.

When the reader selects “Yes” to the initial question in Figure 25, it is as if our opponent has engaged in the debate. To counter that assertion, the dynamic decision tree leads us to the node “Why would this be the case?”. When the “opponent” selects a reason, the dynamic decision tree proceeds to a node with an apt response.

For example, if the reader selects “social media creates unrealistic expectations”, the following box contains a response:

• Social media is also a place where people with similar struggles can interact and support each other. Many digital groups are dedicated towards mental health and support. However, doesn’t this seem like social media is trying to solve the insecurities it creates?

The reader may make this counterargument. The final sentence in the box is a follow-up question the opponent reader may ask.

The reader can also use our search functionality to quickly locate particular arguments. For example, by searching “self-esteem”, a reader can immediately find a study within the decision tree stating that teenagers believe that social media boosts their confidence.

In combination, as shown in

Table 1. Each product and its capabilities for readers. “Yes” means the product has the capability to support the application in the column; “No” means that it does not. For authors, dynamic decision trees are unique in allowing for a purely textual input.

Product Name	Product Choice Application	Problem-Solving e.g., Trigonometry	Complex Rules e.g., Debate	External Data Integration	Search Functionality
Protagonist	Yes	No	No	No	No
Best Decision	Yes	No	No	No	No
ZingTree	Yes	Yes	Yes	Yes, using Google Sheets webhook integration	No
Yonyx	Yes	Yes	Yes	Yes, through API calls	Yes, but for authors only
Dynamic decision tree	Yes	Yes	Yes	Yes, using an SQL database	Yes

, dynamic decision trees contain unique features that support both authoring and reading subject matter that requires expertise.

7. Conclusions

The dynamic decision tree system allows non-programmers to author decision trees for rule-based topics in an intuitive format. Readers navigate the decision tree both locally by answering a question at the current node or globally through the search functionality. To reduce cognitive load, at any moment, only the nodes that are still possible (i.e., that have not been excluded by previous answers) of the decision trees are visible.

Implications of this Work

While dynamic decision trees present a way to express rule-based knowledge, there may be other ways to represent this knowledge. The common current methods are as articles and videos. Large language models extract knowledge from text at a high level of proficiency in medicine (e.g., OpenEvidence (https://www.openevidence.com/, accessed 3 August 2024)) and other areas [26]. A fair question to ask is what place an expert system like dynamic decision trees has given to the capabilities of machine intelligence. As we have seen in our examples, laws, strategies, and other areas of expertise may entail complex combinations of conditions, some of which may have never been seen before and may require precise answers. Because deep reasoning and hallucinations are weaknesses of LLMs, there is still a need for readers to be sure that a trusted expert author has entered the rules properly. At the same time, domain experts such as lawyers and doctors do not want to have to learn to program in order to convey their expertise. Dynamic decision trees thus fill an unmet need.

Future Work

Reader Shortcomings and Future Work

The reader interface is currently clear but not attractive and not friendly to the visually impaired. Future work therefore involves aesthetic and usability improvements, including:

• Support for advanced text formatting using TeX typesetting. This would allow for more versatile authoring capabilities, such as including complex mathematical formulas.
• Interfaces for mobile devices.
• Deeper improvements include support for the visually impaired as outlined in Section 2.2.

Authoring Future Work

Though we have removed the need for authors to write program code, the ideal remains a natural language approach that could take text from documents and encode the information into the hyphenated format of dynamic decision trees. We have in fact tried this, but it has not worked in our hands with the tools available at present. As large language models improve, so will their deep reasoning abilities.

A possible use of dynamic decision trees is to have multiple authors create decision trees about the same topic and then compare them either quantitatively using analytic hierarchy processes (AHPs) [21] or qualitatively. The qualitative comparison could determine whether some authors included criteria that others did not. Comparing decision trees semantically is an intriguing area for future work.