পুনঃব্যবহারযোগ্য UI কম্পোনেন্ট: নামকরণ, ভ্যারিয়েন্ট এবং লেআউট নিয়ম

কেন ভিজ্যুয়াল বিল্ডারে স্ক্রিনের সঙ্গতি ভেঙে পড়ে

ভিজ্যুয়াল বিল্ডারগুলো দ্রুত স্ক্রিন শিপ করা সহজ করে। সেই গতি ছোট ছোট ভিন্নতার আড়ালে রেখে দিতে পারে। যখন একাধিক মানুষ একই সময়ে কাজ করে, ছোট সিদ্ধান্তগুলো জমে যায়: একজন 12px প্যাডিং দেয়, আরেকজন 16px ব্যবহার করে, আর তৃতীয়জন পুরনো কোনো বাটন কপি করে আনে।

প্রথমেই লক্ষণগুলো চোখে পড়ে: প্রায়-ডুপ্লিকেট কম্পোনেন্ট, স্ক্রিন অনুযায়ী স্থান বদলা, এবং একই অ্যাকশনের জন্য সামান্য ভিন্ন শব্দচয়ন (Save, Submit, Confirm)। স্টেটেও প্রায়ই পার্থক্য দেখা যায়। একটি ফর্মে লোডিং স্পষ্ট, আরেকটায় নেই। এরর মেসেজ ভিন্ন ভোটে আসে, এবং "দ্রুত সমাধান" একটি পেইজে দেখা যায় কিন্তু শেয়ার করা প্যাটার্নে কখনো ফিরিয়ে আনা হয় না।

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

ভিজ্যুয়াল বিল্ডারের একটি কম্পোনেন্ট লাইব্রেরি হলো শেয়ার করা বিল্ডিং ব্লকগুলোর সেট (বাটন, ফিল্ড, কার্ড, হেডার, এম্পটি স্টেট) যেগুলো সবাই নতুন করে তৈরি না করে ব্যবহার করে। AppMaster-এর মতো প্ল্যাটফর্মে এটার অর্থ সাধারণত ভিজ্যুয়াল UI বিল্ডারের ভিতরে পুনঃব্যবহারযোগ্য UI পিসগুলো তৈরি করা, তারপর সবাই একমত হওয়া—কীভাবে এগুলো নামকরণ, কনফিগার এবং প্লেস করা হবে—তাহলে বিভিন্ন লোক যখন স্ক্রিন তৈরি করে তবু সেগুলো সঙ্গতিপূর্ণ থাকে।

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

কোনগুলো পুনঃব্যবহারযোগ্য কম্পোনেন্ট হওয়া উচিত (আর কোনগুলো নয়)

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

ভাল পুনঃব্যবহারযোগ্য কম্পোনেন্ট হলো এমন কিছু যা আপনি অনেক স্ক্রিনে দেখতে আশা করবেন, অথবা যা প্রতিবার একইভাবে দেখতে ও আচরণ করতে হবে। ব্যবহারকারীরা দ্রুত চিনে ফেলতে পারে এমন প্যাটার্ন ভাবুন: একটি প্রাইমারি বাটন, হেল্প টেক্সট সহ টেক্সট ইনপুট, একটি রেকর্ড প্রিভিউ কার্ড।

একটি ছোট স্টার্টার সেট সাধারণত বেশিরভাগ স্ক্রিন কভার করে: বাটন, ইনপুট, কার্ড, পেজ হেডার, এবং দু’একটি মডাল টাইপ (confirm এবং form)।

একটি ব্যবহারিক এক্সট্র্যাকশন নিয়ম সিদ্ধান্তগুলোকে সরল রাখে: একই UI আপনি যদি 2–3 বার ব্যবহার করেন, অথবা এটি ব্র্যান্ডের জন্য অত্যাবশ্যক এবং একরকম থাকতে হবে, তাহলে এটাকে আলাদা কম্পোনেন্ট করুন। যদি এটি একবারের ব্যাপার হয়, তাহলে লোকাল রাখুন।

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

প্রতি কম্পোনেন্টকে ফোকাসড রাখুন। এক কম্পোনেন্ট এক কাজ করুক। একটি “User Card” যা একই সাথে পারমিশন, বিলিং স্ট্যাটাস, এবং অ্যাডমিন অ্যাকশনও হ্যান্ডেল করে তা পুনঃব্যবহারে কঠিন হয়ে যায়। একটি পরিষ্কার পন্থা হলো একটি ডিসপ্লে-ফোকাসড “User Card” এবং আলাদা অ্যাকশন বাটন ও স্ট্যাটাস চিপ রাখা।

এমন নামকরণ নিয়ম যা চাপের মধ্যে পাঠযোগ্য থাকে

একটি দল দ্রুত শিপ করলে নামগুলো প্রথমেই টিভি-ভাঙে। কেউ “Button2” কপি করে, কেউ “CTA Button” বানায়, কেউ “BlueButton” রেখে দেয়। এক সপ্তাহ পর কেউ জানে না কোনটি ব্যবহার করতে হবে, ফলে তারা নতুনটি বানায়। এভাবেই লাইব্রেরি প্রায়-ডুপ্লিকেটের ঝোপে পরিণত হয়।

একটি সরল প্যাটার্ন আপনাকে কনসিস্টেন্ট রাখে এমনকি আপনি ক্লান্ত থাকলেও: Component - Part - State. বেশিরভাগ কম্পোনেন্টের সব তিনটি দরকার হয় না, কিন্তু অর্ডার একই থাকে।

মানুষ যেগুলো বলেই—এসব শব্দ ব্যবহার করুন। আপনার দল যদি “Customer card” বলে, তাকে “CRM Tile” নামে না রাখুন। প্রোডাক্ট যদি এটাকে “Plan” বলে, তাকে “SubscriptionBox” বলা ঠিক নয়। সরল ভাষা জিতে যায় কারণ তা সার্চযোগ্য।

একটি নিয়ম অনেক বিভ্রান্তি রোধ করে: একই স্তরে “কীভাবে দেখতে লাগে” এবং “কি উদ্দেশ্যে”—দুটো মিশাবেন না। একটি পদ্ধতি বেছে নিন। যদি আপনি উদ্দেশ্যভিত্তিক নামকরণ করেন, রঙের শব্দ এড়ান। যদি ভিজ্যুয়ালভিত্তিক নামকরণ করেন, ব্যবসায়িক অর্থ এড়ান। উদ্দেশ্য-ভিত্তিক নামকরণ সাধারণত ভালভাবে স্কেল করে।

মন্তব্যের উদাহরণ যা কম্পোনেন্ট তালিকায় সহজে স্ক্যান করা যায়:

• Button - Primary
• Button - Secondary - Disabled
• Input - WithLabel
• Card - Compact
• Modal - ConfirmDelete

ফরম্যাটিং একবার নির্ধারণ করুন এবং লিখে রাখুন: Title Case না হলে sentence case, হাইফেনের চারপাশে স্পেস আছে কিনা, এবং সংক্ষিপ্তনগুলো ব্যবহার করবেন কি না (মাত্রই ব্যবহার করুন যদি সেগুলো সর্বজনীন, যেমন “URL”)। ভিজ্যুয়াল বিল্ডারে যেখানে অনেকেই অবদান রাখে, এই ছোট পছন্দগুলো লাইব্রেরি বড় হওয়ার সঙ্গে পাঠযোগ্য রাখে।

ভ্যারিয়েন্ট: কীভাবে বিকল্প দিন কিন্তু বিশৃঙ্খলা না বাড়ান

ভ্যারিয়েন্টগুলো একটি কম্পোনেন্টকে বহু জায়গায় পুনঃব্যবহার করতে দেয় কপি না করে। কুশলতা হলো কোন ভিন্নতাগুলো গুরুত্বপূর্ণ তা আগেই সিদ্ধান্ত নেওয়া এবং বাকিটাকে লক করা।

কয়েকটি ভ্যারিয়েন্ট মাত্রা দিয়ে শুরু করুন যা বাস্তবে প্রয়োজন মেটায়। অনেক কম্পোনেন্টের জন্য তিনটি যথেষ্ট: আকার (S/M/L), উদ্দেশ্য (primary/secondary/danger), এবং স্টেট (default/hover/active)। যদি কোনো নতুন অপশন ঐ মাত্রার মধ্যে না পড়ে, সেটাকে নতুন কম্পোনেন্ট হিসেবে বিবেচনা করুন, “আরও একটি ভ্যারিয়েন্ট” হিসেবে নয়।

ডিফল্টগুলো মানুষের চেয়েও বেশি গুরুত্ব রাখে। নতুন স্ক্রিনগুলো সঠিক দেখুক এমনভাবে সেট করুন এমনকি কেউ কম্পোনেন্টটি টেনে এনে কিছুই বদলাতে না চাইলে। নিরাপদ ডিফল্ট দিন (যেমন size=M, intent=primary, state=default) যাতে গতি র‍্যান্ডম স্টাইলিংয়ে পরিণত না হয়।

প্রতিটি কম্পোনেন্টের জন্য যাদের ভ্যারিয়েন্ট আছে, লিখে রাখুন এবং প্রয়োগ করুন:

• সমর্থিত মাত্রা এবং অনুমোদিত মান (ছোট রাখুন)
• ডিফল্ট মান
• কোনটা কখনও ভ্যারিয়েন্ট জুড়ে বদলায় না (প্যাডিং, ফন্ট, কর্নার রেডিয়াস, আইকন স্পেসিং)
• অনিবার্য স্টেট যেমন disabled এবং loading, এবং সম্ভব হলে error
• কখন নতুন কম্পোনেন্ট তৈরি করবেন ভ্যারিয়েন্ট বাড়ানোর বদলে

উদাহরণ: আপনার কাছে একটি "Submit" বাটন আছে কাস্টমার পোর্টালে। একজন ব্যক্তি যদি একটি “Wide Submit Button” 만들েন এবং অন্যজন “Rounded Submit Button” বানান, তাহলে ড্রিফট দ্রুত দেখা দেবে। নিয়ম থাকলে আপনি একটি Button কম্পোনেন্ট রাখেন। আকার এবং উদ্দেশ্য অনুমোদন করবেন, কাস্টম প্যাডিং ও কর্নার রেডিয়াস নিষিদ্ধ করবেন, এবং “Loading” একবার সংজ্ঞায়িত করবেন (স্পিনার দেখান, ক্লিক লক করুন) যাতে এটি সর্বত্র একইভাবে আচরণ করে।

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

লেআউট নিয়ম: স্পেসিং, অ্যালাইনমেন্ট, এবং গ্রিড যা সবাই মানে

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

স্পেসিং স্কেল দিয়ে শুরু করুন এবং সব কিছুকে বাদ দিন। একটি ছোট সেট বেছে নিন (উদাহরণস্বরূপ 4, 8, 12, 16, 24) এবং এটিকে একটি কীবোর্ডের মতো বিবেচনা করুন: আপনি বহু গান বাজাতে পারবেন, কিন্তু সেসব কীগুলো দিয়েই। কেউ যদি “18px” চায়, সাধারণত এর মানে হলো কম্পোনেন্ট বা গ্রিড সঠিক নয়।

স্পেসিং কী বোঝায় তা স্পষ্ট করুন:

• Padding হচ্ছে কম্পোনেন্টের ভিতরে এবং এটি স্ক্রিন জুড়ে ধারাবাহিক থাকে।
• Gap হচ্ছে একটি কন্টেইনারের ভিতরে আইটেমগুলোর মধ্যে (ফর্ম রো, টুলবার আইটেম)।
• Margin হচ্ছে কম্পোনেন্টের বাইরে এবং এটি সংযতভাবে ব্যবহার করা উচিত।
• স্ট্যাক করা মার্জিনের বদলে gap-কে প্রধান্য দিন যাতে নেস্টিং-এ স্পেস ডাবল না হয়।

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

গ্রিডগুলোকে জটিল হতে হবে না, কিন্তু থাকা উচিত। কলাম ও গাটার নির্ধারণ করুন, এবং ছোট স্ক্রিনে কী হবে তা ঠিক করুন (একটি মৌলিক “ডেস্কটপে 12 কলাম, মোবাইলে সিংগেল কলাম”ও সাহায্য করে)। কন্টেইনার প্রস্থ ও ব্রেকপয়েন্ট একবার সেঠ করে দিন, তারপর সেই রেলগুলোর ভিতরে স্ক্রিন তৈরি করুন।

সাধারণ ফাঁদগুলো: নেস্টেড কন্টেইনার যা প্রত্যেকটাই প্যাডিং যোগ করে, অনিয়মিত পেজ মার্জিন, ফিক্সড প্রস্থকে রেসপন্সিভ কলামের সঙ্গে মিশানো, এবং এমন “ম্যাজিক নাম্বার” যা শুধু একটি স্ক্রিন ঠিক করে।

স্টাইল টোকেন: ফন্ট, রঙ, এবং অ্যাক্সেসিবিলিটি বেসিক্স

স্টাইল টোকেনগুলো হলো শেয়ার করা পছন্দগুলো যা সবাই ব্যবহার করে। যখন টোকেন স্পষ্ট থাকে, পুনঃব্যবহারযোগ্য UI কম্পোনেন্টগুলো কনসিস্টেন্ট থাকে এমনকি বিভিন্ন মানুষ স্ক্রিন বানালেও।

টাইপোগ্রাফি একটি একক সূত্র হিসেবে শুরু করুন। ফন্ট সাইজ, ওয়েট, এবং লাইন হাইটের জন্য একটি ছোট স্কেল বেছে নিন এবং বেশি না বাড়ান। অধিকাংশ টিমকে কয়েক ধাপই যথেষ্ট (উদাহরণ: body, small, caption, title, page heading)। এগুলো এক জায়গায় রাখুন যাতে নতুন টেক্সট একই ডিফল্ট থেকে শুরু করে।

রঙগুলো অর্থ-ভিত্তিকভাবে নামকরণ করলে ভাল কাজ করে, রঙ কোডে নয়। “Primary” মূল অ্যাকশন বোঝায়। “Success” মানে সফলতা, এবং “Warning” মানে যাচাই করা দরকার। “blue-500” ধরনের নাম এড়িয়ে চলুন যদি না আপনার দল ইতিমধ্যে প্যালেটে এইভাবে ভাবতে অভ্যস্ত।

অ্যাক্সেসিবিলিটির বেসিকস যাতে পরে সমস্যা না হয়:

• নিশ্চিত করুন টেক্সটের কনট্রাস্ট যথেষ্ট উচ্চ।
• ট্যাপ টার্গেট বড় রাখুন যাতে থাম্বের জন্য উপযুক্ত হয়, কীবোর্ড পয়েন্টারের জন্য নয়।
• এরর মেসেজ লিখুন যা কি হয়েছে এবং কী করা উচিত তা বলে।
• স্ট্যাটাস জানাতে কেবল রঙের উপর নির্ভর করবেন না।

টোকেনগুলোকে সরাসরি কম্পোনেন্ট ভ্যারিয়েন্টের সাথে যুক্ত করুন। একটি Button ভ্যারিয়েন্ট যেমন Primary, Secondary, বা Danger সেই অনুমোদিত টোকেনগুলো (রঙ, বর্ডার, টেক্সট স্টাইল) বদলাবে, নতুন কোনো ওয়ান-অফ স্টাইল নয়।

টোকেন তালিকাকে পর্যাপ্ত ছোট রাখুন যাতে মানুষ সত্যিই তা ব্যবহার করে। একটি ভালো পরীক্ষা: কেউ কি 5 সেকেন্ডে সঠিক টোকেন বেছে নিতে পারবে? যদি না পারে, মিশিয়ে দিন বা মুছে দিন।

একটি সহজ স্টার্টার সেট হতে পারে টাইপোগ্রাফি (text.body, text.small, text.title), রঙ (color.primary, color.success, color.warning, color.danger), স্পেসিং (space.8, space.16, space.24), রেডিয়াস (radius.sm, radius.md), এবং ফোকাস (focus.ring)।

ধাপে ধাপে: একটি ভিজ্যুয়াল বিল্ডারে কম্পোনেন্ট লাইব্রেরি সেট আপ করা

একটি কম্পোনেন্ট লাইব্রেরি "ডিজাইন পারফেকশন"-এর চেয়ে বেশি প্রতিদিনের মাইক্রো-ফয়সন কমানো সম্পর্কে। যখন সবাই একই বিল্ডিং ব্লক বেছে নেয়, বিভিন্ন মানুষ স্ক্রিন বানালে তবুও সেগুলো সঙ্গতিপূর্ণ থাকে।

একটি বাস্তবসম্মত ৫-ধাপ রোলআউট

1. আপনার যা আছে সেটার অডিট করুন। 5–10টি রিয়েল স্ক্রিন বেছে নিন এবং বারবার দেখা ডুপ্লিকেটগুলো নোট করুন: বাটন, টেক্সট ইনপুট, সেকশন হেডার, কার্ড, এম্পটি স্টেট।

2. প্রথমে স্ট্যান্ডার্ড করার জন্য একটি ছোট তালিকা চুন। প্রতিটি স্থানে সর্বাধিক দেখা যায় এবং সবচেয়ে বড় মিল ভিন্নতা সৃষ্টিকারী শীর্ষ 10 পিস লক্ষ্য করুন। অনেক টিমের জন্য তা বাটন, ইনপুট, ড্রপডাউন, মডাল ডায়ালগ, টেবিল হেডার, এবং কার্ড।

3. তৈরি করার আগে নিয়মগুলো লিখে রাখুন। সংক্ষিপ্ত রাখুন: কম্পোনেন্ট নাম, কখন ব্যবহার করবেন, অনুমোদিত ভ্যারিয়েন্ট, এবং তার চারপাশের লেআউট নিয়ম (স্পেসিং, অ্যালাইনমেন্ট, প্রস্থ)।

4. একবার পুনর্নির্মাণ করুন, তারপর ধীরে প্রতিস্থাপন করুন। নতুন কম্পোনেন্টগুলো আপনার ভিজ্যুয়াল বিল্ডারে তৈরি করুন এবং সম্মত ভ্যারিয়েন্টগুলো লক করে দিন। পুরনো কপি স্ক্রিন বাই স্ক্রিন প্রতিস্থাপন করুন—একটি স্প্রিন্টে সবকিছু রিফ্যাক্টর করার চেষ্টা করবেন না।

5. একটি হালকা-ওজন রিভিউ গেট যোগ করুন। একজন ব্যক্তি (সাপ্তাহিকভাবে রোটেটিং) নতুন কম্পোনেন্ট ও ভ্যারিয়েন্ট চেক করে। লক্ষ্য পুলিশিং নয়; উদ্দেশ্য দুর্ঘটনাজনক ফর্ক প্রতিরোধ করা।

“ভালো পর্যাপ্ত” কেমন দেখায়

আপনি তখন বুঝবেন এটা কাজ করছে যখন একজন ডিজাইনার বা PM বলতে পারবে, “স্ট্যান্ডার্ড কার্ডটি compact header দিয়ে ব্যবহার করো,” এবং দুই জন বিল্ডার একই ফলাফল তৈরি করবে। লাভ হলো: কম এক-অফ সিদ্ধান্ত, কম সূক্ষ্ম অনিয়ম, এবং দ্রুত স্ক্রিন বিল্ডিং।

লাইব্রেরিটিকে ইচ্ছাকৃতভাবে ছোট রাখুন। কেউ নতুন ভ্যারিয়েন্ট চাইলে প্রথমেই জিজ্ঞেস করুন: এটা কি বাস্তব নতুন প্রয়োজন, না বিদ্যমান ভ্যারিয়েন্ট কনটেন্ট বদলে কভার করতে পারে?

সাধারণ ভুলগুলো যা ধীর, অসঙ্গত UI সৃষ্টি করে

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

একটি সাধারণ ফাঁদ হলো ভ্যারিয়েন্ট না বাড়িয়ে প্রায়-ডুপ্লিকেট তৈরি করা। কেউ “primary button, but slightly taller” চায় এবং কম্পোনেন্ট ডুপ্লিকেট করে। এক সপ্তাহ পর আর কেউ তাতে ডুপ্লিকেট করে। এখন তিনটা বাটন আছে যা দেখতে কাছাকাছি কিন্তু আলাদা আচরণ করে, এবং প্রতিটি পরিবর্তন একটি সন্ধান হয়ে যায়।

আরেকটি ধীরগতি কারণ হলো অতিরিক্ত কনফিগারেবল কম্পোনেন্ট: একটি মেগা কম্পোনেন্ট যেটাতে ডজনভাগ টগল। শুরুতে এটা ফ্লেক্সিবল মনে হয়, পরে অনিয়ন্ত্রিত হয়ে যায়। মানুষ এগুলো বিশ্বাস করা বন্ধ করে এবং “এই কেসের জন্য” নতুন সংস্করণ তৈরি করে, যা উদ্দেশ্য ব্যর্থ করে।

লেআউট ভুলও একই পরিমাণ ক্ষতি করে। বড় ভুল হলো দায়িত্ব মিশ্রিত করা: একটি কম্পোনেন্ট তার বাইরের মার্জিন নিয়ন্ত্রণ করে আর স্ক্রিনও_spacing যোগ করে। ফলাফল হচ্ছে এলোমেলো গ্যাপ যা পেজ অনুযায়ী পরিবর্তিত হয়। একটি সহজ নিয়ম সাহায্য করে: কম্পোনেন্টগুলি অভ্যন্তরীণ প্যাডিং সংজ্ঞায়িত করে, স্ক্রিনগুলো কম্পোনেন্টগুলোর মধ্যে স্থান নিয়ন্ত্রণ করে।

সাধারণত দেখা যায়: নামকরণ নিয়ম চাপলে ভেঙে পড়ে, স্টেটগুলো পরে যোগ করা হয় (loading, empty, error), এক-অফ টুইকগুলো স্থায়ী হয়ে যায়, এবং বিভিন্ন লোক একই লেআউটে ভিন্ন সমাধান করে।

প্রতিটি নতুন স্ক্রিনের জন্য দ্রুত সঙ্গতি চেকলিস্ট

কিছু নতুন যোগ করার আগে 60 সেকেন্ড থামুন এবং বেসিকগুলো চেক করুন। একটি স্ক্রিন ঠিক দেখালেও নীরবে সিস্টেম ভাঙতে পারে, এবং একাধিক মানুষ একসাথে কাজ করলে সেই ছোট ভাঙন দ্রুত জমে যায়।

• নামকরণ: প্রতিটি কম্পোনেন্ট সম্মত প্যাটার্ন মেনে চলছে (উদা: Form/Input, Form/Input.HelperText, Table/RowActions)। নাম যদি কারো খোঁজে সাহায্য না করে, এখনই নাম বদলান।
• ওনার + উদ্দেশ্য: প্রতিটি শেয়ার্ড কম্পোনেন্টের একটি ওনার (ব্যক্তি বা দল) এবং কখন ব্যবহার করার একটি এক-সেন্টেন্স বর্ণনা আছে।
• শুধু অনুমোদিত স্পেসিং স্কেল: সব প্যাডিং, গ্যাপ, এবং মার্জিন অনুমোদিত স্পেসিং স্টেপ ব্যবহার করে। যদি আপনি “কোনো নতুন নাম্বার টাইপ করছেন কারণ এটা ঠিক দেখায়,” তখন থামুন এবং নিকটতম স্টেপ বেছে নিন।
• স্টেটগুলো অন্তর্ভুক্ত আছে: মূল ইন্টারঅ্যাকটিভ পিসগুলোতে loading এবং error স্টেট আছে, শুধু হাসি-পথ নয়। ভাবুন disabled বাটন, ইনপুট এরর, এম্পটি লিস্ট, retry।
• নতুন স্টাইল তৈরি নেই: বিদ্যমান টোকেন এবং কম্পোনেন্ট ব্যবহার করে স্ক্রিন তৈরি করুন। যদি আপনি নতুন রঙ, ফন্ট সাইজ, রেডিয়াস, বা শ্যাডো চান, সেটাকে সিস্টেম অনুরোধ হিসেবে ফেলুন, স্ক্রিন-স্তরের ফিক্স হিসেবে নয়।

উদাহরণ: দুই জন একই ফিচার তৈরি করে—নিয়ম ছাড়া ও নিয়ম সহ

Maya এবং Leon কাস্টমার সাপোর্ট টিমে। তাদের দুটো স্ক্রিন দরকার: একটি টিকেট লিস্ট (দ্রুত স্ক্যান করার জন্য) এবং একটি টিকেট ডিটেইলস স্ক্রিন (একটি টিকেটে কাজ করার জন্য)। তারা কাজ ভাগ করে ভিজ্যুয়াল বিল্ডারে তৈরি করে।

নিয়ম ছাড়া, каждый লোক "একটি কার্ড" ভিন্নভাবে তৈরি করে। Maya একটি সাদা কার্ড দেয় পাতলা বর্ডার ও শ্যাডো সহ। Leon গ্রে কার্ড দেয় কোন বর্ডার ছাড়া কিন্তু অতিরিক্ত প্যাডিং দিলেন। এক স্ক্রিনে রাউন্ডেড প্রাইমারি বাটন আছে, অন্যটায় স্কয়ার বাটন ও টেক্সট লিংক আছে। স্ট্যাটাস এক স্ক্রিনে রঙিন ডট ধরে আছে আর অন্যটায় পিল। ডিটেইলস পেজে ফিল্ডগুলো সারিবদ্ধ নয় কারণ লেবেলগুলোর প্রস্থ ভিন্ন, ফলে পুরো ফর্মটা অসংগঠিত লাগে।

রিভিউ মিটিংটা স্টাইলিং বিতর্কে পরিণত হয়, এবং একটি সাধারণ আপডেট (যেমন “Priority” যোগ করা) মানে বহু এক-অফ লেআউটে স্পর্শ করা।

নিয়ম থাকলে, তারা শেয়ার করা পুনঃব্যবহারযোগ্য UI কম্পোনেন্ট থেকে শুরু করে: একটি TicketCard কাঠামো ও স্পেসিংয়ের জন্য, একটি StatusBadge স্ট্যাটাস স্টাইল ও কনট্রাস্টের জন্য, এবং একটি ActionBar কনসিস্টেন্ট প্রাইমারি অ্যাকশনের জন্য।

এখন লিস্ট স্ক্রিন compact TicketCard ভ্যারিয়েন্ট ব্যবহার করে মূল ফিল্ড ও একটি প্রিভিউ লাইনের জন্য। ডিটেইলস স্ক্রিন ডিটেইলড ভ্যারিয়েন্ট ব্যবহার করে পূর্ণ বর্ণনা, টাইমলাইন, এবং অতিরিক্ত ফিল্ড দেখায়। স্ট্রাকচার একই থাকে; ভ্যারিয়েন্ট নির্ধারণ করে কী দেখাবে।

সেরা অংশ হলো আপনি যা না দেখেন: কম রিভিউ মন্তব্য, কম “কেন এটা আলাদা?” প্রশ্ন, এবং পরবর্তীতে দ্রুত আপডেট। যখন দল “Closed” কে “Resolved” বলতে নামকরণ করে এবং তার রঙটা বদলে, তারা একবার StatusBadge পরিবর্তন করে এবং উভয় স্ক্রিন একসাথে আপডেট হয়।

সময়ের সাথে কিভাবে সঙ্গতি ধরে রাখা (পরবর্তী ধাপ)

সঙ্গতি এককালীন সেটআপ নয়। আরও মানুষ স্ক্রিন তৈরি করা শুরু করলে, ছোট “এই পেইজের জন্য” সিদ্ধান্তগুলো গুণে বেড়ে যায় এবং লাইব্রেরি ড্রিফট করতে পারে।

একটি সরল পরিবর্তন প্রক্রিয়া দলকে চলমান রাখে এমনকি প্রতিটি বাটন টুইককে বিতর্কে পরিণত না করে:

• Propose: কী বদলাচ্ছে এবং কেন (নতুন কম্পোনেন্ট, নতুন ভ্যারিয়েন্ট, নাম বদলানো, ডেপ্রিকেট)
• Review: একজন ডিজাইনার বা UI ওনার নামকরণ, স্পেসিং রুল, এবং অ্যাক্সেসিবিলিটি বেসিক চেক করেন
• Approve: স্পষ্ট হ্যাঁ/না, সংক্ষিপ্ত নোটসহ যদি এটি কেবল একটি নির্দিষ্ট ফ্লোতে সীমাবদ্ধ হয়
• Release: শেয়ার্ড লাইব্রেরি আপডেট করুন এবং পরিবর্তন এক জায়গায় ঘোষণা করুন

সিদ্ধান্তগুলোর একটি ঠিকানা থাকা দরকার। একটি সংক্ষিপ্ত “UI rules” ডক যথেষ্ট যদি এতে নামকরণ কনভেনশন, অফিসিয়াল ভ্যারিয়েন্ট লিস্ট (কি আছে আর কি নেই), এবং একটি করা-নাকরা তালিকা (উদা: “দ্বিতীয় ‘Primary Button’ বিভিন্ন প্যাডিং সহ তৈরি করা যাবে না”) অন্তর্ভুক্ত থাকে।

মাসিক একটি ক্লিনআপ স্লট নির্ধারণ করুন। ডুপ্লিকেট মার্জ করুন, ব্যবহারহীন পিসগুলো সরান, এবং পুরনো কম্পোনেন্টগুলো ডিপ্রিকেট হিসেবে চিহ্নিত করুন যাতে মানুষ ভুলবিশ্বাসে সেগুলো না নেয়।

একই প্যাটার্ন দু’বার দেখা গেলে রিফ্যাক্টর করুন (উদা: দুই টিম হালকা ভিন্ন এম্পটি স্টেট তৈরি করেছে)। যদি কিছু প্রকৃতপক্ষে ইউনিক, সময়-সংবেদনশীল এবং পুনরাবৃত্তির সম্ভাবনা কম থাকে তাহলে এক-অফ হিসেবে রাখুন।

AppMaster-এ কাজ করলে, একটি বাস্তবিক পরবর্তী ধাপ হতে পারে প্রথমে একটি একক ওয়ার্কফ্লো স্ট্যান্ডার্ড করা (যেমন “Create ticket”), তারপর প্রসারিত করা। UI বিল্ডারগুলো একই কম্পোনেন্টগুলি স্ক্রিন জুড়ে শেয়ার করা সহজ করে, এবং appmaster.io একটি রেফারেন্স পয়েন্ট হিসেবে ব্যবহারযোগ্য যদি আপনার দল নো-কোড অ্যাপ বানাতে চায় যা কেবল পেজ লেআউট নয় বরং পূর্ণ অ্যাপ সাপোর্ট করে।