طراحی فرم ثبت‌نام برای اتباع خارجی مقیم ایران

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

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

خطای اول: فرم یک‌شکلی

ساده‌ترین طرح این است: یک کادر «کد ملی» و اعتبارسنجی ده‌رقمی. مشکلش دو لایه است.

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

طرح پیشنهادی: انتخاب نوع هویت در گام اول

به نظر من بهترین رفتار این است که کاربر در اولین گام بگوید کدام نوع هویت را دارد:

• «کد ملی ایرانی»
• «شناسهٔ فراگیر اتباع»

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

اعتبارسنجی هر شاخه

• شاخهٔ کد ملی: طول ده و رقم کنترلی.
• شاخهٔ شناسهٔ فراگیر: فقط رقم بودن و بازهٔ طول (ما ده تا شانزده را می‌پذیریم). رقم کنترلی نسازید؛ الگوریتمی در مستند نیست و ساختن‌اش یعنی خطر رد شناسهٔ معتبر.

اعتبارسنجی نرم اینجا درست است، چون تصمیم نهایی با مرجع است و مرجع خطای مشخص می‌دهد.

ستون‌های دیتابیس

سه تصمیم که بعداً هزینهٔ زیادی دارند:

1. نوع هویت را ذخیره کنید. دو ستون جدا یا یک ستون نوع کنار یک ستون مقدار. فقط یک رشتهٔ بی‌نوع بگذارید و شش ماه بعد نمی‌دانید کدام ردیف چیست.
2. یکتایی را روی ترکیب نوع و مقدار بگذارید، نه فقط مقدار.
3. نام جد را به نام پدر نگاشت نکنید. خروجی سرویس هر دو را جدا می‌دهد. اگر ستون ندارید، ستون بسازید یا آن را نگه ندارید؛ ولی در ستون نام پدر نریزید، چون داده را آلوده می‌کند.

بعد از استعلام: مقایسه با ادعای کاربر

استعلام به شما اطلاعات هویتی می‌دهد. مقایسه با آنچه کاربر نوشته کار شماست. دو نکتهٔ عملی:

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

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

خطاها را برای کاربر قابل‌فهم کنید

از مستندات API می‌دانید دو خانوادهٔ خطا هست: ورودی نامعتبر (رایگان و سمت شما قابل اصلاح) و «رکوردی نیست». این دو را در رابط یکی نکنید.

• ورودی نامعتبر: «شناسه را دوباره بررسی کنید.»
• رکوردی نیست: «این شناسه پیدا نشد؛ ممکن است اشتباه نوشته شده یا هنوز ثبت نشده باشد.» و راهی بدهید که کاربر با پشتیبانی تماس بگیرد.

مورد دوم هزینه دارد، پس پیش از ارسال طول و رقم‌بودن را سمت خودتان بسنجید تا فراخوان بی‌دلیل نرود.

آنچه این استعلام نمی‌کند

پیش از طراحی، ورودی و خروجی این سرویس را کنار طرح خودتان بگذارید.

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

یک طرح فرم ساده

برای اینکه تصویر روشن شود، ساختار فرضی یک ثبت‌نام را ببینید:

1. گام اول: «کد ملی ایرانی» یا «شناسهٔ فراگیر اتباع».
2. گام دوم: یک کادر شماره. برچسب و راهنمای کادر بر اساس گام اول عوض می‌شود. برای شناسهٔ اتباع می‌نویسید «شمارهٔ اختصاصی که روی کارت یا برگهٔ هویتی آمده».
3. گام سوم: اگر کد ملی است، تاریخ تولد هم بگیرید؛ اگر شناسهٔ اتباع است، لازم نیست.
4. گام چهارم: نتیجهٔ استعلام را به کاربر نشان بدهید تا تأیید کند همین است.

گام آخر از اهمیت بیشتری برخوردار است: نشان دادن «نام و نام خانوادگی شما این است» و پرسیدن «درست است؟» هم خطای تایپ شناسه را می‌گیرد و هم کاربر را در تصمیم نگه می‌دارد.

آزمون‌هایی که باید داشته باشید

• شناسه با طول‌های مختلف در بازه، شاخهٔ درست را فعال کند.
• ستون نوع هویت پر شود و ترکیب نوع و مقدار یکتا باشد.
• نبود هر فیلد اختیاری در پاسخ، فرایند را نشکند.
• کد ملی ده‌رقمی در شاخهٔ اتباع و بالعکس رفتار قابل‌پیش‌بینی داشته باشد (خطای روشن، نه خطای ۵۰۰).
• نام جد در جای نام پدر ننشیند.

این پنج مورد را اگر داشته باشید، بیشتر شکست‌هایی که در ماه‌های اول پیش می‌آید جلوتر گرفته می‌شود.

گذار از فرم قدیمی

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

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

گزارش‌ها و پشتیبانی

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

اگر عجله دارید

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