از بین بردن بلاتکلیفی بین تجربه کاربری و تجربه توسعه دهنده – قسمت اول

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

این به این معنی است که دیگر نمی‌توانیم در مورد تجربه کاربری (UX) بدون اینکه عملکرد را به عنوان شرط درجه یک بدانیم، صحبت کنیم. مطالعه گوگل نشان داد که ۵۳% از کاربران تلفن همراه، صفحه وبی را که بیش از سه ثانیه طول بکشد تا بارگذاری شود، ترک می‌کنند و هیچ کدام از ما مایل به از دست دادن نیمی از ترافیک خود نیستیم، درست است؟

تجربه کاربری و تجربه توسعه‌دهنده

• تجربه کاربری و عملکرد در حال حاضر در تئوری باهم همسو هستند

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

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

• تجربه کاربری و عملکرد و کارایی در عمل دارای مشکلاتی هستند

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

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

تلاش‌های ما برای اندازه‌گیری و بهبود UX با تلاش‌های طعنه‌آمیز و عجیب برای دوست داشتن کاربران مان همراه است: ما سعی در پیدا کردن راه‌هایی برای بهبود تجربیات خود از طریق تجزیه و تحلیل کردن، آزمایش کردن شکاف و انشعاب، تجزیه و تحلیل رفتاری می‌کنیم. ما پلاگین‌های مربوط به کتابخانه‌های شخص ثالث را بر روی چارچوب‌هایی به نام ایجاد وب سایت “بهتر” دسته‌بندی می‌کنیم – چه این کار گمراه‌کننده باشد، یا چیزی که واقعا برای کمک به مردم درنظر گرفته شده است، مانند یک پوششی در قالب چت برای بخش پشتیبانی. اغلب نتیجه، بارگذاری کندتر صفحه، یک تجربه ناامید کننده، و / یا یک تن کد اضافی و منتقل‌شده به مرورگر است.

پیامی که ما ارسال می‌کنیم این است: “ما به تجربه شما به عنوان یک کاربر اهمیت می‌دهیم و می‌خواهیم آن را متوقف کنیم تا بتوانیم از شما در مورد آن سوال کنیم و نحوه استفاده شما از چیزهایی را که می‌سازیم را متوجه شویم!

• با تلاش برای بهتر کردن آن، آن را بدتر می کنیم

ما این ویژگی را اضافه نمی کنیم تا به طور عمد تجربه کاربرانمان را خراب کنیم ؛ ما آن را اضافه می کنیم زیرا این ویژگی شامل ابزارهایی است که مشکلات سخت توسعه را حل می کنند ، بنابراین لازم نیست که برنامه را تغییر دهیم.

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

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

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

این پارادوکس – یعنی گام‌هایی که برای کمک به مصرف کنندگان مان در نظر می‌گیریم، به طور ناخواسته این تجربه را برای آن‌ها بدتر می‌کند – منجر به چیزی می‌شود که نیکول سالیوان آن را “بن بست بین تجربه توسعه دهنده و تجربه کاربر” می‌نامد.

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

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

تجربه توسعه دهنده فراتر از ابزارهای تکنولوژیک است

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

با این حال، وقتی به مسافرت می‌روم، از آشپزی متنفرم. وسایل آشپزی در Airbnbs همیشه قابلمه های  IKEAو چاقوهای کند و پلوپزهایی با حرارت غیر یکنواخت است و من نمی‌دانم که کدام چیز کجاست. هر وقت که من سعی می‌کنم در این محیط ها آشپزی کنم،  شاید غذا قابل خوردن ‌شود، اما مسلما زیاد هم عالی نیست.

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

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

• تجربه توسعه دهنده خوب، داشتن آزادی برای فراموش کردن است

مانند پخت‌وپز، اگر ابزار توسعه ما به خوبی برای کار در دسترس باشد، ما می‌توانیم بدون نگرانی در مورد جزییات اساسی، کار را به نحو احسنت انجام دهیم.

وقتی اولین سطرهای HTML و CSS را نوشتم، از نوت پد ساده قدیمی استفاده کردم. هیچ گونه هایلایت دستوری و اصلاح خودکار، یا هر کمک دیگری در دسترس نبود. فقط من، یک کتاب مرجع را داشتم، تا تگی که فراموش کرده بودم ببندم را پیدا کنم. تجربه کند، ناامیدکننده و دردناک بود.

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

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

صحبت درباره تاثیرگذاری روی بهره‌وری من که محیط‌های توسعه مدرن ایجاد کرده‌اند، سخت است.

UX و DX با یکدیگر اختلاف دارند

هیچ راه مناسبی برای ساخت همه برنامه‌‌ها وجود ندارد، اما اغلب ابزارهای توسعه دهنده با یک رویکرد مناسب ساخته می‌شوند. برای انجام این کار، اغلب ابزارها برای حل یک چیز به روشی کلی مانند: مدیریت تاریخ یا رمزنگاری ساخته می‌شوند. البته این امر مستلزم جمع آوری چندین ابزار در کنار هم برای رسیدن به اهداف مان است. از دیدگاه DX، این شگفت‌انگیز است: ما تقریبا همیشه می‌توانیم یک راه‌حل متن‌باز برای مشکلاتی پیدا کنیم که بسیار خاص پروژه‌ای که ما روی آن کار می کنیم، نیستند.

با این حال، جمع آوری ده‌ها هزار ابزار برای بهبود DX ما به UX برنامه‌هایمان آسیب می‌رساند. چند کیلوبایت تنها برای این ابزار اضافه می‌کنیم، چند کیلوبایت دیگر برای آن ابزار و قبل از اینکه خودمان بدانیم، در حال ارسال کردن کوهی از کدها هستیم. در چشم‌انداز امروز، دیدن برنامه‌های کاربردی که چندین مگابایت جاوا اسکریپت را ارسال می‌کنند، غیر معمول نیست – فقط باید زبانه شبکه، ابزارهای توسعه دهنده مرورگرتان را باز کنید و به آرامی مشاهده می‌کنید که سایت‌های مورد علاقه‌تان، مقداری از جاوا اسکریپت را به مرورگرتان می‌فرستند.

به طور مثال:

به مدت ۳۰ دقیقه، سایت forbes.com را باز گذاشتم و آن، ۳،۲۷۳ درخواست را ارسال کرد و ۱۰ مگابایت جاوا اسکریپت را بارگذاری کرد.

علاوه بر اینکه صفحه‌ها را برای دانلود آهسته‌تر می‌کنند، اسکریپت‌ها، دستگاه‌های کاربران مان را تحت فشار قرار می‌دهند. برای کسی که تلفنی کم قدرت دارد (برای مثال، یک گوشی هوشمند ارزان‌قیمت، یا یک آیفون قدیمی)، زمان دانلود تنها اولین مانع برای مشاهده این برنامه است؛ پس از دانلود، دستگاه باید تمام این جاوا اسکریپت‌ها را تجزیه کند. به عنوان مثال، ۱ مگابایت از جاوا اسکریپت حدود ۶ ثانیه طول می‌کشد تا در یک سامسونگ گلکسی نوت ۲ تجزیه شود. در یک دستگاه تلفن همراهی که اتصال ۳G دارد، اضافه کردن ۱ مگابایت از جاوا اسکریپت، به معنای اضافه کردن ده ثانیه یا بیشتر به زمان دانلود و تجزیه برنامه تان است. این یعنی تجربه کاربری بد.

• وصله کردن سوراخ ها و شکاف ها در تجربه کاربری به قیمت بستگی دارد

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

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

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

• تجربه کاربری خوب اغلب مستلزم تجربه توسعه دهنده بد است

چارچوب‌هایی برای کمک به توسعه دهندگان وجود دارند و تقریبا هیچ هزینه‌ای ندارند. تجربه کاربری خوب اغلب مستلزم تجربه توسعه دهنده بد است. ما قادر به ساخت یک برنامه کاربردی بدون نیاز به یادگیری تمام کارهای پیکربندی هستیم که به ایجاد محیط توسعه کمک می‌کند. این یک رویکرد محبوب برای توسعه نهایی است – که اغلب به آن “پیکربندی صفر” گفته می شود که نشان می‌دهد راه اندازی و اجرای آن چقدر آسان است – زیرا این امر نیاز به شروع از صفر را برطرف می‌کند. به جای صرف زمان خود برای ایجاد کد اساسی و بنیادی که بین پروژه‌ها تفاوت چندانی ندارد، می‌توانیم بلافاصله بر روی ویژگی‌ها کار کنیم.

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

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

به عنوان مثال، در اینجا:

نحوه شروع یک پروژه جاوا اسکریپت از صفر در سال ۲۰۱۸ وجود دارد:

• Node و npm را نصب کنید،
• برای نصب Yarn، از npm استفاده کنید،
• از Yarn برای نصب React، Redux، Babel (پلاگین های ۱ تا ۵ Babel و پریست ها)، Jest، ESLint، webpack و PostCSS (پلاگین های اضافی) استفاده کنید،
• فایل های پیکربندی را برای Babel، Jest، ESLint، webpack و PostCSS بنویسید،
• چندین سطر کد بویلرپلیت را برای راه اندازی Redux بنویسید،
• و در نهایت شروع به انجام کارهایی می‌کنند که در واقع مربوط به الزامات پروژه هستند.

این می‌تواند به کل روزهای صرف شده برای تنظیم کد بویلرپوینت که بین پروژه‌ها تقریبا یکسان‌ است، اضافه کند. شروع با گزینه پیکربندی صفر، باعث راه اندازی سریع‌تر می‌شود، اما اگر نیاز به انجام کاری داشته باشیم که یک مورد استفاده استاندارد نباشد، ما را به یک پایان عمیق می‌رساند.

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

• یک نفر همیشه هزینه این کار را می‌پردازد

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

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

تحت فشار زمانی، این وضعیت بدتر می‌شود. سازندگان به وسیله ارسال کدی که با این پیام // FIXME oh god I’m so sorry همراه است، زمان را کمتر می کنند. آن‌ها مسایل UX را اولویت‌بندی می‌کنند – به عنوان مثال، اطمینان دادن به کاربران صفحه نمایش که می توانند “برای بازدید مجدد”، چیزها را بخوانند. آن‌ها به نام رسیدن به ضرب العجل ها و بودجه‌ها تصمیم‌گیری می‌کنند که در نهایت مصرف کنندگان مان را مجبور می‌کنند تا هزینه DXمان را پرداخت کنند.

توسعه دهندگان بهترین کار را می‌توانند با زمان و ابزار در دسترس انجام دهند، اما بیشتر به دلیل فقدان زمان و منابع تا سهل‌انگاری، زمانی که یک معامله تجاری بین UX و DX انجام می‌شود، اغلب هزینه ها به سمت کاربران سرازیر می‌شود.