صعود أدوات التطوير الخادمة وأمور أخرى

لا تتكامل تجربة المطور (DX) وتجربة المستخدم (UX) دائمًا. ففي أغلب الأحيان، قد تؤدي أداة توفر تجربة جيدة للمطور إلى تجربة سيئة للمستخدم النهائي، والعكس صحيح.

أظهرت دراسة حديثة أن أداء المواقع المعتمدة على React أسوأ، في المتوسط، من المواقع المعتمدة على jQuery والمُعالجة على الخادم. فهل يعني ذلك أن React أداة سيئة؟ إطلاقًا. لكن أُطر العمل لها تكلفة يتحملها المستخدم النهائي.

لا يهتم المستخدم بـ JSX أو مكوّنات الويب أو CSS-in-JS وسائر النقاشات العبثية في مجتمع المطورين. لكنه يتأثر دلاليًا بـ HTML إذا كان يعتمد على قارئ شاشة. كما يهتم بحجم الصفحة الإجمالي عند الاتصال بشبكة 2G أو 3G بطيئة، أو عندما لا يملك باقة بيانات بأسعار معقولة.

في البرمجيات، يحل التجريد الجيد المشكلات بفاعلية مع إخفاء التفاصيل الأساسية. عندما نستخدم أداة لحل مشكلة معقدة، نفترض أنها تعمل كتجريد جيد. لذلك، ينبغي أن تكون الأدوات وأطر العمل شبكة أمان تتولى معالجة المشكلات الشائعة، مثل الأداء وإمكانية الوصول. لكن كثيرًا من هذه الأدوات لا تلبي سوى احتياجاتنا الأنانية (تجربة المطور)، وتتجاهل إلى حد كبير احتياجات المستخدمين (تجربة المستخدم).

لذلك، يحتاج المطورون اليوم إلى إتقان أداء الويب، وتحسين الصور، وإمكانية الوصول، والأمان، إذا أرادوا إنشاء تجربة ملائمة لمستخدميهم. ويُضاف ذلك إلى قائمة المهارات المتزايدة التي عليهم اكتسابها قبل إطلاق أول «مشروع حقيقي» لهم. وينتهي بهم الأمر إلى محاربة أطر العمل التي يُفترض أن تكون في خدمتهم.

لحسن الحظ، بدأ بعض مطوري أطر العمل بالفعل باتخاذ خطوات في هذا الاتجاه. فهم يبحثون عن طرق لدعم تقسيم الشيفرة البرمجية مباشرةً، ويدمجون أدوات فحص الشيفرة البرمجية للأمور الحساسة مثل إمكانية الوصول والأمان، وغير ذلك. لكن الطريق لا يزال طويلًا، وينبغي أن يصبح هذا توجهًا سائدًا في القطاع.

لذا طرحنا على أنفسنا السؤال التالي:

• من هم مستخدمونا؟
• هل هم المطورون والمصممون ومنشئو المحتوى الذين يستخدمون الأداة يوميًا؟
• أم أنهم مستهلكو المحتوى الذي تنشئه المنصة؟

توصلنا في النهاية إلى أننا نقدم تجربة مباشرة لعملائنا وتجربة غير مباشرة لمستخدميهم، أي المستهلكين. ونؤمن إيمانًا راسخًا بأن اتخاذ خطوات لتحسين تجربة المستهلكين هو وسيلة لخدمة عملائنا على نحو أفضل. ولن نلقي على عاتقهم كامل مسؤولية إنشاء تطبيقات ويب يسهل الوصول إليها وآمنة وسريعة.

إليك بعض الخطوات التي تساعد على تضمين شبكة الأمان هذه في منتجنا:

1. دمج أفضل الممارسات في المنتج
2. منع الأفعال الضارة
3. نشر الوعي والتثقيف

دمج أفضل الممارسات في المنتج#

هناك حالات تكون فيها الخيارات الحاسمة مناسبة من منظور تجربة المستخدم. وبمرور الوقت، وضع المجتمع أفضل الممارسات هذه لإنشاء تطبيقات الويب. لا ينبغي أن نضطر إلى التفكير فيها في كل مشروع جديد.

لنأخذ تحسين الصور مثالًا. تمثل الصور 75٪ من حجم صفحات الويب

وفقًا لـ httparchive.org. لكن ليس لدى الجميع المهارات أو الأدوات اللازمة لإنشاء الصور الأكثر تحسينًا لمستخدميهم. ويمكن أن يصبح تحسين الصور معقدًا بسرعة كبيرة، بسبب اختلاف التنسيقات وكثافات البكسل والأحجام المتجاوبة.

أضفنا مؤخرًا خدمةً تغيّر حجم الصور التي تحمّلها بما يتناسب مع الحاويات التي تُستخدم فيها. وتتم هذه العملية في الخلفية، إذ نفترض أنك تريد الحصول على النسخة الأكثر تحسينًا من الصورة للمنتج النهائي. وخلال الأشهر المقبلة، سنعمل على حل لإنشاء صور متجاوبة، وعلى توفير تنسيقات webp للمتصفحات التي تدعمها.

يُغيَّر حجم الصورة بما يتناسب مع الحاوية التي تُستخدم فيها

في هذا المستوى، تعمل المنصة نيابةً عنك وتنجز «السحر» في الخلفية، دون الحاجة إلى أي تدخل منك.

منع الإجراءات الضارة#

لا ينبغي أن تضطر إلى إجراء تدقيقات على بيئة الإنتاج لتكتشف أن صورتك تفتقر إلى نص بديل، أو أنك أدرجت علامات ارتساء داخل بعضها عن طريق الخطأ. يمكن الإشارة إلى كل هذه الأمور «أثناء عملية البناء».

يمكننا ضمان استحالة حدوث حالات غير صالحة أو غير صحيحة، لأن لدينا معلومات دلالية كاملة في الوقت الفعلي. فعلى سبيل المثال، يمكننا منع تداخل علامات الارتساء أو استخدام تسلسل هرمي غير صحيح للعناوين أثناء تصميمك لصفحتك.

تنويه: لم تُنفَّذ هذه الميزة بعد، وهي حاليًا في مرحلة مقترح التصميم

في هذا السيناريو، تمنع المعرفة المتاحة في المنصة الإجراءات التي قد تضر بتجربة المستخدم.

رفع مستوى الوعي والتثقيف#

وأخيرًا، هناك توصيات بشأن سهولة الاستخدام قد تحتاج إلى معرفتها. القرار لك في العمل بها، لكن ينبغي أن يكون قرارًا مستنيرًا.

يُعد تباين الألوان مثالًا رائعًا. عليك أن تقرر ما إذا كانت مستويات التباين تفي بمعايير AA أو AAA الموصى بها في إرشادات WCAG، بناءً على جمهورك المستهدف. يمكننا إبراز المواضع التي تعاني من مشكلات، وتقديم رؤى، وإرشادك إلى مواد تعليمية حول الموضوع.

حجم الخط مثال آخر. يمكن الالتزام بالحد الأدنى الموصى به، وهو 16px، أو عدم الالتزام به، بحسب الغرض من التطبيق الذي تنشئه. لكن المنصة ستوضح تبعات اختياراتك، لتتمكن من اتخاذ قرار مستنير.

الأداة تعرض رسالة توضيحية حول حجم الخط القياسي.

ما زلنا في بداية طريقنا نحو تحقيق ذلك، لكننا واثقون من أن هذا هو الاتجاه الصحيح لمنتجنا. نؤمن بأن Playground ينبغي أن تكون أداة تطوير خادمة، وهذا ينعكس مباشرةً عليك بصفتك عميلًا، ويحقق فوائد غير مباشرة لمستخدميك. ففي نهاية المطاف، مستخدموك هم مستخدمونا أيضًا.