試行タイムライン

試行タイムラインは、1回の試行のための構造化された設計図として機能します。これは、参加者に提示されるすべての要素の順序とタイミングを決定します。これには、刺激、相互作用、および反応の収集が含まれます。これらの要素を明確な順序で整理することで、試行タイムラインは一貫性と正確な実験制御を保証します。

重要: 試行タイムラインは、1回の試行のみを表します。実験全体ではありません。複数の試行タイムラインを組み合わせて、実験タイムライン内で繰り返すことで、完全な実験を作成できます。

試行タイムラインの範囲

試行タイムラインは、単一の試行インスタンスに限られます。それは、その1回の実行サイクル内で何が起こるかを定義するのみで、試行の開始から完了までを含みます。

試行タイムラインは次の目的には使用されません 🚫これは、試行タイムラインがデフォルトで次の情報を含まないことを意味します：

• 試行が何回繰り返されるか
• 全体の研究内での試行の順序
• 異なる条件やブロックの構成
• 実験の非試行要素

その主な役割と正しい使用法は、1回の単一の試行の内部構造を厳密に定義し、表現することです。これは、その後、より広い研究デザインでどのように使用されるかには依存しません。

試行の構造

実験の各試行は、一連のフレームから構成されており、各フレームは参加者をタスクに導く特定のステップや画面を表します。

フレームの順次フロー

試行タイムラインは、試行内の個々のステップであるフレームで構成されています。各フレームは、異なる画面や状態を表し、フレームは開始から終了までの定義された順序で実行されます。

例えば、1つのフレームは注視点を表示し、次のフレームは刺激を提示し、その後のフレームが反応を収集します。試行タイムラインは、実験が1つのフレームから次のフレームに移動する方法を制御します。これには、各フレームが表示される時間や遷移をトリガーするものが含まれます。

一般的なフレームシーケンス

一般的な試行タイムラインには次のものが含まれる場合があります：

• 参加者を準備するための注視フレーム
• コンテンツを提示する刺激フレーム（例：画像、テキスト、音声、動画）
• 入力が収集される応答フレーム
• フィードバックまたは試行間フレーム

これらはすべて、同じ試行タイムライン内の別々のフレームであり、別々の試行ではありません。

試行タイムラインの操作

試行タイムラインでは、単一の試行の視覚的なシーケンスを構築します。フレームは左から右に順番に表示され、それぞれが参加者が見る画面を表します。このビューから直接フレームを追加、配置、および構成できます。

フレームの追加

試行に新しいフレームを追加するには、試行エディタの下部にあるボタンを使用します。選択できるフレームタイプは3つあり、フレームをインポートするオプションもあります：

キャンバス

キャンバスフレームは、レイアウトを自由に制御します。正確な座標で配置することにより、コンテンツ要素を画面上の任意の場所に置くことができます。視覚認知タスク、反応時間タスク、または画面上の表示位置に対して細かい制御が必要な任意の研究において、このフレームタイプを使用します。詳細な設定については、専用のキャンバスフレームページを参照してください。

ページ

ページフレームは、コンテンツを自動的に上から下へ配置します。標準的なウェブページのようなもので、要素は一貫したスペーシングで垂直にスタックされ、レイアウトの柔軟性よりも可読性と流れが重要なアンケート、同意書、調査に適しています。詳細な設定については、専用のページフレームページを参照してください。

ウェブサイトフレーム

ウェブサイトフレームは、Labvancedが構築した刺激の代わりに、研究内に実際の外部ウェブサイトを埋め込みます。このフレームタイプは、再作成されたバージョンではなく、実際のライブサイトで視線や相互作用をテストまたは追跡する必要がある場合に使用します。詳細な設定については、専用のウェブサイトフレームページを参照してください。

キャンバスフレーム

自由に配置：フレーム内のオブジェクトを好きな場所に配置、サイズ変更、ドラッグします。感覚や反応時間タスクのように、正確な配置やタイミングが重要な場面で使用します。

ページフレーム

ウェブページのような自動的な上から下へのレイアウト。このフレームは、流れが正確な配置よりも重要な質問票、同意書、指示に使用します。

ウェブサイトフレーム

Labvancedが構築した刺激の代わりに、研究内に実際の外部ウェブサイトを埋め込みます。実際のライブサイトで視線をテストまたは追跡する用途に使用します。

フレームのインポート

インポートオプションを使用すると、アクセスできる別のタスクや研究からフレームを持ち込むことができます。これは、既存のデザインをゼロから再構築することなく再利用したい場合に便利です。

インポート時に、フレームに関連付けられている変数の取り扱いについて尋ねられます：

• 新しい変数を作成 — インポートされたフレームは完全に独立しており、変数の独自のコピーとともに機能します
• 既存の変数を再利用 — インポートされたフレームは、現在のタスクに既に存在する変数に接続し、全てをリンクします

インポートされたフレームはタイムラインに追加され、他のフレームと同様に編集できます。

フレーム設定

タイムラインでフレームを選択すると、Frame Settingsパネルが右側に表示され、指定するために利用できます。利用可能なオプションはフレームの種類によって異なりますが、以下はすべてのフレームに共通のものです：

• Name:タスク内でフレームを識別するためのラベル（参加者には表示されません）
• Duration:オプションの固定表示時間（ミリ秒）。チェックが外されている場合、フレームはイベントやアクションによって試行が進むまで画面に表示され続けます
• Background color:カスタム背景色を設定するか、研究のデフォルトを使用します。注意: 目の追跡研究では、キャリブレーション中に背景色がデフォルトの白と同じであることが重要です。
• Hide mouse:このフレームがアクティブな間、参加者のカーソルを非表示にします

キャンバスフレームの設定

• Width and Height:キャンバスエリアの寸法で、ピクセル、フルスクリーン単位、ミリメートル、または視的度で設定可能です（Task Settingsに定義されたタスクのズームモードに依存）。

ページフレームの設定

• Max-Width:ページコンテンツエリアの最大幅
• Border size:要素間の境界線の厚さ
• Element margin:ページ上の要素間のスペーシング

試行タイムラインの変更 — 試行システム

Trial System は、実験の条件を定義し、試行の構造と繰り返しを制御する場所です。要因レベルの各ユニークな組み合わせは条件となり、タイムラインは現在編集している条件を反映するように適応します。

条件ごとの編集

デフォルトでは、タイムラインで行った変更は すべての条件に一度に 適用されます。これは、Trials & Conditionsパネルで Default Trial 行が選択されていることによって示されます。このモードでの編集は、すべての条件に共通するベースラインプロパティを設定します。

特定の条件を編集するには、Trials & Conditionsパネルでその行をクリックします。 タイムラインとフレーム設定はその条件を反映するように更新されます。デフォルトと異なるプロパティは視覚的に強調表示され、カスタマイズされた内容が簡単に確認できます。

働きかけるレベルは次の4つです：

• Default Trial — 変更はすべての条件に適用される
• Factor level — 変更は特定の要因レベルを共有するすべての条件に適用される
• Condition — 変更は特定の要因レベルの組み合わせに適用される
• Individual trial — 変更は条件内の特定の試行の繰り返しに適用される。

Trials & Conditionsテーブルには、条件ごとの# Trialsを入力します。個別の試行にアクセスするには、矢印アイコン►を使用して条件行を展開します。

編集の階層

これらの4つのレベルは厳格な上から下への階層を形成しており、高いレベルで行われた変更は低いレベルでなされた変更に優先します。たとえば、individual trialレベルでテキストオブジェクトをカスタマイズし、その後条件レベルで同じプロパティに変更を加えた場合、条件レベルの設定が個別の試行で設定したものを上書きします。この論理は階層上のすべてに適用されます — Default Trial変更は、そのプロパティに対して要因、条件、または個別の試行レベルで設定されたものを上書きします。

これにより、作業を行う順序が重要になります。一般的なルールとして、設計を上から下に構築します：最初にDefault Trialで共有されているすべてを確立し、その後に要因レベル、条件、そして最後に、より正確な上書きが必要な場合にのみ個別の試行に移ります。設計プロセスの初期段階で詳細レベルで変更を行い、その後に上位レベルを調整するために戻ると、予期しない結果を引き起こすことがあります。なぜなら、高レベルの変更がより特定の変更を上書きするからです。作業中に階層を考慮することで、意図しない上書きを避け、試行設計を予測可能に保つことができます。

例：画像評価研究

想像してみてください、参加者が自然の風景と都市の風景の2つのカテゴリーからの画像を見て、それぞれの画像がどれだけ冷静に感じさせるかを評価する研究を行っているとします。Factorsパネルで、要因名をScene Typeに編集し、2つのレベル — Nature と Urbanを設定します。Trials & Conditionsテーブルには、条件ごとの# Trialsを入力します。個別の試行にアクセスするには、矢印アイコン►を使用して条件行を展開します。

Default Trial — ここから標準形で試行を設計します。画像オブジェクトをフレームの中心に配置し、その下に評価スケールを追加し、上には「この画像はどれだけ冷静に感じさせますか？」と書かれたテキストラベルを設定します。フレームの期間、背景色、表示される画像に関わらず同じままのその他のプロパティを設定します。すべての条件は、このレイアウトを自動的に継承します。

Factor level — あなたの研究には1つの要因があります：Scene Type、レベルはNature と Urbanの2つです。Nature要因レベルでは、画像オブジェクトに自然の写真を表示させ、必要であればテキストラベルを更新します。Urban要因レベルでは、画像を都市の写真に変更します。それぞれのレベルに属するすべての条件は、もはや個別に条件を編集することなく正しい画像を表示します。

Condition — 特定の要因レベルの組み合わせにさらなる調整が必要な場合（特に2x2デザインの場合） — たとえば、特定の条件が正しく表示されるために暗い背景を必要とするコントラストの高い都市画像を使用する場合 — その変更を条件レベルで行うことができ、他のすべてには影響しません。

Individual trial — 条件内の特定の試行の繰り返しにユニークな調整が必要な場合、そのレベルで適用することができます。

上から下に作業することにより、各プロパティを適用される最も高いレベルで一度だけ定義し、残りは階層に処理させます。もし最初から各条件を個別に編集していた場合、共有レイアウトへの後の変更 — 評価スケールを移動するなど — は、すべての条件で個別に繰り返される必要があります。

試行タイムラインの変更と試行システムを特徴とする実際の研究

以下の研究では、実験タスクの文脈で試行タイムラインがどのように機能するかを示しています。特に、各研究内の主要なデスクトップタスクです。これらのデザイン機能をより詳しく確認するには、ImportまたはInspectできます。

条件ごとに変更できるもの

すべてのフレームには、すべての条件にわたって同じオブジェクトセットが含まれています — 特定の条件に対してオブジェクトを追加したり削除したりすることはできません。フレームにオブジェクトが存在する場合、それはすべての条件に存在します。特定の条件にオブジェクトが表示されるかどうかを制御するには、イベントを使用して、そのフレームの開始時にその可視性やアクティブなステータスを変更します。

表示されるオブジェクトについて、次のプロパティは条件ごとにカスタマイズできます：

• Content — 要素が表示するテキスト、画像、音声、またはビデオを変更する
• Position and size — 特定の条件に対して要素を移動またはサイズ変更する
• Styling — 色、フォント、境界線、または他の視覚的プロパティを調整する
• Visibility and active status — 要素を表示または非表示にする、または条件に結び付けられたイベントを使用して完全に非アクティブにする

非実験タスクにおける試行タイムライン

試行タイムラインは、繰り返し可能なフレームのシーケンスのために特に設計されています。同じ構造を何度も提示する必要がある場合、たとえば反応時間タスクや刺激応答実験で使用されます。

しかし、研究のすべての部分がこの繰り返し構造に従うわけではありません。承諾書、指示画面、またはアンケートなどの要素は通常、一度だけ提示され、試行内で繰り返しフレームのシーケンスを構成しません。 このため、これらは実験タスクからは分離して、別のタスクとして実装されます。これは、試行タイムラインのすべての機能を活用する実験タスクとは異なります。

この分離により、試行タイムラインは繰り返しの実験試行に焦点を当て、他のタスクタイプは研究の一度限りまたはユニークな構造を持つ部分を処理します。

したがって、たとえ試行タイムラインが非実験タスク（アンケートベースのタスクのような）でフレームの流れを表すために登場する場合でも、試行タイムラインの全機能は、特にTrial Systemの文脈で実験タスクにて発揮されます。