Instructional Visual/Slide Design Pipeline

وقتی اسلاید تمیز است اما evidence در export می‌شکند

یک درس معماری شش اسلاید دارد: یک diagram متراکم، دو screenshot، یک comparison table و speaker noteهایی که بخش مهمی از توضیح را حمل می‌کنند. در source editor همه‌چیز مرتب به نظر می‌رسد، اما PDF export reading order را تخت می‌کند و یکی از screenshotها alternative description ندارد. اگر فقط فایل source را review کنیم، یک failure واقعی را ندیده‌ایم.

در این درس Instructional Slide & Visual Production Contract v1 را می‌سازیم. هر slide باید به outcome و claim مشخص، content model، visual semantics، alt/description، notes، layout، reading order، density، contrast، export state، review state، revision و provenance متصل باشد. قوی‌ترین state مثبت این درس release خودکار نیست؛ وقتی همهٔ شواهد لازم آماده‌اند، نتیجه VISUAL_PRODUCTION_REVIEW_REQUIRED است. هر جا source و export یا presenter-led و self-paced semantics از هم جدا شوند، سیستم باید fail-closed بماند.

مسیر درس و مرز مالکیت

MKN-012 مالک Instructional Visual/Slide Design Pipeline است. پیش‌نیاز سخت MKN-007 و پیش‌نیاز نرم MKN-011 هستند. MKN-011 مالک Accessible Multimedia Learning UX و MKN-013 مالک Ethical Gamification است؛ این درس هیچ‌کدام را جذب نمی‌کند.

در مسیر Foundation، یک deck کوچک را از outcome تا export QA دنبال می‌کنیم. در مسیر Repair، فقط همان evidence dimension شکسته را تعمیر و دوباره اجرا می‌کنیم. در مسیر Experienced، باید بتوانی توضیح بدهی چرا «اسلاید زیبا» یا «PDF باز می‌شود» هیچ‌کدام اثبات instructional completeness نیست.

Checkpointها: V1 purpose/claim trace؛ V2 semantic alternative + reading order؛ V3 transfer از presenter-led deck به self-paced HTML بدون استفاده از baseline به‌عنوان oracle.

مدل ذهنی: purpose → content model → visual semantics → source QA → export QA → review

جریان پیشنهادی:

learning outcome + claims → slide content model → visual choice → semantics + notes + alternatives → layout/readability QA → export → export accessibility QA → review/revise/release

سه مرز را جدا نگه می‌داریم. اول، content model از layout مستقل است؛ تغییر template نباید claim structure را نابود کند. دوم، visual semantics از ظاهر مستقل است؛ screenshot یا diagram فقط وقتی instructional است که نقش آن و alternative آن روشن باشد. سوم، source QA از export QA مستقل است؛ reading order، text extraction یا alternativeها ممکن است در export خراب شوند.

اگر هر کدام از این سه مرز evidence کافی نداشته باشد، pipeline باید HOLD یا REVIEW_REQUIRED برگرداند.

قرارداد پایه: نوزده بُعد Evidence

ابعاد فریز‌شده عبارت‌اند از: deck_id، lesson_outcome_ref، slide_id، slide_purpose، claim_ids، content_model_ref، visual_type، visual_semantics، alt_or_description، speaker_note_ref، layout_template، reading_order، text_density، contrast_state، export_format، export_accessibility_state، review_state، revision و provenance.

Invariantهای حداقلی:

1. هر slide یک purpose و outcome/claim trace دارد.
2. visual decoration و instructional visual یکی نیستند.
3. visual instructional باید semantics و alternative قابل‌استفاده داشته باشد.
4. اطلاعات ضروری فقط در speaker note پنهان نمی‌شود، مگر اینکه delivery context آن را عمداً پشتیبانی کند.
5. reading order در source و export جداگانه بررسی می‌شود.
6. contrast/readability و text density evidence هستند، نه سلیقهٔ reviewer.
7. export accessibility state باید روی artifact خروجی اندازه‌گیری شود.
8. review به revision دقیق متصل است.
9. provenance source/export/review را به هم وصل می‌کند.
10. تغییر delivery mode، تصمیم قبلی را خودکار معتبر نگه نمی‌دارد.

توضیح عمیق: Instructional Semantics از Rendering جداست

W3C WAI presentation guidance — FACT. راهنمای WAI توصیه می‌کند design اسلایدها consistent باشد، text روی slide محدود و خوانا باشد، visuals مهم توصیف شوند و material در قالب‌های accessible ارائه شود. این guidance template یا density threshold داخلی MAKNOW را تعیین نمی‌کند.

WCAG 2.2 — FACT. WCAG 2.2 success criterionهای technology-independent و testable برای web content می‌دهد. وقتی slide experience به HTML تبدیل می‌شود، این معیارها می‌توانند بخشی از accessibility QA باشند؛ اما WCAG نمی‌گوید کدام diagram pedagogically بهتر است یا sequence آموزشی چه باشد.

Pipeline separation — INFERENCE. چون semantic meaning ممکن است در conversion/export از بین برود، review source به‌تنهایی کافی نیست. source artifact و export artifact باید evidence مستقل داشته باشند.

MAKNOW release contract — DESIGN. visual grammar، density limits، template، review state و release gate authority داخلی پروژه‌اند و باید versioned و auditable باشند.

مثال‌های حل‌شده: Source خوب، Export خراب و Self-paced Transfer

Baseline. deck شش‌اسلایدی در source editor structure قابل‌قبولی دارد. architecture diagram semantics دارد و notes نکات presenter را حمل می‌کنند. اما PDF export reading order را تخت کرده و screenshot دوم alternative description ندارد. نتیجه HOLD_EXPORT_A11Y_REPAIR_REQUIRED است؛ نه چون teaching intent بد است، بلکه چون release evidence ناقص است.

Wrong approach. designer برای ساده‌کردن فایل، speaker notes را حذف می‌کند ولی slideها عمداً sparse هستند و بخشی از explanation فقط در notes بوده است. نتیجه HOLD_SPEAKER_NOTE_DEPENDENCY است تا missing information جبران شود.

Transfer. همان sequence به self-paced HTML تبدیل می‌شود و presenter وجود ندارد. حالا هر اطلاعاتی که قبلاً در narration یا speaker notes بود باید به visible explanation، expandable note، transcript یا assistive alternative منتقل شود. baseline release state oracle نیست؛ transfer باید مستقل recompute شود و در بهترین حالت SELF_PACED_REVIEW_REQUIRED می‌گیرد.

Failure Modeهایی که باید Fail-closed شوند

این حالت‌ها نباید به release عبور کنند:

• slide purpose یا claim trace مفقود است؛
• diagram instructional با screenshot بی‌برچسب جایگزین می‌شود؛
• visual semantics وجود دارد اما alt/description غایب است؛
• sparse slide به speaker note وابسته است ولی note حذف شده؛
• PDF reading order با source تفاوت دارد یا flat شده؛
• contrast state fail یا unknown است؛
• export accessibility فقط از source editor فرض شده است؛
• review به revision قدیمی اشاره می‌کند؛
• provenance source/export/review را وصل نمی‌کند؛
• self-paced transfer از تصمیم presenter-led کپی می‌شود.

در همهٔ این وضعیت‌ها HOLD نتیجهٔ معتبر است.

گزینه‌ها و Trade-offها: Diagram، Screenshot، Table یا Text-first

Diagram برای relation و flow مناسب است، اما اگر semantics در shape/color قفل شود alternative پرهزینه می‌شود. Screenshot برای نشان‌دادن UI واقعی سریع است، اما semantic structure کمی دارد و با تغییر نسخه زود stale می‌شود. Table برای comparison و audit عالی است ولی روی screen کوچک یا اسلاید زنده می‌تواند dense شود. Text-first accessibility و searchability خوبی دارد اما بعضی relationها را کندتر منتقل می‌کند.

انتخاب درست «زیباترین visual» نیست. باید ببینیم learner برای outcome چه representationی نیاز دارد، کدام information باید visible باشد، کدام alternative لازم است و export target چه riskی ایجاد می‌کند. گاهی حذف visual decorative تصمیم بهتر است؛ گاهی split کردن یک slide dense به دو slide، evidence قوی‌تری می‌سازد.

پل Experienced: Slide را View یک Content Model نسخه‌دار ببین

در pipeline حرفه‌ای، slide فایل اصلی حقیقت نیست. آن را یک view از content model نسخه‌دار ببین:

• claim و semantic nodes مستقل از coordinates نگه داشته می‌شوند؛
• visual asset شناسه و purpose دارد؛
• notes و alternatives sibling evidence هستند؛
• layout template presentation concern است؛
• export artifact revision و hash جدا دارد؛
• review source و export را با همان revision می‌سنجد؛
• accessibility failure باید بتواند بدون بازنویسی claim structure repair شود.

این جداسازی اجازه می‌دهد PDF، HTML یا presenter mode از یک content model مشترک ساخته شوند، بدون اینکه تفاوت affordanceهای آنها پنهان شود.

تمرین هدایت‌شده و مستقل

Guided. baseline fixture را باز کن و برای هر slide مشخص کن کدام field از source و کدام field از export آمده است. ابتدا فقط failure با reading order را تعمیر کن و دوباره gate را اجرا کن؛ سپس alternative description مفقود را جداگانه repair کن. هدف این است که چند fault را با یک تغییر مبهم «fix accessibility» نپوشانی.

Independent. یک slide instructional جدید به fixture اضافه کن که comparison table دارد. purpose، claims، reading order، density و export state را خودت تعریف کن. سپس یک mutation بساز که فقط revision را عوض کند ولی review state را دست‌نخورده نگه دارد؛ سیستم باید stale review را تشخیص دهد.

Experienced. توضیح بده چه بخش‌هایی از این contract می‌توانند توسط tooling خودکار check شوند و کدام بخش‌ها—مانند instructional purpose و adequacy of semantic alternative—به human review نیاز دارند.

Verification Evidence: چه چیزی واقعاً باید قابل بازتولید باشد؟

Package باید بتواند بدون hidden reasoning این موارد را ثابت کند: Bible hash فریز‌شده است؛ ۱۳ semantic role در هر دو locale وجود دارند؛ جدول ۳ سناریویی تمام ۱۹ dimension را پوشش می‌دهد؛ Lab deterministic است؛ source/export failureها typed state دارند؛ freshness ledger source ID معتبر دارد؛ و reviewer می‌تواند از fixture به همان state برسد.

Machine validation کیفیت pedagogical را ثابت نمی‌کند، اما drift ساختاری را آشکار می‌کند. برای همین artifact نهایی همزمان content، table، lab، source ledger، acceptance record، critical hash lock و manifest دارد.

Assessment و Transfer: از Presenter-led به Self-paced HTML

ارزیابی چهار لایه دارد: retrieval مرز درس را می‌سنجد؛ application contract baseline را می‌سازد؛ diagnosis یک shortcut را repair می‌کند؛ transfer delivery mode را عوض می‌کند.

در transfer، presenter حذف می‌شود. بنابراین speaker_note_ref دیگر صرفاً metadata پنهان نیست: هر information ضروری باید در visible content یا assistive alternative قابل‌دسترسی باشد. HTML target همچنین accessibility QA خودش را دارد. اگر learner فقط baseline state را کپی کند، نتیجه HOLD_BASELINE_ORACLE_REUSE است.

قبولی یعنی learner بتواند توضیح دهد چه evidenceای به‌دلیل تغییر delivery context عوض شد، نه اینکه صرفاً خروجی را دوباره export کند.

منابع، Freshness و مرز Authority

دو منبع خارجی اصلی این درس W3C WAI Accessible Presentations و WCAG 2.2 هستند. در بازبینی 2026-09-13، WAI همچنان consistent design، محدودکردن متن slide، readable visuals، توصیف visual information و ارائهٔ accessible material را توصیه می‌کند. WCAG 2.2 نیز همچنان W3C Recommendation و معیارهای testable و technology-independent برای web content است.

این منابع FACT boundary می‌دهند؛ visual grammar، density threshold، template، review workflow و release state MAKNOW DESIGN authority هستند. اگر W3C guidance یا target platform semantics تغییر اساسی کند، freshness review باید نسخهٔ جدید package را ایجاد کند و Golden قبلی نباید in-place mutate شود.