Shadows | سایه‌ها (elevation)

سایه‌ها در طراحی رابط تکنیک بصری‌اند که با کنتراست، بلور و موقعیت، اثر نور را تقلید می‌کنند تا عناصر دیجیتال عمق و جدایش پیدا کنند. صفحه ذاتاً تخت است؛ سایه نشانه‌ای می‌دهد که کارت بالاتر از پس‌زمینه نشسته یا دکمه قابل فشردن به نظر برسد. این مدخل دربارهٔ elevation و لایه‌بندی UI است—نه دربارهٔ تیره‌کردن فام رنگ که shade نام دارد. وقتی Material از سطح elevation حرف می‌زند یا مودال روی دیمر می‌نشیند، زبان سایه‌های عمق در کار است.

چرا روی صفحهٔ تخت به عمق ساختگی نیاز داریم؟

انسان از جهان فیزیکی یاد گرفته لبه‌های نرم سایه مرز اشیاء و فاصله از سطح را بخواند. در رابط، کارت با سایهٔ ملایم از پس‌زمینه جدا می‌شود و به‌عنوان قطعهٔ تعاملی شناخته می‌شود؛ عناصر کاملاً تخت گاهی منفعل یا هم‌سطح متن حس می‌شوند. سایه سلسله‌مراتب را راهنمایی می‌کند: لایهٔ بالاتر، توجه بیشتر. بدون هیچ نشانهٔ عمقی، چیدمان شلوغ ممکن است یکدست و سخت‌خوان شود—هرچند طراحی تخت آگاهانه هم مکتب خود را دارد و باید با ابزارهای دیگر مثل فاصله و تایپ جبران کند. سؤال این نیست که «همیشه سایه بله یا خیر»؛ بلکه این است که سایه کجا معنی لایه‌ای می‌دهد و کجا فقط نویز است.

در اپ بانکی، کارت موجودی با سایهٔ خیلی کم از لیست تراکنش جدا می‌شود. در ابزار طراحی، پنل شناور با سایهٔ قوی‌تر نشان می‌دهد روی بوم است. کاربر بدون فکر کردن لایه را می‌فهمد—اگر شدت‌ها در محصول یکدست باشند.

شدت، بلور، افست و جهت نور

سایهٔ قوی و تیره تأکید دراماتیک می‌سازد اما مینیمال را خفه می‌کند. سایهٔ پخش و ملایم جدایش نرم می‌دهد بدون دزدی توجه از محتوا. افست عمودی معمولاً منبع نور فرضی از بالا را القا می‌کند؛ افست عجیب جهت نور را می‌شکند و جعلی به نظر می‌رسد. چند لایه سایه—یکی نزدیک تیز، یکی دور نرم—در سیستم‌های مدرن رایج است تا به واقعیت نزدیک‌تر شود. تیم‌ها باید شدت را در بافت بسنجند: مودال مهم سایهٔ بیشتر؛ کارت لیست سایهٔ کمتر. آزمون چند نسخه جلوی افراط و تفریط را می‌گیرد.

سایهٔ رنگی یا tinted shadow گاهی با رنگ سطح هماهنگ می‌شود تا مصنوعی سیاه خالص نباشد؛ اما زیاده روی در رنگ سایه می‌تواند کثیف یا کم‌کنتراست شود. در تم تاریک، سایهٔ سیاه روی سیاه دیده نمی‌شود؛ اغلب از سطح روشن‌تر، بوردر ظریف یا glow بسیار خفیف به‌جای سایهٔ کلاسیک استفاده می‌شود. کپی کور قوانین تم روشن روی تم تاریک یکی از شکست‌های رایج است.

elevation در Material و لایه‌بندی پنجره

زبان‌های طراحی مثل Material Design سطوح elevation با سایهٔ متناظر تعریف می‌کنند تا سلسله‌مراتب در کل محصول یکدست بماند. دکمه، کارت، اپ‌بار، دیالوگ هر کدام سطح مشخصی دارند. وقتی دو پنل هم‌سطح سایهٔ متفاوت بگیرند، کاربر گیج می‌شود کدام در فوکوس است. سایهٔ لایه‌ای نشان می‌دهد کدام پنجره یا مودال روی بقیه است. در دسکتاپ، پنجرهٔ فعال سایهٔ قوی‌تر از غیرفعال دارد—بازتاب قرارداد سیستم‌عامل. در موبایل، bottom sheet و snackbar هم سطح elevation خود را می‌خواهند تا با محتوای زیر قاطی نشوند.

طراح سیستم باید جدول elevation را مستند کند: از سطح صفر تخت تا سطح مودال. توسعه‌دهنده توکن shadow.sm تا shadow.xl را به همان جدول bind می‌کند. انحراف بدون دلیل در یک صفحه، انسجام برند را می‌شکند حتی اگر آن صفحه به‌تنهایی زیبا باشد.

سایه به‌عنوان بازخورد تعامل، نه فقط تزیین

فراتر از زیبایی، سایه وضعیت و عمق را مخابره می‌کند. سایه در هاور می‌گوید عنصر تعاملی است. سایهٔ قوی‌تر روی کارت درگ‌شده می‌گوید در حال جابه‌جایی است. کاهش سایه در حالت pressed حس فرورفتن می‌دهد. این رفتار پویا ابهام «آیا می‌شود کلیک کرد؟» را کم می‌کند. با این حال سایه نباید تنها نشانهٔ تعامل باشد. کاربر کم‌بینا یا با صفحهٔ کم‌کنتراست ممکن است سایهٔ ظریف را نبیند. جفت کردن با تغییر رنگ، outline، یا حرکت کوتاه، فراگیری را حفظ می‌کند.

در جدول داده، هاور ردیف گاهی فقط پس‌زمینه عوض می‌کند؛ افزودن سایه به ردیف شلوغ معمولاً زیاده‌روی است. سایه را برای اجزایی بگذارید که واقعاً لایه عوض می‌کنند—منوی باز، پاپاور، دیالوگ—نه برای هر هاور جزئی.

دسترس‌پذیری و کنتراست کنار سایه

سایه به‌تنهایی برای همه کافی نیست. باید با نشانه‌های دیگر همراه شود. همچنین متن روی تصویری که زیر سایه یا گرادیان نشسته باید همچنان خوانا بماند؛ سایهٔ تزئینی نباید کنتراست متن را بکشد. در حالت تمرکز کیبورد، outline واضح مهم‌تر از سایه است. اگر محصول شما فقط با سایه هاور «زیبا» است و focus visible ندارد، دسترس‌پذیری صفحه‌کلید شکست خورده است. بررسی با شبیه‌سازی کم‌بینایی و تست واقعی صفحه‌خوان و کیبورد بخشی از تعریف انجام‌شدهٔ کامپوننت‌های دارای سایه است.

کاربران حساس به حرکت ممکن است انیمیشن سایهٔ سنگین را آزاردهنده ببینند؛ احترام به کاهش حرکت سیستم‌عامل یعنی انتقال elevation کوتاه یا بدون افکت پیچیده.

عملکرد رندر و محدودیت دستگاه

سایه‌های پیچیده—به‌ویژه متحرک و چندلایه—روی دستگاه ضعیف هزینهٔ رندر دارند. بلور بزرگ گران است. طراح و توسعه‌دهنده باید زیبایی را با کارایی سبک کنند و روی پلتفرم‌های هدف بسنجند. تکنیک‌هایی مثل استفاده از shadow توکن آماده به‌جای سایهٔ یکتا در هر کارت، کش بهتر و یکدستی می‌آورد. در لیست بلند مجازی‌سازی‌شده، سایهٔ سنگین روی هر ردیف اسکرول را جریمه می‌کند؛ اغلب بوردر یا جدایش رنگی سبک‌تر است. انیمیشن elevation هنگام اسکرول مداوم را با احتیاط به کار ببرید.

در وب، box-shadow با لایهٔ زیاد می‌تواند بیش از filter عمل کند یا برعکس—بسته به سناریو پروفایل کنید. در اپ بومی، API سایهٔ سیستم معمولاً بهینه‌تر از شبیه‌سازی دستی است.

سایه در هویت بصری و آنتی‌پترن‌ها

سایه‌ها بخشی از زبان بصری برندند. محصولی با سایه‌های نرم پخش حس متفاوتی از محصولی با سایهٔ تیز و تیره دارد. سیستم طراحی شدت و رنگ سایه را قفل می‌کند تا صفحهٔ بازاریابی و اپ یک خانواده بمانند. آنتی‌پترن: سایه دور هر جعبه تا صفحه ابری شود؛ سایهٔ رنگی نئونی بی‌ربط به برند؛ تکیه به سایه برای جبران فاصله‌گذاری ضعیف؛ و کپی سایهٔ تم روشن در تم تاریک. آنتی‌پترن دیگر حذف کامل هرگونه جدایش بدون جایگزین است؛ تخت افراطی هم می‌تواند سلسله‌مراتب را بکشد.

در طراحی فارسی RTL، جهت افست افقی سایه معمولاً هنوز از قرارداد نور بالا پیروی می‌کند و با جهت نوشته عوض نمی‌شود؛ اما اگر سایه معنای جهت‌دار مثل «برگه از چپ می‌آید» دارد، با انیمیشن ورود هماهنگ کنید تا متناقض نباشد.

هماهنگی با shade رنگ و جمع‌بندی

سایهٔ عمق و سایهٔ رنگ مکمل‌اند نه جایگزین. دکمه می‌تواند هم shade تیره‌تر در pressed داشته باشد هم سایهٔ elevation در حالت عادی. قاطی کردن واژه‌ها در جلسه باعث می‌شود توسعه‌دهنده رنگ را عوض کند وقتی منظور elevation بوده یا برعکس. در نقد، صریح بگویید کدام. برای بازبینی عملی: جدول elevation را با سه صفحهٔ واقعی چک کنید، هاور و فوکوس را بدون اتکا به سایه alone بسنجید، تم تاریک را جدا بررسی کنید، و عملکرد لیست‌های بلند را روی دستگاه میانی اندازه بگیرید.

سایه‌ها وقتی درست به‌کار روند، عمق، تمرکز و بازخورد می‌سازند بدون اینکه محتوا را گم کنند. در واژه‌نامهٔ مارجین آکادمی آن‌ها را کنار elevation، لایه‌بندی و سیستم طراحی بخوانید و از shade رنگ جدا نگه دارید. محصول منسجم سایه‌اش را مثل تایپ و فاصله جدی می‌گیرد—توکن دارد، استثنا دارد، و دلیل دارد. بدون دلیل، سایه فقط لکه است.

اگر یک عادت در تیم نهادینه کنید این باشد: قبل از افزودن box-shadow جدید، بپرسید آیا توکن موجود همان کار را می‌کند. انفجار سایه‌های یکتا در فایل‌ها همان آشوبی را می‌سازد که پالت هکس پراکنده برای رنگ می‌سازد. نظم elevation نشانهٔ بلوغ UI است؛ هرج‌ومرج سایه نشانهٔ تصمیم‌های لحظه‌ای بدون سیستم.

در آموزش تازه‌واردان، یک تمرین ساده کافی است: یک کارت، یک دکمه، یک مودال را با سه سطح سایه بسازند و توضیح دهند چرا آن سطح را انتخاب کردند. اگر جواب فقط «زیباتر شد» باشد، هنوز معیار سلسله‌مراتب نهادینه نشده است. اگر جواب «مودال باید بالای صفحه بماند و کارت لیست پایین‌تر» باشد، زبان elevation جا افتاده است—و همان زبان جلوی بحث سلیقه‌ای بی‌پایان را در اسپرینت‌های بعد می‌گیرد.