वास्तविक समय प्रपत्र सत्यापन के साथ अपने वेब आगंतुकों को प्रभावित करें

ऑनलाइन फार्म

वेब एप्लिकेशन के उपयोगकर्ता के रूप में आपको आमतौर पर पहला प्रभाव तब होता है जब आप एक वेब फॉर्म भरते हैं। मैं वहां मौजूद वेब फ़ॉर्मों की संख्या पर चकित हूं जिनका सत्यापन शून्य है या जो आपको यह बताने से पहले कि आपको कौन सी समस्याएं हो सकती हैं, अपनी फॉर्म सामग्री जमा करने के लिए प्रतीक्षा करें।

मेरे अंगूठे का नियम यह है कि जो कुछ भी मान्य नहीं है वह समर्थित है। फॉर्म जमा करने से पहले जो कुछ भी मान्य किया जा सकता है वह होना चाहिए। अजाक्स के आगमन के साथ, आप जमा करने से पहले अपने डेटाबेस के विरुद्ध डेटा को मान्य भी कर सकते हैं। आलसी मार्ग न चुनें - उपयोगकर्ता मदद की सराहना करते हैं!

यहाँ कुछ उदाहरण हैं:

  1. ईमेल पते - मुझे उन फ़ॉर्मों से कोई ऐतराज नहीं है जो आपको अपना ईमेल पता दो बार भरने के लिए मजबूर करते हैं, लेकिन तथ्य यह है कि वे आपको यह नहीं बताते हैं कि वे मेल खाते हैं या उचित रूप से निर्मित हैं या नहीं, यह अक्षम्य है।
  2. पासवर्ड - यदि आप मुझसे दो बार पासवर्ड टाइप करने जा रहे हैं, तो कृपया पुष्टि करें कि फ़ॉर्म पोस्ट करने से पहले मान समान हैं।
  3. पासवर्ड क्षमता - यदि आपको एक निश्चित पासवर्ड शक्ति (अल्फ़ान्यूमेरिक वर्णों या मामलों का संयोजन) की आवश्यकता होती है, तो जब मैं अपना पासवर्ड टाइप कर रहा हूँ, तो मेरे लिए कुछ प्रतिक्रिया दें। मुझे यह बताने से पहले कि यह विफल हो गया है, मेरे सबमिट करने की प्रतीक्षा न करें।
  4. तिथियाँ - यदि आप दिनांक को पूर्वाह्न/दिन/वर्ष प्रारूप में चाहते हैं, तो मुझे उन मानों को टाइप करके और उन्हें उचित रूप से स्वरूपित करके एक ही फ़ील्ड में जानकारी दर्ज करने की अनुमति दें। यदि आप अग्रणी शून्य चाहते हैं, तो उन्हें बाद में डालें। एक प्रारूप प्रदर्शित करना और दूसरे को अपने डेटाबेस में सहेजना ठीक है।
  5. आज की तारीख - मेरे लिए इसे भरें! जब आप पहले से ही जानते हैं तो आप मुझे तारीख भरने के लिए क्यों कह रहे हैं ?!
  6. दिनांक स्वरूप - यदि आपके पास एक अंतरराष्ट्रीय आवेदन है, तो आप अपने आवेदन के अंतर्राष्ट्रीयकरण के आधार पर दिनांक प्रारूप को डिफ़ॉल्ट कर सकते हैं। बेशक, उपयोगकर्ताओं के लिए उस विकल्प को ओवरराइड करने और अपना खुद का चयन करने का विकल्प होना अच्छा है।
  7. सामाजिक सुरक्षा नंबर - कुछ जावास्क्रिप्ट जोड़ना बहुत आसान है जो स्वचालित रूप से फ़ील्ड से फ़ील्ड में कूदता है या प्रोग्रामेटिक रूप से मानों के बीच डैश डालता है।
  8. टेलीफ़ोन नंबर - अंतर्राष्ट्रीयकरण को ध्यान में रखते हुए, इस प्रकार के फ़ील्ड को इंटरफ़ेस में टेलीफ़ोन नंबर को स्वरूपित करके भी सरल बनाया जा सकता है, लेकिन इसे किसी अन्य प्रारूप में सहेजना जो आपके बैक-एंड के लिए कुशल हो। अपने उपयोगकर्ताओं को कोष्ठक, रिक्त स्थान और डैश में टाइप न करें।
  9. अधिकतम पाठ लंबाई - यदि आप अपने डेटाबेस में संग्रहीत वर्णों की संख्या को सीमित करते हैं, तो मुझे इतने वर्ण टाइप न करने दें! इसे कठिन सत्यापन की भी आवश्यकता नहीं है... यह सिर्फ टेक्स्टबॉक्स पर एक सेटिंग है।
  10. न्यूनतम पाठ लंबाई - यदि आपको न्यूनतम पाठ लंबाई की आवश्यकता है, तो जब तक मेरे पास पर्याप्त वर्ण न हो, तब तक अलार्म बजाएं।

यहां से पासवर्ड शक्ति फ़ंक्शन का एक उदाहरण दिया गया है गीक बुद्धि:

पासवर्ड टाइप करें:

अद्यतन: 10/26/2007 - मैंने एक जावास्क्रिप्ट संसाधन के साथ एक स्वच्छ संसाधन पाया जो डाउनलोड के लिए उपलब्ध है फ़ॉर्म सत्यापन, जिसे LiveValidation कहा जाता है.

16 टिप्पणियाँ

  1. 1

    मैं मानता हूं कि वे फॉर्म के लिए महान विशेषताएं हैं, लेकिन यह कहना कि यह "अक्षम्य" है कि फ्रंट एंड जावास्क्रिप्ट सत्यापन नहीं करना एक व्यक्तिगत राय है। मुझे जावास्क्रिप्ट में काम करना अच्छा लगता है, और आपने जिन चीजों के बारे में बात की है, उनमें से कुछ को करने के लिए कुछ सुंदर साफ-सुथरे एडिटमास्क लिखे हैं, लेकिन उनमें से बहुत से तुच्छ से बहुत दूर हैं, और कई जावास्क्रिप्ट फॉर्म सत्यापन पैकेजों में कई बड़े छेद हैं। हर कोई अपने बैक एंड सत्यापन को अधिक जटिल फ्रंट एंड जावास्क्रिप्ट सत्यापन के साथ (अधिक बार नहीं) डुप्लिकेट करने में समय का निवेश नहीं करेगा।

    अच्छे अंक, लेकिन निश्चित रूप से मेरी राय में हर ऑनलाइन फॉर्म "जरूरतों" के लिए नहीं।

  2. 2

    पासवर्ड चेकर सापेक्ष रूप से टूट गया है। कोई भी पासवर्ड काफी अच्छा है अगर वह लंबा है।

    उदाहरण:

    क्या यह वास्तव में एक औसत दर्जे का पासवर्ड है?

    f46dffe6ff4ffgdfgfjfgyu656hfdt74tyhdtu5674yfgh6uhhye45herdhrt64684hythdfth54y54348fgdcvzse8cn984v3p4m6vq98476m3wuw89ewfucsd8fg67s4v8tw76u340m6tver7nt+s89346vs+0em9u+s+09hrtuhss586ysvne4896vb4865tbv089rt++

  3. 4

    मेरे लिए सबसे अच्छा फॉर्म सत्यापन तब होता है जब आप उपयोगकर्ता को एक ग्राहक पक्ष सत्यापन का आभास देते हैं जबकि यह AJAX / सर्वर साइड सत्यापन है।
    आपको बस अपने फॉर्म एलिमेंट्स को कुछ ईवेंट हैंडलिंग (की-अप, ब्लर, क्लिक, वगैरह ...) से जोड़ना होगा, जो AJAX के माध्यम से पूरे फॉर्म को सर्वर पर पोस्ट करता है, एक "चेक" फ़ंक्शन को इनवॉइस करता है जो संबंधित त्रुटि संदेशों को वापस करता है (यह पासवर्ड भी है सरल, वह तिथि गलत प्रारूप में है, आदि ...)
    जब उपयोगकर्ता अंततः सबमिट बटन पर क्लिक करके फ़ॉर्म को पोस्ट करता है, तब भी आप डेटाबेस या किसी अन्य प्रक्रिया में डेटा डालने से पहले अंतिम बार फॉर्म को सत्यापित करने के लिए "चेक" सर्वर साइड फ़ंक्शन का उपयोग कर सकते हैं।
    इस तरह, उपयोगकर्ता onthego सत्यापन से खुश हैं और डेवलपर केवल सर्वर विकास सत्यापन से खुश हैं।

    • 5
      • 6

        इतनी जल्दी नहीं डौग - मैं आपके मूल आधार से सहमत हूं कि ये सहायक विशेषताएं, जैसे कि मक्खी पर एक एसएसएन को प्रारूपित करना तुच्छ है। और इसका आलसी सिर्फ एक संदेश पोस्ट करता है कि इसका गलत, जब आप इसे प्रारूप में अनुमान लगाए बिना इसे ठीक कर सकते हैं।

        हालांकि, मैं AJAX के साथ संयोजन में सर्वर साइड लॉजिक का उपयोग करने के बारे में निकोलस से भी सहमत हूं।

  4. 7

    आपका शीर्षक कहता है "अपने मित्रों को प्रभावित करें ..." लेकिन आप इस 2 मिनट के साथ मुझे प्रभावित करने में विफल रहे, पोस्ट में फोन किया।

    अपने शीर्षक को फिर से लिखें (बहुत भ्रामक है, यह सोचता है कि उदाहरण और प्रथाओं पर चर्चा की जा रही है)।

    यदि लोग पहले से अपने रूपों में ऐसा नहीं कर रहे हैं, तो वे सिर्फ सीख रहे हैं या सत्यापन का उपयोग करने के लिए फॉर्म पर्याप्त महत्वपूर्ण नहीं है।

    वास्तविक वेब प्रोग्रामर यह पहले से ही जानते हैं और करते हैं।

    • 8

      जे,

      उसके लिए माफ़ करना! मेरा कहना निश्चित रूप से डेवलपर प्रतिक्रिया प्रदान करने का नहीं था - मैं वास्तव में एक उत्पाद प्रबंधक के दृष्टिकोण से आ रहा था। मैं आपसे सहमत हूं - लेकिन यह दिलचस्प है कि कुछ अन्य डेवलपर्स नहीं करते हैं! मुझे लगता है कि यह दुर्भाग्यपूर्ण है।

      समय लेने के लिए शुक्रिया!
      डॉग

  5. 9

    मैं पूरी तरह से मान्यता के बारे में सहमत हूं कि किसी भी आवेदन का एक आवश्यक घटक है। एक टीम की अगुवाई के रूप में, मैं आमतौर पर खुद को कोड को वापस भेजने के लिए "समाप्त" होने के कारण गुम सत्यापन या पाठ इनपुट लंबाई को प्रतिबंधित करने जैसे कारणों से पाता हूं।

    अधिकांश चीजों के लिए जिन पर मैं काम करता हूं, मुझे लगता है कि सामान्य परिस्थितियों में कुछ काम करने में लगभग 50% समय लगता है और अगर उपयोगकर्ता सिस्टम का उपयोग करते हैं तो मैं जिस तरह से चाहता हूं। अन्य 50% विकास का समय उनके इनपुट की जांच करने से आता है, जिससे डेटा अखंडता बनी रहती है और फॉर्म फ़ील्ड बनाने से दुर्भावनापूर्ण डेटा को दर्ज नहीं होने दिया जाता है।

    मैंने एक पोस्ट लिखी कि मैं अपने हावा स्विंग ऐप्स में InputVerifiers कैसे उपयोग करता हूं, और दिखाता हूं कि मैं एक ईमेल टेक्स्ट फ़ील्ड कैसे सत्यापित करता हूं। मेरे द्वारा उपयोग की जाने वाली नियमित अभिव्यक्ति फोन नंबर, ज़िपकोड, एसएसएन आदि को मान्य करने के लिए आसानी से परिवर्तनीय है।

    मेरा ब्लॉग पोस्ट है http://timarcher.com/?q=node/36

    अच्छा राइटअप डग!

  6. 10

    मैं सहमत हूँ। पासवर्ड वास्तव में महत्वपूर्ण हैं और इसे गंभीरता से लिया जाना चाहिए। मुझे लगता है कि पासवर्ड को दो बार टाइप करना लगभग सभी रूपों के लिए सामान्य है, लेकिन दो पासवर्डों की वैधता नहीं दिखाने से पता चलता है कि इसे गंभीरता से नहीं माना जा रहा है।

  7. 11

    मैं मानता हूं कि क्लाइंट सत्यापन एक बहुत उपयोगकर्ता के अनुकूल सुविधा हो सकती है। हालांकि, यह सुनिश्चित करना अधिक महत्वपूर्ण है कि सत्यापन स्वयं वास्तव में समझ में आता है।

    आपने एक शानदार उदाहरण दिया कि सत्यापन उपयोगकर्ताओं को कैसे भ्रमित कर सकता है और इससे भी बदतर, उन्हें हमारी साइट से दूर कर सकता है:

    Geek Wisdom का पासवर्ड ताकत विचारकों से मान्यता है tZhKwnUmIss एक कमजोर पासवर्ड होने के लिए। न केवल यह पूरी तरह से मजबूत पासवर्ड है, बल्कि यह उपयोगकर्ताओं को भी अलग कर देगा क्योंकि यह उन्हें गलत धारणा देता है कि इस पासवर्ड का उपयोग करके आपकी साइट पर लॉग इन करना किसी तरह असुरक्षित होगा।

    केवल उपयोगकर्ताओं को संकेत देने के लिए यह बेहतर (और आसान) होगा कि एक अच्छा पासवर्ड कम से कम छह वर्ण लंबा हो और उसमें संख्या और अक्षर दोनों हों।

    अन्य संदेहास्पद मान्यताओं में उपयोगकर्ता नाम शामिल हैं जिन्हें एक निश्चित न्यूनतम लंबाई की आवश्यकता होती है या इसमें रिक्त स्थान नहीं हो सकते हैं। उपयोगकर्ता नाम के साथ क्या गलत है X, क़ानून में काल्पनिक व्यक्ति, या और भी # *! §? मैं वह संभाल सकता हूँ।

  8. 12

    मैं आपसे सहमत हुँ। कुछ रूप ठीक दिखते हैं, लेकिन यह अच्छी मान्यता प्रदान नहीं करता है। व्यक्तिगत जानकारी दी जाती है और हार्ड कॉपी में किसी भी व्यावसायिक रूप की तरह इसे गंभीरता से लेना उचित है।

  9. 13
  10. 14
  11. 15

    मुझे यह देखकर थोड़ा आश्चर्य होता है कि आप रियल टाइम फॉर्म वेलिडेशन के लिए अच्छाई के बारे में पोस्ट करते हैं और फिर भी, पोस्ट के नीचे आपका टिप्पणी फॉर्म इनमें से कोई नहीं प्रदान करता है ...

    मुझे पता है कि आप इंटरनेट पर अपने विचारों को ब्लॉग करने के लिए वर्डप्रेस का उपयोग कर रहे हैं, लेकिन शायद यह सुनिश्चित करना कि आप जो भी उपदेश देते हैं, वह ऐसा बुरा विचार नहीं है। 🙂

    अच्छी पोस्ट, वैसे, भले ही मैं जरूरी नहीं कि आप सभी ने लिखा हो।

    • 16

      दोह! तुमने मेरा भंडाफोड़ किया, अमांडा! मेरी इच्छा है कि मेरे पास बेहतर फॉर्म सत्यापन करने और इसे वर्डप्रेस में एकीकृत करने का समय हो। मुझे विशेष रूप से पसंद है एडोब स्प्री सत्यापन ढांचा और किसी को दो को एकीकृत देखना पसंद करेंगे!

      धन्यवाद! (और मैं हमेशा इस बात की सराहना करता हूं कि किसी भी विषय पर कई राय हैं)।
      डॉग

तुम्हें क्या लगता है?

यह साइट स्पैम को कम करने के लिए अकिस्मेट का उपयोग करती है। जानें कि आपका डेटा कैसे संसाधित किया जाता है.