ما الحدث الذي يؤدي إلى تفعيل التحقق من صحة حقل نموذج Javascript وتنسيقه؟

StackOverflow https://stackoverflow.com/questions/116736

سؤال

اسمحوا لي أولاً أن أقول ، نحن نتحقق من صحة كل حقل على جانب الخادم ، لذلك هذا سؤال حول قابلية الاستخدام من جانب العميل.

ما هي الحكمة التقليدية على بالضبط عندما للتحقق من صحة وتنسيق حقول إدخال نموذج HTML باستخدام جافا سكريبت؟

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

يبدو أننا نستطيع

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

لقد رأيت ذلك طوال هذه الطرق ، لكن لا يمكنني العثور على معلومات حول أفضل (أو حتى مقبول عمومًا) من منظور قابلية الاستخدام ، والأهم من ذلك ، لماذا.

[يحرر:بعض التوضيح]

نحن لا ننفذ مطلقًا أي معايير للتنسيق.عندما أقول التنسيق، أعني أننا سنستخدم جافا سكريبت لإعادة كتابة الأشياء حتى تبدو جميلة.إذا كتب المستخدم 1234567890، فسنغيره إلى (123) 456-7890.لا توجد "قواعد التنسيق" التي يمكن أن تفشل.

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

أعتقد أنني يجب أن أعيد صياغة السؤال على النحو التالي: "ما هي الحكمة التقليدية بشأن متى يتم التحقق من الصحة بالضبط ومتى يتم التنسيق بالضبط...؟

معلومات جيدة في الإجابات حتى الآن!

يحرر:إنني أقبل إجابتي أدناه على أمل أن يجد الآخرون الرابط مفيدًا كما فعلت.

هل كانت مفيدة؟

المحلول 4

إلى حد بعيد أفضل إجابة حتى الآن لم تكن إجابة بل تعليقًا (انظر أعلاه). أقوم بإضافتها كإجابة في حالة فاتها أي شخص في التعليق.

راجع المقالة التالية على قائمة وبصرف النظر.

التحقق من الصحة المضمن في نماذج الويب بواسطة Luke Wroblewski

نصائح أخرى

التحقق من صحته وتنسيقه عند خروج المستخدم من الحقل.

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

التحقق من صحة وتنسيق كل حرف تم إدخاله.

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

اعتراض ضغطات المفاتيح ومنع المستخدم من إدخال أحرف خاطئة.

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

لذلك بالنسبة لي المبادئ العامة هي:

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

كنت سأصف الخيارات المختلفة ولكن قد يكون من المفيد فقط استخدام إطار عمل js الحالي للتعامل مع أقنعة الإدخال. إليك مجموعة جيدة من الخيارات المختلفة

ينص bmb على أنهم يقبلون أي تنسيق ويغيرونه إلى التنسيق المطلوب (xxx) nnn-xxxx.هذا جيد جدا.السؤال هو توقيت أ) تغيير التنسيق، و ب) التحقق من الصحة.

أ) يجب أن يتم تغيير التنسيق عند خروج المستخدم من الحقل.عاجلاً أمر مزعج ثم يبطل لاحقًا غرض عرض التغيير على الإطلاق.

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

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

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

بهذه الطريقة، عند الكتابة ستلاحظ أن رقم هاتفك 1-800-HELLOWORLD لا يظهر بشكل صحيح وستدرك أن الحقل يقبل الأرقام فقط (والتي يمكنك أيضًا تمييزها باستخدام نوع ما من حقول المعلومات بجانب حقل الإدخال).

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

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

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

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

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

الاستثناء الوحيد الذي يمكنني التفكير فيه هو مواقف "هل هذه القيمة متاحة" (مثل إنشاء اسم مستخدم فريد) - في هذه الحالة تكون التعليقات الفورية مريحة حقًا.

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

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

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

في حالة رقم هاتفك، اسمح لهم بإدخاله كيفما يريدون، واحذف أي شيء لا يعجبك، وحاول تجميعه مرة أخرى بالتنسيق الذي تريده ( (124) 567-8901 ) وإظهار خطأ إذا كنت لا أستطيع.

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

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

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

إذا كانت لديك مساحة الشاشة العقارية، فيمكنك فقط وضع نص مثل "صالح" أو "يجب أن يكون بالتنسيق XXX-YYY-XXXX".

ضع في اعتبارك أنه عند قيامك بالتحقق من صحة كل ضغطة مفتاح، فإنك تحتاج أيضًا إلى التقاط النص الملصق.

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

للحصول على أفضل ممارسات سهولة الاستخدام، أقترح القراءة كيفية تصميم الشكل المثالي (أكثر دقة السياق والمساعدة) و أشكال جميلة.

للحصول على إطار عمل التحقق من صحة النموذج، تحقق من fValidator و iMask التحرير والسرد، فهي متكاملة وبالتالي تعمل معًا بشكل مثالي.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top