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

سنركِّز في هذه السلسلة تعلم تطوير الويب من المقالات على اختبار مشاريع الويب للتوافق مع المتصفحات Cross Browser Testing، حيث سنحدِّد الجمهور المستهدَف مثل معرفة المستخدِمين والمتصفحات والأجهزة التي يجب أخذها في الحسبان، وسنتعلّم كيفية إجراء الاختبار والمشاكل الرئيسية التي ستواجهها مع أنواع مختلفة من الشيفرات البرمجية وكيفية التخفيف من هذه المشاكل، كما سنتعرّف على الأدوات المفيدة لمساعدتك على اختبار المشاكل وإصلاحها وكيفية استخدام الاختبارات الآلية لتسريع عملية الاختبار. المتطلبات الأساسية: يجب أن تتعلم أساسيات لغات HTML وCSS وجافاسكربت JavaScript أولًا قبل محاولة استخدام الأدوات التي سنشرحها لاحقًا. تتألف هذه السلسلة من المقالات التالية: مدخل إلى اختبار مشاريع الويب للتوافق مع المتصفحات (المقال الحالي): سنقدم في هذا المقال نظرةً عامةً حول موضوع اختبار مشاريع الويب للتوافق مع المتصفحات، وسنجيب على أسئلة مثل "ما هو اختبار التوافق مع المتصفحات؟" و"ما هي أكثر أنواع المشاكل شيوعًا التي ستواجهها؟" و"ما هي الطرق الرئيسية لاختبار المشاكل وتحديدها وإصلاحها؟". استراتيجيات اختبارات مشاريع الويب للتوافق مع المتصفحات: سننتقل بعد ذلك إلى إجراء الاختبارات، وتحديد الجمهور المستهدَف مثل المتصفحات والأجهزة والمجالات الأخرى التي يجب التأكد من اختبارها، وتحديد استراتيجيات اختبار Lo-fi مثل الحصول على مجموعة من الأجهزة وبعض الآلات الافتراضية وإجراء اختبارات مخصصة Ad-hoc عند الحاجة، واستراتيجيات التقنيات المتقدمة مثل الاختبارات الآلية واستخدام تطبيقات الاختبار المخصَّصة، وإجراء الاختبارات مع مجموعات المستخدِمين. معالجة المشاكل الشائعة للتوافق مع المتصفحات في شيفرة HTML وCSS: سننظر بعد ذلك على وجه التحديد في المشاكل الشائعة للتوافق مع المتصفحات التي ستواجهها في شيفرة HTML وCSS، بالإضافة إلى الأدوات التي يمكن استخدامها لمنع حدوث هذه المشاكل أو إصلاحها،كما يتضمن ذلك فحص أخطاء الشيفرة Linting Code والتعامل مع بادئات CSS واستخدام أدوات تطوير المتصفح لتتبّع المشاكل واستخدام تعويض دعم المتصفحات Polyfill لإضافة الدعم إليها ومعالجة مشاكل التصميم المتجاوب مع الشاشات وغير ذلك الكثير. معالجة المشاكل الشائعة للتوافق مع المتصفحات في شيفرة جافاسكربت: سننظر بعد ذلك في مشاكل جافاسكربت الشائعة للتوافق مع المتصفحات وكيفية إصلاحها، ويتضمن ذلك معلومات حول استخدام أدوات تطوير المتصفح لتتبّع المشاكل وإصلاحها واستخدام تعويض دعم المتصفحات Polyfill والمكتبات لحل المشاكل والحصول على ميزات جافاسكربت الحديثة التي تعمل في المتصفحات القديمة وغير ذلك الكثير. معالجة مشاكل سهولة الوصول Accessibility الشائعة للتوافق مع المتصفحات: سننتقل بعد ذلك إلى سهولة الوصول Accessibility وتوفير معلومات حول مشاكلها الشائعة، وكيفية إجراء اختبار بسيط والاستفادة من أدوات التدقيق والاختبارات الآلية للعثور على مشاكل سهولة الوصول. كيفية اكتشاف دعم المتصفحات للميزات أثناء اختبار مشاريع الويب: يتضمن اكتشاف الميزات معرفة ما إذا كان المتصفح يدعم كتلةً معينةً من الشيفرة البرمجية، ويعتمد تشغيل شيفرة برمجية على كونها مدعومة أم لا، بحيث يمكن للمتصفح دائمًا توفير تجربة عمل ناجحة بدلًا من التعطل أو ظهور الأخطاء في بعض المتصفحات، إذ يوضح هذا المقال بالتفصيل كيفية كتابة اكتشاف المتصفحات للميزات البسيطة وكيفية استخدام مكتبة لتسريع التطبيق واستخدام الميزات الأصيلة Native لاكتشاف الميزات مثل الميزة ‎@supports. مدخل إلى اختبارات مشاريع الويب الآلية للتوافق مع المتصفحات: يمكن أن يصبح إجراء الاختبارات يدويًا على العديد من المتصفحات والأجهزة عدة مرات في اليوم أمرًا مملًا ويستغرق وقتًا طويلًا، لذا يمكن معالجة ذلك بكفاءة من خلال استخدام الأدوات الآلية، إذ سنلقي نظرةً في هذا المقال على الأدوات المتاحة وكيفية استخدام مشغّلي المهام وأساسيات كيفية استخدام تطبيقات الاختبارات الآلية للمتصفحات التجارية مثل Sauce Labs و Browser Stack. إعداد بيئتك للاختبارات الآلية في مشاريع الويب للتوافق مع المتصفحات: سنعلِّمك في هذا المقال كيفية تثبيت بيئة الاختبار الآلية وإجراء اختباراتك الخاصة باستخدام بيئة Selenium/WebDriver ومكتبة الاختبارات مثل المكتبة selenium-webdriver الخاصة ببيئة Node، كما سنتعرّف على كيفية دمج بيئة اختبارك المحلية مع التطبيقات التجارية. لنبدأ بمقالنا الأول ولنتعرف على مفهوم اختبار مشاريع الويب للتوافق مع المتصفحات Cross Browser Testing. ما هو اختبار التوافق مع المتصفحات؟ يُستخدَم اختبار التوافق مع المتصفحات للتأكد من أنّ مواقع وتطبيقات الويب التي تنشئها تعمل بنجاح على عدد مقبول من متصفحات الويب، إذ تقع على عاتقك -بصفتك مطور ويب- مسؤولية التأكد من أنّ مشاريعك لا تعمل فقط، ولكنها تعمل مع جميع المستخدِمين بغض النظر عن المتصفح أو الجهاز أو الأدوات المساعدة الإضافية التي يستخدمونها، إذ عليك التفكير فيما يلي: متصفحات مختلفة غير المتصفح أو المتصفحَين اللذين تستخدِمهما بانتظام على أجهزتك بما في ذلك المتصفحات الأقدم قليلًا التي يُحتمَل أنه لا يزال بعض الأشخاص يستخدِمونها والتي لا تدعم أحدث ميزات CSS وجافاسكربت. أجهزة مختلفة ذات قدرات مختلفة من أحدث الحواسيب إلى الأجهزة اللوحية والهواتف الذكية وأجهزة التلفاز الذكية وصولًا إلى الأجهزة اللوحية الرخيصة وحتى الهواتف ذات الميزات القديمة التي يمكن أن تشغّل متصفحات ذات إمكانات محدودة. الأشخاص ذوو الاحتياجات الخاصة الذين يستخدِمون الويب بمساعدة التقنيات المساعدة مثل قارئات الشاشة أو الأشخاص الذين لا يستخدِمون الفأرة، إذ يستخدِم بعض الأشخاص لوحة المفاتيح فقط. تذكَّر دائمًا أنك لست أحد المستخدِمين، إذ لا يعني عمل موقعك بنجاح على جهاز MacBook Pro أو جهاز Galaxy Nexus المتطور أنه سيعمل مع جميع المستخدِمين، فهناك الكثير من الاختبارات التي يجب إجراؤها. إذا تحدّثنا عن المواقع الإلكترونية التي تعمل على متصفحات مختلفة، فهذا يعني أنه يجب أن توفر تجربة مستخدِم مقبولة على متصفحات مختلفة، وقد يُحتمَل ألّا يقدم الموقع التجربة نفسها بالضبط على جميع المتصفحات طالما أن الوظيفة الأساسية يمكن الوصول إليها بطريقة ما، إذ يمكن أن تحصل في المتصفحات الحديثة على شيء متحرك وثلاثي الأبعاد وحديث، في حين يمكن أن تحصل في المتصفحات القديمة على رسم مسطح يمثل المعلومات نفسها، وطالما أنّ صاحب الموقع سعيد بذلك، فهذا يعني أنك نجحت في عملك. من ناحية أخرى، ليس مقبولًا أن يعمل الموقع بنجاح مع المستخدِمين المبصرين مع تعذر الوصول إليه بالنسبة للمستخدِمين ضعاف البصر لأن تطبيق قارئ الشاشة لا يمكنه قراءة أيٍّ من المعلومات المخزنة عليه. لا نعني بعبارة "عبر عدد مقبول من متصفحات الويب" نسبةَ 100% من المتصفحات في العالم، فهذا مستحيل تقريبًا، إذ يمكنك إجراء بحث بشأن المتصفحات والأجهزة التي سيستخدِمها مستخدمو موقعك كما سنناقش في المقال التالي من هذه السلسلة، ولكن لا يمكنك ضمان كل شيء، وتحتاج -بصفتك مطور ويب- الموافقة على مجموعة من المتصفحات والأجهزة التي تحتاجها الشيفرة البرمجية للعمل عليها مع مالك الموقع، ولكنك ستحتاج بعد ذلك لاستخدام البرمجة الدفاعية Defensive Coding لمنح المتصفحات الأخرى أفضل فرصة ممكنة لتكون قادرةً على استخدام محتواك، ويُعَدّ ذلك أحد أكبر التحديات التي تواجه تطوير الويب. سبب حدوث مشاكل التوافق مع المتصفحات هناك العديد من الأسباب المختلفة لحدوث مشاكل التوافق مع المتصفحات، ولاحظ أننا هنا نتحدث عن المشاكل التي تتصرف فيها الأشياء بطريقة مختلفة على مختلف المتصفحات أو الأجهزة أو تفضيلات التصفح، ولكن يجب عليك إصلاح الأخطاء الموجودة في شيفرتك البرمجية قبل أن تحل مشاكل التوافق مع المتصفحات. تحدث مشاكل التوافق مع المتصفحات للأسباب التالية: تحتوي المتصفحات في بعض الأحيان على أخطاء أو يمكن أن تطبّق ميزات بطريقة مختلفة، ولكن يُعَدّ هذا الوضع أقل سوءًا بكثير مما كان عليه في السابق، إذ عمدت شركات المتصفحات إلى تطبيق الأشياء بطريقة مختلفة عن بعضها البعض في محاولة لاكتساب ميزة تنافسية عندما تنافسَ كل من IE4 و Netscape 4 على موقع المتصفح المهمين في التسعينات، مما صعّب الأمور كثيرًا على المطورين، وقد أصبحت المتصفحات أفضل بكثير في اتباع المعايير حاليًا، ولكن لا يخلو الأمر من بعض الاختلافات والأخطاء. يمكن أن تحتوي بعض المتصفحات على مستويات مختلفة من الدعم للميزات التقنية عن غيرها من المتصفحات، وهذا أمر لا مفر منه عندما تتعامل مع ميزات متطورة بدأت المتصفحات في تطبيقها، أو إذا كان عليك دعم المتصفحات القديمة التي لم تَعُدّ قيد التطوير وجُمِّدت، أي لم يُطبَّق عليها أيّ عمل جديد قبل وقت طويل من اختراع ميزة جديدة، فإذا أردت مثلًا استخدام أحدث ميزات جافاسكربت في موقعك، فيمكن ألّا تعمل في المتصفحات القديمة، وإذا كنت بحاجة إلى دعم المتصفحات القديمة، فيمكن أن تضطر إلى عدم استخدام هذه الميزات أو تحويل شيفرتك البرمجية إلى صيغة قديمة الطراز باستخدام نوع من المُصرِّفات Compilers عند الحاجة. يمكن أن تحتوي بعض الأجهزة على قيود تؤدي إلى بطء تشغيل موقع الويب أو عرضه بطريقة سيئة، فإذا صُمِّم موقع ما ليبدو جميلًا على حاسوب مكتبي مثلًا، فيُحتمَل أن يبدو صغيرًا ويصعب قراءته على هاتف محمول، وإذا احتوى موقعك على عدد كبير من الرسوم المتحركة الكبيرة، فيمكن أن يكون الأمر جيدًا على جهاز لوحي عالي المواصفات، ولكنه سيكون بطيئًا على جهاز منخفض المواصفات. هناك المزيد من الأسباب الأخرى، وسنتعرّف في المقالات اللاحقة على مشاكل التوافق مع المتصفحات للوصول إلى حلول لها. سير عمل اختبار التوافق مع المتصفحات يمكن أن يبدو هذا الاختبار مستهلِكًا للوقت ومخيفًا، ولكن لا داعي لأن يكون كذلك، فكل ما عليك فعله هو التخطيط له بعناية والتأكد من إجراء اختبارات كافية في الأماكن الصحيحة للتأكد من عدم ظهور مشاكل غير متوقعة، فإذا أردت العمل في مشروع كبير، فيجب اختباره بانتظام للتأكد من أنّ الميزات الجديدة تعمل بنجاح مع جمهورك المستهدَف وأن الإضافات الجديدة إلى الشيفرة البرمجية لا تعطِّل الميزات القديمة التي كانت عاملةً في السابق، فإذا تركت جميع الاختبارات إلى نهاية المشروع، فستكون أيّ أخطاء أو زلات برمجية تكتشفها أكثر تكلفةً وستستغرق وقتًا طويلًا لإصلاحها مما لو اكتشفتها وأصلحتها أثناء العمل على المشروع. يمكن تقسيم سير عمل الاختبار وإصلاح الزلات البرمجية في المشروع إلى المراحل الأربع التالية تقريبًا، وهذا تقسيم تقريبي فقط، إذ يمكن أن يعمل أشخاص آخرون بطريقة مختلفة: التخطيط الأولي Initial Planning. التطوير Development. الاختبار Testing/الاكتشاف Discovery الإصلاحات Fixes/التكرار Iteration تُكرَّر الخطوات 2 و3 و4 عدة مرات حسب الضرورة لإنجاز التنفيذ بالكامل، كما سنتعرّف على الأجزاء المختلفة من عملية الاختبار بمزيد من التفصيل في المقالات اللاحقة، ولكن لنلخّص فقط ما يحدث في كل خطوة حاليًا. التخطيط الأولي يُحتمَل أن يكون لديك في مرحلة التخطيط الأولي العديد من اجتماعات التخطيط مع مالك الموقع أو العميل الذي يمكن أن يكون رئيسك في العمل أو شخصًا من شركة خارجية تبني موقع ويب لها، حيث تحدد بالضبط ما يجب أن يكون عليه موقع الويب، وما هو المحتوى والوظائف التي يجب أن يحتوي عليها وكيف يجب أن يبدو وما إلى ذلك، كما سترغب في هذه المرحلة في معرفة مقدار الوقت المتاح لك لتطوير الموقع أي الموعد النهائي Deadline، وكم سيدفعون لك مقابل عملك، ولن نخوض في الكثير من التفاصيل حول هذا الأمر، ولكن يمكن أن يكون لمشاكل التوافق مع المتصفحات تأثير خطير على هذا التخطيط. يجب أن تبدأ في استكشاف الجمهور المستهدَف بمجرد حصولك على فكرة عن مجموعة الميزات المطلوبة والتقنيات التي ستبني هذه الميزات بها، مثل استكشاف المتصفحات والأجهزة وغير ذلك والتي سيستخدِمها الجمهور المستهدَف لهذا الموقع، فيمكن أن يكون لدى العميل بيانات حول هذه الأمور من بحث سابق أجراه من مواقع الويب الأخرى التي يمتلكها أو من الإصدارات السابقة من موقع الويب الذي تعمل عليه الآن مثلًا، فإذا لم يكن الأمر كذلك، فستتمكن من الحصول على فكرة جيدة من خلال النظر إلى مصادر أخرى مثل إحصائيات الاستخدام للمنافسين أو البلدان التي سيخدّمها الموقع، كما يمكنك استخدام بعض التخمين. يمكن أن تنشئ مثلًا موقعًا للتجارة الإلكترونية يخدّم العملاء في أمريكا الشمالية، ويجب أن يعمل الموقع بالكامل في الإصدارات الأخيرة من متصفحات الحواسيب المكتبية والهاتف المحمول (iOS و Android و Windows phone) الأكثر شيوعًا، إذ يجب أن يشمل ذلك كروم Chrome وأوبرا Opera الذي يعتمد على محرّك التصيير Rendering نفسه الخاص بكروم، بالإضافة إلى فايرفوكس Firefox و IE/Edge وسفاري Safari، كما يجب أن توفر تجربة مقبولة في الإصدارين IE 8 و9 ويمكن الوصول إليها باتباع تعليمات WCAG AA. أصبحتَ الآن تعرف منصات الاختبار المستهدفة، لذا يجب العودة ومراجعة مجموعة الميزات المطلوبة والتقنيات التي ستستخدِمها. إذا أراد مالك موقع التجارة الإلكترونية مثلًا جولةً ثلاثية الأبعاد مدعومة من WebGL لكل منتج مُضمَّن في صفحات المنتجات، فيجب قبول أنّ ذلك لن يعمل في إصدارات المتصفح IE قبل الإصدار 11، كما يجب أن توافق على توفير نسخة من الموقع بدون هذه الميزة لمستخدِمي إصدارات IE الأقدم، كما يجب عليك تجميع قائمة بمواقع المشاكل المحتمَلة. ملاحظة: يمكنك الرجوع إلى موقع caniuse.com للحصول على مزيد من تفاصيل معلومات دعم المتصفحات للتقنيات. يمكنك المضي قدمًا والبدء في تطوير الموقع بمجرد الاتفاق على هذه التفاصيل. التطوير لننتقل الآن إلى تطوير الموقع، إذ يجب عليك تقسيم الأجزاء المختلفة من عملية التطوير إلى وحدات، حيث يمكنك تقسيم مناطق الموقع المختلفة إلى الصفحة الرئيسية وصفحة المنتجات وعربة التسوق وسير عملية الدفع مثلًا، ثم يمكنك تقسيم هذه الأجزاء إلى تطبيق جزأي الترويسة والتذييل المشتركَين في الموقع، وتطبيق عرض تفاصيل صفحة المنتجات، وعنصر عربة التسوق الدائم وغير ذلك. هناك العديد من الاستراتيجيات العامة لتطوير التوافق مع المتصفحات مثل: الحصول على جميع الوظائف التي تعمل بنجاح قدر الإمكان في جميع المتصفحات المستهدفة، ويمكن أن يتضمن ذلك كتابة مسارات شيفرات برمجية مختلفة تعيد إنتاج الوظائف بطرق مختلفة تستهدف متصفحات مختلفة، أو استخدام تعويض دعم المتصفحات Polyfill لتقليد أيّ دعم مفقود باستخدام جافاسكربت أو تقنيات أخرى، أو استخدام مكتبة تسمح لك بكتابة جزء من الشيفرة البرمجية ثم تطبيق أشياء مختلفة في الخلفية اعتمادًا على ما يدعمه المتصفح. القبول بأن بعض الأشياء لن تعمل بالطريقة نفسها على جميع المتصفحات، وتقديم حلول مختلفة مقبولة في المتصفحات التي لا تدعم الوظائف الكاملة، ويكون ذلك في بعض الأحيان أمرًا لا مفر منه بسبب قيود الجهاز، إذ لن تقدِّم شاشة السينما العريضة التجربة المرئية نفسها لشاشة الجوال التي مقاسها 4 بوصات بغض النظر عن كيفية برمجة موقعك. القبول بأن موقعك لن يعمل في بعض المتصفحات القديمة، ثم المضي قدمًا في عملية التطوير، ويُعَدّ ذلك جيدًا بشرط عدم وجود مشكلة لدى عميلك أو قاعدة المستخدِمين في ذلك. تتضمن عملية التطوير مزيجًا من الأساليب الثلاثة السابقة، ولكن أهم شيء هو أن تختبر كل جزء صغير قبل تنفيذه وألّا تترك جميع الاختبارات حتى النهاية. الاختبار/الاكتشاف يجب اختبار الوظيفة الجديدة بعد كل مرحلة تطبيق، إذ يجب عليك أولًا التأكد من عدم وجود مشاكل عامة في شيفرتك البرمجية تعطل عمل الميزة كما يلي: اختبرها في بعض المتصفحات المستقرة على نظامك مثل Firefox أو Safari أو Chrome أو IE/Edge. أجرِ اختبارات سهولة الوصول Lo-fi مثل محاولة استخدام موقعك باستخدام لوحة المفاتيح فقط أو استخدام موقعك عبر قارئ الشاشة لمعرفة ما إذا كان قابلًا للتنقل عبره أم لا. أجرِ اختبارات على منصة للهاتف المحمول مثل Android أو iOS. أصلِح أيّ مشاكل تجدها في شيفرتك البرمجية الجديدة في هذه المرحلة، ثم يجب أن تحاول توسيع قائمة المتصفحات التي تريد اختبارها إلى قائمة كاملة من متصفحات الجمهور المستهدف والبدء في التركيز على التخلص من مشاكل التوافق مع المتصفحات، فمثلًا: حاول اختبار أحدث تغيير على جميع متصفحات الحواسيب المكتبية الحديثة بما في ذلك Firefox و Chrome و Opera و IE و Edge وSafari على أنظمة التشغيل Mac و Windows و Linux. اختبرها في متصفحات الهاتف المحمول والأجهزة اللوحية الشائعة مثل iOS Safari على أجهزة iPhone/iPad و Chrome و Firefox على أجهزة iPhone/iPad/Android. أجرِ اختبارات أيضًا على أيّ متصفحات أخرى ضمّنتها في قائمة أهدافك. خيار اختبار Lo-fi الأكثر استخدامًا هو إجراء جميع الاختبارات التي يمكنك تطبيقها بنفسك مثل أن يجرّب زملاؤك في الفريق الموقع إذا كنت تعمل في فريق، إذ يجب أن تحاول اختباره على أجهزة حقيقية إذا أمكن ذلك، فإذا لم تكن لديك الوسائل اللازمة لاختبار جميع مجموعات المتصفحات وأنظمة التشغيل والأجهزة المختلفة على العتاد الفيزيائي، فيمكنك الاستفادة من المقلّدات أو المحاكيات Emulators -التي تقلد جهازًا باستخدام برنامج على حاسوبك المكتبي- والآلات الافتراضية التي هي برامج تسمح بمحاكاة مجموعات متعددة من أنظمة التشغيل والبرامج على حاسوبك. يُعَدّ ذلك خيارًا شائعًا جدًا خاصةً في ظروف معينة مثل ألّا يتيح نظام ويندوز تثبيت إصدارات متعددة منه في الوقت ذاته وعلى الجهاز نفسه، لذا يكون استخدام آلات افتراضية متعددة هو الخيار الوحيد في هذه الحالة. يوجد خيار آخر هو استخدام مجموعات المستخدِمين، أي استخدام مجموعة من الأشخاص من خارج فريقك لاختبار موقعك مثل مجموعة من الأصدقاء أو العائلة أو مجموعة من الموظفين الآخرين أو صف دراسي في جامعة محلية أو إعداد اختبار احترافي بحيث يُدفَع للأشخاص لاختبار موقعك وتقديم النتائج. أخيرًا، يمكنك استخدام الاختبار باستخدام أدوات التدقيق أو الاختبارات الآلية، حيث يُعَدّ هذا الاختيار معقولًا مع المشاريع الكبيرة، إذ يمكن أن يستغرق إجراء هذا الاختبار يدويًا وقتًا طويلًا جدًا، كما يمكنك إعداد نظام اختبار آلي مثل تطبيق Selenium الشهير الذي يمكنه تحميل موقعك في عدد من المتصفحات المختلفة مثلًا، ويمكنه: معرفة ما إذا كان النقر على الزر يؤدي إلى حدوث شيء ما بنجاح مثل عرض خريطة، وعرض النتائج بمجرد اكتمال الاختبارات. التقاط لقطة شاشة لكل من هذه الاختبارات، مما يسمح لك بمعرفة ما إذا كان تخطيط الموقع متناقسًا على المتصفحات المختلفة. هناك أدوات تجارية متاحة مثل Browserling و Sauce Labs و Browser Stack و Endtest و LambdaTest و TestingBot و CrossBrowserTesting التي تطبّق هذه الاختبارات دون الحاجة إلى القلق بشأن الإعداد إذا أردت استثمار بعض المال في الاختبارات، كما يمكنك إعداد بيئة تشغّل الاختبارات تلقائيًا نيابةً عنك ثم تتيح لك فقط التحقق من التغييرات التي أجريتها على مستودع الشيفرة المركزي إذا نجحت الاختبارات باستمرار. الاختبار على المتصفحات التجريبية يكون اختبار الإصدارات التجريبية من المتصفحات فكرة جيدة في أغلب الأحيان، لذا اطّلع على الروابط التالية: Firefox Developer Edition. Edge Insider Preview. Safari Technology Preview. Chrome Canary. Opera Developer. ينتشر هذا النوع من الاختبارات خاصةً إذا استخدمتَ تقنيات حديثة جدًا في موقعك ورغبت في اختبار أحدث التطبيقات؛ أو إذا صادفت زلةً برمجيةً في أحدث إصدار من المتصفح وأردت معرفة إذا أصلح مطورو المتصفح هذه الزلة البرمجية في إصدار أحدث. الإصلاحات/التكرار يجب محاولة إصلاح الزلة البرمجية بمجرد اكتشافها، فأول شيء يجب فعله هو تضييق نطاق مكان حدوث الزلة البرمجية قدر الإمكان، لذا احصل على أكبر قدر ممكن من المعلومات من الشخص الذي يبلّغ عن الزلة البرمجية مثل معرفة ما هي المنصة أو المنصات، والجهاز أو الأجهزة، وإصدار أو إصدارات المتصفح التي يستخدمها، وجرب هذا الاختبار على إعدادات مماثلة مثل إصدار المتصفح نفسه على منصات حواسيب مختلفة أو عدة إصدارات مختلفة من المتصفح نفسه على المنصة نفسها لمعرفة مدى انتشار الزلة البرمجبة. يمكن ألّا يكون هذا خطأك، لذا نأمل إصلاح الزلة البرمجية بسرعة في حالة وجودها في المتصفح، كما يمكن أن تكون الزلة البرمجية قد أُصلِحت مسبقًا مثل وجود خطأ في الإصدار 49 من Firefox، ولكنها لم تَعُد موجودةً في Firefox Nightly (الإصدار 52)، فعندئذٍ تكون قد أُصلِحت فعليًا، فإذا لم تكون قد أُصلِحت مسبقًا، فيمكنك إرسال تقرير بالزلة البرمجية. إذا كان ذلك خطأك، فيجب عليك إصلاحه، إذ يتضمن اكتشاف سبب الزلة البرمجية الإستراتيجية نفسها لأي زلة برمجية في عملية تطوير الويب، فإذا اكتشفتَ سبب الزلة البرمجية، فيجب أن تقرر كيفية التعامل معها في المتصفح التي تتسبب في حدوث مشاكل، ولا يمكنك تعديل شيفرة المشكلة البرمجية فقط، إذ يمكن أن يؤدي ذلك إلى تعطّل الشيفرة في المتصفحات الأخرى، والأسلوب العام في هذه الحالة هو تفرّع الشيفرة البرمجية بطريقةٍ ما مثل استخدام شيفرة اكتشاف المتصفحات لميزة جافاسكربت لاكتشاف المواقف التي لا تعمل فيها الميزة التي تؤدي إلى المشكلة، وتشغيل الشيفرة البرمجية الأخرى في الحالات التي تعمل فيها هذه الميزة. يجب تكرار عملية الاختبار بعد إصلاح المشكلة للتأكد من أنّ الإصلاح يعمل بنجاح ولا يتسبب في تعطل الموقع في أماكن أخرى أو في متصفحات أخرى. إصدار تقارير بالأخطاء إذا اكتشفت أخطاءً في المتصفحات، فيجب عليك التبليغ عنها باستخدام ما يلي: Firefox Bugzilla. متعقّب مشاكل EdgeHTML. Safari. Chrome. Opera. الخلاصة يُفترَض أن يمنحك هذا المقال فهمًا عالي المستوى لأهم المفاهيم التي تحتاج معرفتها حول اختبار التوافق مع المتصفحات، وبالتالي أصبحت الآن جاهزًا للمضي قدمًا والبدء في التعرف على استراتيجيات اختبار التوافق مع المتصفحات. ترجمة -وبتصرُّف- للمقالين Cross browser testing وIntroduction to cross browser testing. اقرأ أيضًا المقال السابق: إضافة خاصية ترشيح لتطبيق Angular وتجهيزه للنشر المدخل الشامل لتعلم تطوير الويب وبرمجة المواقع فهم أدوات تطوير الويب من طرف العميل

عندما أطلقنا تطبيق المحادثة الجديد في السنة الماضية، أضفنا للعملاء إمكانية إنشاء ملفات تعريف شخصية غنية بحيث يتأكد المستخدمون أن هناك دائما شخصا حقيقيًّا في الجهة المقابلة. والمشكلة؟ لا أحد يستخدم الميزة. بعد أن أطلقناه بوقت قصير, أكمل 13-15% من العملاء فقط ملفات التعريف الخاصة بهم. ملئت أغلب الملفات جزئيا بينما تُركت العديد منها غير ممسوسة. بعد التحدث مع الزملاء في فرق البحث والتحليل لدينا، اكتشفنا سببيْن رئيسيْن لهذا الاستعمال المنخفض: الوضوح: فقد كانت القدرة على إنشاء ملفك الشخصي محشورة في أماكن تصعب رؤيتها ضمن التطبيق. التثقيف: فقد كان الناس غير مقتنعين بأهمية الملفات الشخصية في تأسيس علاقات شخصية مع عملائهم. جزء واحد من حل أشمل وُجِدَت الملفات التعريفية في أجزاء عدة من المنتج، ممّا يعني أننا اضطررنا إلى إشراك فرق عمل مختلفة لزيادة تبني الميزة. دمَج فريق التطوير إنشاء ملفات التعريف في عمليّة التسجيل، بينما أعطى المنتج وضوحا أكبر لإمكانية تحرير ملف التعريف ضمن التطبيق نفسه. بجميع الأحوال، كانت هناك فرصة كبيرة لزيادة الفعالية وذلك بالاستفادة من ميزات تطبيقات هواتفنا المحمولة. فقد قام حوالي 45% من أعضاء فريقنا ممن تحدثوا مع عملائهم باستخدام تطبيقاتنا على أندرويد أو iOS. البدء ينشئ المصممون في Intercom، بالنسبة لكل مشروع جديد، قائمة بسيطة بالأمور الأساسية المسببة للمشكلة التي يحاولون حلها. الأمر الذي يساعد بالتفكير في حلول عامّة. وحلولنا كانت كما يلي: زيادة توعيّة المستخدمين الذين لم يكملوا ملفاتهم التعريفية أو أكملوها جزئيا. تثقيف المستخدمين بأهمية ملفات التعريف العامة. تسهيل عملية تعديل ملفات التعريف للمستخدمين في الوقت الذي يريدونه. التفكير في الأنظمة أخذنا في البداية ملفات التعريف لنساعد الفريق في فهم النظام وتحديد المكونات الخاصة التي تحتاج الأولوية. مما يعني إعداد جرد بالأجزاء والحالات والقواعد وغيرها. إليك مثالا عن منشور كان معلقا على حائط مساحة العمل الخاصة بنا. الأفكار تأتي من كل مكان ساعد توثيق النظام الفريق في مناقشة العقبات التقنية في وقت مبكر، وحتى في هذه المرحلة المبكرة قدم فريق الهندسة اقتراحات لم يكن فريق التصميم قد فكر بها. على سبيل المثال، ذكر أحدهم أن باستطاعتنا استخلاص بيانات من المصادر الموجودة لملْء مكونات محددة ضمن ملف التعريف. بما أن اسم الشخص موجود لدينا عندما يسجّل دخوله عبر تطبيق الجوّال، فلم لا ننسخ هذ الاسم إلى ملف التعريف ونوفر عليه زمن إدخال تلك البيانات يدويا؟ بعد رسم بعض الاتجاهات، التقينا بEmmet مدير تصميم المنتجات لدينا، للحصول على ردود الفعل واتخاذ قرار بشأن الخطوات التالية. وفيما يلي الخيارات الأربعة التي قدّمناها. الخيار الأول الخيار الثاني الخياران الثالث والرابع إن المكونات الأساسية هنا هي المقاطعة (الإزعاج) والتثقيف . لا نريد أن يكون التثقيف قابلا للتجاوز بسهولة، كما نريد مساحة لنتمكن من تثقيف المستخدمين بأهمية ملف التعريف ومكوناته. إلا أننا نعرف أيضًا أن المزيد من المقاطعة يعني مزيدا من النفور (أي أن المستخدمين يريدون التجاوز)، لذا نريد الإبقاء على عدد الخطوات في الإرشادات التفصيلية منخفضا قدر الإمكان. قررنا في النهاية أن نستخدم خيار الإرشاد البسيط. وفيما يلي القرارات الناتجة عن الاجتماع. يا له من تقدم! تصميم الحل حتى هذه النقطة، اتخذنا قرارا بأمرين. سنضيف إرشادًا بسيطًا لتطبيقنا في البداية نسأل فيه عن أي مكونات مفقودة في ملف التعريف بغية ملئها (المقاطعة والتثقيف). كان هدفنا الثالث إضافة القدرة على “تعديل ملف التعريف من أي مكان”. قررنا العمل ضمن نمط التصفّح الموجود حاليّا في التطبيق وإضافة أيقونة تحرير بسيطة ضمن قائمة التنقل ينتُج عنها بدء الإرشاد. يظهر يسار الصورة أدناه المستكشف الحالي، في ما يوجد المستكشف المُقترَح يمينها. على مستوى النظام، أسسنا ثلاث حالات للمستخدمين ستتحكم بمدى تقدّمهم في الإرشادات. نعلم اعتمادا على التوجّه العام الي اخترناه أن المسار سيتكون من خطوات رئيسية ثلاث (انظر المخطط في الأسفل) نريد جعلها أكثر سهولة وأخف وزنا قدر الإمكان. إن عملية الإرشاد واضحة جدا من حيث تصميم النظام. فهي مسار ثابت من البداية إلى النهاية، لكن المنطق يصبح أكثر تعقيدا عند أخذ حالات المستخدمين بالحسبان. نريدك أن تنتقل مباشرة إلى الجزء الأكثر صلة بحالتك عوضا عن إرغامك على المرور بعملية الإرشاد بكاملها. من المهمّ جدا أخذ خطوات خاصة بالمنصة بعين الاعتبار كأذونات الكاميرا. فليست كل خطوة شاشة جديدة. مرة ثانية، طبعت هذه المخططات وعلقت في قاعة العمل. غالبا ما يكون المهندسون أمام الجدار يدقّقون سير العملية، وقد يجدون حالة حرجة تتطلب منا إجراء تغييرات. هكذا يبدو المخطَّط النهائي لخطوات الإرشاد. التنفيذ أصبح لدينا الأساس لنبني عليه كل جزء من الأجزاء. يحصل التصميم المرئي والتفاعلي لحظيًّا، مع معرفة أننا سنستمر بتعديل المرئيات أثناء بنائها. وجدنا بأنه يجب أن تكتمل التفاصيل المتعلقة بالتفاعلات المعقدة والرسوم المتحركة بأسرع ما يمكن (وهو السبب الذي تعدّ من أجله نماذج الوثوقية العالية عظيمة). لأنه من الصعب تغييرها لاحقا على عكس التعديلات على التصميم المرئي كتحديث الموجودات والألوان وغيرها. استخدمنا Framer JS كطريقة لوضع نماذج أولية للأفكار التفاعلية الأولى، ومناقشتها مع المهندسين والاتفاق على ما يمكن عمله.حصلنا على مخطّط نهائي لتطبيق iOS بعد حوالي 12 نموذجًا أوليًّا. من وجهة نظر التصميم المرئي، تتبع تطبيقات جوالاتنا عن كثب علامتنا التجارية. ويجب على أي تصميم جديد أن يحافظ على تلك اللغة بالإضافة إلى إعادة استخدام أية أنماط مطلوبة. عملنا مع فريق تصميم علامتنا التجارية على الرسوم التوضيحية لشاشات الافتتاح والتأكيد. كان المحتوى هاما جدا لمشكلة التثقيف. توجب علينا أن نشرح أهمية الملفات الشخصية بطريقة موجزة. عمل التصميم عن قرب مع Elizabeth McGuane محللتنا الإستراتيجية التي تُعنَى بالمحتوى، لخلق تجربة أكثر إقناعا ومساعدة المستخدمين في فهم أهمية الملف الشخصي الجيد. في ما يلي مثال على توثيق إستراتيجية المحتوى. الاختبار والتطويع كنا مدركين للتشتت الذي سيحصل خلال العملية وأن عددا من الناس على الأغلب سيتجاوزون الإرشادات، حتى بعد إضافة خيار تذكير المستخدمين بإكمال ملفاتهم الشخصية لاحقا. كان إعداد مقاييس لمدى التقدّم في إكمال الملف هو الحل، بالإضافة إلى السماح بمدة تجريبية للتعديل بناءً على النتائج. بالنسبة لنسختنا التجريبية الأولى، كان معدل الإكمال الأوّلي منخفضا جدا وبخاصة في أندرويد. قمنا بمجموعة من التعديلات على التصميم كإزالة نتوء زر “ذكرني لاحقا” وتبديل التخطيط وتعديل المحتوى ليصبح أكثر تسلية وأقل إملاءً للتعليمات. بعد حوالي أسبوع من التعديلات السريعة والمراقبة، ازداد معدل الإتمام على نحو مفاجئ. بفضل تدخل عدة فرق ارتفع معدل إكمال الملفات الشخصية الإجمالي من 14% إلى 46% خلال مدة شهر. لعبت عملية الإرشاد في الجوّال دورا هاما في هذا الارتفاع. خرجنا أيضا مع مجموعة كبيرة من النصائح الجاهزة التي يمكن أن نطبقها على مشروعنا التالي: تأكد من وضوح المشكلة لجميع المشاركين في العمل. ضع المشكلة تحت البحث والقياس، واستخدم أهدافا عامة لتوجيه حلولك. بغض النظر عما تقوم بصنعه، فكر بالكبير وابدأ بالصغير. يجب أن يعمل المصمّم إلى جانب المهندس في وقت مبكر وعلى نحو مستمر للحصول على الأفكار والتحقق من المفاهيم. يجب أن ينجز التصميم التفاعلي في أقرب وقت ممكن كونه من الأسهل التعديل على التصميم البصري أثناء إنشائه. اعرف عوامل نجاحك وتتبع نجاح حلولك وتأكد من وجود وقت للتعديل. إن اتباع عملية منطقية وواضحة كهذه سيزيد بقدر كبير من فرصنا في إنتاج ميزة يستخدمها الناس فعلا. قد يبدو الأمر وكأنه مليء بالتفاصيل في البداية، لكن بمجرد أن تأخذها كعادة ستصبح جزءا من طبيعتك. ترجمة - بتصرّف - للمقال Design principles: what to do when nobody is using your feature لصاحبه Brendan Fagan. حقوق الصورة البارزة محفوظة لـ Freepik

تزداد أهمية اختبارات الاستخدام في المجالات الموجّهة للمستخدمين الذين يستخدمون منتجاتنا وخدماتنا وتطبيقاتنا، والهدف الأساسي من تلك الاختبارات هو تزويد عملية التصميم ببيانات من منظور المستخدم النهائي End user؛ ذلك أن التصميم المرتكز حول المستخدم يركِّز على التصميم من أجل المستخدم الحقيقي، وتخبرنا اختبارات الاستخدام من هو هذا المستخدم، وكيف يستخدم المنتج، وما الهدف الذي يسعى لتحقيقه. طوّر الباحثون في مجال تجربة الاستخدام تقنيات عدة على مر السنين الفائتة لاختبار أفكارهم والتأكد من صلاحيتها، وتتنوع تلك الاختبارات من دراسات قابلية الاستخدام في المختبرات إلى تلك التي طُوِّرت حديثًا مثل تقييمات تجربة الاستخدام المفتوحة عبر الإنترنت، واختبارات Guerilla. تشمل أشهر صور الاختبارات الحالية اختبارات قابلية استخدام Usability Testing، ومجموعات التركيز Focus Groups، واختبارات المرحلة التجريبية Beta Testing، واختبارات A/B، والاستبيانات Surveys. سنتعرض في هذا المقال لخمس أنواع من هذه الاختبارات. اختبار قابلية الاستخدام Usability Testing اختبار قابلية استخدام منتج ما هو مشاهدة / متابعة مستخدم حقيقي أثناء استخدام المنتج كي ترى مدى سهولة استخدامه حقيقةً ومدى تلبيته لحاجاته، وهو أفضل طريقة لفهم تجربة المستخدم الحقيقي لمنتجك أو موقعك. وميزة هذا الاختبار أنه يُيَسر عليك تجميع مدى واسع من المعلومات والبيانات عن المستخدمين، إضافة إلى سهولة ربطه بتقنيات وأدوات أخرى، لهذا يعد اختبار قابلية الاستخدام ركنًا أساسية في تجربة المستخدم. تحديد ما إذا كانت جلسة الاختبار مراقبة أم لا هو أحد أهم القرارات التي ستتّخذها أثناء تنفيذ هذا الاختبار. دعنا نستعرض الحالتين لترى القرار المناسب للحالة التي لديك. جلسة اختبار قابلية الاستخدام المراقَبة Moderated Usability Testing تدار جلسات اختبار قابلية الاستخدام المراقبة من قبل محترفين يسعون لتجميع ودراسة تغذية راجعة Feedback من مستخدمين حقيقيين، ويتواجد أولئك المراقبون مع المشاركين في الاختبار سواء مباشرةً أو عن بعد، ليجيبوا عن أسئلتهم ويذللوا لهم أي عقبة قد يواجهونها، ويناقشوهم في أي تغذية راجعة قد يقدمها المشارك في الاختبار. إضافة إلى مشاهدة المستخدمين أثناء استخدام المنتج مع طرح أسئلة أثناء الاختبار لحث المستخدم على الجهر بملاحظاتهم وتساؤلاتهم. تُعقد اختبارات قابلية الاستخدام المراقبة غالبًا داخل مختبرات (مصدر الصّورة: usabilitygeek) متى يستخدم هذا الاختبار ينصح باختبارات قابلية الاستخدام المراقبة أثناء مرحلة التصميم، حين يكون لديك تصميم لم ينتهِ تطويره بعد، فحينها تكون الاختبارات المراقبة وسيلة فعّالة لاكتشاف المشاكل المحتملة للنموذج الأولي الذي لديك عبر مشاهدة ردود أفعال المستخدمين على ذلك النموذج الأولي، الأمر الذي يمكّنك من جمع بيانات أساسية توفر عليك وقتًا في التصميم والتطوير على منتج صعب الاستخدام. انتبه! يستطيع المراقب أن يوّجه المشارك في الاختبار للخوض عميقًا داخل المنتج، ويبقيه على الطريق الصحيح، ويساعده في حل أي معضلة تستشكل عليه. لكن مع كل هذا، يجب ألا ينساق المراقب في هذا الدور إلى حد إخبار المشارك بما عليه فعله، فهناك خط رقيق بين إرشاد المستخدم وبين مساعدته. وبناءً على ذلك، فمن الواجب عليك أن تحقق توازنًا بين الجانبين كي تبقي المشارك في اتجاه تطوير المنتج، دون أن تعبث بتجربته الطبيعية في استخدامه. اختبار قابلية الاستخدام غير المراقب Unmoderated Remote Usability Testing على عكس الاختبار السابق الذي توجد فيه مراقبة وإشراف من مطوري المنتج ومصممي تجربة الاستخدام، فهذا يستغني عنهم ليوفّر تجربة سريعة ويعتمد عليها، وقليلة التكلفة في نفس الوقت. يمكن إجراء اختبار قابلية الاستخدام غير المراقَبة من أي مكان في العالم وفي أي وقت، وبمشاركة أي أحد يطابق المواصفات التي تريدها (حقوق الصورة: UserZoom). تعتمد هذه الطريقة على استخدام أدوات وبرامج مصممة لاختبار الاستخدام تجمع ملاحظات المستخدمين آليًّا، كما تسجِّل سلوكهم أثناء الاختبار أيضًا. تطلب الأدوات والمواقع التي تقدم اختبارات قابلية الاستخدام من المشاركين إكمال سلسلة مهام باستخدام المنتج وتسألهم معلومات وملاحظات عن تجربتهم. مزايا الاختبارات غير المراقبة يجرّب المشاركون المنتج في بيئاتهم الطبيعية، حيث سيستخدمون المنتج الحقيقي عادة، دون وجود إشراف أو مراقبة، مما يؤدي إلى نتائج أكثر دقة بسبب الاستخدام الطبيعي للمنتج. يكون الاختبار أقرب إلى استبيان بمهام محددة في الحالات التي تستخدم فيها برامج أو مواقع لمتابعة الاختبار، وهو ما يزيح توترًا من على كاهل المستخدم، حيث يتحرر من القلق بشأن مواعيد انتهاء الاختبار. يمكن إجراء الاختبار على حالات كثيرة في نفس الوقت، كما أن زمن الاختبار ككل أقصر بكثير من الاختبار العادي، وتستطيع جمع البيانات في بضع ساعات اعتمادًا على حجم العينة التي لديك ومعايير الاختبار. تكلفة الاختبار قليلة بما أنك لن تحتاج إلى دفع المال للمشاركين أو المراقبين أو حتى لبيئة الاختبار ومعداته، وما عليك سوى وصف مهام الاختبار بوضوح كي تضمن أفضل النتائج بأقل تكلفة ممكنة. متى تستخدم الاختبار غير المراقب حين تحتاج إلى عينة كبيرة كي تثبت استنتاجًا خرجت به من بحثك الأوّلي والذي تم تحت مراقبة مشرفين. حين تكون لديك أسئلة محددة عن كيفية استخدام الناس لواجهة منتجك لإنجاز مهام بسيطة وبديهية. انتبه! لا تظنّنّ أن الاختبارات غير المراقبة بديل للاختبارات التي تتم تحت إشراف ومراقبة من مصممي تجربة الاستخدام ومطوري المنتج لديك؛ فالاختبارات غير تستخدم إلى جانب الاختبارات المراقَبة، سواء لتوضيح بعض النتائج التي خرجت من الاختبارات التي تمت تحت إشراف، أو الإجابة على بعض التساؤلات التي قد تكون لدى فريق التطوير أو غير ذلك. غياب المراقب يعني سيطرة أقل على الاختبار، ومراقبة أقل لشخص المشارك في الاختبار، ومخاطرة باحتمال ارتباك للمستخدم، لهذا تحتاج أن تضع توقعات واضحة للمشاركين، بأن تجعل المهام واضحة وسهلة الفهم. انتبه إلى الوقت الذي يستغرقه المشاركون في الاختبار، يُقتَرح أن يستغرق الاختبار غير المراقب من 15-30 دقيقة، ويكون به 3-5 مهام، إذ أن معدل ترك الاختبار دون إتمامه يزيد إن استغرقت المهام أكثر من ذلك. مجموعات التركيز Focus Groups تعد مجموعات التركيز من الطرق المجربة للتواصل بين باحث ما وبين المستخدمين للمنتج، وتتكون الجلسة الواحدة من مجموعة من ستة مستخدمين إلى اثنيْ عشر مستخدما يناقشون المشاكل والتخوفات المحتملة في خصائص واجهة الاستخدام، وتستمر هذه الجلسات لمدة ساعتين في المتوسط لكل جلسة منها، وتدار من قبل مراقب يحافظ على تركيز المجموعة. متى تستخدم مجموعات التركيز تسلط مجموعات التركيز الضوء على احتياجات العميل وشعوره تجاه المنتج قبل تصميمه وبعد إطلاقه بفترة كبيرة على السواء، فمثلًا في حالة تصميم موقع أو تطبيق، فإن دور مجموعات التركيز ليس تحديد مدى قابلية التصميم للاستخدام، بل اكتشاف ما الذي يريده المستخدم من المنتج، إضافة إلى تفضيلاتهم الشخصية وخواطرهم أو ملاحظاتهم عن المنتج. انتبه! لا تعتمد بالكامل على مجموعات التركيز في جمع بيانات اختبار العملاء للمنتج، فهي لا تقدم فائدة يعتمد عليها في قابلية الاستخدام، إذ أن المستخدم نادرًا ما يحصل على فرصة اكتشاف المنتج بنفسه. يُنصح بإجراء أكثر من جلسة لمجموعات تركيز، إذ أن نتائج الجلسة الواحدة قد لا تمثل الصورة الكاملة. اختبار المرحلة التجريبية Beta Testing يسمح لك هذا الاختبار بإخراج منتج شبه مكتمل لأفراد مستعدين لتقديم تغذية راجعة تفيد المنتج، ومن ثم تستطيع سؤالهم بعد حصولهم على المنتج بالفعل، وتتعقب طريقة استخدامهم الطبيعي له، مع طلب الإبلاغ بالأعطال بالطبع. متى تستخدم اختبار المرحلة التجريبية حين يكون منتجك شبه مكتمل لكنك تريد وضعه في يد مستخدمين نهائيين لتجمع ملاحظات وتغذية راجعة، وهو أسلوب ممتاز لتسويق منتجك والحصول على نقد بناء في نفس الوقت من أجل تنقيح التصميم وتطوير المنتج بشكل عام. انتبه! يجب أن تجري اختبارات كافية قبل إطلاق المنتج للعملاء، فما تريده من عملائك الذين سيختبرون النسخة التجريبية ليس البحث عن الأخطاء والإبلاغ عنها، بل مجرد ملاحظاتهم عن مزايا المنتج، ومدى قابليته للاستخدام. اختبار A/B حين يحتار المصممون لديك في اتخاذ قرار بين أحد تصميمين في الواجهة، فإن الاختبار المناسب الذي تجريه في هذه الحالة هو عرض أحد الخياريْن أو التصميميْن عشوائيًّا على مجموعة من المستخدمين، وعرض الخيار الآخر على مجموعة مطابقة لنفس مواصفات المجموعة الأولى من حيث العدد والفئة العمرية، …إلخ؛ ثم استخدام الإحصاءات التي خرجت بها من التجربتين لترى أي خيار أنسب لك. يسمح لك اختبار A/B بدراسة سلوك المستخدمين وكيف يتصرفون في السيناريوهات المختلفة لاستخدام المنتج. متى تستخدم اختبار A/B حين تريد اكتشاف الأثر الذي يحدثه فرق أو اختلاف طفيف في تصميم المنتج، خاصة حين تقارن إصدار المنتج الحالي بإصدار أحدث، لترى أثر التصميم الجديد. الاستبيانات الاستبيانات طريقة سهلة لجمع كمية كبيرة من المعلومات عن المستخدمين دون استثمار كثير وقت يذكر، يستطيع الباحث إنشاء استبيان باستخدام أدوات مثل Wufoo، SurveyMonkey، أو Google Forms، ثم يرسلها ويستقبل مئات الردود في بضع دقائق. والمعيار الذي تتبعه في وضع أسئلة الاستبيان هنا هو مدى تغطيتها – أي الأسئلة - لحاجات المستخد ورغباته ومشاكله. متى تستخدم الاستبيانات تُراكِم الاستبيانات كميات من البيانات عن الرضى العام للمستخدم، أو تجمع بيانات كمية لدعم نتائج أبحاث تتعلق بالجودة، حيث تحتاج الأخيرة إلى دعائم من تجربة المستخدمين للميزة، إذ لا يكفي أن تكون جيدة فقط، بل يجب أن تلقى قبولًا لدى المستخدمين أيضًا كي لا تكون تكلفة اقتصادي مهدرة. تتيح الاستبيانات رؤية أثر مئات الردود في نفس الوقت (حقوق الصورة: SurveyMonkey) انتبه! لا تعتمد على الاستبيانات في دراسة سلوك المستخدم. قد يبدو إنشاء استبيان لمنتج ما وكأنه أمر هين يتكون من وضع بضعة أسئلة، لكن على خلاف ذلك، فإنه يستغرق وقتًا غير قليل في تحضيره كما يجب، فالأسئلة يجب أن تكون واضحة وتستخلص إجابة شافية من المستخدم، ويجب أن ينشر هذا الاستبيان بعدها في وسط الفئة المناسبة من المستخدمين. خاتمة اختبار المستخدم هو ركن أساسي في عملية التصميم، وهو طريقة رائعة لفهم كيف تتفاعل قاعدة المستخدمين مع منتجك، فكما رأيت في هذا المقال أن الأنواع المختلفة من اختبارات قابلية الاستخدام تناسب أهدافًا مختلفة أيضًا من الاختبار نفسه. لكن على نحو عام، فإن أفضل صورة لاختبار المستخدم يعتمد كلية على ما هو منتجك أصلًا، وما البيانات التي تود معرفتها من المستخدمين بشأنه، وكم من الوقت لديك لتخصصه لهذا الاختبار، لذا فإن الأمر يعود إليك لترى أي طريقة تناسب احتياجاتك من أجل جمع تغذية راجعة مفيدة من تجربة المستخدم لمنتجك. ترجمة -بتصرف- لمقال The Top 5 User Testing Methods لصاحبه Nick Babich. حقوق الصورة البارزة محفوظة لـ Freepik

تجاهل السّير الذاتية المبهرجة، وانسَ العبارات المنمّقة، فإذا كانت شركتك بحاجة إلى عناوين ملفتة للانتباه، وصف منتجات يدفع قارئه إلى الشّراء وحملات تسويق أسطوريّة على البريد الإلكتروني وأكثر من ذلك، فعليك أن تركّز على ما هو أكثر من سيرة ذاتيّة وهميّة، فهناك آلاف الكتّاب الجيّدين حول العالم، ولكن قد يكون هناك المئات منهم فقط ممّن يمكنه أن يقدّم لك عملًا يستحقّ التّقدير، فلماذا ترضى بالمستوى المتوسّط بينما يمكنك اتّخاذ الخطوة الصّحيحة في سبيل توظيف الكاتب الأفضل على الإطلاق لشركتك. يناقش هذا المقال سبع خطوات مجرّبة ستقودك للعثور على أفضل كاتب لشركتك وتساعدك على إقناعه بالعمل معك باستمرار في سبيل ازدهار أعمالك. الخطوة 1: حدد ما تريده تماما الكتّاب كالأطبّاء، لكلّ منهم اختصاصه، فهل أنت بحاجة إلى مختصّ بآلام الظّهر أم إلى طبيب مفاصل؟ أوّل خطأ يقوم به النّاس عند بحثهم عن كاتب هو محاولة العثور على من يقوم بكلّ العمل، وذلك لأنّهم لا يعرفون ماذا يريدون تحديدًا، لذا يجب عليك تحديد ما تريده من الكاتب ، فربّما يكون بإمكانه القيام بكلّ شيء بدءًا من مراسلة الزّبائن الّذين لم يُتمّوا عمليّة الشّراء إلى كتابة وصف لمنتجاتك، ولكن إن كنت تعرف بالفعل أنّ أكثر ما تحتاج إليه هو التّدوين لترويج منتجاتك مثلًا فعليك التّأكّد من أنّ الكاتب الّذي اخترته متمييز حقّا في هذا المجال، لذا قم بكتابة قائمة بالأولويّات التي ترغب بأن يبدأ بها الكاتب فَور مباشرته للعمل، فإن كان لديك فكرة واضحة عن نوع المحتوى الذي تريد إنشاءه فستتمكّن من تضييق دائرة البحث، ولا تنسَ أن تجهّز أموالك، فمن يطلب كاتبًا متعدّد المواهب، يجب أن يكون جاهزًا لدفع مبلغ ليس بالقليل. الخطوة 2: حدد مستوى المهارات الذي تحتاجه عندما تتصفّح موقع خمسات فلن تكون أيّة خدمة كتابة ستجدها هي الأفضل لك، لذا عليك أن تقرّر المجال الذي تريد الكتابة فيه لتسهّل على نفسك العثور على الكاتب المطلوب. إن كنت تنوي عمل مشروع لمرّة واحدة فابحث عن كاتب مستقل لتوظّفه أو لتتعاقد معه لمرّة واحدة، ويمكنك البحث على منصّة خمسات أو على موقع مستقل لتجد طلبك، فلو كنت تريد تسويق منتج بعينه أو تريد القيام ببعض التّحسينات لنتائج موقعك على محرّكات البحث فسيكون خمسات ومستقل المكان الصّحيح للعثور على مُرادك، أمّا إذا كان هذا المشروع سيتكرّر بعد عدّة أشهر أو يمكن أن يتحوّل إلى سلسلة مشاريع فيجب أن تحاول الحفاظ على هذا الكاتب للاستعانة به لاحقًا، وإذا أمكنك جذبه بوعد بعمل مستمرّ فسيكون لديك فرصة أكبر لتحصل على كاتب جيد ليلتزم معك. إن كنت بحاجة إلى الكثير من الكتابة فسيكون لديك خياران: الأوّل توظيف كاتب بدوام كامل، وبالرغم من أنّ هذا ليس الخيار الأقل كلفةً إلّا أنّ له ميزة كبيرة هي غَوص هذا الكاتب في فهم هويّة شركتك، وسيكون استثمارك مع هذا الكاتب يستحقّ ذلك المبلغ عندما ترى تأثير الكلمات على الزّبائن والزّوّار. أمّا إن كان العمل بدوام كامل ليس ضمن خياراتك فستحتاج إلى توظيف كاتب براتب شهريّ، وكلاكما سيستفيد من هذه الصّفقة، فالدّخل الشّهريّ الثّابت للكاتب سيشكّل دافعًا ممتازًا لتحصل على شخص دائم التّواصل يساعدك في الإعلان عن المنتجات بمجرّد إنزالها إلى السّوق، خصوصًا إن كان شخصًا متآلفًا مع أهداف شركتك. الخطوة 3: لا توظف محترف SEO ليكتب مقالاتك توظيف كاتب قويّ لديه إلمام بمجال SEO أفضل من توظيف خبير SEO لا يحترف إلا هذا المجال، فأنت بحاجة إلى شخص لديه معرفة بمجال SEO ولكنّ الأهمّ من ذلك هو حاجتك لمن يهتم بالمحتوى وليس بالكلمات المفتاحيّة فقط، فلقد ولّى الزّمن الذي كان فيه الكتّاب يحسدون خبراء SEO، وأقول لك بصراحة بأنّه ليس من داع أبدًا لتقلق بخصوص قواعد SEO عندما توظّف كاتبا محترفا، فإن كان هناك كلمات مفتاحية تريدها أن تكون متضمّنة في وصف منتج ما فقم بكتابة قائمة بها وأخبر الكاتب بأن يبقيها حاضرة في ذهنه أثناء الكتابة. لا شيء يقتل الإلهام أكثر من قائمة طويلة وصارمة من الكلمات المفتاحية التي يجب على الكاتب لصقها مع بعضها، وإن كنت تبحث عن إعلان متميّز فلا تضيّق الخناق على الكاتب بقائمة طويلة من الكلمات المفتاحيّة، وابتعد عن طلب جمل تحوي كلمة مفتاحيّة وحيدة، وأعطهم حرّيّة الإبداع التي يحتاجونها لإنتاج مقال مذهل، وطالما أنّ محتوى مقالاتك وقواعد SEO الصارمة قد تم الاهتمام بهما معاً، فسينتج عن ذلك عمل رائع طالما انتظرتَه. الخطوة 4: لا تسأل كاتبا عن معدلات التّحويل Conversion Rates ولا عن عائدات الاستثمار أو عن نتائج اختبار A/B، أو عن أيّ أمر إحصائيّ آخر، فالكتاب يكتبون ولا يقومون بغير ذلك، والكاتب المستقلّ لا يهتمّ إلّا بالمحتوى بما يكفي مسبقا ليعرف كم سيكون تأثيره على القارئ، وتذكّر بأنّك تذهب إلى طبيب العمود الفقري لعلاج آلام ظهرك وليس لفحص كاحلك الملويّ، فالكتّاب رائعون في الكتابة ولكن لا تتوقّع منهم الاحتفاظ بإحصائيّاتٍ لنتائج أعمالهم. الخطوة 5: ابحث عن التغيير الذي قام به الكاتب للشركات التي تعامل معها هل تريد توظيف كاتب يثير إعجابك بالفعل؟ اطلب معرفة ماذا حدث قبل وبعد المقال الذي كتبه، ربما لا يحتفظ الكثير من الكتّاب بمثل هذه المعلومات، وربما سيحتاجون إلى التّنقيب في ملفّاتهم عن شيء كهذا، لكنّ النّظر إلى الفرق الذي أحدثه الكاتب طريقة رائعة للتعرّف عليه، ربّما يكون قد كتب مقالًا رهيبًا، ولكن عندما يكون قد غيّر روح الشّركة بالكامل من خلال مقاله فلا بدّ من أنّك ستنظر إليه نظرة مختلفة، لذا فأقلّ ما يمكنك أن تسأله هو أن يصف لك التّغيير الذي أحدثه في القرّاء، سواءَ كان ذلك التّغيير موافقًا لروح الشّركة أم أنّه قام بإنعاش كامل لأسلوب الموقع الإلكتروني في التّعامل مع الزبائن، وعندما يجيبك عن ذلك ستتمكّن من تخيّل تأثيره في شركتك. الخطوة 6 و7: قم باختبار من جزئين الاختبار الأول: من الهام تقديم اختبار عمليّ للكاتب فيما سيقوم به للشّركة، وقد يفاجئك عدد الشّركات التي لا تقوم بهذا الاختبار، إلّا أنّه ليس من المفترض أن يكون هذا الاختبار سلسلة فِخاخ يجب على الكاتب تجاوزها، ولا أن يكون معقّدا أو مرهقا كثيرًا، بل يجب أن يكون تطبيقا عمليّا لما تريده أن يقوم به، فإن عثرت على شخص تريد منه استلام حملات الإعلانات على البريد الإلكترونيّ فليس عليك أن تختبره بكتابة وصف للمنتجات، بل قم بإحضار أسماءٍ لعشر منتجات مختلفة ثمّ اطلب منه عمل لافتة إعلانيّةٍ لتوضع على الصّفحة الرئيسيّة، فبالتّركيز على مهمّات واضحة ليقوم بها ستحظى بفهم أفضل للمهارات الّتي يملكها. الاختبار الثاني: لم أجد خلال مسيرتي سوى شركة واحدة تقوم بهذا الاختبار، وفحواه أن تقدّم رأيك للكاتب في نتيجة الاختبار السّابق، بمجرّد استلامك لها، واجعله يرجع إلى أوراقه وأقلامه لتختبر كيفيّة تغييره لكتاباته حسب اقتراحاتك المقدّمة، وتختبر إمكانيّة تغييره لطريقة تفكيره حسب تعليماتك، فهذا اختبار رائع يُريك استجابة الممتَحَنِين للنَّقد البنّاء وليس اختباراً لطريقتهم في الكتابة فقط. إنّ جوهر ما تبحث عنه هو كاتب متميز في عمله، ولكنّ العثور على كاتب متميز وماهر في التّحرير ويمكن أن يكون معاونًا لك في العمل، فذلك أمر أفضل بكثير. بعد أن تكون قادرًا على تبادل الأفكار والآراء بينك وبين الكاتب سيكون لديك فكرة واضحة عن براعته وستتكوّن عندك صورة لكيفيّة العمل معه لاحقًا. أسئلة مساعدة في المقابلة يأتي الكتّاب بجميع الأشكال والأحجام، فبعضهم يحبّ سرد القصص، وبعضهم له خبرة في كتابة سيناريوهات مقاطع الفيديو ويندر العثور على كاتب يحبّ الإحصائيات، إلّا أنّهم موجودون أيضاً. ستجد في السّطور التالية أسئلة يرغب كلّ كاتب في أن يُسأل بعضًا منها في المقابلة، لذا استخدمها بدلًا من الأسئلة المعتادة في المرّة القادمة التي ترغب فيها بتوظيف كاتبٍ ينال إعجابك. هل قدّمت مرّة نصًا/قصّةً/عنوانًا ظننت بأنّه رائع ومع ذلك تمّ رفضه؟ لكلّ كاتب قصّة عن عمل تمّ رفضه، فهذا سؤال رائع سيساعدك لتحصل على تصور لنوع الكاتب الذي تتعامل معه دون قيود الرّسميّات. كيف بدأت العمل في الكتابة؟ لا يحتاج هذا السّؤال إلى الكثير من التّفكير، وسيكون من الممتع أن تعرف كيف بدأ هذا الكاتب عمله في هذا المجال، كما سيلقي الضّوء على خلفيّة خبرة هذا الكاتب، ربّما تجد بعض الكتّاب قد بدأ يحلم بأن يصبح كاتبًا مشهوراً منذ كان في السادسة عشرة من عمره ويشغل فكره طوال الوقت باتّباع خطا الكتّاب الكبار. ما هي الشّركة التي تلهمك في مجال الكتابة؟ لكلّ كاتب شركة يحلم بالكتابة لها، لذا اسألهم ما هي الشّركات التي يمكنهم كتابة المحتوى والإعلانات لها بشكل جيّد، وستحصل على تصوّر لنمط الكتابة الذي يحبّونه اعتمادًا على إجاباتهم. هل هناك نوع معيّنٌ من المنتجات تحبّ الكتابة عنها؟ أفترض أنّ معظم المقابلين سيخمّنون أنّني سأختار شيئًا مثل ألبسة الأطفال أو ألعاب الأطفال بناءً على سيرتي الذّاتيّة ولكنّني في الحقيقية أفضّل الكتابة عن المنتجات الرّجالية مثل قوارب الصيد، السّيوف العربية وربطات العنق لأنّني أجد فيها الكثير من التّحدي، فلقد اعتدت ككاتب أن أضع نفسي مكان القارئ لأعرف كيف سيؤثّر ذلك عليه، وهذا ما يدفعني لحبّ عملي في الكتابة والتّأليف. لن تكون مجبرا بشكل رسميّ على توظيف أيّ كاتب في نهاية الاختبار، فأنت تبحث عن كاتب متميز في سرد القصص وكتابة المحتوى وذلك أمر حاسم لنجاح أيّ تجارة إلكترونية أو مدوّنة، فإن كان بإمكانك العثور على كاتب يمكنه إمتاع الزّوّار بكتاباته وجذب الزّبائن ثم إخبارهم عن منتجاتك ودفعهم للشّراء، فسيكون عليك تركيز كلّ جهودك على إحضاره إلى موقعك، وبمجرّد أن يقرأ زبائنك كلّ المقالات الرّائعة الموجودة لديك ستحصل على ما يكفيك من الزّوّار والزّبائن لبقيّة حياتك. ترجمة -وبتصرّف- للمقال The 7 Secret Steps to Find, Hire & Keep a Killer Copywriter لكاتبته Laura Serino. حقوق الصورة البارزة: Designed by Freepik.