તમે એન્ડપોઇન્ટને ઓપ્ટિમાઇઝ કર્યું છે. તમારું resend-email API અડધા સેકન્ડથી પણ ઓછા સમયમાં પ્રતિસાદ આપે છે. તેમ છતાં વપરાશકર્તાઓ હજુ પણ સપોર્ટ ટિકિટો ખોલે છે અને કહે છે કે લિંક ક્યારેય આવી જ નથી. તેઓ બે વાર ક્લિક કરે છે. ઇનબોક્સ તપાસતા પહેલા જ તેઓ પ્રક્રિયા છોડી દે છે. કંઈક તો હજુ પણ ખોટું લાગે છે.
આ વિસંગતતા લગભગ હંમેશા ઇન્ટરફેસમાં હોય છે, ઇન્ફ્રાસ્ટ્રક્ચરમાં નહીં. બેકએન્ડ 400 મિલિસેકન્ડમાં 200 OK પરત કરી શકે છે, પરંતુ જો ફ્રન્ટએન્ડ કૂદતું લેઆઉટ અને ઝબકતા બેનર સાથે જવાબ આપે, તો વપરાશકર્તાને તો નિષ્ફળતાનો જ અનુભવ થાય છે. જ્યારે કોઈ વ્યક્તિ બટન પર ક્લિક કરે છે અને તેમના કર્સરની નીચે સ્ક્રીન ખસી જાય છે, ત્યારે તેઓ ફીડબેક લૂપ્સ અથવા નેટવર્ક લેટન્સી વિશે વિચારતા નથી. તેઓ એમ વિચારે છે કે એપ બગડી ગઈ છે.
વાસ્તવિક સમસ્યા ભાગ્યે જ ઝડપ હોય છે
React ટીમો ઘણીવાર ઇમેઇલ કન્ફર્મેશનને એક સાદી સ્ટેટ મશીન તરીકે જુએ છે: idle, loading, success, error. કમ્પોનન્ટ એક mutation ફાયર કરે છે, isLoading ને true પર સેટ કરે છે, અને પછી જ્યારે promise રિઝોલ્વ થાય ત્યારે મેસેજ બદલે છે. આ બદલાવ (swap) જ એ જગ્યા છે જ્યાં નુકસાન થાય છે. બ્રાઉઝર લેઆઉટની ફરીથી ગણતરી કરે છે, અસરગ્રસ્ત વિસ્તારને ફરીથી પેઇન્ટ કરે છે, અને ક્યારેક આખા કાર્ડ અથવા પેજને રિફ્લો કરે છે. વપરાશકર્તા ત્યાં હલનચલન જુએ છે જ્યાં તેઓ સ્થિરતાની અપેક્ષા રાખતા હતા. તેમના માટે, એપ્લિકેશને ક્રિયાની પુષ્ટિ કરી નથી, પરંતુ તે ધ્રૂજી ઉઠી છે.
આ જ કારણ છે કે સમય કરતાં ધારણા (perception) વધુ મહત્વની છે. એક સ્થિર ઇન્ટરફેસ જે પાંચસો મિલિસેકન્ડ લે છે તે અસ્થિર ઇન્ટરફેસ કરતા વધુ ઝડપી અને સુરક્ષિત લાગે છે જે બસો મિલિસેકન્ડ લે છે. વપરાશકર્તાઓ લેટન્સી માપી શકતા નથી, પરંતુ તેઓ આત્મવિશ્વાસ માપી શકે છે. જ્યારે UI ડગમગે છે, ત્યારે તેઓ માની લે છે કે વિનંતી (request) પણ તેની સાથે ડગમગી ગઈ છે.
ખરાબ ફીડબેક વિશ્વાસ કેવી રીતે તોડે છે તેના ત્રણ રસ્તાઓ
નબળું કન્ફર્મેશન ફીડબેક સામાન્ય રીતે ત્રણ એવા છટકુંમાં ફસાય છે જેને એકવાર તમે શું શોધવું તે જાણી લો પછી ઓળખવા સરળ છે.
અંતર (Distance). જો વપરાશકર્તા ફોર્મની નીચેના ભાગમાં ક્લિક કરે અને સફળતાનો મેસેજ ફોર્મની ઉપરના ભાગમાં ગ્લોબલ બેનરમાં દેખાય, તો તે વિઝ્યુઅલ લિંક તોડી નાખે છે. આંખ મુસાફરી કરે છે; હાથ રાહ જુએ છે; મગજ માની લે છે કે ક્લિક ચૂકી ગયું છે. ફીડબેક એ જ વિસ્તારમાં હોવું જોઈએ જે ક્રિયા દ્વારા ટ્રિગર થયું હોય.
ઘોંઘાટ (Noise). સ્પિનર્સ જે શૂન્યથી ફૂલ સાઈઝ સુધી સ્કેલ થાય છે, ચેકમાર્ક જે બાઉન્સ કરે છે, અથવા રૂટિન ઇમેઇલ મોકલવાની ઉજવણી કરવા માટે ફેડ-ઇન થતા મોડલ્સ - આ બધું જ એવું ધ્યાન ખેંચે છે જે તેને મળવું જોઈએ નહીં. તેઓ એક સાદી પુષ્ટિને નાટકીય પ્રદર્શનમાં ફેરવી નાખે છે. વેસ્ટિબ્યુલર ડિસઓર્ડર (vestibular disorders) ધરાવતા વપરાશકર્તાઓ માટે, વધુ પડતી હલનચલન માત્ર હેરાન કરતી નથી, પણ શારીરિક રીતે અસ્વસ્થતા પેદા કરે છે.
લેઆઉટ શિફ્ટ (Layout shift). બટનની નીચે નવો ફકરો ઉમેરવાથી પછીનું ફોર્મ ફીલ્ડ નીચે ધકેલાઈ જાય છે. ફૂટર ખસી જાય છે. કન્ટેન્ટનું સ્થાન બદલાઈ જાય છે. આ ઉપયોગિતા (usability) અને એક્સેસિબિલિટી (accessibility) બંનેને નુકસાન પહોંચાડે છે. સ્વિચ ડિવાઇસ અથવા ચોક્કસ આઈ-ટ્રેકિંગનો ઉપયોગ કરનાર વ્યક્તિ કદાચ આગલા લક્ષ્ય તરફ આગળ વધવાનું શરૂ કરી ચૂકી હોય અને તે અચાનક તેનું સ્થાન બદલી નાખે. ભલે તમારું બેકએન્ડ 400ms માં પ્રતિસાદ આપે, પણ અસ્થિર UI પ્રક્રિયાને ધીમી અને અસુરક્ષિત બનાવે છે. વપરાશકર્તાઓ તેમનું ઇનબોક્સ મેન્યુઅલી ખોલી શકે છે કારણ કે તમારી એપ શાંત અને સ્પષ્ટ સંકેતો આપવામાં નિષ્ફળ રહી છે.
પ્રક્રિયાને વાંચન ક્રમ (Reading Sequence) તરીકે ફરીથી વિચારો
ઇમેઇલ કન્ફર્મેશનને લોડિંગ અને સક્સેસ સ્ટેટ્સ વચ્ચેના ટૉગલ તરીકે જોવાનું બંધ કરો. તેને એક વાંચન ક્રમ તરીકે જુઓ જેને વપરાશકર્તા એક નજરમાં સમજી લે છે. તમારી જાતને ચાર ચોક્કસ પ્રશ્નો પૂછો.
ક્લિક કર્યા પછી તરત જ વ્યક્તિ શું જુએ છે? જો જવાબ 'કંઈ નહીં' હોય, અથવા જો બટન ફક્ત ફ્રીઝ થઈ જાય, તો તમે તેમને પહેલેથી જ ગુમાવી દીધા છે. સિસ્ટમે ઇનપુટ સાંભળ્યું છે તે દર્શાવતો ત્વરિત, સ્થાનિક ફેરફાર હોવો જોઈએ.
સ્ક્રીન રીડર શું જાહેર કરે છે? એક નમ્ર, અવરોધ ન કરતું અપડેટ વપરાશકર્તાને કોઈપણ અચાનક અવાજ વગર તેમના વર્તમાન સંદર્ભમાં આગળ વધવા દે છે. જાહેરાત ફૂટનોટ જેવી હોવી જોઈએ, સાયરન જેવી નહીં.
રાહ જોતી વખતે લેઆઉટ કેટલું ખસે છે? આદર્શ રીતે, શૂન્ય. વેઇટિંગ સ્ટેટ એ જગ્યા રોકવી જોઈએ જે વપરાશકર્તાના આવતા પહેલા જ અનામત રાખવામાં આવી હોય.
જો ઇમેઇલ આવવામાં સમય લાગે તો કયો સંકેત દેખાતો રહે છે? નેટવર્ક નિષ્ફળ જાય છે. જો વિનંતી થોડી સેકન્ડોથી વધુ સમય લે છે, તો શું વપરાશકર્તા જાણે છે કે કંઈક હજુ પણ થઈ રહ્યું છે, અથવા આ શાંતિ તેમને ગભરાવી દે છે? એક સતત, શાંત ઇન્ડિકેટર ગભરાટને અટકાવે છે.
શાંત કન્ફર્મેશન ફીડબેક માટે ચાર નિયમો
તમે ચાર વ્યવહારુ મર્યાદાઓનું પાલન કરીને મોટાભાગની કન્ફર્મેશન પ્રક્રિયાઓને સુધારી શકો છો.
મેસેજને ક્રિયાની નજીકના નિશ્ચિત વિસ્તારમાં રાખો. ફીડબેકની જરૂર પડે તે પહેલાં જ તેના માટે જગ્યા અનામત રાખો. min-height ધરાવતા કન્ટેનર અથવા CSS grid row નો ઉપયોગ કરો જે મેસેજ સ્લોટને પકડી રાખે. જ્યારે ટેક્સ્ટ દેખાય, ત્યારે તેણે આસપાસના કન્ટેન્ટને ધક્કો મારવો જોઈએ નહીં. કન્ફર્મેશન ત્યાં જ હોવું જોઈએ જ્યાં ઇરાદો (intent) થયો હોય.
ઍક્સેસિબિલિટી માટે role="status" સાથે aria-live="polite" નો ઉપયોગ કરો. તમારા માર્કઅપમાં એક એવું લાઇવ રીજન બનાવો જે પ્રથમ રેન્ડરથી જ અસ્તિત્વમાં હોય. જ્યારે સ્ટેટ બદલાય છે, ત્યારે React તે રીજનની અંદરના ટેક્સ્ટ નોડને અપડેટ કરે છે. સ્ક્રીન રીડર્સ કીબોર્ડ ફોકસ છીનવ્યા વગર અથવા વપરાશકર્તાને વિક્ષેપ પહોંચાડ્યા વગર ફેરફારની જાહેરાત કરશે. સામાન્ય કન્ફર્મેશન માટે ક્યારેય aria-live="assertive" નો ઉપયોગ કરશો નહીં. તે બૂમ પાડવા સમાન છે.
બટનને અનમાઉન્ટ કરશો નહીં. જ્યારે તમે મેસેજ બતાવવા માટે DOM માંથી બટનને દૂર કરો છો, ત્યારે તમે કીબોર્ડ વપરાશકર્તાઓને ગૂંચવણમાં મૂકી દો છો. તેમનો ફોકસ ગાયબ થઈ જાય છે. સ્ક્રીન રીડર્સ અજાણ્યા એન્સેસ્ટર (ancestors) એલિમેન્ટ્સ પર પહોંચી જાય છે. તેના બદલે, બટનને માઉન્ટેડ રાખો. તેને aria-disabled સાથે ડિસેબલ કરો, તેનું લેબલ બદલીને "Sending..." અથવા "Sent" કરો, અથવા તેને કાઉન્ટડાઉન ટાઈમર સાથે બદલો. એલિમેન્ટ તેની જગ્યાએ જ રહેશે. ફક્ત તેનું સ્ટેટ બદલાશે.
prefers-reduced-motion નો આદર કરો. દરેક વ્યક્તિને ઉજવણી જોઈતી નથી. કોઈપણ ટ્રાન્ઝિશનને મીડિયા ક્વેરીમાં લપેટો. જો વપરાશકર્તાએ તેમના ઓપરેટિંગ સિસ્ટમને મોશન ઘટાડવા માટે કહ્યું હોય, તો તેમને ત્વરિત ટેક્સ્ટ ફેરફાર અથવા સૂક્ષ્મ ઓપેસિટી ફેડ (opacity fade) આપો. કોઈ બાઉન્સ નહીં, કોઈ સ્પિન નહીં, કોઈ સ્વીપિંગ સ્લાઇડ્સ નહીં. રિડ્યુસ્ડ મોશનનો અર્થ ઓછો અર્થ નથી.
એક સ્થિર પેટર્ન જે કામ કરે છે
શ્રેષ્ઠ પેટર્ન કંટાળાજનક હોય છે, અને તે જ તેનો મુખ્ય હેતુ છે.
પ્રથમ રેન્ડરથી જ મેસેજ માટે જગ્યા અનામત રાખો. બટનની બરાબર નીચે એક નાનું, દ્રશ્ય રીતે ખાલી કન્ટેનર મૂકો. તેને ફિક્સ્ડ અથવા લઘુત્તમ ઊંચાઈ આપો જેથી ટેક્સ્ટ દાખલ કરવાથી પછીનું સેક્શન નીચે ધકેલાય નહીં. ગ્લોબલ ટોસ્ટનો ઉપયોગ કરવાને બદલે ફીડબેક બટન પૂરતું જ મર્યાદિત રાખો. ટોસ્ટ સિસ્ટમ-વાઈડ ભૂલો માટે ઉપયોગી છે, પરંતુ સામાન્ય ઇમેઇલ કન્ફર્મેશન માટે તે ધ્યાન વિખેરી નાખે છે અને આંખોને ફરવા માટે મજબૂર કરે છે.
ન્યૂનતમ હલનચલનનો ઉપયોગ કરો. જો તમારે એનિમેટ કરવું જ પડે, તો ટ્રાન્ઝિશનને બસો મિલીસેકન્ડથી ઓછું રાખો અને તેને ઓપેસિટી અથવા સોફ્ટ કલર શિફ્ટ પૂરતું મર્યાદિત રાખો. એવા બ્લોક-લેવલ એલિમેન્ટ્સ ઉમેરવાનું અથવા દૂર કરવાનું ટાળો જે લેઆઉટ રીકેલ્ક્યુલેશન માટે મજબૂર કરે છે. જો તમારે બટનની અંદર જ લોડિંગ સ્ટેટ બતાવવાની જરૂર હોય, તો સાદા ટેક્સ્ટ સ્વેપ અથવા સ્ટેટિક આઇકોનનો ઉપયોગ કરો. બટનને સ્કેલ કરશો નહીં, તેને ધ્રુજાવશો નહીં અને સ્ક્રીનને ફ્લેશ કરશો નહીં.
જ્યારે સક્સેસ સ્ટેટ આવે, ત્યારે એક ટૂંકો, ટકી રહે તેવો સંકેત દેખાતો રાખો. "તમારા ઇનબોક્સ તપાસો" પૂરતું છે. તેને ત્રણ સેકન્ડ પછી ઓટો-ડિસમિસ કરશો નહીં. જે વપરાશકર્તા ખોટા સમયે બીજી તરફ જોઈ રહ્યો હોય, તેણે શું થયું તે વિશે વિચારવું ન પડે.
આ શા માટે ખરેખર કલાકો બચાવે છે
જ્યારે તમે આ નાની વિગતો સુધારો છો, ત્યારે તમે વાસ્તવિક પરિણામો જુઓ છો જેનો તમારા ઇન્ફ્રાસ્ટ્રક્ચર બજેટ સાથે કોઈ લેવાદેવા નથી.
એક જ બટન પર ઓછા ડબલ ક્લિક્સ. ડિસેબલ સ્ટેટ અને લોકલ ફીડબેક સ્પષ્ટ કરે છે કે પહેલું ક્લિક નોંધાયું છે.
સેન્ડ પર ક્લિક કર્યા પછી ઓછા વપરાશકર્તાઓ ફ્લો છોડી દે છે. શાંત સંકેતો મગજને જણાવે છે કે સિસ્ટમ કામ કરી રહી છે, તેથી વપરાશકર્તાઓ સ્થિર રહે છે.
ઇમેઇલ આવ્યો નથી તેવા દાવા સાથેની ઓછી સપોર્ટ ટિકિટો, જ્યારે તે ખરેખર આવ્યો હોય. તેમાંથી મોટાભાગની ટિકિટો ઇન્ટરફેસ પેનિકથી શરૂ થાય છે, મિસિંગ મેઇલથી નહીં.
ઝડપી અનુભવાતી કામગીરી (perceived performance). એક સ્થિર UI હંમેશા અસ્તવ્યસ્ત UI કરતા ઝડપી લાગે છે, ભલે લેટન્સી સમાન હોય.
આને ટ્રેક કરવા માટે તમારે જટિલ સાધનોની જરૂર નથી. ડુપ્લીકેટ રિક્વેસ્ટ્સ માટે તમારા એરર લોગ્સ પર નજર રાખો. તમારી સપોર્ટ ક્યુ (support queue) સાંભળો. કન્ફર્મેશન સ્ક્રીન પર સાદા રિટેન્શન દ્વારા વપરાશકર્તાની સ્થિરતા માપો. એક શાંત, અનુમાનિત ઇન્ટરફેસ સંકેત આપે છે કે સિસ્ટમને ખબર છે કે તે શું કરી રહી છે. તે અનુમાનક્ષમતા જ વિશ્વાસ કેળવે છે.