تطوير التطبيقات

مبادئ تصميم واجهة الهاتف

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

  • الدرس 3 من 8
  • مبتدئ
  • مجاني، دون تسجيل

الأعمدة الأربعة لواجهة الهاتف

العمود الأول له أرقام منشورة. والثلاثة الأخرى لا، وتُفحص بالنظر إلى التطبيق نفسه.

واجهة هاتف قابلة للاستعمالبإبهام واحد، أثناء الحركة، وقابلة للانقطاع في أي لحظة
  • مدى الإبهام

    العمل الأساسي في المنطقة المريحة. وحجم الهدف 24 في 24 بكسل CSS على الأقل بحسب WCAG، و48 في 48 وحدة بحسب دليل أندرويد.

  • التسلسل

    عمل أساسي واحد في كل شاشة. فالشاشة الصغيرة لا تتسع لعملين متساويي الوزن.

  • الاستجابة

    علامة فورية على اللمسة ولو تأخر رد الخادم. وإلا ضُغط الزر مرتين.

  • الثبات

    حالات الخطأ والتحميل والفراغ تبدو نفسها في كل شاشة.

واستيفاء الأربعة لا يضمن أن يُستعمل التطبيق. فإن كان ما يفعله التطبيق غير لازم فلن تنفع واجهة بلا عيب.

آخر مراجعة: تُراجع الحقائق وأسماء الأدوات في هذا الدرس مقابل مصادرها في هذا التاريخ.

أين تختلف واجهة الهاتف عن واجهة سطح المكتب؟

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

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

أربعة أعمدة تؤدي هذه الوظيفة. مدى الإبهام يقول ما الذي يمكن ضغطه دون تحريك الهاتف في اليد. والتسلسل يقول أين تقع العين أولاً. والاستجابة تقول كيف تُظهر الشاشة أن شيئاً يجري بعد اللمس. والثبات يقول إن النمط الواحد يبقى نفسه في كل شاشة.

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

مبادئ تصميم واجهة الهاتف: الإبهام والحجم والاتجاه

إلى أين يصل الإبهام، وكم ينبغي أن يكون حجم الهدف؟

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

أما حجم الهدف فليس موضع تخمين، لأن له أرقاماً والأرقام منشورة. يقول معيار WCAG 2.2 في البند 2.5.8 إن هدف مدخلات المؤشر لا يقل عن 24 في 24 بكسل CSS، مع استثناءات يعددها بنفسه: هدف أصغر تحيطه مسافة كافية، أو وظيفة متاحة بطريقة أخرى في الصفحة نفسها، أو هدف يقع داخل جملة. ودليل إتاحة أندرويد نفسه يعطي رقماً أكبر: 48 في 48 بكسل مستقلاً عن الكثافة على الأقل، مع 8 وحدات فصل بين هدفين على الأقل، ويوضح أن 48 وحدة تساوي نحو تسعة مليمترات فيزيائية على أي شاشة.

وفي صفحة غوغل نفسها نقطة أنفع من الرقم ذاته: منطقة اللمس تمتد خارج الحدود المرئية للعنصر. فأيقونة تبدو بعرض 24 وحدة تصير هدفاً بـ48 وحدة بفضل الحشو حولها. أي لا يلزمك أن تجعل الزر كبيراً وقبيحاً؛ يلزمك أن تجعل المنطقة التي تسمع اللمسة كبيرة.

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

مناطق الشاشة الأربع من زاوية الإبهام

  • المنطقة المريحة

    أسفل الشاشة من جهة اليد. موضع العمل الأساسي وشريط التبويب.

  • منطقة التمدد

    الوسط وقرب الأعلى. جيدة للمحتوى لا لزر كثير الاستعمال.

  • الركن البعيد

    بلوغه يعني تزحليق الهاتف في اليد. موضع مناسب لعمل خطر كالحذف.

  • الشريط العلوي

    خارج متناول اليد الواحدة فعلياً في الهاتف الكبير. عنوان نعم، وزر كثير الاستعمال لا.

يد واحدة

هذا التقسيم يفترض إمساك الهاتف بيد واحدة. ومن يكتب بيدين له خريطة أخرى، وأنت لا تعرف أيهما هو.

أألتزم عرف المنصة أم أضع تصميمي الخاص؟

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

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

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

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

أي القرارات للمنصة وأيها لك

تقرره المنصة

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

تقرره أنت

  • اللون والرسم وشكل بطاقة المنتج
  • نبرة النص وأسماء الأقسام
  • شاشة التعريف ومسار الاستعمال الأول
  • الحالة الفارغة والكلمات المكتوبة فيها
  • ما تكتبه في الإشعار

لا علامة خطأ حمراء هنا لأن أي عمود ليس خاطئاً. والخطأ نقل بند من عمود إلى الآخر.

أين تنكسر الواجهة الفارسية على الهاتف؟

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

أولاً الأرقام. تقول أبل إن ترتيب الأرقام داخل عدد بعينه لا يُعكس أبداً: رقم الهاتف ورقم البطاقة والعدد 541 تحتفظ بالترتيب نفسه في أي اتجاه. لكن ترتيب الأرقام التي تظهر تقدماً أو عدّاً يجب أن يُعكس، لأن الأداة نفسها معكوسة. والقاعدتان تتشابهان وهما عملياً متعاكستان.

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

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

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

الأشياء التي لا تظهر إلا على شاشة هاتف فارسية

ورقة مراجعة الواجهة الفارسية على الهاتفمن اليمين إلى اليسار

افحص هذه

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

لا تفعل هذه

  • عكس الساعة والشعار وعلامة الصح
  • كتابة ملف تنسيق ثانٍ للاتجاه المعاكس فقط
  • وضع زر كثير الاستعمال في الركن العلوي البعيد
  • بناء منتقي تاريخ مخصص حين يكفي منتقي النظام

لا تجد أداة آلية أياً من هذه. أعطِ الهاتف لمن يقرأ الفارسية واطلب منه أن يسجّل مرة.

الحالات التي لا يرسمها أحد في التصميم الأول

كل شاشة تجلب بيانات لها خمس حالات على الأقل، والتصميم الأول يعرض واحدة منها عادةً. الحالة الفارغة حين لا شيء بعد. وحالة التحميل بينما هو قادم. وحالة الخطأ حين لم يأتِ. وحالة عدم الاتصال، وهي شائعة على الهاتف نادرة على سطح المكتب. والحالة الممتلئة، أي الصورة التي رُسمت في فيغما.

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

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

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

المسار السريع مع الذكاء الاصطناعي

ثمة عمل ميكانيكي يقضي فيه الناس ساعات وتجيده النماذج فعلاً: تحويل خصائص الاتجاه الفيزيائية في ملف التنسيق إلى خصائص منطقية، كي تعمل الواجهة من اليمين إلى اليسار بلا ملف ثانٍ. وهو لا يحتاج حكماً إلا في حالات قليلة، فيكفي هنا نموذج سريع رخيص من صنف Gemini Flash ويكون النموذج المتقدم هدراً؛ واختيارنا الحالي في قسم الذكاء الاصطناعي في الموقع. أما خطوة الحكم فتؤديها أنت، وهي مسماة أدناه.

  1. استخرج قائمة المرشحين بأمر grep واحد لا بالعين. والنمط: margin-left وmargin-right وpadding-left وpadding-right وborder-left وborder-right وleft وright وحدهما، وtext-align بقيمة left أو right.
  2. أعطِ النموذج مخرجات grep مع أرقام الأسطر وشغّل الوصفة أدناه. ولا تسلّمه الملف كله؛ فالأسطر المطابقة وحدها تكفي ويأتي الجواب أقصر وأدق.
  3. العمود الثالث من الجواب هو خطوة الحكم وهي لك: أكّد أو ارفض كل سطر وسمه النموذج بأنه ينبغي أن يبقى فيزيائياً. والأيقونات والأسهم المدارة تقع في ذلك العمود عادةً.
  4. طبّق التغييرات وافتح الشاشة في الاتجاهين لا بالفارسية وحدها. فالتحويل الصحيح يترك الإنجليزية سليمة أيضاً؛ وإن تحرك شيء في العرض من اليسار إلى اليمين فقد غيّرت موضعه لا اتجاهه.

وصفة جاهزة للنسخ

هذه الأسطر من ملف CSS وكل منها يحمل خاصية اتجاه فيزيائية. والهدف أن تعمل الواجهة من اليمين إلى اليسار دون كتابة ملف ثانٍ.

أعطِ لكل سطر ثلاثة أعمدة بالضبط ولا تكتب أي شرح زائد:
1) رقم السطر والسطر نفسه دون تغيير.
2) البديل المنطقي المقترح إن وُجد: margin-inline-start وmargin-inline-end وpadding-inline-start وpadding-inline-end وborder-inline-start وborder-inline-end وinset-inline-start وinset-inline-end، وtext-align بقيمة start أو end.
3) كلمة واحدة: «منطقي» أو «يبقى فيزيائياً». وكل سطر يشير إلى اتجاه فيزيائي حقيقي، كحدٍّ حُوّل إلى سهم بـrotate أو أيقونة معناها «إلى اليمين»، يجب أن يأخذ «يبقى فيزيائياً».

القواعد:
- السطر الذي لست واثقاً منه ضع له «يبقى فيزيائياً» واكتب السبب في العمود الثالث في عشر كلمات كحد أقصى.
- لا تحذف أي سطر ولا تضف سطراً جديداً.
- لا تُبدِ رأياً في اللون أو الحجم أو أسماء الأصناف.

الأسطر:
{مخرجات grep}

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

الذكاء الاصطناعي في هذا العمل

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

أدوات تساعد فعلا

  • Gemini خيار مجدٍ اقتصادياً لتمريرة ميكانيكية على أسطر التنسيق، وهو يقرأ الصور أيضاً. وصفحة غوغل نفسها تقول إن تطبيق جيميناي يعمل في أكثر من مئتين وثلاثين دولة ومنطقة، وإيران ليست في تلك القائمة.
  • Claude جواب أفضل حين تريد كتابة الحالات المنسية لمكوّن على شكل كود. وإيران ليست في أي من قائمتي الدول المدعومة لدى أنثروبيك؛ قرأنا ذلك في صفحة أنثروبيك نفسها.
  • Accessibility Scanner ليس ذكاءً اصطناعياً وهو هنا عمداً: فهو يقيس فعلاً حجم هدف اللمس على هاتف أندرويد. وتقول صفحة غوغل نفسها إن الأداة لا تحتسب استعمال TouchDelegate إلا من أندرويد 10 فصاعداً، فقد تُبلغ في النسخ الأقدم عن هدف موسّع رغم ذلك.

اين ينقلب ضدك

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

المصادر: W3C: Understanding SC 2.5.8 Target Size (Minimum) W3C WAI: Easy Checks Android Accessibility Help: Touch target size Anthropic: supported countries Google: where Gemini Apps are available

حدود هذه النصيحة

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

من عملنا نحن

قرار بصري واحد في موقعنا كلّف قائمة الهاتف خمسين بكسل من العرض، واضطررنا إلى حصر ذلك القرار في سطح المكتب. فشريط ترويسة rgb.ir فيه تأثير زجاجي مبني بـbackdrop-filter، وهو في main.css لا يُشغَّل إلا فوق 1101 بكسل. والسبب مكتوب ومقيس في تعليق تلك الكتلة: backdrop-filter يحوّل العنصر إلى containing block، فتلتصق القائمة المنسدلة للهاتف، وهي position: absolute بـinset-inline: 0، بداخل الشريط بدل عرض الصفحة الكامل. والرقم في التعليق: 390 بكسل صارت 340.
والمثال الثاني من الجنس نفسه. فالجداول ذات الثلاثة أعمدة فأكثر في هذا الموقع تتحول إلى بطاقات تحت 780 بكسل، واختيارها بـ:has(thead th:nth-child(3)) في CSS لا بصنف تضيفه جافاسكريبت. والسبب هو بالضبط نقطة الاستجابة المذكورة في هذا الدرس: إن انتظر التخطيط سكربتاً اهتزت الصفحة بعد أول رسم. جافاسكريبت تكتب تسمية كل خلية، لكن ارتفاعها محجوز مسبقاً بـmin-height ليكون واحداً قبل تشغيل السكربت وبعده.

اسئلة متابعة حقيقية

هل تصميم واجهة الهاتف هو نفسه التصميم المتجاوب للموقع؟

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

أأضع الزر الأساسي أعلى الشاشة أم أسفلها؟

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

أنحتاج إلى نسخة ثانية من الواجهة لجعل التطبيق من اليمين إلى اليسار؟

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