ನೀವು ಎಂಡ್ಪಾಯಿಂಟ್ ಅನ್ನು ಆಪ್ಟಿಮೈಸ್ ಮಾಡಿದ್ದೀರಿ. ನಿಮ್ಮ resend-email API ಅರ್ಧ ಸೆಕೆಂಡಿಗಿಂತ ಕಡಿಮೆ ಸಮಯದಲ್ಲಿ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ. ಆದರೂ ಬಳಕೆದಾರರು ಲಿಂಕ್ ಎಂದಿಗೂ ತಲುಪಿಲ್ಲ ಎಂದು ಹೇಳುತ್ತಾ ಸಪೋರ್ಟ್ ಟಿಕೆಟ್ಗಳನ್ನು ತೆರೆಯುತ್ತಿದ್ದಾರೆ. ಅವರು ಎರಡು ಬಾರಿ ಕ್ಲಿಕ್ ಮಾಡುತ್ತಾರೆ. ಇನ್ಬಾಕ್ಸ್ ಪರಿಶೀಲಿಸುವ ಮೊದಲೇ ಅವರು ಪ್ರಕ್ರಿಯೆಯನ್ನು ಅರ್ಧಕ್ಕೆ ಬಿಡುತ್ತಾರೆ. ಏನೋ ಒಂದು ತಾಂತ್ರಿಕ ದೋಷವಿರುವಂತೆ ಭಾಸವಾಗುತ್ತಿದೆ.
ಈ ವ್ಯತ್ಯಾಸವು ಹೆಚ್ಚಾಗಿ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿರುತ್ತದೆ, ಇನ್ಫ್ರಾಸ್ಟ್ರಕ್ಚರ್ನಲ್ಲಿಲ್ಲ. ಬ್ಯಾಕೆಂಡ್ 400 ಮಿಲಿಸೆಕೆಂಡ್ಗಳಲ್ಲಿ 200 OK ಅನ್ನು ನೀಡಬಹುದು, ಆದರೆ ಫ್ರಂಟ್ಎಂಡ್ ಜಿಗಿಯುವ ಲೇಔಟ್ ಮತ್ತು ಫ್ಲ್ಯಾಶ್ ಆಗುವ ಬ್ಯಾನರ್ನೊಂದಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸಿದರೆ, ಬಳಕೆದಾರರಿಗೆ ಅದು ವಿಫಲವಾದಂತೆಯೇ ಅನಿಸುತ್ತದೆ. ಒಬ್ಬ ವ್ಯಕ್ತಿಯು ಬಟನ್ ಕ್ಲಿಕ್ ಮಾಡಿದಾಗ ಪರದೆ ಅವರ ಕರ್ಸರ್ ಅಡಿಯಲ್ಲಿ ಚಲಿಸಿದರೆ, ಅವರು ಫೀಡ್ಬ್ಯಾಕ್ ಲೂಪ್ ಅಥವಾ ನೆಟ್ವರ್ಕ್ ಲೇಟೆನ್ಸಿಯ ಬಗ್ಗೆ ಯೋಚಿಸುವುದಿಲ್ಲ. ಆಪ್ ಕೆಟ್ಟುಹೋಗಿದೆ ಎಂದು ಅವರು ಭಾವಿಸುತ್ತಾರೆ.
ನಿಜವಾದ ಸಮಸ್ಯೆ ಅಪರೂಪಕ್ಕೆ ವೇಗಕ್ಕೆ ಸಂಬಂಧಿಸಿರುತ್ತದೆ
React ತಂಡಗಳು ಹೆಚ್ಚಾಗಿ ಇಮೇಲ್ ಕನ್ಫರ್ಮೇಷನ್ ಅನ್ನು ಒಂದು ಸರಳ ಸ್ಟೇಟ್ ಮೆಷಿನ್ ಆಗಿ ಪರಿಗಣಿಸುತ್ತವೆ: idle, loading, success, error. ಕಾಂಪೊನೆಂಟ್ ಒಂದು mutation ಅನ್ನು ಚಾಲನೆ ಮಾಡುತ್ತದೆ, isLoading ಅನ್ನು true ಎಂದು ಸೆಟ್ ಮಾಡುತ್ತದೆ, ನಂತರ promise ಪರಿಹ resolves ಆದಾಗ ಸಂದೇಶವನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ. ಈ ಬದಲಾವಣೆಯೇ ಅಸಲಿ ಸಮಸ್ಯೆಯನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ. ಬ್ರೌಸರ್ ಲೇಔಟ್ ಅನ್ನು ಮರುಹೋಲಿಕೆ ಮಾಡುತ್ತದೆ, ಬಾಧಿತ ಪ್ರದೇಶವನ್ನು ಮರುಚಿತ್ತಿಸುತ್ತದೆ (repaints), ಮತ್ತು ಕೆಲವೊಮ್ಮೆ ಇಡೀ ಕಾರ್ಡ್ ಅಥವಾ ಪೇಜ್ ಅನ್ನು ಮರುಹೊಂದಿಸುತ್ತದೆ (reflows). ಬಳಕೆದಾರರು ಸ್ಥಿರತೆಯನ್ನು ನಿರೀಕ್ಷಿಸಿದ ಜಾಗದಲ್ಲಿ ಚಲನೆಯನ್ನು ನೋಡುತ್ತಾರೆ. ಅವರಿಗೆ, ಅಪ್ಲಿಕೇಶನ್ ಆ ಕ್ರಿಯೆಯನ್ನು ಖಚಿತಪಡಿಸಿಲ್ಲ; ಬದಲಾಗಿ ಅದು ನಡುಗಿದಂತೆ ಭಾಸವಾಗುತ್ತದೆ.
ಇದೇ ಕಾರಣಕ್ಕೆ ಸಮಯಕ್ಕಿಂತ ಗ್ರಹಿಕೆ (perception) ಹೆಚ್ಚು ಮುಖ್ಯವಾಗುತ್ತದೆ. ನೂರು ಮಿಲಿಸೆಕೆಂಡ್ಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ ಅಸ್ಥಿರ ಇಂಟರ್ಫೇಸ್ನಿಗಿಂತ, ಐದು ನೂರು ಮಿಲಿಸೆಕೆಂಡ್ಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುವ ಸ್ಥಿರ ಇಂಟರ್ಫೇಸ್ ವೇಗವಾಗಿ ಮತ್ತು ಸುರಕ್ಷಿತವಾಗಿ ಅನಿಸುತ್ತದೆ. ಬಳಕೆದಾರರಿಗೆ ಲೇಟೆನ್ಸಿಯನ್ನು ಅಳೆಯಲು ಸಾಧ್ಯವಿಲ್ಲ, ಆದರೆ ಅವರು ವಿಶ್ವಾಸವನ್ನು ಅಳೆಯಬಲ್ಲರು. UI ಅಲುಗಾಡಿದಾಗ, ಅವರ ವಿನಂತಿಯೂ (request) ಅಲುಗಾಡಿದೆ ಎಂದು ಅವರು ಭಾವಿಸುತ್ತಾರೆ.
ಕೆಟ್ಟ ಫೀಡ್ಬ್ಯಾಕ್ ವಿಶ್ವಾಸವನ್ನು ಕುಂದಿಸುವ ಮೂರು ಮಾರ್ಗಗಳು
ಸರಿಯಾದ ಕನ್ಫರ್ಮೇಷನ್ ಫೀಡ್ಬ್ಯಾಕ್ ಇಲ್ಲದಿರುವುದು ಸಾಮಾನ್ಯವಾಗಿ ಮೂರು ಬಲೆಗಳಲ್ಲಿ ಬೀಳುತ್ತದೆ; ನೀವು ಏನನ್ನು ಗಮನಿಸಬೇಕು ಎಂದು ತಿಳಿದಿದ್ದರೆ ಇದನ್ನು ಸುಲಭವಾಗಿ ಗುರುತಿಸಬಹುದು.
ದೂರ (Distance). ಬಳಕೆದಾರರು ಫಾರ್ಮ್ನ ಕೆಳಭಾಗದಲ್ಲಿ ಕ್ಲಿಕ್ ಮಾಡಿದಾಗ, ಯಶಸ್ಸಿನ ಸಂದೇಶವು ಫಾರ್ಮ್ನ ಮೇಲ್ಭಾಗದಲ್ಲಿರುವ ಗ್ಲೋಬಲ್ ಬ್ಯಾನರ್ನಲ್ಲಿ ಕಾಣಿಸಿಕೊಂಡರೆ, ಅದು ದೃಶ್ಯದ ಏಕತೆಯನ್ನು ಮುರಿಯುತ್ತದೆ. ಕಣ್ಣು ಅತ್ತ ಕಡೆ ಹೋಗುತ್ತದೆ; ಕೈ ಕಾಯುತ್ತದೆ; ಕ್ಲಿಕ್ ತಪ್ಪಾಗಿದೆ ಎಂದು ಮೆದುಳು ಭಾವಿಸುತ್ತದೆ. ಫೀಡ್ಬ್ಯಾಕ್ ಎಂಬುದು ಆ ಕ್ರಿಯೆಯನ್ನು ಪ್ರಚೋದಿಸಿದ ಅದೇ ಪ್ರದೇಶದಲ್ಲಿ ಇರಬೇಕು.
ಗದ್ದಲ (Noise). ಶೂನ್ಯದಿಂದ ಪೂರ್ಣ ಗಾತ್ರಕ್ಕೆ ಬೆಳೆಯುವ ಸ್ಪಿನ್ನರ್ಗಳು, ಜಿಗಿಯುವ ಚೆಕ್ಮಾರ್ಕ್ಗಳು ಅಥವಾ ಸಾಮಾನ್ಯ ಇಮೇಲ್ ಕಳುಹಿಸುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸಂಭ್ರಮಿಸಲು ಬರುವ ಮಾಡಲ್ಗಳು (modals) ಅನಗತ್ಯ ಗಮನವನ್ನು ಸೆಳೆಯುತ್ತವೆ. ಅವು ಒಂದು ಸರಳ ಕನ್ಫರ್ಮೇಷನ್ ಅನ್ನು ನಾಟಕೀಯ ಪ್ರದರ್ಶನವನ್ನಾಗಿ ಮಾಡುತ್ತವೆ. ವೆಸ್ಟಿಬ್ಯುಲರ್ ಡಿಸಾರ್ಡರ್ಸ್ (vestibular disorders) ಇರುವ ಬಳಕೆದಾರರಿಗೆ, ಅತಿಯಾದ ಚಲನೆಯು ಕೇವಲ ಕಿರಿಕಿರಿ ಮಾತ್ರವಲ್ಲ, ದೈಹಿಕ ಅಸ್ವಸ್ಥತೆಯನ್ನು ಕೂಡ ಉಂಟುಮಾಡುತ್ತದೆ.
ಲೇಔಟ್ ಶಿಫ್ಟ್ (Layout shift). ಒಂದು ಬಟನ್ ಕೆಳಗೆ ಹೊಸ ಪ್ಯಾರಾಗ್ರಾಫ್ ಅನ್ನು ಸೇರಿಸುವುದು ಮುಂದಿನ ಫಾರ್ಮ್ ಫೀಲ್ಡ್ ಅನ್ನು ಕೆಳಕ್ಕೆ ತಳ್ಳುತ್ತದೆ. ಫೂಟರ್ ಚಲಿಸುತ್ತದೆ. ಕಂಟೆಂಟ್ ತನ್ನ ಸ್ಥಾನವನ್ನು ಬದಲಾಯಿಸಿಕೊಳ್ಳುತ್ತದೆ. ಇದು ಬಳಕೆಯ ಸುಲಭತೆ (usability) ಮತ್ತು ಸುಲಭ ಲಭ್ಯತೆಯನ್ನು (accessibility) ಸಮಾನವಾಗಿ ಹಾನಿಗೊಳಿಸುತ್ತದೆ. ಸ್ವಿಚ್ ಸಾಧನ ಅಥವಾ ನಿಖರವಾದ ಐ-ಟ್ರ್ಯಾಕಿಂಗ್ ಬಳಸುವ ವ್ಯಕ್ತಿಯು ಮುಂದಿನ ಗುರಿಯತ್ತ ಚಲಿಸಲು ಪ್ರಾರಂಭಿಸಿದಾಗ, ಅದು ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಸ್ಥಳಾಂತರಗೊಂಡರೆ ಅವರಿಗೆ ತೊಂದರೆಯಾಗುತ್ತದೆ. ನಿಮ್ಮ ಬ್ಯಾಕೆಂಡ್ 400ms ನಲ್ಲಿ ಪ್ರತಿಕ್ರಿಯಿಸಿದರೂ ಸಹ, ಅಸ್ಥಿರ UI ಪ್ರಕ್ರಿಯೆಯನ್ನು ನಿಧಾನ ಮತ್ತು ಅಸುರಕ್ಷಿತವಾಗಿ ಕಾಣುವಂತೆ ಮಾಡುತ್ತದೆ. ನಿಮ್ಮ ಆಪ್ ಶಾಂತವಾದ, ಸ್ಪಷ್ಟವಾದ ಸಂಕೇತಗಳನ್ನು ನೀಡಲು ವಿಫಲವಾದರೆ, ಬಳಕೆದಾರರು ತಮ್ಮ ಇನ್ಬಾಕ್ಸ್ ಅನ್ನು ಮ್ಯಾನುಯಲ್ ಆಗಿ ತೆರೆಯಬಹುದು.
ಪ್ರಕ್ರಿಯೆಯನ್ನು ಒಂದು ಓದುವ ಕ್ರಮವಾಗಿ (Reading Sequence) ಮರುಚಿಂತಿಸಿ
ಇಮೇಲ್ ಕನ್ಫರ್ಮೇಷನ್ ಅನ್ನು ಕೇವಲ ಲೋಡಿಂಗ್ ಮತ್ತು ಸಕ್ಸಸ್ ಸ್ಟೇಟ್ಗಳ ನಡುವಿನ ಬದಲಾವಣೆಯಾಗಿ ನೋಡುವುದನ್ನು ನಿಲ್ಲಿಸಿ. ಬಳಕೆದಾರರು ಒಂದೇ ನೋಟದಲ್ಲಿ ಗ್ರಹಿಸುವ ಒಂದು ಓದುವ ಕ್ರಮವಾಗಿ ಇದನ್ನು ನೋಡಿ. ನಿಮ್ಮನ್ನು ನೀವು ಈ ನಾಲ್ಕು ನಿರ್ದಿಷ್ಟ ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳಿಕೊಳ್ಳಿ.
ಕ್ಲಿಕ್ ಮಾಡಿದ ತಕ್ಷಣ ವ್ಯಕ್ತಿಯು ಏನನ್ನು ನೋಡುತ್ತಾನೆ? ಉತ್ತರ 'ಏನೂ ಇಲ್ಲ' ಎಂದಾಗ ಅಥವಾ ಬಟನ್ ಸುಮ್ಮನೆ ಫ್ರೀಜ್ ಆದಾಗ, ನೀವು ಈಗಾಗಲೇ ಅವರನ್ನು ಕಳೆದುಕೊಂಡಿದ್ದೀರಿ ಎಂದರ್ಥ. ಸಿಸ್ಟಮ್ ಇನ್ಪುಟ್ ಅನ್ನು ಸ್ವೀಕರಿಸಿದೆ ಎಂದು ತಿಳಿಸುವ ತಕ್ಷಣದ, ಸ್ಥಳೀಯ ಬದಲಾವಣೆ ಇರಲೇಬೇಕು.
ಸ್ಕ್ರೀನ್ ರೀಡರ್ ಏನು ಘೋಷಿಸುತ್ತದೆ? ವಿನಯಪೂರ್ವಕವಾದ, ಅಡ್ಡಿಪಡಿಸದ ಅಪ್ಡೇಟ್ ಬಳಕೆದಾರರಿಗೆ ಅವರ ಪ್ರಸ್ತುತ ಸಂದರ್ಭವನ್ನು ಅಡ್ಡಿಯಿಲ್ಲದೆ ಮುಂದುವರಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ. ಆ ಘೋಷಣೆಯು ಸೈರನ್ನಂತೆ ಇರಬಾರದು, ಬದಲಾಗಿ ಒಂದು ಫುಟ್ನೋಟ್ನಂತೆ ಇರಬೇಕು.
ಕಾಯುವ ಸಮಯದಲ್ಲಿ ಲೇಔಟ್ ಎಷ್ಟು ಚಲಿಸುತ್ತದೆ? ಆದರ್ಶಪ್ರಾಯವಾಗಿ, ಶೂನ್ಯವಾಗಿರಬೇಕು. ಬಳಕೆದಾರರು ಬರುವ ಮೊದಲೇ ಕಾಯುವ ಸ್ಥಿತಿಗಾಗಿ (waiting state) ಮೀಸಲಿಟ್ಟ ಸ್ಥಳದಲ್ಲಿಯೇ ಅದು ಇರಬೇಕು.
ಇಮೇಲ್ ಬರಲು ಸಮಯ ತಗೆದುಕೊಂಡರೆ ಯಾವ ಸೂಚನೆ ಕಾಣಿಸುತ್ತಿರುತ್ತದೆ? ನೆಟ್ವರ್ಕ್ ಸಮಸ್ಯೆಗಳು ಉಂಟಾಗಬಹುದು. ವಿನಂತಿಯು ಕೆಲವು ಸೆಕೆಂಡ್ಗಳಿಗಿಂತ ಹೆಚ್ಚು ಸಮಯ ತಗೆದುಕೊಂಡರೆ, ಏನೋ ಒಂದು ನಡೆಯುತ್ತಿದೆ ಎಂದು ಬಳಕೆದಾರರಿಗೆ ತಿಳಿಯುತ್ತದೆಯೇ ಅಥವಾ ಆ ಮೌನವು ಅವರನ್ನು ಗಾಬರಿಗೊಳಿಸುತ್ತದೆಯೇ? ಒಂದು ನಿರಂತರವಾದ, ಶಾಂತವಾದ ಸೂಚಕವು (indicator) ಗಾಬರಿಯನ್ನು ತಡೆಯುತ್ತದೆ.
ಶಾಂತವಾದ ಕನ್ಫರ್ಮೇಷನ್ ಫೀಡ್ಬ್ಯಾಕ್ಗಾಗಿ ನಾಲ್ಕು ನಿಯಮಗಳು
ಈ ನಾಲ್ಕು ಪ್ರಾಯೋಗಿಕ ನಿಯಮಗಳನ್ನು ಅನುಸರಿಸುವ ಮೂಲಕ ನೀವು ಹೆಚ್ಚಿನ ಕನ್ಫರ್ಮೇಷನ್ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಸರಿಪಡಿಸಬಹುದು.
ಸಂದೇಶವನ್ನು ಕ್ರಿಯೆಯ ಸಮೀಪದ ಸ್ಥಿರ ಪ್ರದೇಶದಲ್ಲಿ ಇರಿಸಿ. ಫೀಡ್ಬ್ಯಾಕ್ ಅಗತ್ಯವಾಗುವ ಮೊದಲೇ ಅದಕ್ಕಾಗಿ ಜಾಗವನ್ನು ಮೀಸಲಿಡಿ. ನಿರ್ದಿಷ್ಟ min-height ಹೊಂದಿರುವ ಕಂಟೈನರ್ ಅಥವಾ ಸಂದೇಶದ ಸ್ಲಾಟ್ ಅನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವ CSS grid row ಅನ್ನು ಬಳಸಿ. ಪಠ್ಯವು ಕಾಣಿಸಿಕೊಂಡಾಗ, ಅದು ಸುತ್ತಮುತ್ತಲಿನ ಕಂಟೆಂಟ್ ಅನ್ನು ತಳ್ಳಬಾರದು. ಕನ್ಫರ್ಮೇಷನ್ ಎಂಬುದು ಆ ಕ್ರಿಯೆ ನಡೆದ ಸ್ಥಳದಲ್ಲೇ ಇರಬೇಕು.
ಸುಲಭ ಲಭ್ಯತೆಗಾಗಿ (accessibility) role="status" ಅನ್ನು aria-live="polite" ನೊಂದಿಗೆ ಬಳಸಿ. ನಿಮ್ಮ ಮಾರ್ಕಪ್ನಲ್ಲಿ ಮೊದಲಿನಿಂದಲೇ ಇರುವ ಒಂದು 'ಲೈವ್ ರೀಜನ್' ಅನ್ನು ರಚಿಸಿ. ಸ್ಟೇಟ್ (state) ಬದಲಾದಾಗ, React ಆ ರೀಜನ್ನ ಒಳಗಿರುವ ಟೆಕ್ಸ್ಟ್ ನೋಡ್ ಅನ್ನು ಅಪ್ಡೇಟ್ ಮಾಡುತ್ತದೆ. ಸ್ಕ್ರೀನ್ ರೀಡರ್ಗಳು ಕೀಬೋರ್ಡ್ ಫೋಕಸ್ ಅನ್ನು ಕದಿಯದೆ ಅಥವಾ ಬಳಕೆದಾರರಿಗೆ ಅಡ್ಡಿಪಡಿಸದೆ ಬದಲಾವಣೆಯನ್ನು ತಿಳಿಸುತ್ತವೆ. ಸಾಮಾನ್ಯ ದೃಢೀಕರಣಕ್ಕಾಗಿ (routine confirmation) ಎಂದಿಗೂ aria-live="assertive" ಅನ್ನು ಬಳಸಬೇಡಿ. ಇದು ಕಿರುಚಾಡಿದಂತೆ ಇರುತ್ತದೆ.
ಬಟನ್ ಅನ್ನು ಅನ್ಮೌಂಟ್ (unmount) ಮಾಡಬೇಡಿ. ಸಂದೇಶವನ್ನು ತೋರಿಸಲು ನೀವು ಬಟನ್ ಅನ್ನು DOM ನಿಂದ ತೆಗೆದುಹಾಕಿದಾಗ, ಕೀಬೋರ್ಡ್ ಬಳಕೆದಾರರು ಗೊಂದಲಕ್ಕೀಡಾಗುತ್ತಾರೆ. ಅವರ ಫೋಕಸ್ ಮಾಯವಾಗುತ್ತದೆ. ಸ್ಕ್ರೀನ್ ರೀಡರ್ಗಳು ಅನಿಶ್ಚಿತ ಅಂಶಗಳ ಮೇಲೆ ತಲುಪುತ್ತವೆ. ಬದಲಾಗಿ, ಬಟನ್ ಅನ್ನು ಮೌಂಟ್ ಆಗಿಯೇ ಇರಿಸಿ. aria-disabled ಬಳಸಿ ಅದನ್ನು ಡಿಸೇಬಲ್ ಮಾಡಿ, ಅದರ ಲೇಬಲ್ ಅನ್ನು "Sending..." ಅಥವಾ "Sent," ಎಂದು ಬದಲಾಯಿಸಿ, ಅಥವಾ ಕೌಂಟ್ಡೌನ್ ಟೈಮರ್ನಿಂದ ಬದಲಾಯಿಸಿ. ಎಲಿಮೆಂಟ್ ಅಲ್ಲೇ ಇರುತ್ತದೆ, ಕೇವಲ ಅದರ ಸ್ಟೇಟ್ ಮಾತ್ರ ಬದಲಾಗುತ್ತದೆ.
prefers-reduced-motion ಅನ್ನು ಗೌರವಿಸಿ. ಪ್ರತಿಯೊಬ್ಬರಿಗೂ ಅನಿಮೇಷನ್ ಅಥವಾ ಸಂಭ್ರಮ ಬೇಕೆಂದಿಲ್ಲ. ಯಾವುದೇ ಟ್ರಾನ್ಸಿಶನ್ಗಳನ್ನು (transitions) ಮೀಡಿಯಾ ಕ್ವೆರಿಯಲ್ಲಿ (media query) ಇರಿಸಿ. ಬಳಕೆದಾರರು ತಮ್ಮ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ನಲ್ಲಿ ಚಲನೆಯನ್ನು (motion) ಕಡಿಮೆ ಮಾಡಲು ಕೇಳಿದ್ದರೆ, ಅವರಿಗೆ ತಕ್ಷಣದ ಪಠ್ಯ ಬದಲಾವಣೆ ಅಥವಾ ಮೃದುವಾದ ಒಪಾಸಿಟಿ ಫೇಡ್ (opacity fade) ನೀಡಿ. ಬೌನ್ಸ್, ಸ್ಪಿನ್ ಅಥವಾ ಸ್ಲೈಡ್ಗಳಿಲ್ಲದಂತೆ ನೋಡಿಕೊಳ್ಳಿ. ಚಲನೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುವುದು ಎಂದರೆ ಅದರ ಅರ್ಥವನ್ನು ಕಡಿಮೆ ಮಾಡುವುದು ಎಂದಲ್ಲ.
ಕೆಲಸ ಮಾಡುವ ಒಂದು ಸ್ಥಿರ ಮಾದರಿ
ಅತ್ಯುತ್ತಮ ಮಾದರಿಯು ನೀರಸವಾಗಿರುತ್ತದೆ, ಮತ್ತು ಅದೇ ಇದರ ಉದ್ದೇಶ.
ಮೊದಲಿನಿಂದಲೇ ಸಂದೇಶಕ್ಕಾಗಿ ಜಾಗವನ್ನು ಮೀಸಲಿಡಿ. ಬಟನ್ನ ಕೆಳಗೆ ನೇರವಾಗಿ ಒಂದು ಸಣ್ಣ, ದೃಶ್ಯವಾಗಿ ಖಾಲಿ ಇರುವ ಕಂಟೇನರ್ ಅನ್ನು ಇರಿಸಿ. ಅದಕ್ಕೆ ನಿರ್ದಿಷ್ಟ ಅಥವಾ ಕನಿಷ್ಠ ಎತ್ತರವನ್ನು ನೀಡಿ, ಇದರಿಂದ ಪಠ್ಯವು ಬರುವಾಗ ಮುಂದಿನ ವಿಭಾಗವು ಕೆಳಕ್ಕೆ ತಳ್ಳಲ್ಪಡದಂತೆ ನೋಡಿಕೊಳ್ಳಬಹುದು. ಗ್ಲೋಬಲ್ ಟೋಸ್ಟ್ (global toasts) ಬಳಸುವ ಬದಲು ಫೀಡ್ಬ್ಯಾಕ್ ಅನ್ನು ಬಟನ್ಗೆ ಹತ್ತಿರದಲ್ಲೇ ಇರಿಸಿ. ಟೋಸ್ಟ್ಗಳು ಸಿಸ್ಟಮ್ನಾದ್ಯಂತ ಆಗುವ ದೋಷಗಳಿಗೆ ಉಪಯುಕ್ತವಾಗಿವೆ, ಆದರೆ ಸಾಮಾನ್ಯ ಇಮೇಲ್ ದೃಢೀಕರಣಕ್ಕಾಗಿ ಅವು ಗಮನವನ್ನು ಚದುರಿಸುತ್ತವೆ ಮತ್ತು ಕಣ್ಣುಗಳನ್ನು ಅಲೆದಾಡಲು ಒತ್ತಾಯಿಸುತ್ತವೆ.
ಕನಿಷ್ಠ ಚಲನೆಯನ್ನು ಬಳಸಿ. ನೀವು ಅನಿಮೇಷನ್ ಮಾಡಲೇಬೇಕೆಂದಿದ್ದರೆ, ಟ್ರಾನ್ಸಿಶನ್ಗಳನ್ನು ಇನ್ನೂರು ಮಿಲಿಸೆಕೆಂಡ್ಗಳಿಗಿಂತ ಕಡಿಮೆ ಇರಿಸಿ ಮತ್ತು ಅವುಗಳನ್ನು ಒಪಾಸಿಟಿ ಅಥವಾ ಮೃದುವಾದ ಬಣ್ಣದ ಬದಲಾವಣೆಗೆ ಸೀಮಿತಗೊಳಿಸಿ. ಲೇಔಟ್ ಮರುಹಣಕೆ (layout recalculation) ಮಾಡುವಂತೆ ಬ್ಲಾಕ್-ಲೆವೆಲ್ ಎಲಿಮೆಂಟ್ಗಳನ್ನು ಸೇರಿಸುವುದನ್ನು ಅಥವಾ ತೆಗೆದುಹಾಕುವುದನ್ನು ತಪ್ಪಿಸಿ. ಬಟನ್ನ ಒಳಗೇ ಲೋಡಿಂಗ್ ಸ್ಟೇಟ್ ತೋರಿಸಬೇಕೆಂದಿದ್ದರೆ, ಸರಳ ಪಠ್ಯ ಬದಲಾವಣೆ ಅಥವಾ ಸ್ಟ್ಯಾಟಿಕ್ ಐಕಾನ್ ಬಳಸಿ. ಬಟನ್ ಅನ್ನು ಸ್ಕೇಲ್ ಮಾಡಬೇಡಿ, ಅಲ್ಲಾಡಿಸಬೇಡಿ ಮತ್ತು ಸ್ಕ್ರೀನ್ ಅನ್ನು ಫ್ಲ್ಯಾಶ್ ಮಾಡಬೇಡಿ.
ಯಶಸ್ವಿ ಸ್ಟೇಟ್ ಬಂದಾಗ, ಒಂದು ಸಣ್ಣ, ದೀರ್ಘಕಾಲ ಉಳಿಯುವ ಸೂಚನೆಯನ್ನು ಕಾಣುವಂತೆ ಮಾಡಿ. "Check your inbox" ಎಂಬುದು ಸಾಕಾಗುತ್ತದೆ. ಅದನ್ನು ಮೂರು ಸೆಕೆಂಡುಗಳ ನಂತರ ತಾನಾಗಿಯೇ ಮಾಯವಾಗುವಂತೆ (auto-dismiss) ಮಾಡಬೇಡಿ. ತಪ್ಪು ಸಮಯದಲ್ಲಿ ಬೇರೆಡೆ ನೋಡಿದ ಬಳಕೆದಾರರು ಏನಾಯಿತು ಎಂದು ಯೋಚಿಸಬೇಕಾದ ಅಗತ್ಯವಿರಬಾರದು.
ಇದು ನಿಜವಾಗಿಯೂ ಸಮಯವನ್ನು ಹೇಗೆ ಉಳಿಸುತ್ತದೆ
ನೀವು ಈ ಸಣ್ಣ ವಿವರಗಳನ್ನು ಸರಿಪಡಿಸಿದಾಗ, ನಿಮ್ಮ ಮೂಲಸೌಕರ್ಯ ಬಜೆಟ್ನೊಂದಿಗೆ ಸಂಬಂಧವಿಲ್ಲದ ನೈಜ ಫಲಿತಾಂಶಗಳನ್ನು ನೀವು ನೋಡುತ್ತೀರಿ.
ಒಂದೇ ಬಟನ್ ಮೇಲೆ ಕಡಿಮೆ ಡಬಲ್ ಕ್ಲಿಕ್ಗಳು. ಡಿಸೇಬಲ್ ಸ್ಟೇಟ್ ಮತ್ತು ಸ್ಥಳೀಯ ಫೀಡ್ಬ್ಯಾಕ್ ಮೊದಲ ಕ್ಲಿಕ್ ದಾಖಲಾಗಿರುವುದನ್ನು ಸ್ಪಷ್ಟಪಡಿಸುತ್ತದೆ.
'Send' ಕ್ಲಿಕ್ ಮಾಡಿದ ನಂತರ ಕಡಿಮೆ ಬಳಕೆದಾರರು ಪ್ರಕ್ರಿಯೆಯನ್ನು ಅರ್ಧಕ್ಕೆ ಬಿಡುತ್ತಾರೆ. ಶಾಂತ ಸಂಕೇತಗಳು ಸಿಸ್ಟಮ್ ಕೆಲಸ ಮಾಡುತ್ತಿದೆ ಎಂದು ಮೆದುಳಿಗೆ ತಿಳಿಸುತ್ತವೆ, ಆದ್ದರಿಂದ ಬಳಕೆದಾರರು ಅಲ್ಲಿಯೇ ಇರುತ್ತಾರೆ.
ಇಮೇಲ್ ಬಂದಿದ್ದರೂ ಸಹ, ಅದು ತಲುಪಲಿಲ್ಲ ಎಂದು ದೂರುವ ಸಪೋರ್ಟ್ ಟಿಕೆಟ್ಗಳು ಕಡಿಮೆಯಾಗುತ್ತವೆ. ಅಂತಹ ಹೆಚ್ಚಿನ ಟಿಕೆಟ್ಗಳು ಇಮೇಲ್ ಕಾಣೆಯಾಗಿರುವುದರಿಂದಲ್ಲ, ಬದಲಾಗಿ ಇಂಟರ್ಫೇಸ್ ಗೊಂದಲದಿಂದ (interface panic) ಪ್ರಾರಂಭವಾಗುತ್ತವೆ.
ವೇಗವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಅನುಭವ. ಒಂದೇ ರೀತಿಯ ವಿಳಂಬತೆ (latency) ಇದ್ದರೂ ಸಹ, ಗೊಂದಲಮಯವಾದ UI ಗಿಂತ ಸ್ಥಿರವಾದ UI ಯಾವಾಗಲೂ ವೇಗವಾಗಿ ಅನಿಸುತ್ತದೆ.
ಇದನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಲು ನಿಮಗೆ ಸಂಕೀರ್ಣ ಪರಿಕರಗಳ ಅಗತ್ಯವಿಲ್ಲ. ಡ್ಯುಪ್ಲಿಕೇಟ್ ರಿಕ್ವೆಸ್ಟ್ಗಳಿಗಾಗಿ ನಿಮ್ಮ ಎರರ್ ಲಾಗ್ಗಳನ್ನು ಗಮನಿಸಿ. ನಿಮ್ಮ ಸಪೋರ್ಟ್ ಕ್ಯೂ ಅನ್ನು ಗಮನಿಸಿ. ಕನ್ಫರ್ಮೇಷನ್ ಸ್ಕ್ರೀನ್ನಲ್ಲಿ ಬಳಕೆದಾರರ ಸ್ಥಿರತೆಯನ್ನು (retention) ಅಳೆಯಿರಿ. ಶಾಂತವಾದ, ಮುನ್ಸೂಚನೆ ನೀಡುವ ಇಂಟರ್ಫೇಸ್ ಸಿಸ್ಟಮ್ ಏನು ಮಾಡುತ್ತಿದೆ ಎಂಬುದು ಅದಕ್ಕೆ ತಿಳಿದಿದೆ ಎಂದು ಸೂಚಿಸುತ್ತದೆ. ಆ ಮುನ್ಸೂಚನೆಯೇ ನಂಬಿಕೆಯನ್ನು ಬೆಳೆಸುತ್ತದೆ.