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

طراحی وب (Web Design) چیست؟

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

در فهرست توصیه‌های طراحی واکنش‌گرا، یک قلم هست که به‌نظرم خطرناک‌ترین توصیهٔ کل این متن است: «محتوا را اولویت‌بندی و پنهان کنید تا با بافت کاربر بخواند.»

چون پنهان‌کردن، اولویت‌بندی نیست — و در ادامه می‌گویم چرا.

تعریف

طراحی وب به طراحی وب‌سایت‌ها اشاره دارد، و معمولاً به جنبه‌های تجربهٔ کاربری ساخت سایت مربوط است نه به توسعهٔ نرم‌افزار. تا میانهٔ دههٔ ۲۰۱۰ تمرکزش بر مرورگر دسکتاپ بود؛ از آن پس، طراحی برای موبایل و تبلت اهمیت فزاینده گرفت.

طراح وب روی سه چیز کار می‌کند: ظاهر (رنگ، تایپوگرافی، تصویر) · چیدمان (اینکه اطلاعات چگونه ساخت‌یافته و دسته‌بندی می‌شود) · و در برخی موارد محتوا. و سایت خوب ساده است، روشن حرف می‌زند، اعتماد مخاطب هدف را جلب می‌کند و تا حد ممکن نقاط سرخوردگی را حذف می‌کند.

طراحی واکنش‌گرا

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

و توصیه‌های منبع برای اجرایش:

• - رویکرد موبایل‌اول را بگیرید — طراحی را از موبایل شروع کنید نه از دسکتاپ.
• - شبکه و تصویر شنا‌کننده بسازید.
• - به گرافیک برداری مقیاس‌پذیر (SVG) اولویت بدهید.
• - سه نقطهٔ شکست یا بیشتر داشته باشید.
• - محتوا را اولویت‌بندی و پنهان کنید تا با بافت کاربر بخواند؛ سلسله‌مراتب بینایی را بررسی کنید و از آشکارسازی تدریجی و کشوی ناوبری استفاده کنید.
• - به کمینه‌گرایی برسید و الگوهای طراحی جاافتاده را به‌کار ببرید (مثل الگوی افتادن ستون).
• - و دسترس‌پذیری را هدف بگیرید.

طراحی انطباقی

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

• - در واکنش‌گرا، محتوا و کارکرد برای همهٔ دستگاه‌ها یکی است؛ تنها چیدمان عوض می‌شود.
• - در انطباقی، هم دستگاه و هم بافت کاربر در نظر گرفته می‌شود — یعنی محتوا و کارکرد می‌توانند به‌کل متفاوت باشند.

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

دسترس‌پذیری

منبع فهرست پایهٔ W3C را می‌آورد، با این نقل‌قول از تیم برنرز‌لی: «قدرت وب در جهان‌شمولی‌اش است. دسترسی همه، مستقل از ناتوانی، جنبه‌ای اساسی است.»

• - تباین کافی میان پیش‌زمینه و پس‌زمینه، و آزمودنش با ابزار سنجش نسبت تباین.
• - رنگ به‌تنهایی حامل معنا نباشد — پیوند را علاوه بر رنگ با زیرخط هم نشان دهید تا کوررنگ هم آن را ببیند.
• - عناصر تعامل‌پذیر آسان تشخیص داده شوند — سبک متفاوت در حالت اشاره و در حالت تمرکز با صفحه‌کلید.
• - ناوبری روشن و سازگار — چیدمان و نام‌گذاری یکسان؛ اگر خرده‌نان دارید، همیشه در یک جا باشد.
• - برچسب هر فیلد فرم روشن و مرتبط باشد — منبع پیشنهاد می‌دهد برچسب را سمت چپ فیلد بگذارید (برای زبان‌های چپ‌به‌راست) نه بالای آن و نه داخلش.
• - بازخورد آسان‌تشخیص — پیام خطای ریز یا رنگ‌محور برای کسی با بینایی کم یا کوررنگی کار نمی‌کند.
• - سرنویس و فاصله‌گذاری برای گروه‌بندی محتوای مرتبط.
• - طراحی برای اندازه‌های مختلف نما، و جایگزین متنی برای تصویر و رسانه (با متنی که معنا را منتقل کند نه اینکه تصویر را توصیف کند).
• - و کنترل برای محتوایی که خودکار شروع می‌شود — کاربر بتواند پویانمایی یا ویدئو را متوقف کند.

پنهان‌کردن، اولویت‌بندی نیست

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

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

قاعده‌ای که به‌نظرم درست است: قالب را پنهان کنید، محتوا را نه.

• - قالب یعنی ناوبری فرعی، نوار کنار، فیلترهای پیشرفته، تزئین. اینها می‌توانند در کشو بروند.
• - محتوا یعنی چیزی که کاربر برای آن آمده. اگر پنهانش کنید، صفحه را حذف کرده‌اید، نه ساده.

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

مرز واقعی واکنش‌گرا و انطباقی: حذف محتوا

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

اما یک تفکیک هست که ارزش برجسته‌کردن دارد، و همان تفکیکی است که منبع می‌گوید و رهایش می‌کند: واکنش‌گرا محتوای یکسان با چیدمان متفاوت است؛ انطباقی می‌تواند محتوای متفاوت باشد. و به محض اینکه محتوا متفاوت شد، شما یک تصمیم فنی نگرفته‌اید — تصمیم گرفته‌اید چه کسی چه چیزی بگیرد.

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

• - اگر چیزی که حذف می‌شود تزئین است، حذفش کنید. تصویر قهرمان، پویانمایی، ویدئوی پس‌زمینه.
• - و اگر جوابِ پرسش کاربر است، حذفش نکنید — ارزانش کنید. اینفوگرافیکی که داده در آن است، جواب است. راهش تبدیلش به متن و جدول است، نه جایگزین‌کردنش با خلاصه.

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

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

این بخش هم افزودهٔ مترجم است. «سه نقطهٔ شکست یا بیشتر (چیدمان برای سه دستگاه یا بیشتر)» واحد اندازه‌گیری را اشتباه انتخاب می‌کند: دستگاه.

مسئله این است که دستگاه‌ها ثابت نمی‌مانند و بازهٔ اندازه‌ها پیوسته است — و همین طرز فکر است که آن «چیدمان تبلت» را می‌سازد که هیچ‌کس ازش استفاده نمی‌کند: چیدمانی که برای دسته‌ای از دستگاه‌ها ساخته شده، نه برای اندازه‌ای که محتوا در آن مشکل پیدا می‌کند.

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

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

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

در بافت فارسی: پنج چیزی که وب فارسی جداگانه لازم دارد

این بخش هم افزودهٔ مترجم است.

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

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

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

چهار: ارقام. سه دستگاه رقم در دسترس است و ترکیبشان در یک صفحه رایج‌ترین بی‌نظمی بینایی سایت‌های ماست. یک دستگاه انتخاب کنید و همه‌جا همان باشد — و برای هر چیزی که کاربر باید کپی کند یا بخواند و بگوید (کد پیگیری، شبا، کد تخفیف) رقم لاتین امن‌تر است، چون در کپی و جست‌وجو و تماس تلفنی مشکل نمی‌سازد.

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

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

جمع‌بندی

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