الأكاذيب الحقيقية لواجهات المستخدم المتفائلة

تنتقل ثلاث واجهات مستخدم (UIs) إلى حانة. الأول يطلب مشروبًا ، ثم عدة مرات أخرى. بعد ساعتين ، يسأل عن الفاتورة ويترك الحانة في حالة سكر. تطلب واجهة المستخدم الثانية مشروبًا ، وتدفع ثمنه مقدمًا ، وتطلب مشروبًا آخر ، وتدفع ثمنه وما إلى ذلك ، وفي غضون ساعتين تترك الحانة في حالة سكر. تخرج واجهة المستخدم الثالثة من الحانة وهي في حالة سكر بالفعل فور دخولها - فهي تعرف كيف تعمل الحانات وتكون فعالة بما يكفي لعدم إضاعة الوقت. هل سمعت عن هذا الثالث؟ يطلق عليه "واجهة مستخدم متفائلة".

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

مزيد من القراءة على SmashingMag:

• المستخدم هو مصمم الويب المجهول
• تصميم واجهات المستخدم القائمة على البطاقة
• واجهات المحادثة: أين نحن اليوم؟
  

ولكن قبل أن نبدأ ، نقول الحقيقة ، لا يمكن تسمية أي شيء "واجهة مستخدم متفائلة". بل هو النموذج الذهني وراء تنفيذ الواجهة. تصميم واجهة المستخدم المتفائل له تاريخه الخاص ومنطقه.

في يوم من الأيام

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

1. ينقر المستخدم على زر.
2. يتم تشغيل الزر في حالة التعطيل.
3. يتم إرسال مكالمة إلى الخادم.
4. يتم إرسال استجابة من الخادم إلى الصفحة.
5. يتم إعادة تحميل الصفحة لتعكس حالة الاستجابة.

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

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

الأيام الجيدة غير القديمة

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

1. ينقر المستخدم على زر.
2. يتم تشغيل الزر في حالة التعطيل ، ويتم عرض قرص دوار من نوع ما على الزر للإشارة إلى أن النظام يعمل.
3. يتم إرسال مكالمة إلى الخادم.
4. يتم إرسال استجابة من الخادم إلى الصفحة.
5. يتم تحديث الحالة المرئية للزر والصفحة وفقًا لحالة الاستجابة.

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

تم استخدام هذا النوع من أنماط التفاعل على نطاق واسع في كل مكان في الوسائط الرقمية. ولكن تظل هناك مشكلة واحدة: لا يزال يتعين على المستخدمين انتظار استجابة من الخادم. نعم ، يمكننا جعل خوادمنا تستجيب بشكل أسرع ، ولكن مهما حاولنا تسريع البنية التحتية ، فلا يزال يتعين على المستخدمين الانتظار. مرة أخرى ، لا يحب المستخدمون الانتظار ، بعبارة ملطفة. على سبيل المثال ، تظهر الأبحاث أن 78٪ من المستهلكين يشعرون بمشاعر سلبية نتيجة لمواقع الويب البطيئة أو غير الموثوق بها. علاوة على ذلك ، وفقًا لمسح أجرته Harris Interactive for Tealeaf ، اعترف 23٪ من المستخدمين بشتم هواتفهم ، و 11٪ صرخوا عليهم ، و 4٪ ألقوا بالفعل هواتفهم عند مواجهة مشكلة في معاملة عبر الإنترنت. التأخير من بين تلك المشاكل.

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

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

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

op-ti-mis-tic ، صفة متفائل وواثق من المستقبل.

لنبدأ بجزء "الثقة بالمستقبل".

ما رأيك: كم مرة يقوم الخادم بإرجاع خطأ في بعض إجراءات المستخدم؟ على سبيل المثال ، هل تفشل واجهة برمجة التطبيقات الخاصة بك كثيرًا عندما ينقر المستخدمون على زر؟ أو ربما يفشل كثيرًا عندما ينقر المستخدمون على ارتباط؟ بصراحة لا أعتقد ذلك. بالطبع ، قد يختلف هذا بناءً على واجهة برمجة التطبيقات وتحميل الخادم ومستوى معالجة الأخطاء وعوامل أخرى قد لا ترغب في المشاركة فيها ، بصفتك مطور الواجهة الأمامية أو متخصص تجربة المستخدم. ولكن طالما أن واجهة برمجة التطبيقات مستقرة ويمكن التنبؤ بها وتتواصل الواجهة الأمامية بشكل صحيح مع الإجراءات المشروعة في واجهة المستخدم ، ومن ثم سيكون عدد الأخطاء استجابة للإجراءات التي بدأها المستخدم منخفضًا جدًا. أود أن أذهب إلى حد القول بأنه لا ينبغي أبدًا تجاوز نسبة 1 إلى 3٪. هذا يعني أنه في 97 إلى 99٪ من الحالات عندما ينقر المستخدم على زر على موقع ويب ، يجب أن تكون استجابة الخادم ناجحة ، بدون أخطاء. هذا يستحق أن يوضع في منظور أفضل:

فكر في الأمر للحظة: إذا كنا متأكدين بنسبة 97 إلى 99٪ من نجاح الاستجابة ، فيمكننا أن نكون واثقين بشأن مستقبل تلك الردود - حسنًا ، على الأقل أكثر ثقة بشأن المستقبل من قطة شرودنجر. يمكننا كتابة قصة جديدة كاملة عن تفاعل الأزرار:

1. ينقر المستخدم على زر.
2. يتم تشغيل الحالة المرئية للزر في وضع النجاح على الفور.

هذا هو! على الأقل من وجهة نظر المستخدم ، لا يوجد شيء أكثر من ذلك - لا انتظار ، لا يحدق في زر معطل ، ولا يوجد زر دوار آخر مزعج. يكون التفاعل سلسًا ، دون أن يتدخل النظام بوقاحة لتذكير المستخدم بنفسه.

من وجهة نظر المطور ، تبدو الدورة الكاملة كما يلي:

1. ينقر المستخدم على زر.
2. يتم تشغيل الحالة المرئية للزر في وضع النجاح على الفور.
3. يتم إرسال المكالمة إلى الخادم.
4. يتم إرسال الاستجابة من الخادم مرة أخرى إلى الصفحة.
5. في 97 إلى 99٪ من الحالات ، نعلم أن الاستجابة ستكون ناجحة ، ولذلك لا نحتاج إلى إزعاج المستخدم.
6. فقط في حالة فشل الطلب سوف يتحدث النظام. لا تقلق بشأن هذا في الوقت الحالي - سنصل إلى هذه النقطة لاحقًا في المقالة.

لنلقِ نظرة على بعض الأمثلة على التفاعلات المتفائلة. ربما تكون على دراية بأزرار "الإعجاب" ، كما هو موجود في Facebook و Twitter. دعونا نلقي نظرة على الأخير.

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

دعونا نرى ما يحدث في علامة التبويب "الشبكة" الخاصة بأدوات مطوري المتصفح في هذه اللحظة بالذات.

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

بعد تلقي استجابة ناجحة من الخادم ، يتم تحديث العداد ، ولكن الانتقال أدق بكثير من تغيير اللون الفوري. يوفر هذا للمستخدم تجربة سلسة دون انقطاع ، دون أي انتظار متصور.

يوجد مثال آخر للتفاعل المتفائل على Facebook ، مع زر الإعجاب الخاص به. السيناريو مشابه تمامًا ، باستثناء أن Facebook يقوم بتحديث العداد على الفور ، جنبًا إلى جنب مع لون الزر الناجح ، دون انتظار استجابة الخادم.

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

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

علم النفس وراء واجهات المستخدم المتفائلة

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

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

تحتوي واجهة المستخدم المتفائلة على مكونين أساسيين يستحقان التحليل النفسي:

• الاستجابة السريعة لعمل المستخدم ؛
• معالجة الأعطال المحتملة على الخادم والشبكة وفي أي مكان آخر.

استجابة سريعة لعمل المستخدم

عندما نتحدث عن تصميم واجهة المستخدم المتفائل ، فإننا نتحدث عن وقت الاستجابة الأمثل في التفاعل بين الإنسان والحاسوب. وقد كانت التوصيات الخاصة بهذا النوع من الاتصالات موجودة منذ عام 1968. في ذلك الوقت ، نشر روبرت ب. أنواع مختلفة من الاستجابات التي يمكن للمستخدم الحصول عليها من جهاز كمبيوتر. أحد هذه الأنواع يسميها ميلر "استجابة للتحكم في التنشيط" - التأخير بين الضغط على مفتاح والتغذية الراجعة المرئية. حتى في عام 1968 ، كان يجب ألا يتجاوز 0.1 إلى 0.2 ثانية. نعم ، طراز RAIL ليس أول من أوصى بهذا - النصيحة موجودة منذ حوالي 50 عامًا. ومع ذلك ، يلاحظ ميللر أنه حتى هذا التأخير القصير في التعليقات قد يكون بطيئًا جدًا بالنسبة للمستخدمين المهرة. هذا يعني أنه من الناحية المثالية ، يجب أن يحصل المستخدم على إقرار بإجراءاته في غضون 100 مللي ثانية . هذا هو الدخول في نطاق واحد من أسرع الإجراءات اللاواعية التي يمكن لجسم الإنسان القيام بها - وميض العين. لهذا السبب ، عادة ما يُنظر إلى الفاصل الزمني البالغ 100 مللي ثانية على أنه فوري. تقول دافينا بريستو ، من معهد طب الأعصاب بجامعة كوليدج لندن ، "معظم الناس يرمشون حوالي 15 مرة في الدقيقة ، وتستمر طرفة عين في المتوسط ​​من 100 إلى 150 مللي ثانية" ، مضيفة أن هذا "يعني أننا نقضي 9 أيام على الأقل في السنة في الوميض. "

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

معالجة الفشل المحتمل

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

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

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

• ردا على استفسار بسيط عن المعلومات المدرجة ؛
• ردا على استفسار معقد في شكل بياني ؛
• ردًا على "النظام ، هل تفهمني؟"

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

مسلحين بعلم النفس حول كيفية التعامل مع الفشل في واجهة مستخدم متفائلة ، فلنصل أخيرًا إلى تلك 1 إلى 3٪ من الطلبات الفاشلة.

الجانب المتشائم من تصميم واجهة المستخدم المتفائل

إلى حد بعيد ، الملاحظة الأكثر شيوعًا التي أسمعها هي أن تصميم واجهة المستخدم المتفائل هو نوع من النمط الأسود - الغش ، إذا صح التعبير. وهذا يعني ، من خلال استخدامه ، أننا نكذب على مستخدمينا بشأن نتيجة تفاعلهم. من الناحية القانونية ، من المحتمل أن تدعم أي محكمة هذه النقطة. ما زلت أعتبر التقنية تنبؤًا أو أملًا. (تذكر تعريف "متفائل" هنا حيث نسمح ببعض المساحة للجزء "المأمول" منه.) يكمن الاختلاف بين "الكذب" و "التنبؤ" في كيفية تعاملك مع 1 إلى 3٪ من الطلبات الفاشلة. دعونا نلقي نظرة على كيفية تصرف زر "أعجبني" المتفائل في Twitter في وضع عدم الاتصال.

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

ولكن نظرًا لأن المستخدم غير متصل بالإنترنت ، يفشل الطلب.

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

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

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

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

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

التشاؤم الشديد

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

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

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

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

من البديهيات

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

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

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

موارد

• "وقت الاستجابة في معاملات المحادثة بين الإنسان والحاسوب" (PDF) ، روبرت ب. ميلر ، مؤتمر Fall Joint Computer Conference ، 1968
• "تقديم RAIL: نموذج للأداء يركز على المستخدم" ، بول أيرش ، بول لويس ، Smashing Magazine ، 2015
• "ضغوط الويب للجوال: تأثير سرعة الشبكة على التفاعل العاطفي وإدراك العلامة التجارية" ، تامي إيفيرتس ، مدونة Radware ، 2013
• تطبيقات التدفق في التنمية البشرية والتعليم ، Mihaly Csikszentmihalyi ، 2014
• "تفاصيل تصميم الجوّال: تجنب Spinner" ، Luke Wroblewski ، 2013
• "لماذا يهم الأداء ، الجزء 2: إدارة التصور" ، Denys Mishunov ، Smashing Magazine ، 2015