المُقدّمة
يعد تطوير واجهات فعالة لأنظمة الكمبيوتر هو الهدف الأساسي للبحث في التفاعلات بين الإنسان والحاسوب.
يمكن تعريف الواجهة على أنها مجموع مكونات الأجهزة والبرامج التي يتم من خلالها تشغيل النظام وإعلام المستخدمين بحالته. تشتمل مكونات الأجهزة على أجهزة إدخال البيانات والتأشير (مثل لوحات المفاتيح والماوس) وأجهزة عرض المعلومات (مثل الشاشات ومكبرات الصوت) وأدلة المستخدم والوثائق. تتضمن مكونات البرنامج أوامر القائمة ، والرموز ، والنوافذ ، وتعليقات المعلومات ، وأنظمة الملاحة والرسائل وما إلى ذلك. قد تكون مكونات الأجهزة والبرامج الخاصة بالواجهة مرتبطة ارتباطًا وثيقًا بحيث لا يمكن فصلها (على سبيل المثال ، مفاتيح الوظائف على لوحات المفاتيح). تتضمن الواجهة كل ما يدركه المستخدم ويفهمه ويتلاعب به أثناء تفاعله مع الكمبيوتر (Moran 1981). لذلك فهو محدد حاسم للعلاقة بين الإنسان والآلة.
يهدف البحث عن الواجهات إلى تحسين أداة الواجهة ، وإمكانية الوصول ، والأداء والسلامة ، وسهولة الاستخدام. لهذه الأغراض ، يتم تحديد الأداة بالرجوع إلى المهمة المراد تنفيذها. يحتوي النظام المفيد على الوظائف الضرورية لإنجاز المهام التي يُطلب من المستخدمين القيام بها (مثل الكتابة والرسم والحسابات والبرمجة). إمكانية الوصول هي مقياس لقدرة الواجهة على السماح لفئات متعددة من المستخدمين - خاصة الأفراد ذوي الإعاقة ، وأولئك الذين يعملون في مناطق معزولة جغرافيًا ، في حركة مستمرة أو مشغولين - لاستخدام النظام لأداء أنشطتهم. الأداء ، الذي يُنظر إليه هنا من وجهة نظر بشرية وليس من وجهة نظر فنية ، هو مقياس لدرجة أن النظام يحسن الكفاءة التي يؤدي بها المستخدمون عملهم. يتضمن ذلك تأثير وحدات الماكرو واختصارات القائمة ووكلاء البرامج الذكية. يتم تحديد سلامة النظام من خلال المدى الذي تسمح به الواجهة للمستخدمين بأداء عملهم دون مخاطر التعرض للإنسان أو المعدات أو البيانات أو الحوادث أو الخسائر البيئية. أخيرًا ، يتم تعريف قابلية الاستخدام على أنها السهولة التي يتم بها تعلم النظام واستخدامه. بالتمديد ، فإنه يشمل أيضًا أداة النظام والأداء الموضح أعلاه.
عناصر تصميم الواجهة
منذ اختراع أنظمة التشغيل ذات الوقت المشترك في عام 1963 ، وخاصة منذ ظهور الحواسيب الصغيرة في عام 1978 ، كان تطوير واجهات الإنسان والحاسوب متفجرًا (انظر Gaines and Shaw 1986 للاطلاع على التاريخ). كان الدافع وراء هذا التطور مدفوعًا بشكل أساسي بثلاثة عوامل تعمل في وقت واحد:
أولاً ، كان التطور السريع جدًا لتكنولوجيا الكمبيوتر ، نتيجة للتقدم في الهندسة الكهربائية والفيزياء وعلوم الكمبيوتر ، أحد المحددات الرئيسية لتطوير واجهة المستخدم. وقد أدى ذلك إلى ظهور أجهزة الكمبيوتر ذات القوة والسرعة المتزايدة باستمرار ، مع سعات ذاكرة عالية ، وشاشات رسومات عالية الدقة ، وأجهزة تأشير أكثر طبيعية تسمح بالتلاعب المباشر (على سبيل المثال ، الفئران ، وكرات التتبع). كانت هذه التقنيات أيضًا مسؤولة عن ظهور الحوسبة الدقيقة. كانت أساس الواجهات المستندة إلى الأحرف في الستينيات والسبعينيات ، والواجهات الرسومية في أواخر السبعينيات ، وواجهات الوسائط المتعددة والممتدة التي ظهرت منذ منتصف الثمانينيات بناءً على البيئات الافتراضية أو باستخدام مجموعة متنوعة من التعرف على المدخلات البديلة التقنيات (على سبيل المثال ، الصوت والكتابة اليدوية والكشف عن الحركة). تم إجراء قدر كبير من البحث والتطوير في السنوات الأخيرة في هذه المجالات (Waterworth and Chignel 1960 ؛ Rheingold 1970). بالتزامن مع هذه التطورات ، تم تطوير أدوات برمجية أكثر تقدمًا لتصميم الواجهة (على سبيل المثال ، أنظمة النوافذ ، ومكتبات الكائنات الرسومية ، وأنظمة النماذج الأولية) التي تقلل بشكل كبير من الوقت المطلوب لتطوير الواجهات.
ثانيًا ، يلعب مستخدمو أنظمة الكمبيوتر دورًا كبيرًا في تطوير واجهات فعالة. هناك ثلاثة أسباب لذلك. أولاً ، المستخدمون الحاليون ليسوا مهندسين أو علماء ، على عكس مستخدمي أجهزة الكمبيوتر الأولى. ولذلك فهي تتطلب أنظمة يمكن تعلمها واستخدامها بسهولة. ثانيًا ، يتنوع العمر والجنس واللغة والثقافة والتدريب والخبرة والمهارة والتحفيز والاهتمام للمستخدمين الفرديين تمامًا. لذلك يجب أن تكون الواجهات أكثر مرونة وأكثر قدرة على التكيف مع مجموعة من الاحتياجات والتوقعات. أخيرًا ، يتم توظيف المستخدمين في مجموعة متنوعة من القطاعات الاقتصادية ويؤدون مجموعة متنوعة تمامًا من المهام. لذلك يجب على مطوري الواجهات إعادة تقييم جودة واجهاتهم باستمرار.
أخيرًا ، تعمل المنافسة الشديدة في السوق وتوقعات السلامة المتزايدة على تطوير واجهات أفضل. هذه الانشغالات مدفوعة بمجموعتين من الشركاء: من ناحية ، منتجو البرمجيات الذين يسعون جاهدين لخفض تكاليفهم مع الحفاظ على تميز المنتج الذي يعزز أهدافهم التسويقية ، ومن ناحية أخرى ، المستخدمون الذين يمثل البرنامج بالنسبة لهم وسيلة لتقديم منتجات تنافسية والخدمات للعملاء. لكلتا المجموعتين ، توفر الواجهات الفعالة عددًا من المزايا:
لمنتجي البرمجيات:
- أفضل صورة للمنتج
- زيادة الطلب على المنتجات
- أوقات تدريب أقصر
- انخفاض متطلبات خدمة ما بعد البيع
- قاعدة صلبة يمكن على أساسها تطوير خط إنتاج
- الحد من مخاطر الأخطاء والحوادث
- تقليل الوثائق.
للمستخدمين:
- مرحلة التعلم الأقصر
- زيادة قابلية التطبيق العام للمهارات
- تحسين استخدام النظام
- زيادة الاستقلالية باستخدام النظام
- تقليل الوقت اللازم لتنفيذ المهمة
- تقليل عدد الأخطاء
- زيادة الرضا.
يمكن للواجهات الفعالة تحسين صحة وإنتاجية المستخدمين بشكل كبير في نفس الوقت حيث تعمل على تحسين الجودة وتقليل تكلفة تدريبهم. ومع ذلك ، يتطلب هذا تصميم الواجهة الأساسية وتقييمها على مبادئ مريحة ومعايير الممارسة ، سواء كانت مبادئ توجيهية ، أو معايير الشركات لكبرى الشركات المصنعة للأنظمة أو المعايير الدولية. على مر السنين ، تراكمت مجموعة رائعة من المبادئ والإرشادات المريحة المتعلقة بتصميم الواجهة (Scapin 1986؛ Smith and Mosier 1986؛ Marshall، Nelson and Gardiner 1987؛ Brown 1988). تغطي هذه المجموعة متعددة التخصصات جميع جوانب وضع الأحرف والواجهات الرسومية ، بالإضافة إلى معايير تقييم الواجهة. على الرغم من أن تطبيقه الملموس يسبب أحيانًا بعض المشكلات - على سبيل المثال ، المصطلحات غير الدقيقة والمعلومات غير الكافية عن ظروف الاستخدام والعرض التقديمي غير المناسب - إلا أنه يظل موردًا قيمًا لتصميم الواجهة وتقييمها.
بالإضافة إلى ذلك ، طورت كبرى الشركات المصنعة للبرامج إرشاداتها الخاصة ومعاييرها الداخلية لتصميم الواجهة. تتوفر هذه الإرشادات في المستندات التالية:
- إرشادات واجهة Apple البشرية (1987)
- افتح Look (الأحد 1990)
- دليل نمط OSF / Motif (1990)
- دليل وصول مستخدم IBM Common لتصميم واجهة المستخدم (1991)
- مرجع تصميم واجهة IBM المتقدم (1991)
- واجهة Windows: دليل تصميم التطبيق (مايكروسوفت 1992)
تحاول هذه الإرشادات تبسيط تطوير الواجهة من خلال فرض حد أدنى من التوحيد والاتساق بين الواجهات المستخدمة على نفس منصة الكمبيوتر. فهي دقيقة ومفصلة وشاملة تمامًا من عدة جوانب ، وتوفر مزايا إضافية تتمثل في كونها معروفة جيدًا ويمكن الوصول إليها واستخدامها على نطاق واسع. هم ال في الواقع معايير التصميم التي يستخدمها المطورون ، ولهذا السبب لا غنى عنها.
علاوة على ذلك ، تعد معايير المنظمة الدولية للتوحيد القياسي (ISO) أيضًا مصادر قيمة للغاية للمعلومات حول تصميم الواجهة وتقييمها. تهتم هذه المعايير بشكل أساسي بضمان التوحيد عبر الواجهات ، بغض النظر عن الأنظمة الأساسية والتطبيقات. لقد تم تطويرها بالتعاون مع وكالات التقييس الوطنية ، وبعد مناقشة مستفيضة مع الباحثين والمطورين والمصنعين. معيار تصميم واجهة ISO الرئيسي هو ISO 9241 ، الذي يصف المتطلبات المريحة لوحدات العرض المرئية. وهي تتألف من 17 جزء. على سبيل المثال ، تناقش الأجزاء 14 و 15 و 16 و 17 أربعة أنواع من الحوار بين الإنسان والحاسوب - القوائم ، ولغات الأوامر ، والتلاعب المباشر ، والنماذج. يجب أن تأخذ معايير ISO الأولوية على مبادئ وإرشادات التصميم الأخرى. تناقش الأقسام التالية المبادئ التي يجب أن تكون شرطًا لتصميم الواجهة.
فلسفة تصميم تركز على المستخدم
اقترح Gould and Lewis (1983) فلسفة تصميم تركز على مستخدم وحدة عرض الفيديو. مبادئها الأربعة هي:
- الاهتمام الفوري والمستمر للمستخدمين. يتم الحفاظ على الاتصال المباشر مع المستخدمين ، من أجل فهم أفضل لخصائصهم ومهامهم.
- تصميم متكامل. تم تطوير جميع جوانب قابلية الاستخدام (على سبيل المثال ، الواجهة ، والكتيبات ، وأنظمة المساعدة) بالتوازي ووضعها تحت سيطرة مركزية.
- التقييم الفوري والمستمر من قبل المستخدمين. يقوم المستخدمون باختبار الواجهات أو النماذج الأولية في وقت مبكر في مرحلة التصميم ، في ظل ظروف عمل محاكية. يتم قياس الأداء والتفاعلات كماً ونوعاً.
- التصميم المتكرر. يتم تعديل النظام على أساس نتائج التقييم ، وبدأت دورة التقييم من جديد.
تم شرح هذه المبادئ بمزيد من التفصيل في Gould (1988). كانت وثيقة الصلة جدًا عندما تم نشرها لأول مرة في عام 1985 ، بعد خمسة عشر عامًا ، ظلت كذلك ، بسبب عدم القدرة على التنبؤ بفعالية الواجهات في غياب اختبار المستخدم. تشكل هذه المبادئ قلب دورات التطوير المستندة إلى المستخدم التي اقترحها العديد من المؤلفين في السنوات الأخيرة (Gould 1988؛ Mantei and Teorey 1989؛ Mayhew 1992؛ Nielsen 1992؛ Robert and Fiset 1992).
ستحلل بقية هذه المقالة خمس مراحل في دورة التطوير التي يبدو أنها تحدد فعالية الواجهة النهائية.
تحليل المهمة
يعد تحليل المهام المريح أحد ركائز تصميم الواجهة. بشكل أساسي ، هي العملية التي يتم من خلالها توضيح مسؤوليات المستخدم وأنشطته. وهذا بدوره يسمح بتصميم واجهات متوافقة مع خصائص مهام المستخدمين. هناك وجهان لأي مهمة معينة:
- • مهمة رمزية، بما يتوافق مع التعريف الرسمي للمنظمة للمهمة. وهذا يشمل الأهداف والإجراءات ومراقبة الجودة والمعايير والأدوات.
- • مهمة حقيقية، بما يتوافق مع قرارات المستخدمين وسلوكياتهم اللازمة لتنفيذ المهمة الاسمية.
الفجوة بين المهام الاسمية والحقيقية أمر لا مفر منه وينتج عن فشل المهام الاسمية في مراعاة الاختلافات والظروف غير المتوقعة في سير العمل ، والاختلافات في التمثيلات الذهنية للمستخدمين لعملهم. تحليل المهمة الاسمية غير كافٍ للفهم الكامل لأنشطة المستخدمين.
يفحص تحليل النشاط عناصر مثل أهداف العمل ، ونوع العمليات المنجزة ، وتنظيمها الزمني (متسلسل ، متوازي) وتكرارها ، وأنماط التشغيل التي يعتمد عليها ، والقرارات ، ومصادر الصعوبة ، والأخطاء وأنماط الاسترداد. يكشف هذا التحليل عن العمليات المختلفة التي يتم إجراؤها لإنجاز المهمة (الكشف ، البحث ، القراءة ، المقارنة ، التقييم ، القرار ، التقدير ، التوقع) ، الكيانات التي تم التلاعب بها (على سبيل المثال ، في التحكم في العملية ، ودرجة الحرارة ، والضغط ، ومعدل التدفق ، والحجم) و العلاقة بين المشغلين والكيانات. السياق الذي يتم تنفيذ المهمة فيه يشترط هذه العلاقات. هذه البيانات ضرورية لتحديد وتنظيم ميزات النظام المستقبلي.
يتكون تحليل المهام في أبسط صوره من جمع البيانات وتصنيفها وتحليلها. يمكن إجراؤه قبل أو أثناء أو بعد حوسبة المهمة. في جميع الحالات ، يوفر إرشادات أساسية لتصميم الواجهة وتقييمها. يهتم تحليل المهام دائمًا بالمهمة الحقيقية ، على الرغم من أنه قد يدرس أيضًا المهام المستقبلية من خلال المحاكاة أو اختبار النموذج الأولي. عندما يتم إجراؤها قبل الحوسبة ، فإنها تدرس "المهام الخارجية" (أي المهام الخارجية للكمبيوتر) التي يتم إجراؤها باستخدام أدوات العمل الموجودة (Moran 1983). هذا النوع من التحليل مفيد حتى عندما يُتوقع أن تؤدي الحوسبة إلى تعديل كبير للمهمة ، حيث إنها توضح طبيعة ومنطق المهمة وإجراءات العمل والمصطلحات والمشغلين والمهام وأدوات العمل ومصادر الصعوبة. وبذلك ، فإنه يوفر البيانات اللازمة لتحسين المهام والحوسبة.
يركز تحليل المهام الذي يتم إجراؤه أثناء حوسبة المهام على "المهام الداخلية" ، كما يؤديها ويمثلها نظام الكمبيوتر. يتم استخدام نماذج النظام لجمع البيانات في هذه المرحلة. يتم التركيز على نفس النقاط التي تم فحصها في المرحلة السابقة ، ولكن من وجهة نظر عملية الحوسبة.
بعد حوسبة المهام ، يدرس تحليل المهام أيضًا المهام الداخلية ، لكن التحليل يركز الآن على نظام الكمبيوتر النهائي. غالبًا ما يتم إجراء هذا النوع من التحليل لتقييم الواجهات الحالية أو كجزء من تصميم الواجهات الجديدة.
يعد تحليل المهام الهرمية طريقة شائعة في بيئة العمل المعرفية أثبتت أنها مفيدة جدًا في مجموعة متنوعة من المجالات ، بما في ذلك تصميم الواجهة (Shepherd 1989). وهو يتألف من تقسيم المهام (أو الأهداف الرئيسية) إلى مهام فرعية ، يمكن تقسيم كل منها إلى مزيد من التقسيمات الفرعية ، حتى يتم الوصول إلى المستوى المطلوب من التفاصيل. إذا تم جمع البيانات مباشرة من المستخدمين (على سبيل المثال ، من خلال المقابلات ، النطق) ، يمكن أن يوفر التقسيم الهرمي صورة للخريطة الذهنية للمستخدمين لمهمة ما. يمكن تمثيل نتائج التحليل بواسطة مخطط أو جدول على شكل شجرة ، ولكل تنسيق مزايا وعيوب.
تحليل المستخدم
الركيزة الأخرى لتصميم الواجهة هو تحليل خصائص المستخدم. قد تتعلق خصائص الاهتمام بعمر المستخدم أو الجنس أو اللغة أو الثقافة أو التدريب أو المعرفة الفنية أو المتعلقة بالكمبيوتر أو المهارات أو الدافع. الاختلافات في هذه العوامل الفردية هي المسؤولة عن الاختلافات داخل وبين مجموعات المستخدمين. لذلك فإن أحد المبادئ الأساسية لتصميم الواجهة هو أنه لا يوجد شيء مثل المستخدم العادي. بدلاً من ذلك ، يجب تحديد مجموعات مختلفة من المستخدمين وفهم خصائصهم. ينبغي تشجيع ممثلي كل مجموعة على المشاركة في تصميم الواجهة وعمليات التقييم.
من ناحية أخرى ، يمكن استخدام تقنيات من علم النفس وبيئة العمل والهندسة المعرفية للكشف عن معلومات حول خصائص المستخدم المتعلقة بالإدراك والذاكرة ورسم الخرائط المعرفية واتخاذ القرار والتعلم (Wickens 1992). من الواضح أن الطريقة الوحيدة لتطوير واجهات متوافقة حقًا مع المستخدمين هي مراعاة تأثير الاختلافات في هذه العوامل على قدرات المستخدم وحدوده وطرق التشغيل.
ركزت الدراسات المريحة للواجهات بشكل حصري تقريبًا على المهارات الإدراكية والمعرفية والحركية للمستخدمين ، بدلاً من العوامل العاطفية أو الاجتماعية أو السلوكية ، على الرغم من أن العمل في المجالات الأخيرة أصبح أكثر شيوعًا في السنوات الأخيرة. (للحصول على رؤية متكاملة للبشر كنظم معالجة معلومات ، انظر Rasmussen 1986 ؛ لمراجعة العوامل المتعلقة بالمستخدم التي يجب مراعاتها عند تصميم الواجهات ، انظر Thimbleby 1990 و Mayhew 1992). تستعرض الفقرات التالية الخصائص الأربع الرئيسية المتعلقة بالمستخدم والتي يجب أن تؤخذ في الاعتبار أثناء تصميم الواجهة.
التمثيل العقلي
تعكس النماذج الذهنية التي ينشئها المستخدمون للأنظمة التي يستخدمونها الطريقة التي يتلقون بها هذه الأنظمة ويفهمونها. لذلك تختلف هذه النماذج كدالة لمعرفة المستخدمين وخبراتهم (Hutchins 1989). من أجل تقليل منحنى التعلم وتسهيل استخدام النظام ، يجب أن يكون النموذج المفاهيمي الذي يقوم عليه النظام مشابهًا للتمثيل العقلي للمستخدمين له. ومع ذلك ، يجب الاعتراف بأن هذين النموذجين غير متطابقين أبدًا. يتميز النموذج العقلي بكونه شخصيًا (Rich 1983) ، غير مكتمل ، ومتغير من جزء من النظام إلى آخر ، وربما يكون خاطئًا في بعض النقاط وفي تطور مستمر. يلعب دورًا ثانويًا في المهام الروتينية ولكنه يلعب دورًا رئيسيًا في المهام غير الروتينية وأثناء تشخيص المشكلات (Young 1981). في الحالات الأخيرة ، سيكون أداء المستخدمين ضعيفًا في حالة عدم وجود نموذج عقلي مناسب. التحدي الذي يواجه مصممو الواجهة هو تصميم الأنظمة التي يؤدي تفاعلها مع المستخدمين إلى حث هؤلاء المستخدمين على تشكيل نماذج عقلية مشابهة للنموذج المفاهيمي للنظام.
تعلم
يلعب القياس دورًا كبيرًا في تعلم المستخدم (Rumelhart and Norman 1983). لهذا السبب ، فإن استخدام المقارنات المناسبة أو الاستعارات في الواجهة يسهل التعلم ، من خلال تعظيم نقل المعرفة من المواقف أو الأنظمة المعروفة. تلعب التشبيهات والاستعارات دورًا في أجزاء كثيرة من الواجهة ، بما في ذلك أسماء الأوامر والقوائم والرموز والأيقونات والأكواد (مثل الشكل واللون) والرسائل. عندما يكون ذلك مناسبًا ، فإنها تساهم بشكل كبير في جعل الواجهات طبيعية وأكثر شفافية للمستخدمين. من ناحية أخرى ، عندما لا تكون ذات صلة ، يمكن أن تعيق المستخدمين (Halasz and Moran 1982). حتى الآن ، فإن الاستعارتين المستخدمتين في الواجهات الرسومية هما سطح المكتب وبدرجة أقل ، فإن غرفة.
يفضل المستخدمون عمومًا تعلم برامج جديدة باستخدامها على الفور بدلاً من القراءة أو المشاركة في دورة تدريبية - فهم يفضلون التعلم القائم على الإجراء الذي يكونون فيه نشطين معرفيًا. ومع ذلك ، فإن هذا النوع من التعلم يقدم بعض المشكلات للمستخدمين (Carroll and Rosson 1988؛ Robert 1989). يتطلب بنية واجهة متوافقة وشفافة ومتسقة ومرنة وظاهرة طبيعية ومتسامحة مع الأخطاء ، ومجموعة ميزات تضمن قابلية الاستخدام والتغذية الراجعة وأنظمة المساعدة والمساعدات الملاحية ومعالجة الأخطاء (في هذا السياق ، تشير "الأخطاء" إلى الإجراءات التي يرغب المستخدمون في التراجع عنها). تمنح الواجهات الفعالة المستخدمين بعض الاستقلالية أثناء الاستكشاف.
تطوير المعرفة
تتطور معرفة المستخدم مع زيادة الخبرة ، ولكنها تميل إلى الاستقرار بسرعة. وهذا يعني أن الواجهات يجب أن تكون مرنة وقادرة على الاستجابة في نفس الوقت لاحتياجات المستخدمين بمستويات مختلفة من المعرفة. من الناحية المثالية ، يجب أن يكونوا أيضًا حساسين للسياق ويقدمون مساعدة مخصصة. يعد نظام EdCoach ، الذي طورته Desmarais و Giroux و Larochelle (1993) واجهة من هذا القبيل. تصنيف المستخدمين إلى فئات مبتدئين ومتوسطين وخبراء غير مناسب لغرض تصميم الواجهة ، لأن هذه التعريفات ثابتة للغاية ولا تأخذ في الاعتبار الاختلافات الفردية. تكنولوجيا المعلومات القادرة على الاستجابة لاحتياجات أنواع مختلفة من المستخدمين متاحة الآن ، وإن كان ذلك على مستوى البحث ، وليس المستوى التجاري (Egan 1988). يشير الغضب الحالي لأنظمة دعم الأداء إلى تطوير مكثف لهذه الأنظمة في السنوات القادمة.
أخطاء لا مفر منها
أخيرًا ، يجب إدراك أن المستخدمين يرتكبون أخطاء عند استخدام الأنظمة ، بغض النظر عن مستوى مهارتهم أو جودة النظام. دراسة ألمانية حديثة أجراها Broadbeck et al. (1993) أن ما لا يقل عن 10٪ من الوقت الذي يقضيه العمال ذوو الياقات البيضاء في العمل على أجهزة الكمبيوتر مرتبط بإدارة الأخطاء. أحد أسباب الأخطاء هو اعتماد المستخدمين على التصحيح بدلاً من استراتيجيات الوقاية (ريد 1982). يفضل المستخدمون التصرف بسرعة وتكبد الأخطاء التي يجب عليهم تصحيحها لاحقًا ، والعمل بشكل أبطأ وتجنب الأخطاء. من الضروري أن تؤخذ هذه الاعتبارات في الاعتبار عند تصميم واجهات بين الإنسان والحاسوب. بالإضافة إلى ذلك ، يجب أن تكون الأنظمة متسامحة مع الأخطاء ويجب أن تتضمن إدارة فعالة للأخطاء (Lewis and Norman 1986).
تحليل الاحتياجات
يعد تحليل الاحتياجات جزءًا واضحًا من دورة تطوير روبرت وفيست (1992) ، وهو يتوافق مع تحليل Nielsen الوظيفي ويتم دمجه في المراحل الأخرى (تحليل المهمة أو المستخدم أو الاحتياجات) التي وصفها مؤلفون آخرون. وهو يتألف من تحديد وتحليل وتنظيم جميع الاحتياجات التي يمكن أن يلبيها نظام الكمبيوتر. يتم تحديد الميزات المراد إضافتها إلى النظام أثناء هذه العملية. يجب أن يساعد تحليل المهام والمستخدم ، المعروض أعلاه ، في تحديد العديد من الاحتياجات ، ولكن قد يثبت أنه غير مناسب لتحديد الاحتياجات الجديدة الناتجة عن إدخال تقنيات جديدة أو لوائح جديدة (على سبيل المثال ، السلامة). تحليل الاحتياجات يملأ هذا الفراغ.
يتم إجراء تحليل الاحتياجات بنفس طريقة التحليل الوظيفي للمنتجات. يتطلب مشاركة مجموعة من الأشخاص المهتمين بالمنتج ويمتلكون تدريبًا تكميليًا أو مهنًا أو خبرة عملية. يمكن أن يشمل ذلك المستخدمين المستقبليين للنظام ، والمشرفين ، وخبراء المجال ، وعند الاقتضاء ، المتخصصين في التدريب وتنظيم العمل والسلامة. يمكن أيضًا مراجعة الأدبيات العلمية والتقنية في مجال التطبيق ذي الصلة ، من أجل تحديد الحالة الحالية للفن. يمكن أيضًا دراسة الأنظمة التنافسية المستخدمة في المجالات المماثلة أو ذات الصلة. يتم بعد ذلك تصنيف الاحتياجات المختلفة التي حددها هذا التحليل ووزنها وتقديمها في شكل مناسب للاستخدام طوال دورة التطوير.
النماذج
تعد النماذج الأولية جزءًا من دورة التطوير لمعظم الواجهات وتتكون من إنتاج ورقة أولية أو نموذج إلكتروني (أو نموذج أولي) للواجهة. تتوفر العديد من الكتب حول دور النماذج الأولية في التفاعل بين الإنسان والحاسوب (Wilson and Rosenberg 1988؛ Hartson and Smith 1991؛ Preece et al. 1994).
النماذج الأولية لا غنى عنها تقريبًا للأسباب التالية:
- يواجه المستخدمون صعوبة في تقييم الواجهات على أساس المواصفات الوظيفية - وصف الواجهة بعيد جدًا عن الواجهة الحقيقية ، والتقييم مجرد للغاية. تعتبر النماذج الأولية مفيدة لأنها تتيح للمستخدمين رؤية الواجهة واستخدامها وتقييم فائدتها وقابليتها للاستخدام بشكل مباشر.
- من المستحيل عمليا إنشاء واجهة مناسبة في المحاولة الأولى. يجب اختبار الواجهات من قبل المستخدمين وتعديلها ، في كثير من الأحيان بشكل متكرر. للتغلب على هذه المشكلة ، يتم إنتاج وتنقيح الورق أو النماذج الأولية التفاعلية التي يمكن اختبارها أو تعديلها أو رفضها حتى يتم الحصول على نسخة مرضية. هذه العملية أقل تكلفة بكثير من العمل على واجهات حقيقية.
من وجهة نظر فريق التطوير ، تتمتع النماذج الأولية بالعديد من المزايا. تسمح النماذج الأولية بدمج عناصر الواجهة وتصورها في وقت مبكر من دورة التصميم ، وتحديد سريع للمشاكل التفصيلية ، وإنتاج موضوع محدد ومشترك للمناقشة في فريق التطوير وأثناء المناقشات مع العملاء ، وتوضيح بسيط للحلول البديلة للأغراض المقارنة والتقييم الداخلي للواجهة. ومع ذلك ، فإن الميزة الأكثر أهمية هي إمكانية قيام المستخدمين بتقييم النماذج الأولية.
تتوفر أدوات برمجية غير مكلفة وقوية للغاية لإنتاج النماذج الأولية تجاريًا لمجموعة متنوعة من الأنظمة الأساسية ، بما في ذلك أجهزة الكمبيوتر الصغيرة (على سبيل المثال ، Visual Basic و Visual C ++ (™ Microsoft Corp.) ، UIM / X (™ Visual Edge Software) ، HyperCard (™) Apple Computer) ، SVT (™ SVT Soft Inc.)). متوفرة بسهولة ويسهل تعلمها نسبيًا ، فقد أصبحت منتشرة بين مطوري النظام والمقيمين.
أدى دمج النماذج الأولية إلى تغيير عملية تطوير الواجهة تمامًا. نظرًا للسرعة والمرونة التي يمكن بها إنتاج النماذج الأولية ، يميل المطورون الآن إلى تقليل تحليلاتهم الأولية للمهام والمستخدمين والاحتياجات ، وتعويض أوجه القصور التحليلية هذه من خلال اعتماد دورات تقييم أطول. يفترض هذا أن اختبار قابلية الاستخدام سيحدد المشكلات وأنه سيكون أكثر اقتصادا لإطالة أمد التقييم بدلاً من قضاء الوقت في التحليل الأولي.
تقييم الواجهات
يعد تقييم المستخدم للواجهات طريقة فعالة لا غنى عنها لتحسين فائدة الواجهات وقابليتها للاستخدام (Nielsen 1993). يتم تقييم الواجهة دائمًا تقريبًا في شكل إلكتروني ، على الرغم من إمكانية اختبار النماذج الأولية الورقية أيضًا. التقييم هو عملية تكرارية وهو جزء من دورة تعديل تقييم النموذج الأولي التي تستمر حتى يتم الحكم على الواجهة بأنها مقبولة. قد يكون من الضروري إجراء عدة دورات من التقييم. يمكن إجراء التقييم في مكان العمل أو في مختبرات قابلية الاستخدام (انظر الإصدار الخاص من السلوك وتقنية المعلومات (1994) للحصول على وصف للعديد من مختبرات الاستخدام).
بعض طرق تقييم الواجهة لا تشمل المستخدمين ؛ يمكن استخدامها كمكمل لتقييم المستخدم (Karat 1988 ؛ Nielsen 1993 ؛ Nielsen and Mack 1994). من الأمثلة الشائعة نسبيًا على هذه الأساليب استخدام معايير مثل التوافق والاتساق والوضوح البصري والتحكم الصريح والمرونة وعبء العمل العقلي وجودة التغذية الراجعة وجودة المساعدة وأنظمة معالجة الأخطاء. للحصول على تعريف مفصل لهذه المعايير ، انظر Bastien and Scapin (1993) ؛ كما أنها تشكل أساس استبيان مريح على الواجهات (Shneiderman 1987 ؛ Ravden and Johnson 1989).
بعد التقييم ، يجب إيجاد حلول للمشاكل التي تم تحديدها ، والتعديلات التي تم مناقشتها وتنفيذها ، واتخاذ القرارات بشأن ما إذا كان النموذج الأولي الجديد ضروريًا.
وفي الختام
سلطت هذه المناقشة حول تطوير الواجهة الضوء على المخاطر الرئيسية والاتجاهات العامة في مجال التفاعل بين الإنسان والحاسوب. باختصار ، (أ) يلعب تحليل المهمة والمستخدم والاحتياجات دورًا أساسيًا في فهم متطلبات النظام ، وبالتالي ، ميزات الواجهة الضرورية ؛ و (ب) النماذج الأولية وتقييم المستخدم لا غنى عنهما لتحديد قابلية استخدام الواجهة. توجد مجموعة رائعة من المعرفة ، تتكون من مبادئ وإرشادات ومعايير تصميم ، حول التفاعلات بين الإنسان والحاسوب. ومع ذلك ، من المستحيل حاليًا إنتاج واجهة مناسبة في المحاولة الأولى. وهذا يشكل تحديا كبيرا للسنوات القادمة. يجب إنشاء روابط أكثر وضوحًا ومباشرة ورسمية بين التحليل (المهمة والمستخدمين والاحتياجات والسياق) وتصميم الواجهة. يجب أيضًا تطوير الوسائل لتطبيق المعرفة المريحة الحالية بشكل مباشر وأكثر بساطة على تصميم الواجهات.