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

تستند هذه المقالة بالكامل تقريبًا إلى اقتباسات من كتاب جيف راسكين " الواجهة - اتجاهات جديدة في تصميم أنظمة الكمبيوتر " مع إضافاتي وإعادة صياغتي لمثال الواجهة الواردة في الكتاب.



إجابة سريعة على السؤال حول ما إذا كان من المفيد استخدام تحليل GOMS لاختبار قابلية الاستخدام: "إذا كنت تصمم واجهة ، فعند العمل بها من تأخير قدره 0.3 ثانية. لا أحد يموت - لا يستحق كل هذا العناء ".



لذا ، فإن "نموذج الأهداف ، والكائنات ، والطرق ، وقواعد الاختيار" (GOMS) هي طريقة بحث واجهة طورها Card و Moran و Newell في الثمانينيات. يتوقع GOMS المدة التي سيستغرقها مستخدم متمرس لإكمال عملية معينة باستخدام واجهة محددة.



الآن بعد أن اعتدنا على هذا المصطلح ، غريب بالنسبة للأذن الروسية ، يمكننا وصف جوهره.



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

إيماءات جومس والتوقيت

1. H (نقل اليد إلى الماوس) = 0.4 ثانية
2. K (الضغط على لوحة المفاتيح أو مفتاح الماوس) = 0.2 ثانية
3. ف (تحريك المؤشر إلى الموضع الموجود على الشاشة) = 1.1 ثانية
4. م (التفكير في الخطوة التالية) = 1.35 ثانية
5. R (انتظار استجابة من النظام) - يعتمد الوقت على سرعة نظام معين ولا يشارك في الحسابات.

في عمليات حسابية أخرى ، سيتم استبدال الإيماءات بأحرف من القائمة أعلاه وسيطلق عليها "المشغلون".



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

قواعد تعيين المشغل

• 0. M
  
  M K ( ), P ( ), (, ); P, (, ), M .
• 1. M
  
  , M, , M, M . , , M, 0.
• 2. M
  
  M K M K M K… , M, . , «4564.23» « ».
  
  
• 3. M
  
  K , (, « — »), M, .
• 4. M,
  
  K , (, , ), M, . , M. K , M .
• 5. M
  
  M, R, , , .

معطى:



يُطلب من المستخدم تحويل درجة الحرارة من فهرنهايت إلى درجة مئوية أو العكس. على سبيل المثال ، قد يسألون: "حوّل 3.5 درجة فهرنهايت إلى درجات مئوية". يمكن للمستخدم إدخال قيمة درجة الحرارة فقط باستخدام لوحة المفاتيح أو الماوس.



الهدف:

تصميم واجهة يكون فيها الوقت اللازم لترجمة قيم درجة الحرارة ضئيلاً.



الشروط

للتبسيط ، سنفترض أن المستخدم أدخل حرفين كحد أقصى وأن المستخدم لا يخطئ.



هام : تستخدم الأمثلة أدناه بدقة لتوضيح القواعد الموضحة في الكتاب. يمكن حل هذه المشكلة بطرق أخرى ، ربما تكون أفضل.

القرار. الخيار 1

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

دفع

H (يد على الماوس) + M (فكر) + P (حرك المؤشر إلى مجموعة الراديو) + K (نقر) + M (فكر) + P (المؤشر إلى الحقل) + K (نقر) + H (حرك اليد من الماوس إلى لوحة المفاتيح) + M (فكر) + K (أدخل الرقم الأول) + M (فكر) + K (أدخل الرقم الثاني).



وفقًا للقاعدة 2 ، نقوم بإزالة M الإضافية ونحصل على:

H + M + P + K + M + P + K + H + M + K + K



إذا كان اتجاه تحويل درجة الحرارة غير مناسب ، فإننا نحصل على:

0.4 + 1.35 + 1.1 + 0.2 + 1.35 + 1.1 + 0.2 + 0.4 + 1.35 + 0.2 + 0.2 = 7.85 ثانية



إذا تم اختيار اتجاه مناسب لتحويل درجة الحرارة ، فإننا نحصل على:

0.4 + 1.35 + 1.1 + 0.2 + 1.35 + 0.2 + 0.2 = 4.8 ثانية

القرار. الخيار 2

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

دفع

H (0.4) + M (1.35) + P (1.1) + K (0.2) + P (1.1) = 4.15 ثانية



خيار التنفيذ هذا هو 0.65 "أكثر قابلية للاستخدام" من الأول ثانية.

خطأ في الأسلوب

يكتب راسكين أنه باستخدام هذه الطريقة ، من الممكن توقع المدة التي سيحتاجها المستخدم لمهامه بخطأ مطلق أقل من 5٪ .



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

رأيي في تحليل جومس

عندما اكتشفت ذلك لأول مرة ، أردت البدء في استخدامه على الفور في جميع مشاريعي. بدا لي أن هذا هو - التخلص من العذاب القديم المتمثل في اختيار "الطريق الصحيح". بدون الذاتية والاتجاهات. الرياضيات الحقيقية "الغبية". ولكن في الواقع ، لوصف أكثر الواجهة بدائية ، تحتاج إلى قضاء ضعف الوقت الذي تستغرقه في تصميمها. وبعد ذلك لا يزال يتعين عليك تصميم بديل لحسابه. وحتى إذا اكتشفت في النهاية الخيار الأفضل ، فقد اتضح أنه أفضل بمقدار 0.65 ثانية. أخذ 3-4 ساعات للفوز 0.65 ثانية أمر قوي.

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



يكتب راسكين شيئًا مثل هذا:

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

ملاحظة

هناك أيضًا تعديلات على تحليل GOMS. على سبيل المثال ، "Critical-path method GOMS" (CPM-GOMS) وإصدار يسمى لغة GOMS الطبيعية (NGOMSL) ، والذي يأخذ في الاعتبار سلوك مستخدم عديم الخبرة ، على سبيل المثال ، الوقت الذي يستغرقه التعلم. يمكنك أن تقرأ عن هذه الإصدارات بنفسك.