مشكلة زر الحذف: كيف تحمي المستخدمين من نقرة واحدة خاطئة في تطبيقك المبني بالذكاء الاصطناعي
اجعل الحذف آمنًا عبر أرشفة السجلات بدلاً من محوها نهائيًا، وأضف نافذة قصيرة لـ"التراجع" بعد كل عملية حذف، واحتفظ برسائل تأكيد "هل أنت متأكد؟" للإجراءات التي لا يمكن التراجع عنها فعليًا أو التي تؤثر على أشخاص آخرين — وليس لكل زر.
ما هي مشكلة زر الحذف؟
مشكلة زر الحذف بسيطة: نقرة واحدة عن طريق الخطأ على زر حذف أو مسح أو إلغاء يمكن أن تدمر بيانات شخص ما نهائيًا في تطبيق قمت ببنائه، دون تأكيد يتناسب مع خطورة الإجراء ودون أي طريقة للتراجع عنه. كل تطبيق تبنيه فيه بضعة أزرار تقوم بأمور لطيفة — حفظ، تعديل، إضافة. وعادة ما يحتوي على زر أو اثنين يقومان بأمر نهائي: حذف عميل، إلغاء طلب، مسح قائمة، إزالة صورة. هذه الأزرار النهائية هي التي ستُفسد يوم شخص ما عاجلاً أم آجلاً، وعندما تبني باستخدام أداة بناء تطبيقات بالذكاء الاصطناعي، من السهل إضافة زر الحذف دون التفكير فيما يحدث في اللحظة التي ينقر فيها أحدهم على الزر الخطأ.
الأمر المثير بشأن زر الحذف هو أنه يعمل بشكل مثالي أثناء اختبارك، لأنك في اختبارك تنقر عليه دائمًا عن قصد. الناس الحقيقيون لا يفعلون ذلك. ينقرون عليه بالخطأ على شاشة هاتف صغيرة. يضغطونه ظنًا منهم أنه يمسح مرشحًا (filter)، لا السجلات الفعلية. يسلّمون التطبيق لزميل يزيل الصف الخطأ لأن صفين بدا شكلهما متطابقًا. المشكلة ليست في الكود — زر الحذف يفعل بالضبط ما يقوله. المشكلة أن “بالضبط ما يقوله” يكون أحيانًا كارثة.
دعني أحدّثك عن اثنتين من تلك الأمسيات.
عملت مستقلة على بناء متتبّع عملاء بسيط. في إحدى الأمسيات، أثناء الترتيب، حذفت ما ظنّت أنه إدخال تجريبي قديم. لكنه كان عميلاً حقيقيًا — ثلاثة أشهر من الفواتير والملاحظات وسجل التواصل، اختفت بنقرة واحدة، دون أي طريقة لاستعادتها. وفي حادثة منفصلة، نقرت متطوعة تدير حملة توزيع طعام صغيرة على “مسح الكل” متوقعة أنه سيعيد ضبط مربع بحث. لكنه أفرغ قائمة التسجيل بأكملها في الليلة التي سبقت الحدث.
لم يرتكب أي منهما أي خطأ. التطبيق ببساطة وثق بنقرة واحدة أكثر مما ينبغي.
ما الذي يجعل زر الحذف خطيرًا إلى هذا الحد؟
يصبح زر الحذف خطيرًا عندما يتعامل التطبيق مع كل نقرة بنفس الطريقة: يمحو البيانات نهائيًا، أو يسأل “هل أنت متأكد؟” بكثرة تجعل الناس يتوقفون عن قراءته، أو لا يقدّم أي طريقة للرجوع بعد وقوع الحدث. معظم قصص الحذف العرضي تعود إلى نفس العادات الثلاث، وكلها قابلة للإصلاح.
الأولى هي “الحذف يعني الاختفاء إلى الأبد.” عندما تُزيل أداة البناء لديك سجلاً، هل تمحوه فعليًا، أم تخفيه فقط؟ افتراضيًا، الكثير من التطبيقات المبنية بالذكاء الاصطناعي تفعل الأمر الحرفي وتمحوه. النمط الأكثر أمانًا هو ما تفعله التطبيقات الكبرى بهدوء خلف الكواليس — لا تحذف، بل تؤرشف. يُوسم السجل كمُزال ويُخفى عن العرض، لكنه يبقى موجودًا لفترة في حال احتاجه أحدهم مجددًا. بالنسبة للمستخدم، يبدو الأمر وكأنه حُذف. بالنسبة لك، يمكن استرجاعه.
الثانية هي سؤال “هل أنت متأكد؟” عن كل شيء — أو عن لا شيء. إذا كان كل زر على الشاشة يُظهر رسالة تأكيد، يتوقف الناس عن قراءتها. ينقرون “نعم، نعم، نعم” بردة فعل تلقائية، ويحصل التأكيد الوحيد المهم على نفس “النعم” العمياء التي حصل عليها كل ما سبقه. المهارة ليست في إضافة تأكيدات أكثر؛ بل في ادّخارها للإجراءات التي لا يمكن التراجع عنها فعليًا أو التي تؤثر على أشخاص آخرين. يجب أن يبدو التأكيد نادرًا بما يكفي ليجعل أحدهم يتوقف ويفكر.
الثالثة هي عدم وجود أي طريقة للرجوع على الإطلاق. حتى مع وجود تأكيد، تقع الحوادث. أفضل شبكة أمان ليست تحذيرًا قبل الإجراء — بل خيار “تراجع” مباشرة بعده. رأيت هذا من قبل: تحذف بريدًا إلكترونيًا فيظهر شريط صغير يقول “تم الحذف. تراجع،” ويبقى ظاهرًا لبضع ثوانٍ. هذا النمط يلتقط الأخطاء العرضية دون إزعاج أحد، لأنه يبقى بعيدًا عن الطريق ما لم تحتجه فعلاً.
ماذا يجب أن تطلب من أداة بناء التطبيقات بالذكاء الاصطناعي؟
اطلب من أداتك أن تؤرشف بدلاً من أن تمحو، وأن تضيف نافذة “تراجع” قصيرة بعد الحذف، وأن تقتصر التأكيدات على الإجراءات التي لا يمكن التراجع عنها فعليًا أو التي تؤثر على أشخاص آخرين. لست بحاجة لمعرفة كيفية بناء أي من هذا. أنت بحاجة فقط لطلبه بلغة بسيطة. إليك ما يجب أن تقوله لأداة البناء بالذكاء الاصطناعي:
- “عندما يحذف أحدهم شيئًا، لا تمحه. ضع عليه علامة كمؤرشف وأخفه عن العرض العادي. أضف قسم ‘مؤرشف’ حيث يمكنني رؤية العناصر المُزالة واستعادتها.”
- “بعد أن يحذف أحدهم شيئًا، أظهر خيار ‘تراجع’ لمدة عشر ثوانٍ تقريبًا قبل أن يختفي فعليًا.”
- “أظهر تأكيد ‘هل أنت متأكد؟’ فقط للإجراءات التي لا يمكن التراجع عنها أو التي تؤثر على بيانات أشخاص آخرين — وليس للإجراءات اليومية.”
- “اجعل شكل أزرار الحذف و’مسح الكل’ مختلفًا عن الأزرار العادية، ولا تضعها بجانب زر الحفظ أو الإرسال مباشرة.”
النقطة الأخيرة أهم مما تبدو عليه. زر حذف أحمر يقع على بُعد عرض إبهام واحد من زر الحفظ هو حادث في انتظار أن يقع على شاشة صغيرة.
القرارات الأكثر هدوءًا
هناك بضعة أمور تختبئ خلف زر الحذف تستحق التفكير قبل الإطلاق.
الإجراءات الجماعية هي الأكثر رعبًا. مزيج “تحديد الكل ثم الحذف” يمكن أن يمحو كل شيء بحركة واحدة. إذا كان تطبيقك يحتوي على هذه الميزة، فهذا أول مكان تضيف فيه تأكيدًا حقيقيًا — ويُفضّل الاحتفاظ بالنسخ المؤرشفة تحته أيضًا.
بعض عمليات الحذف تسحب معها أشياء أخرى. إذا كان حذف عميل يحذف أيضًا كل طلباته، فهذا عادة ما يفاجئ الشخص الذي يقوم به. اسأل أداة البناء لديك عمّا يختفي أيضًا عند إزالة سجل، وما إذا كان هذا فعلاً ما تريده.
قرّر من يُسمح له بالحذف أصلاً. إذا كان أكثر من شخص يستخدم تطبيقك، فإن “الجميع يمكنهم حذف أي شيء” نادرًا ما تكون الإجابة الصحيحة. السماح لأشخاص معينين فقط بإزالة السجلات غالبًا ما يكون أبسط حماية على الإطلاق.
كيف تختبر ما إذا كان زر الحذف لديك آمنًا؟
اختبره بفحص مدته ثلاثون ثانية: حاول حذف شيء ما في تطبيقك، ثم حاول استعادته — إذا لم تستطع التراجع أو إيجاده مؤرشفًا، فلن يستطيع مستخدموك ذلك أيضًا. افتح تطبيقك على هاتفك وحاول حذف شيء ما — ثم حاول استعادته. هل استطعت؟ سلّم التطبيق لصديق دون أن تشرح له شيئًا، وراقب إلى أين يتجه إبهامه. هل تقع الأزرار الخطيرة بجانب الأزرار اليومية مباشرة؟ هل يختفي شيء مهم دون فرصة للتراجع؟
لست مضطرًا لجعل كل إجراء قابلاً للتراجع. عليك فقط أن تجد الزر الواحد في تطبيقك الذي، إذا نُقر عليه بالخطأ، سيُفسد يوم شخص ما — وتجعل ذلك الزر آمنًا أولاً. ابدأ من هناك، ومعظم الأمسيات المؤلمة لن تحدث أبدًا.