آپ نے اینڈ پوائنٹ (endpoint) کو بہتر بنا دیا ہے۔ آپ کی resend-email API آدھے سیکنڈ سے بھی کم وقت میں جواب دیتی ہے۔ اس کے باوجود صارفین اب بھی سپورٹ ٹکٹس کھول رہے ہیں کہ لنک کبھی موصول ہی نہیں ہوا۔ وہ دو بار کلک کرتے ہیں۔ وہ اپنا ان باکس چیک کرنے سے پہلے ہی عمل (flow) چھوڑ دیتے ہیں۔ کچھ نہ کچھ اب بھی خراب محسوس ہوتا ہے۔

یہ فرق تقریباً ہمیشہ انٹرفیس (interface) میں ہوتا ہے، انفراسٹرکچر (infrastructure) میں نہیں۔ ایک بیک اینڈ (backend) 400 ملی سیکنڈ میں 200 OK واپس کر سکتا ہے، لیکن اگر فرنٹ اینڈ (frontend) ایک اچھلتے ہوئے لے آؤٹ اور چمکتے ہوئے بینر کے ساتھ جواب دے، تو صارف کو پھر بھی ناکامی کا تجربہ ہوتا ہے۔ جب کوئی شخص بٹن پر کلک کرتا ہے اور اس کے کرسر کے نیچے اسکرین ہل جاتی ہے، تو وہ فیڈ بیک لوپس (feedback loops) یا نیٹ ورک لیٹنسی (network latency) کے بارے میں نہیں سوچتے۔ وہ سمجھتے ہیں کہ ایپ خراب ہو گئی ہے۔

اصل مسئلہ شاذ و نادر ہی رفتار کا ہوتا ہے

React ٹیمیں اکثر ای میل کنفرمیشن کو ایک سادہ اسٹیٹ مشین (state machine) کے طور پر لیتی ہیں: idle، loading، success، error۔ کمپوننٹ (component) ایک میوٹیشن (mutation) چلاتا ہے، isLoading کو true پر سیٹ کرتا ہے، اور پھر جب پرومس (promise) حل ہو جاتا ہے تو پیغام تبدیل کر دیتا ہے۔ یہی وہ جگہ ہے جہاں نقصان ہوتا ہے۔ براؤزر لے آؤٹ کا دوبارہ حساب لگاتا ہے، متاثرہ حصے کو دوبارہ پینٹ کرتا ہے، اور کبھی کبھی پورے کارڈ یا پیج کو ری فلو (reflow) کر دیتا ہے۔ صارف وہاں حرکت دیکھتا ہے جہاں اسے سکون کی توقع تھی۔ ان کے لیے، ایپلی کیشن نے عمل کی تصدیق نہیں کی، بلکہ وہ تڑپ اٹھی۔

یہی وجہ ہے کہ وقت سے زیادہ تاثر (perception) اہمیت رکھتا ہے۔ ایک مستحکم انٹرفیس جو پانچ سو ملی سیکنڈ لیتا ہے، ایک لرزتے ہوئے انٹرفیس سے زیادہ تیز اور محفوظ محسوس ہوتا ہے جو دو سو ملی سیکنڈ لیتا ہے۔ صارفین لیٹنسی (latency) کو نہیں ناپ سکتے، لیکن وہ اعتماد کو ناپ سکتے ہیں۔ جب UI لڑکھڑاتا ہے، تو وہ فرض کر لیتے ہیں کہ درخواست بھی اس کے ساتھ لڑکھڑا گئی ہے۔

تین طریقے جن سے ناقص فیڈ بیک اعتماد کو کمزور کرتا ہے

ناقص کنفرمیشن فیڈ بیک عام طور پر تین ایسے جالوں میں پھنستا ہے جنہیں پہچاننا آسان ہے اگر آپ کو معلوم ہو کہ کیا دیکھنا ہے۔

فاصلہ (Distance)۔ ایک کامیابی کا پیغام جو فارم کے اوپری حصے میں ایک گلوبل بینر میں ظاہر ہوتا ہے، جبکہ صارف نے نیچے کے قریب کلک کیا ہو، بصری تسلسل (visual thread) کو توڑ دیتا ہے۔ آنکھ سفر کرتی ہے؛ ہاتھ انتظار کرتا ہے؛ دماغ فرض کر لیتا ہے کہ کلک غلط ہو گیا۔ فیڈ بیک کو اسی جگہ ہونا چاہیے جہاں وہ عمل ہوا جس نے اسے متحرک کیا۔

شور (Noise)۔ اسپنرز (spinners) جو صفر سے مکمل سائز تک بڑھتے ہیں، چیک مارکس (checkmarks) جو اچھلتے ہیں، یا ماڈلز (modals) جو ایک عام ای میل بھیجنے کی خوشی میں ظاہر ہوتے ہیں، وہ سب ایسی توجہ مانگتے ہیں جس کے وہ مستحق نہیں ہوتے۔ وہ ایک سادہ سی تصدیق کو ایک ڈرامائی پیشکش میں بدل دیتے ہیں۔ ویسٹیبولر ڈس آرڈرز (vestibular disorders) والے صارفین کے لیے، زیادہ حرکت صرف پریشان کن نہیں ہوتی، بلکہ جسمانی طور پر تکلیف دہ ہوتی ہے۔

لے آؤٹ شفٹ (Layout shift)۔ بٹن کے نیچے ایک نیا پیراگراف ڈالنے سے اگلا فارم فیلڈ نیچے چلا جاتا ہے۔ فوٹر (footer) حرکت کرتا ہے۔ اسکرین کے نچلے حصے کا مواد اپنی جگہ بدل لیتا ہے۔ یہ استعمال (usability) اور رسائی (accessibility) دونوں کو برابر نقصان پہنچاتا ہے۔ سوئچ ڈیوائس یا درست آئی ٹریکنگ (eye tracking) استعمال کرنے والا شخص شاید اگلے ہدف کی طرف بڑھنا شروع کر چکا ہو جب وہ اچانک اپنی جگہ بدل لے۔ اگرچہ آپ کا بیک اینڈ 400ms میں جواب دیتا ہے، لیکن ایک لرزتا ہوا UI عمل کو سست اور غیر محفوظ محسوس کرواتا ہے۔ صارفین اپنا ان باکس خود سے کھول سکتے ہیں کیونکہ آپ کی ایپ پرسکون اور واضح اشارے فراہم کرنے میں ناکام رہی۔

عمل (Flow) کو پڑھنے کے تسلسل کے طور پر دوبارہ سوچیں

ای میل کنفرمیشن کو صرف لوڈنگ اور کامیابی کی حالتوں کے درمیان تبدیلی کے طور پر دیکھنا بند کریں۔ اسے پڑھنے کے ایک ایسے تسلسل کے طور پر دیکھیں جسے صارف ایک نظر میں سمجھ لیتا ہے۔ خود سے چار مخصوص سوالات پوچھیں۔

کلک کے فوراً بعد صارف کیا دیکھتا ہے؟ اگر جواب کچھ نہیں ہے، یا اگر بٹن صرف جم (freeze) جاتا ہے، تو آپ انہیں پہلے ہی کھو چکے ہیں۔ ایک فوری اور مقامی تبدیلی ہونی چاہیے جو یہ بتائے کہ سسٹم نے ان پٹ وصول کر لیا ہے۔

اسکرین ریڈر (screen reader) کیا اعلان کرتا ہے؟ ایک شائستہ اور بغیر مداخلت والا اپ ڈیٹ صارف کو بغیر کسی جھٹکے کے اپنے موجودہ سیاق و سباق میں رہنے دیتا ہے۔ اعلان ایک فٹ نوٹ (footnote) کی طرح محسوس ہونا چاہیے، نہ کہ کسی سائرن کی طرح۔

انتظار کے دوران لے آؤٹ کتنا حرکت کرتا ہے؟ مثالی طور پر، بالکل نہیں۔ انتظار کی حالت کو ایسی جگہ گھیرنی چاہیے جو صارف کے آنے سے پہلے ہی مخصوص کر دی گئی ہو۔

اگر ای میل میں وقت لگے تو کون سا اشارہ نظر آتا رہتا ہے؟ نیٹ ورکس میں خرابی آ سکتی ہے۔ اگر درخواست چند سیکنڈ سے زیادہ وقت لے لے، تو کیا صارف کو معلوم ہوتا ہے کہ کچھ ہو رہا ہے، یا خاموشی انہیں پریشان کر دیتی ہے؟ ایک مستقل اور خاموش اشارہ گھبراہٹ کو روکتا ہے۔

پرسکون کنفرمیشن فیڈ بیک کے لیے چار اصول

آپ چار عملی پابندیوں پر عمل کر کے زیادہ تر کنفرمیشن فلو کو ٹھیک کر سکتے ہیں۔

پیغام کو عمل کے قریب ایک مقررہ جگہ پر رکھیں۔ فیڈ بیک کی ضرورت پڑنے سے پہلے ہی اس کے لیے جگہ محفوظ کر لیں۔ ایک ایسا کنٹینر (container) استعمال کریں جس کی min-height متعین ہو یا CSS grid row جو پیغام کے لیے جگہ فراہم کرے۔ جب متن ظاہر ہو، تو اسے آس پاس کے مواد کو کبھی بھی دھکیلنا نہیں چاہیے۔ تصدیق وہیں ہونی چاہیے جہاں عمل کا ارادہ کیا گیا تھا۔

رسائی (accessibility) کے لیے role="status" کو aria-live="polite" کے ساتھ استعمال کریں۔ اپنے مارک اپ میں ایک لائیو ریجن (live region) بنائیں جو پہلے رینڈر (render) سے ہی موجود ہو۔ جب اسٹیٹ (state) تبدیل ہوتی ہے، تو React اس ریجن کے اندر ٹیکسٹ نوڈ کو اپ ڈیٹ کر دیتا ہے۔ اسکرین ریڈرز کی بورڈ فوکس (keyboard focus) کو ہٹائے بغیر یا صارف کے کام میں مداخلت کیے بغیر تبدیلی کا اعلان کریں گے۔ معمول کی تصدیق کے لیے کبھی بھی aria-live="assertive" استعمال نہ کریں۔ یہ چیخنے کے مترادف ہے۔

بٹن کو ان ماؤنٹ (unmount) نہ کریں۔ جب آپ پیغام دکھانے کے لیے بٹن کو DOM سے ہٹا دیتے ہیں، تو آپ کی بورڈ استعمال کرنے والوں کو الجھا دیتے ہیں۔ ان کا فوکس غائب ہو جاتا ہے۔ اسکرین ریڈرز نامعلوم اسیسٹرز (ancestors) پر پہنچ جاتے ہیں۔ اس کے بجائے، بٹن کو ماؤنٹ ہی رہنے دیں۔ اسے aria-disabled کے ذریعے ڈس ایبل (disable) کر دیں، اس کے لیبل کو "Sending..." یا "Sent" میں تبدیل کر دیں، یا اسے کاؤنٹ ڈاؤن ٹائمر سے بدل دیں۔ ایلیمنٹ اپنی جگہ پر رہتا ہے۔ صرف اس کی اسٹیٹ تبدیل ہوتی ہے۔

prefers-reduced-motion کا احترام کریں۔ ہر کوئی جشن (celebration) نہیں چاہتا۔ کسی بھی ٹرانزیشن (transition) کو میڈیا کوئری (media query) میں لپیٹ دیں۔ اگر صارف نے اپنے آپریٹنگ سسٹم سے موشن (motion) کو کم کرنے کا کہا ہے، تو انہیں فوری ٹیکسٹ تبدیلی یا ہلکا سا اوپیسیٹی فیڈ (opacity fade) دیں۔ کوئی باؤنس (bounce)، کوئی اسپن (spin)، یا کوئی تیزی سے سلائیڈ (slide) نہیں۔ کم موشن کا مطلب کم معنی نہیں ہے۔

ایک مستحکم پیٹرن جو کام کرتا ہے

بہترین پیٹرن بورنگ ہوتا ہے، اور یہی اصل مقصد ہے۔

پہلے رینڈر سے ہی پیغام کے لیے جگہ محفوظ کر لیں۔ بٹن کے بالکل نیچے ایک چھوٹا، بصری طور پر خالی کنٹینر (container) رکھیں۔ اسے ایک فکسڈ (fixed) یا کم از کم اونچائی دیں تاکہ داخل ہونے والا ٹیکسٹ کبھی بھی اگلے سیکشن کو نیچے نہ دھکیلے۔ فیڈ بیک کو گلوبل ٹوسٹ (global toasts) کے بجائے بٹن تک محدود رکھیں۔ ٹوسٹ (Toasts) سسٹم کے پیمانے پر ہونے والی غلطیوں کے لیے مفید ہیں، لیکن معمول کی ای میل تصدیق کے لیے وہ توجہ کو منتشر کر دیتے ہیں اور آنکھوں کو ادھر ادھر گھومنے پر مجبور کرتے ہیں۔

کم سے کم حرکت استعمال کریں۔ اگر آپ کو اینیمیٹ (animate) کرنا ہی ہے، تو ٹرانزیشنز کو دو سو ملی سیکنڈ سے کم رکھیں اور انہیں صرف اوپیسیٹی (opacity) یا رنگ کی ہلکی تبدیلی تک محدود رکھیں۔ ایسے بلاک لیول (block-level) ایلیمنٹس کو شامل کرنے یا ہٹانے سے گریز کریں جو لے آؤٹ کی دوبارہ کیلکولیشن (layout recalculation) پر مجبور کریں۔ اگر آپ کو بٹن کے اندر ہی لوڈنگ اسٹیٹ دکھانے کی ضرورت ہے، تو سادہ ٹیکسٹ سویپ (text swap) یا ایک اسٹیٹک آئیکن (static icon) استعمال کریں۔ بٹن کو اسکیل (scale) نہ کریں، اسے ہلائیں نہیں، اور اسکرین کو چمکائیں (flash) نہیں۔

جب کامیابی کی اسٹیٹ (success state) آئے، تو ایک مختصر اور مستقل اشارہ نظر آنے دیں۔ "Check your inbox" کافی ہے۔ اسے تین سیکنڈ کے بعد خود بخود ختم (auto-dismiss) نہ کریں۔ ایک صارف جس نے غلط وقت پر نظر ہٹا لی ہو، اسے یہ سوچنے پر مجبور نہیں ہونا چاہیے کہ کیا ہوا۔

یہ واقعی گھنٹوں کا وقت کیوں بچاتا ہے

جب آپ ان چھوٹی تفصیلات کو درست کرتے ہیں، تو آپ کو حقیقی نتائج نظر آتے ہیں جن کا آپ کے انفراسٹرکچر بجٹ سے کوئی تعلق نہیں ہوتا۔

ایک ہی بٹن پر کم ڈبل کلکس۔ ڈس ایبل اسٹیٹ اور مقامی فیڈ بیک سے یہ واضح ہو جاتا ہے کہ پہلا کلک رجسٹر ہو گیا ہے۔

سینڈ (send) پر کلک کرنے کے بعد کم صارفین عمل (flow) چھوڑ کر جاتے ہیں۔ پرسکون اشارے دماغ کو بتاتے ہیں کہ سسٹم کام کر رہا ہے، اس لیے صارفین اپنی جگہ پر رہتے ہیں۔

سپورٹ ٹکٹس میں کمی، جہاں یہ دعویٰ کیا جاتا ہے کہ ای میل نہیں پہنچی جبکہ وہ پہنچ چکی ہوتی ہے۔ ان میں سے زیادہ تر ٹکٹس ای میل کے نہ ملنے سے نہیں بلکہ انٹرفیس کے خوف (panic) سے شروع ہوتے ہیں۔

بہتر محسوس ہونے والی کارکردگی (perceived performance)۔ ایک مستحکم UI ہمیشہ افراتفری والے UI کے مقابلے میں تیز محسوس ہوتا ہے، چاہے لیٹنسی (latency) ایک جیسی ہی کیوں نہ ہو۔

اس کا پتہ لگانے کے لیے آپ کو پیچیدہ ٹولز کی ضرورت نہیں ہے۔ ڈپلیکیٹ درخواستوں کے لیے اپنے ایرر لاگز (error logs) پر نظر رکھیں۔ اپنی سپورٹ کیو (support queue) پر توجہ دیں۔ کنفرمیشن اسکرین پر سادہ ریٹینشن (retention) کے ذریعے صارف کے استحکام کی پیمائش کریں۔ ایک پرسکون اور قابلِ پیش گوئی انٹرفیس اس بات کا اشارہ دیتا ہے کہ سسٹم جانتا ہے کہ وہ کیا کر رہا ہے۔ یہی قابلِ پیش گوئی ہونے کا عمل اعتماد پیدا کرتا ہے۔