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

قالب بخشنده (Forgiving Format) چیست؟

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

کاربر شمارهٔ کارت را با فاصله می‌نویسد و فرم می‌گوید «فرمت نامعتبر». فاصله را خودِ سیستم می‌تواند حذف کند و به‌جایش کاربر را برگردانده تا دوباره تایپ کند.

قالب بخشنده دقیقاً برای همین ساخته شده — و منطقش این است که کار پاک‌کردن ورودی، کار سیستم است نه کار کاربر.

تعریف

الگوی قالب بخشنده به کاربر اجازه می‌دهد اشتباه کند.

و تعریف کاملش دو بخش دارد. قالب بخشنده فقط اشتباه‌ها را تصحیح نمی‌کند؛ اجازه می‌دهد کاربر رویکردهای مختلفی به یک مسئله بگیرد، یعنی اگر یک راه را بلد نبود یا نتوانست، سراغ راه دیگری برود.

بخش دوم کمتر گفته می‌شود و مهم‌تر است. بخشندگی فقط تحمل خطا نیست؛ تکثر راه است.

و تفاوت این دو در طراحی خیلی بزرگ است.

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

تکثر راه یک کار طراحی است: باید بدانید آدم‌ها چند شکل مختلف به این مسئله فکر می‌کنند و برای هر کدام مسیری بگذارید. اینجا کاربر متوجه می‌شود — و همین است که کار می‌کند.

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

و دومی چیزی است که با پاک‌کردن ورودی به‌دست نمی‌آید. باید از قبل بدانید که وجود دارد.

دو کاربرد

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

نمونهٔ کاربرد دوم، فیلد مکان در ایربی‌ان‌بی است: نام کشور، نام شهر، یا نشانی دقیق — هر سه پذیرفته می‌شوند.

و نمونه‌های کاربرد اول، همین‌هایی است که هر روز می‌بینید: «Chicago Ill.» و «Chicago, IL» و «Chgo, Ilns.» که همه یک جا هستند. یا «Srteet» که باید «Street» خوانده شود.

و در جست‌وجو: «can’t find download» و «fail locate program» و «where is file?» همه یک نیت دارند.

ساختنش

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

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

و ارزش دارد که روی یک قاعده بیشتر بایستیم، چون بیشتر از بقیه اثر دارد و کمتر از بقیه اجرا می‌شود: هشدار در حین حرکت میان فیلدها.

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

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

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

جنیفر تیدول در «طراحی رابط‌ها» همین را در یک جمله می‌گوید: «آزمون کنید، آزمون کنید، و باز هم با کاربر واقعی آزمون کنید.»

جاهایی که سخت می‌شود

سه موقعیت هست که بخشندگی در آن‌ها ساده نیست.

• - ابهام واقعی. «آتن» یونان است یا آتنِ ایالت جورجیا؟ اینجا حدس‌زدن غلط است و باید پرسید.
• - هم‌آواها و خطای انتخاب واژه. «there» و «their»، یا «desert» و «dessert». سیستم نمی‌داند کدام را می‌خواستید.
• - اشتباه یکسان که دو بار تکرار می‌شود. رمزی که در هر دو فیلد یک‌جور غلط تایپ شده، از دید سیستم درست است.

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

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

وقتی سیستم می‌گوید «نتایج برای مشهد — به‌جای مشحد» و کاربر می‌خواهد واقعاً همان املای خودش را بجوید، باید یک راه برگشت داشته باشد.

و اگر این راه نباشد، بخشندگی به سرسختی تبدیل می‌شود. سیستمی که همیشه فکر می‌کند بهتر از شما می‌داند چه می‌خواهید، دقیقاً همان‌قدر آزاردهنده است که سیستمی که هیچ‌چیز را نمی‌بخشد.

فایده‌اش

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

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

مرزش با اعتبارسنجی

و یک سوءتفاهم رایج هست که ارزش رفعش را دارد: قالب بخشنده به معنای برداشتن اعتبارسنجی نیست.

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

تفاوت در این است که اعتبارسنجی باید دربارهٔ معنا قضاوت کند، نه دربارهٔ شکل.

«۱۲۳۴ ۵۶۷۸ ۹۰۱۲ ۳۴۵۶» با فاصله نوشته شده و کاملاً معتبر است. «۱۲۳۴۵۶۷۸» بدون فاصله نوشته شده و معتبر نیست. شکل اولی غیرمنتظره است و معنایش درست؛ دومی برعکس.

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

در بافت فارسی

بخشندگی در فارسی کار بیشتری می‌خواهد، چون یک مفهوم واحد شکل‌های نوشتاری بیشتری دارد.

یک: عدد فارسی و عربی و لاتین. «۱۲۳» و «١٢٣» و «123» یک عددند و سه رشتهٔ متفاوت. هر فیلد عددی باید هر سه را بپذیرد و به یک شکل تبدیل کند.

دو: «ی» و «ک» عربی و فارسی. کاربر با صفحه‌کلیدهای مختلف می‌نویسد و «علی» با «علي» از دید سیستم دو نام است. یکسان‌سازی این دو حرف، ساده‌ترین بخشندگی ممکن است و اغلب انجام نمی‌شود.

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

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

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

پنج: تاریخ. «۱۴۰۵/۰۶/۰۶» و «۶ شهریور ۱۴۰۵» و «1405-06-06». اگر فقط یک شکل را می‌پذیرید، دارید کاربر را وادار می‌کنید قالب شما را یاد بگیرد.

چطور بفهمیم کجا لازم است

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

یک: نرخ خطای هر فیلد. اگر ثبتش نمی‌کنید، ارزش یک روز کار را دارد. فیلدی که ۳۰ درصد کاربران در آن خطا می‌گیرند، یک فیلد سخت نیست — یک فیلد بدطراحی‌شده است.

دو: تعداد تلاش تا موفقیت. کاربری که سه بار یک فیلد را اصلاح می‌کند، دارد قالب مورد قبول شما را حدس می‌زند. و این حدس‌زدن، کار شما بود.

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

و این سومی معمولاً غافلگیرکننده‌ترین است، چون آنچه در پایگاه داده هست، نمایندهٔ کسانی است که موفق شدند. کسانی که نتوانستند، اصلاً در آن جدول نیستند.

یک قاعدهٔ ساده برای شروع

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

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

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

جمع‌بندی

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