# 1.1.2 — How to Use This Course Page-by-Page (Deliverables per Page) 🧭

This course is designed like a **production checklist**: every page (lesson) ends with **clear deliverables** you can verify in your Bricks/WordPress build. The goal is that you *never* “kind of understand”—you either **shipped the artifact** (code + Bricks setup + notes), or you didn’t.

---

## The Page-by-Page Workflow (Repeatable Every Time) ✅

### 1) Before You Start: Prepare the “Lesson Sandbox” (5–10 min)
1. **Pick one page to implement** (e.g., `1.1.2`) and commit to finishing it end-to-end.
2. **Choose a controlled location in Bricks**:
   1. A dedicated *Course Sandbox* page (recommended), or  
   2. A specific template/section you won’t reuse yet.
3. **Disable variables that hide problems** (temporarily):
   1. Cache/minify plugins (or bypass via dev mode)
   2. CDN optimizations
   3. Aggressive script deferring (until your baseline works)

**Deliverable:** A dedicated Bricks page/template you can safely break and reset.

---

### 2) Implementation: Build What the Lesson Asks—Nothing More 🎯
Each lesson page will include:
1. **Goal** (what you’re building)
2. **Why it matters** (the mental model)
3. **Bricks implementation** (exact placement + selectors)
4. **Code** (copy/paste + explanation)
5. **Micro-exercises** (small variations that prove understanding)
6. **Troubleshooting** (common failure modes)

**Rule:** implement *exactly* the described effect first.  
Polish (styling, extra features) comes **after** the effect is reliable.

**Deliverable:** The animation/behavior works exactly as described in the lesson.

---

### 3) Verification: Prove It Works (Not Just “Looks OK”) 🔍
For every page, you’ll verify four categories:

1. **Functional verification**
   1. Does it run on first load?
   2. Does it run after refresh?
   3. Does it run on hard reload (cache bypass)?
2. **Selector verification**
   1. Does it still work if there are *two* instances of the section?
   2. Does it break if the DOM structure changes slightly?
3. **Responsive verification**
   1. Test at least: mobile, tablet, desktop breakpoints
   2. Confirm no overflow, clipping, or unexpected shifts
4. **Accessibility/motion sanity check**
   1. If motion is significant: consider `prefers-reduced-motion`
   2. Ensure no focus traps or invisible-but-clickable overlays

**Deliverable:** A short checklist (written by you) marking what you tested.

---

## What “Deliverables per Page” Actually Means 📦

Each page produces *artifacts* you keep. Over time, these become your personal GSAP toolkit.

### Core Deliverables (Every Page)
1. **Working demo inside Bricks**
   1. A section/page where the effect is visible
   2. Uses robust selectors (usually classes/data attributes)
2. **Saved code snippet**
   1. Stored in your project in a predictable place (see “Folder pattern” below)
   2. Includes a short header comment: what it does + how to apply
3. **One-liner notes**
   1. What surprised you?
   2. What broke first?
   3. What you’d do differently next time

### Optional Deliverables (When the page includes them)
1. **Reusable function** (e.g., `initHeroReveal(rootEl)`)
2. **Mini utility** (e.g., a scoped selector helper)
3. **A variation** (e.g., “same reveal but staggered”)

---

## Standard Folder + Naming Pattern (So You Don’t Lose Anything) 🗂️

Even if you’re not using a bundler yet, use a consistent structure.

1. Create a “course lab” area in your theme or child theme (or a snippets plugin):
   1. `gsap-lab/`
   2. `gsap-lab/pages/`
   3. `gsap-lab/utils/`
2. Name files by lesson number:
   1. `pages/01-01-02-workflow.js`
   2. Later: `pages/04-01-first-tween.js`, etc.
3. Add a short header comment at the top of each file:
   1. What it does
   2. Where it’s used (Bricks page/template)
   3. Dependencies (GSAP core, ScrollTrigger, etc.)

**Deliverable:** A place where your “lesson code” lives permanently, not in random Bricks textareas.

---

## Bricks Placement Rules (So Scripts Don’t Turn Into Chaos) 🧱

You’ll repeatedly choose *where* code goes. Use these rules while learning:

1. **During learning (recommended):**
   1. Put lesson JS in **one** predictable place (global or the sandbox page)
   2. Keep selectors scoped to the sandbox section to avoid side effects
2. **When you turn a lesson into a reusable component:**
   1. Move code into a “component init” function
   2. Initialize per section instance (important for query loops/repeated sections)

**Deliverable:** You can explain *why* your code is placed where it is (not “because it worked once”).

---

## The “Two-Instance Test” (Your Fastest Pro Filter) 🧪

A huge amount of WordPress/Bricks animation pain comes from accidental global targeting.

**Do this after most lessons:**
1. Duplicate the animated section in Bricks (same page).
2. Reload.
3. Confirm:
   1. Both instances animate correctly
   2. One instance doesn’t hijack the other’s elements
   3. Timing doesn’t “double fire”

If it fails, you learn a key professional habit: **scope your selectors**.

**Deliverable:** A screenshot or note: “Two-instance test: pass/fail + fix”.

---

## What You Should Send Me After Completing Any Page 📤
When you finish a lesson page, reply with:

1. **Where you put the code** (Bricks global/page/element OR theme file)
2. **Your selectors** (classes/data attributes you used)
3. **What worked immediately**
4. **What broke**
5. **One screenshot** (optional but helpful) or a short description

Then I can:
1. Suggest improvements (scoping, maintainability)
2. Flag performance/accessibility risks early
3. Provide a cleaner “component version” of your solution

---

## Your Deliverables for *This* Page (1.1.2) ✅

1. A written **personal workflow checklist** you will follow for each lesson page (copy the sections above and simplify to your taste).
2. A **sandbox page/template in Bricks** dedicated to course experiments.
3. A **project structure decision**:
   1. Where lesson JS will live *for now*
   2. How you will name and store lesson code snippets
4. A quick **two-instance test habit** added to your checklist.

---

## Quick Micro-Exercise (5 minutes) ✍️
Create a checklist you can paste at the top of each future lesson file:

1. Goal:
2. Where installed (Bricks/page/global/file):
3. Selectors used:
4. Tested:
   1. Refresh
   2. Hard reload
   3. Two-instance test
   4. Mobile/tablet/desktop
   5. Reduced motion (if relevant)
5. Notes: