تجربیات کاری – قسمت دوم: Validation ها و عمه برنامه نویس!

اگر بخش یک رو نخوندید از اینجا بخونید:  تجربیات کاری – قسمت اول: Back Button ها

این دفعه میخوام از یک چیزی صحبت کنم که بعضا شاید خودمون به عنوان برنامه نویس باهاش سروکار داشتیم و ازش رد شدیم و واگذار کردیمش به کاربر یا هم مسئولیت پذیریمون بالا بوده و خودمون انجامش دادیم تا کاربرمون بهترین تجربه رو از مخلوق ما کسب کنه. یا هم اصلا اونقدر درکمون پایینه که نمیدونیم همچین چیزاییم هست و ممکنه پیش بیاد!


بیاین سه تا مثال بزنیم:

۱- علی وارد یک سایت مالی دولتی میشه که یک سری کار انجام بده.علی یک لیست بلند بالا از اعداد رو بعد از کلی وارد کردن عدد و تیک و … پر میکنه و در نهایت هم کد ملیشو بدون زدن ۰ وارد میکنه و بعد که فرم رو تایید میکنه، ای داد بیداد یک پیام میاد که “لطفا در ورود اطلاعات دقت کنید!” یا هم شانس میاره و میگه مثلا “کد ملی خود را اصلاح کنید”. حالا علی باید دوباره فرم رو پر کنه و حواسشو جمع کنه !

۲- آرمان میخواد در یک دنیای موازی یک نشریه دانشگاهی ثبت کنه. میره تو سایت دانشگاهشون و مثلا از لیست دسته بندی ها یک دسته بندی خاص رو انتخاب میکنه و از یک لیست دیگه هم باید دانشکده نشریه شو انتخاب کنه که خب میکنه. بعد که کاراش تموم میشه و فرم شو هم پر میکنه و میخواد که تایید کنه، سایت بعد از رفرش شدن بهش میگه که اصلا این دسته بندی خاص تو این دانشکده خاص پشتیبانی نمیشه! یعنی انگار مهم بوده که هماهنگی بین دسته بندی و دانشکده رعایت بشه. ولی خب آرمان این موضوع رو باید میدونسته و از بین لیست های طویل پیش روش، همون مواردی که با هم ارتباط دارن رو انتخاب میکرده، ولی خب یا حواس پرتی کرده یا هم هر دلیل دیگه. (در صورتی که یک برنامه نویس حرفه ای  که در اصل یک هنرمند باسلیقه هستش، میدونه که باید داده های مرتبط با هم به کاربر داده بشه نه بگیم بیا اینا همشه. خودتی و خدای خودت و هرکار میخوای بکن!)

۳− ریحانه میخواد یک محصول پستی رو رهگیری کنه. کدی که براش پیامک شده رو داره برای مامانمش میخونه تا تو سیستم وارد کنه. یک جا مامانمش به جای ۴ میزنه ۵. خب بعد که تایید میکنه، سیستم صفحه رو رفرش میکنه و بهش میگه اشتباه زدی! حالا اونا دوباره باید تایپ کنن! (البته تو این مثال بحث ولیدیشن رعایت شده ولی یکم فراتر از ولیدیشن بهش خواستم فکر کنم. توجه به عمر و زمان و اعصاب کاربر و عمه خودمون!)


validation ها چه در سمت کلاینت و چه در سمت سرور خیلی ضروری هستن و در نهایت به سود کاربر و ما (برنامه) هستش. اگرچه شاید ما حواسمون به یک سری از اعتبارسنجی های اولیه باشه (مثلا اگر جایی قراره ایمیل بگیریم از type ایمیل تو html استفاده کنیم) ولی این ممکنه بعضی مواقع، ما رو از چیزهای مهم و ریز دیگه غافل کنه.


چاره چیه؟ چطور حواسمون به ضروریات اولیه و کمی بیشتر از اولیه، باشه؟ و حتی کاری کنیم که کاربر بهترین تجربه ممکن رو از کارش ببره؟ (چون شما اگر بهترین نرم افزار دنیا رو هم ساخته باشید تا زمانی که مشکلی تو کار نباشه کسی به شاهکار شما پی نمیبره ولی اگر یک مشکل خیلی خیلی کوچیک به وجود بیاد تمام اون شاهکار میره یک طرف و اون مشکل هم یک طرف! چرا؟ نمیدونم! باید ساختار مغز انسان رو بررسی کنیم. احتمالا جواب اونجاست)

پاسخ اینه:

  • تکلیفتون با خودتون مشخص باشه! بدونید چه type ها و داده هایی دارید میگیرید و چه ساختاری بر داده ای که دریافت میکنید حاکمه!  آیا من کد ملی میگیرم؟ پس حواسم باشه کد ملی تو کشور ایران چه قواعدی داره و بر اساس اونا جلوی هر اشتباهی رو قبل از اتلاف وقت بگیرم! مثلا: لینک، یا این که من با اعداد فارسی که کاربر وارد میکنه چه کار میکنم؟ تکلیفشون چیه؟ آیا همه چیز باید کاراکتر های انگلیسی در نظر گرفته بشه و کاربر اینو میدونه؟ و کلی از این چیزا که به فراخور کارتون باید پیداش کنید.
  • مخاطب نرم افزار شما، شما نیستی! خودتونو بزارین جای کاربر بیچاره ای که قراره از برنامه ای که شما خالقش بودین استفاده کنه! چه حالت هایی ممکنه پیش بیاد؟ تک تک رو تست کنید. بهترین (و هوشمندانه ترین) واکنش برنامه رو تو هر حالت پیاده کنید!
  • از بعضی مخاطب های اصلی برنامه تون که در دسترس هستن خواهش کنین که زمانی رو به تست برنامه شما اختیار بدن و شما تحلیل آبگوشتی خفن از رفتارهاشون بکنین (احتمالش هست درخواست هزینه کنند که خب کارفرما یا مافوق شما در پروژه باید به نوعی عهده دارش بشه)
  • بقیه نرم افزارهای خوب چطور این موارد رو انجام میدن؟ ایده بگیریم.

البته افراط و تفریط همیشه محکوم هستند. لازم نیست تو کلاینت ها یک میلیارد Event listener رجیستر کنیم و هزارتا if else و switch بزاریم که جلوی اشتباهات رو بگیریم (که کاربر با پر شدن حافظه اش بهای این رو باید بپردازه!). با ساده سازی مسائل و تحلیل های درست احتمالا هیچ وقت کار به جاهای سخت کشیده نمیشه!


و در نهایت نکته ای که میخوام بگم که برای خودم خیلی تاثیرگذار بود این بود که تو هر پروژه ای که توش سهیمید، اشتباهاتتون رو در بیارید، آرشیو کنید و چک لیست بسازید ازش. شما نباید اشتباهات پروژه N رو در N+1 ام تکرار کنید و احتمالا تو پروژه N هم اشتباهات N-1 رو تکرار نکردید! وگرنه باید به بعضی چیزها شک کنید! آرشیو کردن این چیزا به صورت مکتوب یا هر روش دیگه خیلی به آینده کاری و حرفه ای شدنمون کمک میکنه و در  نهایت جامعه و خودمون سودشو میبریم.


با یک سری اعتبار سنجی های ساده میتونیم هم از حجم بار SERVER کم کنیم هم به کاربر لذت کار با تکنولوژی رو با مخلوقمون بچشونیم!


خیلی دوست دارم تجربیات شما یا حتی خاطره های تلخ و شیرین شما رو بخونم تا بیشتر یاد بگیرم. من خودم پر از خاطره های تلخ و شیرینم تو پروژه ها فقط به خاطر همین اعتبار سنجی ها 🙂

امیدوارم هر جا هستید خالق بهترین شاهکارهای زندگیتون باشید و سالم و تندرست و پر از انرژی و امید و انگیزه باشید!

 

 

۱ دیدگاه

  1. آره همین چیزای ساده و شاید نادیدنی باعث تجربه کاربری قوی میشن.
    به نظرم خیلی لازمه که به اینجور چیزا ساده توجه بکنه ادم موقع طراحی یک سیستم.
    مثلا خود من وقتی رو یک سیستمی پسوردمو فراموش میکنم. و یک بار قبل پسوردمو با ایمیلم زدم واقعا رو مخمه که تو ص ریکاوری پسورد دوباره ایمیلمو وارد کنم.
    اون سایت هایی که خودشون وار کردن و واقعا عزیز میدونم 🙂

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *