25 سبتمبر 2025·7 دقيقة
حالات التحميل والخطأ والفراغ المتسقة عبر الويب والجوال
تعلم نظامًا بسيطًا لتوحيد حالات التحميل والخطأ والفراغ عبر الويب والجوال، ليبقى واجهة المستخدم المولّدة بالذكاء الاصطناعي متماسكة وتحتاج لتلميع أقل.
تعلم نظامًا بسيطًا لتوحيد حالات التحميل والخطأ والفراغ عبر الويب والجوال، ليبقى واجهة المستخدم المولّدة بالذكاء الاصطناعي متماسكة وتحتاج لتلميع أقل.
حالات التحميل والخطأ والفراغ هي الشاشات (أو كتل واجهة صغيرة) التي يراها الناس عندما ينتظر التطبيق، أو فشل شيء ما، أو ببساطة لا يوجد ما يُعرض. هذه حالات طبيعية: الشبكات بطيئة أحيانًا، تُرفض الأذونات، والحسابات الجديدة تبدأ بدون بيانات.
تتبعثر لأن الفرق عادة تضيفها متأخرًا وبسرعة. يبني الفريق مسار السعادة أولًا، ثم يضيف مؤشر تحميل سريعًا، ورسالة حمراء، ومَوضع "لا عناصر" حيثما تنهار الواجهة. افعل ذلك عبر عشرات الشاشات فتنتهي بمجموعة من العناصر الفردية.
التكرار السريع يزيد الطين بلّة. عندما تُنتج الواجهة بسرعة (بما في ذلك الواجهات المولّدة بالذكاء الاصطناعي)، قد يظهر التخطيط الرئيسي في دقائق، لكن هذه الحالات سهلة التجاوز. كل شاشة جديدة تحصل على نمط مؤشر تحميل مختلف، وصياغة مختلفة ("حاول مرة أخرى" مقابل "إعادة المحاولة")، ومكان زر مختلف. السرعة المكتسبة في البداية تتحول إلى أعمال تلميع قبل الإطلاق.
الحالات غير المتطابقة تشتت المستخدمين وتكلف الفرق وقتًا. لا يعرف الناس إن كان القايمة الفارغة تعني "لا نتائج" أو "لم تُحمّل بعد" أو "ليس لديك وصول". على قسم الاختبار اختبار العديد من المتغيرات الصغيرة، وتنسل الأخطاء لأنها تختلف بين الويب والجوال.
"الفوضى" غالبًا تظهر كالتالي:
الهدف بسيط: نهج موحَّد عبر الويب والجوال. إذا كان فريقك يولد ميزات بسرعة (مثلاً باستخدام منصة مثل Koder.ai)، فإن وجود نمط حالات مشترك يصبح أكثر أهمية لأن كل شاشة جديدة تبدأ متسقة افتراضيًا.
معظم التطبيقات تتكرر عند نقاط ضغط متشابهة: القوائم، صفحات التفاصيل، النماذج، لوحات المعلومات. هنا تتكاثر المؤشرات واللافتات ورسائل "لا شيء هنا".
ابدأ بتسمية وتوحيد خمسة أنواع من الحالات:
حالتان خاصتان تستحقان قواعد منفصلة لأن سلوكهما مختلف:
عبر الشاشات والمنصات، حافظ على البنية متسقة: أين تظهر الحالة، نمط الأيقونة، النبرة، والإجراءات الافتراضية (إعادة المحاولة، تحديث، مسح الفلاتر، إنشاء). ما يمكن أن يختلف هو السياق: اسم الشاشة وجملة تستخدم كلمات المستخدم.
مثال: إذا ولّدت قائمة ويب وقائمة جوال لـ"المشاريع"، ينبغي أن تشارك نفس نمط نتائج صفرية. تسمية الإجراء يمكن أن تتوافق مع المنصة ("مسح الفلاتر" مقابل "إعادة ضبط").
إذا ابتكرت كل شاشة مؤشر تحميلها الخاص، وبطاقة الخطأ الخاصة، ورسالة الفراغ الخاصة، فسوف ينتهي بك الأمر بدزينة من الإصدارات المطموسة. أسرع حل هو "مجموعة حالات" صغيرة يمكن لأي ميزة إسقاطها.
ابدأ بثلاث مكوّنات قابلة لإعادة الاستخدام تعمل في كل مكان: Loading وError وEmpty. اجعلها مقصودة في الملل. يجب أن تكون سهلة التعرّف ولا تتنافس مع واجهة المستخدم الرئيسية.
اجعل المكوّنات متوقعة بتحديد مجموعة صغيرة من المدخلات:
ثم ثبّت الشكل. قرر مرة واحدة على التباعد، والطباعة، وحجم الأيقونة، ونمط الزر، واعتبره قاعدة. عندما يبقى حجم الأيقونة ونوع الزر ثابتين، يتوقف المستخدمون عن ملاحظة واجهة الحالة ويبدأون بالثقة بها.
حافظ على عدد المتغيرات محدودًا حتى لا تتحول المجموعة إلى نظام تصميم ثانٍ. ثلاثة أحجام عادةً تكفي: صغير (ضمني)، افتراضي (قسم)، وصفحة كاملة (حاجز).
إذا ولّدت شاشات في Koder.ai، فإن تعليمًا بسيطًا مثل "استخدم StateKit الافتراضي للتحميل/الخطأ/الفراغ" يمنع الانحراف. كما يقلل من أعمال التنظيف قبل الإطلاق عبر React web وFlutter mobile.
النص جزء من النظام، وليس زخرفة. حتى لو كان التخطيط متسقًا، فإن الصياغات الارتجالية تجعل الشاشات تبدو مختلفة.
اختر صوتًا مشتركًا: قصير، محدد، هادئ. اشرح ما حدث بلغة بسيطة ثم قل للمستخدم ما الذي يجب عليه فعله بعد ذلك. معظم الشاشات تحتاج عنوانًا واضحًا واحدًا، شرحًا قصيرًا، وإجراءً واحدًا واضحًا.
بعض أنماط الرسائل تغطي معظم الحالات. اجعلها قصيرة حتى تناسب الشاشات الصغيرة:
تجنّب نصًا غامضًا مثل "حدث خطأ ما" وحده. إذا لم تكن تعرف السبب حقًا، قل ما تعرفه وما الذي يمكن للمستخدم فعله الآن. "لم نتمكن من تحميل مشاريعك" أفضل من "خطأ".
ضع قاعدة واحدة: كل خطأ أو حالة فراغ تعرض خطوة تالية.
هذا مهم أكثر مع واجهات الذكاء الاصطناعي المولّدة، حيث تظهر الشاشات بسرعة. القوالب تحافظ على تناسق النص فلا تعيد كتابة عشرات الرسائل الفردية أثناء التلميع النهائي.
عندما تقترح شاشات الحالة إجراءات مختلفة من صفحة لأخرى، يتردد المستخدمون. ثم ينتهي الفريق بتعديل الأزرار والنص قبل الإطلاق.
قرّر أي إجراء يخص كل حالة، وحافظ على الوضع والتسمية ثابتين. معظم الشاشات يجب أن تحتوي على إجراء أساسي واحد. إذا أضفت ثانويًا، يجب أن يدعم المسار الرئيسي، لا يتنافس معه.
حافظ على الإجراءات المسموح بها ضيقة:
الأزرار المملة ميزة. تجعل الواجهة مألوفة وتساعد الشاشات المولَّدة على البقاء متناسقة.
اعرض "إعادة المحاولة" فقط عندما يكون من الواقعي أن تعمل مرة أخرى (انتهت المهلة، شبكة متقلبة، 5xx). أضف ازدواج منع سريع حتى لا تُمطِر النقرات الطلبات، وغيّر الزر إلى حالة تحميل أثناء إعادة المحاولة.
بعد فشل متكرر، احتفظ بنفس الزر الأساسي وحسّن المساعدة الثانوية (مثل تلميح "تحقق من الاتصال" أو "حاول لاحقًا"). تجنّب إدخال تخطيطات جديدة لأن شيئًا فشل مرتين.
بالنسبة لتفاصيل الخطأ، اعرض سببًا واضحًا يمكن للمستخدمين اتخاذ إجراء بشأنه ("انتهت جلستك. سجل الدخول مرة أخرى."). أخفِ التفاصيل التقنية افتراضيًا. إن احتجت إليها، ضعها خلف ضابط "تفاصيل" ثابت عبر المنصات.
مثال: فشل تحميل قائمة "المشاريع" على الجوال. كلا المنصتين تظهران نفس الإجراء الأساسي "إعادة المحاولة"، ويُعطّل أثناء إعادة المحاولة، وبعد فشلين تضيف تلميحًا صغيرًا عن الاتصال بدلاً من تغيير تخطيط الأزرار كله.
عامل اتساق الحالات كتغيير منتج صغير، لا كإعادة تصميم. ابدأ تدريجيًا واجعل التبنّي سهلًا.
ابدأ بلقطة سريعة لما لديكم. لا تهدف إلى الكمال. التقط التباينات الشائعة: مؤشرات مقابل هياكل هيكلية (skeletons)، أخطاء صفحة كاملة مقابل لافتات، شاشات "لا نتائج" بنغمات مختلفة.
خطة طرح عملية:
بمجرد وجود المكوّنات، الموفر الحقيقي للوقت هو مجموعة قواعد قصيرة تزيل الجدل: متى تحجب الحالة الصفحة بالكامل مقابل بطاقة فقط، وأي إجراءات يجب توافرها.
احفظ القواعد قصيرة:
إذا استخدمت مولد واجهات AI مثل Koder.ai، تعود هذه القواعد بسرعة. يمكنك الطلب "استخدم مكوّنات StateKit" والحصول على شاشات تطابق نظامك على كل من React web وFlutter mobile مع أعمال تنظيف أقل.
عادةً ما تحدث أعمال التلميع المتأخرة لأن معالجة الحالات بُنيت كعناصر فردية. الشاشة "تعمل"، لكن التجربة تختلف في كل مرة يحدث فيها تأخير أو فشل أو لا توجد بيانات.
الهياكل الهيكلية مفيدة، لكن تركها طويلاً يجعل الناس يظنون أن التطبيق مجمّد. سبب شائع هو عرض هياكل كاملة عند نداء بطيء بدون إشارة أن الأمور تتحرك.
حدّ زمن العرض: بعد مهلة قصيرة، انتقل إلى رسالة أخف "لا يزال التحميل مستمرًا…" أو أظهر تقدمًا عندما تستطيع.
الفرق غالبًا يكتب رسالة جديدة كل مرة، حتى لو كان السبب واحدًا. "حدث خطأ ما"، "تعذر الجلب"، و"خطأ في الشبكة" قد تصف حالة واحدة، لكنها تبدو غير متسقة وتُصعّب الدعم.
اختر تسمية واحدة لكل نوع خطأ أعد استخدامها على الويب والجوال، بنفس النبرة ومستوى التفاصيل.
خطأ كلاسيكي آخر هو إظهار حالة فراغ قبل اكتمال التحميل، أو عرض "لا عناصر" عندما المشكلة الحقيقية طلب فشل. يتخذ المستخدم إجراءً خاطئًا (مثل إضافة محتوى عندما ينبغي عليه إعادة المحاولة).
اجعل ترتيب القرار صريحًا: التحميل أولًا، ثم الخطأ إذا فشل، ثم الفراغ فقط عندما تعرف أن الطلب نجح.
الخطأ بدون إجراء استرداد يخلق مآزق. على النقيض، ثلاث أزرار تتنافس للانتباه شائع أيضًا.
اجعلها ضيقة:
الاختلافات الصغيرة تتراكم: أنماط الأيقونات، التباعد، أشكال الأزرار. هذا أيضًا حيث قد تنحرف الواجهات المولّدة بالذكاء الاصطناعي إن تعدّدت التعليمات لكل شاشة.
ثبّت التباعد ومجموعة الأيقونات والتخطيط لمكوّنات الحالة حتى ترث كل شاشة جديدة نفس البنية.
إذا أردت معالجة حالات متسقة عبر الويب والجوال، اجعل القواعد "المملة" صريحة. معظم أعمال التلميع المتأخرة تحصل لأن كل شاشة تختلق سلوك تحميلها ومهلاتها وتسمياتها.
لتحميل صفحة كاملة، اختر افتراضيًا واحدًا: الهياكل الهيكلية للشاشات المحتوية على محتوى كثير (قوائم، بطاقات، لوحات معلومات) ومؤشر دوار فقط للانتظار القصير حيث لا يُعرف التخطيط.
أضف حد مهلة حتى لا تبقى الواجهة معلقة بصمت. إذا استغرق التحميل أكثر من حوالي 8 إلى 10 ثوانٍ، انتقل إلى رسالة واضحة وإجراء مرئي مثل "إعادة المحاولة".
للاعباء الجزئية، لا تفرغ الشاشة. حافظ على المحتوى الموجود مرئيًا وأظهر مؤشر تقدم صغيرًا بالقرب من القسم الذي يتحدّث (مثلاً شريط رفيع في الرأس أو مؤشر داخل السطر).
للبيانات المخزّنة مؤقتًا، فضّل "قديم لكنها صالحة للاستخدام". اعرض المحتوى المخزّن فورًا وأضف مؤشرًا طفيفًا "تحديث…" ليعلم الناس أن البيانات قد تتغير.
عدم الاتصال حالة بحد ذاتها. قلها ببساطة، وقل ما الذي ما زال يعمل. مثال: "أنت غير متصل. يمكنك عرض المشاريع المحفوظة، لكن المزامنة متوقفة." اقترح خطوة تالية واحدة مثل "حاول مرة أخرى" أو "افتح المحفوظات".
حافظ على هذه القواعد عبر المنصات:
إذا كنت تولّد واجهات باستخدام أداة مثل Koder.ai، تضمين هذه القواعد في StateKit المشترك يساعد على إبقاء كل شاشة جديدة متسقة افتراضيًا.
تخيّل CRM بسيط به شاشة قائمة جهات اتصال وشاشة تفاصيل جهة اتصال. إذا تعاملت مع حالات التحميل والخطأ والفراغ كعناصر فردية، ينحرف الويب والجوال بسرعة. نظام صغير يحافظ على التوافق حتى عندما تُنتج الواجهات بسرعة.
حالة الفراغ للمرة الأولى (قائمة جهات الاتصال): يفتح المستخدم جهات الاتصال ولا يرى شيئًا بعد. على الويب والجوال، يبقى العنوان نفسه ("جهات الاتصال"), تشرح رسالة الفراغ السبب ("لا توجد جهات اتصال بعد"), ويُعرض إجراء واضح واحد ("أضف جهة الاتصال الأولى"). إن تطلب الإعداد خطوة (مثل ربط بريد وارد أو استيراد CSV)، تشير الحالة الفارغة إلى تلك الخطوة المحددة.
التحميل على شبكة بطيئة: يفتح المستخدم صفحة تفاصيل جهة اتصال. كلا المنصتين تعرضان هيكلًا هيكليًا متوقعًا يطابق بنية الصفحة النهائية (رأس، حقول أساسية، ملاحظات). زر العودة لا يزال يعمل، واسم الصفحة ظاهر، وتتجنب مؤشرات عشوائية في مواضع مختلفة.
خطأ الخادم: فشل طلب التفاصيل. يظهر نفس النمط على الويب والجوال: عنوان قصير، جملة واحدة، وإجراء أساسي ("إعادة المحاولة"). إن فشلت إعادة المحاولة مرة أخرى، اعرض خيارًا ثانيًا مثل "العودة إلى جهات الاتصال" حتى لا يبقى المستخدم محاصرًا.
ما يظل متسقًا هو بسيط:
قد يبدو الإصدار "مكتملًا" حتى يصطدم أحدهم باتصال بطيء، أو حساب جديد، أو واجهة برمجة تطبيقات متقطعة. تساعدك هذه القائمة على اكتشاف ثغرات اللحظات الأخيرة دون تحويل اختبار الجودة إلى لعبة البحث.
ابدأ بشاشات القوائم، لأنها تتكاثر. اختر ثلاث قوائم شائعة (نتائج البحث، العناصر المحفوظة، النشاط الأخير) وتأكد أنها كلها تستخدم نفس بنية الحالة الفارغة: عنوان واضح، جملة مفيدة واحدة، وإجراء أساسي واحد.
تأكد من أن الحالات الفارغة لا تظهر أبدًا أثناء تحميل البيانات. إن وميضت "لا شيء بعد" لجزء من الثانية ثم استُبدلت بالمحتوى، يتراجع مستوى الثقة بسرعة.
تحقق من مؤشرات التحميل للتطابق: الحجم، الموضع، ومدة عرض معقولة حتى لا تومض. إن عرض الويب شريط تحميل علوي بينما الجوال يعرض هيكل كامل لنفس الشاشة، سيشعر المستخدم أنه منتجان مختلفان.
يجب أن تجيب الأخطاء دائمًا على سؤال "ماذا الآن؟". كل خطأ يحتاج خطوة تالية: إعادة المحاولة، التحديث، تغيير الفلاتر، تسجيل الدخول مجددًا، أو الاتصال بالدعم.
فحص سريع قبل اعتبار البناء جاهزًا:
إذا كنت تستخدم منشئ واجهة مثل Koder.ai، تهم هذه الفحوصات أكثر لأن الشاشات تولَّد بسرعة لكن الاتساق يعتمد على المجموعة المشتركة وقواعد النص.
الاتساق أسهل عندما يصبح جزءًا من العمل اليومي، وليس عملية تنظيف لمرة واحدة. كل شاشة جديدة يجب أن تستخدم نفس الأنماط بدون أن يتذكر أحد "جعله مطابقًا" في النهاية.
اجعل سلوك الحالات جزءًا من تعريف الإنجاز. لا تُعتبر الشاشة مكتملة حتى تحتوي على حالة تحميل، وحالة فراغ (عند الاقتضاء)، وحالة خطأ مع إجراء واضح.
اكتب القواعد بشكل خفيف، لكن دون إهمال. مستند صغير به لقطات وشروح الصياغة الدقيقة عادة يكفي. عامل المتغيرات الجديدة كاستثناءات. عندما يقترح أحدهم تصميم حالة جديدًا، اسأل إن كانت حالة جديدة فعلًا أم أنها تندرج تحت المجموعة.
إن كنت تعيد هيكلة العديد من الشاشات، قلّل المخاطرة عبر خطوات مسيطرة: حدّث مسارًا واحدًا في كل مرة، تحقق منه على الويب والجوال، ثم تابع. في Koder.ai، تساعد اللقطات والعودة على جعل التغييرات الكبيرة أكثر أمانًا، ويمكن أن يساعد وضع التخطيط على تعريف StateKit المشترك حتى تتبع الشاشات المولّدة الافتراضات من اليوم الأول.
اختر هذا الأسبوع منطقة واحدة تسبب عادة إصلاحات متأخرة (غالبًا نتائج البحث، البدء، أو موجز النشاط). ثم:
علامة ملموسة على النجاح: قِلّة التذاكر الصغيرة مثل "أضف إعادة المحاولة"، "تبدو الحالة الفارغة غريبة"، أو "مؤشر التحميل يحجب الصفحة".
عيّن مالكًا واحدًا لمعايير الحالات (مصمم أو قائد تقني أو كلاهما). لا يحتاج هذا الشخص للموافقة على كل شيء، لكن يجب أن يحمي المجموعة من الانقسام التدريجي إلى متغيرات جديدة متشابهة وتختلف في السلوك وتكلف وقتًا لاحقًا.
ابدأ بتسمية مجموعة صغيرة من الحالات التي ستستخدمها في كل مكان: التحميل الأولي، التحديث/التحديث الخلفي، الحالة الفارغة الأساسية، نتائج صفرية، والخطأ. أضف قواعد صريحة للحالة دون اتصال ولشبكة بطيئة حتى لا تُعامل كأخطاء عشوائية. بعد اتفاق الفريق على التسميات والمحفزات، يصبح سلوك الواجهة متوقعًا عبر الشاشات والمنصات.
ابنِ StateKit صغير مكوّن من ثلاثة عناصر قابلة لإعادة الاستخدام: Loading وError وEmpty. اجعل كل واحد يُدار بنفس المدخلات (عنوان، رسالة قصيرة، إجراء أساسي واحد، وتفاصيل اختيارية) حتى يمكن لأي شاشة إدراجه دون اختراع واجهة جديدة. اجعل الانماط الافتراضية سهلة الاستخدام حتى يتوقف الفريق عن إنشاء حالات فردية.
استخدم ترتيب قرار بسيط: اعرض التحميل حتى تنتهي الطلبية، ثم اعرض الخطأ إن فشل، وعرض الفراغ فقط بعد استجابة ناجحة بلا بيانات. هذا يمنع المشكلة الشائعة حيث يظهر “لا عناصر” لفترة وجيزة قبل ظهور المحتوى. كما يسهل هذا على قسم الاختبار لأن السلوك يصبح متسقًا في كل مكان.
عيّن إجراء افتراضي واحد لكل حالة وأعد استخدام نفس الوسم والموقع عبر الشاشات. عادةً تُعطى الأخطاء "Retry"، والحالات الفارغة الأساسية "Create" أو خطوة الإعداد التالية، ونتائج الصفر "Clear filters". عندما يصبح الإجراء الأساسي متوقعًا، يتحرك المستخدمون أسرع ويتوقف الفريق عن الجدل حول صياغة الأزرار.
اكتب النصوص بصيغة مشتركة: عنوان قصير يحدد الحالة، جملة واحدة تشرحها بلغة بسيطة، وخطوة واضحة تالية. فضّل عبارات محددة مثل “لم نتمكن من تحميل مشاريعك” بدلاً من غموض مثل “حدث خطأ ما”. حافظ على نبرة هادئة ومتناسقة حتى يشعر مستخدمو الويب والجوال بأنهما نفس المنتج.
عامل وضع عدم الاتصال كحالة مستقلة، وليس كخطأ عام. اعرض المحتوى المخبَّأ إن وُجد، وقل بصراحة "أنت غير متصل"، واشرح ما الذي يعمل الآن. اقترح خطوة تالية مفردة مثل "حاول مرة أخرى" حتى لا يبقى المستخدم في حيرة.
تجنّب فلاشات الأخطاء السريعة على الاتصالات البطيئة عبر الانتظار قليلًا قبل تغيير واجهة المستخدم. إذا تجاوز التحميل عتبة زمنية، انتقل إلى رسالة واضحة مثل "لا يزال التحميل مستمرًا…" ووفّر إجراءً مرئيًا مثل "إعادة المحاولة". هذا يجعل التطبيق يبدو سريع الاستجابة حتى عندما تكون الشبكة بطيئة.
استخدم ثلاث أحجام متغيرة: صغيرة داخلية (بطاقة أو قسم صغير)، الحجم الافتراضي للقسم، والصفحة الكاملة الحاجزة. حدد متى يُسمح بكل منها حتى لا يبتدع الفريق خيارًا مختلفًا لكل شاشة. إبقاء التباعد ونمط الأيقونات ونمط الأزرار متطابقًا عبر المتغيرات ما يجعل التجربة متسقة.
ادمج قواعد بسيطة: حرك التركيز إلى رسالة الحالة والإجراء الأساسي عند ظهورها، أعلن حالات التحميل والأخطاء بنصوص قصيرة واضحة لقارئات الشاشة، واجعل الأزرار سهلة النقر على الجوال، ولا تعتمد على اللون أو الحركة وحدها. إذا كانت هذه القواعد جزءًا من StateKit، فكل شاشة جديدة ترثها تلقائيًا.
انفذ النشر على منطقة منتظمة في التطبيق مرة واحدة في كل مرة، ابدأ بالشاشات ذات الحركة العالية والقوائم والتفاصيل. قوّم ما لديك، اختر بضعة مواضع معيارية، ثم استبدل الحالات الفردية بالمكوّنات المشتركة كلما طرأت تغييرات على شاشة. إن كنت تولّد واجهات باستخدام Koder.ai، أضف تعليمًا ثابتًا لاستخدام StateKit افتراضيًا حتى لا تنحرف الشاشات الجديدة.