صفحه‌ای که در تصویر عالی به نظر می‌رسد، ممکن است در دست کاربر واقعی شکست بخورد. دکمه را می‌زند و نمی‌فهمد درخواست ثبت شده یا نه. اینترنت قطع می‌شود و اطلاعات فرم از بین می‌رود. با کیبورد نمی‌تواند به مرحله بعد برود.
این‌ها جزئیات تزئینی نیستند. بخشی از محصول‌اند و دقیقاً جایی هستند که مهندسی فرانت‌اند معنا پیدا می‌کند.
فرانت‌اند کجای سیستم قرار می‌گیرد؟
فرانت‌اند بخشی از نرم‌افزار است که کاربر از طریق آن اطلاعات را می‌بیند و با سیستم تعامل می‌کند. در وب، HTML ساختار و معنای محتوا، CSS نمایش و چیدمان و JavaScript بخش زیادی از رفتار تعاملی را شکل می‌دهند. فریم‌ورک‌ها می‌توانند توسعه را سامان بدهند، اما جای فهم این پایه‌ها را نمی‌گیرند.
مهندسی فرانت‌اند یعنی برای این تعامل، تصمیم فنی قابل دفاع بگیریم: داده از کجا می‌آید؟ چه وضعیت‌هایی ممکن است؟ چگونه خطا را نشان بدهیم؟ چه چیزی روی دستگاه ضعیف هم قابل استفاده می‌ماند؟ تغییر بعدی با چه هزینه‌ای انجام می‌شود؟
یک فرم ثبت‌نام، چند مسئله مهندسی
فرض کنیم فرم ثبت‌نامی با سه ورودی و یک دکمه داریم. پیاده‌سازی اولیه ساده به نظر می‌رسد. اما محصول واقعی به پاسخ این سؤال‌ها نیاز دارد:
- آیا هر ورودی برچسب روشن دارد و خطا کنار همان فیلد نمایش داده می‌شود؟
- آیا هنگام ارسال، وضعیت انتظار مشخص است و کلیک تکراری مدیریت می‌شود؟
- اگر درخواست شکست خورد، داده‌های واردشده حفظ می‌شوند؟
- اگر سرور خطای متفاوتی برگرداند، کاربر راه اصلاح را می‌فهمد؟
- آیا فرم با کیبورد، صفحه‌خوان و روی موبایل قابل استفاده است؟
راهنمای فرم‌های دسترس‌پذیر W3C بر برچسب‌ها، راهنمای ورود اطلاعات، اعتبارسنجی و اعلام نتیجه تأکید دارد. این اصول مستقیماً به همین مثال مربوط‌اند.
اعتبارسنجی مرورگر به تجربه کاربر کمک می‌کند، اما کنترل امنیت و مجوز باید در سرور هم انجام شود. هیچ دکمه مخفی‌شده‌ای جای کنترل دسترسی واقعی را نمی‌گیرد.
وضعیت‌ها را طراحی کنیم، نه فقط صفحه‌ها را
برای یک فهرست ساده، دست‌کم وضعیت بارگذاری، داده موجود، فهرست خالی و شکست درخواست را در نظر بگیریم. «هنوز چیزی ثبت نکرده‌ای» با «دریافت اطلاعات ناموفق بود» فرق دارد. اولی به راه شروع نیاز دارد؛ دومی به توضیح خطا و امکان تلاش دوباره.
اگر این وضعیت‌ها از ابتدا روشن نباشند، معمولاً در پایان پروژه با شرط‌های پراکنده به کد اضافه می‌شوند. نتیجه هم برای کاربر مبهم است و هم برای تیم سخت‌تر نگهداری می‌شود.
سرعت را از دید کاربر بسنجیم
اندازه بسته JavaScript و زمان بارگذاری مهم‌اند؛ اما سؤال عملی این است: کاربر چه زمانی محتوا را می‌بیند و چه زمانی می‌تواند کارش را انجام بدهد؟ تصویر بزرگ، اسکریپت اضافی یا جابه‌جایی ناگهانی چیدمان می‌تواند تجربه را خراب کند.
آموزش عملکرد وب MDN هم سرعت بارگذاری و پاسخ‌گویی به تعامل را بخشی از تجربه کاربر می‌داند. در عمل باید روی مسیر اصلی، با شرایطی نزدیک به مخاطب، اندازه‌گیری کنیم. نتیجه روی لپ‌تاپ توسعه‌دهنده و اینترنت خوب برای قضاوت درباره همه کاربران کافی نیست.
کیفیت امروز، هزینه تغییر فردا
یک کامپوننت مشترک زمانی ارزش دارد که رفتار و مسئولیت روشنی داشته باشد. تقسیم کردن صفحه به ده‌ها فایل، به‌تنهایی معماری نیست. اگر منطق کسب‌وکار، درخواست شبکه و نمایش درهم باشند، کوچک بودن فایل‌ها مشکل را حل نمی‌کند.
برای یک پروژه فارسی، راست‌به‌چپ بودن، نمایش متن انگلیسی میان فارسی، اعداد، تاریخ و پیام‌های خطا هم باید جزو طراحی باشد. فارسی کردن عنوان‌ها در آخر پروژه برای ساختن تجربه درست کافی نیست.
یک تمرین واقعی برای یادگیری
به‌جای ساختن یک صفحه خوش‌ظاهر دیگر، یک فرم درخواست مشاوره بسازیم که اطلاعات را حفظ کند، نتیجه ارسال را روشن نشان بدهد، با کیبورد کار کند و در قطع شبکه مسیر بازیابی داشته باشد. بعد از یک نفر بخواهیم بدون توضیح ما آن را استفاده کند.
اگر نتوانیم توضیح بدهیم کاربر در هر وضعیت چه می‌بیند و چه کاری می‌تواند انجام بدهد، هنوز بخشی از مهندسی را انجام نداده‌ایم. فرانت‌اند خوب، پیچیدگی سیستم را برای کاربر قابل فهم می‌کند.
