من در سال ۱۹۹۲ از دانشگاه ویرجینیا در رشته علوم کامپیوتر (در حد فرعی) فارغ‌التحصیل شدم. دلیل اینکه این رشته فرعی بود و نه اصلی این بود که برای تحصیل در رشته اصلی علوم کامپیوتر (CS) در UVa، باید از مدرسه مهندسی عبور می‌کردید و، به بیان ساده، من اصلاً برای ریاضیات و فیزیک سنگین ساخته نشده بودم. زیبایی یک رشته فرعی این بود که می‌توانستم تمام کلاس‌های جذاب CS را انتخاب کنم و بقیه را نادیده بگیرم.
یکی از کلاس‌های موردعلاقه‌ام، که بیش از همه به یادم مانده، کلاس الگوریتم‌ها بود. همیشه به دیگران می‌گفتم که کلاس الگوریتم‌ها تنها بخشی از تحصیلات دانشگاهی‌ام بود که بیشترین تأثیر را روی من به‌عنوان یک برنامه‌نویس داشت. دقیقاً نمی‌دانستم چرا، اما چند سال پیش حدسی زدم، یک رزومه خاص را جستجو کردم و فهمیدم که رندی پاش (Randy Pausch) – بله، همان رندی پاش سخنرانی آخر (Last Lecture) – آن کلاس را تدریس می‌کرد. زمان‌بندی دقیقاً درست بود: دانشگاه ویرجینیا، پاییز ۱۹۹۱، CS461 تحلیل الگوریتم‌ها، ۵۰ دانشجو.
من یکی از آن‌ها بودم.
جای تعجب ندارد که اینقدر تحت تأثیر قرار گرفتم. پاش معلمی فوق‌العاده و کاریزماتیک بود، گواهی بر این ضرب‌المثل قدیمی که باید ابتدا معلم را انتخاب کنید و بعد محتوای کلاس را، اگر اصلاً قصد انتخاب دارید. و این کاملاً درست است.
در این مورد، ترکیب یک معلم عالی و یک موضوع عالی به شدت قدرتمند بود، زیرا الگوریتم‌ها در مرکز کاری هستند که برنامه‌نویسان انجام می‌دهند. نه اینکه ما الگوریتم‌های جدیدی اختراع کنیم، اما باید کدی را که وجود دارد درک کنیم، بفهمیم چرا بر اساس موازنه‌های انتخاب‌شده سریع یا کند است، و الگوریتم‌های درست را برای کارمان انتخاب کنیم. این مسئله حیاتی است.
یکی از جذاب‌ترین چیزهایی که آقای پاش به من یاد داد، این بود که این سؤال را بپرسم:
«الگوریتم خداگونه برای این چیست؟»
خب، وقتی قرار است لیستی را مرتب کنیم، مسلماً خدا نیازی به استفاده از مرتب‌سازی حبابی یا سریع یا شل، مثل ما انسان‌های فانی، ندارد. خدا به‌سادگی آیتم‌ها را مستقیماً به ترتیب درست قرار می‌دهد. بوم. یک مرحله. پایین‌ترین حد ممکن برای محاسبات، O(1). نه فقط در زمان ثابت، بلکه در یک مرحله آنی، چون خداست!
این موضوع در آن زمان ذهنم را به کلی منفجر کرد.
همیشه حدس می‌زدم که برنامه‌نویسان به این دلیل برنامه‌نویس می‌شوند که می‌توانند با جهان‌های کوچکشان روی میزهایشان نقش خدا را بازی کنند. رندی پاش این تفکر را گرفت و آن را به روشی واقعاً کاربردی برای تعیین مرزها و پرسیدن سؤالات سخت از خودتان در مورد کاری که انجام می‌دهید و چرایی آن تبدیل کرد.
بنابراین وقتی قصد داشتیم یک دیالوگ ورود برای Discourse بسازیم، به آنچه در کلاس الگوریتم‌ها یاد گرفته بودم برگشتم و از خودم پرسیدم:
«خدا چگونه این دیالوگ ورود را می‌ساخت؟»
و جواب، البته، این است که خدا اصلاً زحمت ساختن دیالوگ ورود را به خود نمی‌داد. هر کاربر از لحظه‌ای که صفحه را بارگذاری می‌کرد، قبلاً وارد GodApp شده بود، چون خدا می‌داند آن‌ها چه کسانی هستند. قطعاً و بدون شک.
این برای ما کاملاً غیرممکن است، چون خدا یکی از سرمایه‌گذاران ما نیست.
اما… چقدر می‌توانیم به تجربه ورود خداگونه نزدیک شویم؟ این یک هدف شرافتمندانه و ارزشمند است.
آیا این بیل گیتس (Bill Gates) نبود که یک‌بار پرسید چرا هر برنامه‌نویسی باید بارها و بارها همان دیالوگ باز کردن فایل را بنویسد؟ این دقیقاً همان احساسی است که در مورد دیالوگ‌های ورود دارم. مدت‌هاست که می‌گویم بهترین ورود، عدم نیاز به ورود است و من قویاً حامی ورود با «گواهینامه اینترنتی» هستم، هر جا که ممکن باشد. پس اگر آن را پیکربندی کرده باشید، ما حتماً از آن پشتیبانی می‌کنیم.
اما امروز می‌خواهم بر تجربه اصلی و اساسی ورود تمرکز کنم: کاربر و گذرواژه. این پیش‌فرض است، مگر اینکه روش‌های دیگر ورود را تنظیم کنید.
یک فرم ورود با دو فیلد، دو دکمه، و یک لینک ساده به نظر می‌رسد، درست است؟ استاندارد و معمولی. این‌طور است، تا وقتی که به همه راه‌هایی فکر کنید که این عمل ساده ورود با آن دو فیلد می‌تواند برای کاربر اشتباه پیش برود. بیایید فکر کنیم.
اجازه دهید کاربر ایمیل را برای ورود وارد کند
مشکل اساسی OpenID، با وجود اینکه به‌عنوان یک راه‌حل اولیه ورود از آن خوشم می‌آمد، این بود که فرض می‌کرد کاربران می‌توانند یک URL را به‌عنوان «هویت» خود بپذیرند. این کاملاً غیرمنطقی است، و در درازمدت این فرض مرکزی معیوب OpenID را به‌عنوان یک استاندارد آینده شکست داد.
هویت کاربر همیشه ایمیل است، ساده و سرراست. وقتی گذرواژه‌تان را فراموش می‌کنید چه اتفاقی می‌افتد؟ یک ایمیل دریافت می‌کنید، درست است؟ پس، ایمیل همان هویت شماست. برخی حتی پیشنهاد می‌کنند که از ایمیل به‌عنوان تنها روش ورود استفاده شود.
داشتن یک نام کاربری، البته، خوب است، اما همیشه اجازه دهید کاربران با نام کاربری یا ایمیلشان وارد شوند. چون با اطمینان ۱۰۰٪ می‌توانم بگویم وقتی آن کاربران گذرواژه‌شان را فراموش کنند – و این همیشه اتفاق می‌افتد – برای دریافت بازنشانی گذرواژه به همان ایمیل نیاز خواهند داشت. ایمیل و گذرواژه مفاهیمی به‌شدت مرتبط هستند و باید با هم باشند. همیشه!
(و نفرین بر خدماتی که به من اجازه نمی‌دهند از ایمیل به‌عنوان نام کاربری یا روش ورود استفاده کنم. منظورم شما هستید، Comixology!)
اطلاع رسانی عدم وجود ایمیل
خب، حالا می‌دانیم که ایمیل برای اکثر مردم به‌عنوان هویت تعریف‌شده است، و این یک وضعیت منطقی و ضروری است. اما کدام‌یک از ۱۰ آدرس ایمیل من را برای ورود به سایت شما استفاده کرده‌ام؟
این موضوع باعث یک بحث طولانی در Discourse شد که آیا منطقی است وقتی کاربر در فرم «گذرواژه را فراموش کرده‌ام» یک آدرس ایمیل وارد می‌کند، به او نشان دهیم که آیا آن ایمیل در سایت ما ثبت شده است یا خیر. در بسیاری از وب‌سایت‌ها، این نوع پیام را بعد از وارد کردن ایمیل در فرم «گذرواژه را فراموش کرده‌ام» مشاهده خواهید کرد:
«اگر حسابی با name@example.com مطابقت داشته باشد، باید به‌زودی یک ایمیل با دستورالعمل‌هایی برای بازنشانی گذرواژه خود دریافت کنید.»
به «اگر» در اینجا توجه کنید که یک اقدام احتیاطی در برابر تمام پیامدهای امنیتی فاش کردن اینکه آیا یک آدرس ایمیل خاص با تایپ آن در فرم «گذرواژه را فراموش کرده‌ام» در سایت وجود دارد یا خیر.
ما درباره انتخاب پیش‌فرض‌های امن برای Discourse کاملاً جدی هستیم، بنابراین به‌صورت پیش‌فرض شما مورد سوءاستفاده، هک یا حمله اسپمرها قرار نمی‌گیرید. اما پس از تجربه وضعیت واقعی «کدام ایمیل را اینجا استفاده کرده بودیم؟» در ده‌ها نمونه Discourse، متوجه شدیم که در این مورد خاص، کاربرپسند بودن بسیار مهم‌تر از امنیت است.
پیش‌فرض جدید این است که به کاربران اطلاع دهیم وقتی ایمیلی را وارد کرده‌اند که آن را نمی‌شناسیم. این کار عقل آن‌ها و شما را نجات می‌دهد. البته می‌توانید امنیت اضافی مربوط به پنهان کردن این مورد را از طریق یک تنظیم سایت فعال کنید.
اجازه دهید کاربر در هر لحظه بین ورود و ثبت‌نام جابه‌جا شود
بسیاری از وب‌سایت‌ها شروع به نمایش دکمه‌های ورود و ثبت‌نام در کنار هم کرده‌اند. این برای من عجیب بود؛ آیا عمل ورود و ثبت‌نام ذاتاً بسیار متفاوت نیستند؟
خب، از دیدگاه کاربر، ظاهراً این‌طور نیست. این دیالوگ ورود سایت Verge نشان می‌دهد که فرم‌های ثبت‌نام و ورود چقدر به یکدیگر نزدیک هستند. نگاهی به این گیف متحرک از عملکرد آن بیندازید.
ما این شباهت را با قابل‌دسترس کردن هر دو فرم در هر لحظه از طریق دو دکمه در پایین فرم، به عنوان یک کلید جابه‌جایی، به رسمیت شناخته‌ایم:
و هر دو می‌توانند مستقیماً از هر صفحه‌ای از طریق دکمه‌های ورود و ثبت‌نام در گوشه بالا سمت راست آغاز شوند:
انتخاب واژه‌های متداول
مشکل زبان این است که ما کلمات زیادی برای این مفاهیم داریم:
- ورود (Sign In)
- ورود (Log In)
- ثبت‌نام (Sign Up)
- ثبت‌نام (Register)
- عضویت در <سایت> (Join )
- ایجاد حساب (Create Account)
- شروع (Get Started)
- اشتراک (Subscribe)
کدام یک “درست” است؟ داده‌های تحقیقات کاربری نتیجه قطعی ندارند.
من تمایل دارم نسخه‌های کوتاه‌تر را در صورت امکان انتخاب کنم، بیشتر به این دلیل که طرفدار خلاصه‌گویی هستم، اما برای هرکدام، بسته به شرایط و ترجیحات کاربر، می‌توان دلایل معتبری مطرح کرد.
ورود (Sign In) ممکن است کمی رایج‌تر باشد، اما ورود (Log In) به دلیل پیشینه دریانوردی و تاریخچه آن در رایانه‌محوری، ارزشمند است:
چند سال پیش یک نظرسنجی از وب‌سایت‌های برتر در ایالات متحده و بریتانیا انجام دادم که آیا از “Sign In”، “Log In”، “Login”، “Log On” یا نسخه دیگری استفاده می‌کنند. جواب در آن زمان این بود که اگر “Log In” و “Login” را با هم جمع کنید، از “Sign In” پیشی می‌گیرند، اما نه خیلی. همچنین متوجه شدم که روند استفاده از “Sign In” به‌ویژه در محبوب‌ترین سرویس‌ها در حال افزایش است. به نظر می‌رسد که فیسبوک همچنان به “Log In” پایبند است.
کار با مدیریت‌کننده‌های رمز عبور مرورگر
هر دیالوگ ورود که ایجاد می‌کنید باید طوری آزمایش شود که با مدیریت‌کننده‌های رمز عبور پیش‌فرض در مرورگرهای زیر کار کند:
- Internet Explorer
- Chrome
- Firefox
- Safari
این حداقل استاندارد است. در ورودهای بعدی در همان مرورگر، باید نام کاربری و رمز عبور به‌طور خودکار پر شوند.
کاربران به این مدیریت‌کننده‌های رمز عبور پیش‌فرض در مرورگرهایی که استفاده می‌کنند متکی هستند، و هر فرم ورود مدرن و مناسب باید این را رعایت کند و به‌درستی طراحی شده باشد، مثلاً فیلد رمز عبور باید در HTML دارای نوع “password” و نامی باشد که به‌راحتی به‌عنوان فیلد ورودی رمز عبور قابل شناسایی باشد.
همچنین ابزارهایی مثل LastPass و موارد مشابه وجود دارند، اما معمولاً فرض می‌کنم اگر دیالوگ ورود با مدیریت‌کننده‌های رمز عبور داخلی مرورگرها کار کند، با ابزارهای شخص ثالث نیز کار خواهد کرد.
رسیدگی به اشتباهات رایج کاربران
اوه، کاربر رمز عبور خود را با روشن بودن Caps Lock تایپ کرده است؟ باید او را از این موضوع مطلع کنید.
اوه، کاربر ایمیل خود را به صورت name@gmal.com به‌جای name@gmail.com وارد کرده است؟ یا name@hotmail.cm به‌جای name@hotmail.com؟ باید یا این اشتباهات را برای آن‌ها اصلاح کنید یا به آن‌ها اطلاع دهید.
(من همچنین طرفدار بزرگی از قابلیت “نمایش رمز عبور” بومی مرورگرها برای فیلد رمز عبور هستم، تا کاربر بتواند رمز عبوری را که تایپ کرده یا به‌طور خودکار پر شده است، بررسی کند. فقط Internet Explorer و فکر می‌کنم Safari این قابلیت را ارائه می‌دهند، اما همه مرورگرها باید این را داشته باشند.)
کمک به کاربران برای انتخاب رمزهای عبور بهتر
مکاتب فکری زیادی درباره اجبار برای کمک به کاربران در انتخاب رمزهای عبوری که بسیار ضعیف نباشند وجود دارد، مثل password123 و iloveyou و غیره.
یکی از روش‌ها، نشانگر قدرت رمز عبور است که به‌صورت بلادرنگ هنگام تایپ رمز عبور به‌روزرسانی می‌شود.
این ایده جالبی است، اما در برخی سایت‌ها به‌شدت حالت موعظه‌گرانه پیدا می‌کند. اجرای آن نیز جای کار دارد، زیرا این موضوع به سلیقه مالک سایت سپرده شده است که تصمیم بگیرد قدرت رمز عبور چه معنایی دارد. رمز عبور “خوب” یک سایت ممکن است برای سایت دیگر غیرقابل قبول باشد. این ناامیدکننده است.
بنابراین، در دیسکورس، به‌جای همه این‌ها، تصمیم گرفتم که حداقل طول رمز عبور را به‌طور پیش‌فرض 8 کاراکتر تعیین کنیم و سپس رمز عبور را بررسی کنیم تا مطمئن شویم که جزو 10,000 رمز عبور شناخته‌شده و رایج نیست، با بررسی هش آن.
کیبورد را فراموش نکنید
احساس می‌کنم که کاربران کیبورد در حال انقراض هستند، اما برای آن‌هایی که، هنگام مواجهه با دیالوگ ورود، دوست دارند سریعاً تایپ کنند:
name@example.com، Tab، p4$$w0rd، Enter
… لطفاً مطمئن شوید که این موارد همان‌طور که باید، کار می‌کنند. ترتیب تب، ارسال با اینتر، و غیره.
محدودیت نرخ دسترسی برای همه چیز
شما باید نرخ دسترسی هر کاری که کاربران می‌توانند انجام دهند را در همه جا محدود کنید، و این موضوع به‌ویژه درباره دیالوگ ورود صدق می‌کند.
اگر کسی رمز عبور خود را فراموش کند و ۳ بار تلاش کند تا وارد شود، یا ۳ درخواست برای بازیابی رمز عبور ارسال کند، احتمالاً مشکلی نیست. اما اگر کسی هزار بار تلاش کند تا وارد شود یا هزار درخواست برای بازیابی رمز عبور ارسال کند، این کمی عجیب به نظر می‌رسد. چرا که ممکن است حتی بتوان حدس زد که شاید … انسان نباشد.
می‌توانید کارهای پیشرفته‌ای انجام دهید، مثل غیرفعال کردن موقت حساب‌ها یا نمایش CAPTCHA در صورت وجود تعداد زیادی تلاش ناموفق برای ورود، اما این اقدامات می‌تواند به‌راحتی به یک ابزار آزار و اذیت تبدیل شود، پس باید محتاط باشید.
من فکر می‌کنم یک راه‌حل میانه خوب این است که پس از شکست‌های متوالی یا درخواست‌های متوالی بازیابی رمز عبور از یک آدرس IP مشخص، وقفه‌های استانداردی با اندازه متوسط و رو به افزایش قرار دهیم. این دقیقاً همان کاری است که ما انجام می‌دهیم.
چیزهایی که فراموش کردم
سعی کردم همه مواردی را که هنگام طراحی دیالوگ ورود ایده‌آل برای دیسکورس از سر گذراندیم، به یاد بیاورم، اما مطمئنم چیزی را فراموش کرده‌ام یا می‌توانستم جزئیات بیشتری ارائه کنم. به یاد داشته باشید که دیسکورس ۱۰۰٪ متن‌باز است و به‌طور ذاتی یک پروژه در حال پیشرفت محسوب می‌شود – بنابراین همان‌طور که دوستم میگل ده ایکازا (Miguel de Icaza) دوست دارد بگوید، وقتی خراب شد، هر دو نیمه‌اش مال خودتان است. حتماً پیاده‌سازی ما را آزمایش کنید و بازخورد خود را در نظرات ارائه دهید، یا به نمونه‌های دیگری از تجربیات عالی ورود اشاره کنید، یا مشاوره‌های مفید دیگری را مطرح کنید.
ورود شامل یک فرم ساده با دو فیلد، یک لینک و دو دکمه است. با این حال، پس از خواندن همه این مطالب، مطمئنم موافقید که این فرم به‌طرز فریبنده‌ای پیچیده است. بهترین اقدام شما این است که اصلاً دیالوگ ورود طراحی نکنید و در عوض، هر زمان که ممکن بود، به احراز هویت از یک منبع خارجی متکی شوید.
مثلاً، خدا.