ما هي الواجهة المتفائلة ومتى تُستخدم

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

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

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

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

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

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

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

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

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

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

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

ما الذي يجب أن يحدث عندما يرفض الخادم عملية تعديل عُرضت مسبقًا بشكل متفائل في الواجهة؟

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