vndangkhoa/open-design
1
0
Fork 0
mirror of https://github.com/nexu-io/open-design.git synced 2026-06-01 03:14:35 +07:00
Code Issues Projects Releases Packages Wiki Activity Actions 1
open-design/skills/mobile-app/SKILL.md
Mohamed Abdallah 5da21e4054
feat(craft): animation-discipline module + opt-ins on mobile-app, mobile-onboarding, gamified-app (#515) 
* feat(craft): add animation-discipline + opt-ins on mobile-app, mobile-onboarding, gamified-app

Animation discipline is the second behavioral craft module proposed in
#501 and explicitly invited in @mrcfps's post-merge comment on #502.

Differentiation from prior art (LottieFiles motion-design-skill, MIT,
96 stars): citation-grounded against primary sources rather than
asserted. Anchors:

- Tversky/Morrison/Bétrancourt 2002 (IJHCS) on the one demonstrated
  win-condition for animation
- Heer & Robertson TVCG 2007 on staging (with the actual durations
  they tested, not the laundered '300-1000ms' rule)
- Harrison/Yeo/Hudson CHI 2010 on perceived-duration scope (progress
  bars only, not skeletons)
- Doherty & Thadani IBM 1982 productivity numbers
- Material 3 motion tokens (M3 standard vs M2 legacy delta)
- IBM @carbon/motion durations
- Apple SwiftUI Animation API published defaults
- W3C View Transitions API + WCAG 2.2.2/2.3.3 calibration
- WebKit 2017 prefers-reduced-motion rationale

The 'common mistakes (lint these)' section busts five specific
folklore claims that don't survive primary-source check, including
the Doherty-400ms attribution and the M2-vs-M3 standard easing
confusion.

Three skills opt in via od.craft.requires:
  - mobile-app (animation-heavy mobile screens)
  - mobile-onboarding (multi-screen flow with transitions)
  - gamified-app (animations central to the format)

Refs #501.

* fix(craft): address review findings on animation-discipline

Six findings from @lefarcen's CHANGES_REQUESTED review on #515,
addressed in one pass. Reviewed by codex across three loops before
push.

P1 integration gaps:
- gamified-app and mobile-onboarding skills now require both
  state-coverage and animation-discipline (both render stateful UI
  with motion).
- craft/README.md silent-fallback example reframed as a
  planned-but-not-yet-vendored placeholder rather than a hard-coded
  next-to-ship slug. Note added pointing skill authors who arrive from
  older guidance at animation-discipline as the equivalent of the
  earlier 'motion' placeholder.

P2 reasoning completeness:
- > 500 ms duration row reframed: 'Reserved for cross-screen, staged,
  or platform-native transitions (e.g. M3 long2-extraLong4, Heer &
  Robertson 2007's per-stage recommendation)'. Surrounding paragraph
  rewritten with an enumerated category — 'Non-navigation
  microinteractions: hover, press, toggle, validation, chip selection,
  row expansion' — rather than the vague 'routine' term.
- New 'Flashing limits' subsection added in the Reduced motion
  section. WCAG 2.3.1 (Level A) three-flashes-in-any-one-second-period
  rule with the area/brightness threshold qualifier; WCAG 2.3.2 (AAA)
  unconditional rule. Photosensitive epilepsy framing.
- New 'Repeated and ambient motion' section added. Five rules covering
  iteration cap, WCAG 2.2.2 pause control after 5s, cancel-on-route,
  one-shot reward animations, and spinner timeout cross-referencing
  state-coverage.md.

File length now 154 lines (was 130, 80-110 craft target). Trade is
citation density and the new sections demanded by the integration
context (gamified/onboarding skills with looping motion).

Refs #501, #515.
2026-05-05 18:32:30 +08:00

3.8 KiB
Raw Blame History

name description triggers od
mobile-app A mobile-app screen rendered inside a pixel-accurate iPhone 15 Pro frame on the page. Built by copying the seed `assets/template.html` and pasting one screen archetype from `references/layouts.md`. Use when the brief asks for "mobile app", "iOS app", "Android app", "phone screen", or "app UI".
mobile app
ios app
android app
phone screen
app ui
app mockup
移动端
手机 app
mode platform scenario preview design_system craft
prototype mobile design
type entry
html index.html
requires sections
true
color
typography
layout
components
requires
state-coverage
animation-discipline

Mobile App Skill

Produce a single mobile-app screen mockup, framed inside a real-feeling iPhone 15 Pro device.

Resource map

mobile-app/
├── SKILL.md                ← you're reading this
├── assets/
│   └── template.html       ← seed: device frame + screen primitives (READ FIRST)
└── references/
    ├── layouts.md          ← 6 screen archetypes (Feed / Detail / Onboarding / Profile / Checkout / Focus)
    └── checklist.md        ← P0/P1/P2 self-review (anti-fake-device)

Workflow

Step 0 — Pre-flight

  1. Read assets/template.html end-to-end through the <style> block. The Dynamic Island, status bar SVG icons, home indicator, side rails, and tab bar are all already drawn in HTML/SVG — do not re-implement them inline on each screen.
  2. Read references/layouts.md so you know which 6 archetypes exist.
  3. Read the active DESIGN.md — map its tokens to the six :root variables in the seed.

Step 1 — Copy the seed

Copy assets/template.html to the project root as index.html. Replace the six :root variables with the active design system's tokens. Replace the page <title> and the caption above the device.

Step 2 — Pick exactly one archetype

Brief language Use
feed, inbox, timeline, list, messages, notifications A — Feed
article, post, item, recipe, song, product, song detail B — Detail
sign-up, welcome, intro, walkthrough, tour C — Onboarding
profile, account, user page, someone's bio D — Profile
checkout, payment, order, form, settings step E — Checkout
timer, map, dashboard widget, single big number F — Focus / hero card

A mobile screen does one job. If the brief seems to combine two, ship one screen and offer the other as a follow-up.

Step 3 — Paste and fill

Copy the archetype block from layouts.md into <main class="content">, replacing the placeholder card. Fill bracketed text with real, specific copy from the brief. Drop the <nav class="tabbar"> block entirely for archetypes that don't show one (B, C, E).

Step 4 — Self-check

Run through references/checklist.md. Pay extra attention to:

  • Frame still has the Dynamic Island, status bar SVGs, and home indicator
  • Tap targets ≥ 44px
  • One accent, used ≤ 2× on the screen
  • Display headings still use var(--font-display) (serif)

Step 5 — Emit the artifact

<artifact identifier="mobile-slug" type="text/html" title="Mobile — Screen Name">
<!doctype html>
<html>...</html>
</artifact>

One sentence before describing what's there. Stop after </artifact>.

Hard rules

  • The phone is real. Dynamic Island gap, SVG status icons, home indicator. The seed protects all three — don't rewrite the frame.
  • Single screen, single job. No multi-tab tours, no spliced flows.
  • Accent budget = 2. One active tab + one primary action is the default.
  • Numerics in mono via .num class.
  • Display in serif via var(--font-display).
  • No external images — use .ph-img placeholders.