كيف أرسم مخطط توضيحي لنظام معقد بصيغة SVG: دليل عملي خطوة بخطوة

متى يكفي الرسم isometric لشرح آلة أو نظام؟

يكفي عندما يكون الهدف شرح العلاقات بين المكوّنات: أين يقع الصمام، وأي خط يغذي أي وحدة، وماذا يتغير عند إغلاق جزء. ويمكن ربط عناصر الرسم بالنقر أو بتحريك المؤشر لعرض تفاصيل إضافية، دون الحاجة إلى نموذج ثلاثي الأبعاد كامل.

من الحالات المناسبة:

• تتبع مسار سائل أو إشارة عبر مكوّنات مرتبة.
• توضيح ترتيب التركيب أو الصيانة على جهاز واحد.
• شرح لوحة تحكم بعدّادات وأزرار يمكن قراءتها من الرسم نفسه.

متى تحتاج فعلاً إلى نموذج ثلاثي الأبعاد؟

تظهر الحاجة الحقيقية عندما تحتاج القطعة إلى الدوران أو الانحناء بطريقة تتبع منظور الكاميرا. يصف ملف README في مستودع anatomy وضع الرسم ثلاثي الأبعاد بأنه تجريبي (beta). فيه تُعاد إسقاط الأجزاء المتحركة فقط وتظليلها في كل إطار، بينما يبقى باقي الشكل رسماً ثابتاً.

أما الظواهر مثل اللهب والماء والبخار، فتحتاج عادة إلى طبقة WebGL. وفق ملف README، تعمل هذه الطبقة داخل عنصر canvas يقع بين طبقتي SVG، واحدة خلفه وأخرى أمامه، وبالكاميرا المائلة نفسها. ويبقى الشكل مقروءاً من دون WebGL، لأن طبقات SVG تحمل الأجزاء الأساسية.

القاعدة العملية: ابدأ بالإسقاط المائل، وأضف طبقة أعقد فقط عندما يفشل الشرح بدونها.

حدّد النظام والسؤال الذي يجيب عنه الرسم

اكتب جملة واحدة تحدد النظام والسؤال، مثل: كيف ينتقل الضغط في محطة ضخ عند فتح صمام العزل؟ إذا غاب السؤال، تكاثرت الأجزاء دون أن تخدم الشرح.

وحدّد حدود النظام أيضًا. قد يرسم فريق الصيانة في منشأة افتراضية الخط من الخزان حتى المضخة فقط، ويترك الشبكة الخارجية لرسم آخر. الحدود الواضحة تمنع الرسم من التضخم.

اكتب قائمة الأجزاء والوصلات قبل الرسم

سجّل كل جزء بالاسم والعدد والمقاس من الوثيقة الفنية للنظام، لا من الذاكرة. ثم سجّل كل وصلة: أين يدخل السائل، وإلى أين يخرج، والجهاز الذي يتحكم فيها.

راجع القائمة مع مدير العمليات قبل الرسم، فتقل التعديلات بعد اكتمال الأجزاء. القائمة هي مصدر الرسم، ولا تُستنتج من الصورة نفسها.

• الاسم والعدد والمقاس الحقيقي لكل جزء
• نقطة الدخول ونقطة الخروج لكل وصلة
• الصمام أو الجهاز الذي يتحكم في الوصلة

ضع شبكة isometric والمقاسات الحقيقية

كيف أرسم رسمًا isometric لآلة؟ يبدأ الجواب من الشبكة. الإسقاط isometric يعرض المحاور الثلاثة بزوايا ثابتة، فتبقى المسافات على كل محور متناسبة، وهذا ما يجعل مقارنة الأجزاء ممكنة.

حدّد وحدة قياس واحدة، مثل وحدة تمثل قيمة محددة من القائمة، واكتبها تعليقًا في الملف ليعرف من يعدّل الرسم لاحقًا معناها. وإذا لم تطابق النسب القيم المكتوبة، فالخلل في الشبكة لا في الأجزاء.

ابنِ الملف وراجعه في المتصفح

ابنِ الملف على طبقات: الهيكل أولًا، ثم الأنابيب والوصلات، ثم النصوص والتسميات فوقها. استخدم مجموعات <g> بمعرّفات واضحة لكل طبقة، حتى يسهل تعديل طبقة دون أخرى، ثم افتح الملف في المتصفح وفحصه كأي صفحة ويب.

في مستودع anatomy تحصل على مصدر تملكه: سكربت بناء في Node وصفحة يكتبها، وبحسب ملف README تفحص الأداة الرسم بتشغيل متصفح بلا واجهة على جهازك. وقد تمنع بيئة معزولة هذا المتصفح، فتفشل الفحوص وحدها دون أن يتأثر الرسم. تبقى المراجعة النهائية على الفريق، إذ يقارن أحد أعضائه الرسم بالنظام الفعلي.

التمرير فوق جزء لإظهار معلومته

مثال توضيحي افتراضي: في محطة ضخ صغيرة، يمرّ المؤشر فوق صمام فتظهر نسبة فتحه، ويتغير لون المسار المرتبط به. الرقم هنا للشرح فقط. المهم أن الجزء والقراءة يرتبطان بمصدر واحد، فإذا تغيّر النموذج تغيّر الجزء والقراءة معاً.

• اربط كل معلومة بجزء واحد واضح، وامنح المعرّف (id) اسماً يصف وظيفة الجزء.
• احسب القراءة من النموذج الذي يحرّك الجزء، ولا تكتبها يدوياً داخل النص.

النقر أو تبديل الطبقات لعرض التفاصيل

التمرير يعرض المعلومة ما دام المؤشر فوق الجزء، أما النقر فيُبقيها ظاهرة بعد رفع المؤشر. قسّم المخطط إلى طبقات، مثل الهيكل الخارجي والأنابيب والمكونات الداخلية، ليختار القارئ ما يراه أولاً.

مثال افتراضي: يفتح فريق الصيانة طبقة الأنابيب ليتتبع مسار الماء، ثم يغلقها ليرى المضخة دون ازدحام.

التنقل بلوحة المفاتيح ومؤشر التركيز

من يعتمد على لوحة المفاتيح أو على تقنيات مساعدة لا يستطيع استخدام رسم يعمل بالفأرة وحدها. لذلك يتحقق الفريق بنفسه من أن كل جزء تفاعلي يصل إليه التنقل بالمفتاح، وأن مؤشر التركيز يظهر بوضوح حول الجزء المحدد. هذه مراجعة يتولاها الفريق بعد التوليد.

يوضح ملخص WCAG 2.2 تحت المعيار 1.1.1 أن المحتوى الزخرفي الذي لا يحمل معلومة ينبغي أن يُنفَّذ بطريقة تستطيع التقنيات المساعدة تجاهلها. وتذكر الصفحة نفسها تقنيات لتوفير نص بديل، منها aria-label وaria-labelledby وalt.

• رتّب عناصر التنقل بترتيب الشرح، لا بترتيب الطبقات في الملف.
• أعطِ الأجزاء التي تحمل معنى نصاً بديلاً عبر aria-label أو aria-labelledby، واجعل الزخرفة بحيث تتجاهلها التقنيات المساعدة.
• عند تفعيل تفضيل تقليل الحركة في المتصفح، أوقف الحركة وتأكد أن المعلومة ما زالت مقروءة. بحسب README، تتوقف أمثلة anatomy عن الحركة في هذه الحالة.

ما الذي تضيفه طبقة WebGL فعلاً؟

تضيف الطبقة التأثيرات التي تحتاج إلى حساب الضوء والحركة داخل الصورة نفسها. لنفترض، كمثال توضيحي افتراضي لا يمثل عميلاً حقيقياً، أن فريقاً يشرح دورة تشغيل محطة ضخ لموظفين جدد. الخزان والمضخة والصمامات تبقى SVG، بينما يمكن إضافة تدفق الماء داخل الأنبوب كتأثير WebGL.

يذكر README أمثلة مثل النار والعادم والماء والإضاءة والتوهج والبخار. لذلك يبدأ القرار بسؤال واحد: هل التأثير جزء من الفكرة التي يشرحها الرسم؟

• SVG: الأجزاء الصلبة والأنابيب والمؤشرات والتسميات.
• WebGL: اللهب والعادم والماء والإضاءة والبخار، عندما يكون التأثير جزءاً من الشرح.

تكلفة الصيانة والأداء والتوافق

كل طبقة إضافية تعني ملفات أكثر يجب فهمها وتحديثها. إذا غيّر أحد أعضاء الفريق زاوية الكاميرا، فيجب أن تتطابق طبقة SVG وطبقة WebGL معها.

من ناحية التوافق، تحتاج الشيدرات إلى WebGL. ويذكر README أن الرسم يبقى مقروءاً دونها، وأن الحركة تتوقف عند تفعيل تقليل الحركة. لذلك لا تضع المعلومة الأساسية داخل الشيدر وحده.

ومن ناحية الأداء، يذكر README أن بناء مثال raptor-engine يستغرق عدة دقائق. هذا وقت بناء لا وقت عرض، وأداء العرض على أجهزة المستخدمين يقيسه فريقكم بنفسه. ويصف README وضع 3D بأنه بيتا، فلا يخلط هذا القسم بينه وبين طبقة WebGL.

القاعدة العملية: ابدأ بـ SVG، ولا تضف طبقة WebGL أو تأثيرات شيدر في الرسوم التوضيحية إلا عندما يكون التأثير نفسه جزءاً من الفكرة. وإذا كانت الطبقة تحمل معلومة أساسية، فانقلها إلى الأجزاء الصلبة أو إلى النص.

ما الذي تفعله الأداة بالوصف الذي تكتبه؟

بحسب README، تبني الأداة الهندسة مرة واحدة من قائمة الأجزاء، ثم تشغّل فحصًا هندسيًا عليها. يتحقق الفحص في kit/audit.mjs من أن الأجزاء لا تمر عبر بعضها، وأن كل طرف يقع على تثبيت، وأن التداخلات مرسومة بترتيب العمق الصحيح. هذا فحص لاتساق الرسم مع نفسه.

المستودع يصف نطاق الفحص بهذه العبارات فقط. مقارنة الرسم بمخطط المصنع أو بمواصفة الجهاز تبقى خطوة يقوم بها الفريق بنفسه.

• الفحص يتحقق من الاتساق الهندسي داخل الرسم، ولا يُستخدم بديلًا عن مطابقة المقاسات مع الجهاز.
• الأداة ترسم الآلات والأدوات والأثاث، ولا ترسم الأشخاص ولا الخرائط الدقيقة، بحسب README.
• الفكرة التي لا تملك آلية ميكانيكية واضحة تخرج أضعف، بحسب README.

كيف تراجع التسميات والنسب والوصلات؟

عامل الناتج كمسودة فنية. قارن كل تسمية بلوحة الجهاز أو بدليل تشغيله المعتمد، وقارن النسب بالقياس الفعلي أو بالمخطط الذي تعتمده الشركة، واطلب من شخص يعرف الجهاز أن يراجع اتجاه الوصلات.

مثال توضيحي، لا يمثل شركة بعينها: يطلب فريق صيانة في محطة ضخ رسمًا لمسار المياه بين المضخة وصمام العزل. إذا لم يحدد الوصف الجانب الذي تدخل منه الوصلة، فقد يرسم الشكل الأنبوب من الجهة المعاكسة لما هو مركّب فعلًا. لذلك اكتب في الوصف جانب كل وصلة بالنسبة لواجهة محددة، ثم راجع الرسم مع من يعرف المحطة. فحص الاتساق لن يلتقط هذا النوع من الخطأ، لأن الرسم سيكون متسقًا مع وصفه.

عنوان ووصف لكل رسم

كل رسم يحمل معلومة يحتاج إلى بديل نصي يشرح غرضه. تتناول إرشادات WCAG هذا في معيار 1.1.1 الخاص بالمحتوى غير النصي، وتذكر تقنيات مثل ARIA6 وARIA10 لتوفير بديل نصي عبر aria-label وaria-labelledby. أما الزخرفة التي لا تحمل معلومة فتُخفى عن التقنيات المساعدة حتى لا يقرأها قارئ الشاشة دون فائدة.

الوصف الجيد يذكر ما يوضحه الرسم. عبارة «مخطط يوضح مسار الماء من الخزان إلى المضخة» أفضل بكثير من «رسم لمضخة». وإذا كان الرسم يعرض قيمة متغيرة مثل قراءة عداد، فاكتب القيمة الحالية في نص قريب منه داخل الصفحة.

• العنوان: اسم الآلة أو النظام في جملة واحدة.
• الوصف: ما الذي يتحرك، وما الذي يجب أن يلاحظه القارئ.
• القيم المرئية: نص موازٍ يحمل الرقم نفسه المعروض على الرسم.

التباين والتشغيل بلوحة المفاتيح

افحص تباين النص والألوان التي تدل على الحالة، مثل الأخضر للتشغيل والأحمر للإنذار، بأداة فحص تباين تطبق متطلبات WCAG المناسبة لحجم النص. لا تعتمد على اللون وحده، بل اكتب الحالة نصيًا بجانبه.

ثم شغّل الرسم بلوحة المفاتيح وحدها. تأكد من أن كل عنصر تفاعلي يصل إليه التنقل، وأن مؤشر التركيز يظهر بوضوح. اختبر أيضًا وضع تقليل الحركة في نظام التشغيل، لأن الرسم قد يتوقف عن الحركة فيه.

الشيدر يحتاج WebGL. لذلك اختبر الصفحة مع إيقاف WebGL، وتأكد من أن الرسم ما زال مقروءًا بمعلوماته الأساسية.

حجم الملف والأداء

راقب حجم ملف SVG وعدد عناصره. الرسم الكثيف بعدد كبير من الأجزاء الصغيرة يحتاج وقتًا أطول للعرض، وهذا يظهر أوضح على الهواتف والأجهزة القديمة. لا تذكر هذه المقالة رقمًا محددًا للحجم المقبول، لذلك حدّد ميزانية خاصة بفريقك واختبرها على الأجهزة التي يستخدمها موظفوك فعلًا.

الرسوم التي تحتوي على WebGL أو حركة مستمرة تزيد الحمل على المعالج والبطارية. لا تكتفِ بجهاز المطور، بل شغّل الصفحة على جهاز متوسط المواصفات وعلى هاتف يستخدمه الفريق الميداني.

• افتح الملف في المتصفحات الأساسية التي يستخدمها فريقك.
• راقب سلاسة الحركة، وأوقفها إذا أثّرت على قراءة المعلومات.
• احفظ نسخة خفيفة للعرض على الشاشات الصغيرة إذا كان الرسم كثيفًا.

ما الذي يعمل على جهازك؟

يذكر README أن المكتبة تستخدم وحدات Node المدمجة فقط، ولا تحتاج إلى مفاتيح API ولا إلى حزم npm إضافية. لكن التثبيت يجلب المستودع من GitHub، ويصف README أن ذلك ينسخه كاملاً بما فيه الأمثلة.

في المقطع الذي راجعناه لا يصف README اتصالاً بالشبكة غير التثبيت ومشاركة الأشكال. هذا لا يعني أنه لا يوجد اتصال آخر، فإذا كانت سياسة شركتكم تتطلب ذلك، راقب حركة الشبكة أثناء التثبيت والبناء بنفسك.

• يعمل محلياً: بناء الملفات عبر سكربت Node، وكتابة الصفحات بجوار السكربت، وفحوص Chrome. يصف README أن الفحوص تشغّل Chrome بملف تعريف مؤقت ومنفذ محلي.
• قد يخرج من الجهاز: التثبيت يجلب الملفات من GitHub. ويصف README مشاركة الشكل إلى معرض المجتمع، وفيها تعرض الأداة ما سيُرسل قبل موافقتك.
• يحتاج صلاحيات: تشغيل Chrome والوصول إلى منفذ محلي. ويذكر README أن صندوق Codex الرملي قد يوقف هذه الفحوص.

ماذا تراجع قبل التشغيل وبعده؟

اقرأ سكربت البناء وسكربت الفحص قبل أول تشغيل، فكل شكل يصل إليك كمصدر تملكه: سكربت Node وصفحة يكتبها. ويذكر README أن الفحوص تعتمد على Chrome، لذلك حدّد المتصفح الذي سيعمل، وهل تحتاج إلى ضبط متغير CHROME_PATH.

مثال توضيحي: يشغّل مهندس الأداة على جهاز اختبار معزول، ثم يقارن النتيجة بالنسخة السابقة قبل أي تحديث. يذكر README أن التحديث يتم عبر git pull داخل مجلد المهارة، وهذا يغيّر الكود الذي يعمل على جهازك، فأعد الاختبار بعده.

أما فحص الملفات الناتجة وصلاحيتها وإمكانية وصولها فيُشرح في القسم السادس. وتصف MDN صيغة SVG بأنها نصية تعمل مع CSS وJavaScript، لذلك لا يُعد الملف الناتج ملفاً ثابتاً بالضرورة.

الوصف الذي تكتبه كمدخل

الوصف الجيد يذكر كل جزء باسمه، ويحدد اتجاه التدفق، ويحدد ما الذي يجب أن يتحرك. استخدم القيم من وثيقة المشروع، واترك الخانات الناقصة فارغة بدلاً من تقدير غير موثوق. كلما كان الوصف محدداً، قلّت الافتراضات التي يضطر الرسم إلى اتخاذها.

• الخزان: السعة بالمتر المكعب [من وثيقة المشروع]، ومتصل بخط السحب من الأسفل.
• المضخة: تسحب من الخزان وتدفع إلى خط التوزيع، ويظهر التدفق بحركة في السائل.
• صمامات العزل: واحد قبل المضخة وواحد بعدها، ويُغلق كل منهما عند النقر.
• مقياس الضغط: بعد المضخة، ويعرض قيمة الضغط من النموذج نفسه.
• الوصلات: قطر الأنابيب [من المواصفة]، ومسار كل وصلة من نقطة إلى نقطة.

ما الذي تتحقق منه بعد الإخراج؟

الرسم المولد ليس دليلاً على صحة المحطة. ابدأ بالأرقام: هل تطابق كل قيمة تظهر في الرسم الوثيقة الأصلية؟ ثم تحقق من الوصلات: هل تنتهي كل وصلة عند تركيب واضح؟ يذكر README أن فحص الهندسة يتأكد من أن الأجزاء لا تخترق بعضها وأن كل طرف يقع على حامل. هذا فحص هندسي، وليس فحصاً لصحة المحطة نفسها.

ثم راجع إمكانية الوصول. يصف MDN صيغة SVG بأنها لغة نصية مفتوحة تعمل مع CSS وJavaScript، لذلك يمكن فحص الملف كنص قبل النشر. وتطلب إرشادات WCAG نصاً بديلاً للمحتوى غير النصي الذي يحمل معلومة، وإخفاء الزخارف عن التقنيات المساعدة.

وتذكّر حدود الأداة: هي ليست مكتبة مخططات بيانية، ولا ترسم أشخاصاً أو خرائط دقيقة. فإن احتجت إلى منحنى زمني للضغط، فهو خارج ما تقدمه الأداة.

• هل تطابق كل قيمة في الرسم الوثيقة الأصلية؟
• هل تتبع الأسهم اتجاه السائل فعلاً؟
• هل يوجد نص بديل يصف الرسم؟
• هل راجعت الملف في المتصفح قبل اعتماده؟