16 दिस॰ 2025·8 मिनट पढ़ने में

SwiftUI फॉर्म मान्यकरण जो स्वदेशी लगे: फोकस और त्रुटियाँ

SwiftUI फॉर्म मान्यकरण जो स्वदेशी लगे: फोकस संभालना, सही समय पर इनलाइन त्रुटियाँ दिखाना, और सर्वर संदेशों को साफ़ तरीके से दिखाना बिना उपयोगकर्ता को परेशान किए।

SwiftUI में "स्वदेशी-सा" मान्यकरण कैसा लगता है

एक स्वदेशी-सा iOS फॉर्म शांत होता है। यह उपयोगकर्ता के टाइप करते समय उससे बहस नहीं करता। यह उस समय स्पष्ट फीडबैक देता है जब ज़रूरी होता है, और आपको यह ढूँढने के लिए परेशान नहीं करता कि क्या गलत हुआ।

मुख्य अपेक्षा भविष्यवाणी योग्य होना है। वही क्रियाएँ हर बार एक ही तरह की प्रतिक्रिया देनी चाहिए। अगर कोई फील्ड अवैध है, तो फॉर्म उसे लगातार एक ही जगह, एक ही लहजे में और एक स्पष्ट अगले कदम के साथ दिखाए।

अधिकतर फ़ॉर्म को तीन तरह के नियमों की ज़रूरत होती है:

फ़ील्ड नियम: क्या यह एकल मान वैध है (खाली, फ़ॉर्मेट, लंबाई)?
क्रॉस-फ़ील्ड नियम: क्या मान एक-दूसरे पर निर्भर हैं या मेल खाते हैं (Password और Confirm Password)?
सर्वर नियम: क्या बैकएंड इसे स्वीकार करता है (email पहले से उपयोग में है, invite आवश्यक है)?

समय सबसे ज़्यादा मायने रखता है—लिखावट से ज़्यादा। अच्छा मान्यकरण किसी अर्थपूर्ण पल का इंतज़ार करता है, फिर एक बार स्पष्ट रूप से बोलता है। एक व्यावहारिक लय कुछ इस तरह दिखती है:

उपयोगकर्ता टाइप कर रहा है तो चुप रहें, खासकर फ़ॉर्मेट नियमों के लिए।
फील्ड छोड़ने के बाद या उपयोगकर्ता ने Submit दबाया हो तो फ़ीडबैक दिखाएँ।
त्रुटियों को तब तक दिखाएँ जब तक वे ठीक न हों, फिर तुरंत हटा दें।

जब उपयोगकर्ता अभी भी उत्तर बना रहा हो—जैसे ईमेल या पासवर्ड टाइप करते समय—तो मान्यकरण मौन होना चाहिए। पहले कैरेक्टर पर त्रुटि दिखाना चिढ़ाने जैसा लगता है, भले ही तकनीकी रूप से सही हो।

मान्यकरण तब दिखाई देनी चाहिए जब उपयोगकर्ता संकेत दे कि वे पूरा कर चुके हैं: फोकस हट गया, या उन्होंने सबमिट करने की कोशिश की। यही वह क्षण है जब वे मार्गदर्शन चाहते हैं, और आप उनकी मदद कर सकते हैं कि सही फ़ील्ड पर ध्यान दें।

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

एक साधारण मान्यकरण स्टेट मॉडल सेट करें

एक स्वदेशी-सा फॉर्म शुरू से ही साफ़ अलगाव के साथ होना चाहिए: उपयोगकर्ता ने जो टेक्स्ट टाइप किया वह ऐप की राय नहीं है। अगर आप इन्हें मिलाते हैं, तो या तो आप त्रुटियाँ बहुत जल्दी दिखाएँगे या UI रिफ्रेश पर सर्वर संदेश खो देंगे।

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

struct FieldState {
    var value: String = ""
    var touched: Bool = false
    var localError: String? = nil
    var serverError: String? = nil

    // One source of truth for what the UI displays
    func displayedError(submitted: Bool) -> String? {
        guard touched || submitted else { return nil }
        return localError ?? serverError
    }
}

struct FormState {
    var submitted: Bool = false
    var email = FieldState()
    var password = FieldState()
}

कुछ छोटे नियम इसको भविष्यवाणी योग्य रखते हैं:

लोकल और सर्वर त्रुटियों को अलग रखें। लोकल नियम (जैसे “required” या “invalid email”) सर्वर संदेश जैसे “email already taken” को ओवरराइट न करें।
जब उपयोगकर्ता उस फ़ील्ड को फिर से बदलें तो serverError को साफ करें, ताकि वे पुराने संदेश को न देखें।
touched = true तभी सेट करें जब उपयोगकर्ता फ़ील्ड छोड़ दे (या जब आप तय करें कि उन्होंने इंटरैक्ट करने की कोशिश की), पहले कैरेक्टर पर नहीं।

इससे आपका view value से स्वतंत्र रूप से बाइंड कर सकता है। मान्यकरण localError अपडेट करे, और आपकी API परत serverError सेट करे, बिना आपस में टकराए।

फोकस हैंडलिंग जो मार्गदर्शित करे, न कि डाँटे

अच्छा SwiftUI मान्यकरण सिस्टम कीबोर्ड की तरह महसूस होना चाहिए जो उपयोगकर्ता को कार्य पूरा करने में मदद कर रहा है, न कि ऐप उसे डाँट रहा हो। फोकस इसका बड़ा हिस्सा है।

एक साधारण पैटर्न यह है कि फोकस को @FocusState का एकल स्रोत बनाएँ। अपने फील्ड्स के लिए एक enum परिभाषित करें, प्रत्येक फील्ड को उससे बाइंड करें, और जब उपयोगकर्ता कीबोर्ड बटन दबाए तो आगे बढ़ाएँ।

enum Field: Hashable { case email, password, confirm }

@FocusState private var focused: Field?

TextField("Email", text: $email)
  .textContentType(.emailAddress)
  .keyboardType(.emailAddress)
  .textInputAutocapitalization(.never)
  .submitLabel(.next)
  .focused($focused, equals: .email)
  .onSubmit { focused = .password }

SecureField("Password", text: $password)
  .submitLabel(.next)
  .focused($focused, equals: .password)
  .onSubmit { focused = .confirm }

जो इसे स्वदेशी जैसा बनाता है वह संयम है। केवल स्पष्ट उपयोगकर्ता क्रियाओं पर ही फोकस मूव करें: Next, Done, या प्राथमिक बटन टैप करना। सबमिट पर, पहली अवैध फ़ील्ड पर फोकस रखें (और ज़रूरत हो तो उसे स्क्रॉल करें)। टाइप करते समय फोकस न छीनें, भले ही मान अभी अवैध हो। कीबोर्ड लेबल के साथ भी संगति रखें: मध्यवर्ती फ़ील्ड्स के लिए Next, आख़िरी फ़ील्ड के लिए Done।

एक आम उदाहरण Sign Up है। उपयोगकर्ता Create Account टैप करता है। आप एक बार validate करते हैं, त्रुटियाँ दिखाते हैं, फिर पहली असफल फ़ील्ड (अक्सर Email) पर फोकस सेट करते हैं। अगर वे Password फ़ील्ड में हैं और अभी टाइप कर रहे हैं, तो उन्हें बीच में Email पर वापस मत कूदाइए। यह छोटा सा विवरण अक्सर "पोलीश्ड iOS फॉर्म" और "परेशान करने वाला फॉर्म" का फर्क तय करता है।

सही समय पर दिखने वाली इनलाइन त्रुटियाँ

इनलाइन त्रुटियाँ एक शांत संकेत की तरह होनी चाहिए, डाँट की तरह नहीं। "स्वदेशी" और "निराश" के बीच सबसे बड़ा अंतर यह है कि आप संदेश कब दिखाते हैं।

समय निर्धारण के नियम

अगर कोई त्रुटि किसी के टाइप करते ही दिखाई दे तो वह बाधा डालता है। बेहतर नियम है: उपयोगकर्ता को फ़ील्ड पूरा करने का एक न्यायप्रिय मौका दें।

इन अच्छे क्षणों पर इनलाइन त्रुटि दिखाएँ:

जब फ़ील्ड का फोकस हटे
जब उपयोगकर्ता Submit टैप करे
टाइप करते समय थोड़े विराम के बाद (केवल स्पष्ट जांचों के लिए, जैसे ईमेल फ़ॉर्मेट)

एक भरोसेमंद तरीका है कि संदेश केवल तब दिखाएँ जब फ़ील्ड touched हो या सबमिट का प्रयास हुआ हो। एक ताज़ा फॉर्म शांत रहता है, पर उपयोगकर्ता को जब वे इंटरैक्ट करें स्पष्ट मार्गदर्शन मिल जाता है।

लेआउट और स्टाइल

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

त्रुटि टेक्स्ट को छोटा और विशिष्ट रखें, और हर संदेश में एक कार्रवाई बताएं। "Password must be at least 8 characters" क्रियाशील है। "Invalid input" नहीं।

स्टाइलिंग के लिए सूक्ष्म और सुसंगत लक्ष्य रखें। फील्ड के नीचे एक छोटा फ़ॉन्ट (जैसे footnote), एक सुसंगत त्रुटि रंग, और फील्ड पर हल्का हाइलाइट आमतौर पर भारी बैकग्राउंड से बेहतर दिखता है। मान्य होते ही संदेश साफ़ कर दें।

एक यथार्थवादी उदाहरण: साइनअप फॉर्म पर, उपयोगकर्ता अभी भी name@ टाइप कर रहा हो तो "Email is invalid" न दिखाएँ। फ़ील्ड छोड़ने के बाद या छोटा विराम लेने पर दिखाएँ, और जैसे ही पता वैध हो संदेश हटा दें।

लोकल मान्यकरण फ्लो: टाइप करना, फ़ील्ड छोड़ना, सबमिट करना

सर्वर त्रुटियों को साफ़ हैंडल करें

सर्वर-साइड त्रुटियों (जैसे email taken) को यूज़र इनपुट मिटाए बिना या UI तोड़े बिना टेस्ट करें।

प्रोटोटाइप करें

एक अच्छा लोकल फ्लो में तीन गति होती हैं: टाइप करते समय हल्के संकेत, फ़ील्ड छोड़ने पर कड़े चेक, और सबमिट पर पूर्ण नियम। इस लय से मान्यकरण स्वदेशी लगता है।

जब उपयोगकर्ता टाइप कर रहे होते हैं तो मान्यकरण हल्का और शांत रखें। सोचें "यह स्पष्ट रूप से असंभव है?" न कि "यह परफेक्ट है?" ईमेल फ़ील्ड के लिए आप केवल यह चेक कर सकते हैं कि उसमें @ है और स्पेस नहीं हैं। पासवर्ड के लिए, आप टाइप शुरू होते ही एक छोटा हिल्पर जैसे "8+ characters" दिखा सकते हैं, पर पहले केस पर लाल त्रुटि दिखाने से बचें।

जब उपयोगकर्ता फ़ील्ड छोड़ता है, तो कड़े एक-फ़ील्ड नियम चलाएँ और जरूरत हो तो इनलाइन त्रुटियाँ दिखाएँ। यहीं "Required" और "Invalid format" का स्थान है। यह व्हाइटस्पेस ट्रिम करने और इनपुट सामान्य करने का अच्छा समय भी है (जैसे ईमेल को लोअरकेस करना) ताकि उपयोगकर्ता देख सके कि क्या सबमिट होगा।

सबमिट पर, सब कुछ फिर से वैलिडेट करें, जिसमें क्रॉस-फ़ील्ड नियम भी शामिल हों जो पहले तय नहीं किए जा सकते। क्लासिक उदाहरण है Password और Confirm Password का मेल न खाना। यदि यह फेल हो, तो फोकस उस फ़ील्ड पर ले जाएँ जिसे ठीक करने की ज़रूरत है और उसके पास एक स्पष्ट संदेश दिखाएँ।

सबमिट बटन का उपयोग सोच-समझकर करें। उपयोगकर्ता फॉर्म भरते समय बटन सक्षम रखें। केवल तब असक्षम करें जब टैप करना कोई प्रभाव न डाले (उदाहरण के लिए, पहले से ही सबमिट हो रहा हो)। अगर आप इसे अमान्य इनपुट पर असक्षम करते हैं, तो पास के स्थान पर बताएं क्या ठीक करना है।

सबमिशन के दौरान स्पष्ट लोडिंग स्टेट दिखाएँ। बटन लेबल को ProgressView के साथ बदल दें, डबल टैप रोकें, और फॉर्म दृश्यमान रखें ताकि उपयोगकर्ता समझें क्या हो रहा है। यदि अनुरोध एक सेकंड से अधिक लेता है तो "Creating account..." जैसा छोटा लेबल चिंता घटाता है बिना शोर बढ़ाए।

उपयोगकर्ता को निराश किए बिना सर्वर-साइड मान्यकरण

सर्वर-साइड चेक अंतिम सत्य होते हैं, भले ही आपके लोकल चेक मजबूत हों। पासवर्ड आपके नियम पास कर सकता है पर सर्वर कह सकता है यह बहुत आम है, या ईमेल पहले से लिया हुआ हो सकता है।

सबसे बड़ा UX जीत यह है कि "आपका इनपुट स्वीकार्य नहीं है" को "हम सर्वर से जुड़ नहीं पाए" से अलग रखना। अगर अनुरोध टाइमआउट हो या उपयोगकर्ता ऑफ़लाइन हो, तो फ़ील्ड को अमान्य मत मानिए। एक शांत बैनर या अलर्ट दिखाएँ जैसे "कनेक्ट नहीं कर सके। फिर से कोशिश करें।" और फॉर्म को वैसा ही रखें जैसा था।

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

सरल पैटर्न यह है कि संरचित एरर रिस्पॉन्स को दो बाल्टी में पार्स करें: फील्ड एरर्स और फॉर्म-लेवल एरर्स। फिर UI स्टेट अपडेट करें बिना टेक्स्ट बाइंडिंग बदले।

struct ServerValidation: Decodable {
  var fieldErrors: [String: String]
  var formError: String?
}
// Map keys like "email" or "password" to your local field IDs.

क्या सामान्यतः स्वदेशी लगता है:

फील्ड संदेश इनलाइन रखें, फ़ील्ड के नीचे, जब सर्वर की वाक्यविन्यास स्पष्ट हो तब सर्वर की वर्डिंग का उपयोग करें।
सबमिट के बाद ही पहली त्रुटिपूर्ण फ़ील्ड पर फोकस रखें, टाइप के बीच में नहीं।
अगर सर्वर कई समस्याएँ लौटाए, तो प्रति फ़ील्ड पहला संदेश दिखाएँ ताकि पठनीय रहे।
अगर आपके पास फील्ड विवरण हैं, तो "Something went wrong." पर लौटें नहीं।

उदाहरण: उपयोगकर्ता साइनअप सबमिट करता है और सर्वर लौटाता है "email already in use." ईमेल वही रखें, संदेश Email के नीचे दिखाएँ, और उस फ़ील्ड पर फोकस रखें। अगर सर्वर डाउन है, तो एक सिंगल रीट라이 संदेश दिखाएँ और सभी फ़ील्ड अछुए रखें।

सर्वर संदेश सही जगह पर कैसे दिखाएँ

ऐप और बैकएंड जनरेट करें

PostgreSQL में users और credentials मॉडल करें, फिर ऐप और बैकएंड एक साथ जनरेट करें।

प्रोजेक्ट शुरू करें

जब सर्वर त्रुटियाँ एक यादृच्छिक बैनर में दिखती हैं तो वे "अन्यायपूर्ण" लगती हैं। हर संदेश को उस फ़ील्ड के जितना पास हो सके उतना पास रखें जिसने उसे जन्म दिया। सिर्फ़ तभी जनरल संदेश रखें जब आप सचमुच किसी एक इनपुट से जोड़ न पाएं।

शुरूआत सर्वर के एरर पेलोड को अपने SwiftUI फील्ड आइडेंटिफ़ायर्स में बदलकर करें। बैकएंड email, password, या profile.phone जैसे कीज़ लौट सकता है, जबकि आपका UI Field.email और Field.password जैसा enum उपयोग करता है। रिस्पॉन्स के तुरंत बाद यह मैप करें ताकि बाकी view सुसंगत रहे।

एक लचीला मॉडल यह है कि serverFieldErrors: [Field: [String]] और serverFormErrors: [String] रखें। भले ही आप आमतौर पर एक संदेश दिखाएँ, एरेज़ रखें। जब आप इनलाइन त्रुटि दिखाएँ, तो सबसे सहायक संदेश पहले चुनें। उदाहरण के लिए, "Email already in use" "Invalid email" से अधिक उपयोगी है अगर दोनों मौजूद हों।

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

उन त्रुटियों के लिए जो किसी फ़ील्ड से जुड़ी नहीं हैं (expired session, rate limits, "Try again later"), उन्हें सबमिट बटन के पास रखें ताकि उपयोगकर्ता उन्हें उसी समय देखे जब वे क्रिया कर रहे हों। साथ ही सुनिश्चित करें कि सफलता पर पुराने एरर्स साफ़ हो जाएँ ताकि UI "फंस हुआ" न दिखे।

अंत में, उपयोगकर्ता संबंधित फ़ील्ड बदलते ही सर्वर एरर्स साफ़ कर दें। व्यावहारिक रूप से, email के लिए onChange हैंडलर serverFieldErrors[.email] हटाना चाहिए ताकि UI तत्काल यह दर्शाए कि "ठीक है, आप इसे ठीक कर रहे हैं।"

पहुँच और लहजा: छोटे चुनाव जो स्वदेशी लगते हैं

बदलाव पर पुन:काम कम करें

जैसे-जैसे आवश्यकताएँ बदलें और ऐप रीजेनरेट हो, क्लाइंट और सर्वर मान्यकरण को संरेखित रखें।

शुरू करें

अच्छा मान्यकरण केवल तर्क के बारे में नहीं है। यह इस बारे में भी है कि यह कैसे पढ़ता है, कैसे सुनाई देता है, और Dynamic Type, VoiceOver, और अलग भाषाओं के साथ कैसे व्यवहार करता है।

त्रुटियाँ पढ़ने में आसान बनाएं (केवल रंग पर निर्भर न रहें)

मान लें कि टेक्स्ट बड़ा हो सकता है। Dynamic Type-अनुकूल स्टाइल्स का उपयोग करें (जैसे .font(.footnote) या .font(.caption) बिना फिक्स्ड साइज़ के), और त्रुटि लेबल्स को रैप करने दें। जब त्रुटि दिखाई दे तो स्पेसिंग सुसंगत रखें ताकि लेआउट ज़्यादा न उछले।

केवल लाल रंग पर निर्भर न रहें। एक स्पष्ट आइकन, "Error:" प्रिफ़िक्स, या दोनों जोड़ें। इससे रंग दृष्टि समस्याओं वाले लोगों की मदद होती है और स्कैनिंग तेज़ होती है।

एक त्वरित चेकलिस्ट जो आमतौर पर टिकता है:

Dynamic Type के साथ स्केल होने वाला पठनीय टेक्स्ट स्टाइल उपयोग करें।
त्रुटि संदेशों के लिए रैपिंग की अनुमति दें और ट्रंकेशन से बचें।
रंग के साथ-साथ एक आइकन या "Error:" जैसा लेबल जोड़ें।
Light और Dark मोड दोनों में उच्च कंट्रास्ट रखें।

VoiceOver को सही चीज़ पढ़ने दें

जब कोई फ़ील्ड अवैध हो, VoiceOver को लेबल, वर्तमान मान, और त्रुटि एक साथ पढ़ना चाहिए। यदि त्रुटि फ़ील्ड के नीचे अलग Text है, तो वह स्किप हो सकती है या संदर्भ से बाहर पढ़ी जा सकती है।

दो पैटर्न मदद करते हैं:

फ़ील्ड और उसकी त्रुटि को एक accessibility element में जोड़ दें, ताकि जब उपयोगकर्ता फ़ील्ड पर फोकस करे तो त्रुटि घोषित हो जाए।
एक accessibility hint या value सेट करें जो त्रुटि संदेश शामिल करे (उदा., "Password, required, must be at least 8 characters").

लहजा भी मायने रखता है। संदेश ऐसे लिखें जो स्पष्ट और स्थानीयकृत करने में आसान हों। स्लैंग, चुटकुले और अस्पष्ट लाइनों जैसे "Oops" से बचें। "Email is missing" या "Password must include a number" जैसे स्पष्ट निर्देश पसंद करें।

उदाहरण: लोकल और सर्वर नियमों वाला साइनअप फॉर्म

कल्पना करें एक साइनअप फॉर्म जिसमें तीन फ़ील्ड हैं: Email, Password, और Confirm Password। लक्ष्य एक ऐसा फॉर्म है जो उपयोगकर्ता टाइप करते समय शांत रहे, और फिर आगे बढ़ने पर सहायक बने।

फोकस ऑर्डर (Return क्या करता है)

SwiftUI FocusState के साथ, हर Return की प्रेस एक प्राकृतिक कदम जैसा महसूस होना चाहिए।

Email Return: फोकस Password पर जाए।
Password Return: फोकस Confirm Password पर जाए।
Confirm Password Return: कीबोर्ड.dismiss और Submit का प्रयास।
यदि Submit फेल हो: फोकस पहली उस फ़ील्ड पर जाए जिसे ठीक करने की ज़रूरत है।

यह आख़िरी कदम मायने रखता है। यदि ईमेल अवैध है, तो फोकस Email पर लौटे, न कि कहीं और सिर्फ़ एक लाल संदेश के पास।

त्रुटियाँ कब दिखाई दें

एक सरल नियम UI को शांत रखता है: फील्ड touched होने के बाद (उपयोगकर्ता ने उसे छोड़ा) या सबमिट प्रयास के बाद ही संदेश दिखाएँ।

Email: फ़ील्ड छोड़ने पर या सबमिट पर "Enter a valid email" दिखाएँ।
Password: छोड़ने पर या सबमिट पर नियम दिखाएँ (जैसे न्यूनतम लंबाई)।
Confirm Password: छोड़ने पर या सबमिट पर "Passwords don’t match" दिखाएँ।

अब सर्वर साइड। मान लीजिए उपयोगकर्ता सबमिट करता है और आपकी API यह लौटाती है:

{
  "errors": {
    "email": "That email is already in use.",
    "password": "Password is too weak. Try 10+ characters."
  }
}

उपयोगकर्ता क्या देखता है: Email के नीचे सर्वर संदेश दिखता है, और Password के नीचे उसका संदेश। Confirm Password शांत रहता है जब तक वह लोकल रूप से फेल न हो।

अगला क्या करता है: फोकस Email (पहली सर्वर त्रुटि) पर आता है। वे ईमेल बदलते हैं, Return दबाकर Password पर जाते हैं, पासवर्ड समायोजित करते हैं, फिर फिर से सबमिट करते हैं। क्योंकि संदेश इनलाइन हैं और फोकस इरादे के साथ चलता है, फॉर्म सहयोगी लगता है, न कि डाँटने वाला।

सामान्य जाल जो मान्यकरण को "अन-iOS" बनाते हैं

मान्यकरण पैटर्न मानकीकृत करें

हर स्क्रीन के लिए वही लॉजिक बार-बार नहीं लिखने पाने के लिए एकसार त्रुटि अवस्थाएँ और सबमिट फ्लो बनाएं।

अब बनाएं

किसी फॉर्म का तकनीकी रूप से सही होना और सही महसूस न कराना दोनों अलग बातें हैं। ज़्यादातर "अन-iOS" मान्यकरण समस्याएँ समय निर्धारण से आती हैं: आप कब त्रुटि दिखाते हैं, कब फोकस मूव करते हैं, और सर्वर पर कैसे प्रतिक्रिया करते हैं।

एक आम गलती बहुत जल्दी बोलना है। अगर आप पहले कीस्ट्रोक पर त्रुटि दिखाते हैं तो लोग टाइप करते समय डाँटे जाने जैसा महसूस करते हैं। फ़ील्ड touched होने तक (वे छोड़ते हैं, या वे सबमिट करने की कोशिश करते हैं) इंतज़ार करने से अक्सर यह ठीक हो जाता है।

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

एक और जाल हर edit पर सब कुछ साफ़ कर देना है। किसी भी कैरेक्टर बदलते ही सभी त्रुटियाँ साफ़ करना असली समस्या छुपा सकता है, ख़ासकर सर्वर संदेशों के साथ। केवल उस फ़ील्ड की त्रुटि साफ़ करें जिसे संपादित किया जा रहा है, और बाकी तब तक रखें जब तक वे सच में ठीक न हों।

"साइलेंट फेलर" सबमिट बटन से बचें। अगर आप Submit को हमेशा के लिए डिसेबल करते हैं बिना यह बताए कि क्या ठीक करना है, तो उपयोगकर्ता को अनुमान लगाना पड़ेगा। यदि आप इसे डिसेबल करते हैं, तो पास में विशिष्ट संकेत दें, या सबमिट की अनुमति दें और फिर पहले मुद्दे की दिशा दिखाएँ।

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

एक त्वरित शांत चेक:

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

उदाहरण: अगर सर्वर कहता है "email already in use" (शायद आपके बैकएंड से), तो संदेश Email के नीचे रखें, Password को छुए बिना रखें, और उपयोगकर्ता को पूरा फॉर्म फिर से शुरू किए बिना Email एडिट करने दें।

त्वरित चेकलिस्ट और अगले कदम

स्वदेशी-सा मान्यकरण अनुभव ज्यादातर समय और संयम के बारे में है। आप कड़े नियम रख सकते हैं और स्क्रीन को शांत महसूस करा सकते हैं।

शिप करने से पहले इनकी जाँच करें:

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

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

डिबग और सपोर्ट के लिए, सर्वर मान्यकरण कोड्स (रॉ संदेश नहीं) स्क्रीन और फ़ील्ड नाम के साथ लॉग करना मदद करता है। जब उपयोगकर्ता कहे "यह साइनअप नहीं कर रहा", तो आप जल्दी बता सकें कि यह email_taken, weak_password, या नेटवर्क टाइमआउट था।

इसे पूरे ऐप में सुसंगत रखने के लिए, अपना फील्ड मॉडल (value, touched, local error, server error), त्रुटि प्लेसमेंट, और फोकस नियम मानकीकृत रखें। अगर आप हर स्क्रीन हाथ से कोड किए बिना नेटिव iOS फॉर्म तेज़ी से बनाना चाहते हैं तो AppMaster (appmaster.io) SwiftUI ऐप्स और बैकएंड सर्विसेज़ को जनरेट कर सकता है, जो क्लाइंट और सर्वर मान्यकरण नियमों को संरेखित रखना आसान बना सकता है।