التصميم للوضع الداكن دون كسر الوضع الفاتح

يبدو منتجك أنيقاً في الوضع الفاتح (light mode). ثم يحوّل أحد المستخدمين هاتفه إلى الوضع الداكن (dark mode) في الحادية عشرة مساءً، فيتحول لون علامتك التجارية المختار بعناية إلى شريط نيون متوهج، ويختفي النص الرمادي «الخفيف» في الخلفية، وتومض بطاقة بيضاء كنت قد نسيتها كأنها فلاش كاميرا. الوضع الداكن ليس فلتراً تشغّله في النهاية. إنه نظام بصري ثانٍ يجب أن يتعايش مع الأول، وأن تتقن أحدهما بينما تكسر الآخر بصمت هو من أكثر أخطاء UI design شيوعاً التي نراها.

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

لماذا يكسر الوضع الداكن الوضع الفاتح (والعكس)

السبب الجذري دائماً تقريباً هو نفسه: ألوان مكتوبة بشكل ثابت (hardcoded) لوضع واحد يُعاد استخدامها في الآخر. يختار المصمم #FFFFFF لبطاقة و#111111 للنص لأنه يبدو رائعاً على صفحة فاتحة. بعد ستة أشهر يضيف أحدهم الوضع الداكن بقلب الخلفية، والآن يجلس النص الأسود نفسه على سطح داكن ويصبح غير مقروء.

يفشل الـ theming حين تتناثر قرارات الألوان. فهي تعيش داخل مكوّنات فردية، وأنماط مضمّنة (inline styles)، وقيم hex لمرة واحدة، ولقطات شاشة تُسلَّم للمطورين. لا يوجد مكان واحد يقول «هذا ما يعنيه السطح» أو «هذا ما يعنيه النص الأساسي». وحين يغيب هذا المصدر الموحّد للحقيقة، يصبح الوضع الداكن ترقيعاً بدلاً من نظام، وكل شاشة جديدة تخاطر بكسر أحد الوضعين.

الأسود الخالص والأبيض الخالص هما الفخ الثاني. خلفية سوداء بالكامل (#000000) مع نص أبيض ساطع تخلق تبايناً قاسياً يسبب ظاهرة الهالة، حيث يبدو النص مهتزاً، خاصة على شاشات OLED الشائعة في سوق الخليج. والأسطح البيضاء الخالصة في الوضع الداكن تشبه وميضاً مبهراً. كلا الوضعين يحتاج إلى تلطيف للحدود القصوى.

ابنِ على رموز ألوان دلالية، لا قيم خام

أهم تحوّل على الإطلاق هو الانتقال من الألوان الخام إلى الرموز الدلالية (semantic tokens). بدلاً من أن تقول لزر «كن #0066FF»، تقول له «استخدم color-primary». ثم تحدد إلى ماذا يتحول color-primary في كل سمة (theme).

بنية رموز عملية تبدو هكذا:

• الأسطح: surface-base، surface-raised، surface-overlay للخلفيات عند ارتفاعات مختلفة
• المحتوى: text-primary، text-secondary، text-disabled لتسلسل النص الهرمي
• العلامة: brand-primary، brand-hover، brand-muted
• التغذية الراجعة: status-success، status-error، status-warning، status-info
• الحدود: border-subtle، border-strong

كل رمز يحصل على قيمتين، واحدة لكل سمة. لا يعرف المكوّن أبداً أي سمة مفعّلة؛ هو فقط يطلب text-primary ويحصل على اللون الصحيح تلقائياً. هذا هو جوهر الـ theming القابل للصيانة، ويعمل بالطريقة نفسها سواء كنت تبني بمتغيرات CSS في موقع Next.js، أو بكائن ThemeData في Flutter، أو برموز تصميم في Figma.

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

اضبط التباين والعمق بشكل صحيح في الوضعين

اللون في الوضع الداكن لا يتصرف مثل اللون في الوضع الفاتح، ومعاملتهما بشكل متطابق هي حيث تتسرّب إمكانية الوصول (accessibility) بهدوء.

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

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

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

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

سير عمل يبقي السمتين أمينتين

العملية لا تقل أهمية عن لوحة الألوان. الفرق التي تطلق theming موثوقاً تتبع بضع عادات.

• صمّم الوضعين بالتوازي، لا بالتتابع. ارسم النسخة الداكنة من شاشة في الجلسة نفسها مع الفاتحة. تظهر المشكلات فوراً بدلاً من بعد أشهر.
• استخدم ملف رموز مشترك كعقد بين التصميم والتطوير. تتطابق متغيرات Figma مباشرة مع خصائص CSS المخصصة أو قيم سمة Flutter، فتكون هناك مفردات واحدة عبر الفريق كله.
• اختبر على أجهزة OLED وLCD حقيقية، لا على محاكٍ فقط. تُعرَض الخلفيات الداكنة بشكل مختلف جداً على العتاد الفعلي، وكثيراً ما تظهر مشكلات التباين فقط على شاشة حقيقية في غرفة خافتة.
• احترم تفضيل النظام افتراضياً، ثم دع المستخدمين يتجاوزونه. قراءة prefers-color-scheme وتوفير زر تبديل صريح يغطيان المستخدم الذي يريد التبديل التلقائي والآخر الذي لديه تفضيل ثابت.
• دقّق الصور والشعارات والرسوم بشكل منفصل. صور PNG الشفافة برسوم خطية داكنة تختفي على الخلفيات الداكنة. وفّر نسخاً من الأصول واعية بالسمة أو أضف حاويات خفيفة.

أهم النقاط

• يكسر الوضع الداكن الوضع الفاتح لأن الألوان مكتوبة بشكل ثابت لكل شاشة بدلاً من تعريفها مرة واحدة. الحل هو رموز ألوان دلالية بقيمة لكل سمة.
• تجنّب الأسود الخالص والأبيض الخالص. لطّف الحدود القصوى لتقليل إجهاد العين وتأثير اهتزاز النص، خاصة على شاشات OLED.
• تحقق من نسب تباين WCAG في السمتين بشكل مستقل. زوج يجتاز في وضع قد يفشل في الآخر.
• استخدم أسطحاً أفتح، لا ظلالاً، لإظهار العمق في الوضع الداكن، وخفّف تشبّع ألوان العلامة كي لا تبهر.
• صمّم واختبر الوضعين معاً من اليوم الأول. التركيب اللاحق للوضع الداكن هو مصدر معظم أخطاء الـ theming.

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