قائمة التحقق لتوافق واجهة المستخدم عبر الويب والتطبيقات الأصلية

ماذا يعني توافق واجهة المستخدم (ولماذا ينهار بسهولة)\n\nتوافق واجهة المستخدم يعني أن تطبيق الويب وتطبيق الهاتف الأصلي يشعران وكأنهما نفس المنتج. ليس تطابقًا حرفيًا في البيكسلات، بل نفس المعنى، نفس التوقعات، ونفس النتائج عندما ينقر المستخدم أو يكتب أو ينتظر.\n\nاختبار بسيط: إذا تعلّم المستخدم شيئًا على شاشة معينة، يجب أن ينتقل ذلك التعلم إلى الشاشة المكافئة على المنصة الأخرى.\n\nغالبًا ما تكون الفروق الصغيرة هي ما يربك المستخدمين. إذا كان الزر يقول "حفظ" على الويب و"تم" على الهاتف، يتوقف المستخدم لحظة. إذا كان التباعد أضيق على منصة ما، تشعر الشاشة بمزيد من التوتر حتى لو كانت الخصائص نفسها. إذا كان النقر على صف قائمة يفتح التفاصيل على المحمول لكنه يظهر خانة اختيار على الويب، يبدأ الناس بالتخمين بدلًا من الثقة بالواجهة.\n\nما الذي يجب أن يتطابق تمامًا؟ أي شيء يؤثر على الفهم والثقة. بالنسبة لمعظم المنتجات، يعني ذلك:\n\n- الأسماء والتسميات لنفس الإجراءات، ومكان ظهورها\n- التخطيطات الأساسية للشاشات الرئيسية (التنقل، الإجراءات الرئيسية، المعلومات الحرجة)\n- الحالات مثل التحميل، الخطأ، المعطّل، والنتائج الفارغة\n- سلوك المكوّنات (نقرة، سحب، ضغطة طويلة، لوحة مفاتيح، تركيز)\n- نبرة وبنية الرسائل (ماذا حصل، ماذا يجب فعله بعد ذلك)\n\nما الذي يمكن تكييفه؟ الأشياء المتعلقة براحة كل منصة. عرض الخطوط، مساحات الأمان، والأنماط الأصلية مثل إيماءات العودة في iOS أو أزرار النظام في Android يمكن أن تختلف، طالما يصل المستخدمون إلى نفس المكان ويفهمون ما تغيّر.\n\nهدف عملي هو "أنماط متوقعة". إذا حدّث شخص ملفه الشخصي على الويب، يجب أن يتعرّف على نفس الحقول، نفس قواعد التحقق، ونفس رسالة النجاح على المحمول. حتى لو بنت بسرعة باستخدام أداة مثل AppMaster (واجهة ويب بالإضافة إلى واجهات أصلية iOS/Android)، يحتاج التوافق إلى قواعد صريحة حتى تنمو التطبيقات في نفس الاتجاه، لا كمنتجين متشابهين لكن مختلفين.\n\n## ضع خطًا أساسيًا مشتركًا قبل مقارنة الشاشات\n\nتنهار مراجعات التوافق عندما تُقاس كل منصة مقابل فكرة مختلفة عن "الصحيح". قبل مقارنة شاشات الويب والمحمول، اتفقوا على ما يُحسب "نفس الشيء"، واكتبه. قد لا يكون مثيرًا، لكنه يمنع ساعات من إعادة العمل.\n\nلا تحتاج إلى مواصفة ضخمة. تحتاج إلى بعض القواعد التي توقف الانحراف الشائع:\n\n- الطباعة: الأحجام، ارتفاع السطر، وكيف يلتف النص أو يُقتطع\n- التباعد: الحشو، الهوامش، خطوات الشبكة، ومتى نستخدم تخطيطًا مدمجًا مقابل مريحًا\n- أدوار الألوان: الأساسي، التحذير، الخافت، حدود التباين الدنيا، وتوقعات الوضع المظلم\n- المكونات: أي الأزرار، المدخلات، البطاقات، وأنماط التنقل "مُعتمدة"\n- الحالات: التحميل، الخطأ، الفارغ، المعطّل، وردود فعل النجاح\n\nبعدها، اختر مصدر حقيقة واحد. بعض الفرق تستخدم ملف تصميم؛ أخرى تعتمد على Tokens مع دليل مكتوب قصير. المهم أن القواعد موجودة في مكان واحد وتسجَّل التغييرات. إذا كنت تبني بـ AppMaster، فالمفيد هو مواءمة Tokens والمكوّنات القابلة لإعادة الاستخدام عبر مُنشئات واجهة الويب والمحمول حتى تظهر نفس الخيارات في كل مكان.\n\nأخيرًا، حدد الإيقاع والملكية. عامل التوافق كاختبار، لا كلمسة تجميل أخيرة. قرّر متى تحدث المراجعات (قبل الإصدارات وبعد تغييرات على المكوّنات المشتركة)، من يوقّع (التصميم للمظهر، المنتج للغرض، ضمان الجودة للحالات الحافة وتغطية الأجهزة)، وماذا يعني "منجز" (تصحح الاختلافات أو تُقبل صراحة مع سبب).\n\nمثال: إذا أضاف بوابة العملاء صفحة "الفواتير" جديدة، قرّر مسبقًا كيف تنهار الجداول على المحمول، كيف تشرح الحالات الفارغة غياب الفواتير، وماذا يفعل زر "ادفع الآن" عندما يكون الجهاز غير متصل. مع هذا الأساس، تصبح المراجعة فحص انحراف سريع، لا نقاشًا حول الذوق.\n\n## قواعد الطباعة التي تبقى متناسقة عبر المنصات\n\nالطباعة هي المكان الذي يتحول فيه "تقريبًا نفس الشيء" سريعًا إلى "هذا يشعر كمنتج مختلف". ابدأ بتسمية أنماطك بتوكنات واضحة (H1، H2، Body، Caption) وتطبيقها بنفس الطريقة على الويب والأصلية.\n\nاختر عائلات خطوط مُراعية للمنصة. استخدم عائلة أساسية لكل منصة تتطابق في الشخصية والكثافة، ثم عرّف بدائل. مثال: خط النظام على iOS (SF)، خط النظام على Android (Roboto)، وخط ويب يبدو قريبًا، مع بديل آمن إلى system-ui. الهدف ليس أحرف متطابقة، بل نفس النبرة وقابلية القراءة.\n\nحدّد مقياس أحجام واحدًا مرة، واجعله صغيرًا بما يكفي حتى لا يخترع أحد أحجامًا جديدة. مثال:\n\n- H1: 28-32px، ارتفاع السطر 1.2-1.3\n- H2: 20-24px، ارتفاع السطر 1.25-1.35\n- Body: 16px، ارتفاع السطر 1.4-1.6\n- Secondary: 14px، ارتفاع السطر 1.4-1.6\n- Caption: 12-13px، ارتفاع السطر 1.3-1.5\n\nسلوك النص مهم بقدر الحجم. قرّر كيفية التعامل مع العناوين الطويلة والبيانات غير المتوقعة (الأسماء، العناوين، مواضيع التذاكر) حتى لا ينحرف الويب عن المحمول:\n\n- العناوين: حد أقصى سطرين، ثم اقتطاع مع الحذف (...)\n- خلايا الجداول: سطر واحد، اقتطاع، اظهار القيمة الكاملة عند النقر/التحويم\n- الفقرات: التفاف طبيعي، لا قطع منتصف الكلمة\n- الأرقام: استخدم أرقامًا جدولية إذا كانت متاحة، حافظ على محاذاة الفواصل العشرية\n\nالمحاذاة اختلاف شائع آخر. افترض المحاذاة لليسار لمعظم النص، خاصة النماذج والقوائم. المركزية فقط للمواقف القصيرة والمحددة مثل رسالة نجاح أو عنوان حالة فارغة.\n\nضع حدود وصولية ولا تتفاوض بشأنها. استهدف على الأقل 16px للنص الأساسي على المحمول، تجنّب أوزان خطوط فاتحة جدًا عند الأحجام الصغيرة، وحافظ على تباين كافٍ للقراءة في ضوء ساطع. إذا استخدمت AppMaster، اجعل هذه Tokens التصميمية مشتركة حتى تقرأ الشاشة بشكل متناسق عبر الويب والأصلية.\n\n## قواعد التباعد والتخطيط (بما في ذلك مساحات الأمان على المحمول)\n\nالتباعد هو المكان الذي يتحول فيه "تقريبًا نفس الشيء" إلى "يبدو مختلفًا". إذا كانت شاشة الويب تتنفس لكن شاشة المحمول مكتظة، يلاحظ المستخدمون ذلك حتى عندما تتطابق الألوان والخطوط.\n\nابدأ بمقياس تباعد واحد تستخدمه كلتا المنصتين. مقياس بسيط يعتمد على 4 يتوافق جيدًا مع CSS وشبكات التخطيط الأصلية. اجعل القواعد بسيطة: العناصر ذات العلاقة تحصل على فجوات أصغر من الأقسام المنفصلة، حشوة شاشة افتراضية ثابتة، والاستثناءات نادرة وموثقة.\n\nنقطة أساسية نموذجية تبدو هكذا:\n\n- خطوات مشتركة: 4، 8، 12، 16، 24\n- فجوات بين العناصر المرتبطة: 8-12\n- فجوات الأقسام: 16-24\n- حشوة الشاشة الافتراضية: 16\n\nثم قوّم مساحات الأمان على المحمول. لا ينبغي أن تجلس المحتويات تحت النوتش أو مؤشر الهوم أو أشرطة النظام. قاعدة واضحة تساعد: "كل المحتوى الأساسي يحترم مساحة الأمان + الحشوة الأساسية." إذا كان لديك شريط سفلي، أدرجه في إدخال المحتوى حتى تظل آخر صفوف القائمة قابلة للوصول.\n\nكثافة القوائم تحتاج أيضًا خيارًا صريحًا. اختر خيارين وسمّيهما (مضغوط ومريح). حدّد ارتفاع الصف، الحشو الرأسي، واستخدام الفاصل. طبق نفس الخيار عبر الويب والمحمول لنفس نوع الشاشة، حتى لا تبدو "قائمة الفواتير" كتصميمين مختلفين.\n\nأهداف اللمس جزء من التباعد. على المحمول، يجب أن تكون عناصر التحكم سهلة الاستهداف حتى عندما يكون التخطيط ضيقًا. حد أدنى جيد هو 44x44 للنقرات، مع فراغ كافٍ بين الإجراءات لمنع النقرات الخاطئة.\n\nبالنسبة للويب، اكتب سلوك الاستجابة عند نقاط توقف رئيسية: عدد الأعمدة، سلوك الشريط الجانبي، ومتى تتحول القوائم إلى بطاقات. أثناء مراجعة التوافق، قارِن النية لا البيكسلات. يمكن للويب أن يعرض المزيد دفعة واحدة، لكنه لا ينبغي أن يغير التسلسل الهرمي أو يخفي الإجراءات الرئيسية.\n\nإذا بنَيت في AppMaster، فالحفاظ على نفس Tokens التباعدية في مُنشئات واجهة الويب والمحمول يساعد الشاشات على الاتساق افتراضيًا.\n\n## الحالات: التحميل، الخطأ، المعطّل، والشاشات الفارغة\n\nالتناسق غالبًا ما ينكسر في الحالات، لا في المسار السعيد. عامل واجهات الحالات كمكوّن من الدرجة الأولى بنفس البنية والنبرة والإجراءات على الويب والأصلية.\n\nابدأ بالإجراءات. يجب أن تكون الإجراءات الأساسية واضحة وموجودة بشكل متناسق (مثلًا، أسفل اليمين في حوارات الويب وزر ثابت أسفل الشاشة على المحمول). لا تتنافس الإجراءات الثانوية مع الأساسية. تحتاج الإجراءات المدمرة إلى احتكاك إضافي: تسمية واضحة ("حذف المشروع"), خطوة تأكيد، وطريقة آمنة للخروج ("إلغاء").\n\nالعناصر المعطلة لا يجب أن تبدو كأخطاء. استخدم التعطيل فقط عندما لا يمكن تنفيذ الإجراء حقًا بعد، وفسّر السبب بالقرب من عنصر التحكم. نص المساعدة أفضل من تلميحات لا يرى مستخدمو المحمول معظمها. إذا كان المستخدم يستطيع الإصلاح، قل كيف ("أضف طريقة دفع لتمكين الدفع"). إذا لم يستطع، قل متى سيفتح ("متاح بعد الموافقة").\n\n### قواعد التحميل\n\nاختر نمط تحميل واحد لكل سياق وحافظ عليه عبر المنصات:\n\n- استخدم skeletons لمحتوى الصفحة الذي سيظهر في مكانه (جداول، بطاقات، قوائم).\n- استخدم مؤشر دوار فقط للانتظار القصير والحاجز (تسجيل الدخول، إرسال نموذج).\n- ضع المؤشر حيث ينظر المستخدم بالفعل: داخل الزر الذي نقره، أو في مساحة المحتوى التي تتغير.\n- منع قفز التخطيط بحجز مساحة للعناصر الأساسية (العنوان، الزر الرئيسي).\n\n### قواعد الخطأ والحالة الفارغة\n\nيجب أن تكون الأخطاء محددة، هادئة، وقابلة للاسترداد. ضع الرسالة بجانب المشكلة عندما يكون ذلك ممكنًا (مستوى الحقل). وإلا، استخدم لافتة أو حوار مع إجراء استرداد واحد واضح: "أعد المحاولة"، "حرّر التفاصيل"، أو "اتصل بالدعم". تجنّب لوم المستخدم.\n\nتعمل الحالات الفارغة بشكل أفضل بقالب قابل للتكرار: عنوان قصير، جملة إرشادية واحدة، وإجراء رئيسي واحد يتوافق مع ما يتوقعه المستخدم فعله بعد ذلك. مثال: في بوابة عملاء مبنية بـ AppMaster، يمكن لعلامة تبويب "الفواتير" الفارغة أن تقول "لا توجد فواتير بعد" مع زر "إنشاء فاتورة" كنداء رئيسي، مع مزامنة الصياغة والسلوك بين الويب والمحمول.\n\n## قواعد سلوك المكونات (ليس كيف تبدو فقط)\n\nقد تبدو شاشتان متشابهتين وتظل تشعران مختلفتين. السلوك هو ما يلاحظه المستخدم أولًا: ماذا يحدث عند النقر مرتين، كيف تظهر الأخطاء، وهل "العودة" تعيده إلى المكان المتوقع. يجب أن تغطي قائمة التحقق للتوافق قواعد التفاعل، لا الألوان والخطوط فقط.\n\n### حدّد قواعد التفاعل للمكوّنات الأساسية\n\nاكتب حقيقة واحدة لكل مكوّن، ثم قارِنها مع أنماط كل منصة دون تغيير النتيجة.\n\n- الأزرار: حدّد ردود الفعل عند الضغط (ripple، تمييز، هابتك)، إن كان للضغط الطويل وظيفة، وكيف تمنع الإرسال المزدوج (تعطيل لفترة قصيرة أو حتى عودة الطلب).\n- النماذج: قرّر متى يحدث التحقق. العديد من الفرق تتحقق عند فقدان التركيز لحقل البريد وتعرض الأخطاء فقط عند الإرسال للحقول الاختيارية. حافظ على مواضع الأخطاء الداخلية متسقة وركّز على أول حقل غير صالح دائمًا.\n- القوائم: اختر نمط تحديث أولي. قد يستخدم المحمول السحب للتحديث بينما يستخدم الويب زر تحديث، لكن كلاهما يجب أن يحدث نفس البيانات ويحافظ على موضع التمرير بشكل متوقع. اختر أيضًا نهجًا واحدًا للترقيم: صفحات مرقمة، "تحميل المزيد"، أو تمرير لا نهائي.\n- التنقل: اجعل سلوك العودة يطابق النية، لا حيل النظام. حدد كيف تتصرف الروابط العميقة، كيف تُغلق النوافذ المنبثقة، ومتى تكون التدفقات بملء الشاشة مقابل منبثقة.\n- البحث: موحّد ما يفعله زر المسح (النص فقط مقابل النص والنتائج)، حافظ على نص النتائج الفارغ متناسقًا، واجعل رقائق الفلتر قابلة للإزالة بنقرة واحدة.\n\n### مثال صغير يمكنك اختباره\n\nتخيّل بوابة عملاء حيث يبحث المستخدمون عن الفواتير، يفتحون التفاصيل، ويدفعون. على المحمول، النقر السريع مرتين على "ادفع" قد ينشئ شحنتين إذا عرضت مؤشر تحميل لكن لم تُقفل العملية. على الويب، ضغط Enter قد يرسل النموذج رغم أن حقلًا غير صالح.\n\nإذا بنيت هذا في AppMaster، اضبط نفس القواعد في منطق Business Process (طلب دفع واحد جاري التنفيذ)، ووافق سلوك واجهة المستخدم في منشئي الويب والمحمول.\n\nقرّر مرة واحدة، ثم تحقق في كل إصدار: انقر مرتين، أرسل بوجود أخطاء، حدّث، عُد للخلف، امسح البحث.\n\n## خطوة بخطوة: كيفية إجراء مراجعة للتوافق\n\nتعمل مراجعات التوافق أفضل كطقس قابل للتكرار. الهدف التقاط "نفس الميزة، تجربة مختلفة" قبل أن يلاحظها المستخدمون.\n\nابدأ باختيار مجموعة مقارنة جنبًا إلى جنب: تسجيل الدخول، البحث، عرض التفاصيل، إرسال نموذج، والإعدادات. استخدم نفس بيانات الاختبار على الويب والمحمول حتى تقارن السلوك لا المحتوى.\n\nأجرِ المراجعة بترتيب ثابت:\n\n- أكد أن التسميات، الإجراءات، والنتائج متطابقة.\n- تحقق من الحالات: التحميل، الخطأ، الفارغ، المعطّل، النجاح.\n- افحص السلوك: النقرات، التركيز، لوحة المفاتيح، التمرير، التأكيدات.\n- ثم افحص التباعد، الطباعة، والصقل البصري.\n- أعد الاختبار بعد الإصلاحات على مسار "الطريق الذهبي" واحد على الأقل.\n\nتبقى بطاقة تسجيل النتائج القرارات سريعة. لكل شاشة أو مكوّن، علّمها كمطابقة (نفس النية والسلوك، اختلافات منصّية فقط)، اختلاف مقبول (واجهة مختلفة، نفس النتيجة، موثّق)، أو عدم تطابق (يغيّر المعنى، يضيف خطوات، أو يكسر قاعدة).\n\nعند تسجيل عدم تطابق، أرفق لقطتي شاشة، القاعدة المنتهكة بالضبط (مثل "موضع الفعل الرئيسي" أو "نبرة الحالة الفارغة"), وتأثير المستخدم في جملة واحدة. إذا بنيت بـ AppMaster حيث يمكن للويب والأصلية مشاركة المنطق، لاحظ إن كانت المشكلة إعدادًا في منشئ الواجهة، قاعدة مكوّن مشترك، أو في عملية الأعمال نفسها.\n\nكن مستعدًا لتعديل القواعد أيضًا. إذا تكرّر نفس "الاختلاف" كثيرًا، فغالبًا أن دليلك غامض أو غير واقعي. حدّث النظام بدلًا من تصليح الشاشات واحدة واحدة.\n\n## الفخاخ الشائعة التي تسبب عدم الاتساق\n\nمعظم مشاكل التوافق ليست قرارات كبيرة. إنها تغييرات صغيرة تتسلل أثناء التنفيذ، إصلاحات الأخطاء، والتعديلات في اللحظة الأخيرة. تساعد القائمة، لكن فقط إذا عرفت أين يبدأ الانحراف عادة.\n\nتآكل النسخ نصيًا (copy drift) كلاسيكي. قد يقول الويب "حفظ التغييرات" بينما يقول الهاتف "تحديث" رغم أنهما يؤدّيان نفس العمل. يشعر المستخدمون بذلك كاحتكاك، خاصة في إعادة تعيين كلمات المرور، تحرير الملفات الشخصية، وتأكيد الدفع.\n\nالتباعد ينزلق بصمت. يضيف شخص ما 6px من الحشو لإصلاح شاشة واحدة، وتنتشر الاستثناءات. بعد عدة سبرنتات، يبدو تخطيط الويب فسيحًا بينما يبدو المحمول مكتظًا رغم أن كلاهما يفترض استخدام نفس التصميم.\n\nالفجوات في الحالات تسبب أكبر ارتباك. قد يعرض الويب حالات فارغة واضحة ورسائل خطأ، بينما ينتهي الحال على المحمول بقائمة فارغة، مؤشر تحميل لا ينتهي، أو فشل صامت. يحدث هذا غالبًا عندما تُدار الحالات في أماكن مختلفة (الواجهة الأمامية على الويب، منطق العرض على المحمول).\n\nأثناء المراجعات، راقب:\n\n- تسميات مختلفة لنفس الإجراء، أو نبرة مختلفة لنفس الرسالة\n- حشوات أو هوامش عشوائية أضيفت خارج مقياس التباعد\n- حالات التحميل/الخطأ/الفارغ/المعطّل مفقودة على منصة واحدة\n- تسرب إعدادات افتراضية للمنصة (مفاتيح تبديل، منتقي تواريخ، تنبيهات) دون قاعدة واضحة\n- تراجعات الوصول: ترتيب تركيز الويب المربك أو أهداف اللمس الصغيرة على المحمول\n\nمثال بسيط: في بوابة عملاء، يعرض الويب "لا توجد فواتير بعد" مع تلميح وزر لإضافة طريقة دفع، بينما يعرض المحمول قائمة فارغة. الحل ليس تلميحًا بصريًا فقط؛ هو الاتفاق على نص الحالة الفارغة وسلوك الزر وتطبيقه في كل مكان.\n\nحتى لو كنت تبني كلًا من الويب والأصلية في AppMaster، يظل التوافق بحاجة لقواعد للنص، Tokens التباعد، ومعالجة الحالات حتى لا تصبح كل شاشة استثناءً بذاتها.\n\n## قائمة تحقق سريعة للتوافق (فحص 5 دقائق قبل الإصدار)\n\nفحص سريع للتوافق يلتقط ما يلاحظه المستخدمون أولًا: نص يبدو غريبًا، أزرار تتصرف بشكل مختلف، وشاشات تبدو غير مكتملة.\n\nافتح شاشة مرجعية واحدة على الويب وعلى هاتف. اختر مسارك الأكثر استخدامًا (تسجيل الدخول، البحث، الدفع، نموذج طلب)، ثم قم بمسح سريع:\n\n- مقياس الطباعة: العناوين، نص الجسم، والتعليقات تتبع نفس خطوات الأحجام وقواعد الوزن. افحص ارتفاع السطر خاصة على الهواتف الصغيرة.\n- التباعد وراحة اللمس: الحشو حول البطاقات، النماذج، والحوارات متناسق. على المحمول، تأكد من أن المحتوى ليس مكتظًا قرب النوتش أو مؤشر الهوم.\n- حالات الشاشة: الشاشات الرئيسية تعرض بوضوح التحميل، الخطأ، الفارغ، والمعطّل. يجب أن يعرف المستخدم دائمًا ما الذي يحدث وماذا يفعل بعد ذلك.\n- سلوك المكوّنات: الإجراءات الأساسية تُرسل بنفس الطريقة، تعرض نفس الاستجابة، وتمنع النقرات المزدوجة. سلوك العودة لا يجب أن يضيّع البيانات المدخلة فجأة.\n- مقصد النسخ: التسميات ورسائل الخطأ متطابقة في المعنى، لا في الكلمات فقط. إذا قال الويب "عنوان الفوترة" لا يجب أن يقول المحمول "معلومات الدفع" ما لم تكونا مختلفتين حقًا.\n\nإذا فشل شيء، اطرح سؤالًا واحدًا: "هل سيشعر المستخدم أنه انتقل إلى منتج مختلف؟" أصلح أكبر عدم تطابق أولًا.\n\nمثال: في بوابة عملاء مبنية بـ AppMaster، قد ترى نفس النموذج على الويب والأصلية، لكن النسخة المتنقلة تسمح بالنقر مرتين على "إرسال" على شبكة بطيئة. أضف حالة تحميل واضحة وعلِّم الزر بالتعطيل حتى ينتهي الطلب لتتطابق السلوكيات وتتجنّب التكرارات.\n\n## مثال: جعل بوابة العملاء متناسقة على الويب والمحمول\n\nتخيل بوابة عملاء بسيطة بها ثلاث شاشات: تسجيل الدخول، الملف الشخصي، وقائمة الطلبات. يُستخدم تطبيق الويب على لابتوب من قبل موظفي الدعم. يُستخدم تطبيق المحمول من قبل العملاء أثناء التنقل. تريد نفس التدفق والمعنى في كل مكان حتى لو اختلفت تفاصيل الواجهة.\n\nاختلاف شائع يظهر عندما لا يملك العميل طلبات بعد. على الويب، قد تعرض صفحة الطلبات حالة فارغة ودية مع أيقونة، رسالة قصيرة، وزر رئيسي مثل "تصفح المنتجات". على المحمول، تنتهي نفس الشاشة أحيانًا كقائمة فارغة بدون إرشاد. يفترض المستخدمون أن التطبيق معطّل.\n\nالحل هو معامل التوافق كقواعد، لا كحدس بصري. هكذا تُطبّق القواعد:\n\n- قالب الحالة الفارغة: نفس البنية والنص على كلتا المنصتين: عنوان ("لا توجد طلبات بعد"), سطر إرشادي واحد، وإجراء رئيسي واضح. احتفظ بالإجراءات الثانوية كروابط لا كأزرار.\n- تسلسل الأزرار: إجراء رئيسي واحد لكل شاشة. على الويب والمحمول، يكون "تصفح المنتجات" هو الأساسي. "اتصل بالدعم" يصبح ثانويًا ويبدو أخف.\n- مقياس التباعد: استخدم نفس خطوات التباعد (مثل 8، 16، 24) حتى يشعر التخطيط بأنه مرتبط. يمكن للمحمول إضافة حشو عمودي أكثر حول أهداف اللمس، لكنه يستخدم نفس المقياس.\n\nالسلوك هو المكان الذي ينكسر فيه التوافق غالبًا، فحدده صراحة:\n\n- التحديث: يدعم المحمول السحب للتحديث؛ الويب يستخدم أيقونة تحديث أو زر "إعادة التحميل". كلاهما يفعّل نفس حالة التحميل ويحاول الحفاظ على موضع التمرير عند الإمكان.\n- الترقيم: يمكن للويب عرض "تحميل المزيد" وعناصر التحكم في حجم الصفحة؛ المحمول يستخدم التمرير اللانهائي أو "تحميل المزيد". في كلتا الحالتين تُلحق العناصر الجديدة بدل استبدال القائمة.\n- الأخطاء: إذا فشل تحميل الطلبات، تعرض كلتا المنصتين نفس الرسالة وإجراء إعادة المحاولة. لا تُخفي الأخطاء وراء إشعار سريع في منصة وتعرضها كامل الشاشة في أخرى.\n\nالنتيجة هي ما يهم: يفهم المستخدم ما الذي يحدث وماذا يفعل بعد ذلك. تحترم الواجهة كل منصة (مساحات الأمان، سلوك لوحة المفاتيح، التحويم مقابل النقر)، لكن المنتج يبدو كبوابة واحدة متماسكة.\n\n## الخطوات التالية: حافظ على التوافق مع نمو المنتج\n\nالحفاظ على التوافق سهل الوصول إليه عند التنفيذ ومعلوم لخسارته مع تحرك المنتج. الميزات الجديدة، إصلاحات سريعة، وطلبات المنصة فقط تتراكم بسرعة. الهدف أن يصبح "الحفاظ على الاتساق" الخيار الأسهل.\n\nعامل قائمة التحقق كوثيقة حية. بعد كل إصدار، سجّل ما تغيّر وما فاجأك. إن شحنت شاشة بحالة فارغة مختلفة على المحمول، حوّل ذلك إلى قاعدة أو مثال حتى لا يتكرر.\n\n### اجعل الاتساق طريق المقاومة الأقل\n\nكلما استعدت أكثر، قلما تضطر لإعادة القرار. ابنِ مجموعة صغيرة من المكونات القابلة لإعادة الاستخدام وقوالب الصفحات لأنماط شائعة مثل شاشات القوائم، شاشات التفاصيل، النماذج، وعروض "لا نتائج". احتفظ بمصدر حقيقة واحد للنسخ المشتركة (تسميات الأزرار، رسائل الحالات الفارغة) حتى لا تطور الويب والمحمول نبرة مختلفة ببطء.\n\nروتين بسيط يساعد الفرق على الصدق:\n\n- حدّث قواعد التوافق ضمن ملاحظات الإصدارات، ليس بعد أسابيع.\n- أضف عناصر توافق إلى معايير قبول الميزة (الحالات، التباعد، السلوك).\n- افرض لقطات شاشة أو تسجيلات قصيرة من كل منصة عند توقيع PR أو QA.\n- تتبّع "الاختلافات المعتمدة" حتى تكون الاستثناءات صريحة لا عشوائية.\n- جدولة فحص سريع للتوافق بعد أي تغيير في نظام التصميم.\n\n### اجعل التوافق جزءًا من طريقة البناء\n\nبغض النظر عن الأدوات التي تستخدمها، هدفك مشاركة Tokens، القوالب، وقواعد السلوك. إذا كنت تستخدم AppMaster، فاعتبر Tokens ونماذج الواجهة القابلة لإعادة الاستخدام أصولًا مشتركة بين مُنشئات الويب والمحمول، واحفظ السلوك الحاسم في مكان واحد عبر Business Process Editor. بهذه الطريقة، يدعم البناء التوافق بدلًا من أن تُطبَّق التعديلات بجهود بطولية في اللحظات الأخيرة.\n\nإذا أردت أن يثبت هذا، اختر ميزة قادمة وأضِف فحوصات التوافق إلى تعريف جاهزيتها. إنها طريقة سهلة لتحويل "الحفاظ على الاتساق" إلى عمل يمكن للفريق التحقق منه فعليًا.