ਤੁਸੀਂ endpoint ਨੂੰ ਆਪਟੀਮਾਈਜ਼ ਕੀਤਾ ਹੈ। ਤੁਹਾਡੀ resend-email API ਅੱਧੇ ਸੈਕਿੰਡ ਤੋਂ ਵੀ ਘੱਟ ਸਮੇਂ ਵਿੱਚ ਜਵਾਬ ਦਿੰਦੀ ਹੈ। ਫਿਰ ਵੀ ਉਪਭੋਗਤਾ (users) ਅਜੇ ਵੀ ਸਪੋਰਟ ਟਿਕਟਾਂ ਖੋਲ੍ਹ ਰਹੇ ਹਨ ਕਿ ਲਿੰਕ ਕਦੇ ਮਿਲਿਆ ਹੀ ਨਹੀਂ। ਉਹ ਦੋ ਵਾਰ ਕਲਿੱਕ ਕਰਦੇ ਹਨ। ਉਹ ਇਨਬਾਕਸ ਚੈੱਕ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਪ੍ਰਕਿਰਿਆ (flow) ਨੂੰ ਛੱਡ ਦਿੰਦੇ ਹਨ। ਕੁਝ ਅਜੇ ਵੀ ਖਰਾਬ ਲੱਗਦਾ ਹੈ।
ਇਹ ਅਸੰਗਤਤਾ (disconnect) ਲਗਭਗ ਹਮੇਸ਼ਾ ਇੰਟਰਫੇਸ ਵਿੱਚ ਹੁੰਦੀ ਹੈ, ਇਨਫਰਾਸਟ੍ਰਕਚਰ ਵਿੱਚ ਨਹੀਂ। ਇੱਕ backend 400 ਮਿਲੀਸੈਕਿੰਡ ਵਿੱਚ 200 OK ਵਾਪਸ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਜੇਕਰ frontend ਇੱਕ ਉਛਲਦੇ ਹੋਏ layout ਅਤੇ ਇੱਕ ਚਮਕਦੇ ਹੋਏ ਬੈਨਰ ਨਾਲ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਉਪਭੋਗਤਾ ਨੂੰ ਫਿਰ ਵੀ ਅਸਫਲਤਾ ਦਾ ਅਹਿਸਾਸ ਹੁੰਦਾ ਹੈ। ਜਦੋਂ ਕੋਈ ਵਿਅਕਤੀ ਬਟਨ 'ਤੇ ਕਲਿੱਕ ਕਰਦਾ ਹੈ ਅਤੇ ਸਕ੍ਰੀਨ ਉਸਦੇ ਕਰਸਰ ਦੇ ਹੇਠਾਂ ਖਿਸਕ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਉਹ feedback loops ਜਾਂ network latency ਬਾਰੇ ਨਹੀਂ ਸੋਚਦੇ। ਉਹ ਸੋਚਦੇ ਹਨ ਕਿ ਐਪ ਖਰਾਬ ਹੋ ਗਈ ਹੈ।
ਅਸਲ ਸਮੱਸਿਆ ਬਹੁਤ ਘੱਟ ਹੀ ਰਫਤਾਰ ਹੁੰਦੀ ਹੈ
React ਟੀਮਾਂ ਅਕਸਰ ਈਮੇਲ ਕਨਫਰਮੇਸ਼ਨ ਨੂੰ ਇੱਕ ਸਧਾਰਨ state machine ਵਜੋਂ ਮੰਨਦੀਆਂ ਹਨ: idle, loading, success, error। ਕੰਪੋਨੈਂਟ ਇੱਕ mutation ਚਲਾਉਂਦਾ ਹੈ, isLoading ਨੂੰ true 'ਤੇ ਸੈੱਟ ਕਰਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਜਦੋਂ promise ਹੱਲ (resolve) ਹੋ ਜਾਂਦਾ ਹੈ ਤਾਂ ਇੱਕ ਸੁਨੇਹਾ ਦਿਖਾਉਂਦਾ ਹੈ। ਉਹ ਬਦਲਾਅ (swap) ਹੀ ਉਹ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ ਨੁਕਸਾਨ ਹੁੰਦਾ ਹੈ। ਬ੍ਰਾਊਜ਼ਰ layout ਦੀ ਮੁੜ-ਗਣਨਾ ਕਰਦਾ ਹੈ, ਪ੍ਰਭਾਵਿਤ ਖੇਤਰ ਨੂੰ ਦੁਬਾਰਾ ਰੰਗਦਾ (repaint) ਹੈ, ਅਤੇ ਕਦੇ-ਕਦੇ ਪੂਰੇ ਕਾਰਡ ਜਾਂ ਪੇਜ ਨੂੰ reflow ਕਰਦਾ ਹੈ। ਉਪਭੋਗਤਾ ਉੱਥੇ ਹਲਚਲ ਦੇਖਦਾ ਹੈ ਜਿੱਥੇ ਉਹ ਸ਼ਾਂਤੀ ਦੀ ਉਮੀਦ ਕਰ ਰਿਹਾ ਸੀ। ਉਹਨਾਂ ਲਈ, ਐਪਲੀਕੇਸ਼ਨ ਨੇ ਕਾਰਵਾਈ ਦੀ ਪੁਸ਼ਟੀ ਨਹੀਂ ਕੀਤੀ। ਇਹ ਤਾਂ ਅਚਾਨਕ ਹਿੱਲ ਗਈ।
ਇਸੇ ਕਰਕੇ ਸਮਾਂ (timing) ਨਾਲੋਂ ਅਹਿਸਾਸ (perception) ਜ਼ਿਆਦਾ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ। ਇੱਕ ਸਥਿਰ ਇੰਟਰਫੇਸ ਜੋ ਪੰਜ ਸੌ ਮਿਲੀਸੈਕਿੰਡ ਲੈਂਦਾ ਹੈ, ਇੱਕ ਅਸਥਿਰ ਇੰਟਰਫੇਸ ਨਾਲੋਂ ਤੇਜ਼ ਅਤੇ ਸੁਰੱਖਿਅਤ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ ਜੋ ਸਿਰਫ ਦੋ ਸੌ ਮਿਲੀਸੈਕਿੰਡ ਲੈਂਦਾ ਹੈ। ਉਪਭੋਗਤਾ latency ਨੂੰ ਮਾਪ ਨਹੀਂ ਸਕਦੇ, ਪਰ ਉਹ ਭਰੋਸੇ ਨੂੰ ਮਾਪ ਸਕਦੇ ਹਨ। ਜਦੋਂ UI ਡੋਲਦਾ ਹੈ, ਤਾਂ ਉਹ ਮੰਨ ਲੈਂਦੇ ਹਨ ਕਿ ਬੇਨਤੀ (request) ਵੀ ਉਸਦੇ ਨਾਲ ਡੋਲ ਗਈ ਹੈ।
ਤਿੰਨ ਤਰੀਕੇ ਜਿਨ੍ਹਾਂ ਨਾਲ ਮਾੜਾ feedback ਭਰੋਸਾ ਘਟਾਉਂਦਾ ਹੈ
ਮਾੜਾ ਕਨਫਰਮੇਸ਼ਨ feedback ਆਮ ਤੌਰ 'ਤੇ ਤਿੰਨ ਅਜਿਹੇ ਜਾਲਾਂ ਵਿੱਚ ਫਸਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਪਛਾਣਨਾ ਆਸਾਨ ਹੈ ਜੇਕਰ ਤੁਹਾਨੂੰ ਪਤਾ ਹੋਵੇ ਕਿ ਕੀ ਦੇਖਣਾ ਹੈ।
ਦੂਰੀ (Distance)। ਇੱਕ ਸਫਲਤਾ ਸੁਨੇਹਾ ਜੋ ਫਾਰਮ ਦੇ ਸਿਖਰ 'ਤੇ ਇੱਕ ਗਲੋਬਲ ਬੈਨਰ ਵਿੱਚ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਉਪਭੋਗਤਾ ਨੇ ਹੇਠਾਂ ਦੇ ਨੇੜੇ ਕਲਿੱਕ ਕੀਤਾ ਸੀ, ਵਿਜ਼ੂਅਲ ਲੜੀ ਨੂੰ ਤੋੜ ਦਿੰਦਾ ਹੈ। ਅੱਖ ਸਫ਼ਰ ਕਰਦੀ ਹੈ; ਹੱਥ ਉਡੀਕ ਕਰਦਾ ਹੈ; ਦਿਮਾਗ ਮੰਨ ਲੈਂਦਾ ਹੈ ਕਿ ਕਲਿੱਕ ਗਲਤ ਹੋ ਗਿਆ। Feedback ਉਸੇ ਇਲਾਕੇ ਵਿੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿੱਥੇ ਉਹ ਕਾਰਵਾਈ ਹੋਈ ਸੀ ਜਿਸ ਨੇ ਇਸਨੂੰ ਸ਼ੁਰੂ ਕੀਤਾ।
ਸ਼ੋਰ (Noise)। ਸਪਿਨਰ (Spinners) ਜੋ ਜ਼ੀਰੋ ਤੋਂ ਪੂਰੇ ਸਾਈਜ਼ ਤੱਕ ਵਧਦੇ ਹਨ, ਚੈੱਕਮਾਰਕ ਜੋ ਉਛਲਦੇ ਹਨ, ਜਾਂ ਮੋਡਲ (modals) ਜੋ ਇੱਕ ਰੁਟੀਨ ਈਮੇਲ ਭੇਜਣ ਦੀ ਖੁਸ਼ੀ ਵਿੱਚ ਫੇਡ-ਇਨ ਹੁੰਦੇ ਹਨ, ਉਹ ਸਾਰਾ ਧਿਆਨ ਖਿੱਚਦੇ ਹਨ ਜਿਸ ਦੇ ਉਹ ਹੱਕਦਾਰ ਨਹੀਂ ਹਨ। ਉਹ ਇੱਕ ਸਧਾਰਨ ਕਨਫਰਮੇਸ਼ਨ ਨੂੰ ਇੱਕ ਨਾਟਕੀ ਪ੍ਰਦਰਸ਼ਨ ਵਿੱਚ ਬਦਲ ਦਿੰਦੇ ਹਨ। ਵੈਸਟੀਬੂਲਰ (vestibular) ਵਿਕਾਰਾਂ ਵਾਲੇ ਉਪਭੋਗਤਾਵਾਂ ਲਈ, ਜ਼ਿਆਦਾ ਹਲਚਲ ਸਿਰਫ ਪਰੇਸ਼ਾਨ ਕਰਨ ਵਾਲੀ ਨਹੀਂ ਹੁੰਦੀ। ਇਹ ਸਰੀਰਕ ਤੌਰ 'ਤੇ ਅਸੁਖਾਵੀਂ ਹੁੰਦੀ ਹੈ।
ਲੇਆਉਟ ਸ਼ਿਫਟ (Layout shift)। ਇੱਕ ਬਟਨ ਦੇ ਹੇਠਾਂ ਨਵਾਂ ਪੈਰਾਗ੍ਰਾਫ ਪਾਉਣ ਨਾਲ ਅਗਲਾ ਫਾਰਮ ਫੀਲਡ ਹੇਠਾਂ ਵੱਲ ਧੱਕਿਆ ਜਾਂਦਾ ਹੈ। ਫੁੱਟਰ (footer) ਹਿੱਲ ਜਾਂਦਾ ਹੈ। ਸਕ੍ਰੀਨ ਦੇ ਹੇਠਲੇ ਹਿੱਸੇ ਦੀ ਸਮੱਗਰੀ ਆਪਣੀ ਜਗ੍ਹਾ ਬਦਲ ਲੈਂਦੀ ਹੈ। ਇਹ usability ਅਤੇ accessibility ਦੋਵਾਂ ਨੂੰ ਬਰਾਬਰ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਂਦਾ ਹੈ। ਇੱਕ ਵਿਅਕਤੀ ਜੋ switch device ਜਾਂ ਸਹੀ eye tracking ਦੀ ਵਰਤੋਂ ਕਰ ਰਿਹਾ ਹੈ, ਉਹ ਸ਼ਾਇਦ ਅਗਲੇ ਨਿਸ਼ਾਨੇ ਵੱਲ ਵਧਣਾ ਸ਼ੁਰੂ ਕਰ ਚੁੱਕਾ ਹੋਵੇ ਜਦੋਂ ਕਿ ਉਹ ਅਚਾਨਕ ਆਪਣੀ ਜਗ੍ਹਾ ਬਦਲ ਲੈਂਦਾ ਹੈ। ਭਾਵੇਂ ਤੁਹਾਡਾ backend 400ms ਵਿੱਚ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਇੱਕ ਅਸਥਿਰ UI ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਹੌਲੀ ਅਤੇ ਅਸੁਰੱਖਿਅਤ ਬਣਾ ਦਿੰਦਾ ਹੈ। ਉਪਭੋਗਤਾ ਆਪਣੇ ਇਨਬਾਕਸ ਨੂੰ ਮੈਨੂਅਲੀ ਖੋਲ੍ਹ ਸਕਦੇ ਹਨ ਕਿਉਂਕਿ ਤੁਹਾਡੀ ਐਪ ਸ਼ਾਂਤ ਅਤੇ ਸਪਸ਼ਟ ਸੰਕੇਤ ਦੇਣ ਵਿੱਚ ਅਸਫਲ ਰਹੀ।
ਪ੍ਰਕਿਰਿਆ (Flow) ਨੂੰ ਪੜ੍ਹਨ ਦੇ ਕ੍ਰਮ ਵਜੋਂ ਦੁਬਾਰਾ ਸੋਚੋ
ਈਮੇਲ ਕਨਫਰਮੇਸ਼ਨ ਨੂੰ loading ਅਤੇ success states ਦੇ ਵਿਚਕਾਰ ਇੱਕ ਟੌਗਲ ਵਜੋਂ ਦੇਖਣਾ ਬੰਦ ਕਰੋ। ਇਸਨੂੰ ਪੜ੍ਹਨ ਦੇ ਇੱਕ ਅਜਿਹੇ ਕ੍ਰਮ ਵਜੋਂ ਦੇਖੋ ਜਿਸ ਨੂੰ ਉਪਭੋਗਤਾ ਇੱਕੋ ਨਜ਼ਰ ਵਿੱਚ ਸਮਝ ਲੈਂਦਾ ਹੈ। ਆਪਣੇ ਆਪ ਨੂੰ ਚਾਰ ਖਾਸ ਸਵਾਲ ਪੁੱਛੋ।
ਕਲਿੱਕ ਕਰਨ ਤੋਂ ਤੁਰੰਤ ਬਾਅਦ ਵਿਅਕਤੀ ਕੀ ਦੇਖਦਾ ਹੈ? ਜੇਕਰ ਜਵਾਬ ਕੁਝ ਵੀ ਨਹੀਂ ਹੈ, ਜਾਂ ਜੇਕਰ ਬਟਨ ਸਿਰਫ ਫ੍ਰੀਜ਼ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਗੁਆ ਚੁੱਕੇ ਹੋ। ਇੱਕ ਤੁਰੰਤ, ਸਥਾਨਕ (local) ਬਦਲਾਅ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਦੱਸੇ ਕਿ ਸਿਸਟਮ ਨੇ ਇਨਪੁਟ ਸੁਣ ਲਿਆ ਹੈ।
ਪਹੁੰਚਯੋਗਤਾ (accessibility) ਲਈ role="status" ਨੂੰ aria-live="polite" ਦੇ ਨਾਲ ਵਰਤੋ। ਆਪਣੇ ਮਾਰਕਅੱਪ ਵਿੱਚ ਇੱਕ ਲਾਈਵ ਰੀਜਨ (live region) ਬਣਾਓ ਜੋ ਪਹਿਲੇ ਰੈਂਡਰ (render) ਤੋਂ ਹੀ ਮੌਜੂਦ ਹੋਵੇ। ਜਦੋਂ ਸਟੇਟ (state) ਬਦਲਦੀ ਹੈ, ਤਾਂ React ਉਸ ਰੀਜਨ ਦੇ ਅੰਦਰ ਟੈਕਸਟ ਨੋਡ ਨੂੰ ਅਪਡੇਟ ਕਰ ਦਿੰਦਾ ਹੈ। ਸਕ੍ਰੀਨ ਰੀਡਰ ਕੀਬੋਰਡ ਫੋਕਸ ਨੂੰ ਖੋਹੇ ਬਿਨਾਂ ਜਾਂ ਉਪਭੋਗਤਾ ਨੂੰ ਰੋਕੇ ਬਿਨਾਂ ਬਦਲਾਅ ਦੀ ਘੋਸ਼ਣਾ ਕਰਨਗੇ। ਰੁਟੀਨ ਪੁਸ਼ਟੀ (confirmation) ਲਈ ਕਦੇ ਵੀ aria-live="assertive" ਦੀ ਵਰਤੋਂ ਨਾ ਕਰੋ। ਇਹ ਚੀਖਣ ਦੇ ਬਰਾਬਰ ਹੈ।
ਬਟਨ ਨੂੰ unmount ਨਾ ਕਰੋ। ਜਦੋਂ ਤੁਸੀਂ ਸੁਨੇਹਾ ਦਿਖਾਉਣ ਲਈ ਬਟਨ ਨੂੰ DOM ਤੋਂ ਹਟਾ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਕੀਬੋਰਡ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਭੁਲੇਖਾ ਪਾਉਂਦੇ ਹੋ। ਉਹਨਾਂ ਦਾ ਫੋਕਸ ਗਾਇਬ ਹੋ ਜਾਂਦਾ ਹੈ। ਸਕ੍ਰੀਨ ਰੀਡਰ ਅਣਪਛਾਤੇ ancestors 'ਤੇ ਪਹੁੰਚ ਜਾਂਦੇ ਹਨ। ਇਸ ਦੀ ਬਜਾਏ, ਬਟਨ ਨੂੰ mounted ਰੱਖੋ। ਇਸ ਨੂੰ aria-disabled ਨਾਲ ਡਿਸੇਬਲ (disable) ਕਰੋ, ਇਸ ਦੇ ਲੇਬਲ ਨੂੰ "Sending..." ਜਾਂ "Sent" ਵਿੱਚ ਬਦਲੋ, ਜਾਂ ਇਸ ਨੂੰ ਕਾਊਂਟਡਾਊਨ ਟਾਈਮਰ ਨਾਲ ਬਦਲ ਦਿਓ। ਐਲੀਮੈਂਟ ਆਪਣੀ ਜਗ੍ਹਾ 'ਤੇ ਰਹਿੰਦਾ ਹੈ। ਸਿਰਫ਼ ਇਸ ਦੀ ਸਟੇਟ ਬਦਲਦੀ ਹੈ।
prefers-reduced-motion ਦਾ ਸਤਿਕਾਰ ਕਰੋ। ਹਰ ਕੋਈ ਜਸ਼ਨ ਨਹੀਂ ਚਾਹੁੰਦਾ। ਕਿਸੇ ਵੀ transitions ਨੂੰ media query ਵਿੱਚ ਰੱਖੋ। ਜੇਕਰ ਉਪਭੋਗਤਾ ਨੇ ਆਪਣੇ operating system ਨੂੰ motion ਘੱਟ ਕਰਨ ਲਈ ਕਿਹਾ ਹੈ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਤੁਰੰਤ ਟੈਕਸਟ ਬਦਲਾਅ ਜਾਂ ਹਲਕਾ opacity fade ਦਿਖਾਓ। ਕੋਈ bounces ਨਹੀਂ, ਕੋਈ spins ਨਹੀਂ, ਕੋਈ sweeping slides ਨਹੀਂ। ਘੱਟ motion ਦਾ ਮਤਲਬ ਘੱਟ ਮਹੱਤਵ ਨਹੀਂ ਹੈ।
ਇੱਕ ਸਥਿਰ ਪੈਟਰਨ ਜੋ ਕੰਮ ਕਰਦਾ ਹੈ
ਸਭ ਤੋਂ ਵਧੀਆ ਪੈਟਰਨ ਉਦਾਸੀਨ (boring) ਹੁੰਦਾ ਹੈ, ਅਤੇ ਇਹੀ ਇਸਦਾ ਮਕਸਦ ਹੈ।
ਪਹਿਲੇ ਰੈਂਡਰ ਤੋਂ ਹੀ ਸੁਨੇਹੇ ਲਈ ਜਗ੍ਹਾ ਰਾਖਵੀਂ ਰੱਖੋ। ਬਟਨ ਦੇ ਬਿਲਕੁਲ ਹੇਠਾਂ ਇੱਕ ਛੋਟਾ, ਵਿਜ਼ੂਅਲ ਰੂਪ ਵਿੱਚ ਖਾਲੀ container ਰੱਖੋ। ਇਸਨੂੰ ਇੱਕ fixed ਜਾਂ ਘੱਟੋ-ਘੱਟ ਉਚਾਈ ਦਿਓ ਤਾਂ ਜੋ ਟੈਕਸਟ ਆਉਣ ਨਾਲ ਅਗਲਾ ਸੈਕਸ਼ਨ ਹੇਠਾਂ ਨਾ ਧੱਕਿਆ ਜਾਵੇ। ਗਲੋਬਲ toasts ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਬਜਾਏ ਫੀਡਬੈਕ ਨੂੰ ਬਟਨ ਦੇ ਨੇੜੇ ਹੀ ਰੱਖੋ। Toasts ਸਿਸਟਮ-ਵਾਈਡ ਗਲਤੀਆਂ ਲਈ ਉਪਯੋਗੀ ਹੁੰਦੇ ਹਨ, ਪਰ ਰੁਟੀਨ ਈਮੇਲ ਪੁਸ਼ਟੀ ਲਈ ਉਹ ਧਿਆਨ ਨੂੰ ਖਿੰਡਾਉਂਦੇ ਹਨ ਅਤੇ ਅੱਖਾਂ ਨੂੰ ਦੂਰ ਤੱਕ ਜਾਣ ਲਈ ਮਜਬੂਰ ਕਰਦੇ ਹਨ।
ਘੱਟੋ-ਘੱਟ ਹਰਕਤ ਦੀ ਵਰਤੋਂ ਕਰੋ। ਜੇਕਰ ਤੁਹਾਨੂੰ animate ਕਰ