البحث في الموقع

سنعرض في هذا المقال تتمّة لمجموعة المتحكمات الخاصّة بواجهة الاستخدام، والتي يحتاج المصمّم لمعرفتها جيّدًا، حيث سنعرض مجموعة من الأدلّة الموجزة عن كل متحكمات الخرج المتمثلة في كل من: التحقّق من صّحّة المدخلات، وأداة التّلميح، والتّنبيه، وجدول البيانات، والأيقونة. دليل موجز عن التحقق من صحة المدخلات (Validation Guidelines) تُستخدَم عملية التّحقّق من صّحّة المدخلات غالبًا بديلًا عن التّنبيهات، وهي طريقةٌ جيّدةٌ لتقديم الملاحظات، أو الإرشادات مع مقاطعةٍ بسيطةٍ للمستخدم. ويشرح كل من مقال إضافة عناصر تحكم واجهة المستخدم وترتيبها Adding and Arranging UI Controls، ومقال عنصر التحكم في التحرير Editing Controls كيفية إضافة متحكم وآلية تحريره، كما يمكنك الاطلاع على طريقة إنشاء الرّموز في تطبيق Balsamiq لتصميم واجهة المستخدم. متى نستخدم التحقق من الصحة نستعيض أحيانًا بلآلية التحقق من صحة المدخلات عن التّنبيهات، أو يستخدمان معًا لعرض رسائل الخطأ، ولا يقتصر عمله على إخبار المستخدمين بالخطأ الذي ارتكبوه فقط بل يستخدم أيضًا لإخبارهم عند قيامهم بعملٍ صحيحٍ، أو ليقترح عليهم أفكارًا للتّحسين (مثل زيادة قوّة كلمة المرور). هدف عملية التّحقّق من الصّحّة غالبًا هو مساعدة المستخدمين على تصحيح الأخطاء أثناء إدخالهم لبيانات مطلوبة؛ وبدلًا من الاعتناء بعرض رسالة خطأ جميلة للمستخدم، يفضَّل وضع إرشادات واضحة تساعد المستخدم على إدخال البيانات بطريقة صحيحة لتقليل عرض الأخطاء له الناتجة عن التحقق من صحة البيانات المدخلة تلك. كيف نستخدم التحقق من الصحة لا يجب عرض أنماط أو رسائل التّحقّق من الأخطاء، إلّا بعد تفاعل المستخدم مع حقلٍ معيّن. يجب التّحقّق من الصّحّة "أثناء التّنقّل (on-the-fly)" قبل إرسال النّموذج، وفي حال عدم تمكّننا من ذلك ينبغي إضافة إشعارٍ لتلخيص التّعليقات في الجزء العلويّ من الصّفحة عند إعادة تحميلها. لا يجب مسح بيانات الإدخال الخاطئة إلا عند عدم تمكّن المستخدم من تصحيح الأخطاء بسهولةٍ، إذ يسمح هذا للمستخدمين بتصحيح الأخطاء دون الحاجة للبدء من جديد. يجب تقديم إرشاداتٍ حول كيفيّة إصلاح الأخطاء، وليس إعلام المستخدمين بالخطأ الذي ارتكبوه وحسب. يجب اتّباع إرشادات الصّوت والنّبرة عند توافرها، وفي حال عدم وجودها يؤمّن الرّابط التّالي أمثلة رائعة عن إرشادات الصّوت، والنّبرة، والمحتوى. الاستخدام الرئيسي الحالات هناك ثلاث حالاتٍ عامّةٌ لمكوّنات التّحقّق الموضّحة أعلاه، وهي: نجاح: تخبر هذه الحالة المستخدمين بصحّة القيم المدخلة أو اختيارهم لقيم محددة، وهي ليست مطلوبةً لكنّها مفيدةٌ للمستخدمين الجدد أو المبتدئين. تحذير: تشير عادةً إلى قبول البيانات المدخلة أو المختارة ولكن يفضل فعل سلوك يوصى به (مثل إدخال كلمة مرور مقبولة ولكن ضعيفة سهلة التخمين). خطأ: أكثر أشكال التّحقّق شيوعًا، وينبّه المستخدمين إلى أنّ البيانات المدخلة غير صحيحة، ويُفضّل اقتراح كيفيّة إصلاح الخطأ. التنوع تختلف مكوّنات التّحقّق أساسيًّا في عرضها أو تصميمها، ويُستخدم اللّون كثيرًا وبطرقٍ مختلفةٍ، ومع ذلك ينبغي أن لا يكون هو المؤشّر الوحيد، فقد لا يميَّز من قبل المستخدمين المصابين بعمى الألوان، وتستخدَم غالبًا إضافةً للنّصّ، أيقونةٌ (و/أو) نصّ مساعدةٍ. دليل موجز عن أداة التلميح (Tooltip Guidelines) أداة التّلميح نوع شائعٌ من أنواع المساعدة التي تلعب دورًا إيجابيًّا عندما يطلب المستخدم بعض التّفاصيل، وهي طريقةٌ رائعةٌ لمساعدة المبتدئين دون إزعاج المستخدمين ذوي الخبرة، إذ يُعدّ عرض اختصارات لوحة المفاتيح عندما يضع المستخدم الفأرة فوق زرّ الإجراء، من حالات أدوات التّلميح التّقليدية، يصف "آلان كوبر" في كتابه أساسيّات تصميم التّفاعل أدوات التّلميح بأنّها "واحدةٌ من أذكى تعابير واجهة المستخدم وأكثرها فاعليّة". متى نستخدم أداة التلميح لا تستخدم أدوات التّلميح عادةً، لذلك عندما نكون غير واثقين من ذلك (يجب استخدامها بطريقة مناسبة عندما تكون تفاصيل التّنفيذ حرجةً)، سنتّحدث لاحقًا في المقالة عن كيفيّة استخدامها. لدى إرشادات منصّة ويندوز قاعدةٌ جيّدةٌ لأدوات التّلميح وهي "لن نحتاج لأداة تلميحٍ إذا كانت المعلومات متاحةً في مكانٍ آخر من الصًفحة نفسها"، هذا يعني أنّ الزّر الذي يحوي أيقونةً ونصًّا لابدّ من عدم احتوائه على أداة تلميحٍ، ولكنّ الزّرّ الذي يحوي أيقونةً فقط يحتاج أداة تلميحٍ كما في الشّكل أدناه. فيما يلي مثالٌ نموذجيٌّ عن أداة تلميح تكون أدوات التّلميح مفيدةً عندما يكون التّفسير المطوّل مفيدًا أيضًا، ولكنها ليست عمليّةً فيما يخصّ مساحة الصّفحة، كما يمكن استخدامها عندما "يستفيد عنصر تحكّمٍ من وصفٍ تكميليٍّ، أو معلوماتٍ إضافيّةً"، ومع ذلك لا ينبغي أبدًا استخدام أدوات التّلميح كبديلٍ عن الأيقونات، أو التّسميات غير الواضحة. وتُعدّ أدوات التّلميح معلوماتٍ تكميليّةً ولا يجب التّعامل معها كوسيلةٍ أساسيّةٍ لمساعدة المستخدمين في فهم النظام، إذ لا تستخدم أدوات التلميح غالبًا في الأجهزة المحمولة، لذا يجب أن لا نعتمد عليها أو نفترض أنّ المستخدم سيقرأها. كيف نستخدم أداة التلميح يجب أن تظهر أدوات التّلميح نتيجةً لتفاعل المستخدم فقط،عوض الظهور بمفردها. يجب إظهار النّصّ العاديّ فقط في أداة التّلميح، ويجب عدم استخدام الصّور أو النّصوص المنسّقة. لا يجب استخدام الخاصية "alt" في لغة "HTML" من أجل أدوات التّلميح، يجب استخدامها فقط كنصٍّ بديلٍ للوصول لغرضٍ ما، ويُفضّل استخدام الخاصية "title" بدلًا منها. يجب التّركيز على العمل الذي يسبّبه عنصر التّحكم، نستخدم فعلًا لنخبر المستخدمين بما سيحدث عند النّقر. يجب أن تكون أدوات التّلميح قصيرةً، وتقترح إرشادات واجهة نظام آبل (Apple) تراوُح الحدّ الأقصى لطول أداة التّلميح بين 60-75 حرفًا. يجب وضع أدوات التّلميح بالقرب من الكائن الذي نتعامل معه، ولكن يجب عدم وضعها بطريقةٍ تتعارض مع ما يفعله المستخدم فيشتّت انتباهه. يجب إضافة أزرارٍ إعلاميّةٍ صغيرةٍ إن كنا نريد استخدام أدوات التّلميح في الهاتف المحمول بواسطة شاشات اللّمس (سنتحدث لاحقًا في المقال عن التّنوع في أدوات التّلميح). تجدر الإشارة هنا إلى أن التّوقيت مهم إذا كان بالإمكان التّحكم فيه، إذ يجب اتّباع الإرشادات التّالية: تأخير بداية التّيت أمر هامّ إذا كان بالإمكان التّحكم فيه، إذ يجب ادم للفأرة، حيث يجب الانتظار حتى يتّوقف المستخدم عن تحريك المؤشّر ثانيةً واحدةً. عرض أداة التّلميح لمدّة عشر ثوانٍ أو إلى حين تّحرك المؤشّر بعيدًا عن عنصر التّحكم. اختفاء أداة التّلميح لأكثر من 150 مللّي ثانية. تحوي معظم أنظمة التّشغيل، وأنظمة العمل على أدوات تلميحٍ مضمّنةً، يمكن استخدامها بدل إنشاء أداةٍ جديدةٍ. الاستخدام الرئيسي الحالات حالات أدوات التّلميح بسيطةٌ، فهي دائمًا تكون إما ظاهرة أي في وضع التّشغيل (On)، أو مخفية أي في وضع الإيقاف (off)، ويجب حدوث الانتقال بين الحالتين -في حال حدوثه- بسرعةٍ (150 مللي ثانية على الأكثر). التنوع تختلف أنماط أدوات التّلميح كثيرًا على الرّغم من محدوديّة اختلافاتها الوظيفيّة، وذلك لتوقّع المستخدمين تصرّفها بطريقةٍ قياسيّةٍ، ومن هذه الاختلافات البسيطة تتمثّل فيما يلي: إضافة سهمٍ باتّجاه الكائن الذي يصفه التّلميح. استخدام التّنسيق البسيط، أو العناصر المرئيّة للمعلومات الإضافيّة. إضافة زرّ -أو أيقونة- تلميحٍ واضحٍ، وقد يفيد ذلك في الواجهات المعقّدة أو الجديدة، حيث نتوقّع احتياج المستخدمين إلى المساعدة، أو عند إضافة إمكانية اللّمس في الهاتف المحمول. دليل موجز عن التنبيه (Alert Guidelines) يلفت كلّ متحكِّم المستخدم في أيّ واجهةٍ تُعدّ متحكّم تنبيه، ويجب استخدامه بحكمة واعتدال، وتقاطع التّنبيهات عمل المستخدم، وتتطلب عملًا يجب متابعته من قبله بخلاف الإشعارات (notification)/، أو رسائل التّحقق من الصحة (validation messages). متى نستخدم التنبيهات تنصح إرشادات التّنبيه كلّها باستخدام التّنبيهات باعتدال، إذ يؤدّي الإكثار من استخدامها إلى التّقليل من أهمّيّتها وإزعاج المستخدم، وتقترح إرشادات تصميم تطبيقات نظام ويندوز windows "اقتصار التّنبيهات على حالات الخطر والحالات المرتبطة، والقابلة للتّنفيذ، والغامضة، ونادرة الحدوث، باستثناء ذلك يجب حذف الرّسالة، أو إعادة صياغتها". تحدّد الإرشادات لائحةً من أسباب استخدام التّنبيهات، مثل: نشر الوعي. منع الخطأ. منع مشكلة وشيكة الحدوث. 4 التّأكيد على العمل المحفوف بالمخاطر. التّأكيد على العواقب غير المقصودة. المزيد من التّوضيحات. وتوضّح الأشكال التّالية بعض الأمثلة: يقترح نظام تصميم الويب الأمريكيّ وجوب استخدام [التحقق المضمن (inline validation) بدلًا من أو بالإضافة إلى التّنبيهات عند تصميم النّماذج (forms). كيف نستخدم التنبيهات تُعَدّ إرشادات واجهة نظام آبل موجزةً في ارشاداتها، فتوضّح أنه عندما يكون التّنبيه ضروريًا تكون وظيفةُ المصمّم الأهمّ شرحَ الموقف بوضوحٍ ومنحَ المستخدمين طريقةً للتّعامل مع التّنبيه، ولتحديدٍ أكثر نستخدم القواعد التّالية: يجب إنشاء رسائل خطأ محدّدة وقابلة للتّنفيذ وتركّز على المستخدم، ثم يقوم المستخدم بتنفيذ إجراءٍ أو تغيير سلوكه بسبب الرّسالة. يجب استخدام أنماط النّظام أو أنماطٍ محدّدةٍ مسبقًا، فلا يجب الابتعاد عن المألوف عندما يمكن ذلك. يجب استخدام تنبيهات لها زرّان (كما في نافذة الحوار) عمومًا. يجب التّعبير عن كلّ شيء بمصطلحاتٍ يعرفها المستخدم، كما يجب استخدام لغةٍ واضحةٍ وخاليةٍ من المصطلحات. لابد من توافق اسم الزّر الافتراضيّ مع الإجراء الذي يصفه التّنبيه، ومن المستحسن تجنّب استخدام الموافقة (OK) كاسم للزّر الافتراضيّ. يجب أن يكون تجاهل التّنبيه سهلًا عندما يكون ذلك مناسبًا، مثلًا عند الضغط على زرّ الخروج (Escape)، أو زرّ الإغلاق (CLOSE) في مربّع حوار، بالإضافة إلى زرٍّ، أو رابطٍ واضحٍ لرفض التّنبيه. يجب استخدام الأسلوب، والنّمط الذي يتبعه المصمّم (في الرّابط بعض الأفكار التي تخصّ الصّوت والنّمط وإرشادات المحتوى)، على سبيل المثال تشرح إرشادات النّمط والأسلوب الخاصّ بويندوز استخدام "من فضلك"، و "آسف". يجب استخدام "من فضلك" عندما يكون غيابها فظًّا. يجب استخدام "آسف" فقط في رسائل الخطأ التي تؤدّي إلى مشاكل كبيرةٍ للمستخدم. الاستخدام الرئيسي الحالات يمكن استخدام التنبيهات -كما هو الحال في رسائل التّحقق من الصّحة- للإبلاغ عن الأخطاء أو عرض تحذيرات حول الإجراءات التي قد تكون فادحة وقاتلة، بينما لا ينبغي استخدام التّنبيهات - بخلاف رسائل التّحقق من الصّحة- لعرض رسائل النجاح ما لم تكن للإبلاغ عن اكتمال إجراء مهمٍّ كما يوضّح الشّكل التّالي: التنوع تختلف التّنبيهات حسب نظام التّشغيل ومنصّة العمل -كما هو موضح أعلاه-، وتوفّر معظم منصّات البرامج مكوّنات تنبيهٍ مدمجةً، حيث يفضّل استخدام أنماط النّظام الافتراضيّة للتّنبيهات، إذ تسمح بعض أنظمة التّشغيل بالرّموز (و–أو) الألوان للتّمييز بين حالات، أو أنواع التّنبيهات كما في الشّكل التّالي: دليل موجز عن جدول البيانات (Data Table Guidelines) تستخدم جداول البيانات -التي تسمّى أيضًا عارض الجدول (table views)، والجداول (tables)، وشبكات البيانات (data grids)- الأعمدة والصفوف لعرض المعلومات المرتبطة في شبكة. table { width: 100%; } thead { vertical-align: middle; text-align: center; } td, th { border: 1px solid #dddddd; text-align: right; padding: 8px; text-align: inherit; } tr:nth-child(even) { background-color: #dddddd; } هذا هو جدول بسيط جدًا لعرض البيانات في الصفحة تكون الجداول قابلةً للقراءة ومألوفةً عندما تصمّم بطريقة مناسبة، يسهل اتّباع الإرشادات عندما تكون الجداول بسيطة، لكنّ الصّعوبة تكمن عندما تصبح البيانات أصعب على الفهم، وذلك عندما نستخدم طرق تصفية البيانات، وفرزها، والبحث فيها، والتّعامل معها. يمكنك الاطلاع على طريقة استخدام جدول البيانات في تطبيق Balsamiq لتصميم واجهة المستخدم. متى نستخدم جدول البيانات يُستخدم جدول البيانات أفضل مع البيانات الرّقميّة وقوائم الأغراض التي لها نفس النّوع، فيما يلي جدول بياناتٍ رقميٌّ نموذجيٌّ: تُعدّ الجداول -كالجدول التاّلي الذي يحتوي على إجراءاتٍ، وروابطَ، وأزرارٍ- شائعةً في تطبيقات المؤسّسات وإدارة علاقات العملاء (Customer Relationship Management)، وتطبيقات الأعمال الأخرى. تقترح إرشادات التّصميم التّابعة لشركة غوغل Google استخدام الجداول المكوّنة من ثلاثة أعمدة على الأقل، إذ يمكن استخدام القوائم المتجاورة (Side-by-side lists)، أو أيّ عنصر تحكّمٍ نصّيٍّ آخر لمقارنة بسيطة بين عمودين. تقترح شركة آبل Apple استخدام عارض المخطّط التفصيليّ (outline view) (المعروف أيضًا باسم عارض الشّجرة [Tree view]) بدلًا من جدول البيانات الهرميّة (table view for hierarchical data)، سنذكر لاحقًا جدول الشّجرة (tree table) وهو أحد الاختلافات في هذه الحالة. كيف نستخدم جدول البيانات للصّفوف الرّئيسيّة (رأس الجدول) للحصول على وصولٍ أسهل، وتصميمٍ أبسط. يجب استخدام صفٍّ رئيسيٍّ يحتوي على عناوين وصفية. يجب السّماح للمستخدمين بالنّقر على عناوين الأعمدة لفرز عارض الجدول إذا كان يحوي قيمًا. يجب أن يؤدي النّقر مرّةً واحدةً على عنوان العمود إلى فرزٍ طبيعيٍّ (مثل الفرز أبجديًا، أصغر رقم أولًا، أقرب تاريخ أولًا، العناصر المحدّدة أولًا)، وأن يظهر "سهمٌ للأسفل"، كما يجب أن يؤدي النّقر مرّة أخرى إلى عكس التّرتيب وعرض "سهمٍ للأعلى". يجب استخدام ألوانٍ متناوبةٍ للصّفوف في الجداول الكبيرة، وهو ما يُسمّى نمط "خطوط الحمار الوحشيّ" (zebra striping). يجب أن نرفق مربّعات الانتقاء (checkboxes) بكلّ صفٍّ إذا كان على المستخدم تحديد البيانات أو معالجتها. يجب تأمين رابطٍ، أو أيقونةٍ في العمود الأخير من الجدول للإجراءات التي لا يمكن تطبيقها إلا على صفٍّ واحدٍ في كل مرة (كالتّحرير، أو عرض التّفاصيل). يجب استخدام الوسم <THEAD> والوسم <TH>، و الخاّصتين بلغة HTML وذلك من أجل تسهيل قراءة المحتوى لقارئات الشاشة (تسهيل الوصول accessibility) وعرض الجدول بتنسيق جيد بتمييز ترويسته (رأسه) عن محتواه يجب أن تكون محاذاة النّص يساريّةً، ومحاذاة الأرقام يمينيّة. يجب الاحتفاظ بمستوىً مناسب للدّقة إذا احتوى الجدول على بياناتٍ رقميّةٍ، فكلّما قلّ عدد الكسور العشريّة، قلّ الزّمن المستغرق لمسح البيانات وفهمها. يجب عرض المعلومات التي يحتاجها المستخدم مع إمكانيّة التّعمّق في التّفاصيل عند الحاجة، كما يجب استخدام البيانات المتجمّعة (Inlays) والبيانات المتراكبة (Overlays)، وأدوات التلميح ToolTips، لعرض التّفاصيل في صفحة الجدول نفسها حفاظًا على مسار عمل المستخدم. يجب استخدام صفوفٍ رئيسيّةٍ ثابتةٍ في الجداول الطّويلة. يجب تأمين إمكانيّة البحث ضمن الجداول الطّويلة. يجب الانتباه لكثافة العرض، إذ تصعب قراءة البيانات المتقاربة أكثر، كما أن استخدام الكثير من المسافات يؤدّي لمزيدٍ من التّمرير (ومزيد من الوقت ليجد القارئ ما يحتاج له)، ويمكن تأمين خيارٍ لتغيير كثافة العرض كما يوضّح مقال تصميم جداول بيانات أفضل Design better data tables، ولكن لا يجب أن يكون هذا عذرًا لعدم وضع خيارٍ افتراضيٍّ جيّدٍ. يُعدّ ترقيم الصّفحات مفيدًا لمجموعات البيانات الكبيرة لكنّه ليس ضروريًّا، فقد أظهرت الدّراسات أنّ المستخدمين لا يمانعون القيام بالتّمرير في كثيرٍ من الحالات، وأنّ عرض جميع المعلومات في صفحة واحدة يتيح لهم إمكانيّة البحث والفرز بسهولة أكبر للعثور على ما يبحثون عنه. يجب عرض عدد الصّفحات -أو عدد النّتائج- الإجماليّ إذا استخدمنا ترقيم الصفحات، كما يجب تحديد عدد الصّفوف التي ستعرض في صفحةٍ واحدةٍ. يجب وضع الإجراءات التي يمكن للمستخدمين تنفيذها على البيانات بجانب حدود الجدول (كما يوضح الشّكل أدناه)، وعادةً يوضع ترقيم الصّفحات في الجزء السّفليّ من الجدول، بينما توضع إجراءات التّصفية، والفرز وإجراءات الصّفوف المتعدّدة في أعلى يسار الجدول (و/أو) أعلى يمينه. في حال وجود طريقة لتصفية البيانات أو تحديدها، يجب الإشارة إلى أنّ مجموعةً جزئيّةً فقط من البيانات هي التي تُعرض حاليًّا. يجب استخدام اللّون والزّخرفة باعتدالٍ، وقد يكون تمييز البيانات غير المتوقّعة مفيدًا (كالقيم المتطرّفة/المعزولة أو الإجراءات الفاشلة) ولكن قد يقلّل ذلك من إمكانيّة القراءة الكليّة. الاستخدام الرئيسي الحالات لا يوجد للجداول حالاتٌ -كما هو الحال مع عناصر تحكّم واجهة المستخدم الأخرى- لكن قد يحتوي بعضها على خلايا يمكن تغييرها من حالة (القراءة فقط) إلى حالة (قابلة للتّحرير)، ويجب أن تكون الخلايا القابلة للتّحرير مميّزةً باستخدام حدودٍ مائلةٍ (lowered bevel)، أو حدودٍ أكثر سماكة. التنوع إن عارض الجدول (table view)، عارض الشّجرة (tree view) الهجين القابل للتّوسيع هو أحد التّنوّعات الشّائعة لجدول البيانات، ويستخدَم حتّى لا ينتقل المستخدم لصفحةٍ جديدةٍ ويضيع سياق العمل، ويقدم مقال إرشادات جدول البيانات (Data Table Guidelines) مزيدًا من أمثلة تنوّع جدول البيانات. يجب تخصيص اختلافات (التّفاصيل عند الطّلب details-on-demand) لجداول البيانات المعقّدة، فهو مزعجٌ عندما يقوم المستخدم بالتّصفّح، لذا من الأفضل عرض البيانات التي يحتاجها المستخدم فقط. دليل موجز عن الأيقونات (Icon Guidelines) توجد الأيقونات في كل مكان في البرامج والويب، وتساعد المستخدمين على التّعرّف على الأشياء بسرعةٍ ودقّةٍ، وهي وفقًا لـ مجموعة التّصميم المرئيّKDE تنقل المعنى للمستخدمين بسرعةٍ، وقد تكون مفيدةً أيضًا لشرح مفهومٍ ما عندما لا يمكن وصفه بالكلمات، ويمكنك الاطلاع على شرح لكيفية إضافة الأيقونات في تطبيق Balsamiq لتصميم واجهة المستخدم. متى نستخدم الأيقونات من النّادر ألا نشجّع على استخدام الأيقونات، لكنّه من الخطأ استخدام الأيقونات الغامضة أو غير الواضحة استخدامًا قد يضلّل المستخدم أو يتعارض مع العنوان المجاور للأيقونة، ممّا يؤدّي إلى تجربةٍ أبطأ (و/أو) محبطةٍ مع المنتَج المصمَّم، فباختصار تُكلّف الأيقونات الخاطئة المصمِّم. تنصّ إرشادات مطوّري مجموعة GNOME على الاختيار الصحيح لأيقونة كل غرض "وذلك ضروريٌّ للتَأكد من قابليّة التَطبيق للاستخدام"، وتشجّع المجموعة على استخدامها وتصفها بأنّها "جزءٌ أساسيٌّ من أيّ تطبيق"، و"جزء مهمّ من هويّته". تُعدّ الأيقونات طريقةً رائعةً لمنع التّكرار، لا سيّما في الرّسائل المهمة، ويُظهر الشّكل التّالي ثلاث طرقٍ للتّعبير عن الخطأ وهي النّص واللّون والأيقونة، حيث تعزّز الأيقونة من خطورة الرّسالة. تسرّع الأيقونات تفاعل المستخدم مع المنتج عند استخدامها السّليم، وتحسّن قابليّته للاستخدام، وتعزّز هويّة العلامة التّجارية كما يظهر الشّكل التّالي: كيف نستخدم الأيقونات ملاحظة: تميّز إرشادات التّصميم الخاصّة بشركة غوغل Google بين أيقونات المنتجات وأيقونات النّظام، حيث تستخدم أيقونات المنتجات للعلامات التجاريّة، وللتّعبير عن الهويّة المرئيّة، مثال على أيقونة المنتج أيقونة التّطبيق في شريط المهام (task bar)، أو الشّاشة الرّئيسيّة (home screen)، تنطبق الإرشادات أدناه على أيقونات النّظام، وهي عبارة عن معرّفات للإجراءات، أو الأوامر. يجب تغيير التّصميم بما يناسب نمط الأيقونات. يجب استخدام الأيقونات مرّةً واحدةً فقط مثلًا لا تستخدم أيقونة الفرشاة (brush) مرتيّن لخيارين مختلفين. يجب استخدام الأسهم فقط إن كانت مرتبطةً بالميّزات المكانيّة، مثل: (السّابق/التّالي) على التّسلسل، أو (أعلى/أسفل) وفق تسلسل هرميّ، يجب تجنّب استخدام الأسهم اعتباطيًّا كالرّد، أو إعادة التّوجيه، أو التّراجع، أو الإعادة. يجب استخدام قواعد ثابتةٍ لـوضع النّص بجوار الأيقونات. قد تحتاج الأيقونات التي تفقد التّفاصيل عند تقليص حجمها إلى إصدارٍ خاصٍّ يحافظ على المعنى حتّى في الأحجام الأصغر، فقد لا نتعرّف على التّفاصيل الهامّة عند تصغير الأيقونة. يجب تجنّب استخدام النّص ضمن تصميمات الأيقونات فقد لا تتّسع جيّدًا في الأحجام الأصغر. يجب اتّباع القواعد، فلا يجب إنشاء أيقونات جديدة عندما تكون الأيقونات المألوفة متاحة. يجب إرفاق الأيقونات بتسميات دائمًا، إلا إذا كانت الأيقونات عالميّة (كالصّفحة الرئيسيّة، والطّباعة، والبحث) وهو أمرٌ نادر الحدوث. لا يجب استخدام الأيقونات التي ترتبط عادةً بمعانٍ مختلفةٍ. يجب استخدام الألوان، وقواعد تصميم الأيقونات، وتطبيقها باستمرارٍ، كما توضّح إرشادات التّصميم الخاصّة بشركة غوغل. يجب استخدام أدوات التّلميح للحصول على معلوماتٍ إضافيّةٍ، أو عند عدم استخدام التّسميات. الاستخدام الرئيسي الحالات تحتوي الأيقونات غالبًا على متغيرات "تفعيل (on)"، و"تعطيل (Off)" للإشارة للحالة عندما نستخدمها على أساس أزرار ، مثل: التبديل بين "الإعجاب (Like)"، و"عدم الإعجاب (dislike)" على شيءٍ ما، ويمكن أيضًا وضع الشّارات (badged) فوق الأيقونات للإشارة لحالةٍ أكثر تعقيدًا. التنوع بغضّ النّظر عن النُّسَخ الأبسط للأيقونات -والتي تسمّى الشّارات (badges)- فالاختلاف بين الأيقونات يكون في شكلها وأسلوبها، فبعضها بسيطٌ أحادي اللّون، والبعض الآخر مشرقٌ معقّد، فقد نستخدم النّمط الممتلئ، أو التّفصيليّ/المجوّف، والمهم هو تصميم الأيقونات باتّساق، بحيث تكون سهلة الفهم. ملاحظة الأمثلة المعروضة سابقًا من موقع The Balsamiq متوفّرة للتّنزيل، كما يمكن قراءة التّعليمات عن استخدام Wireframes في تطبيق Balsamiq لتصميم واجهة المستخدم. ترجمة -وبتصرف- للمقالات: Validation Guidelines Tooltip Guidelines Alert Guidelines Data Table Guidelines Icon Guidelines من موقع Balsamiq.com. اقرأ أيضًا المقال التالي: مقدمة عن نماذج تصميم واجهة المستخدم وقوالب تصميمها المقال السابق: متحكمات واجهة المستخدم -متحكمات التنقل-

مبادئ التّصميم هي قواعد أساسيّةٌ تعمل جيّدًا في توصيل المعلومات، بحيث يمكن للمستخدم استعمالها للقيام بعملٍ ما -مثل: اتّخاذ قرارٍ، أو القيام بإجراءٍ ما، أو فهم المعلومات المنقولة-، وقد ظهرت مبادئ التّصميم لكونها مثاليّةٌ للغرض الذي تخدمه -كما هو الحال في النّماذج-، وهو التّواصل الفعّال. من مبادئ التّصميم التي سنتحدّث عنها: التّباين (Contras) التّسلسل الهرميّ (Hierarchy) التّقارب (Proximity) المحاذاة (Alignment) قد تبدو هذه المبادئ جديدةً علينا حتّى تصبح مألوفةً، ونستطيع التّحكّم بها عن طريق تصنيفها وفهمها، وسنستطيع استخدامها عاديًّا كلّما مارسناها أكثر، حتّى تصبح جزءًا من اللّغة التي نستخدمها لتوصيل المعلومات في الواجهة، ولن نتمكّن من العمل دون أخذها بالحسبان بعد ذلك. التشبيه بالطهي لنتخيّل أنّنا طلبنا طبق تاكو السمك، وعندما وصل الطّبق إلى المائدة كانت التّورتيلا مغمورةً بالزّيت، والأسماك جافةً ومطهوّةً أكثر من اللّازم، ومقدّمةً في طبق منفصل، ثم قُدّمت التّوابل في وعاءٍ منفصلٍ. أي من الواضح هنا أنّنا سنعيد الطّبق، إذ لا تشكّل المكوّنات وحدها طبقًا ممتعًا، بل اختيار المكوّنات، وإعدادها، وترتيبها هو ما يشكّل الطّبق، فقد يجعل أسلوب التّقديم وتقنيّاته الطّبق أكثر شهيّةً، وهذا ما يجعل الطّبق لذيذًا بالفعل. ولدينا ما يشبه ذلك في التّصميم، إذ يعتمد على مبادئ عالميّة تجعل التّواصل معه فعّالًا. سنتحدث عن بعض مبادئ التّصميم المرئيّ الأساسيّة التي تساعد في تصميم الواجهات، وقد اخترنا أربعة مبادئ، عندما نبدأ باستخدامها في تصميم الواجهة سنحصل على أقصى استفادةٍ منها، فهناك العديد من المبادئ الأخرى لكنّ المبادئ الأربعة هذه تقدّم أساسًا جيّدًا لجعل الإطارات الشّبكيّة (wireframes) أكثر فعاليّة. لماذا تستخدم مبادئ التصميم قد يكون استخدام مبادئ التّصميم غير ملحوظٍ بدايةً عند النّظر إلى الصّفحات في الويب، بينما نبدأ بملاحظة عدم تطبيق مبادئ التّصميم هذه، ويكون تطبيقها مفيدًا عندما نجد صعوبةً في اجتياز نموذجٍ form كبيرٍ، أو عندما لا يمكننا العثور على زرٍّ Button، بين عددٍ كبيرٍ من عناصر التّحكم في تطبيقٍ مزدحمٍ، فعندها سيكون استخدام هذه المبادئ مفيدًا. يميل التّصميم المدروس جيّدًا إلى الاختفاء عندما يخدم الغرض منه في تحسين التّواصل، أو الاستخدام، ويختفي ويساعد المستخدمين ليصلوا إلى أهدافهم بسرعة. قد لا نطبّق التّصميم المرئيّ النّهائيّ على منتجاتنا، ومع ذلك فبعض الإلمام بمبادئ التّصميم يساعدنا في إيضاح أفكارنا، وقد نتعامل بأقلّ مع استدعاء الواجهة النهائيّة، لكنّ فهم الكثير مما نريد توصيله ينتج مما نستكشفه في التّفاعل، ومن المعلومات في إطاراتنا الشّبكيّة (Wireframes)، سنلقي نظرةً على كلّ مبدأ، ونتعرّف كيفيّة استخدامه في التّواصل في إطاراتنا الشّبكيّة وزمنه. التباين يشير التّباين إلى الاختلافات بين الأشياء، ويمكن تحقيقه بطرقٍ مختلفة، من أكثرها شيوعًا جعل الأشياء مختلفةً جدًّا في الحجم، أو استخدام الألوان المتناقضة. متى يستخدم التباين يستخدم التّباين في تصميم الواجهة لتنظيم المعلومات وتوجيه النّظر، وقد يكون مقطع النّصّ الذي لا يحوي عناصر متباينةً تكسر التّسلسل مملًّا في القراءة، كما قد تشير أنماط الخطوط وأحجامها المتباينة إلى عنوانٍ رئيسيٍّ يسبق قسمًا من النّصّ الثّانويّ يقسم النص، ويعرض للقارئ إشاراتٍ مرئيّةً ليتوقّف قليلًا ويحوّل تركيزه، ويسمح له بمعالجة المعلومات على مراحل، يوضّح الشّكل التّالي تخطيطًا لصفحةٍ رئيسيّةٍ لموقع ويب، أين نلاحظ كيف تساعد الطّباعة على إضافة تباينٍ في العناوين: توجد العديد من هذه الأمثلة في الصّحف التّقليديّة، ويُعدّ هذا أيضًا مثالًا على التّسلسل الهرميّ المرئيّ، والذي سنتحدث عنه أكثر فيما بعد. وبالإضافة إلى ما ذكرنا، يُستخدم التّباين أيضًا للإشارة إلى معلوماتٍ مهمّةٍ، حيث يؤدي استخدام طباعةٍ، أو ألوانٍ مختلفةٍ إلى تنبيه المستخدمين عند وجود تحذيرٍ، أو رسالةٍ مهمّة تتطلّب الانتباه، فمثلًا تؤدّي كتلة النّصّ الأحمر إلى توقّف المستخدم مؤقّتًا قبل القيام بإجراءٍ خطيرٍ، إذ يتناقض مربع الحوار الأحمر بشدّة مع الخلفيّة الرماديّة الباهتة. سنجد أمثلةً شبيهةً بذلك في تصميم التّطبيق، كما هو الحال عند عرض متصفّح غوغل كروم (Google Chrome) لتحذير عندما يكون المستخدم على وشك الدّخول إلى موقعٍ يحوي برامج ضارّةً، أين نلاحظ كيف يعمل النّصّ الأبيض جيّدًا مقابل الخلفيّة الحمراء، لتناقض اللّون الأبيض بشدّة معها. توجد بعض التّحفّظات عند استخدام اللّون، لكنّها غير مقلقةٍ عندما يتعلّق الأمر بالإطارات الشبكيّة، ومع ذلك يجب أن نكون على درايةٍ ببعض المشكلات أدناه أثناء الانتقال إلى التّصميم المرئيّ: يجب عدم استخدام الألوان التي لا تتباين بما يكفي، فهي قد تجعل القراءة صعبة. يجب مراعاة المعايير الثّقافيّة عند استخدام الألوان. للألوان معانٍ مختلفةٌ في الثّقافات المختلفة. يجب مراعاة المستخدمين الذين يعانون من عمى الألوان، فقد يواجهون أيضًا صعوبةً في التّعرف على ألوانٍ معيّنةٍ. كيف يستخدم التباين يعمل التّباين أفضل عندما تكون الأشياء مختلفةً عن بعضها كثيرًا، ففي الشّكل اللّاحق تتشابه النصوص كلّها تمامًا، وتُظهر العناوين والتّسميات تباينًا بسيطًا، وبالتّالي يتطلّب الأمر مزيدًا من الجهد من قبل المستخدم لتحليل النّصّ لتحديد مكان انتهاء معلومةٍ، وبدء معلومةٍ أخرى. يمكننا إضافة المزيد من التّباين لتختلف أجزاء المعلومات عن بعضها، ويمكن قراءة العناوين الرّئيسيّة بسرعةٍ بجعلها واضحةً باستخدام حجم الخطّ وكثافته، قبل المتابعة مع المدخلات inputs كما يوضّح الشّكل أدناه، حيث يساعد هذا المستخدم على قراءة المعلومات بسهولةٍ أكبر. تساعد بعض عناصر التّحكم على استخدام النّصّ المتباين بسهولةٍ، ففي موقع بالساميك (Balsamiq) مثلًا، يكون عنصر تحكّم العنوان بحجم 40 بكسل (pixel) افتراضيًّا، وتأخذ كتلة النّصّ إعدادات المشروع الافتراضيّة (بين 13 - 16 بكسل)، وهذا مفيدٌ للنّصّ الأساسيّ. ويُؤدّي تذكّر استخدام عناصر التّحكّم التي تمّ إنشاؤها لمحتوياتٍ محدّدةٍ شبيهة بهذه، إلى استخدام التّباين بفعاليّة. التسلسل الهرمي يشير التّسلسل الهرميّ إلى مجموعةٍ من الأشياء، حيث يتمّ ترتيب العناصر وفق أهمّيتها، ويُعرض التّسلسلّ الهرمي في النّظام بطرقٍ مختلفةٍ، فمن الأمثلة النّموذجيّة على ذلك، ترتيب المعلومات من الأكثر إلى الأقلّ أهميةً مرئيًّا، كما هو الحال في هذا الشّكل الذي يعرض الشّجرة الهرميّة من الأعلى إلى الأسفل، ونرى ذلك غالبًا في المخطّطات التّنظيميّة (Organizational Charts)، أو خرائط الموقع (Site Maps). متى يستخدم التسلسل الهرمي يستخدم التّسلسل الهرميّ لتنظيم المعلومات في نظامٍ، وتُعدّ خرائط الموقع -مثل تمثيل الشّجرة في الشّكل التالي- تمثيلًا نموذجيًّا لكيفيّة استخدام التّسلسل الهرميّ عند تنظيم الصّفحات في تصميم الموقع، أو التّطبيق. من الممكن وجود تسلسلٌ هرميٌّ داخل الصّفحات المستقلّة، ويُظهر الشّكل أعلاه في أمثلة النّصّ المتباين، أحد استخدامات التّسلسل الهرميّ، حيث استخدمنا الحجم والمقياس للفت الانتباه إلى المعلومات الأكثر أهميّةً في الصّفحة، ثمّ استخدمنا طريقة الطّباعة على نطاقٍ أصغر للنّصّ الأساسيّ، ويُستخدم التّسلسل الهرميّ أيضًا لمساعدة المستخدمين على فهم العلاقة بين محتويات النّظام، ويشار إلى التّسلسل الهرميّ بطرقٍ مختلفةٍ، فقد نقوم بإنشاء قوائم تحوي قوائم فرعيّةً متداخلةً منبثقةً (nested flyout sub-menus) كما في الشّكل اللّاحق حيث نعرض قائمةً هرميّةً للوظائف في أحد التّطبيقات. يستخدم التّسلسل الهرميّ أيضًا عندما نعرض قوائم موسّعةً للفئات وفئاتها الفرعيّة كما يوضّح الشّكل التّالي، وقد تكون هذه من الواجهات التي تظهر في موقع تسوّق على سبيل المثال، كما توجد طرقٌ مختلفةٌ لعرض التّسلسل الهرميّ في قوائم. سنجد أمثلةً على التّسلسل الهرميّ في عناصر التّحكم في البرامج، كالقوائم المنبثقة (flyout Menus) في نظام التّشغيل ويندوز (Windows)، أو آبل ماكنتوش (Mac)، وفي القوائم القابلة للطّيّ (collapsible lists)، في متصفّح ويندوز، أو متصفّح آبل التي تبدو كالسّلالم عند توسيعها، وفي قوائم مسار التّنقّل (breadcrumb)، التي تعرض العلاقة بين الأصل والفرع. باختصار يمكننا القول أنّ التّسلسل الهرميّ في كلّ مكان. كيف يستخدم التسلسل الهرمي تتمثّل الطّريقة الشّائعة لتحقيق التّسلسل الهرميّ في احتواء مجموعاتٍ من المعلومات الفرعيّة، أو دمجها داخل حاويةٍ رئيسيّة، سنعرض مثالًا لمجموعةٍ من الصّفحات في موقع ويب مرتّبةً ترتيبًا أبجديًّا، حيث لا معنى للعلاقة بين الصّفحات، وتبدو متساويةً في هذا التّسلسل الهرميّ المسطّح. يمكننا إنشاء قائمة تنقل لموقع الويب، عن طريق تجميع المعلومات في علاقات "أصل/فرع" كما في الشّكل أدناه: سنرى هذا النّوع من التّنقّل في التّطبيقات الخاصّة للفئات المتداخلة في برنامجٍ مثل بوربوينت (PowerPoint)، أو كينوت (keynote)، أو حتى بالساميك. يساعد التّسلسل الهرميّ المستخدمين على فهم الأنظمة المعقّدة، فهناك أمثلةٌ رائعةٌ يساعد فيها التّسلسل الهرميّ في أنظمة المعلومات الشّاملة، كما هو الحال في المتاجر الإلكترونيّة الضّخمة مثل أمازون (Amazon)، كما يُستخدم التّسلسل الهرميّ في التّنقّل لمساعدة المستخدمين على التّنقّل في المحتوى من الفئات الموسّعة إلى الفئات الأصغر. وكما رأينا في أمثلة التّباين سابقًا، فقد تستفيد الواجهات الأصغر مثل النماذج، من عرض التّسلسل الهرميّ داخل الصّفحة. يُعدّ إنشاء نمط نصٍّ شديد التّباين للعناوين -حيث نشير إلى أهمّ الأجزاء في محتوى الشّاشة- مثالًا عن استخدام التّسلسل الهرميّ في الصّفحة التقارب يتعلّق مبدأ التّقارب بإنشاء علاقةٍ بين العناصر، من خلال وضعها بالقرب من بعضها، والعكس صحيح، فالأشياء التي يُنظر إليها على أنّها بعيدةٌ عن بعضها ليست مرتبطةً، حيث نُعرّف كيفيّة الارتباط من خلال علم النّفس البشريّ وهو ما يسمّى بمبدأ جيستالت للتّجميع (Gestalt principle of grouping)، ويمكننا استخدامه لصالحنا في تصميم الواجهة. متى يستخدم التقارب قد يكون التّقارب مفيدًا عندما نريد استخدام التّشابه لمساعدة المستخدم، إذ يمكن لتجميع العناصر المتشابهة في وظيفتها، المساعدة -على سبيل المثال- في العثور على الإجراءات المرتبطة. هذا مثالٌ من تطبيقٍ يقوم بإنشاء مجموعاتٍ من الأزرار في شريط أدواتٍ، وهو إطارٌ شبكيٌّ لشريط أدوات برنامج كينوت، حيث خُصّصت المجموعة الأولى للإجراءات على مستوى المستند، مثل: العرض، والتكبير، وإضافة شرائح جديدةٍ؛ أمّا المجموعة الثّانية، فخُصّصت لوظائف العرض؛ بينما الثّالثة، فهي مخصّصة لإدراج المحتوى وما إلى ذلك. حيث يساعد تجميعُها بهذه الطّريقة المستخدمَ على استدعاء الأزرار المتشابهة في عملها، واستخدامها المتكرّر. يمكننا فصل أقسام المحتوى عن بعضها عندما نريد تبيان عدم ارتباطها، ففي الإطار الشّبكي للموقع في الشّكل أدناه، نلاحظ تواجد بعض المعلومات المهمّة في الأعلى، بما في ذلك بعض الأزرار للإجراءات المهمّة التي يُطلب من المستخدم اتّخاذها، كما توجد بعض المعلومات الأكثر أهميّة، والتي هي أكثر كثافةً في الجزء السفليّ من الصفحة، ونلاحظ أيضًا أنّ النّصّ الأصغر في المنتصف مفصولٌ باستخدام خطوط الحدود، ومن الواضح أنّ هذا يخدم وظيفةً أقلّ أهميةً لذلك قرّر الموقع فصله عن الأجزاء الأخرى. يفيد التّقارب في هذه الحالة، فهو يساعد المستخدم في بعض الحالات، كما هو الحال في مجموعة التّصريحات في الإطار الشّبكيّ في الشّكل أعلاه، إذ يمكنه المساعدة في جعل شيء ما مرئيًا في لحظة ما، ثمّ يوجهه نحو الأجزاء الأكثر أهميّةً من المعلومات. كيف يستخدم التقارب ناقشنا في الأمثلة السّابقة كيف يساعد استخدام التّقارب في تنظيم المعلومات في الواجهة، حيث يجب استخدام مساحةٍ بيضاء كافيةٍ بين المجموعات لاستخدام التّقارب بفعاليّة، ولابدّ من توفيرنا لنسخةٌ أكثر تفصيلًا من نموذج معلومات الزّبائن. باستخدام خيار مربّع الاختيار (checkbox)، وزرّ الإرسال والمساعدة، سيكون النّموذج محمّلًا بالمعلومات بكثافة أكثر. يساعد التّباين الذي أضفناه إلى العناوين -بجعلها أكبر أو أغمق- في فصل أجزاء النّموذج، لكن لا يزال علينا تجاوز الكثير، وقد تكون تعبئة النّماذج مملّةً جدًّا، لذا يمكننا القيام بالكثير لتسهيل الأمر على المستخدمين، إذ من الممكن للتّقارب مساعدتنا هنا، حيث يمكننا وضع مجموعات حقول النّموذج المرتبطة بالقرب من بعضها، وإضافة مسافةٍ بيضاء لفصل المجموعات غير المرتبطة. هذا يسهّل الإدراك المرئيّ ويقدّم للمستخدم إشارةً واضحةً عند الانتهاء من تعبئة مجموعةٍ من الحقول، ليتمكّن من التّوقف مؤقّتًا والعمل على المجموعة التّالية، وسنلاحظ مع مرور الوقت كيف يُستخدم مبدأ التّقارب في كلّ مكانٍ. عندما نتساءل إذا كان التّقارب من الأشياء كافيًا أم قليلًا جدًا، فعلينا تجربة اختبار النّظر (squinting)، وفيه نبتعد عن الشّاشة ونشوّش رؤيتنا، فإذا تمكنّا من التّعرّف على مجموعات المعلومات المنفصلة أثناء ذلك، فسندرك نفع لتّقارب؛ إمّا إذا كانت المسافة بين المجموعات تبدو صغيرةً جدًّا بحيث لا نتمكّن من التّعرف على المجموعات، فيجب عندها إضافة مسافةٍ أكبر بينها. المحاذاة يتعلق مبدأ المحاذاة بتسهيل معالجة المعلومات على المستخدمين من خلال توجيه أنظارهم إلى الأغراض المحاذية، فعندما يتمكّن المستخدمون من قراءة المعلومات التي تحتوي على خطٍّ، أو مسارٍ واضحٍ لتقرأه أعينهم فسيعرفون ببدهيٍّة إلى أين ينظرون لاتّخاذ الإجراء التّالي، فكم من الشّاق قراءة كتابٍ يقع كلّ نصّه في المركز، لذا يجب أن تكون النّصوص في الكتب بمحاذاة بمحاذاة اتجاه لغة الكتاب (يمين/ يسار)، بحيث تعود العينان تلقائيًا إلى بداية السّطر التّالي دون عناءٍ، ويمكننا استخدام المحاذاة بهذه الطّريقة مع أشياء أخرى غير النّصّ في واجهاتنا. متى تستخدم المحاذاة يمكن استخدام المحاذاة -بل يجب ذلك- عندما نقوم بتخطيط صفحةٍ ذات معلوماتٍ تطلب معالجتها، فباستخدام المحاذاة يمكننا التأكّد من عدم وضع أي شيءٍ تعسّفيًّا في الصّفحة، وإلّا قد يؤدّي ذلك إلى عواقب غير مقصودةٍ، كما في الانتخابات الرّئاسيّة للولايات المتّحدة عام 2000، والتي تميّزت فيها بطاقة الاقتراع في ولاية فلوريدا بواجهةٍ غير متجانسةٍ أدّت إلى تصويت العديد من النّاخبين للمرشّح الخطأ. أربك هذا الاقتراع الكثير من الناخبين حيث كان المرشّح الديموقراطي آل جور هو الثّاني على الجانب الأيسر، ثمّ تبيّن أنّ مرشّح الإصلاح بات بوكانان على الجانب الأيمن قد حصل على عدد أصواتٍ أكبر ممّا كان مُتوقّعًا، ويُعتقد اختيار النّاخبين الدّيمقراطيين للثّقب الثّاني، بحيث صوّتوا لبوكانان. يوجد عددٌ قليلٌ من العناصر التي تؤدّي إلى هذا الالتباس، حيث يصعب فهم عدم المحاذاة، وتعدّد خطوط الحدود والأسهم، ويمكن استخدام المحاذاة عندما نريد أن يكون المسار إلى المعلومات واضحًا، وقد يكون هذا الاقتراع المعاد تصميمه قد وضّح للنّاخبين مكان الاختيار ليصوّتوا لمرشّحهم. عندما نبدأ في التّفكير في وجوب محاذاة كلّ شيءٍ مع شيءٍ ما في الصّفحة، تصبح المعلومات أكثر وضوحًا وأسهل استخدامًا، وستبدو الواجهة أكثر تماسكًا. كيف تستخدم المحاذاة لنستخدم المحاذاة علينا النّظر إلى كلّ شيءٍ في الواجهة، والتّفكير في كيفيّة ارتباط كلّ عنصرٍ مع العناصر المحيطة به، فأحد التّمارين التي يمكننا القيام بها هو محاولة معرفة إمكانيّة محاذاة كلّ كائنٍ مع آخر. لننظر مثلًا إلى صفحة معلومات العملاء، أين قمنا بعملٍ جيّدٍ في إضافة التّباين واستخدام المساحة البيضاء لوضع العناصر المرتبطة بجانب بعضها، لكن لننظر إلى الصّفحة التي تحوي خطوطًا زرقاء وحمراء في الشّكل أدناه: تُظهر الخطوط الزّرقاء الكائنات التي لها محاذاةٌ يساريّةٌ قويّةٌ بالنّسبة للكائنات الأخرى، لكن توضّح الخطوط الحمراء عدم تماشي بعض الكائنات مع الكائنات الأخرى، خاصّةً تلك التي على يمين النّموذج، ويتمّ تحديد حجم مدخلات النّموذج، بحيث تنشأ حافّة يمنى مبعثرةٌ تجعل العين تنتقل إلى اليمين مقارنةً بالمحاذاة اليساريّة القويّة، ويمكننا إنشاء تخطيطٍ أكثر صلابةً يوجّه العين إلى أسفل النّموذج عن طريق تغيير حجم الكائنات، ووضعها، بحيث يتماشى كلٌّ منها مع الآخر. لنرى الخطوط الزّرقاء الآن. لجميع الكائنات محاذاةٌ يساريّةٌ قويّة، كما تحتوي معظم الكائنات أيضًا على كائنٍ تتمّ محاذاته مع الجانب الأيمن، وتساعد إضافة خطّ شعريٍّ خفيفٍ في مساحتنا البيضاء بين أجزاء النّموذج في خلق الإحساس بالمحاذاة الصّلبة، وهكذا عزّزنا الإحساس بالحركة باستخدام الاتّجاه الطّبيعي الذي تتّخذه أعيننا عند القراءة (للأسفل ولليمين مع اللغات التي تبدأ من اليسار إلى اليمين)، عن طريق تحريك زرّ الإرسال إلى الجزء السّفلي اليمينيّ من التّخطيط، وهذا ما يبدو عليه النّموذج دون خطوط المحاذاة. توجد طرقٌ مختلفةٌ تعمل جيّدًا تُمكّننا من محاذاة الكائنات في هذا النّموذج، والهدف هنا هو التّفكير في كيفيّة مساعدة المستخدمين على المضيّ قدمًا عبر الواجهة لإكمال أيّ مهمّةٍ، أو هدفٍ مقصودٍ، وكما أوضحنا في هذا المثال كيفيّة استخدام جميع مبادئنا الأساسيّة لتحسين واجهةٍ واحدةٍ، يجب استخدام هذا النّهج التّدريجيّ عند العمل على منتجٍ، أو موقعٍ خاصٍّ لنعرف إمكانيّة تطبيق المبادئ على كلّ صفحةٍ من صفحاتنا، وقد يكون أخذ لقطة شاشةٍ لعملنا مفيدًا لمعرفة مدى سهولة استخدام واجهتنا بعد تطبيق المبادئ. ترجمة -وبتصرّف- للمقال Visual Design Principles، من موقع Balsamiq.com اقرأ أيضًا المقال التالي: خطوات تصميم واجهة تطبيق من الصفر وفق المعايير الصحيحة باستعمال تطبيق رسم الإطارات Balsamiq المثال السابق: مقدمة عن نماذج تصميم واجهة المستخدم وقوالب تصميمها

يُستخدم نموذج التّصميم (Design Pattern) كحلٍّ متكرّر الاستخدام لمشاكل شائعة الحدوث، وكما هو الحال في وصفة الطّهو التي تحوي مكوّنات الطّبق وطريقة إعداده، كذلك يقدّم نموذج التّصميم حلًّا معروفّا، ويمكن التّنبّؤ به لمشكلةٍ في تصميم الواجهة، وقوالب تصميمها. وسنقدّم في هذا المقال شرحًا لكلّ من تصميم واجهة المستخدم وقوالب تصميمها، حتى تكون قادرًا على متابعة عملك، وحلّ المشاكل التي قد تصادفك أحيانًا، على مستوى واجهة المستخدم. مقدمة عن أنماط تصميم واجهة المستخدم (Intro to UI Design Patterns) ظهرت فكرة أنماط التّصميم من فنّ العمارة وانتقلت إلى البرمجة، حيث كان الهدف تطوير الحلول التي تعمل جيّدًا وفق سياقٍ معيّنٍ، ثمّ عُرفت هذه الحلول التي ظهرت متكرّرةً كـ (صيغةٍ يمكن إعادة استخدامها). يمكن لفريق العمل الاستفادة من كون الميّزات الهيكليّة والسلوكيّة للنّموذج مألوفة للمستخدم، بدلًا من إعادة تصميم النّموذج -أي إعادة اختراع العجلة-، ممّا يزيد من سهولة المنتج واستخدامه. ومع ذلك فلابدّ من الإشارة إلى حاجتنا لتعديل النّموذج وفقًا لاحتياجات الأعمال والمستخدمين، على الرّغم من فائدة النّماذج في تحديد قرارات التّصميم بما يخصّ مشكلةً معيّنةً. سنبدأ بنموذج التّصميم وبعض الأمثلة عن استخدامه وتفصيل تنفيذه، ثم سنذكر بعض النّماذج الشّائعة لتصميم الواجهة، ويمكن للمصمّم التّعمّق في اكتشافها. التشبيه بالطهي في فنّ الطّهي نجمع المكوّنات لنعدّ طبقًا، لنفترض مثلًا إعدادنا لـوجبة تاكو سمك، فإذا كان الطّبق مألوفًا لنا فسنقوم بإعداده من سمك مقشّر كسمك القدّ، والتّورتيلا، والتّوابل المختلفة، والزّيت، والصّلصة، وربّما شرائح اللّيمون للزّينة؛ بمعنى توجد طرقٌ مختلفةٌ للإضافة لهذا الطّبق ليكون خاصًّا بنا، لكن المكوّنات الأساسيّة له واحدةٌ، هذا يشبه استخدام نماذج التّصميم إلى حدٍّ كبيرٍ، حيث توجد طريقةٌ عامّةٌ لإعداد الطّبق، كما يمكننا إضافة أو إزالة بعض المكوّنات، وتغيير طريقة إضافتها معًا لنعدّ طبقنا الخاصّ. عناصر نموذج التصميم تُكتب نماذج التّصميم عادةً بمجموعةٍ مشتركةٍ من الصّفات التي تبدو كالتّالي: قالب نموذج التصميم اسم النّموذج ووصفه: يؤمّن الاسم طريقةً واضحةً للتّواصل، والإشارة إلى هذا النّموذج خاصّةً عند مناقشته بين الزّملاء. المشكلة: تصف المشكلة التي يحلّها النّموذج والهدف منه. سياق الاستخدام: يصف متى يستخدم هذا الحلّ. الحلّ: يصف آليّة العمل، والحلّ بالتّفصيل. التّوصيات: تعرض المزيد من التّوصيات. أمثلة. قالب نموذج التصميم لنبدأ بكتابة نموذج تصميم عربة تسوّق (Shopping Cart) لموقع ويب، يبدو هذا وصفًا واضحًا لمكوّن مألوفٍ جدًّا، علينا موازنة عربة التّسوق بتجارب الشّراء الأخرى كالشّراء بنقرةٍ واحدةٍ (one-click)، أو عمليّات الشّراء المماثلة كالحجز، وكيفيّة اختلاف ذلك عند استخدام الهاتف المحمول. اسم النّموذج: عربة تسوّقٍ لموقع تجارةٍ إلكترونيّة. الوصف: يتألّف مكوّن العربة من: زرّ "إضافة إلى عربة التّسوّق" لشراء منتجٍ. رمز عربة التّسوّق ليشير إلى معروضيّة المنتج للشّراء، ويحوي رابطًا لعرض العناصر، ولبدء عملية الدّفع. المشكلة: يرغب المستخدمون في شراء منتجٍ من موقع تجارةٍ إلكترونيّةٍ. سياق الاستخدام: يُستخدم هذا النّموذج عندما يسمح متجرٌ إلكترونيٌّ بتصفّح المنتجات، أو عندما يحوي المتجر أكثر من منتجٍ للشّراء، أو عندما يطلب المتجر مراجعة الطّلب قبل إتمام الشّراء؛ فقد يشتري المستخدم منتجاتٍ أثناء التّسوّق من متجرٍ إلكترونيٍّ، لكنّه قد يرغب في متابعة التّصفح ثمّ القيام بمراجعة وتعديل ما حدّده قبل بدء الدّفع، وهذا يشبه وضع المنتجات في عربة تسوّق في العالم الماديّ. الحلّ: عرض المنتج وإضافته إلى عربة التّسوّق: وضع زرٍّ بجانب المنتج لإضافته إلى عربة التّسوّق. تعديل ومعاينة العربة: عندما يضغط المستخدم على زرّ "إضافة إلى عربة التّسوّق" تظهر ملاحظة تشير إلى إتمام إضافة المنتج إلى العربة، ويزداد عدد المنتجات في مؤشرٍّ رقميٍّ بجوار أيقونة عربة التّسوّق. عرض معاينةٍ لعربة التّسوّق مع المنتجات، وعرض الخيارات المحدّدة. عرض ملاحظات بشأن الخطوات التّالية، مثل: تعديل عربة التّسوّق، أو عرض كامل سلّة التّسوّق، أو مواصلة التّسوّق، أو بدء الدّفع لإكمال الشّراء. عرض عربة التّسوّق: عرضٌ منفصلٌ لسلّة التّسوّق مع المنتجات المضافة إليها بحيث يمكن للمستخدم تعديلها، أو إكمال طلبه. تأمين إجراءاتٍ لتعديل الكميّات، وإزالة المنتجات. تأمين طريقةٍ للدّفع وتسجيل الخروج (checking out)، أو إتمام الشّراء. التّوصيات: قد تعرض خياراتٌ مع زرّ "إضافة إلى عربة التّسوّق"، مثل: محدّد للكميّة، أو محدّد للنّمط، وغير ذلك. ويجب إلغاء تفعيل زرّ "إضافة إلى عربة التّسوّق" إذا كان المنتج يتطلّب خياراتٍ، مثل: تحديد النّمط، أو الحجم ولم يحدّدها المستخدم. يجب وضع خيار التّسجيل بنقرةٍ واحدةٍ للمستخدمين الذين سجلوا دخولهم بالفعل، أو الانتقال المباشر إلى عمليّة الدّفع إذا كان المتجر يعرض عنصرًا واحدًا للشّراء. أمثلة: نايك (Nike) شوبيفاي (Shopify) كريت أند باريل (Crate and Barrel) أمثلة فيما يلي مثالان عن عربة التّسوّق المذكورة سابقًا، وسنتحدّث عن تفصيل حلّ هذه المسألة وانعكاس هذا على النّموذج، سنركّز على شراء المستخدم للمنتج باستخدام عربة التّسوّق عل أساس مكان افتراضيّ في موقعي Nike، وTatt.ly وهو موقعٌ يستخدم الشوبيفاي (Shopify). عربة تسوق موقع نايك (Nike) عربة تسوق موقع تاتلي الذي يستخدم شوبيفاي للتجارة الإلكترونية (TattlyTattly cart, which uses Shopify for e-commerce) الموازنة يعتمد نموذج التّصميم في كلا المثالين على استخدام عربة التّسوّق بمثابة مكانٍ افتراضيٍّ للاحتفاظ المؤقّت بالمنتجات التي سنشتريها، حيث يتمّ اعتماد رمزٍ مشتركٍ، إذ يوجد عادةً مؤشّرٌ لعدد المنتجات التي تمّ الاحتفاظ بها، مع الافتراض أنّ الخطوة التّالية هي الدّفع والخروج، تمامًا كما يفعل الشّخص في العالم الماديّ في المتجر. هناك بعض الاختلافات البسيطة بين المثالين: يؤمّن موقع نايك (Nike) أسلوبًا لطيفًا لمعاينة العربة دون مغادرة صفحة المنتج، وربّما يسهّل هذا على المستخدم العودة إلى التسوّق، في حين يستخدم موقع كريت آند باريل (Crate and Barrel) نفس الفكرة لمعاينة العربة، لكنّه يروّج أيضًا للمنتجات الأخرى التي قد يرغب المستخدم بشرائها بناءً على ما وضعه في سلّة التّسوّق، في حين تروّج شركة نايك (Nike) لمنتجاتٍ أخرى عند عرض سلّة التّسوّق نفسها. يوجّه شوبيفاي (Shopify) المستخدم إلى عربة التّسوّق مباشرةً بعد إضافة منتجٍ إليها. يوجد في كلٍّ من موقعي نايك (Nike)، وتاتلي (Tatt.ly)، وشوبيفاي (Shopify) نفس السّلوك العامّ ومراحل التجربة، فبدلًا من إعادة إنشاء التّجربة يعتمد كلٌّ منهما غالبًا على مصطلحاتٍ معروفةٍ، والتي تشكّل نموذج عربة التّسوّق الشّائع. استخدام وإنشاء نماذج خاصة من المحتمل أنّه قد تمّ تصميم العديد من الواجهات التي نراها وفق نموذج تصميمٍ شائعٍ، فمثال عربة التّسوّق الذي يتمّ نسخه غالبًا، يعود إلى اعتمادها على إمكانيّة التعرّف على هذا النّموذج، فهي تريح المستخدم الحامل لتوقّعات عن آليّة عمل التّسوّق عبر الإنترنت، كما تلبّي احتياجات العمل لتكون التّجربة خاليةً من المتاعب قدر الإمكان، وتضيف قيمةً لفرص البيع. عند البدء باستخدام نماذج التّصميم علينا إدراك أنّه على الرّغم من فائدتها -في مساعدتنا في تحديد قرارات التّصميم الخاصّة بنا عند حلّ مشكلةٍ شائعةٍ في واجهة المستخدم- إلّا أنّ ذلك لا يعني نسخها دون التّفكير في احتياجات المستخدم، والمنتج الخاصّ بنا. كتبت جينيفر تيدويل كتابًا ممتازًا لتصميم الواجهة بعنوان Designing Interfaces وقدّمت فيه نصيحةً بشأن استخدام النّماذج في القسم المسمّى "حول النّماذج" (About Patterns)، وتقول فيها: "النّماذج ليست مكوّناتٍ جاهزةً، إذ يختلف تطبيق كلّ نموذج عن الآخر، كما أنّها ليست قواعد، أو استدلالاتٍ بسيطةً، إذ لن ترشدنا خلال مجموعةٍ كاملةٍ من قرارات التّصميم". توجد العديد من الحلول المحتملة لمشاكل التّصميم في معارض أنماط التّصميم وواجهة المستخدم، كما توجد واجهاتٌ مسبقة الصّنع للعديد من هذه النّماذج في Wireframes to Go قوالب تصميم واجهة المستخدم (UI Design Templates) ربّما نكون قد استخدمنا قوالب الملفّات من قبل، حيث النّوع الشّائع بينها هو قالب المستند، مثل قالب ملفّ في تطبيق تحرير النّص، وقد تكون القوالب رائعةً لتأمينها نقطة بداية لمستند، مع بعض السّمات المحدّدة مسبقًا، مع مساعدتها على المضيّ قدمًا سريعًا، من خلال البدء بالمشروع من صفحات جاهزة يمكن تعديلها. وهناك أنواع قليلة من القوالب لتصميم الواجهة والتي قد تستخدمها: القالب الخاصّ بالحلّ: قد تكون القوالب خاصّةً بالمشكلة التي نحلّها، وتوفّر صفحات مجهّزة بمكتبة من عناصر التّحكم للحلول النّموذجيّة، ومن أحد الأمثلة على ذلك، قالب لإنشاء ميزة البحث أو حلّ مسألة عربة التّسوق الإلكترونيّة المذكورة سابقًا. قالب خاصّ بالنّظام / منصّة العمل: قد يوفّر القالب تخطيط صفحة موحّد، ورموزًا لمنصّة تصميم معيّنة. فمثلًا، قد تكون بعض القوالب مخصّصةً لإطار عمل بوتسراب (Bootstrap)، أو نظام تصميم، مثل: ماتيريال ديزاين (Material Design). قالب خاصّ بالشّركة / المنتج: من المفيد إنشاء قوالب خاصّة باستخدامنا كقالب لمنتجنا مع رموز من أجل دليل النّمط (style) الخاصّ بنا. لنبدأ بالتّعرف على كيفيّة تعديل القالب، فلابدّ من التّمكّن في نهاية هذه المقالة من إنشاء قالب خاصّ بنا. استيراد (Importing) القوالب القالب في موقع بالساميك (balsamiq) هو ببساطة ملفّ مشروع مبدئيّ نستدعيه إن كنّا نستخدم منصّة بالاساميك السّحابيّة Balsamiq Cloud، نضيف قالبًا من قائمة (E-Commerce Template <- Import Into Project) من موقع ويرفرامز تو غو wireframes to Go، حيث نستعرض القوالب، ونستخدم زرّ استيراد لإضافة القالب إلى مشروعنا الخاصّ. اختيار الصفحات التي نحتاجها في مثالنا عن المتجر الالكترونيّ online shop، يمكننا استخدام نموذج التّجارة الإلكترونيّة E-Commerce template لتصميم المزيد من تجارب التّسوق، فمن الواضح أنّنا سنرغب في توضيح عمل عربة التّسوق من خلال تأكيد المناقلة. وفي الأِشكال أدناه مثال عن الصّفحات الموجودة في هذا النّموذج، فقد لا يتطلب حلّنا الخاّص استخدامها جميعًا، ومن المحتمل أن يكون للمستخدم توقّعات أخرى يجب مراعاتها، إلى جانب قواعد عمل يجب تطبيقها، لذلك سنقوم بتعديل التّجربة حسب الضّرورة، مع اختيار ما نحتاجه وتجاهل الباقي، ولنفترض رغبتنا على سبيل المثال في تجسيد تجربة الشّراء المسبق (pre-purchase) على صفحات، مثل صفحات الهبوط (Landing page)، لنستخدم القالب لإنشاء صفحة هبوط لتطبيق هاتف ذكيّ خيالي. تعديل الصفحات مسبقة الصنع سنعدّل في هذا المثال قالب صفحة هبوط باستخدام نسختنا الخاصّة، كما سنضيف بعض العناصر لتطبيق الهاتف الذّكي الخياليّ. عندما نفتح قالبًا سنرى بعض من العناصر المؤقّتة (placeholder) كما في الشّكل أدناه، ويجب اختيار وتعديل كل من هذه العناصر. وبعد تعديلنا للنّص في الإطار الّشبكي في اليمين، وإضافتنا لبعض العناصر ذات الإطار الشّبكي لتوضيح منتجنا، وبمعرفتنا الجديدة بمبادئ التّصميم، أضفنا بعض الأجزاء لتتناسب أكثر مع الرّسوم التّوضيحيّة والنّسخ الجديدة. تحرير العناصر المؤقّتة لتخصيص الصّفحة نموذج مع اقتراحات البدء لتصميم صفحة هبوط تُعَدّ هذه العمليّة بسيطةً جدًّا، ونأمل أن يكون تحرير القالب أسرع بكثير من تخطيط جميع المكوّنات منذ البداية إذ سنرغب في تعديلها لتناسب احتياجاتنا، لكنّها تُعدّ طريقةً جيّدةً لبدء مناقشة التّصميم مع فريق العمل. ملاحظة حول مكتبات الرموز قد تحتوي بعض القوالب أيضًا على مكتبات للرّموز، يحتوي قالب التّجارة الإلكترونيّة الخاصّ بناءً على رموز للمكوّنات المستخدمة في الصّفحات المذكورة أعلاه، او لفكرة من استخدام الرّموز هي قدرتنا السّهلة على إسقاط هذه المكوّنات القابلة لإعادة الاستخدام، والمصمّمة خصّيصًا لهذا النّوع من المشاريع، ويمكن معرفة المزيد عن الرّموز في مستندات بالاساميك أفكار ختامية كما هو الحال مع أنماط التّصميم، تعمل القوالب مثل نقطة بداية، وعادةً ما تُبنى من فهم ما الذي ينفع جيّدًا لحلّ مشكلة شائعة، وتختلف القوالب عن أنماط التّصميم من حيث اقتراحها عادةً لخطّة لحلّ ما أهو أشمل من مجرّد مشكلة. يُعرّف مصمّمو الواجهة ببناء أنظمة ليصبح عملهم فعّالًا، فالقوالب هي مثال واحد على ذلك، وبمجرد براعتنا في العمل مع النّماذج، يمكننا البدء في إعداد أنظمتنا الخاصّة لتسريع العمل، فإذا كان العمل داخليًّا مع فريق إنتاج، فيجب بإنشاء قوالب تعكس النّمط التّنظيمي؛ أمّا إذا كان العمل في وكالة أو متجر تصميم / تطوير، فيجب إنشاء قوالب للأنواع القابلة للتّكرار لمشاريع المستخدم التي يعمل عليها. تشبيه بفن الطهي بتشبيه القوالب بفنّ الطّهي، تتزامن الأطباق معًا لتشكّل وجبة، وهذا ما يسمى تجربة طهي متكاملة، كذلك القوالب غالبًا ما تدمج أجزاءً من واجهة المستخدم معًا لتشكّل تجربةً كاملة. سنبدأ في رؤية أجزاء النّموذج التي تناسب احتياجاتنا، ونبدّل ما لا يناسبنا بينما نتعرف على المستخدمين ومشكلتهم بعمق، كما نغيّر الوصفة لتصبح خاصّة بك. ترجمة -وبتصرف- للمقال Intro to UI Design Patterns، والمقال UI Design Templates من موقع Balsamiq.com اقرأ أيضًا المقال التالي: مبادئ التصميم المرئي المقال السابق: متحكمات واجهة المستخدم - متحكمات الخرج -

سنتحدّث في مقالنا الأخير من "سلسلة في مقدّمة عن تصميم واجهة المستخدم" من خلال الإطارات الشّبكيّة Wireframes، عن المراحل التي يجب اتّباعها للتّأكد من أنّ أفكارنا ستُنتَج وتُسعِد المستخدمين يومًا بعد يوم، فقد تحدّثنا في المقالات السّابقة عن كيفيّة تصميم واجهات المستخدم، كما ستركّز هذه المقالة على عمليّة التّصميم، وهي حصيلة العديد من المقابلات التي أجراها موقع بالاساميك Balsamiq مع روّاد الأعمال، ومديري المنتجات، ومصمّمي تجربة المستخدم، والمسوّقين، والمطوّرين؛ حيث تختلف كلّ منظّمة قليلًا، لكننا نعتقد أنّ ما نصفه قد يكون بمثابة نقطة انطلاق مفيدة للمصمّم وللفريق، وتختلف العملية قليلًا لمّا يكون العمل جديدًا بدلًا من إضافة ميزة صغيرة إلى برنامج أو موقع ويب موجود مسبقًا، كما يختلف الأمر أيضًا إذا كان المصمّم متواجدًا في شركة منتجات، أو في شركة استشاريّة، وسنسلّط الضّوء على هذه الاختلافات. مراحل العملية هي: جمع المتطلّبات تحديد الأفكار إرسال المقترحات إلى المجموعة الأساسيّة دمج المراجعات في الإطارات الشّبكيّة الانتقال إلى المجموعة الأكبر إنشاء نموذج أوّليّ عالي الدّقة /اختياري -غير مستحسن العمل الوثيق مع المطوّرين المساعدة في الاختبار والنّشر والتّسويق مراقبة ردود الفعل تجاه العمل الخطوة 1: جمع المتطلبات عندما تردنا فكرة لمنتج جديد أو ميزة جديدة لنصمّم حلًا لها، تأتي الأفكار من كل مكان، ولو كنّا نعمل في شركة المنتج، فغالبًا ما تأتي الأفكار عن طريق فرق الدّعم، أو المبيعات بسبب طلبات العملاء، وتُعدّ هذه الأفكار أحيانًا ذات أهميّة إستراتيجيّة من قبل السّلطات (رؤساء الوزراء، التّنفيذيّين، التّسويق ...إلخ.)، حيث يطرح أحيانًا فريق التّطوير والتصميم الأفكار، فإذا كنّا من المؤسّسين المستقلّين، عندها نجمع كلّ هذه الأفكار ونحدد الأولويّات، وإذا كنّا نعمل في شركة استشاريّة، فغالبًا ما تحدث هذه الدّيناميكيّات داخل مؤسّسات الزبائن ويتواصلون معنا فقط عندما يكونون مستعدّين لتنفيذ الفكرة، والآن حان وقت التّنفيذ بغضّ النّظر عن كيفيّة حدوث ذلك، والخطوة الأولى هي فهم ما يطلبه منّا الزبون، حيث تسمى هذه المرحلة عادةً بمرحلة جمع المتطلّبات، وجمع المتطلبّات هو تخصّص لوحده فبعض الناس يمتهنونه، وفيما يلي رؤية عامّة عالية المستوى. أولًا يجب الحرص على تحويل المحادثة من الحلول وأفكار للحلول، إلى "ما المشكلة التي نحاول حلها"، حيث يميل البشر إلى الانتقال إلى الحلول عندما يواجهون أيّ مشكلة، ولذلك فمن المحتمل التّأطير الفعليّ لما قد يطلبونه من المصمّم، مع تحديد حلّ. فعلى سبيل المثال، قد يُطلب منّا "إضافة بحث إلى الموقع أو التّطبيق"، وهو أمر واضح نظرًا لإتمام تأطير الطّلب كحلّ ولهذا يمكننا تصميمه، لكن الحلّ قد يخطئ في تحقيق الهدف، فربّما كان من الممكن حلّ المشكلة التي أراد الزبون حلّها بطريقة أفضل من هذه، وذلك من خلال تحسين العمل الدّاخلي، أو عن طريق إضافة قناة دعم عبر الهاتف. لذا فالخطوة الأولى هي إنشاء صفحة ويكيبيديا، أو مستند غوغل Google، أو أيّ أداة نستخدمها للتّواصل داخليُّا في المشاريع، وتحديد عنوان لها "ما هي المشكلة/المشكلات التي نحاول حلها"، بعدها يجب الحرص على إضافة المجموعة الصّحيحة من أصحاب العمل، وأولئك الذين طلبوا الميزة، وقادة التّطوير، والتّسويق، وأيّ شخص سيتأثّر بهذا التّغيير، إذا كان من الصّعب العثور على زبون خارجيّ (ولا يجب أن يكون ذلك شاقًا)، فيجب البحث عن زبون داخليّ ليكون الوكيل مثالًا لأحدهم من مكتب الدّعم الفنّي. بعد ذلك يجب علينا سؤال أصحاب العمل عن المشكلة التي نحاول حلّها من خلال هذا التّغيير، مع تدوين الملاحظات، فقد نضطرّ أحيانًا إلى استخدام تقنيّة الأسباب الخمسة، للوصول إلى جذر المشكلة، ويجب البحث عن أنماط الرّدود، وتصنيف الإجابات بحيث يكون لدينا قائمة واضحة من المتطلّبات، فعندما ندرك ماهيّة المشكلات ونستوعبها بالكامل، فقد نرغب في تعميم الملاحظات مع أصحاب العمل مجدّدًا لنحرص على موافقة الجميع، فهذه هي المشكلات التي نريدها حلّها. في هذه المرحلة لابدّ من فهم مدى أهميّة هذا التّغيير أو إلحاحه بالنّسبة للجميع، وعندما ننتهي من ذلك (بعد يوم أو يومين كأفضل سيناريو)، يمكننا الانتقال لنفكّر في الحلول الممكنة، مع محاولة تجنّب مشكلة أوّلًا، "فإذا كان كل ما لدينا هو المطرقة، فكل شيء سيبدو مسمارًا" بمعنى آخر ألا ننتقل إلى ما يسهل القيام به، بل يجب محاولة التّفكير بطريقة أكثر شموليّة، مع وضع أنفسنا مكان الزّبون النّهائي، فلا يقتصر تفكيرنا على الحلّ البرمجيّ، بل نفكّر في مفهوم المنتج بالكامل، فربّما يكون الحلّ الأفضل هو التّوثيق الأفضل، أو التّدريب، أو تغيير العمليّة، أو بدء البثّ الصّوتي. يجب اختبار هذه الأفكار عالية المستوى المحتملة مع أصحاب العمل مجدّدًا ليومين أو أكثر، وإذا اتفقتم جميعًا على أنّ حلّ البرنامج يستحق المتابعة، فقد حان الوقت للانتقال إلى الخطوة التّالية، وهذا لا يعني بالضّرورة إلزاميّتنا بتنفيذ أيّ حلّ نوشك على تصميمه، فقد يكون ما نصمّمه لا يمكن تنفيذه في الوقت المناسب وخارج حدود الميزانيّة، أو لا يمكن للمؤسسة دعمه، في هذه المرحلة يجب الالتزام باستكشاف حلّ برمجيّ ممكن للمشكلة فقط. الخطوة 2: تحديد الأفكار هذا هو الجزء الأكثر إبداعًا ومرحًا، حيث تقوم بعض فرق البرامج بهذا الجزء معًا في غرفة اجتماعات باستخدام لوحة بيضاء، أو باستخدام البرامج التّعاونيّة في أداة التّخطيط الشّبكي، مثل: تطبيق بالاساميك السحابي Balsamiq Cloud، وقد تحبّ الفرق الأخرى القيام بتمرين حيث يتوصّل العديد من الأشخاص إلى حلول بمفردهم، ثم يجتمعون معًا لمراجعتها واختيار أفضل العناصر لكلّ منها، ومع ذلك يُنفّذ هذه المرحلة شخص واحد بمفرده غالبيّة الوقت. لذلك يجب الارتياح قليلًا والابتعاد عن الإزعاجات، والاستماع لبعض الموسيقى الهادئة مع الاستعداد للبدء، فإذا كنّا مصمّمين نميل للفنّ ولا نخاف من الصّفحة البيضاء، فقد نفضّل البدء برسم الأفكار على ورق، بحيث يجب أن تكون بمستوى عالي، مع احتوائها على مربّعات وأسهم؛ أمّا إذا كنّا لا نملك مهارة استخدام الورقة والقلم، أو نخاف من الصّفحة البيضاء لإتاحتها الكثير من الحريّة (مما قد يجعل التّصميم صعب التّنفيذ)، فـأداةٌ مثل بالاساميك تُعدّ مناسبةً لنا، ويمكننا اختيار العناصر القياسيّة من مكتبة واجهة المستخدم وتجميعها، كما يجب الحرص على استخدام أداة الرّسم Sketch لهذه الخطوة. ومن الأخطاء الفادحة التّحول إلى هيكل إطار شبكي، أو استخدام أداة تسمح لنا بالتّصميم بدقّة عالية، فعندها سنفكر كثيرًا بتفاصيل، مثل: الألوان، والخطوط، والمحاذاة المثاليّة للبكسل. وفي هذا مضيعة كبيرة للوقت، فإذا كان المطلوب هو إضافة جزء من الوظائف إلى واجهة مستخدم موجودة مسبقًا، فمن الأسرع أخذ لقطة شاشة لواجهة المستخدم الحاليّة، وتعديلها باستخدام أداة اقتصاص الصّورة وبهذا يكون قد حان الوقت لاستخدام جميع النّصائح والتّقنيات التي تعلّمناها في المقالات السّابقة، والأهم من ذلك ألا نخاف من البدء من جديد، فإذا كنّا نريد رؤية كيف تبدو هذه العمليّة في الحياة الواقعيّة، فيجب التّحقق من قائمة تشغيل مقاطع اليوتيوب youtube الخاصة بـالإطار الشّبكي لبالاساميك، فهدفنا الآن ليس التّوصل إلى "الحلّ المحدّد"، بل وضع بعض واجهات المستخدم لتقديمها إلى الفريق كمقترحات لنعرف كيفيّة تفاعلهم معها. ويجب الحذر من الوقوع في فخ الإصدار 3 من تطبيق بالاساميك، فبما أنّنا نميل عادةً إلى وضع الكثير من التّفاصيل في إطاراتنا الشّبكية بسبب طريقة عمل أدمغتنا، فذلك يلزمنا بمحاولة تقليص إطاراتنا الشّبكية الأوّليّة مرة واحدةً (الإصدار 2) بمجرد الانتهاء منها، ثمّ نقلصّها مجدّدًا لنصل إلى ما يجب إصداره في الإصدار 1، وإذا كنّا نرغب في عرض الرّؤية الكاملة للفريق، فيجب إضافة بعض التّعليقات التّوضيحيّة annotations، التي تعرض رسالة "إصدار2"، أو "يمكن أن يظهر لاحقًا"، ويمكننا استخدام أزرار مُدبّبة صفراء، أو أقواس عموديّة متعرّجة. الخطوة 3: إرسال المقترحات إلى المجموعة الأساسية بعد انتهائنا من الرّسوم التّوضيحيّة يجب العودة إلى أصحاب العمل للتّحقق من العمل سريعًا لنرى إذا كان الطّريق الذي نسلكه صحيحًا ومنطقيًّا للجميع، ويجب تسمية هذه الرّسومات بـ "المسودّات المبكرة والسّريعة"، كما يجب إخبار الجميع بعدم تمسّكنا بأيّ من هذه الأفكار، وهكذا لن يمتنعوا عن ردود الفعل الصّادقة خوفًا من إيذاء مشاعرنا، إذ لا يجب إرسال الرّسومات بالبريد الإلكتروني أو بأيّ طريقة أخرى، نظرًا لصعوبة فهمها، حيث يجب مقابلة أصحاب العمل، واطلاعهم على كلّ رسم تخطيطيّ، فهدفنا هو جمع أكبر قدر ممكن من الرّدود feedback حول رغبة كلّ شخص في التّصميم، وذلك يُعدّ خطوةً مهمّة فرسوماتنا – رغم أولويّتها - تتيح للجميع تصوّر الحلّ في أذهانهم، مما سيؤدّي بدوره إلى إثارة الأفكار والمخاوف التي لم يكن بإمكانهم التّفكير بها أثناء جمع المتطلّبات. قد يهتم كلّ شخص بجوانب مختلفة من الحلّ، فقد يهتمّ التّنفيذيون أو أفراد المبيعات بالعلامة التّجارية والأهميّة الاستراتيجيّة أكثر، بدلًا من سهولة الاستخدام، ويهتمّ المطوّرون في الغالب بقابلية التّنفيذ، في حين يهتمّ مصمّمو الرّسوم عمومًا بالجماليات. تُعدّ معرفة ما يهتمّ به كلّ صاحب مصلحة جزءا مهمًّا من العمليّة، وكلّما قمنا بذلك، كانت الإطارات الشّبكية أفضل في المرّة القادمة، تمامًا كما هو الحال في الرّسوم الكارتونيّة القديمة، إذ سنشعر وكأنّ كلّ ملاك صغير على أكتافنا يقدّم لنا ملاحظات أثناء التّصميم. ويجب الحرص على تدوين ملاحظات جيّدة أثناء هذه الجولة من الرّدود، مع حفظها في مكان ما، فإذا كانت بعض المراجعات رائعةً وواضحة وغير مثيرة للجدل، فيجب تطبيقها على تصميمنا فورًا، إذ لا داعي للانتظار حتى نتحدّث مع الجميع. كلمة تحذير إن تلقّينا القليل من المراجعات، أو مجرد عبارة "تبدو جيدةً بالنسبة لي"، فيجب عدّها إشارةً سيّئة، فهي تعني عدم اهتمام الأشخاص، أو عدم فهمهم لما نقترحه، أو أنّهم الجمهور الخطأ، أو أي شيء آخر. وتجدر الإشارة إلى أنّ التصميم على هذا المستوى من الدقة، يتسبّب دائمًا في ردود الفعل. الخطوة 4: دمج الردود في الإطارات الشبكية حان الوقت الآن لتحويل الرّسومات الأوّلية إلى إطارات شبكيّة مناسبة، وعندها يجب النّظر إلى التّصميمات المختلفة، مع دراسة قائمة الرّدود ومحاولة تجميعها معًا في حلّ واحد، فإذا استخدمنا مخطّطات ورقيّة من قبل، فهذا هو الوقت المناسب لتحويلها إلى إطارات شبكيّة عبر تطبيق بالساميك Balsamiq wireframes، حيث يسهل فهمها ومشاركتها، ويمكن الاستعانة بكلّ ما تعلّمناه في الفصول السّابقة لإنشاء تصميمات رائعة وقابلة للاستخدام. لا يزال يتعيّن علينا الحفاظ على الاشياء بمستوى دقّة منخفض هنا، فمن الساّبق لأوانه المخاطرة بإلهاء النّاس بالألوان والأيقونات الجميلة، وهذا صحيح خاصّةً عند إنشاء ميزة جديدة، أو صفحة ويب، أو منتج جديد، حيث نوصي بتصميم الصّفحات المفتاحيّة فقط في هذه المرحلة ربّما أقلّ من دزّينة، فما علينا سوى تصميم السّيناريو الافتراضي Happy Paths، ثمّ سنفكر لاحقًا في مربّعات حوار التّأكيد وشروط الخطأ. قد نرغب في استخدام ميزة الرّموز Symbols feature للرّؤوس والتّذييلات، وقد نرغب في ربط الصفحات معًا للمساعدة في التّنقل بينها، رغم أنّ ذلك غير مطلوب عمومًا طالما أننا نفرز الإطارات الشّبكية بطريقة تعمل فيها طبيعيًّا. نعتقد في هذه المرحلة أنّ من المهمّ السّماح للآخرين بالمشاركة في عمليّة التّخطيط الشّبكي، فلا يعني كونهم "مطوّرون" أو "رجال أعمال" استعبادنا لأفكارهم لواجهة المستخدم على سبيل المثال، فقد صُمّمت بالاساميك خصّيصًا للسّماح لغير المصمّمين بالمشاركة، لذا فلا يجب تقييد تصاميمنا، بل لابدّ من دعوة الآخرين المهتمّين بمشاركة أفكار واجهة المستخدم في مشروعنا ضمن سحابة بالاساميك على سبيل المثال، ويمكننا القيام بذلك بسهولة بالغة، إذ يمكنهم العمل معنا وإنشاء إصدارات بديلة لمراجعتها، كما يمكننا بسهولة التّعليق على تصاميمهم لنتمكّن من مراجعتها معًا. يجب الحرص على العمل الوثيق مع التّطوير في هذه المرحلة، فمن المحتمل أن يكون لديهم شروط لا نعرفها؛ أمّا موافقتهم فحتّى لو كانت متردّدة، فهي ضرورية للمضي قدمًا، ويجب أن نعلم عندما ننتهي عدد الأشخاص اللاّزمين لإتمام التّصميم والوقت اللّازم لذلك تقريبيًّا. الخطوة 5: الانتقال إلى المجموعة الأكبر بمجرّد الانتهاء من التّصميم بعد بضعة أيّام من العمل عليه -أي يكون قد عُمّم ربّما إلكترونيًّا مع الفريق الأساسيّ مجدّدًا للمراجعة النّهائية-، فهذا يعني أنّه قد حان الوقت لتقديمه للجميع، حيث سيكون هذا اجتماع مبيعات أكثر منه اجتماع تبادل أفكار brainstorming meeting، وفيه نستعرض التّصميم على أصحاب العمل وكلّنا ثقة بتلبيته للمتطلّبات، ويجب تقبّل المراجعات دون توقّع الكثير منها، وبصرف النّظر عن جميع أصحاب العمل، ففي الخطوة الأولى يجب الحرص على دعوة من يتمتّع بدرجة عالية بما يكفي ليكون قادرًا على الموافقة على التّصميم، بحيث يمكن البدأ بالتّطوير - الذي عادةً ما يكون في القسم التّنفيذي أو عميلًا- وهذا هو الهدف الرّئيسي في هذا الاجتماع. إحدى الحيل التي يستخدمها بعض الزّبائن في هذه المرحلة هي التّبديل إلى مظهر الهيكل الشّبكي، ورغم انخفاض دقّته، إلّا أنّه يُعدّ أكثر متانة، ويكفي لكيلا نحصل على نفس القدر من التّعليقات، مثل: التّعليقات على الرّسوم التّخطيطيّة Sketch. يجب التّجول في الاجتماع بين الأشخاص لرؤية كلّ صفحة من الصّفحات التي صمّمتها واحدةً تلو الأخرى، مع إبقاء العرض التّقديمي جذّابًا، إلى جانب تجنّب الانغماس في الكثير من التّفاصيل، وفي حالة اعترض أحدهم، فيجب تدوين الاعتراضات والتّعهد بالتّعامل معها على حدى بعد الاجتماع إن أمكن، وحتى لو كنّا قد أتممنا عملنا جيّدًا بمشاركة الفريق الأساسيّ مرارًا وتكرارًا قبل الاجتماع، فمع ذلك يجب أن يكون هذا العرض التّقديمي جيدًا، ويمكن قراءة تلميحات لتقديم الإطارات الشّبكيّة لمزيد من المعلومات. الخطوة 6: إنشاء نموذج أولي عالي الدقة في السّابق كانت الإصدارات التي مدّتها 18 شهرًا هي القاعدة الثّابتة، وكان بناء النّماذج الأوليّة طريقةً رائعةً لتقليل مخاطر الحلّ الخاصّ بنا - حتّى لو كان مدروسًا جيّدًا ووافق عليه الفريق-، لكن كان ينقصها العلامة التّجارية للزّبائن، وهو الأمر الأكثر مرونةً اليوم، حيث يمكن للمطوّرين تحويل الإطارات الشّبكية إلى شيء يمكنك العمل عليه لأيام وليس لأسابيع أو شهور. يستغرق إنشاء النّماذج الأوّلية عالية الدّقة بعض الوقت (يجب تصميم كلّ شاشة بالتّفصيل، وربط كلّ عنصر على حدة بوجهته، وتقديم بيانات وهميّة، وما إلى ذلك)، وتُنفّذ باستخدام أدوات باهظة الثّمن بواسطة منحنى تعليميٍّ عال، ويُعدّ هذا سهلًا إذا كنّا مصمّمي تجربة مستخدم UX ضمن فريق عمل، إذ لا يستطيع أحد غيرنا القيام بهذه الوظيفة، ومن السيّء تكرار النّماذج الأوّليّة، فتغيير التّصميمات عالية الدّقة في أداة الرّسم sketch، أوبرنامج الصّور Photoshop يستغرق وقتًا، وإعادة توصيل جميع أجزاء النّموذج الأوّلي يُعدّ أمرًا شاقًّا. أخيرًا وليس آخرًا، عندما ننتهي من النّموذج الأوّلي فسنتخلّص منه، ولهذه الأسباب وأكثر، يجب تخطّي مرحلة النّماذج الأوّلية عالية الدّقة والانتقال مباشرةً إلى التكويد والبناء البرمجي، فحتى إذا لم تكن الإطارات الشبكية ممتازة واضطررت إلى تغيير يصل إلى 15٪ من كود واجهة المستخدم، فلا يزال بإمكاننا الاحتفاظ بنسبة 75٪ المتبقّية من الكود وتكلفة تغيير يصل إلى تلك النسبة قد يكون أقل من تكلفة بناء نموذج أولي، ومع ذلك فإنشاء نماذج أوّلية عالية الدّقة قد يكون منطقيًا أحيانًا، ولنفترض هنا أنّنا نبني سيّارةً أو قمرًا صناعيًا، فهو أمر ليس من السّهل تكراره بعد إطلاقه. تستخدم بعض الشّركات الكبيرة عادةً، نماذج أوليّة عالية الدقة ليشتريها المديرون التّنفيذيّون، ففي عالم المؤسّسات لا يريد أصحاب القرار رؤية أشياء منخفضة الدّقة وذات مظهر سطحيّ، بل يريدون رؤية الشّيء الحقيقي بكلّ مجده المميّز. وهناك استخدام آخر للنّماذج الأوّلية عالية الدّقة هو خدمة اختبار الاستخدام الذاتية self-service user-testing. يعتقد بعض النّاس أنّ المستخدمين النّهائيين لن يقدّموا مراجعات ذات مغزى ما لم يروا الأمر برمّته كما لو كان حقيقيًا، وقد يكون الأمر كذلك، لكنّنا أشركنا مستخدمينا في مرحلة وضع الاطارات الشّبكية عدّة مرّات، وحقّقنا نتائجًا رائعة، لذا فيجب علينا محاولة معرفة الأفضل لنا ولشركتنا، وإذا قمنا بهذه الخطوة، فعندها يجب إضافة بضعة أسابيع على الأقلّ إلى جدول عملنا. الخطوة 7: العمل الوثيق مع المطورين حان الآن وقت العمل عن كثب مع فريق التّطوير للتّأكد من البناء الآمن لتصميماتنا، ويمكننا المساعدة بعدّة طرق أوّلًا، من خلال إضافةً الكثير من التّفاصيل والتّعليقات التّوضيحيّة annotations إلى مجموعة الإطارات الشّبكيّة، ويجب أن نكون مستعدّين لنُجيب بسرعة على أيّ أسئلة يطرحها المطوّرون، كما يجب تخصيص وقت لمراجعة عمليّات التّنفيذ المبكرة، عن طريق منصّة عمل staging، أو عبر برامج مشاركة الشّاشة لأجهزة المطوّرين. يجب التّفكير في جميع الحالات المتطرّفة الممكنة ونسجلها، إذ سيساعد هذا المطوّرين على كتابة الاختبارات unit tests، كما سيساعد المختبرين اليدويّين على التّحقق من كلّ حالة، وسيسمح لفرق الدّعم والتّوثيق أيضًا، بالتّأكد من توثيق كلّ شيء باستخدام لقطات الشّاشة الصّحيحة، حيث يجب تحديد موعد للاجتماع أسبوعيًّا أو حتى يوميًا مع المطوّرين، لنعرف كيف يتقدّم العمل، ولا يجب الخوف من العودة إلى التّخطيط الشّبكي إذا لاحظنا العمل غير السليم لأجزاء من التّصميم عند تنفيذها في كود حقيقيّ، إذ سنعود إلى الإطارات الشّبكية ونعدّل التّصميم ليعمل. الخطوة 8: المساعدة في الاختبار والنشر والتسويق عندما تقترب الميزة من التّجهيز، فسنكون في وضع جيّد للمساعدة على الإجابة عن الأسئلة بشأن الميزة من مختلف أصحاب العمل، إذ سيرغب التّسويق في معرفة كيفيّة إظهار الميزة، وسيطلب منّا فريق التّوثيق مراجعة عملهم على الميزة، كما سيريد التّنفيذيون عرضًا توضيحيًّا حقيقيًّا قبل الإطلاق، وبهذا سنحظى بشعبيّة كبيرة وسنرى ميزتنا الجديدة تنطلق للعالم. الخطوة 9: مراقبة ردود الفعل تجاه العمل من المدهش عدد الأشخاص الذين لا يقومون بهذا، أو لا يفكرون حتّى في القيام به، فمن الصّعب الانتقال من الفكرة إلى الإنتاج، وربما يكون معظم المصمّمين مُنهَكين في هذه المرحلة، ولكن إذا كنّا لا نعرف إن كانت ميزاتنا ستلقى استحسان المستخدمين النّهائيّين فكيف سنتحسّن في التّصميم؟ هناك العديد من الطّرق لمعرفة ما إذا كانت الميزة ناجحةً أم لا، حيث يمكننا متابعة الاستخدام عبر المقاييس، كما يمكننا البحث عن المنشورات في موقع تويتر twitter، أو - بالطّريقة المفضّلة لدينا - يمكننا إجراء مقابلات مع المستخدمين بشأنها. أفكار ختامية للعملية وهكذا نكون قد انتهينا، نأمل أن يساعد هذا المخطط الموجز العالي المستوى في التّحضير لما تبدو عليه حياة مصمّم واجهة المستخدم - حتى المصمّم غير الاحترافي - عندما يُحوِّل شيئًا من فكرة إلى إنتاج، كما نأمل أن نكون قد قدّمنا فكرةً عن أصحاب العمل وما تتضمّنه كلّ مرحلة. وكما قلنا سابقًا، فكلّ مؤسسة مختلفة، والعمليّة المذكورة أعلاه هي عملية متوسّطة لما سمعناه من خلال عشرات المقابلات البحثيّة للمستخدمين مع عملاء بالاساميك، فإذا كانت العمليّة التي تقوم بها مختلفةً فيجب التّواصل معنا، ويسعدنا دائمًا تحسين هذه الارشادات. ترجمة -وبتصرف- للمقال An Opinionated Guide to Creating Software من موقع Balsamiq.com اقرأ أيضًا المقال السابق: مبادئ التصميم المرئي

تحدّثنا في المقال السّابق عن مجموعة من متحكّمات واجهات المستخدم التي تهمّ كثيرًا المصمّمين، وفي هذا المقال سنتابع مع مجموعة أخرى منها هي متحكّمات التّتنقّل، من خلال عرض أدلّة موجزة عن كلّ من: علامات التّبويب، ومسار التنقّل، والتنقّل العموديّ، وشريط القائمة، والأكورديون. دليل موجز عن الروابط (links) للرّوابط التّشعّبيّة (Hyperlinks) دورٌ أساسيٌّ في التّنقّل في الويب، وعدم الالتزام بأهمّ الإرشادات قد يدمّر موقعك أو تطبيقك. متى نستخدم الرابط روابط النّصوص التّشعّبيّة (hypertext links) -التي اختصرت إلى روابط تشعّبيّة (hyperlinks) ثمّ صار يشار لها باسم الرّوابط (links) فقط-، هي الطّرق الأساسيّة للتّنقّل من صفحةٍ لأخرى في الويب، وهي شائعةٌ في تطبيقات الويب والتّطبيقات المكتبية الشّبيهة بالويب، إذ تكمن قوّتها في بساطتها، وقد تُضمّن في النّصّ العاديّ مما يسمح للمستخدم بقراءة المحتوى دون مقاطعته، مع إشارة الرّابط إلى أنّ المحتوى المرتبط به متاحٌ للقراءة. إضافةً إلى ذلك فهي لا تحتاج إلى الكثير من التّصميم (كما هو الأمر عند استخدام الأزرار) لإنجاز العمل -طالما نُفّذت بطريقة صحيحة- فهي قياسيّة، حيث يتوقّع المستخدمون أنّ عليهم الضّغط على النّصّ ذي اللّون المختلف أو الذي تحته خطّ. في الشّكل التّالي أمثلة عن استخدام الرّوابط في موقع ويكي حسوب: قد نستخدم الرّابط كجزءٍ من نصٍّ ليشير إلى محتوىً مرتبطٍ به، كما يمكن أوضع الرّابط وحده ليلفت الانتباه كما في التّنقّل الثّانويّ أو الرّئيسيّ، كشريط القائمة (menu bars)، أو مسار التّصفّح (breadcrumbs)، أو التّنقّل العموديّ (vertical navigation). ويُعدّ استخدام الرّوابط التّشعّبيّة باستخدام الفأرة أو لوحة المفاتيح، للتّنقّل بين أو ضمن الصّفحات، أمرًا سهلًا وشائعًا، ومع ذلك قد يسبّب وجود الكثير من الرّوابط في الصّفحة محدوديّةً في استخدامها. كيف نستخدم الرابط يجب استخدام لونٍ مختلفٍ للرّوابط التي تمّ النّقر عليها. يجب أن يكون لنصّ الرّابط معنىً (مثلًا يجب عدم استخدام جملة "اضغط هنا"). يجب أن يكون نصّ الرّابط موجزًا قدر الإمكان. يجب استخدام عناوين الرّوابط (باستخدام الصّفة "title") لمساعدة المستخدمين على توقّع وجهة الرّابط قبل النّقر عليه ما لم يكن ذلك واضحًا، كما يمكن فعل ذلك باستخدام التّلميح (tooltips). يجب استخدام رابطٍ صادرٍ (خارجيٍّ) عند الارتباط بصفحاتٍ خارج نطاقك. يجب تجنّب استخدام الرّوابط لبدء عملٍ ما، بل يجب استخدامها أساسًا للتّنقّل بين الصّفحات. لابدّ من وجود تباينٌ بين ألوان الرّوابط وخلفيّاتها. الاستخدام العادي الحالات افتراضي (default): رابط عاديٌّ وليس مختارًا. المقروء بالتحويم عليه (hover): عندما تمرّر الفأرة على الرّابط يصبح مقروءًا. نشيط (active): يصبح الرّابط نشيطًا عند الضّغط عليه. مُزار (visited): يصبح الرّابط مُزارًا بعد استخدامه. كما هو واضح سابقًا، يجب علينا استخدام نمطً مميّز للرّابط التّلقائيّ، ونمط مختلفً للرّوابط التي تمّت زيارتها، ويتمّ تجاهل حالة المقروء في أجهزة الهاتف المحمول لأنّ هذه الحالة غير متاحةٍ فيها. التنوع من المفيد الإشارة إلى الرّوابط التي تنتقل إلى مواقع خارجيّةٍ باستخدام رمزٍ صغيرٍ كما في الشّكل: دليل موجز عن الأقسام الفرعية (Tabs) طريقةٌ ذكيّةٌ لتقسيم محتوى الصّفحة إلى أقسامٍ (يطلق عليها أحيانًا علامات تبويب ولا أدري -يقول المحرر- سبب هذه التسمية!)، لكنّ استخدامها سيفٌ ذو حدّين، فهي تلفت اهتمام المستخدم إلى جزءٍ من المحتوى لتجعل الصّفحة سهلة الفهم من جهةٍ، وتخفي أجزاء أخرى لتجعل المستخدمين يخمّنون مكانها أو يتساءلون فيما إذا كانت موجودةً من جهةٍ أخرى، وفي مقال تصميم واجهات الويب Designing Web Interfaces مثال عن ذلك. يقول (آلان كوبر) في كتاب أساسيات التصميم التفاعليّ إن "التنقل مكلف"، وهذا ما يعني أنّه في كلّ مرة يتنقّل فيها المستخدم من صفحة إلى أخرى، فهذا يزيد من التّكلفة المعرفيّة لتجاربه، وأضاف "نادرًا ما يتماشى العمل الذي يقوم به المستخدمون في البرامج، وعلى مواقع الويب مع احتياجاتهم، وأهدافهم، ورغباتهم"، ولهذا حثّ المؤلّف المصمّمين على تقليل مقدار التّنقّل المطلوب، ويشرح كل من مقال إضافة عناصر تحكم واجهة المستخدم وترتيبها Adding and Arranging UI Controls، ومقال عنصر التحكم في التحرير Editing Controls كيفية إضافة متحكم وآلية تحريره. متى تستخدم علامة التبويب علامات التّبويب هي من أكثر نماذج التّنقل شهرةً إضافةً لشريط القوائم (menu bars)، والتّنقّل العموديّ (vertical navigation) ، ومن أهمّ ميّزاتها مألوفيّتها، وثباتها غالبًا، حتى لا يشعر المستخدم بالضّياع عندما يتنقّل في موقعٍ أو تطبيق. ومع ذلك هناك بعض القواعد الواجب اتّباعها عند استخدام علامات التّبويب، مثل: تستخدم علامات التّبويب عندما تكون خيارات التّنقّل المتاحة محدودةً (تصل إلى خمسة تنقّلاتٍ عند استخدام الهاتف المحمول، وأقل من سبعةٍ عند استخدام الحاسوب المكتبيّ). يحدد طول علامة التّبويب عادةً بطول النّص فيها، لذلك يجب علينا وضع تأثير موقع الخطّ وحجمه في الحسبان. يجب استخدام علامات التّبويب لعرض محتوياتٍ مترابطة بطريقة ما، ويجب تواجد هذه المحتويات في مستوى التّسلسل الهرميّ نفسه. يجب تجنب استخدام علامات التّبويب للمهامّ، أو النّوافذ المتتالية، كما يجب التّمكّن من استخدام كلّ علامة التّبويب باستقلاليّة عن العلامات الأخرى. كيف تستخدم علامات التبويب يجب تجنّب استخدام عدّة مجموعات من علامات التّبويب، لذا علينا -عند حصول ذلك- الحرص على تمييز المجموعة الثّانية عن الأولى. يجب وضع المحتوى الأكثر أهميّة في علامة التّبويب الأولى. يجب أن يكون تأثير المتحكّمات ضمن الجزء (pane) "المساحة التي تحتلّها علامة التّبويب" محدودًا بالجزء نفسه فقط. يجب عدم استخدام علامة تبويبٍ واحدةٍ. يجب عدم شغل علامة التّبويب لأكثر من سطرٍ، ففي حال لم نستطع ذلك يمكننا استخدام علامات تبويب التّمرير (scrolling tabs)، أو العلامات المنسدلة (drop-down tabs). لابدّ من عدم استخدام الأيقونات وحدها في علامات التّبويب، بل يوصى بإضافة نصٍّ في أعلى أو أسفل الأيقونة، حيث "تعتبر التّسميات النّصّيّة ضروريّةً لتوضيح المعنى وتقليل الغموض" كما في الشّكل: يمكن استخدام علامات التّبويب العموديّة عندما يكون عدد علامات التّبويب الأفقيّة كبيرًا (أو يمكن استخدام طريقة تنقّلٍ مختلفةٍ تمامًا). الاستخدام العادي الحالات يجب احتواء علامات التّبويب على حالتين أساسيّتين (محدّدةٌ وغير محدّدةٍ)، كما يمكن استخدام حالة المقروء لتنفيذ إجراءٍ ما -يشبه هذا ضغط زرٍّ ما- كما يوضّح الشّكل أعلاه، إذ تمييز علامة التّبويب المحدّدة عن علامات التّبويب غير المحدّدة، بحيث تكون علامة التّبويب المحدّدة أكثر وضوحًا (أعلى تباينًا) من غيرها، ويمكن استخدام النّصّ الغامق للتّأكيد على علامة التّبويب المحدّدة. التنوع يوضّح الشّكل التّالي بعضًا من تنوّعات علامات التّبويب الشّائعة: توجد عادةً حدودٌ للجزء الذي تشير إليه علامات التّبويب، لكنّ هذه الحدود ليست إجباريّةً. دليل موجز عن مسار التنقل (Breadcrumb) طريقةٌ مختصرةٌ لإظهار التّسلسل الهرميّ للتّنقّلات ضمن مستويات متعددة الموقع، وهي غير مزعجةٍ ولا تُشتّت انتباه المستخدمين، ولا تعرض مكان وجودهم فحسب، بل توفّر طريقةً سهلةً للسّماح لهم بالتّنقّل في مستوياتٍ متعدّدةٍ، بحيث لا تتطلّب سوى مساحةٍ صغيرةٍ، كما تُعدّ مألوفةً جدًّا للمستخدمين. كتبت مجموعة "Nielsen Norman Group" (أظهر اختبار المستخدم وجود العديد من الفوائد للتّنقل الثّانوي، مع عدم وجود أيّة مساوئ). متى يستخدم مسار التنقل تستخدم مسارات التّنقّل للتّنقّل الثّانويّ كما ذكرنا سابقًا، ولا ينبغي استخدامها باعتبارها الطّريقة الوحيدة لتنقّل المستخدمين نظرًا لعدم وضوحها أو ملحوظيّتها كغيرها من طرق التّنقّل الأخرى (مثل: علامات التّبويب). تستخدم مسارات التّنقّل عند عدم وجود طريقةٍ واضحةٍ للعودة إلى الصّفحة الرّئيسيّة، في حين لا يُحتاج لها عند استخدام متحكّم الشّجرة (tree control) للتّنقّل العموديّ الهرميّ، وذلك نظرًا لكون مسار التّنقّل واضح دائمًا، ويُفضّل استخدام مسارات التّنقّل -على عناصر التّحكّم الهرميّة الأخرى- في التّنقّل عندما تكون المساحة (خاصّة في الاتّجاه الأفقيّ) محدودةً، وذلك مثلًا عند استخدام الهاتف المحمول، ومع ذلك فقد لا تكون هذه الطّريقة مثاليّة للتّسلسلات الهرميّة العميقة جدًّا حيث قد يصبح المسار بالغ الطّول. كيف تستخدم مسارات التنقل يجب أن يكون اسم الصّفحة الحاليّة هو العنصر الأخير في مسار التّنقّل، دون أن يكون هذا الاسم رابطًا، ومن المفيد عدم وضع روابط للصّفحة الحاليّة. على الرّغم من إمكانيّة ذكر عنوان الصّفحة في مسار التّنقّل، إلّا أنّه من المستحسن تكراره في الأسفل، فغالبًا ما يكون مسار التّنقل صغيرًا. يجب استخدام محرفٍ واحدٍ لفصل الرّوابط، وتعتبر (">" و"/") الفواصل الأكثر شيوعًا لمسارات التّنقّل. يمكن استخدام مسارات التّنقّل لعرض التّسلسل الهرميّ (للموقع/للتّطبيق)، أو لعرض المسار الذي سلكه المستخدم (وهذا أقرب إلى اسمه "مسار التّنقّل")، ومع ذلك فمعظم التّوجيهات توصي بالخيار الأول -أي عرض روابط التّسلسل الهرميّ للموقع- بدلًا من مسار المستخدم. يجب وضع مسارات التّنقّل فوق محتوى الصّفحة، ولكن ليس فوق أي تنقّل أساسيٍّ (مثل: القائمة الرئيسيّة "header menu"، أو القائمة الأفقيّة "horizontal menu"). يجب تجنّب استخدام عدّة مجموعات من مسارات التّنقّل في صفحةٍ واحدةٍ. الاستخدام العادي الحالات تصمّم مسارات التّنقّل بما يشابه الرّوابط والنّصوص، ولها نفس حالاتها، وكما هو الحال مع الرّوابط القياسيّة (standard links)، فقد تنتمي روابط مسارات التّنقّل لإحدى الحالات (عاديّة، ومقروءة، ونشطة، ومُزارة). التنوع تستخدم مسارات التّنقّل المكثّفة (Condensed Breadcrumbs)عندما يكون عدد العناصر أكبر من خمسة عناصر، أو عندما يتجاوز المساحة المتاحة، حيث يمكن توسيع القائمة بأكملها، أو العناصر القليلة الأخيرة بالضّغط على "..." فقط. مسارات التّنقّل المنسدلة (Dropdown Breadcrumbs) هي نمط أقلّ شيوعًا حيث تجمع مسارات التّنقّل مع قائمةٍ عموديّةٍ للسّماح للمستخدمين بالتّنقّل الغير خطّيٍّ، وهي نمطٌ غير قياسيٍّ، ويجب استخدامه باعتدالٍ. يمكن مراجعة أمثلة هذا النموذج وإعداداته دليل موجز عن التنقل العمودي (Vertical Navigation) يسمّى أيضًا الشّريط الجانبيّ (sidebar)، وهو طريقةٌ لعرض بنية الموقع أو التّطبيق إلى جانب عرض المنتج، حيث تعرّفه إرشادات واجهة المستخدم لنظام التّشغيل آبل macOS بكونه عارضًا لجدول (table view)، أو عارض لمخطّطٍ تفصيليّ (outline view)، بحيث يسمح للمستخدمين بالتّنقّل، واختيار العناصر التي يريدون العمل عليها في الجزء الرئيسيّ من الصّفحة. يستخدم التّنقّل العموديّ على نطاقٍ واسعٍ في الويب، ثمّ شاع استخدامه في الهاتف المحمول عبر نمط قائمة التّنقّل المنزلقة navigation drawer متى نستخدم التنقل العمودي يشبه التّنقّل العموديّ علامات التّبويب، وهو واحد من اثنا عشر نمطًا من أنماط الصّفحة القياسيّة، وهو مناسبٌ للمستخدم، فهو يسمح له بالبقاء في الصّفحة نفسها عند التّنقّل بين العناصر. خلافًا لعلامات التّبويب يكون التّنقّل العموديّ مناسبًا عندما يكون عدد الفئات كبيرًا، أو قابلًا للتّخصيص من قبل المستخدم (كالمجلّدات أو العلّامات (tags) في البريد الإلكترونيّ). ويعدّ نمط تنقّلٍ آمنًا لأنه مألوفٌ ومرنٌ ولا يشغل مساحةً كبيرةً في الصّفحة، ويستخدم عندما لا يكون هناك خيارٌ واضحٌ آخر. لا نستخدم التّنقّل العموديّ عندما تكون المساحة الأفقيّة للصّفحة محدودةً، لهذا تحذف العديد من مواقع الويب -بما في ذلك هذه الصّفحة- التّنقّل العموديّ للشّاشات صغيرة الحجم وتستبدلها بمسار التّنقّل (breadcrumbs)، أو بقائمة "الهامبرغر" الشّهيرة (hamburger menu). وتُميّز إرشادات التّصميم أربعة أنواعٍ مختلفةٍ من طرق التّنقّل اعتمادًا على حجم الصّفحة ومحتواها، وهي: القياسيٌّ، والمشروط، والمرئيٌّ الدّائم، والقابلٌ للرّفض. كيف نستخدم التنقل العمودي يجب تمييز (الصّفحة / العنصر) المحدّد في القائمة، ولا ينبغي تصميمه على نحو مشابهٍ للعنصر القابل للنّقر (وإن كان يتصرّف بالطّريقة نفسها). يجب استخدام العناوين لتجميع العناصر المرتبطة. يجب أن يؤدّي النّقر على أسماء المجموعات إلى توسيع هذه الفئة أو طيّها، عوضًا عن الانتقال لصفحتها الخاصّة. يجب أن تكون أسماء روابط التّنقّل قصيرةً، ويمكن اشتقاقها من عناوين الصّفحات. يجب ترتّيب العناصر وفقًا لما هو أكثر فائدةً لمستخدمي التّطبيق. وجود بياناتٍ هرميةٍ لا يعني وجوب استخدام طريقة عارض الشّجرة (tree view)، في أكثر الحالات تكون طريقة عارض القائمة (list view) أبسط وأكثر فعاليّة. يجب الامتناع عن عرض أكثر من مستويين من التّسلسل الهرميّ في الشّريط الجانبيّ. يمكن أن يكون الشّريط الجانبيّ على الجانب الأيسر أو الأيمن من الصّفحة، ولكن لابدّ من ثباته عبر التّطبيق. يجب أن يتمكّن المستخدمون من الوصول للقائمة بأكملها (كاستخدام التّمرير إلى ما بعد محتويات الصّفحة)، إن كان محتوى الشّريط الجانبيّ أطول من محتوى الصّفحة. يجب استبدال لوحة التّنقّل (navigation panel) باللّوحة المنزلقة (slide-out panel) عند استخدام الشّاشات الصّغيرة، أو استبدالها بمسار التّنقل (breadcrumbs) عند استخدام شاشات سطح المكتب. الاستخدام الرئيسي الحالات يجب أن تكون حالة التّنقّل العموديّ محدّدةً وواضحةً كما هو الحال عند استخدام علامات التّبويب، ويتمّ ذلك بجعل العنصر المحدّد بلونٍ غامقٍ (و-أو) مميّزًا، كما يمكن استخدام حالة المقروء(hover) أيضًا. التنوع دليل موجز عن شريط القائمة (Menu Bar Guidelines) يسمح شريط القائمة للمستخدمين بالتّنقل باستخدام الفئات والفئات الفرعيّة، وهو ثابتٌ لا يتغيّر في التّطبيق، وهو العنصر الموجود في أعلى تطبيقات سطح المكتب -مثل قائمة ملف (File Menu)- ويقع أعلى الصّفحة كذلك في عالم الويب. ويدعم في كلتا الحالتين القوائم المتداخلة (nested menus)، أو العمل كفئات قائمة بذاتها (وتسمّى أيضًا التّجميع في خطّ واحد monoclinegrouping، أو البنية المسطّحة (flat structure)). متى نستخدم شريط القائمة يُستخدم شريط القائمة حصريًّا للتّنقّل الأساسيّ (primary navigation)، على عكس التّنقّل العموديّ، أو علامات التّبويب اللّذين يُستخدمان للتّنقّل الثّانويّ أيضًا. يستخدم شريط القائمة في فئات التّطبيقات، أو الموقع التي لها معنىً عند استخدامه، شرط عدم وجود فئات كثيرة جدًا. في حال وجود عدد كبير جدًا من الفئات التي لا يمكن احتواؤها في الصّفحة، يمكن التّفكير في استخدام التّنقّل العموديّ كما يوضّح الشّكل التّالي: أهمّ ما يميز أشرطة القوائم هو ثباتها، أي إمكانيّة الوصول إليها دائمًا، وتوضّح أساسيّات تصميم التّفاعل ذلك. ملاحظة تستخدم مواقع الويب المصمّمة جيّدًا العناصر الثّابتة -التي تبقى ثابتةً طوال عمليّة التّسوق- بحذرٍ، خاصّةً شريط التّنقّل ذي المستوى الأعلى على طول الجزء العلويّ من الصّفحة، ولا تؤمّن هذه المناطق خيارات تنقّلٍ واضحةً فحسب، بل يساعد وجودها وتصميمها على توجيه الزّبائن أيضًا. تحتوي أشرطة القوائم على قوائم فرعيّةٍ (كما هو موضّح أعلاه)، ولكن يجب تجنّب التعمّق لأكثر من مستوىً واحدٍ إذا أمكن ذلك، فهو يُغيّر فكرة المستخدم عن النّظام، فـ "تنظيم الأشياء في طبقة واحدة من المجموعات أمرٌ شائعٌ، ويمكن العثور عليه في كلّ مكانٍ في منزلك ومكتبك" كيف نستخدم شريط القائمة تزوّد إرشادات الواجهة لنظام التّشغيل آبل (macOS) دليلًا شاملًا لاستخدام القوائم في تطبيقات سطح المكتب (ينطبق الكثير منها على مواقع الويب أيضًا)، من أبرز نقاطه: يجب أن تكون عناوين القائمة قصيرةً دون تأثير ذلك على الوضوح، ويُفضّل اقتصار على كلمةٍ واحدة. يجب استخدام نصٍّ -لا أيقونةٍ- لعناوين القائمة (يمكن استثناء استخدام شعار أو رسم بدلًا من كلمة الصّفحة الرّئيسيّة (home) في عالم الويب، كما يوضّح الشّكل لاحقًا). يجب إلغاء تفعيل العناصر غير المتاحة في القائمة لا إخفاؤها. يجب تحديد استخدام القوائم الفرعيّة وعمقها وطولها. يجب تعيين اختصارات لوحة المفاتيح، وعرضها بجانب عناصر القائمة المرتبطة بها. يجب استخدام خطوط فاصلة لإنشاء مجموعات مميّزة لعناصر القائمة المرتبطة. يجب وضع العناصر الأكثر استخدامًا في أعلى القائمة. يجب تجميع عناصر القائمة التي تؤدّي لإجراءاتٍ مرتبطة. يجب استخدام علامة (checkmark) للإشارة إلى وجود عنصر ما نشط حاليًا. بعض الإرشادات الأخرى المهمّة لشريط القوائم: لا يجب وضع نموذج التّنقّل وفقًا للهيكل التّنظيميّ للوكالة (أو النّموذج البنيويّ للتّطبيق)، بل يجب تنظيمه اعتمادًا على المهامّ، والمعلومات التي يريد المستخدم الوصول المتكرّر إليها. يجب وضع روابط تنقّل للتّخطي للسّماح للمستخدمين الذين يملكون برامج قراءة الشّاشة (screen readers) بتجاوز قوائم التّنقّل الطّويلة. يجب التّفكير في استخدام قائمة ضخمة (mega menu) عند وجود أكثر من ستّة روابط أو عناصر قائمة ضمن قائمة أخرى. يجب استخدام تسع فئات أو أقلّ من فئات المستوى الأعلى. يمكن تحويل أشرطة القوائم إلى قائمة منزلقة (slide-out menu)، أو قائمة هامبرغر (hamburger menu) قابلة للتّوسيع في مواقع وتطبيقات الجوّال. يجب أن تكون عناصر القائمة تفاعليّةً ومرئيّةً بما يكفي لتدعو لفعلٍ ما. يجب أن تكون روابط القائمة كبيرة بما يكفي للنّقر عليها بسهولةٍ، مع تأمين هوامش ومسافة كافية حتى لا ينقر المستخدم على العنصر الخطأ. يجب تفضيل التّناسق على إبهار المستخدم (wow factor)، ويمكن تجاوز المعايير على مسؤوليّة المصمّم الخاصّة. الاستخدام الرئيسي الحالات كما هو الحال مع علامات التّبويب والتّنقّل العموديّ، فيجب أن تكون لأشرطة القوائم حالةٌ محددةٌ وواضحةٌ، يشار لها عادةً بنصٍّ عالي التّباين (أو عكس النّمط غير المحدّد)، وقد يكون بالخطّ الغامق، كما يجب استخدام حالة القراءة. التنوع يمكن دمج وظائف أخرى في منطقة شريط القائمة -مثل: مربّع البحث، أو الإجراءات المهمة (مثل تسجيل الدّخول / الخروج)- حتى يبقى رأس الصفحة مضغوطًا، وهو ما يسمّى الرّأس الموسّع extended header يمكن استخدام تراكب القائمة الضّخمة (mega menu" overlay") لعرض المزيد من التّسلسلات الهرميّة المعقّدة، والذي يعرض أعمدةً متعدّدةً من الفئات الفرعيّة (أو حتى مستوى إضافيًّا من التّشعّب)، يجب الانتباه لتنفيذها عند استخدامها، خاصّةً في ما يتعلّق بتوقيت عرض القائمة وإخفائها. دليل موجز عن الأكورديون (Accordion Guidelines) الأكورديون عبارة عن حاوياتٍ مكدّسةٍ تحوي عناصر متشعّبةً تتّسع وتنطوي بالنّقرعليها، ويُعدّ عنصر تحكّمٍ لافتًا نظرًا لسماحه بعرض كثيرٍ من الرّوابط في مساحةٍ مضغوطةٍ، لكنه غير مألوفٍ كثيرًا، لذا يجب ألّا نفرط في استخدامه، ويمكن استخدامه للتّنقّل أو للمحتوى -على عكس التّنقل العمودي-، ومن أسمائه الأخرى لوحة التّوسيع (expansion panel)، ومتحكّم "التّوسّع/التّصغير" (expand/collapse control). متى نستخدم الأكورديون ورد في كتاب واجهات تصميم الويب Designing Web Interfaces: يُعدّ الأكورديون "جيّد لوحدات المحتوى المتشعبّة، ومع ذلك يجب استخدامه باعتدال، حيث يتمتّع بأسلوبٍ مرئيٍّ قويّ". يشتمل جزءٌ من هذا النّمط المرئيّ على تحريك اللّوحات أثناء فتحها وإغلاقها، والذي قد يبدو تأثيرًا مذهلًا، لكنّه يضيف أحيانًا تكلفةً تفاعليّةً interaction cost غير ضروريّةٍ يمكن تجنّبها باستخدام عنصر تحكّمٍ أبسط، فهو بهذا يشبه عناصر التحكّم الدائريّة carousel controls التي فقدت شهرتها لهذا السّبب. على الرّغم من أنّ الأكورديون ليس الخيار الأفضل لصفحات سطح المكتب، إلّا أنّه مناسبٌ في الهواتف المحمولة، مثل قائمة التنقّل الخاصّة بالهواتف المحمولة من موقع UX Mastery الموضّحة في الشّكل التالي: يستخدم الأكورديون في التّنقّل عندما يرغب المستخدم في رؤية كامل التّنقّل الهرميّ، أو جزءٍ منه، وكذلك عندما يرغب في اكتشاف محتوى الموقع قبل الالتزام بقسمٍ أو رابطٍ معيّنٍ، وبذلك يشبه التّنقّل العموديّ الهرميّ. يجب استخدام الأكورديون للتّنقّل فقط وفقًا لـأنماط واجهة المستخدم في الحالات التّالية: عندما يكون هناك أكثر من قسمين رئيسيّين في موقع ويب يحتوي كلٌّ منهما على قسمين فرعيين أو أكثر. عندما يكون هناك أقلّ من عشرة أقسامٍ رئيسيّةٍ. عند عرض مستويين فقط في شريط التّنقّل الرّئيسيّ. أمّا عن استخدام الأكورديون في محتوى الصّفحة، فيقترح نظام تصميم الويب في الأمريكيّ ترْك استخدامه عند عدم وجود محتوىً كثيرٍ، وكذلك عند رغبة المستخدم في رؤية المحتوى كلّه في وقتٍ واحدٍ. ومن الأمثلة الصّحيحة على استخدامه صفحة تعليمات الأسئلة الشّائعة (FAQ help page)، ومع ذلك لا ينبغي استخدامه، إذ كان هناك محتوى كبير فقط، ففكرة عدم محبّة مستخدمي سطح المكتب للصّفحات الطّويلة هي غير صحيحة. في جميع الحالات يجب تجنّب الأكورديون الأفقيّ (horizontal accordions) -حيث تكون الألواح مكدّسة أفقيًّا- فهو غير مألوف، إذ يكون دائمًا أقلّ قيمةً من أنواع المتحكّمات الأخرى. كيف نستخدم الأكورديون فيما يلي إرشادات عامّة تنطبق على معظم الحالات: تتوسّع اللوحة (panel) عند النّقر عليها بينما يتمّ تصغير اللّوحات الأخرى، ويجب فتح لوحةٍ واحدةٍ فقط في كلّ مرة. لا تفتح حاويات الأكورديون عند القراءة (hover)، بل يجب استخدام النّقر، أو اللّمس عوضًا عن القراءة. يجب السّماح للمستخدمين بالنّقر فوق أيّ مكانٍ في منطقة الرّأس لتوسيع المحتوى أو تصغيره، ومن الأسهل التّعديل على العنصر الأكبر. يجب البدء بفتح القسم الأوّل ولا يجب إغلاق كل الأقسام افتراضيًّا. يجب تمييز اللّوحة الحاليّة ليتمكّن المستخدم من التّمييز بين رؤوس اللّوحات المفتوحة، ورؤوس اللّوحات المغلقة. عند استخدام اللّوحات المتحركّة، يجب أن تكون الحركة دقيقةً، ولا تدوم أكثر من 250 مللي ثانية. لا يجب المزج بين الأكورديون، وأنواع التّنقّل الأخرى في المستوى نفسه. إذا لم يتسع محتوى القسم عموديًّا في الصّفحة يجب التّمرير داخل اللوحة بدلًا من تمرير عنصر التّحكم بالكامل. الاستخدام الرئيسي الحالات يجب أن يكون للأكورديون حالةٌ محدّدةٌ وواضحةٌ للّوحة المفتوحة، وللعنصر المحدّد داخله، كما يجب تطبيق حالة القراءة على كليهما. التنوع ينبغي التّقليل من الاختلافات حفاظًا على ثبات المعايير، من الخيارات الشّائعة إضافة الأيقونات، والرّمزان +، و- هما الأشهر، كما يمكن استخدام المثلّثات المدبّبة (Pointed triangles)، أو إشارة الرّتب (chevrons). لابد من إعلام حالات الأيقونة المستخدمَ بما سيحدث عندما ينقر عليها، كما يجب ظهور أيقونة +، أو أيقونة التّوسيع على اللّوحات المصغّرة بدلًا من الإشارة إلى أنّ اللّوحة المفتوحة تمّ توسيعها. ملاحظة الأمثلة المعروضة سابقًا من موقع The Balsamiq متوفّرة للتّنزيل، كما يمكن قراءة التّعليمات عن استخدام Wireframes في تطبيق Balsamiq لتصميم واجهة المستخدم. ترجمة -وبتصرف- للمقالات: Link Guidelines Tab Guidelines Breadcrumb Guidelines Vertical Navigation Guidelines Menu Bar Guidelines Accordion Guidelines. من موقع Balsamiq.com. اقرأ أيضًا المقال التالي: متحكمات واجهة المستخدم وكيفية عرضها: متحكمات الخرج المقال السابق: متحكمات واجهة المستخدم وكيفية عرضها: متحكمات الدخل

تتمثّل البنى الأساسيّة لواجهة المستخدم في المتحكّمات التي قلنا عنها في المقال السابق، أنّها مُهمة جدًّا ويتوجّب على كلّ مصمم معرفتها من أجل القيام بعمله على أكمل وجه، وسنتعرف في هذا المقال على مجموعة من هذه المتحكّمات، وتعرف بمتحكّمات الدخل، وذلك بالتطرق لأدلّة موجزة عن كل من: الأزرار، وحقل إدخال النّص، والقائمة المنسدلة، وزرّ الانتقاء، والرّوابط. دليل موجز عن الأزرار (Buttons) يُستخدم الزّر لإجراء عملٍ ما كإرسال بريدٍ إلكترونيٍّ، وقد يكون تصميم الأزرار أمرًا واضحًا لكنّه أعقد ممّا نتخيّل، إذ يجب اتّباع بعض الإرشادات في تصميمها، ويشرح كل من مقال إضافة عناصر تحكم واجهة المستخدم وترتيبها Adding and Arranging UI Controls، ومقال عنصر التحكم في التحرير Editing Controls كيفية إضافة متحكم وآلية تحريره. متى نستخدم الأزرار وفقًا لكتاب تصميم الواجهات Designing Interfaces لجينيفر تيدويل (Jenifer Tidwell)، فلابدّ من مقروئيّة ووضوح وسهولة استخدام الأزرار حتّى عندما يتعامل معها أقلّ مستخدمي الحاسوب خبرًة، ويُفضّل استخدامها لإجراء الأعمال المهمّة، فكلما زاد عدد الأزرار التي نضيفها إلى الصّفحة قلّ وضوحها وسهولة استخدامها، لذا يجب اختيارها بحكمةٍ كما يوضّح الشّكل التّالي: في الشّكل السّابق العديد من العناصر، والكثير من الإجراءات التي يمكن للمستخدم استخدامها، ومع ذلك توجد ثلاثة أزرارٍ فقط تُستخدم وفق ترتيبٍ منطقيٍّ، وهي زرّ اشتر الآن، وزرّ إضافة إلى سلّة المشتريات، وزرّ بيع الآن. كيف تستخدم الأزرار يجب تعيين الزّر الذي نتوقّع اختياره من قِبل المستخدم مثل خيارٍ افتراضيٍّ (أساسيٍّ). يجب تجنّب استخدام الزّر ليشابه سلوك متحكّمات أخرى. يجب استخدام مسافةٍ كافيةٍ بين الأزرار ليتمكّن المستخدم من الضّغط عليها بسهولةٍ. يجب تجنّب عرض صورةٍ في زرّ قياسيٍّ. يجب استخدام فعل، أو جملة فعلية، وكتابة أوائل حروف الكلمات الأجنبية بشكل كبيرة في نصّ الزّر. يجب وضع علامة الحذف (...) في نصّ الزّر إذا كان عمل الزر يؤدّي لفتح نافذةٍ/مربع حوارٍ/تطبيقٍ آخر. يجب الفصل بين الأزرار التي تؤدّي إلى الحذف والأزرار التي لا تؤدي إليه. يجب بدء العمل بعد ضغط الزّر مباشرةً. يجب أن يكون للأزرار المتجاورة نفس العرض، وهذا مهمّ خصوصًا عند استخدام زرّي الموافقة والحذف. يجب عدم تعيين الزّر على أساس زرٍّ افتراضيٍّ، إذا كان ضغطه بالخطأ يؤدّي إلى حذف معلوماتٍ. يجب أن تكون نصوص الأزرار مختصرةً حتّى لا يشغل الزّر مساحةً كبيرةً، ومن المهم أيضًا أخذ تغير طول النص في الحسبان عند ترجمته إلى لغة أخرى (في المواقع متعددة اللغات). الاستخدام الرئيسي حالات الزر التنوع أزرار الأيقونات (Icon buttons): هي الأزرار التي تحوي أيقونةً (icon)، أو صورةً (مصاحبةً لــ/بديلةً عن) نصّ الزّر. أزرار القائمة المتشعبة (Split Menu buttons): هي الأزرار التي تتفعّل بالضّغط عليها، حيث تعرض قائمةً ثانويّةً من الخيارات ضمن قائمةٍ منسدلةٍ (drop-down menu). دليل موجز عن مدخل النص (Text Input) تسمح حقول إدخال النّصّ بإدخال نصٍّ من لوحة مفاتيح المستخدم، لكنّها ليست بتلك البساطة، إذ تستخدم بالتّكرار مع أنواع أخرى من متحكّمات الإدخال في نموذج الإدخال، كما يمكن استخدامها وحدها. متى نستخدم مدخل النص يستخدم لإدخال بياناتٍ في نموذجٍ، كرقم الهاتف، أو اسم المستخدم، أو كلمة المرور، أو تّعليق. وهي من المكوّنات الأساسيّة في النّموذج، حيث تستخدم بالتّكرار في البحث والتّعليقات والدّردشة كما يوضّح الشّكل الموالي: من المهمّ معرفة متى لا نستخدم مدخل النّص، فباتباع إرشادات الاستخدام التي جاء في مقال التّعرف على الذّاكرة والتذكّر في واجهات المستخدم (Memory Recognition and Recall in User Interfaces)، يفضّل استخدامنا للقائمة المنسدلة (dropdown menu) أو متحكّم دخلٍ مقيّدٍ، إذا كنّا نعلم مسبقًا لائحة المدخلات الممكنة الصّحيحة، وذلك لتقليل الأخطاء وتسهيل الإدخال. فمثلًا عند السّؤال عن اسم دولةٍ أو عن الحالة الاجتماعيّة أو طريقة الدّفع، يقترح نظام تصميم الويب الأمريكيّ استخدام مدخل النّصّ عندما "لا يمكنك التنبؤ بإجابة المستخدمين وعند احتمال التنوّع الكبير في إجاباتهم". كيف نستخدم مدخل النص يجب توفق طول حقل مدخل النّصّ مع طول الدّخل المتوقّع. يجب على حقول النص الإشارة لحالتها سواء كانت مفعّلةً أم غير مفعّلةٍ، فارغةً أو ممتلئةً، صحيحةً أو غير صحيحةٍ، ولها عنوانٌ مساعدٌ واضحٌ. يجب محاذاة عنوان الحقل لسطر الإدخال ومرئيًّا دائمًا. يجب ألا يشغل عنوان الحقل عدّة أسطر. يمكن استخدام نصّ تلميحٍ داخل حقل الإدخال على ألّا يحلّ محلّ عنوان الحقل في النّموذج، ويجب الاختفاء عندما يبدأ المستخدم بالطّباعة كما يشرح مقال عناصر تحكّم النماذج Form controls يجب تجنّب تقسيم الأعداد إلى أجزاء منفصلةٍ (كأرقام الهاتف، أو رقم الضّمان الاجتماعيّ، أو بطاقة الائتمان) في حقول إدخالٍ منفصلةٍ (يمكن استخدام بدائل، مثل: أقنعة الإدخال " Input masks"، أو المدخلات المرنة " flexible inputs"). يستخدم مربّع نصّ متعدّد الأسطر (text area) في حال النّصوص الأطول (ويسمى حقل إدخال متعدّد الأسطر) عوضًا عن متحكّمٍ وحيد السّطر. الاستخدام العادي الحالات التنوع دليل موجز عن القائمة المنسدلة (Dropdown Menu) ومربع التحرير (Combo Box) هو متحكّم له عدّة أسماءٍ، حيث يعطي لائحةً من العناصر لنختار منها، وهو مألوف ومتعدّد الاستخدامات، حيث يستخدم يوميٍّا سواء كان اسمه قائمةً منسدلةً، أو مربّع تحريرٍ، أو قائمةً منسحبةً (Pull-down menu)، أو أداة اختيارٍ (Picker)، أو قائمة اختيارٍ (Select menu). تختلف القائمة المنسدلة عن مربّع التّحرير، فمربّع التّحرير هو مزيجٌ من قائمةٍ منسدلةٍ، ومدخل نصٍّ (text input)، وهو مقيّدٍ بلائحة من القيم، حيث يستخدم بكثرة، نظرًا لتمكينه لنا من عرض القيم (كلّها أو جزءٍ منها)، والتي نرغب باختيارها دون الحاجة للمرور على جميع قيم القائمة، طبيعة مربّع التّحرير ليست واضحةً لذلك لا يعرف العديد من المستخدمين إمكانيّة كتابتهم داخله. متى نستخدم القائمة المنسدلة تُعدّ القائمة المنسدلة طريقةً رائعةً لتقديم عددٍ كبيرٍ من الخيارات دون شغل مساحةٍ كبيرةٍ في الصّفحة، وتستطيع تجنّب الأخطاء مقارنةً مع حقول مدخل النّصّ، فالدّخل في القائمة المنسدلة مقيّدٌ بخياراتٍ متاحةٍ. وقد ذُكر في صفحة الأنماط الخاصّة بموقع weli.com، أنّ المستخدم قد يتعرّف على الدّخل الصّحيح، لكنه قد لا يدرك الصّيغة المطلوبة لإدخاله. ومن عيوب القائمة، عدم قدرة المستخدم على رؤية الخيارات كلّها دفعةً واحدةً، كما قد يحتاج وقتًا ومهارةً للتّمرير، ويمكننا استخدام مربّع التّحرير، أو حقل مدخل نصّ تلقائيّ التّعبئة إذا كانت القائمة المنسدلة طويلةً جدًّا. وفقًا لمعايير تصميم الويب الأمريكيّة، فالعدد المثاليّ لعناصر القائمة المنسدلة يجب أن يكون بين سبعة وخمسة عشر عنصرًا، ويُقترح استخدام أزرار الانتقاء (radio buttons) أو مربّع الانتقاء (checkboxes) للقوائم القصيرة. وهناك استثناء من هذه القاعدة في حالة القائمة المألوفة للمستخدم، أي التي يعرف المستخدم محتوياتها قبل النّقر عليها كأيّام السّنة، والأشهر، والولايات، والمقاطعات، والبلدان، وتستخدم صفحة القوائم المنسدلة لموقع GNOME المثال التّالي: إذا كانت القائمة المنسدلة بعنوان (الشّهر) مع تحديد العنصر (كانون الثاني)، فقد يستنتج المستخدم منطقيًا أنّ القائمة تحوي اثني عشر شهرًا دون الحاجة إلى البحث. كيف نستخدم القائمة المنسدلة؟ يجب أن يكون ترتيب عناصر القائمة منطقيًّا (كأن يكون تسلسليّا عند ذكر التّواريخ والأرقام، وأبجديًّا عند ذكر البلدان). يجب أن يكون العنصر الافتراضيّ ذا معنىً (قد يؤدّي التّحديد المسبق لعنصرٍ إلى نتائج سيئةٍ، إذ لا يمكننا التّحقق مما إذا كان المستخدم قد اختاره عمدًا أم لا، لذلك يجب جعل الخيار الافتراضيّ هو عدم تحديد أيّ عنصرٍ). يجب أن تكون عناصر القائمة مرتبطةً لأن القوائم الأطول تحتاج وقتًا أطول للمرور عليها، لذا يجب تجنّب إضافة عناصر قد لا يختارها المستخدم. في القائمة المنسدلة يجب تجنّب وضع عناصر تتغيّر بناءً على دخلٍ في قائمةٍ أخرى في الصّفحة، إذ لا يفهم المستخدمون غالبًا كيف يؤثّر اختيار عنصرٍ في تغيير عنصرٍ آخر. يجب السّماح للمستخدمين بالضّغط على أيّ مكانٍ في عنصر التّحكم لفتحه، لا من سهم القائمة فقط. يجب استخدام تجميع العناصر، أو تصنيفها في القائمة عندما يكون ذلك منطقيًّا، ويجب أن تكون عناوين المجموعات غير قابلة للتّحديد. الاستخدام الرئيسي حالات القائمة المنسدلة التنوع دليل موجز عن زر الانتقاء (Radio Button) ومربع الانتقاء (Checkbox) يسمح كلّ من زرّ الانتقاء ومربّع الانتقاء للمستخدمين بانتقاء عناصر من اللّائحة، ولهما استخدامات وإرشادات مختلفة قد تصعب عمليّة الانتقاء بينهما، لذا توضّح هذه المقالة الفرق بينهما ومتى، وكيف نستخدم كلًّا منهما. متى نستخدم زر الانتقاء ومربع الانتقاء كما هو الحال عند استخدام القائمة المنسدلة، فزرّ الانتقاء ومربع الانتقاء مناسبان عندما يكون هناك مجال من الخيارات المتاحة؛ أمّا الفرق بينهما، فيكمُن في كون زرّ الانتقاء مخصص للحالات التي يتوجّب فيها استخدام خيارٍ واحد فقط (الحالة الاجتماعية، والنوع...)؛ بينما يدعم مربّع الانتقاء عدم الانتقاء، أو الانتقاء المتعدّد (كمثال النّشاطات المفضّلة، أو الاهتمامات). على عكس القائمة المنسدلة يسمح زرّ الانتقاء ومربّع الانتقاء للمستخدمين برؤية كل الخيارات دفعةً واحدة، مما يسرّع من الانتقاء، لكن مشكلتهما الوحيدة هي المساحة التي تشغلانها، وبسبب هذا ينصح المقال المنشور في موقع GNOME حول الأزرار، بعدم استخدام أكثر من 8 خيارات لكلّ مجموعة منها. من الصّعب الانتقاء بين استخدام مربّع الانتقاء وزرّ الانتقاء عندما يكون الخيار ثنائي (نعم/لا)، إذ يمكن استخدام أيّ منهما، وتكون أفضلية الانتقاء للأوضح بينهما، ففي المثال السّابق اُستخدم زرّ الانتقاء من أجل خيارات الزّمن (رقمي/ تناظري)، ويمكن استخدام مربّع انتقاء عوضًا عنه، من الممكن استبدال مربّع انتقاء في المثال السابق (عرض صباحًا / مساءً)، لـ(لا تعرض صباحًا / مساءً). كيف نستخدم زر الانتقاء ومربع الانتقاء دليل موجز لكلاهما يجب استخدام عنوان لوصف كل مجموعة خيارات ما لم يكن المربع لخيار واحد. من الأسهل قراءة وفهم الخيارات العموديّة، لكن يمكن استخدام المحاذاة المستطيلة، أو الأفقيّة عند طباعة الخيارات إن حسّن ذلك تخطيط الصّفحة. لابد من عدم تأدية هذه الخيارات لعملٍ ما، بل يجب استخدام زر عوضًا عنها. يجب أن يتمكّن المستخدمون من الضّغط على (الزّر/ مربع الانتقاء) أو عنوانه لتفعيله. يجب مراعاة اعدادات الانتقاء الافتراضيّ (تجنّب استخدام الأنماط المظلمة). دليل موجز عن أزرار الانتقاء يجب استخدام زرّي انتقاء دائمًا على الأقل، فليس من المنطقيّ استخدام زرّ واحد. تنصّ بعض الإرشادات على تحديد خيار واحد في مجموعة أزرار الانتقاء افتراضيًّا ما لم تكن متأكّدًا من الخيار الذي يجب عليك اختياره عندها أضف خيار عدم انتقاء صريح (مثل: "غير متأكّد"، "لا شيء"، "رفض الحالة"). دليل موجز عن مربعات الانتقاء يجب تجنّب استخدام لغة سلبيّة في العناوين، فقد تكون غير منطقيّة، مثل: (لا تُسجّل). الاستخدام الرئيسي الحالات يمكن إلغاء تفعيل أزرار الانتقاء ومربّعات الانتقاء كما هي الحال مع أغلب متحكّمات النّموذج وفقًا لحاجتنا، الحالة الوحيدة التي تنفرد بها أزرار الانتقاء ومربّعات الانتقاء هي الحالة غير المحدّدة المتعددة (وتسمى أيضًا الحالة المختلطة)، يجب استخدام الحالة (غير المحدّدة / المختلطة) فقط "للإشارة إلى إتمام اختيار بعض -وليس كلّ- الخيارات الفرعيّة، ويجب عدم استخدامها لتمثيل حالةً ثالثةً"، يوضح الشّكل أدناه جميع الحالات. التنوع يمكن استخدام مجموعة مربّعات انتقاء قابلة للتّمرير (scrolling checkbox) عندما لا يكون عدد العناصر معروفًا، أو يمكن للمستخدم تخصيص مجموعة مربّعات الانتقاء عندما تكون المساحة محدودة. قد تبدو أزرار الانتقاء ومربعات الانتقاء مختلفةً على الهاتف المحمول لتحسين اللّمس، عند استخدام نظام iOS على سبيل المثال يمكن استخدام علامات الانتقاء (check marks) للخيارات غير المتقاطعة عوضًا عن أزرار الانتقاء ويمكن استبدال مربع الانتقاء بمفتاح التبديل (toggle switch) عوضًا عنه. ترجمة -وبتصرّف- للمقالات: Text Input Guidelines Button Guidelines Dropdown Menu (Combo Box) Guidelines Radio Button and Checkbox Guidelines من موقع Balsamiq.com اقرأ أيضا المقال التالي: متحكمات واجهة المستخدم -متحكمات التنقل- المقال السابق: مقدمة في تصميم واجهة المستخدم UI ومتحكماتها

تصميم واجهة المستخدم (User Interface) -واختصار (UI)- هو عمليّة تصميم كيفيّة تفاعل المستخدم مع البرنامج، حيث سنتعرف فيما يلي على المبادئ الشّائعة لهذه العمليّة، والتي تتضمّن طريقة تطبيق مبادئ التّصميم، ومتحكّماتها التي هي عبارة عن البنى الأساسيّة لواجهة أيّ تطبيق، حيث يساعد استعمالها -السّليم- المستخدم على التعرّف على منتجك كما ترغب، ويُشعره بالأُلفة، كما يمكّنه من تعلّمه حتى لو لم يستخدم المنتج سابقًا، فمن الضّروري تعرّف المصمّم على المتحكّمات ليقدّم للمستخدم خدمةً جيّدةً. ما هو تصميم واجهة المستخدم؟ من الصّعب إيجاد تعريف دقيق جدًّا لمصطلح تصميم واجهة المستخدم، إذ يُعرّفه موقع ويكيبيديا بأنّه: "تصميم واجهات برنامج المستخدم"، وهذا ليس تعريفًا دقيقًا، حيث يمكن تعريفه بطريقة أفضل على أنّه: "عمليّة تفكيك واجهة المستخدم في الأماكن التي تهمّ مصمّمي الواجهات"، فتصميم الواجهات الجيّد لا يحدث فجأة -كما سنرى-، إذ هناك العديد من الطّبقات في تصميم الواجهات، والعديد من وجهات النّظر التي يتّبعها المصمّم عند إنشاء واجهة مستخدم، وفي الشّكل اللّاحق مثالٌ لواجهة مستخدم نموذجيّة لموقع إلكتروني. هناك اختلافات بسيطة في وجهات نظر واجهات المستخدم في عالم الويب، والهاتف المحمول، والتّطبيقات المكتبيّة، والأنواع الأخرى من البرامج، لكن تُعدّ جميعها برامجًا، حيث تنطبق عليها المبادئ التي سنتطرّق إليها لاحقًا في المقالة. لنتعرّف على تصميم واجهات المستخدم خطوةً بخطوة، ونتعلّم كيف نقترب من تصميم يشبه واجهة تصميم هذا الموقع. طبقة تصميم واجهة المستخدم الأولى: المتحكمات (controls) لنبسط الصفحة المعروضة في الأعلى بعرضها كـإطارٍ شبكيٍّ (wireframe)، قبل تقسيم طبقة المتحكّمات كما في الشّكل التّالي: والآن لنتعرّف على بعض متحكّمات واجهة المستخدم التي استُعملت في بناء هذه الصّفحة كما يوضّح الشّكل التّالي: تُعرّف متحكّمات واجهة المستخدم (والتي تدعى أيضًا العناصر، أو المكوّنات، أو التّطبيقات المصغّرة [widget]) بأنّها أجزاءٌ مستقلّةٌ من واجهة المستخدم تؤدّي وظيفةً واحدة، من أمثلة ذلك الروابط (links)، والأزرار، والأيقونات (icons)، وحتّى النصّ العادي (plain text)، يُعدّ عنصر تحكّم وظيفته وصف، أو عنونة شيء ما في واجهة المستخدم. لكل متحكّم هدفٌ محدّدٌ، ويهتمّ تصميم واجهة المستخدم بعملية اختيار المتحكّم، والهدف منه، وهو ما سنتعرّف عنه لاحقًا. طبقة تصميم واجهة المستخدم الثانية: الأنماط (patterns) يمكننا تبسيط صفحة الموقع بتقليل وضوح الإطار الشّبكي للصّفحة لاستخلاص المتحكّمات المستقلة كما في الشكل: لنفكّر في مجموعات المتحكًمات والغرض منها في الصّفحة. يُعرّف نموذج واجهة المستخدم بأنّه مجموعة من المتحكّمات التي تعمل لحلّ مشكلةٍ محدّدةٍ، وفيما يلي سنتعرّف على بعض النّماذج في هذه الصّفحة: من المفيد أخذ هذه الطّبقة من تصميم واجهة المستخدم بالحسبان حتى قبل الانتقال إلى مستوى المتحكّمات، ليحقّق كل نموذجٍ هدفه بطرق مختلفة ولاستخدام متحكّمات مختلفة. يمكن التعرّف على المزيد عن النّماذج في نماذج تصميم واجهات المستخدم وقوالب تقييمها. طبقة تصميم واجهة المستخدم الثالثة: مبادئ التصميم التّعريف الأكثر شيوعًا لتصميم واجهة المستخدم هو طبقة تصميم المرئي (visual design layer)، لكن هذا التّعريف ليس واضحًا، فالتصميم المرئيّ لا يقتصر على جعل التّصميم جميلًا وحسب، لذا تعُدّ الطريقة الأفضل هي تِعداد تصميم واجهة المستخدم تطبيقًا لتحقيق مبادئ التّصميم المرئيّ، والتي يتأصّل الكثير منها في الفهم العلميّ النفسيّ، أو العصبيّ، أو الفسيولوجيّ، حيث سنغطّي في هذا المنهج مبادئ التّباين (Contrast)، والتّسلسل الهرميّ (Hierarchy)، والتّجاور (Proximity)، والإزاحة (Alignment). يستخدم مصمّمو واجهة المستخدم اختبار "سيكوينت (squint)" لتقييم مبادئ التّصميم، والذي يساعد على تجريد التّصميم إلى مبادئه المرئيّة، وتوجد طريقةٌ بديلة وهي تشويش الصّفحة كما في الشّكل: الهدف في كلا الحالتين هو تجاهل المحتوى للتّركيز على التّأثيرات البصريّة، والتّقنيات. يمكن التّعرف أكثر على مبادئ التّصميم في مبادئ التّصميم المرئيّ. طبقة تصميم واجهة المستخدم الرابعة: القوالب (templates) إذا أخذنا بالحسبان موقع الويب بأكمله، فيمكن النّظر إلى أيّ صفحةٍ من صفحاته على أساس كونها جزء من قالبٍ متكاملٍ منسجمٍ يُعاد استخدامه في الموقع، أكثر من كونها كيانًا منفصلًا خاصًّا بصفحة واحدة فقط، ففي موقعٍ قد يحوي عشرات أو مئات الصّفحات سيكون مفيدًا لكلٍّ من مصممي الموقع، ومطوّريه، وللمستخدم النّهائيّ ظهور هذه الصّفحات متناسقة، وسلوكها لسلوك متشابه عبر الموقع بأكمله. يمكن وصف الموقع الذي كنّا ندرسه حتى الآن كقالب "عرض تفصيليّ لمنتج" والذي يبدو مشابهًا جدًا لعرض أيّ منتج آخر، إذ يوجد قالبُ واجهة مستخدمٍ آخرُ هو "نموذج الفئات (category)" كما في الشّكل التّالي: يمكن لهذا الموقع احتواء قوالب أخرى للتّحقق (checking out)، والشّراء، وعرض نتائج البحث، فقد نطبّق نوعًا مختلفًا من القوالب على كلّ منتج، وتُستخدم كلّ أنواع التّطبيقات طريقة الاعتماد على القالب في التّصميم. التشبيه بالطهو يشير مصطلح "mise en place" في عالم الطّبخ إلى (ترتيب كلّ شيء في مكانه)، لذلك عندما يحين موعد الطّهو يمكن العثور على ما نحتاجه في المكان الذي نتوقّعه أتوماتيكيًّا، والأمر مماثل عندما نستخدم المتحكّمات، والنّماذج حينما تصبح مألوفةً لدينا، إذ سنجد في تطبيق Balsamiq مكوّناتٍ (متحكّماتٍ) في مكتبة واجهة المستخدم، كما يمكننا العثور على وصفات قوالب التّصميم، أو يمكننا إنشاء قوالبنا الخاصّة، كما يمكننا تقديم حلول متكاملة أكثر باستخدام مبادئ التّصميم (المكونات)، والقوالب (الوصفات) عندما نتعلّم كيفيّة ترتيب الأجزاء كلّها معًا. أخيرًا، لنجاح المطعم يجب معرفة كيفيّة تحضير الطّعام الذي يجب طهيه بمكوّناتٍ محدّدةٍ وبحرارةٍ مناسبةٍ، كما يجب تسبيق هذا كلّه تدريبٌ ودراسةٌ. يمكن التّعرّف أكثر على إجرائيّة تصميم واجهة المستخدم في خطوات تصميم واجهة تطبيق من الصفر وفق المعايير الصحيحة. هناك الكثير لنتعلمه لكنّنا لن نتعمّق في هذا المنهاج أكثر، فإذا نجحت في تعلمه فسيساعدك على أن تكون مرتاحًا في تصميم ومراجعة واجهات المستخدم في عملك، ونأمل استمتاعك قليلًا، فهل أنت جاهز؟ لنبدأ بالمكوّنات (متحكّمات واجهة المستخدم). مقدمة في متحكمات واجهة المستخدم (UI Controls) قد يحتار العديد من المصمّمين في الاختيار بين مربّع الانتقاء، وزرّ الانتقاء في نموذج الإدخال (form)، وكذلك في عدد علامات التّبويب الانتقاليّة المراد في الصّفحة، ولحسن الحظّ تحقّقت أفضل الإرشادات في موضوع متحكّمات واجهة المستخدم جيّدًا عبر سنوات (وربّما عقود) من البحث والتّدريب، وسنقدّم في مايلي، وفي المقالات التّالية أنواع متحكّمات واجهة المستخدم الأكثر شيوعًا، وسنشرح وقت وكيفيّة استخدامها، كما سنعرض أمثلةً ستجعلك تشعر بالألفة عند انتقائها واستخدامها في تصميمك الخاصّ. تشبه متحكّمات واجهة المستخدم المكوّنات في وصفة الطّهو، حيث يمكن التّعرف على مذاقها المميّز ومميّزاتها، كما يمكن الارتجال فيها، وانتقاؤها، واستبدالها لتلبية احتياجات المصمّمين، أو المستخدمين. ويمكننا البدء في إعداد وصفتنا الخاصّة (قوالب التّصميم) من الصّفر إذا تعرّفنا على المتحكّمات جيّدًا. فيما يلي لائحة بمتحكّمات واجهة المستخدم التي سنتعرّف عليها، وقد ننظّمها وفقًا لما يلي: متحكّمات الدّخل كالمتحكّمات التي نراها في نموذج الإدخال، ومتحكّمات التّنقل التي تسمح للمستخدمين بالتّنقّل في التّطبيق، أو الموقع، ومتحكّمات الخرج التي توصل المعلومات للمستخدم. وتتمثّل هذه المتحكّمات في كل ممّا يلي: دليل موجز عن الأزرار (Button) دليل موجز عن مدخل النص (Text Input) دليل موجز عن القائمة المنسدلة (Dropdown Menu) دليل موجز عن مربع الانتقاء (Checkbox)، وزر الانتقاء (Radio Button) دليل موجز عن الرابط (Link) دليل موجز عن علامات التبويب (Tab) دليل موجز عن مسار التصفح (Breadcrumb) دليل موجز عن التنقل العمودي (Vertical Navigation) دليل موجز عن شريط القائمة (Menu Bar) دليل موجز عن الحاويات المطوية (Accordion) دليل موجز عن التحقق (Validation) دليل موجز عن أداة التلميح (Tooltip) دليل موجز عن التنبيه (Alert) دليل موجز عن جدول البيانات (Data Table) دليل موجز عن الأيقونة (Icon) سنشرح في المقالات الموالية كلّ نوع من هذه المتحكّمات على حدة، في متحكّمات الدّخل، ومتحكّمات التنقّل، ومتحكّمات الخرج. ترجمة -وبتصرف- للمقال What Is UI Design?‎، والمقال Intro to UI Controls، من موقع Balsamiq.com اقرأ أيضًا المقال التالي: متحكمات واجهة المستخدم: متحكمات الدخل