You optimized the endpoint. Your resend email API responds in under half a second. And yet users still open support tick

നിങ്ങൾ എൻഡ്‌പോയിന്റ് ഒപ്റ്റിമൈസ് ചെയ്തു. നിങ്ങളുടെ resend-email API അര സെക്കൻഡിൽ താഴെ സമയത്തിനുള്ളിൽ പ്രതികരിക്കുന്നു. എന്നിട്ടും ലിങ്ക് ലഭിച്ചില്ല എന്ന് പറഞ്ഞ് ഉപയോക്താക്കൾ സപ്പോർട്ട് ടിക്കറ്റുകൾ തുറക്കുന്നു. അവർ രണ്ടുതവണ ക്ലിക്ക് ചെയ്യുന്നു. ഇൻബോക്സ് പരിശോധിക്കുന്നതിന് മുമ്പ് തന്നെ അവർ പ്രക്രിയ ഉപേക്ഷിക്കുന്നു. എന്തോ തകരാർ സംഭവിക്കുന്നുണ്ടെന്ന് ഇപ്പോഴും തോന്നുന്നു.

ഈ വ്യത്യാസം മിക്കവാറും ഇൻഫ്രാസ്ട്രക്ചറിലല്ല, മറിച്ച് ഇന്റർഫേസിലാണ്. ഒരു ബാക്കെൻഡിന് 400 മില്ലിസെക്കൻഡിൽ 200 OK നൽകാൻ കഴിയും, എന്നാൽ ഫ്രണ്ട്‌എൻഡ് ഒരു ചാടുന്ന ലേഔട്ടും മിന്നുന്ന ബാനറും കാണിച്ചാൽ, ഉപയോക്താവിന് അത് പരാജയമായി അനുഭവപ്പെടും. ഒരാൾ ഒരു ബട്ടൺ ക്ലിക്ക് ചെയ്യുമ്പോൾ സ്ക്രീൻ അവരുടെ കർസറിന് താഴെ മാറിക്കിടക്കുകയാണെങ്കിൽ, അവർ ഫീഡ്‌ബാക്ക് ലൂപ്പുകളെക്കുറിച്ചോ നെറ്റ്‌വർക്ക് ലേറ്റൻസിയെക്കുറിച്ചോ ചിന്തിക്കില്ല. ആപ്പ് തകരാറിലായി എന്നാണ് അവർ കരുതുന്നത്.

യഥാർത്ഥ പ്രശ്നം അപൂർവ്വമായി മാത്രമേ വേഗതയുമായി ബന്ധപ്പെട്ടിട്ടുള്ളൂ

React ടീമുകൾ പലപ്പോഴും ഇമെയിൽ കൺഫർമേഷനെ ഒരു ലളിതമായ സ്റ്റേറ്റ് മെഷീനായി (state machine) കാണുന്നു: idle, loading, success, error. ഒരു കമ്പോണന്റ് ഒരു mutation ഫയർ ചെയ്യുന്നു, isLoading എന്നത് true ആക്കുന്നു, തുടർന്ന് പ്രോമിസ് (promise) റെസൾവ് ചെയ്യുമ്പോൾ ഒരു മെസ്സേജ് കാണിക്കുന്നു. ആ മാറ്റമാണ് (swap) യഥാർത്ഥത്തിൽ പ്രശ്നം ഉണ്ടാക്കുന്നത്. ബ്രൗസർ ലേഔട്ട് വീണ്ടും കണക്കാക്കുന്നു, ബാധിക്കപ്പെട്ട ഭാഗം വീണ്ടും വരയ്ക്കുന്നു (repaint), ചിലപ്പോൾ മുഴുവൻ കാർഡോ പേജോ റീഫ്ലോ (reflow) ചെയ്യുന്നു. ഉപയോക്താവ് പ്രതീക്ഷിച്ചത് ശാന്തതയാണ്, എന്നാൽ അവർ കാണുന്നത് ചലനങ്ങളാണ്. അവർക്ക് ആ ആപ്ലിക്കേഷൻ ആക്ഷൻ കൺഫേം ചെയ്തില്ല; അത് വിറയ്ക്കുകയാണ് ചെയ്തത്.

അതുകൊണ്ടാണ് സമയത്തേക്കാൾ ഉപരിയായി പെർസെപ്ഷൻ (perception) പ്രധാനമാകുന്നത്. ഇരുന്നൂറ് മില്ലിസെക്കൻഡ് എടുക്കുന്ന ഒരു അസ്ഥിരമായ ഇന്റർഫേസിനേക്കാൾ, അഞ്ഞൂറ് മില്ലിസെക്കൻഡ് എടുക്കുന്ന ഒരു സ്റ്റേബിൾ ഇന്റർഫേസ് വേഗമേറിയതും സുരക്ഷിതവുമാണെന്ന് തോന്നും. ഉപയോക്താക്കൾക്ക് ലേറ്റൻസി അളക്കാൻ കഴിയില്ല, പക്ഷേ അവർക്ക് ആത്മവിശ്വാസം അളക്കാൻ കഴിയും. UI ഉലയുമ്പോൾ, റിക്വസ്റ്റും അതോടൊപ്പം ഉലയുന്നു എന്ന് അവർ കരുതുന്നു.

മോശം ഫീഡ്‌ബാക്ക് വിശ്വാസം തകർക്കുന്ന മൂന്ന് വഴികൾ

മോശം കൺഫർമേഷൻ ഫീഡ്‌ബാക്ക് സാധാരണയായി മൂന്ന് കെണികളിൽ വീഴാറുണ്ട്. എന്താണ് ശ്രദ്ധിക്കേണ്ടതെന്ന് അറിഞ്ഞാൽ ഇവ എളുപ്പത്തിൽ തിരിച്ചറിയാം.

ദൂരം (Distance). ഉപയോക്താവ് ഫോമിൻ്റെ താഴെ ഭാഗത്താണ് ക്ലിക്ക് ചെയ്തതെങ്കിൽ, ഫോമിൻ്റെ മുകളിൽ ഒരു ഗ്ലോബൽ ബാനറിൽ സക്സസ് മെസ്സേജ് വരുന്നത് കാഴ്ചയുടെ ഒഴുക്കിനെ തടസ്സപ്പെടുത്തുന്നു. കണ്ണ് യാത്ര ചെയ്യുന്നു; കൈ കാത്തിരിക്കുന്നു; ക്ലിക്ക് തെറ്റി എന്ന് മസ്തിഷ്കം കരുതുന്നു. ഫീഡ്‌ബാക്ക് ആ ആക്ഷനുമായി ബന്ധപ്പെട്ട അതേ പരിസരത്ത് തന്നെയായിരിക്കണം.

ബഹളം (Noise). പൂജ്യത്തിൽ നിന്ന് പൂർണ്ണ വലുപ്പത്തിലേക്ക് മാറുന്ന സ്പിന്നറുകൾ, ചാടുന്ന ചെക്ക്മാർക്കുകൾ, അല്ലെങ്കിൽ ഒരു സാധാരണ ഇമെയിൽ അയക്കുന്നതിനെ ആഘോഷമാക്കാൻ വരുന്ന മോഡലുകൾ എന്നിവ അനാവശ്യമായ ശ്രദ്ധ ആകർഷിക്കുന്നു. അവ ഒരു ലളിതമായ കൺഫർമേഷനെ ഒരു നാടകീയമായ പ്രകടനമാക്കി മാറ്റുന്നു. വെസ്റ്റിബുലാർ ഡിസോർഡറുകൾ (vestibular disorders) ഉള്ള ഉപയോക്താക്കൾക്ക് അമിതമായ ചലനം വെറുപ്പല്ല, മറിച്ച് ശാരീരികമായ അസ്വസ്ഥതയാണ് ഉണ്ടാക്കുന്നത്.

ലേഔട്ട് ഷിഫ്റ്റ് (Layout shift). ഒരു ബട്ടണിന് താഴെ പുതിയൊരു പാരഗ്രാഫ് ചേർക്കുന്നത് അടുത്ത ഫോം ഫീൽഡിനെ താഴേക്ക് തള്ളുന്നു. ഫൂട്ടർ മാറുന്നു. ഉള്ളടക്കം പുനർക്രമീകരിക്കപ്പെടുന്നു. ഇത് ഉപയോഗക്ഷമതയെയും (usability) ആക്സസിബിലിറ്റിയെയും (accessibility) ഒരുപോലെ ബാധിക്കുന്നു. ഒരു സ്വിച്ച് ഡിവൈസോ കൃത്യമായ ഐ ട്രാക്കിംഗോ ഉപയോഗിക്കുന്ന ഒരാൾ അടുത്ത ടാർഗെറ്റിലേക്ക് നീങ്ങാൻ തുടങ്ങുമ്പോൾ അത് പെട്ടെന്ന് സ്ഥാനം മാറുന്നു. നിങ്ങളുടെ ബാക്കെൻഡ് 400ms-ൽ പ്രതികരിച്ചാലും, ഒരു അസ്ഥിരമായ UI പ്രക്രിയ സാവധാനത്തിലുള്ളതും സുരക്ഷിതമല്ലാത്തതുമായി തോന്നിപ്പിക്കുന്നു. നിങ്ങളുടെ ആപ്പ് ശാന്തവും വ്യക്തവുമായ സൂചനകൾ നൽകുന്നതിൽ പരാജയപ്പെട്ടതിനാൽ ഉപയോക്താക്കൾ ഇൻബോക്സ് നേരിട്ട് പരിശോധിച്ചേക്കാം.

പ്രക്രിയയെ ഒരു വായനാ ക്രമമായി (Reading Sequence) കാണുക

ഇമെയിൽ കൺഫർമേഷനെ ലോഡിംഗും സക്സസ് സ്റ്റേറ്റും തമ്മിലുള്ള ഒരു മാറ്റമായി മാത്രം കാണുന്നത് നിർത്തുക. ഉപയോക്താവ് ഒറ്റനോട്ടത്തിൽ മനസ്സിലാക്കുന്ന ഒരു വായനാ ക്രമമായി ഇതിനെ കാണുക. സ്വയം നാല് ചോദ്യങ്ങൾ ചോദിക്കുക.

ക്ലിക്ക് ചെയ്ത ഉടൻ തന്നെ വ്യക്തി എന്താണ് കാണുന്നത്? ഉത്തരം 'ഒന്നുമില്ല' എന്നോ അല്ലെങ്കിൽ ബട്ടൺ വെറുതെ ഫ്രീസ് ആയതാണെന്നോ ആണെങ്കിൽ, നിങ്ങൾ അവരെ നഷ്ടിച്ചു കഴിഞ്ഞു. സിസ്റ്റം ഇൻപുട്ട് സ്വീകരിച്ചു എന്ന് പറയുന്ന ഒരു തൽക്ഷണവും പ്രാദേശികവുമായ (local) മാറ്റം അവിടെ ഉണ്ടായിരിക്കണം.

ഒരു സ്ക്രീൻ റീഡർ എന്താണ് പ്രഖ്യാപിക്കുന്നത്? ഒരു മാന്യമായ, തടസ്സപ്പെടുത്താത്ത അപ്‌ഡേറ്റ് ഉപയോക്താവിനെ അവരുടെ നിലവിലെ സാഹചര്യത്തിൽ തന്നെ തുടരാൻ അനുവദിക്കുന്നു. ആ അറിയിപ്പ് ഒരു സൈറൺ പോലെയാകരുത്, മറിച്ച് ഒരു ഫൂട്ട്നോട്ട് പോലെയായിരിക്കണം.

കാത്തിരിക്കുമ്പോൾ ലേഔട്ട് എത്രത്തോളം മാറുന്നു? ആദർശപരമായി പറഞ്ഞാൽ, പൂജ്യം. ഉപയോക്താവ് വരുന്നതിന് മുമ്പ് തന്നെ ആ സ്ഥലം റിസർവ് ചെയ്തിരിക്കണം.

ഇമെയിൽ വരാൻ സമയമെടുത്താൽ ഏത് സൂചനയാണ് ദൃശ്യമായി നിൽക്കുന്നത്? നെറ്റ്‌വർക്കുകൾ തകരാറിലാകാം. റിക്വസ്റ്റ് ഏതാനും സെക്കൻഡുകൾക്ക് മുകളിൽ നീണ്ടുപോയാൽ, എന്തോ നടക്കുന്നുണ്ടെന്ന് ഉപയോക്താവിന് അറിയാൻ കഴിയുന്നുണ്ടോ, അതോ ആ നിശബ്ദത അവരെ പരിഭ്രാന്തരാക്കുന്നുണ്ടോ? ഒരു സ്ഥിരമായ, ശാന്തമായ ഇൻഡിക്കേറ്റർ പരിഭ്രാന്തി ഒഴിവാക്കുന്നു.

ശാന്തമായ കൺഫർമേഷൻ ഫീഡ്‌ബാക്കിനായി നാല് നിയമങ്ങൾ

നാല് പ്രായോഗിക നിയന്ത്രണങ്ങൾ പാലിച്ചുകൊണ്ട് നിങ്ങൾക്ക് മിക്കവാറും എല്ലാ കൺഫർമേഷൻ ഫ്ലോകളും ശരിയാക്കാം.

മെസ്സേജ് ആക്ഷന് അടുത്തുള്ള ഒരു നിശ്ചിത സ്ഥലത്ത് തന്നെ നിലനിർത്തുക. ഫീഡ്‌ബാക്ക് ആവശ്യമുള്ളതിന് മുമ്പ് തന്നെ അതിനായി സ്ഥലം മാറ്റിവെക്കുക. ഒരു നിശ്ചിത min-height ഉള്ള കണ്ടെയ്നറോ അല്ലെങ്കിൽ മെസ്സേജ് സ്ലോട്ട് നിലനിർത്തുന്ന ഒരു CSS grid റോയോ ഉപയോഗിക്കുക. ടെക്സ്റ്റ് വരുമ്പോൾ അത് ചുറ്റുമുള്ള ഉള്ളടക്കത്തെ തള്ളിക്കളയരുത്. ആക്ഷൻ നടന്ന സ്ഥലത്ത് തന്നെ കൺഫർമേഷൻ നിലനിൽക്കണം.

ആക്സസിബിലിറ്റിക്കായി (accessibility) role="status" എന്നതിനോടൊപ്പം aria-live="polite" ഉപയോഗിക്കുക. ആദ്യത്തെ റെൻഡറിംഗ് (render) മുതൽ നിലവിലുള്ള ഒരു ലൈവ് റീജിയൻ (live region) നിങ്ങളുടെ മാർക്കപ്പിൽ (markup) നിർമ്മിക്കുക. സ്റ്റേറ്റ് (state) മാറുമ്പോൾ, ആ റീജിയനുള്ളിലെ ടെക്സ്റ്റ് നോഡ് React അപ്‌ഡേറ്റ് ചെയ്യും. കീബോർഡ് ഫോക്കസ് (keyboard focus) മാറ്റുകയോ ഉപയോക്താവിനെ തടസ്സപ്പെടുത്തുകയോ ചെയ്യാതെ തന്നെ സ്ക്രീൻ റീഡറുകൾ ഈ മാറ്റം അറിയിക്കും. സാധാരണമായ ഒരു കൺഫർമേഷനായി ഒരിക്കലും aria-live="assertive" ഉപയോഗിക്കരുത്. അത് ഉറക്കെ വിളിച്ചു പറയുന്നതിന് തുല്യമാണ്.

ബട്ടൺ അൺമൗണ്ട് (unmount) ചെയ്യരുത്. ഒരു സന്ദേശം കാണിക്കാനായി ബട്ടൺ DOM-ൽ നിന്ന് നീക്കം ചെയ്യുമ്പോൾ, അത് കീബോർഡ് ഉപയോക്താക്കളെ ആശയക്കുഴപ്പത്തിലാക്കും. അവരുടെ ഫോക്കസ് നഷ്ടപ്പെടും. സ്ക്രീൻ റീഡറുകൾ അജ്ഞാതമായ ഭാഗങ്ങളിൽ എത്തും. പകരം, ബട്ടൺ മൗണ്ട് ചെയ്തまま (mounted) തന്നെ നിലനിർത്തുക. aria-disabled ഉപയോഗിച്ച് അത് ഡിസേബിൾ ചെയ്യുക, അതിന്റെ ലേബൽ "Sending..." എന്നോ "Sent" എന്നോ മാറ്റുക, അല്ലെങ്കിൽ ഒരു കൗണ്ട്ഡൗൺ ടൈമർ ഉപയോഗിക്കുക. എലമെന്റ് അവിടെത്തന്നെ ഇരിക്കും, അതിന്റെ സ്റ്റേറ്റ് മാത്രമേ മാറുന്നുള്ളൂ.

prefers-reduced-motion മാനിക്കുക. എല്ലാവർക്കും അമിതമായ ചലനങ്ങൾ (animations) ഇഷ്ടപ്പെടണമെന്നില്ല. എല്ലാ ട്രാൻസിഷനുകളും (transitions) ഒരു മീഡിയ ക്വറിയിൽ (media query) ഉൾപ്പെടുത്തുക. ചലനങ്ങൾ കുറയ്ക്കണമെന്ന് ഉപയോക്താവ് ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തോട് ആവശ്യപ്പെട്ടിട്ടുണ്ടെങ്കിൽ, പെട്ടെന്നുള്ള ടെക്സ്റ്റ് മാറ്റമോ അല്ലെങ്കിൽ നേരിയ ഓപാസിറ്റി ഫേഡോ (opacity fade) നൽകുക. ബൗൺസുകളോ (bounces), കറക്കങ്ങളോ (spins), വലിയ സ്ലൈഡുകളോ (sweeping slides) പാടില്ല. ചലനങ്ങൾ കുറയ്ക്കുക എന്നാൽ അർത്ഥം കുറയ്ക്കുക എന്നല്ല.

ഫലപ്രദമായ ഒരു സ്ഥിരതയുള്ള രീതി

ഏറ്റവും മികച്ച രീതി ബോറടിപ്പിക്കുന്നതാകാം, അതാണ് ഇതിന്റെ ഗുണം.

ആദ്യത്തെ റെൻഡറിംഗ് മുതൽ തന്നെ സന്ദേശത്തിനായി സ്ഥലം മാറ്റിവെക്കുക. ബട്ടണിന് തൊട്ടുതാഴെയായി കാഴ്ചയിൽ ശൂന്യമായ ഒരു ചെറിയ കണ്ടെയ്നർ (container) നൽകുക. അതിന് ഒരു നിശ്ചിത ഉയരമോ (fixed height) കുറഞ്ഞ ഉയരമോ നൽകുക, അങ്ങനെ പുതിയ ടെക്സ്റ്റ് വരുമ്പോൾ അടുത്ത സെക്ഷൻ താഴേക്ക് തള്ളപ്പെടാതിരിക്കട്ടെ. ഗ്ലോബൽ ടോസ്റ്റുകൾ (global toasts) ഉപയോഗിക്കുന്നതിന് പകരം ഫീഡ്‌ബാക്ക് ബട്ടണിന് അടുത്ത തന്നെ നിലനിർത്തുക. സിസ്റ്റം മുഴുവൻ ഉണ്ടാകുന്ന പിശകുകൾക്ക് ടോസ്റ്റുകൾ ഉപയോഗപ്രദമാണ്, എന്നാൽ സാധാരണ ഇമെയിൽ കൺഫർമേഷനുകൾക്ക് അവ ശ്രദ്ധ തിരിക്കുകയും കണ്ണ് അങ്ങോട്ടുമിങ്ങോട്ടും നീങ്ങാൻ നിർബന്ധിക്കുകയും ചെയ്യുന്നു.

ചലനങ്ങൾ കുറയ്ക്കുക. അനിമേഷൻ ആവശ്യമാണെങ്കിൽ, ട്രാൻസിഷനുകൾ ഇരുനൂറ് മില്ലിസെക്കൻഡിൽ താഴെയായിരിക്കണം, അവ ഓപാസിറ്റിയോ (opacity) അല്ലെങ്കിൽ നേരിയ നിറ മാറ്റമോ (color shift) മാത്രമായി പരിമിതപ്പെടുത്തുക. ലേഔട്ട് റീകാൽക്കുലേഷൻ (layout recalculation) ആവശ്യമാക്കുന്ന ബ്ലോക്ക്-ലെവൽ എലമെന്റുകൾ ചേർക്കുന്നതോ നീക്കം ചെയ്യുന്നതോ ഒഴിവാക്കുക. ബട്ടണിനുള്ളിൽ തന്നെ ഒരു ലോഡിംഗ് സ്റ്റേറ്റ് കാണിക്കണമെങ്കിൽ, ലളിതമായ ഒരു ടെക്സ്റ്റ് മാറ്റമോ അല്ലെങ്കിൽ ഒരു സ്റ്റാറ്റിക് ഐക്കണോ ഉപയോഗിക്കുക. ബട്ടണിന്റെ വലിപ്പം കൂട്ടുകയോ (scale), കുലുക്കുകയോ (shake), സ്ക്രീൻ മിന്നിക്കുകയോ (flash) ചെയ്യരുത്.

സക്സസ് സ്റ്റേറ്റ് (success state) വരുമ്പോൾ, ചെറിയൊരു സൂചന ദൃശ്യമായി നിലനിർത്തുക. "Check your inbox" എന്നത് മതിയാകും. മൂന്ന് സെക്കൻഡിന് ശേഷം അത് തനിയെ അപ്രത്യക്ഷമാക്കരുത് (auto-dismiss). തെറ്റായ സമയത്ത് ശ്രദ്ധ മാറിയ ഒരു ഉപയോക്താവിന് എന്ത് സംഭവിച്ചു എന്ന് ചിന്തിക്കേണ്ടി വരരുത്.

ഇത് എങ്ങനെ സമയം ലാഭിക്കുന്നു

ഈ ചെറിയ കാര്യങ്ങൾ ശ്രദ്ധിക്കുമ്പോൾ, നിങ്ങളുടെ ഇൻഫ്രാസ്ട്രക്ചർ ബജഡുമായി (infrastructure budget) ബന്ധമില്ലാത്ത യഥാർത്ഥ ഫലങ്ങൾ നിങ്ങൾക്ക് കാണാൻ കഴിയും.

ഒരേ ബട്ടണിൽ തന്നെ ഡബിൾ ക്ലിക്ക് ചെയ്യുന്നത് കുറയുന്നു. ഡിസേബിൾ ചെയ്ത അവസ്ഥയും (disabled state) ലോക്കൽ ഫീഡ്‌ബാക്കും വഴി ആദ്യത്തെ ക്ലിക്ക് രേഖപ്പെടുത്തി എന്ന് വ്യക്തമാകും.

സെൻഡ് ക്ലിക്ക് ചെയ്ത ശേഷം ഉപയോക്താക്കൾ പാതിവഴിയിൽ ഉപേക്ഷിക്കുന്നത് കുറയുന്നു. സിസ്റ്റം പ്രവർത്തിക്കുന്നുണ്ടെന്ന ശാന്തമായ സൂചനകൾ ഉപയോക്താക്കളെ പിടിച്ചുനിർത്തും.

ഇമെയിൽ ലഭിച്ചില്ല എന്ന് പരാതിപ്പെടുന്ന സപ്പോർട്ട് ടിക്കറ്റുകൾ കുറയുന്നു. ഇത്തരം ടിക്കറ്റുകളിൽ ഭൂരിഭാഗവും ഇമെയിൽ നഷ്ടപ്പെട്ടതുകൊണ്ടല്ല, മറിച്ച് ഇന്റർഫേസിലെ ആശയക്കുഴപ്പം മൂലമാണ് ഉണ്ടാകുന്നത്.

വേഗത്തിലുള്ള പെർസീവ്ഡ് പെർഫോമൻസ് (perceived performance). ഒരേ ലേറ്റൻസി (latency) ആണെങ്കിൽ പോലും, ഒരു സ്ഥിരതയുള്ള UI എപ്പോഴും കുഴപ്പമുള്ളതിനേക്കാൾ വേഗതയുള്ളതായി തോന്നും.

ഇത് ട്രാക്ക് ചെയ്യാൻ നിങ്ങൾക്ക് സങ്കീർണ്ണമായ ടൂളുകൾ ആവശ്യമില്ല. ഡ്യൂപ്ലിക്കേറ്റ് റിക്വസ്റ്റുകൾക്കായി നിങ്ങളുടെ എറർ ലോഗുകൾ (error logs) പരിശോധിക്കുക. സപ്പോർട്ട് ക്യൂ (support queue) ശ്രദ്ധിക്കുക. കൺഫർമേഷൻ സ്ക്രീനിലെ റിറ്റൻഷൻ (retention) വഴി ഉപയോക്താക്കളുടെ സ്ഥിരത അളക്കുക. ശാന്തവും പ്രവചിക്കാവുന്നതുമായ (predictable) ഒരു ഇന്റർഫേസ്, സിസ്റ്റം കൃത്യമായി പ്രവർത്തിക്കുന്നു എന്നതിന്റെ സൂചനയാണ്. ആ പ്രവചനാതീതമല്ലാത്ത സ്വഭാവമാണ് വിശ്വാസം വളർത്തുന്നത്.