Important aspects of dynamic checklist evaluations are conditional statements. In RayQC, users are able to define a combination of several conditional statements, which may decide about the actual evaluation path of a checklist. For example, if the result of Checkpoint A is TRUE and the result of Multi-Option B is FALSE, checklist group X has to be evaluated. If not, checklist group X is invisible and does not affect the result of the checklist. Conditions may be applied to single elements as well as to complete group objects.
The logical idea of Conditions in RayQC 8.0 is based upon the so called "disjunctive normal form" (DNF), which allows building any kind of condition as a combination of ORs between ANDs. To be more precise: A DNF is a disjunction of conjunctive clauses. Within our checklist editor, clauses are called buckets. Within each bucket, there may be several conditional statements, but all have to evaluate to TRUE in order to let the bucket evaluation result become TRUE. If the condition for an element contains more than one of those buckets, it is sufficient to have one bucket evaluate as TRUE to let the whole condition evaluate as TRUE. So you see, the buckets contain a number of ANDs, and are chained by ORs.
Handling conditions via the RayQC Checklist Editor user interface has been adjusted to follow the latest RaySuite interface guidelines: Adding a condition to an element is achieved by a combination of drag and drop operations, followed by selections from predefined drop-down controls:
A Multi-Option element with an already existing condition, containing one bucket with one conditional statement that needs to be extended.
To add another clause to the condition, the decisive element has to be dragged...
... to the drop area of the existing bucket (or below to open a new bucket).
At the end the user just needs to select the expected result for a true conditional clause evaluation from the automatically added bucket item.
Conditions specified for a certain item decide, whether or not the item itself is available for user interaction in the Checklist Viewer interface. The results of unavailable items will not be considered when the overall checklist result is calculated.
The number of conditional statements is limited by logical restrictions Conditions have to stand up against:
•A Condition controls the availability of the checklist item (or group) that contains the conditional statements..
(It is not possible to define a Condition in item A that controls the availability of item B or group C.)
•A conditional statement can only target checklist item results.
(It is not possible to define the availability of an element dependent on the availability of another element or a group.)
•A conditional statement targets exactly one Checkpoint or Multi-Option element result value.
(It is not possible to check against the textual result of Data Field elements.)
|
Hint: To check against the textual result of Data Field elements, use functions like: ContainsString, CompareValue, or NumberInRange. |
•A conditional statement can only refer to results of items that are listed higher within the checklist item sequence (e. g. in a prior group or with a higher position within the same group as the item that includes the conditional statement definition).
Therefore, the first item within a checklist may not be bound to Conditions, since there are no prior item results to validate against.
•A Condition is evaluated to be either true or false.
If it evaluates to true, the item (or group) is automatically available for processing within the Checklist Viewer.
•A Condition is by default evaluated to true if all of the conditional statements evaluate true.
(Item evaluation is by default executed in conjunction mode (i.e. statements are combined by logical AND operators.)
It is possible to change the default assessment method to disjunction mode, i. e. conditional statements are combined by logical OR operators, please see below.
•A Condition always controls the availability of the owning object along with all direct children of that object (e.g., all elements and sub-elements of an unavailable group are unavailable as well).
|
Be aware: When Conditions are heavily used, it may happen that a user loses track of the actual evaluation path. Since it is possible to add conditions regarding the result of conditional objects, it is actually possible to create conditional statements that may never result in the availability of a certain group or element. Therefore, it is highly recommended to double-check conditional constructs, and additionally use the Validate Conditions button from the Swipe bar, which is available in the Checklist Viewer. If the check returns issues, these should be cleared before the checklist is deployed for productive use. |
|
Note: The items stored within a checklist group are indexed. If an item is not available for user interaction, its index number is missing from the present checklist number sequence. This choice of checklist interface design leads to the fact that users may very well notice that there are items which are not visible or accessible for them. However, providing a stable index reference for each checklist item, independent from the current availability for evaluation, is considered more important from an organizational / communicative point of view, than the absence of any indicators regarding conditional items. |
To Activate This Option
1.Within the Checklist Editor, scroll to the checklist item that should only be available under certain circumstances.
2.Select the element with a left-click and select the Conditions tab on the Details pane.
|
Be aware: The Conditions tab itself is permanently displayed for all checklist items and groups. However, if there is no checklist element present that might actually be evaluated for conditional statement definitions, users are simply unable to drop items into it. |
3.Drag any Checkpoint or Multi-Option element that resides earlier within the checklist structure to the Conditions tab, and drop it there. If it is the first drop, a new bucket is created automatically. If one or more buckets for conditional phrases are already present, the new one will either be added to one of the existing buckets, or wrapped into a new one - dependent on the exact position of element dropping. Please observe the hover effect shown by RayQC as soon as an element is dragged into the Details pane area to get info about the target object: new or existing bucket.
Please keep in mind, that the conditional statements within one bucket are evaluated in an AND relation: All statements have to evaluate to true in order to have the bucket evaluated to true. The buckets themselves are related by OR operators: If one of the buckets evaluates to true, the whole condition is regarded to be true, which allows the parent element (or group) to be seen (and evaluated) by users within the checklist viewer.
|
Be aware: Checkpoint elements may have an active Expected Value option, setting the "correct" result to NO. |
4.Save the changes made to the checklist and switch to the Checklist Viewer mode.
5.Use the Validate Conditions button from the Swipe bar to make sure no invalid conditional statement combination has been created.
If there are issues returned from the check, click on the MORE button within the info dialog to get details regarding the incorrect statements. Resolve the issues and re-run the check until no further issues are reported.
6.Check whether the item becomes available as the expected combination(s) of evaluation results are selected.