منبع: بنیاد طراحی تعامل (IxDF) · بازنویسی آزاد: سپنتا پویا · مرداد ۱۴۰۵ · زمان مطالعه: حدود ۱۳ دقیقه

طراحی واکنش‌گرا (Responsive Design) چیست؟

💡 این متن «بازنویسی آزاد» است: ایده‌ها و مفاهیم مطلب اصلی با نگارش کاملاً مستقل فارسی و مثال‌های تازه بازگو شده‌اند و ترجمهٔ کلمه‌به‌کلمه نیست. بخش‌های افزودهٔ مترجم در جعبهٔ منبع مشخص شده‌اند.

طراحی واکنش‌گرا (Responsive Design) یعنی یک صفحه را چنان بسازیم که خودش را با فضایی که در اختیارش گذاشته‌اند جور کند: همان محتوا، همان نشانی، اما چیدمانی که روی نمایشگر بیست‌ونه اینچی و روی گوشی‌ای که در مترو با یک دست گرفته‌اید، هر دو خوانا و قابل‌استفاده باشد. تعریفش تقریباً همیشه با کلمهٔ «تطبیق» گفته می‌شود، اما کلمهٔ دقیق‌تر «انعطاف» است؛ صفحهٔ واکنش‌گرا از پیش نمی‌داند به کجا می‌رود و به همین دلیل باید بتواند در هر ظرفی جا شود.

این تمایز ظریف، واکنش‌گرایی را از کاری که خیلی‌ها به اسمش انجام می‌دهند جدا می‌کند. کوچک کردن یک صفحهٔ رومیزی تا وقتی روی موبایل «بیرون نزند»، واکنش‌گرا نیست؛ فشرده‌سازی است. طراحی واکنش‌گرا وقتی شروع می‌شود که بپذیرید در عرض ۳۶۰ پیکسل، بعضی از چیزهایی که در ۱۴۴۰ پیکسل کنار هم بودند باید زیر هم بروند، بعضی‌شان باید پشت یک تعامل پنهان شوند و بعضی‌شان اصلاً نباید آنجا باشند. یعنی واکنش‌گرایی پیش از آنکه یک مسئلهٔ CSS باشد، یک مسئلهٔ اولویت‌بندی محتواست.

چه چیزی را حل می‌کند و از کجا آمد

تا اواخر دههٔ ۲۰۰۰، فرض غالب در وب این بود که صفحه با عرض ثابت ساخته می‌شود — عددی مثل ۹۶۰ پیکسل که با نمایشگرهای آن دوره جور بود. وقتی گوشی‌های هوشمند آمدند، اولین واکنش صنعت این بود که برای موبایل یک سایت جداگانه بسازد؛ همان نشانی‌های m.example.com که هنوز جابه‌جا رد پایشان پیداست. آن راه‌حل روی کاغذ منطقی بود و در عمل دو خرج جداگانه داشت: دو پایگاه کد، دو مسیر انتشار محتوا، و مجموعه‌ای از خطاهای همیشگی مثل لینکی که از موبایل باز می‌شد و کاربر را به نسخهٔ رومیزی می‌انداخت.

در سال ۲۰۱۰ اتان مارکات (Ethan Marcotte) پیشنهاد دیگری مطرح کرد: به‌جای ساختن چند سایت برای چند دستگاه، یک سایت بسازیم که ذاتاً انعطاف‌پذیر باشد. سه عنصر فنی این ایده — شبکهٔ سیال، تصویر سیال و مدیا کوئری — هیچ‌کدام اختراع تازه‌ای نبودند؛ نوآوری در ترکیب و در آن تغییر نگرش بود که می‌گفت عرض صفحه یک عدد نیست، یک بازه است. نکتهٔ جالب اینکه استدلال اصلی آن روزها فنی نبود؛ اقتصادی و ویرایشی بود. یک منبع محتوایی واحد یعنی یک بار نوشتن، یک بار نگهداری، و یک نشانی که همه‌جا کار می‌کند.

امروز که تنوع دستگاه‌ها از تلویزیون و ساعت گرفته تا نمایشگرهای فوق‌عریض گسترده شده، همان استدلال قوی‌تر هم شده است. هیچ تیمی نمی‌تواند برای هر اندازه‌ای یک نسخه نگه دارد؛ تنها راه پایدار این است که طرح، خودش با اندازه کنار بیاید.

سه ستونی که واکنش‌گرایی روی آن ایستاده است

زیر همهٔ پیچیدگی‌های امروزی، ساختار پایه هنوز همان سه چیز است:

• - ۱. شبکهٔ سیال: ستون‌ها به‌جای عدد ثابت، سهم نسبی می‌گیرند. ستون کناری «۳۰۰ پیکسل» نیست، «یک‌سوم فضای موجود» است. همین یک تغییر باعث می‌شود صفحه به‌جای اینکه فقط در چند اندازهٔ مشخص درست به نظر برسد، در همهٔ اندازه‌های میانی هم سالم بماند.
• - ۲. تصویر سیال: تصویر نباید از ظرفش بزرگ‌تر شود. قاعدهٔ حداقلی‌اش یک خط است (max-width: 100%)، اما نسخهٔ درست‌ترش این است که برای اندازه‌های مختلف، فایل‌های مختلف بفرستید؛ ارسال یک عکس ۲۰۰۰ پیکسلی به گوشی‌ای که فقط ۳۶۰ پیکسل از آن را نشان می‌دهد، هم پول کاربر است و هم زمان او. برای آیکون و نشانه‌ها هم SVG بهترین انتخاب است، چون در هر اندازه‌ای تیز می‌ماند و معمولاً از تصویر نقطه‌ای هم سبک‌تر است.
• - ۳. مدیا کوئری: شرط‌هایی در CSS که می‌گویند در فلان بازهٔ عرض، چیدمان طور دیگری بشود. این همان جایی است که سه ستون به دو ستون و بعد به یک ستون تبدیل می‌شود. عرضی که در آن چیدمان عوض می‌شود را «نقطهٔ شکست» (breakpoint) می‌نامیم.

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

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

نقطهٔ شکست را محتوا تعیین می‌کند، نه دستگاه

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

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

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

موبایل‌اول: ترتیب تصمیم، نه ترتیب ساخت

«موبایل‌اول» را معمولاً یک دستورالعمل فنی می‌فهمند: اول CSS موبایل را بنویس، بعد با مدیا کوئری برای اندازه‌های بزرگ‌تر اضافه کن. این توصیه درست است و کد تمیزتری می‌سازد، اما ارزش اصلی‌اش جای دیگری است.

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

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

در سطح وایرفریم هم همین ترتیب کمک می‌کند: نسخهٔ موبایل را اول بکشید، ولی هر دو نسخه را کنار هم نگه دارید، چون تصمیم‌های موبایل روی چیدمان بزرگ اثر می‌گذارند و برعکس.

پیکسل کدام پیکسل؟ رزولوشن، ویوپورت و چگالی

این بخش در منبع اصلی به این شکل نیست و از سوءتفاهم‌هایی می‌آید که مدام بین طراح و برنامه‌نویس تکرار می‌شود. سه عدد متفاوت وجود دارد که همه‌شان «پیکسل» نامیده می‌شوند و یکی نیستند:

• - رزولوشن سخت‌افزاری: تعداد واقعی نقطه‌های نمایشگر؛ همان چیزی که در مشخصات فنی می‌نویسند، مثل 1080p یا 4K.
• - عرض ویوپورت: عرضی که CSS می‌بیند و مدیا کوئری بر اساس آن تصمیم می‌گیرد. گوشی‌ای با نمایشگر ۱۱۷۰ نقطه‌ای ممکن است ویوپورتی حدود ۳۹۰ داشته باشد.
• - نسبت پیکسل دستگاه: ضریب میان آن دو. وقتی این نسبت ۳ است، برای اینکه تصویر تار نشود باید فایل سه‌برابری بفرستید — و دقیقاً به همین دلیل است که «کیفیت پایین» و «حجم زیاد» در موبایل دو روی یک سکه‌اند.

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

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

جایی که واکنش‌گرایی جواب نمی‌دهد

این بخش هم افزودهٔ مترجم است. واکنش‌گرایی راه‌حل پیش‌فرض درستی است، اما راه‌حل همه‌چیز نیست و چند مورد شناخته‌شده دارد:

• - وقتی زمینهٔ استفاده فرق می‌کند، نه فقط اندازهٔ صفحه: کسی که در ایستگاه اتوبوس سراغ سایت بانک می‌رود می‌خواهد مانده را ببیند؛ همان آدم پشت میز می‌خواهد گزارش سالانه بگیرد. اینجا مسئله چیدمان نیست، اولویت است. پاسخ درست معمولاً تغییر ترتیب و برجستگی است، نه صرفاً زیر هم بردن ستون‌ها.
• - جدول‌های داده‌ای بزرگ: جدول ده‌ستونی در عرض ۳۶۰ پیکسل واقعاً واکنش‌گرا نمی‌شود. هر سه راه‌حل رایج — اسکرول افقی، تبدیل هر سطر به کارت، و پنهان‌کردن ستون‌های کم‌اهمیت — بده‌بستان دارند؛ باید یکی را آگاهانه انتخاب کنید، نه اینکه امیدوار باشید CSS حلش کند.
• - ابزارهای دقیق: ویرایش ویدیو، طراحی نقشه، صفحهٔ گستردهٔ حرفه‌ای. اینها به اشاره‌گر دقیق و فضای زیاد وابسته‌اند و نسخهٔ موبایلشان معمولاً باید محصول دیگری با دامنهٔ کوچک‌تر باشد، نه همان محصول در قابی کوچک‌تر.
• - هزینهٔ پنهان کارایی: واکنش‌گرا بودن به‌خودی‌خود سرعت نمی‌آورد. اگر همان صفحهٔ سنگین رومیزی را با چیدمان تازه به موبایل بفرستید، کاربر روی شبکهٔ ضعیف همان مدت منتظر می‌ماند. آنچه کاربر «کند بودن سایت» می‌نامد، معمولاً همین است.

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

واکنش‌گرایی در وب فارسی و راست‌به‌چپ

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

ویژگی‌های جهت‌دار. هر جا در استایل‌ها left و right نوشته باشید، در راست‌به‌چپ آینه نمی‌شود و باید دستی وارونه‌اش کنید — که یعنی دو برابر کد و دو برابر جای خراب‌شدن. معادل‌های منطقی (start و end) این کار را خودکار می‌کنند و امروز پشتیبانی‌شان کامل است. اگر یک تصمیم فنی از این نوشته بردارید، همین باشد.

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

اعداد و متن دوجهته. ترکیب فارسی و لاتین در یک سطر — «۱۲ گیگابایت»، شمارهٔ سفارش، نشانی ایمیل — در فضای تنگ موبایل به‌راحتی جابه‌جا می‌شود. پرانتز و علامت‌های نگارشی هم در همین حالت سر از جای اشتباه درمی‌آورند. تکه‌های لاتین را صریحاً علامت‌گذاری کنید و نتیجه را در باریک‌ترین حالت ببینید، نه فقط در ماکت.

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

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

جمع‌بندی

طراحی واکنش‌گرا در نهایت یک اعتراف است: ما نمی‌دانیم کاربر با چه چیزی سراغمان می‌آید. شبکهٔ سیال، تصویر سیال و مدیا کوئری ابزارهای این اعتراف‌اند، اما کار اصلی جای دیگری انجام می‌شود — در تصمیم دربارهٔ اینکه چه چیزی اول دیده شود، چه چیزی می‌تواند صبر کند و چه چیزی اصلاً لازم نیست.

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