تصميم سهولة الاستخدام
يتم تحديد سهولة استخدام أي تطبيق بشكل أساسي من قبل المستخدم. يعد تصميم الواجهة عملية متكررة؛ عند تصميم واجهة لأحد التطبيقات، فمن النادر الحصول على واجهة مثالية منذ الخطوة الأولى. كلما شارك المستخدمون مبكرًا في عملية التصميم، قل الجهد المبذول لإنشاء واجهة أفضل وأكثر قابلية للاستخدام.
ما هي الواجهة الجيدة
عند تصميم واجهة مستخدم، من الجيد أن تبدأ بالنظر إلى بعض التطبيقات الأكثر مبيعًا من Microsoft أو الشركات الأخرى. ففي نهاية المطاف، لن يتم بيع التطبيق ذو الواجهة الضعيفة بشكل جيد. ستجد العديد من الأشياء الشائعة، مثل أشرطة الأدوات، وأشرطة الحالة، وتلميحات الأدوات، وقوائم السياق، ومربعات حوار العلامات. ليس من قبيل الصدفة أن Visual Basic لديه القدرة على إضافة كل هذه الأشياء إلى التطبيق.
يمكنك أيضًا الاعتماد على تجربتك الخاصة في استخدام البرنامج. فكر في بعض التطبيقات التي استخدمتها، وما الذي نجح، وما الذي لم ينجح، وكيف يمكنك تعديله. لكن تذكر أن التفضيلات الشخصية لا تساوي تفضيلات المستخدم، ويجب عليك مواءمة آرائك الخاصة مع آراء المستخدمين.
لاحظ أيضًا أن معظم التطبيقات الناجحة توفر خيارات لاستيعاب تفضيلات المستخدم المختلفة. على سبيل المثال، يسمح Microsoft Windows Explorer للمستخدمين بنسخ الملفات من خلال القوائم أو أوامر لوحة المفاتيح أو السحب والإفلات. سيؤدي توفير الخيارات إلى توسيع نطاق جاذبية التطبيق، ويجب على الأقل إتاحة الوصول إلى جميع الوظائف عن طريق الماوس ولوحة المفاتيح.
إرشادات واجهة Windows
الميزة الرئيسية لنظام التشغيل Windows هي أنه يوفر واجهة مشتركة لجميع التطبيقات. يمكن للمستخدمين الذين يعرفون كيفية استخدام التطبيقات المستندة إلى Windows أن يتعلموا بسهولة كيفية استخدام التطبيقات الأخرى. من الصعب فهم التطبيقات التي تنحرف كثيرًا عن إرشادات الواجهة المحددة.
تعد القوائم مثالًا جيدًا على ذلك - فمعظم التطبيقات المستندة إلى Windows تتبع هذا المعيار: قائمة "ملف" في أقصى اليسار، ثم "تحرير" و"أدوات" وقوائم اختيارية أخرى، وقائمة "ملف" في أقصى اليمين قائمة المساعدة ". إذا كانت المستندات أفضل من الملف، أو يجب وضع قائمة التعليمات أولاً، فسيكون الأمر يستحق المناقشة. لا يوجد ما يمنعك من القيام بذلك، ولكن القيام بذلك يمكن أن يربك المستخدمين ويقلل من سهولة استخدام التطبيق الخاص بك. يتعين على المستخدمين التوقف والتفكير في كل مرة يقومون فيها بالتبديل بين التطبيقات والبرامج الأخرى.
موقع القوائم الفرعية مهم أيضًا. يتوقع المستخدمون العثور على قوائم فرعية مثل "نسخ" و"قص" و"لصق" ضمن قائمة "تحرير"، لكن نقلها ضمن قائمة "ملف" سيسبب ارتباكًا للمستخدمين. لا تحيد كثيرًا عن الإرشادات التي تم إنشاؤها ما لم يكن هناك سبب وجيه للقيام بذلك.
اختبار سهولة الاستخدام
أفضل طريقة لاختبار سهولة استخدام واجهتك هي إشراك المستخدمين في عملية التصميم. سواء كنت تصمم تطبيقًا كبيرًا ومضغوطًا أو تطبيقًا صغيرًا ومحدود الاستخدام، فيجب أن تكون عملية التصميم هي نفسها تمامًا. باستخدام إرشادات التصميم التي تم إنشاؤها، يجب أن يبدأ تصميم الواجهة على الورق.
الخطوة التالية هي إنشاء نموذج أولي واحد أو أكثر وتصميم النموذج في Visual Basic. لا تزال بحاجة إلى إضافة تعليمات برمجية كافية لبدء النموذج الأولي: عرض النموذج، وملء مربع القائمة ببيانات نموذجية، وما إلى ذلك. ثم الاستعداد لاختبار قابلية الاستخدام.
يمكن أن يكون اختبار قابلية الاستخدام عملية غير رسمية لمراجعة التصميم مع المستخدمين، أو يمكن أن يكون عملية رسمية في مختبر قابلية الاستخدام الذي تم إنشاؤه. الغرض من كلتا الطريقتين هو نفسه: التعلم بشكل مباشر من المستخدمين حول ما يعمل بشكل جيد وما يحتاج إلى تحسين. اترك المستخدمين مع التطبيق، ولاحظهم، وهذا الأسلوب أكثر فعالية من سؤال المستخدمين. اطلب من المستخدمين التعبير عن عملية تفكيرهم أثناء محاولتهم إكمال سلسلة من المهام: "أريد فتح مستند جديد، لذلك أبحث عنه في القائمة ملف." لاحظ أن تصميم الواجهة لا يعكس عملية تفكيرهم. قم بالاختبار مع أنواع مختلفة من المستخدمين، إذا وجدت أن المستخدمين يواجهون صعوبة في إكمال مهمة معينة، فقد تحتاج هذه المهمة إلى مزيد من الاهتمام.
بعد ذلك، قم بمراجعة السجلات وفكر في كيفية تعديل الواجهة لجعلها أكثر قابلية للاستخدام. قم بتعديل الواجهة واختبارها مرة أخرى. بمجرد أن تشعر بالرضا عن سهولة استخدام التطبيق، فأنت جاهز لبدء البرمجة. الاختبار مطلوب أيضًا من وقت لآخر أثناء عملية التطوير للتأكد من صحة الافتراضات حول النموذج الأولي.
إمكانية اكتشاف الميزة
المفهوم الرئيسي في اختبار قابلية الاستخدام هو قابلية الاكتشاف. إذا لم يتمكن المستخدمون من معرفة كيفية استخدام إحدى الميزات (أو حتى لا يعرفون بوجودها)، فمن غير المرجح أن يتم استخدامها. على سبيل المثال، لم يعرف معظم مستخدمي Windows 3.1 مطلقًا أنه يمكن استخدام مجموعة المفاتيح ALT وTAB للتبديل بين التطبيقات المفتوحة. لا يوجد أي مكان في الواجهة يتم توفير أدلة لمساعدة المستخدمين على اكتشاف هذه الميزة.
لاختبار إمكانية اكتشاف الوظائف، اطلب من المستخدمين إكمال مهمة دون شرح كيفية القيام بذلك (على سبيل المثال، إنشاء مستند جديد باستخدام "قالب نموذج"). إذا لم يتمكنوا من إكمال المهمة، أو استغرق الأمر عدة محاولات، فيجب تحسين إمكانية اكتشاف هذه الميزة.
التفاعل مع المستخدمين عندما يحدث خطأ ما معهم أو بالنظام
في عالم مثالي، ستعمل البرامج والأجهزة دائمًا دون أي خلل، ولن يرتكب المستخدمون أي أخطاء أبدًا. في الواقع، الأخطاء أمر لا مفر منه. يعد تحديد كيفية استجابة تطبيقك عندما تسوء الأمور جزءًا من تصميم واجهة المستخدم.
الاستجابة الشائعة هي عرض مربع حوار يطلب من المستخدم إدخال كيفية تعامل التطبيق مع المشكلة. الاستجابة الأقل شيوعًا (ولكنها الأفضل) هي حل المشكلة ببساطة دون إزعاج المستخدم. بعد كل شيء، يهتم المستخدمون في المقام الأول بإكمال المهام، وليس التفاصيل الفنية. عند تصميم واجهة مستخدم، ضع في اعتبارك الأخطاء المحتملة وحدد الأخطاء التي تتطلب تفاعل المستخدم وتلك التي يمكن حلها باستخدام حلول مرتبة مسبقًا.
إنشاء مربعات حوار سهلة الفهم
في بعض الأحيان يحدث خطأ في أحد التطبيقات ويتطلب الأمر اتخاذ قرار لحل الموقف. يحدث هذا عادةً كفرع من التعليمات البرمجية - عبارة If...Then أو عبارة Case. إذا كان هذا الحكم يتطلب تفاعل المستخدم، فعادةً ما يتم عرض هذه المشكلة للمستخدم باستخدام مربع حوار. تعد مربعات الحوار جزءًا من واجهة المستخدم، ومثل الأجزاء الأخرى من الواجهة، يلعب تصميمها دورًا في سهولة استخدام التطبيق.
في بعض الأحيان يبدو الأمر وكأن العديد من مصممي مربعات حوار البرنامج لا يتحدثون بكلمات تسهل على الأشخاص فهمها. على سبيل المثال، رسالة مثل هذه: "قطاع القرص الصلب C تالف أو لا يمكن الوصول إليه. هل تريد الإجهاض، إعادة المحاولة، التجاهل؟" (انظر الشكل 6.22) هذا ليس من السهل فهمه بالنسبة للمستخدمين العاديين. وهذا يعادل سؤال النادل للعميل: "ليس لدينا حساء أو المطبخ يشعل النار، توقف، حاول مرة أخرى، تجاهل؟" من المهم وصف المشكلة (والاختيار) بطريقة أو عبارة يمكن للمستخدمين فهمها. في المثال السابق، ستكون الرسالة الأفضل هي "توجد مشكلة في حفظ الملف على محرك الأقراص C. الرجاء حفظ الملف على محرك الأقراص A. هل تريد حفظ الملف؟"
عند إنشاء مربعات حوار لتطبيقك، ضع المستخدم في الاعتبار. هل تنقل هذه الرسالة معلومات مفيدة للمستخدم؟ هل من السهل أن نفهم؟ هل الاختيارات التي تمثلها أزرار الأوامر واضحة؟ هل هذا الاختيار مناسب للظروف المذكورة؟ تذكر أن مجرد مربع رسالة مزعج واحد يمكن أن يعطي المستخدمين انطباعًا سيئًا عن تطبيقك.
إذا كنت تقوم بتصميم مربع حوار مخصص، فحاول الالتزام بالأنواع القياسية. إذا انحرف كثيرًا عن تخطيط مربع الرسالة القياسي، فقد لا يتعرف عليه المستخدمون كمربع حوار.
لمزيد من المعلومات حول مربعات الحوار، راجع "مربعات الحوار" سابقًا في هذا الفصل.
معالجة الأخطاء بدون مربع حوار
ليس من الضروري مقاطعة المستخدم عند حدوث خطأ. في بعض الأحيان يفضل معالجة الأخطاء في التعليمات البرمجية دون إشعار المستخدم، أو تنبيه المستخدم بطريقة لا توقف سير عمل المستخدم. ومن الأمثلة الجيدة على هذه التقنية ميزة "التصحيح التلقائي" في Microsoft Word: إذا كانت هناك خطأ إملائي في كلمة شائعة، يقوم Word بتصحيحها تلقائيًا؛ وإذا كانت هناك خطأ إملائي في كلمة غير شائعة، يتم رسم خط أحمر تحتها لتذكير المستخدم بتصحيحها لاحقًا .
هناك عدد كبير من التقنيات المتاحة، الأمر متروك لك لتحديد التقنيات المناسبة لتطبيقك. فيما يلي بعض الاقتراحات:
1. أضف وظيفة "تراجع" في قائمة "تحرير". بالنسبة لمواقف مثل الحذف، بدلاً من مقاطعة المستخدم بمربع حوار "موافق"، يمكنك التأكد من أنه اتخذ القرار الصحيح وتوفير ميزة "التراجع" في حالة تغيير رأيه لاحقًا.
2. عرض الرسالة على شريط الحالة أو الرمز. إذا لم يؤثر الخطأ على المهمة الحالية للمستخدم، فلا تقم بإيقاف التطبيق. استخدم شريط الحالة أو رمز التحذير الساطع لتنبيه المستخدمين بأنه يمكنهم التعامل مع المشكلة عندما يكونون جاهزين.
3. قم بتصحيح المشكلة. في بعض الأحيان يكون الحل الخاطئ واضحًا. على سبيل المثال، إذا كان القرص ممتلئًا عندما يحاول المستخدم حفظ ملف، يقوم النظام بفحص محركات الأقراص الأخرى بحثًا عن المساحة. إذا توفرت مساحة، فسيتم حفظ الملف، ويتم عرض رسالة في شريط الحالة تخبر المستخدم بما تم.
4. احفظ الرسالة وانتظر المعالجة. نظرًا لأن الأخطاء ليست كلها خطيرة أو تتطلب اهتمامًا فوريًا؛ فكر في تسجيلها في ملف وعرضها للمستخدم عند الخروج من التطبيق أو في وقت آخر مناسب. إذا ارتكب المستخدم خطأ في الإدخال (على سبيل المثال، كتابة MainSt. بدلاً من MianSt.)، فقم بتسجيله. أضف زر "ReviewEntries" ووظيفة تعرض الاختلافات حتى يتمكن المستخدمون من تصحيحها.
5. لا تفعل أي شيء. في بعض الأحيان لا يكون الخطأ مهمًا بدرجة كافية لتبرير التحذير. على سبيل المثال، حقيقة أن الورق غير جاهز للطابعة على LPT1 لا يهم كثيرًا حتى يصبح جاهزًا للطباعة. انتظر حتى تصبح الرسالة ذات صلة بالمهمة الحالية.
لمزيد من المعلومات حول تقنيات معالجة الأخطاء، راجع الفصل 13، "تصحيح الأخطاء البرمجية ومعالجة الأخطاء".
تصميم أنماط مساعدة المستخدم
بغض النظر عن مدى جودة تصميم واجهة المستخدم، سيحتاج المستخدمون في بعض الأحيان إلى المساعدة. يتضمن وضع مساعدة المستخدم للتطبيق أشياء مثل المساعدة عبر الإنترنت والوثائق المطبوعة؛ ويمكن أن يتضمن أيضًا أجهزة مساعدة المستخدم مثل تلميحات الأدوات، وأشرطة الحالة، ومساعدة "ما هذا"، والمعالجات.
مثل أي جزء آخر من التطبيق، يجب أن يسبق تصميم نمط مساعدة المستخدم التطوير. سيختلف محتوى المخطط اعتمادًا على مدى تعقيد التطبيق والجمهور المستهدف.
المساعدة والوثائق
تعد التعليمات عبر الإنترنت جزءًا مهمًا من أي تطبيق وغالبًا ما تكون أول مكان يلجأ إليه المستخدمون عندما تكون لديهم أسئلة. حتى التطبيقات البسيطة يجب أن توفر "المساعدة". إن عدم تقديمه يشبه افتراض أن المستخدمين لن يواجهوا مشكلة أبدًا.
عند تصميم نظام المساعدة، تذكر أن الغرض الأساسي منه هو الإجابة على الأسئلة. حاول استخدام مصطلحات المستخدم عند إنشاء أسماء المواضيع وإدخالات الفهرس، على سبيل المثال، "كيف أقوم بتنسيق صفحة؟" يسهل العثور على المواضيع من قوائم "تحرير" أو "تنسيق الصفحة". لا تنس السياق؛ سيشعر معظم المستخدمين بالإحباط إذا ضغطوا على المفتاح F1 للحصول على مساعدة في حقل معين فقط ليجدوا أنفسهم في موضوع المحتوى.
يعد توثيق المفاهيم الأساسية، سواء كان مطبوعًا و/أو مقدمًا على قرص مضغوط، مفيدًا للجميع باستثناء التطبيقات البسيطة. يمكن أن يوفر معلومات يصعب نقلها باستخدام موضوع تعليمات قصير. على أقل تقدير، يجب أن يكون هناك مستند في نموذج الملف التمهيدي الذي يمكن للمستخدم طباعته إذا لزم الأمر.
جهاز مساعد للمستخدم
في واجهات المستخدم، هناك العديد من التقنيات التي تساعد المستخدمين. من السهل إضافة تلميحات الأدوات وتعليمات "ما هذا" وعروض الحالة والمعالجات إلى تطبيقاتك باستخدام Visual Basic. الأمر متروك لك لتحديد أي من هذه الأجهزة مناسب لتطبيقك الخاص.
تلميح الأدوات
تعد تلميحات الأدوات (الشكل 6.23) طريقة رائعة لعرض المعلومات للمستخدمين أثناء بحثهم على واجهة المستخدم. تلميح الأداة عبارة عن تسمية صغيرة تظهر عندما يستقر مؤشر الماوس على عنصر التحكم وعادةً ما يحتوي على وصف لوظيفة عنصر التحكم. يتم عادةً استخدام تلميحات الأدوات مع أشرطة الأدوات، وهي تعمل بشكل جيد في معظم أجزاء الواجهة.
تشتمل معظم عناصر تحكم Visual Basic على خاصية تُستخدم لعرض تلميحات الأدوات: ToolTipText. سيوفر التعليمة البرمجية التالية تلميح أداة لزر أمر يسمى "cmdPRint".
cmdPrint.ToolTipText=Printsthecurrentdocument
كما هو الحال مع الأجزاء الأخرى من الواجهة، تأكد من أن هذا النص ينقل الرسالة بوضوح إلى المستخدم.
لمزيد من المعلومات حول تلميحات الأدوات، راجع "خاصية ToolTipText" في مرجع اللغة.
"ما هذا" مساعدة
عندما يحدد المستخدم ما هي المساعدة وينقر فوق ما هو المؤشر في عنصر التحكم، توفر ما هي المساعدة رابطًا لموضوع التعليمات المنبثق (انظر الشكل 6.24). يمكن تشغيل تعليمات "ما هذا" من زر شريط أدوات أو عنصر قائمة أو زر موجود على شريط عنوان مربع الحوار.
لتمكين مساعدة "ما هذا" من القائمة أو شريط الأدوات، اتبع الخطوات التالية:
1. حدد عنصر التحكم الذي تريد مساعدته.
2. في نافذة الخصائص، حدد خاصية WhatsThisHelpID.
3. أدخل معرف السياق لموضوع التعليمات المنبثق ذي الصلة.
4. كرر الخطوات من 1 إلى 3 لأي عناصر تحكم أخرى.
5. حدد النموذج.
6. في نافذة "الخصائص"، قم بتعيين خاصية WhatsThisHelp الخاصة بالنموذج إلى True.
7. في حدث النقر على زر القائمة أو شريط الأدوات، اكتب الكود التالي:
اسم النموذج.WhatsThisHelp
عندما يقوم المستخدم بالنقر فوق الزر أو القائمة، يتغير مؤشر الماوس إلى مؤشر التعليمات "ما هذا". لتمكين المساعدة "ما هذا" على شريط عنوان نموذج حوار مخصص، قم بتعيين خصائص WhatsThisButton وWhatsThisHelp للنموذج إلى True.
لمزيد من المعلومات حول مساعدة "WhatsThis"، راجع "خاصية WhatsThisHelp" و"خاصية WhatsThisButton" في مرجع اللغة.
عرض الحالة
يمكن أيضًا استخدام شاشات الحالة لتقديم المساعدة للمستخدم بنفس طريقة استخدام تلميحات الأدوات. تُعد شاشات الحالة طريقة رائعة لتوفير الإرشادات أو الرسائل التي قد لا تكون مناسبة لتلميحات الأدوات. يمكن لعنصر تحكم شريط الحالة المضمن في إصدارات Professional وEnterprise من Visual Basic عرض الرسائل بشكل جيد جدًا؛ ويمكن أيضًا استخدام عنصر تحكم التسمية كعرض للحالة.
يمكن تحديث النص المعروض في شاشة عرض الحالة بإحدى طريقتين: استخدام عنصر التحكم أو الحدث GotFocus الخاص بالنموذج، أو استخدام الحدث MouseMove. إذا كنت تريد استخدام شاشة العرض كجهاز تعليمي، أضف عنصرًا إلى القائمة "تعليمات" للتبديل بين تشغيل وإيقاف الخاصية المرئية.
لإضافة عرض الحالة، اتبع الخطوات التالية:
1. أضف عنصر تحكم التسمية إلى النموذج.
2. حدد عنصر التحكم الذي تريد عرض رسالة له.
3. أضف التعليمة البرمجية التالية في حدث MouseMove (أو GotFocus) لعنصر التحكم: Labelname.Caption=Enterthecustomer'sIDnumberinthisfield عندما يتحرك الماوس فوق عنصر التحكم، سيتم عرض هذه الرسالة في عنصر تحكم التسمية هذا.
4. كرر الخطوات من 2 إلى 3 لأي عناصر تحكم أخرى.
معالج
المعالج هو جهاز مدعوم من قبل المستخدم يرشدك خلال تنفيذ العملية خطوة بخطوة باستخدام بياناتك الفعلية. غالبًا ما يتم استخدام المعالجات لتقديم المساعدة الخاصة بالمهام. فهي تساعد في المهام التي تتطلب عملية تعليمية طويلة (ومزعجة)، وتوفر معلومات متخصصة للمستخدمين الذين لم يصبحوا خبراء بعد.
تتضمن إصدارات Professional وEnterprise من Visual Basic أداة لإنشاء المعالجات: Wizard Manager.
للحصول على تفاصيل حول المعالج، الرجاء الرجوع إلى "استخدام المعالجات والوظائف الإضافية" في الفصل الرابع "إدارة المشاريع".
->