<< Click to Display Table of Contents >> RayQC > 7.3 u2 > User Guide > Checklist Structures > Basic Checklist Properties > Steps and Actions Elements |
Elements are the actually decisive objects within a RayQC checklist. They are defined within the XML based structure of the template file type (*.rqct), and come alive when result values are added to form a checklist project instance (*.rqcp)
As outlined before, there are some basic properties which are present for all element types within RayQC, whilst others are rather type-specific. The following summary is describing the general properties, whilst later sections go into individual details.
Elements are displayed as indented boxes within the group elements of checklists. The displayed content depends on the currently active application view (Checklist Viewer or Checklist Editor) and the selection status of the element.
The basic properties are named in the order of their position within the element boxes.
The index value is a dot separated list of hierarchical level values, displayed within the upper left corner of the element box representations. All elements have an explicit index value, unique within their parent group. The first digit group gives an outline of the position within the elements on the root level of the groups item tree structure. The second and all subsequent digit groups define the position of the item within the child element list of their parent element. The maximum depth of a checklist element hierarchy is 4, which leads to a position index length limitation of 4 levels (e. g. 1.2.3.4).
Users who evaluate the checklist refer to elements by their position index value, since the internal identifier (element id) is by default not visible for them. However, the index value is present in all checklist views and view modes.
The position index cannot be entered manually, but changed by moving the element, either dragging it up and down within the vertical evaluation sequence of elements, or using the left or right icons (which vertically changes the indent, and therefore the hierarchy level, but not the vertical sequence of elements).
If an element is not available for evaluation in the Checklist Viewer (e. g., due to condition restrictions), the position index value sequence of the parent group is not changed, which means that there may be gaps when the checklist is opened within the Checklist Viewer. (For example, an item number 7.3 may directly be followed by 7.5, due to a conditional availability of item 7.4)
Triggering index value changes by the appearance of dynamic tree branches of the checklist would surely lead to clear element identification issues, which is why living with gaps in the index sequence is the preferred operational method.
Each element has a specific, fixed type. Once an element has been added to a checklist, its type cannot be changed any more. The element type decides about options and controls available for an element, since each type has a unique purpose by design, which require different editor choices and possibilities.
Within the Checklist Viewer, evaluators recognize the item type by the result input controls. Information elements do not have result input controls, Data Field elements display a text input field, Checkpoint elements a radio button, and Multi-Option elements a selector control. Within the Checklist Editor, authors recognize the type by the icon displayed within elements box representation.
Please refer to the upcoming Element Types section for further details.
The element ID is the internal identifier of elements, used for example to share item result values between items and their conditions, plug-ins, and the like. Prior versions of RayQC revealed the ID within the Editor or Viewer interface in order to allow users to manually establish relations between elements. However, thanks to the advanced Editor interface with its drag & drop capabilities, there is no longer need for manual relation definition. Therefore, neither element ID's, nor group ID's are displayable within the application views. If users have to find out about these properties, they have to open the underlying checklist structure XML file with an external editor.
Each element has a description property, designed to contain the task description given for the current checklist item. The Information type for example usually does not consist of much more than the description property.
The text can contain RayQC specific format markup tags to allow editors to add some structure, or even descriptive images, to their task definitions.
It is recommended to outline not only instructions on the actual task, but also note conditional options and dependencies set upon the item within the text.
Note: If the description alone does not provide enough possibilities to give the full task description, each item may be augmented with an additional help file. BUT: the text of an element is always plain to see, whilst help files have to be brought to view by clicking on the help icon optionally displayed within the elements box representation in the Checklist Viewer mode. |