8.2 Distributing Content to Project Files and Tasks
The CBA ItemBuilder’s flexibility for creating assessment components with multiple pages requires planning how the content should be distributed as either one or in multiple Tasks (i.e., entry-points) and Project Files (i.e., zip archives).
Assessments created with the CBA ItemBuilder are composed of Tasks. Tasks are stored in Project Files that share their resources (e.g., images, videos, audio files). All test deployment tools described in chapter 7 can be used to administer either a single Task or a linear sequence of Tasks. While this is sufficient for typical data collections using only one booklet or a set of fixed booklets, adaptive testing (including multi-stage tests) can require to analyze responses live during the assessment to select the appropriate subsequent Task (or multiple Tasks such as stages).
Assessment material will be used as shown in Table 8.3 to collect data with a particular test design (i.e., implementing a particular test assembly strategy), using either manual or automated test assembly (see section 2.7) or booklets. Typically, in a calibration (or field trial) study, the first version of a newly developed test (i.e., a more extensive selection of items implemented, for instance, in CBA ItemBuilder project files) is administered. After investigating item properties (such as item fit, see section 2.5), items are slightly modified, and a selection of items is used to create the test(s) using the test assembly approach of choice.
| Test Design and Assembly |
|---|
| Test Assembly Specification |
| Booklet Definition |
For many use cases, the following five rules are helpful in deciding how to distribute content to Tasks and how to distribute Tasks to Project Files:
All content that is always administered together should be in one task. For example, if the items that belong to a shared stimulus form a unit, then each unit should be created as a task.
Content that might be separated after a revision or item selection should be put into different tasks. This ensures that the CBA ItemBuilder tasks need as little revision as possible after a field test.
Tasks that refer to the same pages or resources should be placed in one CBA ItemBuilder project file. This avoids repeated copying of content (e.g., images, videos, etc.).
If information from an item is needed, for instance, for a subsequent filter or jump rule, then the items involved can, in the simplest case, be placed in one task. In this way, the CBA ItemBuilder project files remain as independent as possible from the specific functions of the test delivery software.
Generally, the tasks (and the CBA ItemBuilder project files) should be as small as possible. This will save time inspecting and previewing the items and allow different persons to work on different parts of the assessment.
A more detailed, albeit complicated, description of the dependencies is summarized below:
Each CBA ItemBuilder Task will always contain at least one page with at least one item. However, multiple pages (and multiple items) within a single Task are possible. In order to guide the possibilities to optimize the distribution of items to Tasks and Tasks to Project Files, but also to discuss dependencies and potential limitations, the following section summarizes what needs to be considered when planning the use of Project Files with multiple Tasks.
Tasks: Tasks are the entry-points the test-deployment software can use (see section 3.6). The primary role of a Task is to define the first page (or the first page and an additional X-Page), shown after an assessment component has been loaded. Only one Task can be used at once. If multiple items should be visible simultaneously, the items need to be on the same page and shown within the identical Task (see section 2.4 for details about test design, item presentation and navigation).
Runtime Commands: Runtime Commands (see section 3.12) can be used to trigger action from the current Task to the test deployment software, for instance, to request a navigation to the next or the previous Task. Test-taker can trigger a Runtime Commands, when the Runtime Command is attached to components (e.g., Buttons). Runtime Commands can also be triggered either by timers or by any component that can be linked to Events (i.e., Runtime Commands can be triggered as operators in rules defined in the Finite-State Machine, see section 4.4.6).
Pages: Tasks show either single pages (one at a time) or multiple pages simultaneous (either using X-Page layout, see section 3.4.2, as Page Areas, see section 3.5.4 or using dialog pages, see section 3.15). Each Page can be used in a Task multiple times and different Tasks within one Project File can share Pages (i.e., different Tasks can use the same Pages). Links (see section 3.11) and Conditional Links (see section 4.3) can be used to navigate between Pages.
Finite-State Machine: The internal logic layer of the CBA ItemBuilder (i.e., one or multiple Finite-State Machine(s), see section 4.4) is defined for each CBA ItemBuilder Project File (i.e., multiple Tasks) share the identical Finite-State Machine definition(s). However, the Task Initialization syntax (see section 4.5) can be used to prepare the general Finite-State Machine definition for a particular Task.
Variables: In addition to the finite-state machine definition, variables in CBA ItemBuilder Project Files are also globally defined and valid for all Tasks.
Summary: The use of multiple Tasks within one Project Files requires additional considerations to make sure, the Tasks can be used independently. Dependencies can arise based on links (see section 3.11) and conditional links, the Finite-State Machine(s) (see section ) and variables (see section 4.2). If information or results within parts of an assessment needs to be shared, for instance, using Variables provided by the Finite-State Machine, these assessment components must be implemented with one Tasks (see, for instance, the examples provided in section 6.4.2).
Assessment content (i.e., items, units or clusters) distributed in booklet designs, for instance, used in balanced (incomplete) block designs, must be distributed into different Tasks to enable an test deployment software to assemble the tests as required. Similarly, for item-level adaptive testing or unit-level adaptive testing, the entities that are selected adaptively from an Item Pool must be implemented in separate Tasks.
Finally, if identical resources are used in different Tasks (for instance, audio and video files), the Tasks should be implemented in one Project File to reduce redundant files that need to be deployed (and maintained).