Understand animation components (primary, secondary, sound)

4. Design Guidelines Checklist

• Is the primary animation obvious, purposeful and timed between 200 ms – 500 ms?
• Do secondary animations add value (weight, realism) without distracting from the primary action?
• Is the sound brief (250 ms), context‑appropriate, and optional for users who need it muted?
• Are easing functions consistent and appropriate for the motion type?
• Do you respect prefers-reduced-motion and provide visual alternatives?
• Are only GPU‑accelerated properties (transform, opacity) used for motion?
• Is the animation tested on target devices for smoothness and low CPU/GPU usage?

4.1 Mapping Guidelines to Assessment Objectives (AO)

5. Accessibility: Reduced‑Motion Definition & Code

Reduced motion is a user preference that asks the system to minimise or eliminate non‑essential visual movement (e.g., animations, transitions). It is typically set at the OS level and exposed to web content via the CSS media query prefers-reduced-motion.

/* Example: replace slide animation with a simple fade when reduced motion is requested */
@media (prefers-reduced-motion: reduce) {
    .panel‑enter {
        animation: fade‑in 150ms ease‑out forwards;
    }
    .panel‑leave {
        animation: fade‑out 150ms ease‑out forwards;
    }
}

/* Normal slide animation (used when motion is allowed) */
@media (prefers-reduced-motion: no-preference) {
    .panel‑enter {
        animation: slide‑in‑right 300ms cubic-bezier(0.4,0,0.2,1) forwards;
    }
}

6. Sequencing Animation – Algorithm / Flow‑Chart Example

Below is a simple pseudo‑code algorithm that shows how primary, secondary and sound components are orchestrated.

function runInteraction() {
    // 1. Start primary animation
    startPrimaryAnimation();
    // 2. After a short delay (e.g., 50 ms) start secondary animation
    setTimeout(startSecondaryAnimation, 50);
    // 3. Play sound concurrently with primary (or after a tiny offset)
    playSoundCue();
    // 4. When primary finishes, clean‑up if needed
    onPrimaryEnd(() => {
        // optional: trigger next UI state
    });
}

In a visual flow‑chart the steps appear as:

7. Real‑World Case Studies

7.1 Mobile App On‑boarding Flow (existing example)

1. Step 1 – Welcome screen fades in. Classification: Primary animation
2. Step 2 – Illustrative icon slides up slightly while a subtle shadow follows. Classification: Secondary animation
3. Step 3 – A soft “whoosh” sound plays as the next screen slides from the right. Classification: Sound
4. Step 4 – The “Get Started” button scales up on tap, then bounces back. Classification: Primary animation (button press) with a secondary bounce.
5. Step 5 – If the user has enabled “Reduced Motion” in the OS, the slide transition is replaced by a quick fade, and the sound is muted. Classification: Accessibility adaptation (visual alternative + optional audio mute).

7.2 Desktop/Web Modal Dialog (new cross‑platform example)

1. Primary animation: The modal dialog fades in and scales from 95 % to 100 % over 250 ms using cubic‑bezier(0.4,0,0.2,1).
2. Secondary animation: The background overlay darkens slightly and a subtle “shadow‑grow” effect follows the dialog’s scaling (starts 50 ms after the dialog animation, lasts 150 ms).
3. Sound: An optional “click‑off” tone (180 ms) plays when the user confirms the dialog; it respects the mute control.
4. Reduced‑motion handling: When prefers-reduced-motion: reduce is detected, the dialog appears instantly with no scaling, and only the overlay opacity changes (no sound is played unless the user has explicitly enabled audio feedback).

8. Connections to Other Syllabus Topics

• System life‑cycle: Animation design is part of the implementation and testing phases; performance testing links to the maintenance stage.
• New & emerging technologies: Techniques such as WebGL, AR/VR, and motion‑sensing devices rely heavily on efficient, hardware‑accelerated animation.
• Communications technology: Sound cues must consider bandwidth (e.g., using compressed audio formats) and latency, especially in web‑based applications.
• Usability & accessibility: The animation guidelines directly support the syllabus’s focus on inclusive design.

9. Evaluation Rubric – “Good” vs. “Excessive” Animation

10. Practical Example – “Add to Cart” Interaction

1. Primary animation: The product image scales up slightly and moves into the cart icon (200 ms, ease‑in‑out cubic).
2. Secondary animation: The cart icon bounces once and a faint shadow shift follows (150 ms, ease‑out).
3. Sound: A soft “ding” tone (< 200 ms) plays; respects mute setting and reduced‑motion preference.

This combination confirms the action, adds a sense of weight, and remains accessible.

11. Summary

Understanding the three components of animation—primary animation, secondary animation, and sound—enables developers to create interfaces that are:

• Functional (clear feedback and guidance).
• Engaging (pleasant, realistic motion).
• Accessible (respecting reduced‑motion and providing optional audio).
• Performant (using hardware‑accelerated properties and testing on target devices).

By applying the design‑guideline checklist, the guideline‑to‑AO mapping, and the evaluation rubric, learners can analyse, classify and improve the animation quality of their own projects, fully meeting the Cambridge 9626 syllabus requirements.