ওয়েব ও মোবাইলে লোডিং, ত্রুটি ও খালি স্টেটগুলি সঙ্গতিপূর্ণ করা

কেন এই স্টেটগুলো এত দ্রুত এলোমেলো হয়ে যায়

লোডিং, ত্রুটি, এবং খালি স্টেটগুলো হল সেই স্ক্রিন (বা ছোট UI ব্লক) যা ব্যবহারকারী দেখে যখন অ্যাপ অপেক্ষা করছে, কিছু ব্যর্থ হয়েছে, বা দেখানোর মতো কিছু নেই। এইগুলো স্বাভাবিক: নেটওয়ার্ক ধীর হয়, অনুমতি অস্বীকৃত হয়, এবং নতুন অ্যাকাউন্টে ডেটা শুরুতে শূন্য থাকে।

এগুলো এলোমেলো হয়ে যায় কারণ সাধারণত এগুলো পরে এবং দ্রুতভাবে যোগ করা হয়। টিমগুলো প্রথমে হ্যাপি পাথ গড়ে তোলে, তারপর যেখানে UI ভেঙে পড়ে সেখানে দ্রুত একটি স্পিনার, একটি লাল বার্তা, এবং একটি “no items” প্লেসহোল্ডার লাগায়। বহু স্ক্রিনে এভাবে করলে একগুচ্ছ অনন্য ভার্সন তৈরি হয়।

দ্রুত পুনরাবৃত্তি এটা আরও খারাপ করে। যখন UI দ্রুত তৈরি করা হয় (AI-উত্পাদিত UI সহ), মূল লেআউট কয়েক মিনিটে দেখে দেওয়া যায়, কিন্তু এই স্টেটগুলো স্কিপ করা সহজ। প্রতিটি নতুন স্ক্রিনে আলাদা স্পিনার স্টাইল, আলাদা লেখন (“Try again” বনাম “Retry”), এবং আলাদা বোতামের অবস্থান দেখা যায়। শুরুতে যে গতি অর্জিত হয়, তা লঞ্চের ঠিক আগে পলিশ কাজ হয়ে দাঁড়ায়।

ম্যাচ না করা স্টেটগুলো ব্যবহারকারীকে বিভ্রান্ত করে এবং টিমের সময় নেয়। মানুষ বুঝতে পারে না একটি খালি তালিকা কি “কোন ফলাফল নেই”, “এখনো লোড হয়নি”, না “আপনার অ্যাক্সেস নেই” বোঝায়। QA-কে ছোট ধরনের অনেক ভ্যারিয়েশন পরীক্ষা করতে হয়, এবং বাগগুলো সরে পড়ে কারণ ওয়েব ও মোবাইলে আচরণ আলাদা।

"এলোমেলো" প্রায়শই এভাবে দেখা যায়:

• লোডিং এক স্ক্রিনে অ্যাকশন গোপন করে কিন্তু অন্যটিতে নয়।
• ত্রুটিগুলো কখনো পেজ ব্লক করে, কখনো ছোট টেক্সট হিসেবে দেখা যায়।
• খালি স্টেটগুলোর টোন, আইকন এবং পরবর্তী পদক্ষেপ ভিন্ন ভিন্ন।
• একই অ্যাকশনের জন্য ওয়েব ও মোবাইলে ভিন্ন লেবেল ব্যবহার করা হয়।

লক্ষ্য সহজ: ওয়েব ও মোবাইল জুড়ে একটি শেয়ার্ড পদ্ধতি। যদি আপনার টিম দ্রুত ফিচার তৈরি করে (উদাহরণস্বরূপ, Koder.ai প্ল্যাটফর্ম ব্যবহার করে), তাহলে শেয়ার্ড স্টেট প্যাটার্ন আরও বেশি গুরুত্বপূর্ণ কারণ প্রতিটি নতুন স্ক্রিন ডিফল্টভাবে সঙ্গতিপূর্ণ শুরু করবে।

প্রথমে স্ট্যান্ডার্ডাইজ করার জন্য ৫টি স্টেট টাইপ

অধিকাংশ অ্যাপ একই চাপের বিন্দুগুলো পুনরাবৃত্তি করে: তালিকা, ডিটেইল পেজ, ফর্ম, ড্যাশবোর্ড। এগুলোই যেখানে স্পিনার, ব্যানার, এবং “কিছু নেই” বার্তা বাড়ে।

শুরু করুন পাঁচটি স্টেট টাইপকে নাম দিয়ে ও স্ট্যান্ডার্ড করে:

• Initial loading: স্ক্রিন প্রথমবার খুললে, ডেটা না থাকার আগে।
• Refreshing / updating: স্ক্রিনে ইতিমধ্যেই ডেটা আছে, কিন্তু আপনি নতুন ডেটা নিয়ে আসছেন।
• Empty baseline: সত্যিই কিছুই নেই (নতুন অ্যাকাউন্ট, নতুন ওয়ার্কস্পেস, কোনো আইটেম তৈরি করা হয়নি)।
• Zero results: ডেটা আছে, কিন্তু ফিল্টার বা সার্চ কিছুই ফেরত দিল না।
• Error: রিকোয়েস্ট ব্যর্থ হয়েছে, অনুমতি ব্লক করেছে, বা কিছু ভেঙে পড়েছে।

দুইটি বিশেষ কেস আলাদা নিয়ম পায় কারণ এগুলো আচরণে ভিন্ন:

• Offline: সম্ভব হলে ক্যাশড কন্টেন্ট দেখান এবং সরলভাবে বলুন “You’re offline”।
• Slow network: দ্রুত ত্রুটি ফ্ল্যাশ এড়িয়ে চলুন; একটি ছোট বিলম্বের পরে “Still loading…” (বা অনুরূপ) তে স্যুইচ করুন।

স্ক্রিন ও প্ল্যাটফর্ম জুড়ে কাঠামো সঙ্গতিপূর্ণ রাখুন: স্টেট কোথায় দেখায়, আইকন স্টাইল, টোন, এবং ডিফল্ট অ্যাকশন (Retry, Refresh, Clear filters, Create)। যা পরিবর্তিত হতে পারে তা হল প্রসঙ্গ: স্ক্রিনের নাম এবং ব্যবহারকারীর শব্দ ব্যবহার করে একটি বাক্য।

উদাহরণ: আপনি যদি ওয়েব তালিকা এবং মোবাইল তালিকা উভয় তৈরি করেন “Projects” জন্য, তাহলে তাদের একই zero-results প্যাটার্ন শেয়ার করা উচিত। অ্যাকশন লেবেল প্ল্যাটফর্ম অনুযায়ী মিলিয়ে যেতে পারে (“Clear filters” বনাম “Reset”)।

একগুচ্ছ অনন্য বস্তুতে সময় নষ্ট করার বদলে একটি ছোট স্টেট কিট তৈরি করুন

প্রতিটি স্ক্রিন যদি তার নিজস্ব স্পিনার, এরর কার্ড, এবং খালি বার্তা উদ্ভাবন করে, তাহলে শেষমেষ আপনার কাছে ডজনখানেক সামান্য আলাদা ভার্সন থাকবে। দ্রুত সমাধান হল একটি ছোট "StateKit" যা কোনো ফিচারই সহজে জুড়ে দিতে পারে।

প্রতিটি জায়গায় কাজ করবে এমন তিনটি পুনঃব্যবহারযোগ্য কম্পোনেন্ট দিয়ে শুরু করুন: Loading, Error, এবং Empty। উদ্দেশ্য অনুসারে সেগুলো নির্বিকার ও সাদামাটা রাখুন। এগুলো সহজে চিনে নেওয়া যাবে এবং প্রধান UI-এর সাথে প্রতিদ্বন্দ্বিতা করবে না।

কম্পোনেন্টগুলোকে পূর্বানুমেয় করে তুলুন ছোট ইনপুট সেট নির্ধারণ করে:

• Title (সংক্ষিপ্ত ও নির্দিষ্ট)
• Message (এক বা দুই বাক্য)
• Primary action label
• Primary action handler (retry, refresh, বা পরবর্তী ধাপ)
• ঐচ্ছিক বিবরণ (এরর কোড, সেকেন্ডারি অ্যাকশন)

তারপর লুক লক করে দিন। একবার spacing, typography, icon size, এবং button style ঠিক করে নিন এবং এটাকে একটি রুল হিসেবে বিবেচনা করুন। যখন আইকন সাইজ ও বোতামের ধরন একই থাকে, ব্যবহারকারীরা স্টেট UI-এর দিকে কম নজর দেয় এবং এর উপর ভরসা করতে শুরু করে।

বিভিন্নতা সীমিত রাখুন যাতে কিটটি আরেকটি ডিজাইন সিস্টেমে পরিণত না হয়। সাধারণত তিনটি সাইজই কভার করে: small (inline), default (section), এবং full-page (blocking)।

আপনি যদি Koder.ai-তে স্ক্রিন জেনারেট করেন, একটি সহজ নির্দেশ যেমন “use the app StateKit for loading/error/empty with default variant” ড্রিফট রোধ করে। এটি React web এবং Flutter mobile জুড়ে লেট-সাইকেল ক্লিনআপও কমায়।

এমন কপি লিখুন যা সঙ্গতিপূর্ণ থাকে

কপি সিস্টেমের অংশ, সাজসজ্জা নয়। লেআউট সঙ্গতিপূর্ণ থাকলেও, এড-হক ফ্রেইজিং স্ক্রিনগুলোকে আলাদা করে তোলে।

একটি শেয়ার্ড ভয়েস বেছে নিন: সংক্ষিপ্ত, নির্দিষ্ট, শান্ত। কী ঘটেছে সহজ ভাষায় বলুন, তারপর ব্যবহারকারীকে পরবর্তী কী করতে হবে জানান। অধিকাংশ স্ক্রিনে একটি পরিষ্কার টাইটেল, এক সংক্ষিপ্ত ব্যাখ্যা, এবং একটি স্পষ্ট অ্যাকশনই পর্যাপ্ত।

টেমপ্লেট ব্যবহার করুন যাতে টিমরা ছাড়পত্র না দেয়

কয়েকটি বার্তা প্যাটার্ন বেশিরভাগ অবস্থার জন্য কভার করে। ছোট রাখুন যাতে ছোট স্ক্রিনে ফিট করে:

• Network: “Can’t connect” + “Check your internet and try again.” + Action: “Retry”
• Timeout: “Taking longer than expected” + “The request timed out.” + Action: “Try again”
• Permission: “Permission needed” + “Allow access to continue.” + Action: “Open settings”
• Not found: “Nothing here” + “This item may have been removed.” + Action: “Back”
• Validation: “Fix one thing” + “Add a valid email address.” + Action: “Save”

একাই অস্পষ্ট পাঠ্য এড়িয়ে চলুন যেমন “Something went wrong”। যদি সত্যিই কারণ জানা না থাকে, তবে যা জানা আছে এবং ব্যবহারকারী এখন কী করতে পারে তা বলুন। “We couldn’t load your projects” বলা ভাল “Error” বলতে।

পরবর্তী অ্যাকশনকে পূর্বানুমেয় করুন

একটি নিয়ম সেট করুন: প্রতিটি ত্রুটি ও খালি স্টেট একটি পরবর্তী পদক্ষেপ অফার করে।

• ব্যবহারকারী যদি পুনরুদ্ধার করতে পারে, “Retry” বা “Refresh” অফার করুন।
• যদি স্টেট খালি হয় ফিল্টারের কারণে, “Clear filters” প্রস্তাব করুন।
• যদি ব্যবহারকারী ব্লক হয়ে থাকে (অনুমতি), ঠিক কোথায় সেটি পরিবর্তন করা যায় তা বলুন।

AI-জেনারেটেড UI-এ এটি আরও গুরুত্বপূর্ণ, যেখানে স্ক্রিন দ্রুত আসে। টেমপ্লেট কপি সঙ্গত রাখে যাতে লাস্ট-পলিশে আপনি ডজনখানেক বার্তা পুনরায় না লিখতে হয়।

অ্যাকশনগুলো পূর্বানুমেয় করুন: retry, refresh, এবং পরবর্তী ধাপ

যখন স্টেট স্ক্রিনগুলো একটি পেজ থেকে অন্য পেজে বিভিন্ন অ্যাকশন সাজেস্ট করে, ব্যবহারকারীরা অনিশ্চিত হয়। টিম তখন লঞ্চের ঠিক আগে বোতাম ও কপি সংশোধন করতে থাকে।

প্রতিটি স্টেটের জন্য কোন অ্যাকশন থাকা উচিত তা ঠিক করুন, এবং অবস্থান ও লেবেল সঙ্গতিপূর্ণ রাখুন। অধিকাংশ স্ক্রিনে একটি প্রাথমিক অ্যাকশন থাকা উচিত। যদি দ্বিতীয়টি যোগ করেন, সেটি প্রধান পথকে সাপোর্ট করবে, প্রতিযোগিতা করবে না।

স্কেল করা যায় এমন ছোট অ্যাকশন ম্যাপ

অনুমোদিত অ্যাকশনগুলো সংকীর্ণ রাখুন:

• Loading: সাধারণত কোনো অ্যাকশন থাকে না (ঐচ্ছিকভাবে দীর্ঘ, ব্যবহারকারী-শুরু করা টাস্কের জন্য “Cancel”)।
• Empty: ব্যবহারকারী কিছু যোগ করতে পারে এমন হলে “Create”; যখন ফিল্টারের কারণে খালি, তখন “Adjust filters”।
• Error: সাময়িক ব্যর্থতার জন্য “Retry”; পুরনো ডেটার জন্য “Refresh”; ব্লক হওয়া ওয়ার্কফ্লোর জন্য কেবল “Contact support”।
• Success with no data change: “Back” বা “Done.”

নীরস বোতামগুলো একটি ফিচার। এগুলো UI-কে পরিচিত করে এবং জেনারেট করা স্ক্রিনগুলো সঙ্গত রাখতে সাহায্য করে।

Retry ও এরর বিবরণ নিয়ম

“Retry” তখন দেখান যখন retry করার বাস্তব সুযোগ থাকে (টাইমআউট, ফ্ল্যাকি নেটওয়ার্ক, 5xx)। বারবার ট্যাপ করলে অনুরোধ স্প্যাম না হয় তার জন্য একটি ছোট debounce যোগ করুন, এবং retry করার সময় বোতামকে লোডিং স্টেটে রাখুন।

বারবার ব্যর্থ হওয়ার পরে একই প্রাথমিক বোতাম রাখুন এবং সেকেন্ডারি হেল্প উন্নত করুন (উদাহরণস্বরূপ, “Check connection” টিপ বা “Try again later”)। কোনো কারণে দুইবার ব্যর্থ হওয়ার জন্য পুরো লেআউট পরিবর্তন করবেন না।

এরর ডিটেইলের জন্য ব্যবহারকারীর কাজ করা যায় এমন একটি সরল কারণ দেখান (“Your session expired. Sign in again.”)। প্রযুক্তিগত বিবরণ ডিফল্টভাবে লুকিয়ে রাখুন। যদি দরকার হয়, তা ক্রস-প্ল্যাটফর্মে একটি সঙ্গত “Details” অ্যাফোর্ডেন্সের অন্তর্গত রাখুন।

উদাহরণ: একটি “Projects” তালিকা মোবাইলে লোড করতে ব্যর্থ হলে উভয় প্ল্যাটফর্ম একই প্রাথমিক “Retry” অ্যাকশন দেখায়, retry করার সময় তা ডিসেবল করে, এবং দুইবার ব্যর্থ হলে একটি ছোট কানেকশন হিন্ট যোগ করে সম্পূর্ণ বোতাম লেআউট বদলায় না।

টিমকে ধীর করতে না করে সিস্টেম রোল আউট করুন

স্টেট সামঞ্জস্যকে একটি ছোট প্রোডাক্ট পরিবর্তন হিসাবে বিবেচনা করুন, বদলে একটি রিডিজাইন নয়। ধাপে ধাপে যান, এবং গ্রহণযোগ্যতা সহজ করুন।

প্রথমে আপনার যা আছে তার একটি দ্রুত স্ন্যাপশট নিন। পরফেকশন লক্ষ্য করবেন না। সাধারণ ভ্যারিয়েশনগুলো ধরুন: স্পিনার বনাম স্কেলেটন, ফুল-পেজ এরর বনাম ব্যানার, বিভিন্ন টোনে “no results” স্ক্রীন।

একটি বাস্তবসম্মত রোলআউট প্ল্যান:

• ওয়েব ও মোবাইল জুড়ে ১৫–৩০টি মূল স্ক্রিনের ইনভেন্টরি নিন এবং সবচেয়ে সাধারণ প্যাটার্নগুলো গ্রুপ করুন।
• প্রথমে ৩–৪টি ক্যানোনিকাল প্লেসমেন্ট বেছে নিন (full page, section, inline, toast)।
• ওয়েব ও মোবাইলের জন্য মিলে এমন কম্পোনেন্ট তৈরি করুন যেগুলো একই props ও নাম শেয়ার করে।
• সংক্ষিপ্ত ব্যবহার বিধি লিখুন যাতে নতুন স্ক্রিনগুলো কিট থেকে নির্বাচন করে নতুন ভার্সন তৈরি না করে।
• একটি সময়ে একটি প্রোডাক্ট এরিয়া প্রতিস্থাপন করুন (search, inbox, billing) যাতে রিলিজ নিরাপদ থাকে।

একবার কম্পোনেন্টগুলো থাকা শুরু করলে, সত্যিকারের সময়-সংরক্ষক হবে একটি সংক্ষিপ্ত বিধি সেট যা বিতর্ক অপসারণ করে: কখন স্টেট পুরো পেজ ব্লক করবে বা কেবল একটি কার্ড, এবং কোন অ্যাকশন থাকা আবশ্যক।

নিয়মগুলো সংক্ষিপ্ত রাখুন:

• প্রতিটি ত্রুটি একটি স্পষ্ট পরবর্তী ধাপ দেখায় (retry, refresh, বা contact support)।
• খালি স্টেটগুলো একটি প্রাথমিক অ্যাকশন দেয় (create, import, বা explore)।
• লোডিং স্টেট ডেটা এলে লেআউট না ঝাঁকায়।

আপনি যদি Koder.ai-এর মত AI UI জেনারেটর ব্যবহার করেন, এই নিয়মগুলো দ্রুত ফল দেয়। “use the state kit components” বলে প্রম্পট করলে React web এবং Flutter mobile—উভয়েই আপনার সিস্টেমের সাথে মিল রাখে এমন স্ক্রিনগুলো পাবেন, কম ক্লিনআপ নিয়ে।

সাধারণ ভুলগুলো যা লেট-পলিশ কাজ বাড়ায়

লেট-পলিশ কাজ সাধারণত ঘটে কারণ স্টেট হ্যান্ডলিং এক-অফ করে গড়ে তোলা হয়েছে। একটি স্ক্রিন “কাজ করে”, কিন্তু কোনো কিছু সময় নিলে বা ব্যর্থ হলে অভিজ্ঞতা প্রতিবার আলাদা লাগে।

এমন লোডিং যা আটকে গেছে মত লাগে

স্কেলেটন সাহায্য করে, কিন্তু খুব বেশি সময় স্ক্রিনে রেখে দিলে মানুষ ভাববে অ্যাপ ফ্রিজ করেছে। একটি সাধারণ কারণ হল ধীর কল দেখিয়ে পুরো স্কেলেটন রাখা অথচ কোন ইঙ্গিত না দেয়া যে কিছু চলছে।

টাইম-বক্স করুন: একটি ছোট বিলম্বের পরে, হালকা “Still loading…” বার্তায় স্যুইচ করুন বা সম্ভব হলে অগ্রগতির সংক্ষিপ্ত ইঙ্গিত দেখান।

স্ক্রিন জুড়ে কপি ভিন্ন হওয়া

টিমগুলো প্রায়ই প্রতিবার নতুন বার্তা লেখে, এমনকি সমস্যা একই হলেও। “Something went wrong”, “Unable to fetch”, এবং “Network error” একক সমস্যার বিভিন্নভাবে বর্ণনা করে, কিন্তু এগুলো অসমঞ্জস্যপূর্ণ লাগে এবং সাপোর্ট কঠিন করে।

প্রতিটি এরর টাইপের জন্য একটি লেবেল বেছে নিন এবং ওয়েব ও মোবাইলে একরকম ব্যবহার করুন, একই টোন ও বিস্তারিত স্তরে।

খালি বনাম এরর বনাম এখনও লোড হয়নি

আরও একটি ক্লাসিক ভুল হল তথ্য শেষ হওয়ার আগে খালি স্টেট দেখানো, বা ব্যর্থ অনুরোধের বদলে “No items” দেখানো। ব্যবহারকারী ভুল কাজে যায় (যেমন কন্টেন্ট যোগ করা যখন তাদের অবশ্যই retry করা উচিত)।

নির্ধারণের ক্রম স্পষ্ট রাখুন: প্রথমে loading, তারপর ব্যর্থ হলে error, এবং কেবল অনুরোধ সফল হলে empty দেখান।

অনুপস্থিত বা অভিভ্যক্ত অ্যাকশন

যদি কোনো এরর পুনরুদ্ধারের পথ না দেয় তবে ডেড-এন্ড তৈরি হয়। বিপরীতটা হচ্ছে: তিনটি বোতাম যেগুলোই মনোযোগ ছিনিয়ে নেয়।

সংকীর্ণ রাখুন:

• এররগুলোর জন্য ডিফল্ট একটি প্রাথমিক অ্যাকশন (সাধারণত “Retry”)।
• খালি স্টেটের জন্য একটি স্পষ্ট পরবর্তী ধাপ।
• সেকেন্ডারি অ্যাকশন শুধুমাত্র সত্যিই প্রয়োজন হলে ব্যবহার করুন।

প্ল্যাটফর্মগুলোর মধ্যে ভিজ্যুয়াল মিল না থাকা

ছোট ছোট পার্থক্য জমে যায়: আইকন স্টাইল, প্যাডিং, বোতামের আকার। যদি প্রম্পট বিভিন্ন হয়, AI-জেনারেটেড UI-ও ড্রিফট করতে পারে।

স্টেট কম্পোনেন্টগুলোর spacing, icon set, এবং লেআউট লক করে দিন যাতে প্রতিটি নতুন স্ক্রিন একই কাঠামো উত্তরাধিকারে পায়।

লোডিং আচরণ এবং অ্যাক্সেসিবিলিটির ব্যবহারিক নিয়ম

যদি আপনি ওয়েব ও মোবাইল জুড়ে সঙ্গত স্টেট হ্যান্ডলিং চান, "নীরস" নিয়মগুলো স্পষ্ট করে দিন। অধিকাংশ লেট-পলিশ ঘটে কারণ প্রতিটি স্ক্রিন নিজের লোডিং আচরণ, টাইমআউট, এবং লেবেল উদ্ভাবন করে।

যা দ্রুত মনে করায় এমন লোডিং নিয়ম (এবং প্রকৃতপক্ষে ধীর হলেও)

পুরো পেজ লোডের জন্য একটি ডিফল্ট পছন্দ বেছে নিন: কনটেন্ট-ভারী স্ক্রিনের (তালিকা, কার্ড, ড্যাশবোর্ড) জন্য স্কেলেটন এবং সেই ক্ষেত্রে যেখানে লেআউট অনির্দিষ্ট সেখানে ছোট অপেক্ষার জন্য স্পিনার।

UI নীরসভাবে আটকে না থাকে তার জন্য একটি টাইমআউট থ্রেশহোল্ড যোগ করুন। যদি লোডিং প্রায় ৮–১০ সেকেন্ড অতিক্রম করে, স্পষ্ট বার্তায় স্যুইচ করুন এবং একটি দৃশ্যমান অ্যাকশন দিন যেমন “Retry”।

আংশিক লোডের জন্য স্ক্রিন ফাঁকা করবেন না। বিদ্যমান কন্টেন্ট দৃশ্যমান রাখুন এবং আপডেট হওয়া সেকশনের কাছে একটি ছোট প্রগ্রেস সূচক দেখান (উদাহরণ: হেডারে পাতলা বার বা ইনলাইন স্পিনার)।

ক্যাশড ডেটার জন্য “stale but usable” পছন্দ করুন। ক্যাশ করা কন্টেন্ট তাত্ক্ষণিক দেখান এবং একটি সূক্ষ্ম “Refreshing…” ইন্ডিকেটর যোগ করুন যাতে মানুষ বুঝে ডেটা বদলাতে পারে।

অফলাইন আলাদা স্টেট। সরাসরি বলুন এবং কি কাজ করে তা বলুন। উদাহরণ: “You’re offline. You can view saved projects, but syncing is paused.” একক পরবর্তী ধাপ দিন যেমন “Try again” বা “Open saved items.”

যেগুলো সব জায়গায় প্রয়োগ করার মতো বেসিক অ্যাক্সেসিবিলিটি

নিচেরগুলো সব প্ল্যাটফর্মে সঙ্গত রাখুন:

• Focus order: স্টেট appara হওয়ার সময় ফোকাস মেসেজ ও প্রাথমিক অ্যাকশনে নিয়ে আসুন।
• Screen reader labels: লোডিং ও এররগুলো স্পষ্ট, সংক্ষিপ্ত টেক্সট দিয়ে ঘোষণা করুন।
• Tap targets: মোবাইলে বোতামগুলো বড় রাখুন, ছোট ইনলাইন লিঙ্ক এড়িয়ে চলুন।
• Motion: স্পিনারগুলো সূক্ষ্ম রাখুন এবং কেবল অ্যানیمেশনের ওপর নির্ভর করবেন না।
• Color: কোনো সংকেত শুধুমাত্র রঙের ওপর রাখবেন না (টেক্সট ও আইকনও দিন)।

আপনি যদি Koder.ai-এর মত টুল দিয়ে UI জেনারেট করেন, এই নিয়মগুলো একটি শেয়ার্ড StateKit-এ বেক করলে প্রতিটি নতুন স্ক্রিন ডিফল্টভাবে সঙ্গতিপূর্ণ থাকবে।

উদাহরণ: একটি ফিচার, তিনটি স্টেট, দুইটি প্ল্যাটফর্ম

একটি সাধারণ CRM কল্পনা করুন যার একটি Contacts তালিকা এবং একটি Contact details স্ক্রিন আছে। যদি আপনি লোডিং, ত্রুটি, এবং খালি স্টেটগুলো আলাদাভাবে টreate করেন, ওয়েব ও মোবাইল দ্রুত ড্রিফট করবে। একটি ছোট সিস্টেম থাকলে দ্রুত UI তৈরি হলেও সব কিছু সারিবদ্ধ থাকে।

প্রথমবারের খালি স্টেট (Contacts তালিকা): ব্যবহারকারী Contacts খুললে কিছুই না দেখায়। ওয়েব ও মোবাইলে টাইটেল একই থাকে (“Contacts”), খালি বার্তা কারণটিও ব্যাখ্যা করে (“No contacts yet”), এবং একটিমাত্র স্পষ্ট পরবর্তী ধাপ অফার করা হয় (“Add your first contact”)। যদি সেটআপ প্রয়োজন হয় (যেমন ইনবক্স কানেক্ট করা বা CSV ইম্পোর্ট), খালি স্টেট সুনির্দিষ্ট ঐ ধাপ নির্দেশ করে।

ধীর নেটওয়ার্ক লোডিং: ব্যবহারকারী Contact details পেজ খোলে। উভয় প্ল্যাটফর্মই একটি পূর্বানুমেয় স্কেলেটন লেআউট দেখায় যা চূড়ান্ত পেজ স্ট্রাকচারের (হেডার, কী ফিল্ড, নোট) সাথে মেলে। back বোতাম এখনও কাজ করে, পেজ টাইটেল দৃশ্যমান থাকে, এবং বিভিন্ন জায়গায় এলোমেলো স্পিনার দেখানো এড়ানো হয়।

সার্ভার এরর: ডিটেইল রিকোয়েস্ট ব্যর্থ হয়। একই প্যাটার্ন ওয়েব ও মোবাইলে দেখা যায়: একটি সংক্ষিপ্ত হেডলাইন, একটি বাক্য, এবং একটি প্রাথমিক অ্যাকশন (“Retry”)। যদি retry আবার ব্যর্থ হয়, একটি দ্বিতীয় অপশন দিন যেমন “Go back to Contacts” যাতে ব্যবহারকারী আটকে না পড়ে।

কী জিনিস সঙ্গতিপূর্ণ থাকে সহজঃ

• Placement: মেসেজ কন্টেন্ট এলাকায়, অ্যাকশন এক সচেতন স্থানে।
• Copy: একটি টোন, একই বোতাম লেবেল (Retry, Add contact)।
• Behavior: স্কেলেটনের ট্রিগার একই, retry-এর নিয়ম একই।
• Safety: লোডিংয়ের সময় ডুপ্লিকেট অ্যাকশন ডিসেবল করা।

শিপ করার আগে দ্রুত চেকলিস্ট

একটি রিলিজ “ডান” মনে হবে যতক্ষণ না কেউ ধীর সংযোগ, নতুন অ্যাকাউন্ট, বা ফ্লাকি API আঘাত করে। এই চেকলিস্ট আপনাকে শেষ-মাইল গ্যাপগুলো ধরতে সাহায্য করবে QA-কে একটি স্ক্যাভেঞ্জার হানায় পরিণত না করে।

UI সামঞ্জস্য পরীক্ষা

তালিকা স্ক্রিনগুলো দিয়ে শুরু করুন, কারণ সেগুলো বহুগুণে বাড়ে। তিনটি সাধারণ তালিকা (search results, saved items, recent activity) বেছে নিন এবং যাচাই করুন এগুলো একই empty-state স্ট্রাকচার ব্যবহার করে: একটি স্পষ্ট টাইটেল, একটি সহায়ক বাক্য, এবং একটি প্রাথমিক অ্যাকশন।

লোডিং চলাকালীন কখনো empty states দেখাবেন না। যদি আপনি অল্প সময়ের জন্য “Nothing here yet” ফ্ল্যাশ করে পরে কন্টেন্ট দেখান, ব্যবহারকারীর বিশ্বাস দ্রুত হারায়।

লোডিং ইন্ডিকেটরের সঙ্গতি পরীক্ষা করুন: সাইজ, অবস্থান, এবং একটি বোধগম্য ন্যূনতম সময় যাতে ফ্লিকারিং না হয়। যদি ওয়েবের উপর একটি টপ বার স্পিনার দেখায় কিন্তু মোবাইল একই স্ক্রিনের জন্য ফুল-স্ক্রিন স্কেলেটন দেখায়, তা দুইটি আলাদা পণ্য মনে হয়।

এরর ও QA পরীক্ষা

এররগুলো সর্বদা “এখন কী?” উত্তর দিবে। প্রতিটি এররের একটি পরবর্তী ধাপ থাকা জরুরি: retry, refresh, filter change, পুনরায় সাইন-ইন, বা contact support।

রিলিজ-ready হিসেবে চিহ্নিত করার আগে দ্রুত একটি পাস:

• Empty states: তালিকা স্ক্রিন জুড়ে একই লেআউট, আইকন স্টাইল, ও টোন।
• Loading: খুব আগে empty দিয়ে বদলে না; ইনডিকেটরগুলো ওয়েব ও মোবাইলে মিলে।
• Errors: প্রতিটি এরর স্ক্রিন বা টোস্টে একটি স্পষ্ট পরবর্তী অ্যাকশন।
• Copy rules: প্ল্যাটফর্ম জুড়ে শব্দচয়ন সঙ্গত (টাইটেল, পাঙ্গচুয়েশন, বোতামের ক্রিয়া)।
• QA script: একটি সংক্ষিপ্ত, পুনরাবৃত্তিযোগ্য ধাপ যা loading, empty, এবং error স্টেটগুলো ট্রিগার করে।

আপনি যদি Koder.ai ব্যবহার করে UI জেনারেট করেন, এই চেকগুলো আরও গুরুত্বপূর্ণ কারণ স্ক্রিন দ্রুত তৈরি হবে, কিন্তু সঙ্গতি নির্ভর করবে শেয়ার্ড কিট এবং শেয়ার্ড কপি নিয়মের ওপর।

অ্যাপ বড় হলে সঙ্গতি বজায় রাখার পরবর্তী ধাপ

সঙ্গতি সহজ যখন এটি প্রতিদিনের কাজের অংশ, একবারের ক্লিনআপ নয়। প্রতিটি নতুন স্ক্রিন একই প্যাটার্ন ব্যবহার করবে বিধায় আর কেউ শেষে বলে “মিলিয়ে দাও” মনে করবে না।

স্টেট আচরণকে আপনার definition of done-এর অংশ বানান। একটি স্ক্রিন তখনই শেষ বলে গণ্য হোক যখন এতে লোডিং স্টেট, (যদি প্রযোজ্য) একটি খালি স্টেট, এবং একটি স্পষ্ট একশনসহ এরর স্টেট থাকে।

নিয়মগুলো লঘু রাখুন, কিন্তু লিখে রাখুন। কয়েকটি স্ক্রিনশট ও সঠিক কপি প্যাটার্ন সহ একটি সংক্ষিপ্ত ডক সাধারণত যথেষ্ট। নতুন ভ্যারিয়েন্টগুলোকে ব্যতিক্রম হিসেবে দেখুন। কেউ নতুন স্টেট ডিজাইন প্রস্তাব করলে প্রশ্ন করুন এটা সত্যিই নতুন কেস নাকি কিটে ফিট করে।

আপনি যদি অনেক স্ক্রিন রিফ্যাক্টর করেন, ঝুঁকি কমাতে ধাপে ধাপে করুন: একটানা একটা ফ্লো আপডেট করুন, ওয়েব ও মোবাইলে যাচাই করুন, তারপর চালিয়ে যান। Koder.ai-তে স্ন্যাপশট ও রোলব্যাক বড় পরিবর্তনগুলোকে নিরাপদ করে, এবং planning mode শেয়ার্ড StateKit সংজ্ঞায় সাহায্য করে যাতে নতুনভাবে জেনারেট হওয়া স্ক্রীনগুলোই আপনার ডিফল্ট অনুসরণ করে।

এগুলো এগিয়ে নেওয়ার একটি ব্যবহারিক উপায়

এই সপ্তাহে এমন একটি এলাকা বেছে নিন যেখানে স্টেট সমস্যা লেট-ফিক্স ঘটায় (অften search results, onboarding, বা activity feed)। তারপর:

• ঐ অঞ্চলের গ্রহণযোগ্য চেকলিস্টে স্টেটের প্রয়োজনীয়তা যোগ করুন।
• একগুচ্ছ এক-অফ স্টেটদের পরিবর্তে শেয়ার্ড কম্পোনেন্ট বসান।
• ২–৩টি উদাহরণ (ভালো ও খারাপ) ডক-এ রেকর্ড করুন।
• দ্রুত ক্রস-প্ল্যাটফর্ম রিভিউ করুন (একই অর্থ, একই অ্যাকশন, অনুরূপ লেআউট)।
• পরবর্তী স্প্রিন্টে আপনি কতটি UI পলিশ টিকিট করেছেন তা ট্র্যাক করুন এবং তুলনা করুন।

এটা কাজ করছে যে পরিষ্কার লক্ষণ: “add retry”, “empty state looks weird”, বা “loading spinner blocks the page” ধরনের ছোট টিকিটের সংখ্যা কমে যায়।

মালিকানাকে স্পষ্ট রাখুন

স্টেট স্ট্যান্ডার্ডের জন্য একটি একক মালিক নির্ধারণ করুন (একজন ডিজাইনার, একজন টেক লিড, বা উভয়ই)। তাদের সবকিছু অনুমোদন করতে হবে না, কিন্তু তারা কিটকে ধীরে ধীরে ভাঙতে দেওয়া থেকে রক্ষা করবে যাতে ধীরে ধীরে নতুন ভ্যারিয়েন্ট তৈরি হয়ে সময় নষ্ট না করে।