Atomic Design روشی برای فکرکردن به رابطه اجزای رابط و صفحه‌های واقعی است. Brad Frost آن را با پنج سطح Atoms، Molecules، Organisms، Templates و Pages شرح می‌دهد. طبق توضیح خود او، این سطح‌ها را نباید مراحل خطی اجباری تفسیر کرد که همیشه از کوچک‌ترین جزء آغاز می‌شوند. متن قبلی بیشتر یک زنجیره ساده از اتم تا صفحه و یک ترکیب ابزار «بهترین» پیشنهاد می‌داد. در عمل، ارزش روش به شناخت قرارداد اجزا و برگشت از صفحه واقعی برای اصلاح آن‌ها وابسته است، نه نام پوشه‌ها یا انتخاب یک ابزار خاص.
سطح‌ها چه چیزی را توضیح می‌دهند؟
Atom می‌تواند یک عنصر پایه مانند label یا button باشد. Molecule چند جزء را برای کار محدود کنار هم می‌آورد، مثل فرم جست‌وجو. Organism بخش بزرگ‌تری با مسئولیت مشخص است، مانند header دارای navigation و جست‌وجو. Template ساختار محتوا و بخش‌های صفحه را نشان می‌دهد و Page آن ساختار را با محتوای واقعی به کار می‌گیرد. این نام‌ها برای گفت‌وگو مفیدند، اما هر component مرز قطعی و جهانی ندارد. اختلاف درباره دسته نباید تصمیم درباره مسئولیت و API را متوقف کند.
برای مثال، Search Form از label، input و button تشکیل می‌شود، اما رفتار ارسال و خطا هم دارد. اگر فقط ظاهر سه عنصر را گروه کنیم، قرارداد کار آن کامل نشده است. باید معلوم باشد query از کجا می‌آید، ارسال چه رخدادی دارد و در حالت نامعتبر چه می‌شود. Atomic Design کمک می‌کند رابطه بخش‌ها دیده شود، ولی این قراردادها را خودکار تولید نمی‌کند. طراح و توسعه‌دهنده باید درباره رفتار مشترک تصمیم بگیرند و آن را در مرجع component ثبت کنند.
از صفحه واقعی به جزء برگردید
اگر ابتدا کتابخانه‌ای بزرگ از اجزای فرضی بسازید، ممکن است نیاز محصول را درست پیش‌بینی نکرده باشید. یک صفحه مهم با محتوای واقعی انتخاب کنید و بخش‌های تکرارشونده را پیدا کنید. شاید دو کارت ظاهراً مشابه مسئولیت متفاوت داشته باشند و نباید یک API عمومی پیچیده برای هر دو بسازید. شاید چند دکمه واقعاً از یک قرارداد مشترک استفاده کنند. این بررسی نشان می‌دهد چه چیزی قابلیت استفاده دوباره دارد و چه چیزی فعلاً باید نزدیک همان صفحه بماند.
Page با داده واقعی محدودیت جزء را آشکار می‌کند. عنوان بلند، نبود تصویر و مقدار خالی ممکن است در نمونه کوچک دیده نشده باشند. پس از مشاهده، قرارداد component را اصلاح کنید و دوباره صفحه را بخوانید. این رفت‌وبرگشت بخش مهم روش است. یک مسیر خطی که پس از ساخت atom دیگر به آن برنمی‌گردد، نیاز واقعی را از کتابخانه جدا می‌کند. هدف این نیست که همه عناصر از روز اول کامل باشند؛ باید امکان اصلاح بدون تکرار بی‌نظم وجود داشته باشد.
مرز مسئولیت از اندازه مهم‌تر است
یک component کوچک می‌تواند وابستگی زیادی به داده کسب‌وکار داشته باشد و یک بخش بزرگ می‌تواند صرفاً ترکیب layout باشد. برای مرزبندی، بپرسید چه چیزی تغییر می‌کند و چه کسی صاحب قرارداد است. Button عمومی نباید درباره نوع سفارش تصمیم بگیرد. Order Summary ممکن است به قرارداد مبلغ و وضعیت سفارش وابسته باشد. مخلوط‌کردن این دو، استفاده دوباره را دشوار می‌کند. اسم Atom یا Organism به تنهایی درباره محل state، دسترسی شبکه یا قواعد محصول پاسخ نمی‌دهد.
در React یا framework دیگر، API جزء باید ورودی و خروجی روشن داشته باشد. propهای متعدد برای تغییرهای نامرتبط می‌توانند component را به مجموعه شرط‌های پنهان تبدیل کنند. اگر variant تازه به هدف متفاوتی اشاره دارد، شاید ترکیب یا component جدا مناسب‌تر باشد. مقاله الگوهای Component در React ادامه این بحث است. استفاده دوباره باید هزینه فهم و تغییر را کم کند؛ اشتراک حداکثری کد همیشه به همین نتیجه منتهی نمی‌شود.
Token، عنصر و الگو مسئولیت متفاوت دارند
Design Token مقدار یا نقش سبک را ثبت می‌کند، مثل رنگ متن اصلی یا فاصله. Component آن مقدارها را در ساختار و رفتار به کار می‌گیرد. Pattern توضیح می‌دهد چند component برای یک کار چگونه همکاری می‌کنند. این لایه‌ها را یکی نکنید. ساخت یک button با رنگ ثابت، هنوز سیستم token نمی‌سازد و داشتن چند token هم رفتار فرم را تعریف نمی‌کند. مقاله راهنمای Design System درباره این ارتباط بیشتر توضیح می‌دهد.
نام‌گذاری باید برای تیم قابل یافتن باشد. لازم نیست همه فایل‌ها دقیقاً در پنج پوشه با نام استعاره علمی قرار بگیرند. بخش ابزارهای Atomic Design نیز امکان تغییر نام و دسته‌بندی را مطرح می‌کند. اگر واژه‌های Components و Patterns در تیم روشن‌ترند، می‌توان همان‌ها را به کار گرفت و منطق سطح‌ها را حفظ کرد. هدف، کتابخانه قابل استفاده است. ساختار پوشه‌ای که اعضا برای یافتن یک فرم باید درباره moleculeبودن آن بحث کنند، شاید به اصلاح نیاز دارد.
حالت‌ها بخشی از قراردادند
برای هر component، حالت‌های مرتبط را ثبت کنید: عادی، focus، disabled، loading، خطا و داده خالی. همه اجزا به همه این حالت‌ها نیاز ندارند، اما حالت لازم نباید به مصرف‌کننده واگذار شود بدون راهنما. Disabled بودن باید دلیل قابل فهم داشته باشد. Loading باید با عملیات واقعی هماهنگ باشد. خطا ممکن است به فیلد یا کل بخش مربوط باشد. نمونه‌های کتابخانه باید این تفاوت‌ها را نشان دهند تا صفحه‌های مختلف رفتارهای ناسازگار نسازند.
Storybook یکی از ابزارهای نمایش حالت‌های component است. مستند رسمی Stories هر story را به وضعیت renderشده مرتبط می‌کند. این ابزار می‌تواند به مستندسازی کمک کند، اما شرط لازم Atomic Design نیست. تیم کوچک شاید با صفحه نمونه ساده شروع کند. اگر Storybook انتخاب می‌کنید، داده نمونه و dependencyها را طوری سازمان دهید که component مستقل قابل فهم باشد. اضافه‌کردن ابزار بدون مالک به‌روزرسانی می‌تواند مرجعی قدیمی و گمراه‌کننده بسازد.
طراحی و کد یک قرارداد مشترک داشته باشند
Component در Figma و component کد لازم نیست ساختار داخلی یکسان داشته باشند، اما نام variant و معنی آن باید قابل نگاشت باشد. اگر در طراحی حالت «خطرناک» دارید، توسعه‌دهنده باید بداند چه زمانی استفاده می‌شود. اگر در کد prop تازه‌ای اضافه شده، نمونه طراحی و توضیح کاربردش را دنبال کنید. مقاله Figma Dev Mode درباره تحویل مرجع کمک می‌کند. ابزار Inspect مقادیر را نشان می‌دهد و جای توافق درباره رفتار را نمی‌گیرد.
برای تحویل، نمونه‌های واقعی و موارد ممنوع را کوتاه بنویسید. فرم جست‌وجو ممکن است برای ورودی ساده مناسب باشد و برای فیلتر چندشرطی نه. کارت عمومی ممکن است اطلاعات کوتاه را پوشش دهد، اما نمایش جدول مقایسه مسئولیت دیگری دارد. این محدودیت‌ها جلوی کش‌دادن component به کاربرد نامناسب را می‌گیرند. اگر کاربرد تازه ارزش دارد، قرارداد را آگاهانه گسترش دهید و مصرف‌کنندگان قبلی را در نظر بگیرید. تغییر عمومی نباید بی‌خبر نتیجه صفحه‌های دیگر را عوض کند.
دسترسی‌پذیری در جزء و صفحه
Button عمومی باید نقش و رفتار پایه درست داشته باشد، ولی نام قابل فهم آن در صفحه از محتوا می‌آید. Dialog می‌تواند focus را مدیریت کند، اما ترتیب دعوت به آن و اطلاعات داخلش هم مهم است. پس دسترسی‌پذیری فقط یک بار در atom حل نمی‌شود. هر سطح مسئولیت خودش را دارد. مقاله دسترسی‌پذیری سایت فارسی درباره بررسی مسیر کامل توضیح می‌دهد. صفحه باید با ترکیب اجزای سالم نیز مسیر منطقی و قابل استفاده بسازد.
در رابط فارسی، component باید طول متن، RTL و بخش لاتین را در نظر بگیرد. یک button با عرض ثابت ممکن است label واقعی را قطع کند. یک کارت با icon در سمت ثابت ممکن است در جهت دیگر نیاز به قاعده منطقی داشته باشد. حالت‌ها را با محتوای واقعی فارسی نشان دهید. اگر طراحی فقط placeholder کوتاه دارد، محدودیت کتابخانه پنهان می‌ماند. حفظ اصطلاح انگلیسی استاندارد نیز باید با جهت و خوانایی متن هماهنگ باشد و به ترجمه اجباری منتهی نشود.
نسخه و مالکیت کتابخانه را روشن کنید
استفاده مشترک یعنی تغییر یک جزء می‌تواند بر چند صفحه اثر بگذارد. مسئول پذیرش تغییر و روش اعلام آن را مشخص کنید. اگر API ناسازگار عوض می‌شود، مصرف‌کنندگان باید مسیر مهاجرت داشته باشند. نام version به تنهایی کافی نیست؛ یادداشت باید مشکل و رفتار تازه را توضیح دهد. تغییر رنگ داخلی شاید دامنه کمی داشته باشد، اما تغییر قرارداد value در input می‌تواند منطق چند فرم را عوض کند. شدت بررسی باید به پیامد واقعی مربوط باشد.
برای شروع، یک صفحه مهم را انتخاب کنید و سه جزء تکراری را با مسئولیت و حالت‌هایشان مستند کنید. سپس همان‌ها را در صفحه دوم به کار ببرید و ببینید چه قراردادهایی واقعاً مشترک‌اند. قسمت‌های ویژه را بی‌دلیل عمومی نکنید. از تجربه دو صفحه برای اصلاح کتابخانه استفاده کنید. Atomic Design در این فرایند زبان رابطه‌ها را می‌دهد و ابزارها نمایش و تحویل را تسهیل می‌کنند؛ نتیجه قابل استفاده از تصمیم روشن، محتوای واقعی و نگهداری منظم به دست می‌آید.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!