البحث في الموقع

عندما يتعلق الأمر ببناء نوع معيّنٍ من تطبيقات الويب، فأوّل ما يخطر ببالي هو استخدام ووردبريس! ومن بين المشاريع البرمجية التي عملتُ عليها في السنتين الماضيتين، تطلّب نصفها - على الأقل - إمكانية إدارة حسابات المستخدمين، وهو ما يعني عادةً السماح للمستخدمين بإنشاء حساباتهم، بإدخال بعض البيانات في حقلَي الاسم وعنوان البريد الإلكتروني، ومن ثم ستُرسَل إليهم رسالةٌ بريديةٌ لتفعيل حسابهم بعد إرسال النموذج. توفِّر ووردبريس طريقةً سهلةً لإدارة المستخدمين عبر لوحة التحكم، وإذا كان موقعك تعليميًا أو كنتَ تستعمله مدونةً لك، فلا حاجة إلى إنشاء آليةٍ أخرى لإدارة المستخدمين، لكن إذا كنتَ تبني تطبيقًا متكاملًا، فهنالك طرائق أخرى للتعامل مع حسابات المستخدمين. لنقل مثلًا أنَّ المُصمِّم قد وضع طريقةً معينةً لإدارة الحسابات في الموقع، وإذا أجبرتَ المستخدمين على استخدام لوحة التحكم فستتسبَّب بتخريب تجربة المستخدم، أليس كذلك؟ هنالك طرائقٌ أفضل لتسجيل حسابات المستخدمين وإدارتها بدلًا من استخدام لوحة التحكم التابعة لووردبريس، وسنناقش في هذا الدرس كيفية إنشاء حسابات المستخدمين برمجيًا، وسنلقي نظرةً على النقاط الآتية: الحصول على معلومات المستخدم بصيغةٍ معيّنة، التعرّف على المعلومات اللازمة لإنشاء حساب مستخدم، إنشاء الحساب، التأكد أنَّ شيفرتنا تخضع لمعايير كتابة الشفرات القياسية، وأنها سهلة القراءة والصيانة. لا تقلق، لن يكون هذا الدرس طويلا ومملًّا، أعدك بذلك! إنشاء حسابات مستخدمي ووردبريس يحتاج أحدنا إلى المعلومات الآتية –على الأقل– لإنشاء حساب مستخدم جديد: اسم المستخدم كلمة المرور عنوان البريد الإلكتروني عندما يتعلق الأمر بإنشاء اسم المستخدم، فأنا أفضِّل استخدام البريد الإلكتروني اسمًا للمستخدم لأنني أضمن أنَّه فريد ولن يتكرر مرةً أخرى؛ ولهذا سنستخدمه في هذا الدرس؛ وسنتحدث عن توليد كلمة المرور لاحقًا. أضف إلى ذلك ضرورة افتراض أنَّ البيانات ستأتيك بأيّ صيغة: فربما تكون بصيغة JSON، أو تكون حقولًا مفصولةً بفواصل كما في CSV، وقد تأتي بصيغة XML. بغض النظر عن الصيغة المستعملة، فيجدر بك كتابة الشفرات اللازمة لتفسير تلك المعلومات باستخدام PHP لكي تستطيع التعامل معها لاحقًا. ولتبسيط الشيفرات المعروضة في هذا الدرس، سنفترض وجود تسجيلة Record لمستخدمٍ وحيدٍ مخزنةٌ معلوماته في مصفوفة. هذا لا يعني أنَّ المعلومات ستأتيك مباشرةً على شكل مصفوفة جاهزة، وإنما عليك تحويلها برمجيًا إلى واحدة. أولًا: معلومات المستخدم لنفترض أنَّنا سنضيف شخصًا باسم Meghan إلى نظامنا، ولدينا عنوان بريده الإلكتروني. لكن لا بأس بذلك، فلدينا المعلومات الأساسية التي نريدها: <?php $user_info = array( 'email' => 'meghan@emaildomain.com', 'first_name' => 'Meghan', 'last_name' => 'McFarlin', ); ولنحوِّلها إلى شيءٍ نستطيع من خلاله إنشاء حسابٍ له. ثانيًا: إنشاء الحساب أوّل ما علينا فعله هو التحقق من عدم وجود مستخدم مرتبط بعنوان البريد الإلكتروني نفسه، وإذا حدث ذلك فسنستعمل التعليمة return فقط، لكنك قد ترغب بإظهار رسالة خطأ أو أي نوع من التنبيهات لتخبر المستخدم أنَّك لا تستطيع إنشاء هذا الحساب لوجوده من قبل؛ لكن ذلك خارجٌ عن نطاق هذا الدرس: <?php // التحقق من صحة البريد الإلكتروني الذي أدخله المستخدم وعدم وجوده مسبقًا في قاعدة البيانات $email = $user_info['email']; if ( ! filter_var( $email, FILTER_VALIDATE_EMAIL ) || username_exists( $email ) ) { return; } لنفترض في هذا الدرس أنَّ المستخدم غير موجود، وعلينا إنشاء حساب له؛ ولفعل ذلك سنحتاج إلى عنوان البريد الإلكتروني إضافةً إلى كلمة مرور؛ ولحسن الحظ، توليد كلمات المرور سهلٌ جدًا: <?php $password = wp_generate_password( 16, false ); لنأخذ البريد الإلكتروني الذي أدخله المستخدم وكلمة المرور التي ولّدناها ولنُنشِئ الحساب: <?php // الحصول على البريد الإلكتروني وتوليد كلمة المرور $email = $user_info['email']; $password = wp_generate_password( 12, false ); // إنشاء حساب المستخدم $user_id = wp_create_user( $email, $password, $email ); // ضبط امتيازات أو دور المستخدم $user = new \WP_User( $user_id ); $user->set_role( 'author' ); لاحظ في الشيفرة السابقة أننا ضبطنا دور المستخدم (role)، وذلك عبر الحصول على نسخةٍ من الصنف Wp_User ثم استخدام مُعرِّف المستخدم المُخزَّن في المتغير ‎$user_id لضبط الدور الخاص به. استخدمتُ دور الكاتب Author في المثال السابق، لكن هنالك أدوار ووردبريس أخرى يمكنك اختيار أحدها. ثالثًا: ألا توجد خطواتٌ أخرى؟! أصبح حساب المستخدم جاهزًا عند هذه المرحلة؛ دعني أذكِّرُكَ أنَّ جزءًا كبيرًا من عملية إنشاء المستخدم متعلقٌ بكيفية استقبال البيانات، ومن ثم معالجتها، والطريقة التي تسمح بها لمدير الموقع بإنشاء الحسابات. هذه الأمور مهمة، لكنني وعدتُكَ أن أبقي هذا الدرس قصيرًا ومركَّزًا، وتلك الأمور ترتبط ارتباطًا وثيقًا بشكل موقعك وتجربة المستخدم فيه، أي أنها تختلف من موقعٍ لآخر. الخلاصة لقد تعلمنا في هذا الدرس طريقة إنشاء مستخدمي ووردبريس برمجيًا، عبر تجربتنا لذلك على حساب مستخدمٍ واحد. إذا أردتَ إنشاء مستخدمين عدّة، فعليك إنشاء مصفوفات فيها معلومات المستخدمين، والتي تستطيع الدوران عليها عبر حلقة تكرار وتُنشِئ الحسابات كما فعلنا في هذا الدرس. ترجمة –وبتصرّف– للمقال Programmatically Creating WordPress Users لصاحبه Tom McFrlin. حقوق الصورة البارزة محفوظة لـ Freepik

يأتي Laravel، وهذه إحدى ميزاته الكثيرة، مضمنّا بآليات استيثاق Authentication جاهزة للاستخدام. سنطبق في هذا الدرس آلية الاستيثاق على صفحة الدفع checkout بحيث يُسمح بالدخول للمستخدمين المسجلين فقط. هذا الدرس جزء من سلسلة تعلم Laravel والتي تنتهج مبدأ "أفضل وسيلة للتعلم هي الممارسة"، حيث ستكون ممارستنا عبارة عن إنشاء تطبيق ويب للتسوق مع ميزة سلة المشتريات. يتكون فهرس السلسلة من التالي: مدخل إلى Laravel 5. تثبيت Laravel وإعداده على كلّ من Windows وUbuntu. أساسيات بناء تطبيق باستخدام Laravel. إنشاء روابط محسنة لمحركات البحث (SEO) في إطار عمل Laravel. نظام Blade للقوالب. تهجير قواعد البيانات في Laravel. استخدام Eloquent ORM لإدخال البيانات في قاعدة البيانات، تحديثها أو حذفها. إنشاء سلة مشتريات في Laravel. الاستيثاق في Laravel. (هذا الدرس) إنشاء واجهة لبرمجة التطبيقات API في Laravel. إنشاء مدوّنة باستخدام Laravel. استخدام AngularJS واجهةً أمامية Front end لتطبيق Laravel. الدوّال المساعدة المخصّصة في Laravel. استخدام مكتبة Faker في تطبيق Laravel لتوليد بيانات وهمية قصدَ الاختبار. يغطي الدرس المواضيع التالية: إعداد الاستيثاق في Laravel 5. أساسيات الاستيثاق في Laravel 5. تغيير رابط تسجيل الدخول المبدئي. إعدادات الاستيثاق في Laravel 5 يوجد ملف إعداد الاستيثاق على المسار config/auth.php. في ما يلي جزء من الملف: 'model' => App\User::class, 'table' => 'users', 'password' => [ 'email' => 'emails.password', 'table' => 'password_resets', 'expire' => 60, ], يحدّد الملف: اسم نموذج الاستيثاق. اسم جدول المستخدمين. خيارات إعادة تعيين كلمة السر. سنستخدم النموذج User لاستيثاق المستخدمين. افتح الملف User.php وعدّله على النحو التالي: <?php namespace App; use Illuminate\Auth\Authenticatable; use Illuminate\Database\Eloquent\Model; use Illuminate\Contracts\Auth\Authenticatable as AuthenticatableContract; class User extends Model implements AuthenticatableContract { use Authenticatable; /** * The database table used by the model. * * @var string */ protected $table = 'users'; /** * The attributes that are mass assignable. * * @var array */ protected $fillable = ['name', 'email', 'password']; /** * The attributes excluded from the model's JSON form. * * @var array */ protected $hidden = ['password', 'remember_token']; } فلنعرّج قليلا على الأصناف الجديدة علينا: use Illuminate\Contracts\Auth\Authenticatable as AuthenticatableContract; توجد في Laravel أصناف يطلق عليها اسم العقود Contracts. العقود هي مجموعة واجهات Interfaces تعرّف خدمات يوفّرها إطار العمل. تعرّف العقود دوال يحتاجها إطار العمل لتأدية الخدمة. يستورد السطر أعلاه العقد Authenticatable وهي واجهة تعرّف الدوال الضرورية لاستيثاق المستخدمين. عند استيراد الواجهة أعطيناها الاسم AuthenticatableContract حتى لا تختلط مع السمة Trait الذي يحمل نفس الاسم (نستعمله في نموذج المستخدم كما سنرى لاحقا). يجب على الكائن الذي يستوثق من المستخدمين (نموذج المستخدم في حالتنا) أن ينجز Implement هذه الواجهة: class User extends Model implements AuthenticatableContract لإنجاز دوال الواجهة (تعرّف واجهة Authenticatable الدوال دون أن تنجزها) نستخدم السمة Illuminate\Auth\Authenticatable. نستورده أولا: use Illuminate\Auth\Authenticatable; ثم نستخدمه: use Authenticatable; يحدّد النموذج جدول البيانات المستخدم لتخزين بيانات المسجَّلين، ويفعّل الإسناد الشامل لبعض الحقول. تعيّن مصفوفة hidden$ بيانات المستخدم التي لا نودّ عرضها عند الإجابة على طلب عبر واجهة تطبيقات برمجية API (يجب إخفاء كلمة سر المستخدم password ورمز الأمان remember_token عن الخارج). يأتي مع Laravel مبدئيا ملف تهجير لإنشاء جدول المستخدمين. افتح ملف التهجير 2014_10_12_000000_create_users_table.php (قد يختلف الختم الزمني في اسم الملف حسب إصدار Laravel): <?php use Illuminate\Database\Schema\Blueprint; use Illuminate\Database\Migrations\Migration; class CreateUsersTable extends Migration { /** * Run the migrations. * * @return void */ public function up() { Schema::create('users', function (Blueprint $table) { $table->increments('id'); $table->string('name'); $table->string('email')->unique(); $table->string('password', 60); $table->rememberToken(); $table->timestamps(); }); } /** * Reverse the migrations. * * @return void */ public function down() { Schema::drop('users'); } } يعرّف ملف التهجير حقول جدول المستخدمين. تعيّن الدالة rememberToken رمز حماية لتأمين المستخدمين ضدّ هجمات تزوير الطلب عبر الموقع CSRF. استمارات التسجيل والولوج Login يوجد في عرض الدخول login.blade.php استمارتان، واحدة لتسجيل المستخدمين Registration والأخرى لدخولهم Login. افتح ملف العرض login وحدّثه على النحو التالي: @extends('layouts.layout') @section('content') <section id="form"><!--form--> <div class="container"> <div class="row"> <div class="col-sm-4 col-sm-offset-1"> <div class="login-form"><!--login form--> <h2>Login to your account</h2> <form method="POST" action="{{url('auth/login')}}"> {!! csrf_field() !!} <input type="email" name="email" id="email" placeholder="Email Address" /> <input type="password" name="password" id="password" placeholder="Password" /> <span> <input name="remember" id="remember" type="checkbox" class="checkbox"> Keep me signed in </span> <button type="submit" class="btn btn-default">Login</button> </form> </div><!--/login form--> </div> <div class="col-sm-1"> <h2 class="or">OR</h2> </div> <div class="col-sm-4"> <div class="signup-form"><!--sign up form--> <h2>New User Signup!</h2> <form method="POST" action="{{url('register')}}"> {!! csrf_field() !!} <input type="text" name="name" id="name" placeholder="Name"> <input type="email" name="email" placeholder="Email Address"/> <input type="password" name="password" placeholder="Password"> <button type="submit" class="btn btn-default">Signup</button> </form> </div><!--/sign up form--> </div> </div> </div> </section><!--/form--> @endsection التغييرات الأساسية هنا هي: تعريف رابط مناسب لاستمارتي التسجيل والدخول مع تحديد أن البيانات تُرسَل بإجراء POST: // دخول المستخدمين <form method="POST" action="{{url('auth/login')}}"> // تسجيل المستخدمين <form method="POST" action="{{url('register')}}"> تُرسل بيانات الدخول إلى الرابط larashop.dev/auth/login وبيانات التسجيل إلى الرابط larashop.dev/register. تضيف التعليمة ()csrf_field حقلا أمنيا في الاستمارتين للحيلولة دون هجمات CSRF. مسارات الدخول، الخروج والتسجيل نضيف الآن المسارات الخاصة بالاستيثاق. افتح ملف المسارات routes.php وأضف المسارات التالية: // مسارات الدخول والخروج Route::get('auth/login', 'Front@login'); Route::post('auth/login', 'Front@authenticate'); Route::get('auth/logout', 'Front@logout'); // مسار التسجيل Route::post('/register', 'Front@register'); نعرّف المسار الذي يعرض استمارتي التسجيل والدخول: Route::get('auth/login', 'Front@login'); نعرّف إجراء HTTP POST الذي يوثّق المستخدمين: Route::post('auth/login', 'Front@authenticate'); نعرّف مسار خروج المستخدم: Route::get('auth/logout', 'Front@logout'); نعرف مسار تسجيل المستخدمين الجدد (إجراء HTTP POST): Route::post('/register', 'Front@register'); المسارات المَحمِيّة مسار محمي هو مسار يطلُب من الزائر الدخول قبل الوصول إليه. سنحمي في هذه الفقرة الرابط http://larashop.dev/checkout. يعني هذا أن المستخدمين المسجّلين فقط يمكنهم رؤية صفحة الدفع. عدّل مسار checkout/ في ملف المسارات ليصبح على النحو التالي: Route::get('/checkout', [ 'middleware' => 'auth', 'uses' => 'Front@checkout' ]); تُنفّذ التعليمة 'middleware' => 'auth', قبل دالة Front@checkout؛ وتتحقق من دخول الزائر. فإن لم يكن سجّل دخوله توجّهه إلى الرابط auth/login/، وتعرض له صفحة الدفع بعد الدخول. دوال التسجيل والاستيثاق نعدّل ملف المتحكّم لإضافة دوال تجيب على الطلبات القادمة من المسارات السابقة. افتح ملف المتحكم Front.php لتعديله. نبدأ باستيراد فضاءات الأسماء التي نحتاجها: use App\User; use Illuminate\Support\Facades\Auth; استوردنا نموذج المستخدم User وفضاء الأسماء الخاص بالاستيثاق Auth. توجد في فضاء الأسماء Auth الدوال والكائنات التي نحتاجها للاستيثاق من المستخدمين. تسجيل مستخدم جديد public function register() { if (Request::isMethod('post')) { User::create([ 'name' => Request::get('name'), 'email' => Request::get('email'), 'password' => bcrypt(Request::get('password')), ]); } return Redirect::away('login'); } تستخدم دالة التسجيل المعلومات المذكورة في استمارة التسجيل New User Signup! لإنشاء مستخدم جديد عبر طلب الدالة User::create (تعرّفنا على هذه الدالة خلال درس Eloquent ORM). ثم نوجّه الزائر بعد إلى صفحة الدخول. لاحظ استخدام الدالة bcrypt أثناء تسجيل المستخدم. تعمّي هذه الدالة كلمة السر قبل تخزينها في جدول البيانات. الاستيثاق من المستخدمين تستوثق الدالة التالية من المستخدمين: public function authenticate() { if (Auth::attempt(['email' => Request::get('email'), 'password' => Request::get('password')])) { return redirect()->intended('checkout'); } else { return view('login', array('title' => 'Welcome', 'description' => '', 'page' => 'home')); } } ستوثق الدالة Auth::attempt من المستخدم بناء على عنوان البريد email وكلمة السر password الذين أرسلتهما استمارة الدخول. في حال نجاح دخول المستخدم يُعاد توجيهه إلى صفحة الدفع checkout عبر الدالة ()redirect. تسجيل خروج المستخدمين يؤدي طلب الدالة Auth::logout إلى تسجيل خروج المستخدمين بعد دخولهم عبر الدالة السابقة. عدّل دالة logout الموجودة في ملف المتحكم لتصبح كالتالي: public function logout() { Auth::logout(); return Redirect::away('auth/login'); } تخرج الدالة المستخدم وتوجهه إلى صفحة الدخول. إظهار بيانات الدخول في العرض نحتاج، قبل اختبار التسجيل والدخول، إجراء تغيير أخير. تُظهر الصورة التالية الشريط العلوي الأيمن من الموقع: نريد أن يظهر الشريط على النحو التالي بعد دخول المستخدم: نريد أن يظهر اسم المستخدم بعد الدخول، وإبدال رابط Login بـLogout. افتح ملف العرض layout.blade.php للتعديل عليه. تذكر أن هذا هو العرض الرئيس الذي تمدّده بقية العروض. نغيّر جزئية الترويسة (header) من ملف العرض لتصبح كالتالي: <header id="header"><!--header--> <div class="header_top"><!--header_top--> <div class="container"> <div class="row"> <div class="col-sm-6"> <div class="contactinfo"> <ul class="nav nav-pills"> <li><a href="#"><i class="fa fa-phone"></i> +2 95 01 88 821</a></li> <li><a href="#"><i class="fa fa-envelope"></i> info@domain.com</a></li> </ul> </div> </div> <div class="col-sm-6"> <div class="social-icons pull-right"> <ul class="nav navbar-nav"> <li><a href="#"><i class="fa fa-facebook"></i></a></li> <li><a href="#"><i class="fa fa-twitter"></i></a></li> <li><a href="#"><i class="fa fa-linkedin"></i></a></li> <li><a href="#"><i class="fa fa-dribbble"></i></a></li> <li><a href="#"><i class="fa fa-google-plus"></i></a></li> </ul> </div> </div> </div> </div> </div><!--/header_top--> <div class="header-middle"><!--header-middle--> <div class="container"> <div class="row"> <div class="col-sm-4"> <div class="logo pull-left"> <a href="{{url('')}}"><img src="{{asset('images/home/logo.png')}}" alt="" /></a> </div> </div> <div class="col-sm-8"> <div class="shop-menu pull-right"> <ul class="nav navbar-nav"> <li><a href="#"><i class="fa fa-user"></i> {{Auth::check() ? Auth::user()->name : 'Account'}}</a></li> <li><a href="{{url('checkout')}}"><i class="fa fa-crosshairs"></i> Checkout</a></li> <li><a href="{{url('cart')}}"><i class="fa fa-shopping-cart"></i> Cart</a></li> <li><a href="{{Auth::check() ? url('auth/logout') : url('auth/login')}}"><i class="fa fa-lock"></i> {{Auth::check() ? 'Logout' : 'Login'}}</a></li> </ul> </div> </div> </div> </div> </div><!--/header-middle--> <div class="header-bottom"><!--header-bottom--> <div class="container"> <div class="row"> <div class="col-sm-9"> <div class="navbar-header"> <button type="button" class="navbar-toggle" data-toggle="collapse" data-target=".navbar-collapse"> <span class="sr-only">Toggle navigation</span> <span class="icon-bar"></span> <span class="icon-bar"></span> <span class="icon-bar"></span> </button> </div> <div class="mainmenu pull-left"> <ul class="nav navbar-nav collapse navbar-collapse"> <li><a href="{{url('')}}" {{$page == 'home' ? 'class=active' : ''}}>Home</a></li> <li><a href="{{url('products')}}" {{$page == 'products' ? 'class=active' : ''}}>Products</a></li> <li><a href="{{url('blog')}}" {{$page == 'blog' ? 'class=active' : ''}}>Blog</a></li> <li><a href="{{url('contact-us')}}" {{$page == 'contact_us' ? 'class=active' : ''}}>Contact Us</a></li> </ul> </div> </div> <div class="col-sm-3"> <div class="search_box pull-right"> <input type="text" placeholder="Search"/> </div> </div> </div> </div> </div><!--/header-bottom--> </header><!--/header--> أضفنا التغييرين التاليين على ترويسة العرض: إبدال Account بالتعليمة: {{Auth::check() ? Auth::user()->name : ‘Account’}} نستعمل الدالة Auth::check للتحقق من دخول المستخدم؛ في حال الإيجاب نظهر اسمه بالدالة Auth::user وإلا نبقي على عبارة Account. نفس المبدأ مع عبارة Login التي تصبح بعد الدخول Logout، وتغيير الرابط بما يُناسب (larashop.dev/auth/login للدخول وlarashop.dev/logout للخروج). افتح الرابط http://larashop.dev/auth/login وسجل مستخدما جديد عبر الاستمارة New User Signup. بالضغط على زر Signup تستدعي المسار http://laravel.dev/register مع الإجراء POST. تتولى دالة register في المتحكم تلقي الطلب واستدعاء النموذج الذي ينشئ تسجيلة جديدة في جدول البيانات ثم تعيد الدالة توجيه المستخدم إلى صفحة الدخول. يمكنك التأكد من إنشاء المستخدم في الجدول users ضمن قاعدة البيانات. نجرّب الدخول بالمستخدم الجديد بإدخال عنوانه البريدي وكلمة السر في استمارة التسجيل. إن أدخل بيانات مستخدم صالحة فستُنقل إلى صفحة الدفع. لاحظ أن اسم المستخدم وعبارة Logout يظهران في الشريط العلوي. ترجمة -وبتصرّف- للمقال Laravel 5 Authentication لصاحبه Rodrick Kazembe.

لقد شاع استخدام الاقتباس التالي (وأحيانًا بطريقة خاطئة) لهنري فورد، وقد اتضح مؤخّرًا أن هنري فورد لم يقل هذه الكلمات أصلاً، لكنني لحسن الحظ لا أكتب بحثًا أكاديميًا، وإنما أكتب مقالاً، لذا، بغض النظر عن دقة المعلومات التاريخية، أظن أنكم تتفقون معي حيال كون هذا الاقتباس محفزًا للعديد من الأفكار. وإليكم اقتباسًا آخر، هذه المرة من ستيف جوبز: لقد عرف ستيف جوبز بوضوح أن المستخدم ليس على حق دائمًا. لا يعرف المستخدمون ما هو مناسب لهم كما ترى، لقد عرف كل من ستيف جوبز وهنري فورد درسًا بالغ الأهميّة. درسٌ لم يفهمه الكثير من المصمّمين، الباحثين ورجال الأعمال: لا يعرف الزبون والعميل ما هو جيّد له. ولا أتحدث هنا عن أمور ابتكار المنتجات والخدمات الجديدة، أنا أتحدث بصفة عامة. لا يعرف المستخدمون ما هو جيّد بالنسبة لهم ببساطة وحسب، نعم، لقد سمعت ذلك بوضوح. ليس المستخدم على حقٍ دائمًا، في الواقع، غالبًا ما يكون المستخدم مخطئًا بكل بساطة. بالطبع، ليس ذلك خطأ المستخدم. فكيف نتوقع من المستخدمين أن يكونوا على صواب مع ضيق أفقهم ومحدوديته في نظرتهم السطحية للأمور وآرائهم الفردية حيال مشكلة ما في التصميم؟ لنتوقف عن ممازحة أنفسنا. فالمستخدمون ليسوا مصممين، وفي أغلب الوقت لا يكونون خبراءً في المجال، وحتى لو عرفوا مدخلات ومخرجات الموضوع، سيبقون دائمًا ناقصي الخبرة في تحويل المعرفة بالموضوع إلى حلول تصميم جيدة. مع ذلك، أصادف أحيانًا من يتوقعون أننا سنحتاج فقط إلى سؤال المستخدمين كي يعطونا بأعجوبة كل الأجوبة التي نريدها. سنسأل المستخدمين عمّا يحتاجونه، سنسأل المستخدمين عن المزايا الأهم بالنسبة لهم، سنسأل المستخدمين عن كيفية تنظيم الموقع، سنسأل المستخدمين عمّا يجب وضعه في الصفحة الرئيسية. لنسأل المستخدمين تذكّرني هذه الثقافة الخطرة، ثقافة "لنسأل المستخدمين" بحلقة مميزة من "The Simpsons". أحب أن أستخرج أفضل دروس الحياة من هذه المُسلسل، كنصيحة Homer التي تقول، "إذا لم تنجح من المرة الأولى، استسلم". في إحدى الحلقات يكتشف Homer بأن لديه أخًا غير شقيق يدعى Herb، وصادف أن Herb هو رئيس مصنع Powell motors، مصنع أمريكي كبير، ومع انخفاض مبيعات المصنع، يطلب Herb من Homer أن يساعده في تصميم سيارة للمواطن الأمريكي البسيط، سيارة عادية لزيد وعبيد، من المصمم فلان العادي (أو ربما الأقل من العادي بالنسبة لـ Homer)، ويأمر Herb مصممي سياراته بأن يعطوا زمام تصميم السيارة إلى Homer ويستعملوا كل أفكاره، مهما بلغ جنونها. إنها مريعة لأنها سيارة مصممة بواسطة ولأجل Homer، ولأن من صمّمها ليس مصمّمًا، آمل أن لدى مستخدميك ذوقًا أرقى من ذو Homer (رغم أنني لا أضمن لك ذلك)، لكنني عمومًا أظن بأن هنالك درسًا مهمًا وراء هذه القصة: لا يعرف المستخدمون ما هو أفضل لهم، حتى المستخدمين الخياليين. سيارة Homer - إيضاح لما قد يحدث عندما تتبع اقتراحات المستخدمين اتباعًا أعمى. التصميم ليس مهمة الزبون كما ترى، إنها مسؤولية المصممين. ليس على المستخدمين أن يبدعوا حلولاً مذهلة لتحلّ مشاكلهم. ولا أعني بمسؤولية المصممين فقط من عمله هو التصميم، إنني أعني كامل فريق المنتج. يمكن للمطوّر أن يكون مصمّمًا بقدر ما يمكن لمصمم تجربة الاستخدام أن يكون مصممًا عاديًّا، يمكن للمستخدم من ناحية أخرى أن يكون مصمّمًا سيئًا، وتوقع غير هذا هو مجرّد كسلٍ في التصميم. إن مهمة فهم المستخدمين تعود على المصممين وفريق المنتج مهمة تحديد احتياجاتهم، مشاكلهم، آمالهم، أمنياتهم وأحلامهم، مهمة صنع حلول تصميمٍ أنيقة، مفيدة وسهلة الاستعمال لتلبّي احتياجاتهم تعود تمامًا عليهم، حتى لو لم يدرك المستخدمون حاجتهم لتلك الحلول، كما هو عليه الحال مع سيارة model T وجهاز الـ iPad. التصميم للأطفال كأبٍ لطفلين صغيرين، أرى أن العلاقة بين المصممين والمستخدمين تبدو مشابهة بعض الشيء للعلاقة بين أب وأطفاله (أو طفله). يجب عليك كأب أن تضع أبناءك في المركز. أبناؤك يأتون دومًا في المقام الأول، بدءًا من اتخاذ قرار حيال ما يجب عليك أن تفعله في يوم ماطر ووصولًا إلى التفكير في الطعام الذي يجب عليك أن تشتريه لهذا الأسبوع، كل ما تفعله مرتكز على احتياجات أطفالك. لكن ما يجب عليك ألّا تفعله هو ترك الأطفال ليُخبروك بما يجب عليك فعله لأنهم سيحاولون فعل ذلك، صدّقني سيحاولون! أنت الرئيس بالتأكيد بلا شك، لذلك، أنت العاقل هنا وأنت الأعلم بالأمور (أو على الأقل، هذه هي الصورة التي تحاول إظهارها). وهذه هي الطريقة التي يجب أن تعامل بها المستخدمين. لا أعني بهذا أن الواجب عليك هو معاملة المستخدمين كأطفال (إلا إن كانوا أطفالًا بالفعل)، لكن الواجب عليك هو إمضاء وقتك في محاولة فهمهم، إيجاد ما هو أفضل لهم، أخذهم لأيامٍ من المرح بجانب البحر، وأن لا تتبع إراداتهم اتباعًا أعمى. بالتأكيد، يجب عليك أن تُشرك المستخدمين في عملية التصميم، أن تأخذ آرائهم، تجرّب أفكارهم وتصوّراتهم، اقتراحاتهم وإضافاتهم، دون أن تنسى بأنك خبير التصميم وليسوا هم. أنت من تقود عملية التصميم، وليسوا هم. أود أن أترككم مع هذا الاقتباس الأخير، هذه المرة من Alan Cooper خبير تجربة المُستخدم وأب الـ Visual Basic، وقد أُخذت هذا الاقتباس من محادثة في مؤتمر لـ Microsoft يتحدث فيه Alan عن السبب الذي يجعل من المستخدمين مصدرًا سيّئًا لأخذ لتكوين فكرة عن برنامج ما. إليكم ما قاله Alan Cooper: أظن بأن Alan كان يمزح قليلًا حين قال بأن المستخدمين لا علاقة لهم به، لكنني أرجو أن فكرة Alan قد وصلت إليكم. وبالنسبة لي، لا أخالفه الرأي أبدًا. ترجمة -وبتصرف- للمقال Why the user is not always right لصاحبه Neil Turner.

تقوم على الأقل بعمليّة تسجيل دخول واحدة كل يوم. من تسجيلك الدخول إلى حاسوبك، وحتى تسجيلك الدخول إلى موقع تواصلك الاجتماعي المفضّل، لقد أصبحت هذه العمليّة جزءًا من الحياة اليومية الرقمية. ورغم أن هذه العمليّة شائعة جدًا الآن، إلا أنني ما زلت أندهش من الكم الكبير لصفحات وعمليّات تسجيل الدخول ذات التصميم السّيئ. تأكد من كون صفحة تسجيل الدخول الخاصة بموقعك لا تحتوي على أي عقبات تعيق مستخدمي موقعك باتباعك لهذه النصائح العشرة لتحسين صفحة وعمليّة تسجيل الدخول. 1. أوضح مكان تسجيل الدخول من المفترض أن يكون مكان تسجيل الدخول واضحًا حينما يزور المستخدمون موقعًا أو تطبيقًا لديهم عليه حساب بالفعل. سيكون من الأفضل إظهار حقول الإدخال لكي يتمكن المستخدمون مباشرة من الدخول، بدلاً من توفير رابط خارجي لـ"تسجيل الدخول". من الأفضل أن تظهر حقول الإدخال في موقعك مثلما تفعله فيس بوك، بدلاً من وضع رابط فحسب. من الواجب جعل تسجيل الدخول أساسًا للصفحة إذا كان تسجيل الدخول ضروريًَا لاستعمال الموقع. لا تجبر المستخدمين على البحث عن زر تسجيل الدخول كما هو عليه الحال مع موقع Evernote في صفحته الرئيسية. سيحتاج مستخدمو Evernote إلى البحث كثيرًا لإيجاد طريقة تسجيل الدخول. 2. ميز ما بين تسجيل الدخول وتسجيل حساب أصبحت حقول إدخال تسجيل الدخول (البريد الإلكتروني وكلمة المرور) متشابهة جدًا، إذا لم تكن متطابقة مع حقول إدخال تسجيل الحساب (البريد الإلكتروني وكلمة المرور) في مواقع عديدة متزايدة. من الضروري لذلك أن تفرّق بوضوح بين الاثنين، وأن تقلّل فرصة إخطاء المستخدمين الذين يحاولون تسجيل الدخول عبر نموذج تسجيل الحساب. إحدى الطرق لفعل ذلك هو أن تطلب إدخال كلمة المرور مرتين عند تسجيل الحساب (ستكون هذه فكرة جيدة دائمًا بما أن كلمات المرور لا تظهر عند الإدخال)، أو أن تظهر نموذجًا واحدًا بدل اثنين في صفحة واحدة. تجنّب فعل ما قام به موقع AxShare من إظهار النموذجين بجانب بعضهما. لقد أخطأت عدة مرات أثناء محاولتي تسجيل الدخول بملء نموذج تسجيل الحساب. من السهل تشتيت المستخدم عن نموذج تسجيل الدخول بنموذج تسجيل الحساب في موقع AxShare. 3. اسمح للمستخدمين بتسجيل الدخول عبر حساب خارجي (كحساب فيس بوك مثلا) لماذا تجبر المستخدمين على تذكر معلومات إدخال جديدة كل مرة في حين أن تسجيل الدخول من حساب خارجي قد صار أسهل الآن، كتسجيل حساب باستعمال حساب مسبق في Facebook ،Google أو LinkedIn، بالطبع، لن يوّد الجميع فعل ذلك، لكنها طريقة جيّدة لتسهّل تسجيل الدخول على مستخدميك في موقعك أو تطبيقك، باستخدام حساب يستعملونه يوميًّا. يسمح موقع Ocado بذكاء لمستخدميه بأن يسجّلوا دخولهم مستعملين حساباتهم على Facebook أو PayPall. 4. استعمل البريد الإلكتروني، بدلا من اسم المستخدم تثير هذه المشكلة غضبي في قابليّة استخدام العديد من المواقع، تحديدًا، المواقع التي تطلب من المستخدمين تسجيل دخولهم باسم مستخدمٍ عوضًا عن استخدام بريد إلكتروني لتسجيل الدخول. لديّ بريدان إلكترونيّان (بريد شخصي وآخر للعمل)، والعديد من الأسماء التي أستخدمها لمواقع مختلفة، وبما أن اسم المستخدم يجب أن يكون مميّزًا، فستكون أسماء المُستخدمين المفضّلة محجوزة مسبقًا بالتأكيد، وسيؤدي هذا بالمستخدم إلى استعمال اسم جديد لن يتذكّره أبدًا. إذا كان موقعك أو تطبيقك يستخدم الأسماء لتسجيل الدخول كما تفعل شبكة تويتر، فاسمح على الأقل بخيار لتسجيل الدخول باستعمال البريد الإلكتروني. تسمح شبكة التواصل الاجتماعي تويتر لمستخدميها بتسجيل الدخول مستعملين رقم الهاتف، البريد الإلكتروني أو اسم المستخدم. 5. وفر للمستخدمين إمكانية رؤية كلمة المرور (إن أرادوا ذلك) من المشاكل الشائعة التي يواجهها المستخدمون عادة عند محاولتهم لتسجيل الدخول هي كتابة كلمة مرور خاطئة. من السهل أن تحدث هذه المشكلة بما أن حقل إدخال كلمة المرور لا يكشفها. ستكون ميّزة السماح للمستخدمين (إذا أرادوا) بأن يعرضوا كلمة مرورهم مفيدة حقًا، وذلك بعرض زرّ لإظهارها. من المفترض أن يكون هذا الزرّ غير مفعّل (بمعنى أن كلمة المرور ستكون غير ظاهرة افتراضيًّا). وسيكون هذا مفيدًا أكثر لصفحات تسجيل الدخول على الهاتف، بما أن الضغط على الزرّ الخاطئ محتمل جدًا مع أزرار لوحة المفاتيح الصغيرة. تسمح Microsoft بذكاء لمستخدميها بأن يُظهروا كلمة مرورهم أثناء تسجيل الدخول في العديد من تطبيقاتهم على الهواتف. 6. أخبر المستخدم إذا كان يستخدم الأحرف الكبيرة سيكون تحذير المستخدم بكون زر Caps Lock مفعّلاً طريقةً بسيطةً لمساعدة المستخدمين على إدخال كلمة المرور الصحيحة. إخبار المستخدمين بأنهم يستعملون الأحرف الكبيرة هو أمر جيّد. 7. سهل عملية تغيير كلمة المرور إذا نسيها المستخدم مثلما ينسى الجميع في بعض الأحيان أسماء الناس، محفظاتهم، أو أعياد ميلادهم، أو ذكرى زواجهم (وأنصحك بأن تتجنب نسيان هذه الأخيرة)، سينسى المستخدمون كلمات سرّهم أيضًا. من المهم لهذا أن تكون عمليّة استعادة كلمة المرور أو تغييرها في حال نسيانها (وسيحصل هذا بالفعل!) أمرًا بالغ السهولة. كبداية، تذكّر دائمًا وضع رابط يحتوي على جملة واضحة كـ"هل نسيت كلمة مرورك؟" ليُستخدم بسهولة من قبل مستخدميك. وإذا أردت إبقاء صفحة تسجيل الدخول بسيطة قدر الإمكان، فمن الأفضل أن تُظهر هذا الرابط عند إدخال كلمة المرور الخاطئة، أو أثناء الإدخال في حقل كلمة المرور، لكن المفترض أساسًا هو أن يكون ذلك الرابط موجودًا دائمًا. لا تُجبر المستخدمين على إعادة إدخال بريدهم الإلكتروني في صفحة استعادة كلمة المرور ولا ترسل أبدًا كلمة المرور أو كلمة مرور مؤقتة عبر البريد الإلكتروني (ليس ذلك بأمرٍ ذكيّ!). أفضل أمرٍ لتفعله هو إرسال رابط لصفحة استعادة كلمة المرور عبر البريد الإلكتروني الذي تم التسجيل به. وتأكد أيضًا من إرسال بريد استعادة كلمة المرور فوريًّا، فلا شيء أسوء من الانتظار لفترة طويلة قبل تسجيل الدخول لتأخر بريد الاستعادة. لدواعِ أمنية قد ترغب في التّحقق من هوية المُستخدم قبل أن تسمح له بطلب إعادة كلمة السّر (يحدث الأمر عادة مع مواقع الـB2B). اطلب من المُستخدم أن يجيب على سؤال مُعيّن تعلم أن المستخدم الحقيقي للحساب هو الوحيد القادر على الإجابة عليه. المهم هو أن تكون منطقيًّا أثناء عرضك لأسئلة الأمان، فلن يتذكر أغلب الناس الإجابة الصحيحة إذا سألتهم عن أشياء يسهل الإجابة عنها بشكل خاطئ. أحد الأفكار الذكيّة التي يتّبعها موقع Evernote هو تذكير المستخدمين بآخر مرة غيّروا فيها كلمة مرورهم إذا أدخلوا كلمة المرور الخاطئة. 8. حذر المستخدمين قبل إقفال الحساب لتجنّب هجوم القوة العمياء، يُقفل حساب المستخدم عادة لفترة زمنيّة بعد بضعة محاولات فاشلة لتسجيل الدخول. بالطبع، هذا أمر ضروري لأمان الحساب، لكن من الواجب عليك أن تُعلم المستخدم بأن حسابه سيتعرض للإقفال، كمثال، إذا كان الحساب سيُقفل لـ10 دقائق بعد خمسة محاولات مخفقة للدخول، حذّّر المستخدم بعد المحاولة الثالثة بأن حسابه سيُقفل لعشرة دقائق إذا لم ينجح في تسجيل الدخول في المحاولتين القادمتين. 9. أبق حسابات المستخدمين مفتوحة بعد فتح حساباتهم مضت تلك الأيام التي يدخل فيها النّاس إلى المواقع والخدمات من حواسيب عمومية (هل تتذكر أيام مقاهي الإنترنت؟)، لذا، بدلاً من إتاحة خيار "احفظ بيانات تسجيل الدخول" (Keep me signed in)، من الأفضل أن تُبقي حسابات المستخدمين مفتوحة بعد تسجيل الدخول في الموقع أو التطبيق لمدة زمنيّة محددة (طالما أن الأمان ليس مطلبًا بالغ الأهميّة مثلما هو عليه الحال مع التطبيقات والمواقع البنكية). بالطبع، في بعض الأحيان سيكون الحاسوب مشتركًا (بين أفراد الأسرة على سبيل المثال)، ولهذا، من الضروري أيضًا أن يتمكّن المستخدم من تسجيل الدّخول بحساب آخر في أي وقت. 10. تذكر المستخدم حين يعود تأكد حين يضطر المستخدم إلى إعادة تسجيل الدخول من أن معلوماته محفوظة لديك. وأن المتصفح قادر على ملء حقول الإدخال تلقائيًّا (كحقل البريد الإلكتروني) وتذكّر معلومات الحساب إن أمكن ذلك، بما لا يجبر المستخدم على ملء أي حقل سوى كلمة المرور. تسهّل خدمات Google على مستخدميها تسجيل الدخول بتذكّر الحساب، بحيث لا يحتاج المستخدم إلا لإدخال كلمة المرور. ترجمة -وبتصرف- للمقال: Ten 10 tips for a better login page and process لصاحبه Neil Turner.