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