یک صفحه خدمات را روی گوشی باز کنید: عنوان چند خط می‌شود، کارت‌ها زیر هم می‌آیند و دکمه تماس پایین صفحه قرار می‌گیرد. اگر این تغییر فقط کوچک‌کردن نسخه دسکتاپ باشد، معمولاً ترتیب محتوا و مسیر اقدام کاربر به مشکل می‌خورد. Mobile-first از محدودیت فضا برای روشن‌کردن اولویت‌ها استفاده می‌کند؛ ابتدا مشخص می‌کنید چه اطلاعاتی برای تصمیم لازم است و سپس در فضای بیشتر، چیدمان را گسترش می‌دهید.
برای دفاع از این روش نیازی به آمار عمومی و بدون منبع نداریم. سهم ترافیک موبایل در هر محصول متفاوت است و باید از داده همان سایت فهمیده شود. یک داشبورد داخلی ممکن است بیشتر روی نمایشگر بزرگ استفاده شود؛ یک فرم ثبت سفارش ممکن است بیشتر روی گوشی باز شود. Responsive Design باید هر دو وضعیت را پوشش دهد. Mobile-first یک روش طراحی و پیاده‌سازی است، نه تضمین تجربه مناسب یا رتبه بهتر در جست‌وجو.
ابتدا مسیر کاربر را مشخص کنید
برای صفحه خدمات، شاید مسیر اصلی شامل فهم پیشنهاد، بررسی چند ویژگی و ارسال درخواست باشد. برای فروشگاه، جست‌وجو، مقایسه و خرید اهمیت دارند. این مسیر را قبل از انتخاب تعداد ستون‌ها بنویسید. اگر همه عناصر در صفحه کوچک هم‌وزن باشند، کاربر باید خودش اولویت را پیدا کند. تصمیم درباره عنوان، توضیح کوتاه و دکمه اصلی باید بر هدف صفحه تکیه کند، نه صرفاً اندازه صفحه نمایش.
حذف اطلاعات ضروری برای جا دادن محتوا، روش مناسبی نیست. می‌توانید ترتیب نمایش، میزان جزئیات اولیه یا شکل دسترسی به اطلاعات تکمیلی را تغییر دهید. اما هزینه، محدودیت خدمت و پیام خطای فرم نباید فقط در نسخه دسکتاپ وجود داشته باشند. صفحه کوچک هم باید برای انجام کار اصلی کافی باشد. در راهنمای طراحی وب‌اپلیکیشن Mobile-first می‌توانید این نگاه را برای مسیرهای تعاملی ادامه دهید.
Breakpoint را از شکست محتوا پیدا کنید
راهنمای Media Queries در web.dev انتخاب Breakpoint بر اساس محتوا را توصیه می‌کند. به‌جای ساختن فهرستی از مدل گوشی و تبلت، ببینید چه زمانی چیدمان فعلی دیگر کار نمی‌کند. شاید سه کارت با متن کوتاه در عرضی مشخص جا شوند، ولی همان کارت‌ها با عنوان بلند فارسی به فضای بیشتری نیاز داشته باشند. عدد مناسب، حاصل نیاز همین محتواست و قانون مشترک همه پروژه‌ها نیست.
این تصمیم را با دو حالت افراطی بررسی کنید: کوتاه‌ترین و بلندترین محتوای قابل انتظار. نام طولانی، قیمت چندرقمی، پیام خطا و زبان دوم اغلب مشکلاتی را نشان می‌دهند که در متن نمونه دیده نمی‌شوند. فاصله بین دو Breakpoint هم مهم است. طراحی نباید فقط در سه اندازه مشهور مناسب باشد و در عرض میانی، دکمه‌ها یا ستون‌ها روی هم بیفتند. از عرض‌های انعطاف‌پذیر و محدودیت منطقی برای Container استفاده کنید.
Viewport و اندازه‌ها را درست تنظیم کنید
Meta viewport به مرورگر موبایل کمک می‌کند عرض Layout را با دستگاه هماهنگ کند. این تنظیم جای CSS را نمی‌گیرد. با width ثابت برای کارت یا min-width نامناسب هنوز می‌توانید Overflow ایجاد کنید. همچنین Zoom را با maximum-scale یا user-scalable=no محدود نکنید؛ کاربر ممکن است برای خواندن به بزرگ‌نمایی نیاز داشته باشد. طراحی باید با این نیاز کنار بیاید.
برای متن و فاصله‌ها، واحد نسبی معمولاً ارتباط بهتری با تنظیمات کاربر دارد. این انتخاب به معنی ممنوع‌بودن px نیست؛ اندازه خط مرزی با اندازه بدنه متن مسئله یکسانی ندارد. اگر از clamp استفاده می‌کنید، حداقل و حداکثر را با نیاز واقعی انتخاب کنید. حداقل بسیار کوچک یا رشد شدید بر اساس Viewport ممکن است عنوان را ناخوانا یا بیش‌ازحد بزرگ کند. مقدار انتخابی باید در محتوای واقعی قابل استفاده باشد.
لمس، ماوس و صفحه‌کلید را مستقل ببینید
عرض صفحه به شما نمی‌گوید کاربر حتماً با انگشت کار می‌کند. لپ‌تاپ لمسی، تبلت همراه صفحه‌کلید و مرورگر کوچک‌شده روی دسکتاپ نمونه‌های معمول‌اند. منو یا توضیح ضروری را فقط روی Hover قرار ندهید. کنترل‌ها باید با صفحه‌کلید هم قابل استفاده باشند و Focus مشخص داشته باشند. استفاده از button و a واقعی، پایه مناسب‌تری از یک div با رویداد کلیک است؛ ظاهر را می‌توانید با CSS تغییر دهید.
در معیار اندازه حداقل هدف در WCAG 2.2، اندازه ۲۴ در ۲۴ CSS Pixel یا شرایط جایگزین و استثنا مطرح است. عدد ۴۴ را به‌عنوان الزام عمومی همین معیار معرفی نکنید. در محصول، هدف بزرگ‌تر می‌تواند برای لمس راحت‌تر انتخاب شود. فاصله بین کنترل‌ها و موقعیت آن‌ها نیز اهمیت دارد؛ دکمه بزرگ ولی چسبیده به اقدام خطرناک هنوز احتمال انتخاب اشتباه دارد.
نمونه کامل: صفحه معرفی سه خدمت
کد زیر یک فایل مستقل است. آن را با نام index.html ذخیره کنید و در مرورگر باز کنید؛ ابزار Build، کتابخانه، تصویر یا فونت خارجی لازم ندارد. ابتدا یک ستون نمایش داده می‌شود و پس از عرض انتخاب‌شده برای محتوای نمونه، سه ستون ایجاد می‌شود. هر کارت، عنوان، توضیح و لینک واقعی به بخش درخواست دارد. این نمونه فقط چیدمان و پیمایش داخل صفحه را نشان می‌دهد و فرم ارسال به Server ندارد.
<!doctype html>
<html lang="fa" dir="rtl">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>نمونه خدمات Responsive</title>
<style>
* { box-sizing: border-box; }
html { scroll-padding-block-start: 1rem; }
body { margin: 0; font: 1rem/1.8 sans-serif; color: #162535; background: #f3f6f9; }
.page { max-inline-size: 72rem; margin-inline: auto; padding: clamp(1rem, 3vw, 2rem); }
h1 { font-size: clamp(1.7rem, 1.2rem + 2vw, 2.7rem); line-height: 1.4; }
.intro { max-inline-size: 42rem; }
.cards { display: grid; grid-template-columns: minmax(0, 1fr); gap: 1rem; }
.card { display: flex; flex-direction: column; padding: 1.25rem; border: 1px solid #bbc7d4;
border-radius: .75rem; background: white; overflow-wrap: anywhere; }
.card h2 { margin-block-start: 0; font-size: 1.25rem; }
.card p { flex: 1; }
.action { display: inline-block; min-block-size: 2.75rem; padding: .65rem 1rem;
border-radius: .4rem; color: white; background: #164c85; text-align: center; }
a:focus-visible { outline: 3px solid #8b3100; outline-offset: 4px; }
#request { margin-block-start: 2rem; padding: 1rem; background: white; }
@media (min-width: 52rem) { .cards { grid-template-columns: repeat(3, minmax(0, 1fr)); } }
</style>
</head>
<body>
<main class="page">
<h1>خدمات طراحی برای یک سایت قابل استفاده</h1>
<p class="intro">این صفحه نمونه، سه خدمت را معرفی می‌کند و شما را به توضیح مسیر درخواست می‌برد.</p>
<section class="cards" aria-label="خدمات">
<article class="card"><h2>طراحی رابط کاربر</h2>
<p>چیدمان صفحه‌ها و وضعیت‌های اصلی با توجه به محتوای واقعی پروژه.</p>
<a class="action" href="#request">درخواست طراحی رابط</a></article>
<article class="card"><h2>بازبینی تجربه کاربر و مسیر تکمیل فرم</h2>
<p>بررسی اینکه کاربر چه اطلاعاتی لازم دارد و کجا مسیر اقدام متوقف می‌شود.</p>
<a class="action" href="#request">درخواست بازبینی</a></article>
<article class="card"><h2>راهنمای اجزای سایت</h2>
<p>ثبت قواعد دکمه، فرم، کارت و متن برای اجرای هماهنگ صفحه‌ها.</p>
<a class="action" href="#request">درخواست راهنمای اجزا</a></article>
</section>
<section id="request" tabindex="-1"><h2>مسیر درخواست</h2>
<p>در نسخه واقعی، فرم یا اطلاعات تماس معتبر اینجا قرار می‌گیرد. این نمونه فقط پیمایش داخل صفحه دارد.</p>
</section>
</main>
</body>
</html>
در این فایل، کلاس card واقعاً در HTML وجود دارد و هیچ Selectorای به Markup جاافتاده وابسته نیست. minmax با حداقل صفر کمک می‌کند ستون‌ها از حداقل اندازه محتوای خود بیش‌ازحد بزرگ نشوند. لینک‌ها هنگام بزرگ‌شدن متن می‌توانند چند خط شوند و ارتفاع ثابت ندارند. با این حال، انتخاب Breakpoint این نمونه را به‌عنوان نسخه آماده همه سایت‌ها کپی نکنید؛ عنوان‌ها، تعداد کارت‌ها و مسیر کاربر پروژه خودتان را جایگزین کنید.
چیدمان بصری ترتیب DOM را عوض نمی‌کند. کاربر صفحه‌کلید و ابزار کمکی باید با همان ترتیب معنادار محتوا روبه‌رو شود. اگر برای نسخه بزرگ، کارت مهم را با order به جای دیگری ببرید، مسیر Focus ممکن است با آنچه دیده می‌شود متفاوت باشد. برای ادامه طراحی ستون‌ها، راهنمای CSS Grid و راهنمای Flexbox نمونه‌های مرتبط دارند.
تصویر Responsive فقط عرض صددرصد نیست
در صفحه واقعی، تصویر ممکن است سهم بزرگی از دانلود اولیه داشته باشد. کوچک‌کردن نمایش یک فایل بزرگ، اندازه دانلود آن را خودکار کم نمی‌کند. srcset و sizes برای انتخاب منبع متناسب کمک می‌کنند و picture برای تغییر منبع یا ترکیب‌بندی کاربرد دیگری دارد. راهنمای تصاویر Responsive این قراردادها را توضیح می‌دهد. ابعاد تصویر را نیز مشخص کنید تا فضای آن از قبل در Layout معلوم باشد.
Lazy loading را هم به همه تصاویر تعمیم ندهید؛ تصویری که در ابتدای صفحه برای دیدن محتوا لازم است، با تصویر پایین صفحه نیاز یکسانی ندارد. اگر تصویر اطلاعاتی را منتقل می‌کند، جایگزین متنی متناسب بنویسید. برای تصویر تزئینی، توضیح اضافه به ابزار کمکی ممکن است مزاحم باشد. تصمیم درباره تصویر باید شامل حجم، جایگاه، معنا و رفتار در چند عرض باشد، نه صرفاً انتخاب یک افکت Crop.
فرم و جدول به تصمیم مخصوص خود نیاز دارند
فرم کوچک‌شده دسکتاپ ممکن است Label را از Input جدا کند یا پیام خطا را دور از محل ورود نشان دهد. Label، توضیح و خطا را در ارتباط روشن نگه دارید و از Placeholder به‌عنوان تنها نام فیلد استفاده نکنید. نوع Input را متناسب انتخاب کنید، ولی انتظار نداشته باشید صفحه‌کلید مجازی یا Validation مرورگر همه قواعد کسب‌وکار را پوشش دهد. وضعیت ارسال و خطای شبکه نیز باید در صفحه کوچک معلوم باشد.
برای جدول، ستون‌ها را بدون شناخت کار کاربر حذف نکنید. یک جدول مقایسه ممکن است به Scroll افقی نیاز داشته باشد؛ یک فهرست سوابق ممکن است در عرض کوچک به نمایش ردیفی تبدیل شود. معیار Reflow نیز برای محتوایی که ذاتاً به چیدمان دوبعدی نیاز دارد استثنا دارد. این استثنا به معنی مجوز Overflow کل صفحه یا پنهان‌شدن کنترل‌های اطراف جدول نیست.
تحویل طراحی را با رفتارها کامل کنید
برای تیم اجرا، فقط تصویر سه اندازه نفرستید. ترتیب محتوا، رفتار منو، وضعیت Loading، پیام‌های بلند، حد عرض متن و قواعد تصویر را هم ثبت کنید. وقتی کارت‌ها ارتفاع متفاوت دارند، چه چیزی باید تراز بماند؟ اگر زبان عوض شود، جهت و فاصله‌ها چگونه تغییر کنند؟ این سؤال‌ها تصمیم‌های طراحی‌اند و اگر رها شوند، هر صفحه پاسخ متفاوتی پیدا می‌کند. راهنمای CSS Logical Properties برای بخش جهت متن مرتبط است.
در برنامه بررسی خود، مسیر واقعی را دنبال کنید: کاربر اطلاعات را می‌خواند، به بخش لازم می‌رود و اقدام را کامل می‌کند. بزرگ‌نمایی، طول متن و ورودی صفحه‌کلید را کنار اندازه Viewport قرار دهید. صفحه‌ای که در تصویر کوچک مرتب به نظر می‌رسد، ممکن است با متن واقعی کار نکند. معیار پایان طراحی، قابل انجام‌بودن کار اصلی در شرایط پیش‌بینی‌شده است؛ افزودن یک Media Query دیگر به‌تنهایی این نتیجه را ثابت نمی‌کند.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!