المزيد من الشيء نفسه
إذا لم تكن قد سمعت عن نمط واجهة المستخدم من قبل ، فإليك شرحًا سريعًا: كما هو الحال مع معظم الأشياء ، خاصة أثناء تطوير البرامج ، يمكن غالبًا تجميع مجموعة كبيرة من العناصر معًا ، لأنها تشكل نمطًا يمكن التعرف عليه. من الأمثلة على البرامج تعريف الأنماط المعمارية أو الأنماط المتعلقة بلغة برمجة معينة.
ومع ذلك ، هناك أيضًا أنماط شائعة عند تصميم واجهة المستخدم. بمجرد إلقاء نظرة سريعة على بعض التطبيقات على الجهاز الذي تقرأ هذه المقالة عليه ، تتكرر بعض الأشياء في النهاية:
- طرق عرض مشروطة مع إجراء حفظ و / أو إلغاء و / أو حذف
- أقسام من العناصر التي تحتوي على نص ، على سبيل المثال القوائم مع إجراء التمرير السريع لكل عنصر من عناصر القائمة
لذا ، فكر في خطوة أخرى إلى الأمام ، هل هناك أي موارد يمكنك الاستفادة منها عند تصميم واجهة المستخدم بنفسك؟ ربما مجموعة من الأنماط التي اعترف بها المصممون الآخرون بالفعل وجعلوها رسمية؟ حسنًا ، لن أطرح هذا السؤال إذا لم تكن لدي الإجابة بالفعل! حان الوقت للفصل الثاني!
الفصل الثاني (المعلن)
عند البحث عن تعريف رسمي ، فإن فريق التصميم الكربوني في IBM لديه تعريف رائع: الأنماط هي أفضل حلول الممارسة لكيفية تحقيق المستخدم لهدف ما. تُظهر مجموعات قابلة لإعادة الاستخدام من المكونات والقوالب التي تعالج أهداف المستخدم الشائعة من خلال التسلسلات والتدفقات.
دعونا نلقي نظرة على بعض الأمثلة. يتم أخذ الإدخالات التالية من موقع تصميم الكربون لشركة IBM وكذلك صفحة نمط واجهة المستخدم المادية من Google. لم أتمكن من العثور على موقع لـ Fluent Design من Microsoft ، ولكني قمت بربط صفحة البداية الخاصة بهم على الرغم من ذلك في الملحق.
يبحث
يعد البحث عن المحتوى من اللبنات الأساسية الأساسية لمعظم التطبيقات ، وبالتالي فهو خيار مثالي لتحديد نمط واجهة المستخدم له. بغض النظر عن الاستخدام النهائي (سواء كان بحثًا عالميًا أو بحثًا محددًا على صفحة محتوى) ، يجب أن تقدم واجهة مستخدم البحث
- إدخال نص
- عنصر نائب نصي إذا لم يتوفر إدخال بعد
- رمز يشير بوضوح إلى الغرض من إدخال النص ، على سبيل المثال باستخدام عدسة مكبرة ، بالإضافة إلى العمل كمحفز لبحث جديد
في حالات معينة ، يمكن أن تساعد تسمية التلميح في التمييز بين أنواع المحتوى المختلفة أو تقديم المساعدة بشأن الإدخال غير الصحيح. كلما زاد عدد الشروط التي يجب أن يتعامل معها البحث ، كان من الأفضل أن يتكيف البحث مع هذا المطلب عن طريق إضافة قوائم تصفية صريحة.
حوار
أحد أنماط واجهة المستخدم البارزة جدًا. تسمح مربعات الحوار للتطبيق بعرض جزء من المعلومات دون فقد السياق العام للموقع. يتم تحقيق ذلك من خلال عدم تغطية النافذة بأكملها ولكن فقط جزء أصغر. تقاطع مربعات الحوار سير العمل الحالي للمستخدم ، وبالتالي يجب اعتبارها ضرورية فقط عندما يكون التوقف في سير العمل صالحًا بالفعل. يجب أن يتعاملوا فقط مع المهام الصغيرة وأن يكون لديهم تركيز واضح على ما يجب إنجازه. على سبيل المثال ، التراجع عن التغييرات غير المحفوظة أو تنفيذ إجراء مهم.
الدول الفارغة
على الرغم من أنه قد يبدو غريبًا في البداية ، إلا أن الحالات الفارغة شائعة جدًا في التطبيقات. من المهم إبلاغ المستخدم بعدم توفر أي بيانات ، وتوضيح سبب ذلك بشكل مثالي. اعتمادًا على السياق ، يمكن أن يساعد التلميح حول كيفية حل الحالة الفارغة كثيرًا في إنشاء تجربة مستخدم جيدة. على سبيل المثال ، بحث المستخدم عن شيء ما ولكن لم يتمكن من العثور على أي شيء. قد تكون هذه حالة استخدام حيث قد يساعد اقتراح استعلام بحث مختلف المستخدم في إنجاز المهمة. في كل حالة ، يجب أن يكون كل عرض يمثل حالة فارغة سياقيًا. قد يكون المثال السلبي شيئًا مثل "هذا لم ينجح. حاول مرة أخرى في وقت لاحق".
لا تعامل الحالات الفارغة على أنها فكرة متأخرة في عملية تصميم واجهة المستخدم. إذا تم تنفيذها بشكل صحيح ، فإنها تتيح للمستخدمين متابعة سير العمل بسلاسة. الحالات الفارغة التي توقف سير العمل بالكامل هي في الواقع أسوأ سيناريو ، بصرف النظر عن أعطال التطبيق.
مجرد بداية
كانت هذه نظرة سريعة على بعض أنماط واجهة المستخدم التي اخترتها من تصميم الكربون لشركة IBM وكذلك صفحة أنماط واجهة المستخدم المادية. يمكن أن يساعد تطبيق أنماط واجهة المستخدم على تطبيقك أيضًا بشكل كبير في تقليل الاحتكاك بين سير عمل المستخدم وواجهة المستخدم لإنجاز المهمة. قد يكون تصميم واجهة المستخدم أمرًا صعبًا للغاية ، لذا فإن الوقوف على أكتاف العمالقة من خلال التعلم من دراسات تجربة المستخدم الحالية يساعد كثيرًا في تحسين تصور المستخدمين لسلوك تطبيقك.
