قياس سهولة استخدام البرمجيات حسابياً

تمهيد

تخيل معي لو أن بلدية إحدى المدن، ولتكن طوكيو مثلاً، قررت إطلاق حملة تحديث وتجميل شاملة لأرجاء المدينة وشوارعها، فقامت —من ضمن ما قامت به— بتبديل رموز الشاخصات المرورية برموز أخرى أكثر ألواناً وإشراقاً وجاذبية، ترى ما النتيجة؟

أعتقد ببساطة أنها ستؤدي لارتفاع معدل حوادث السير في المدينة! فظهور رموز جديدة أمام عينيك بصفتك سائقاً (مستخدماً للنظام المروري)؛ مخالِفةً للرموز التي تعلمتها في دورة تعلم القيادة وألفتها مع التجربة، لابد أن يؤدي لانخفاض مستوى قابلية قراءة تلك الرموز وفهمها بالنسبة لك، وبالتالي انخفاض مستوى كفاءتك كسائق مستخدم في استخدام النظام المروري عموماً، أي بعبارة أخرى: انخفاض مستوى قابلية استخدام النظام المروري.

فما هي قابلية الاستخدام؟

إذن، فقابلية الاستخدام هي خاصية في المنتَج ناتجة عن حالة الألفة الحاصلة لدى المستخدم تجاه المنتَج على مر الزمن.

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

قياس قابلية الاستخدام

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

في الوقت الحاضر، يمكن اعتبار منهاج ICDL بمثابة القاعدة القياسية تلك. بعبارة أخرى، يمكن اعتبار كل من ويندوز وأوفيس بمثابة القاعدة القياسية أو المنصة القياسية التي تقاس عليها قابلية استخدام البرمجيات الأخرى العاملة في بيئة ويندوز. وبالمثل، في عالم لينكس، يجب اعتماد توزيعة لينكس معينة كقاعدة قياسية أو منصة يتعين عليك كمستخدم لنظام لينكس تعلمها أولاً، قبل اختبار أي منتج برمجي آخر يعمل في تلك البيئة لمحاولة تقييم قابلية استخدامه.

الآن، لنفترض أنك اخترت توزيعة لينكس معينة كمنصة. ستلاحظ من وجهة نظرك كمستخدم أن واجهة استخدام هذه المنصة ستنطوي على مجموعة من الموارد (مكونات واجهة الاستخدام) يمكن تصنيفها في ثلاث فئات:

• مجموعة مصطلحات خاصة بها
• مجموعة رموز (أيقونات) خاصة بها
• مجموعة نوافذ خاصة بها كـ (فتح/حفظ/حفظ باسم/اختيار خط/اختيار لون… الخ).

وبالمقابل:

• كل منتج برمجي قد تكون له لائحته الخاصة من المصطلحات (تحديداً، تلك المصطلحات التي لم ترد ضمن لائحة مصطلحات المنصة).
• كل منتج برمجي قد تكون له لائحته الخاصة من الرموز (تحديداً، تلك الرموز التي لم ترد ضمن لائحة رموز المنصة).
• كل منتج برمجي قد تكون له لائحته الخاصة من المكونات (تحديداً، تلك المكونات التي لم ترد ضمن لائحة مكونات المنصة).

المبدأ المقترح هنا لقياس قابلية استخدام ذلك المنتَج هو أنه كلما زاد اعتماد هذا المنتَج على مكونات واجهة الاستخدام الخاصة بالمنصة، كلما زادت قابلية استخدامه، وبالمقابل، كلما استحدث مجموعة مكونات واجهة استخدام خاصة به، كلما تقلصت قابلية استخدامه.

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

ولقياس قابلية استخدام منتج برمجي معين عددياً، يتعين عليك كباحث تحديد طريقة معينة لحساب النقاط الموجبة والسالبة فيه:

• النقاط الموجبة (الإيجابيات):
  • عدد الرموز المعرفة في المنصة والمستخدمة في المنتج البرمجي.
  • عدد المصطلحات المعرفة في المنصة والمستخدمة في المنتج البرمجي.
  • عدد استدعاءات مكونات واجهة الاستخدام التابعة للمنصة في المنتج البرمجي.
• النقاط السالبة (السلبيات):
  • عدد الرموز الخاصة بالمنتج البرمجي
  • عدد المصطلحات الخاصة بالمنتج البرمجي
  • عدد المكونات الخاصة بالمنتج البرمجي

مثال:

بفرض أن لدينا البيانات التالية المتعلقة بمنتج برمجي ملتزم بمبدأ الاتساق الداخلي:

يمكنك حساب قابلية استخدامه بالاستعانة بهذه المعادلة:

usability   = Reused Resources - New Resources
            = ( 20 + 30 + 5 ) - ( 5 + 10 + 15)
            = 25

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

أثر اللمسات الفنية الخاصة على سهولة الاستخدام

تُرى ما هو تأثير اللمسات الفنية الخاصة على سهولة الاستخدام؟ هل هي عامل مساعد في جعل المنتج البرمجي أسهل استخداماً؟ أم أن العكس هو الصحيح؟

بلغة المال والأعمال، هل تنجح استراتيجية التمييز التسويقية في عالم البرمجيات؟

بصورة عامة، ووفقاً لخبير التسويق الأمريكي البروفيسور مايكل بورتر، تتمثل استراتيجيات المنافسة التجارية عادة في ثلاث استراتيجيات:

• استراتيجية المنافسة بالتكاليف Cost Leadership Strategy.
• استراتيجية التمييز Differentiation Strategy.
• استراتيجية التخصص Niche Strategy.

وتعني استراتيجية التمييز ابتكار مميزات جديدة في المنتَج (شكلياً ووظيفياً) غير متوفرة في المنتجات المنافسة، الأمر الذي يجذب الزبون بعد اقتناعه بـ تميُّز المنتج عن أقرانه في السوق.

هذا المبدأ يفسر لجوء شركات البرمجيات التجارية في بيئة ويندوز لإكساء منتجاتها البرمجية بمكونات براقة وفريدة بعيداً عن مكونات وموارد المنصة، أملاً منها بجذب الزبائن اعتماداً على استراتيجية التمييز تلك كما أسلفنا.

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

الخلاصة

تشكل الأيقونات والمصطلحات والنوافذ (مربعات الحوار) مجتمعة حالياً مفردات لغة واجهة الاستخدام التي يجري بها تخاطب تلك الواجهات مع المستخدم. وبقدر التزام المنتَج البرمجي باستخدام تلك المفردات، بقدر ما يحظى ذلك المنتَج بمستوىً أعلى من قابلية الاستخدام. بعبارة موجزة: الاتساق والتناغم هو مفتاح قابلية الاستخدام.

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

وعليه، فلا يُنصح باستخدام استراتيجية التمييز في البرمجيات على صعيد الملامح الشكلية (لا المهام الوظيفية بالطبع)، لأنها ستؤثر بلا شك سلباً على قابلية المنتَج البرمجي للاستخدام.