طريقة التفكير في تصميم UX لتطبيقات Windows - جدول قرار لتحديد ما يُعطى الأولوية في ToC / ToB / المراقبة / الأجهزة الميدانية / الأدوات المقيمة

حين نُفكّر في UX لتطبيق Windows، إذا بدأنا أوّلاً من «هل يبدو modern» و«هل الفراغات أنيقة»، فمن السهل أن نُخطئ الترتيب قليلاً.

في Windows desktop، لا يتحدّد UX بالمظهر وحده.

• إلى أين يمكن إنجاز العمل بلوحة المفاتيح
• هل الافتراض هو الماوس، أم اللمس
• هل يُستخدم لوقت طويل، أم بضع دقائق من حين لآخر
• هل هو مراقبة، أم إدخال، أم جهاز ميداني
• ماذا ينكسر حين نُخطئ
• هل يصمد أمام تكبير النص وthemes ذات التباين والتقنيات المساعدة

كلّ هذه النواحي مُجتمعةً تُشكّل UX.

والأمر الأكثر إرباكاً هو أنّ مركز الثقل يختلف بين ToC وToB.
لكن إذا فكّرنا هنا «بما أنّه ToB، يكفي حشو المعلومات» أو «بما أنّه ToC، يكفي صنعه خفيفاً ولطيفاً»، فعادةً ما يحصل حادث في مكان ما.

مثلاً حتى داخل ToB نفسه،

• التطبيقات المكتبية مثل إدخال الحسابات وإدارة الطلبات والشراء
• الأجهزة الميدانية كالمصانع والمستودعات والاستقبال وأجهزة الفحص
• شاشات التشغيل للمراقبة 24 ساعة والصيانة

شروط UX الجيّد تختلف بشكل ملحوظ بينها.

وبالعكس حتى داخل ToC،

• الأدوات الصغيرة الموجّهة للأفراد
• الأدوات للمستخدمين المتقدّمين كتحرير الصور وإنتاج الموسيقى وتحليل الاستثمار

كثافة الـ UI ومتطلّبات الـ shortcut تختلف اختلافاً تامّاً.

كذلك، فإنّ إرشادات تصميم Windows من Microsoft تُركّز على أنّ تصميم تطبيقات Windows يجب أن يكون بديهياً وسهل الوصول، ويعمل بصورة متّسقة عبر أساليب الإدخال وأشكال الأجهزة.¹²

في هذا المقال، نُنظّم UX تطبيقات Windows في صورة جدول قرار حسب الاستخدام.
الهدف هو تيسير التمييز بين «ما الذي ينبغي لهذا التطبيق إعطاؤه الأولوية» في مراحل مراجعة التصميم والتصميم الأوّلي للشاشات.

1. النتيجة أوّلاً

بصيغة عملية إلى حدّ بعيد وبشكل خشن مُسبقاً، الأمر هكذا.

• في ToC، نُعطي الأولوية أوّلاً لـ سهولة الفهم في المرّة الأولى، الإحساس بالطمأنينة، قلّة الإعدادات، انسيابية مسار الاستخدام
• في ToB، نُعطي الأولوية أوّلاً لـ الكفاءة المستمرّة، منع الخطأ في التشغيل، التوافق مع لوحة المفاتيح، التخطيط الثابت
• ومع ذلك في الأجهزة الميدانية ToB، تُعطى الأولوية لـ الوضوح، أهداف التشغيل الكبيرة، قِصَر مسار الاستخدام قبل الكثافة
• ومع ذلك في أدوات المستخدمين المتقدّمين ToC، تُعطى الأولوية لـ كثافة المعلومات، الـ shortcut، قابلية التخصيص قبل البساطة
• في تطبيقات Windows، التفكير في UX بحيث يشمل لوحة المفاتيح / الماوس / اللمس / تكبير النص / themes ذات التباين / التقنيات المساعدة يُساعد لاحقاً على عدم انكسار التصميم¹³⁴⁵⁶⁷

ما ينبغي حقّاً تحديده أوّلاً ليس فقط ToC أم ToB.
ما نريد صياغته بالكلمات أوّلاً هو الخمسة التالية:

1. مَن سيستخدمه (مبتدئ، خبير، مزيج)
2. أين سيُستخدم (مكتب، قاعة اجتماعات، ميدان، مصنع، استقبال، خارج المبنى)
3. بماذا سيُشغّل (لوحة المفاتيح، الماوس، اللمس، القلم، الباركود، التقنيات المساعدة)
4. إلى أيّ مدى سيُستخدم (مرّة أولى بشكل رئيسي، أحياناً، يوميّاً، طوال اليوم)
5. ما هي كلفة الخطأ (خفيفة، ثقيلة، خطيرة، خاضعة للمراجعة)

حين تتّضح هذه الخمسة، يصبح من السهل تحديد أولويّات كثافة الـ UI، والملاحة، والـ shortcut، وdialog التأكيد، وقابلية التخصيص.

2. ToC / ToB مدخل، لكنّه ليس الجواب

تقسيم ToC / ToB مفيد كأوّل مدخل.
لكنّ ما يُقرّر إجابة UX الصحيحة بقوّة أكبر هو نوع طريقة الاستخدام لا نوع المشتري.

مثلاً إذا نظرنا إلى الأمر بمحورين تقريبيّين، يكون كالتالي.

أي إنّ،

• ToC = UI خفيف دائماً
• ToB = UI عالي الكثافة دائماً

هذا ليس صحيحاً.

إرشادات تصميم تطبيقات Windows أيضاً تُركّز على إمكانية الاستخدام بصورة متّسقة عبر الأجهزة وأنواع الإدخال وأشكال الأجهزة، ومن منظور accessibility، يُعدّ من المهمّ الأخذ بالاعتبار، ليس فقط وجود الإعاقة من عدمها، بل أيضاً قيود البيئة مثل الخارج المُشمس، الفضاءات المُشتركة، الأماكن الهادئة، الأماكن الصاخبة.¹²

لذلك، يُنصح بأنّه بعد رؤية ToC / ToB، يُقطع كذلك بالمحاور التالية.

إذا قُطع هذا أوّلاً، تنخفض كثيراً نقاشات الاجتماعات من نوع «modern بشكل ما» و«شبيه بتطبيق أعمال بشكل ما».

3. جدول القرار حسب الاستخدام في ورقة واحدة

أوّلاً نضع الجدول الأكثر سهولة في الاستخدام عمليّاً.

من هذا الجدول وحده يظهر الاتّجاه بشكل ملحوظ.
المهمّ بشكل خاصّ هو أنّ UI عالي الكثافة ليس الجواب الصحيح للأجهزة الميدانية حتى وإن كانت ToB، وأنّه حتى في ToC، تكون الكفاءة هي الحقّ في أدوات المستخدمين المتقدّمين أكثر من الخفّة.

4. سياسة التصميم حسب الاستخدام

4.1 أدوات ToC / تطبيقات شخصية

في تطبيقات Windows ToC الصغيرة، تكون «قابلة للاستخدام فور التشغيل» قويّةً جدّاً.

ما نريد التركيز عليه بشكل خاصّ هو النقاط التالية:

• معرفة ماذا يفعل التطبيق من الشاشة الأولى
• تركيز العمليات الرئيسية في عمليّة أو اثنتين
• أن لا تكون الحالة الفارغة غير ودودة
• أن تكون العمليات الخطرة قابلة للتراجع
• عدم إظهار جميع الإعدادات منذ البداية

ما يحدث كثيراً هنا هو سرد كلّ ما يمكن إنجازه تقنيّاً.
لكن في الأدوات الخفيفة ToC، قابلية الاستخدام الفورية أكثر قيمةً في كثير من الأحيان من تعدّد الميزات.

إرشادات الملاحة في Windows أيضاً تُشير إلى أنّه ليس هناك جواب واحد يصلح لجميع التطبيقات، وأنّ ما يُركَّز عليه أوّلاً هو الاتّساق، البساطة، الوضوح. واستخدام controls قياسية وأماكن قياسية يجعل الـ UI قابلاً للتنبّؤ.⁸

لذلك، في ToC،

• شاشة واحدة إذا كان صغيراً
• ملاحة علوية إذا كانت الأقسام متوازية
• إظهار الإعدادات بشكل تدريجي
• جعل العمليات الرئيسية مُضيئة، والباقي هادئاً

عادةً ما يكون هذا التنظيم كافياً.

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

4.2 ToB إدخال مكتبي / back office

ما يهمّ في تطبيقات ToB المكتبية ليس خفّة المظهر، بل عدم توقّف العمل.

المستخدمون اليوميّون يعتادون الـ UI خلال أيّام.
ما يصبح فعّالاً بعد ذلك هو:

• إلى أين يمكن الوصول بلوحة المفاتيح فقط
• هل التنقّل بين الإلمام والتفاصيل سهل
• هل يمكن رؤية الأعمدة المهمّة والحالات بنظرة واحدة
• هل يمكن الاحتفاظ بالـ filter وفرز الترتيب
• هل يمكن إصلاح الأخطاء في مكانها

إرشادات Microsoft لـ keyboard accessibility تُشير أيضاً إلى أنّ من المهمّ إمكانية الوصول إلى جميع الميزات بلوحة المفاتيح، ويُوصى بترتيب Tab، والـ focus، والتشغيل بـ Enter / Space، وتنفيذ الـ shortcut.³

كذلك، إنّ access keys ليست مفيدة فقط لـ accessibility، بل أيضاً لتحسين كفاءة power users الذين يُفضّلون لوحة المفاتيح. يُوصى بدعم access keys في الأماكن المناسبة، بما في ذلك الـ controls المخصّصة.⁹

في الإدخال المكتبي، تكون list/detail قويّةً جدّاً كملاحة.
دليل ملاحة Windows يُشير أيضاً إلى أنّ list/detail تُلائم الاستخدامات التي يُتنقّل فيها بين العناصر بشكل متكرّر مع عرض التفاصيل أو تحديثها، وتُلائم حالات مثل صناديق البريد الواردة، قوائم جهات الاتّصال، إدخال البيانات.⁸

أي أنّ هذا التكوين طبيعي جدّاً:

• تصنيف الميزات على اليسار
• الإلمام في الوسط
• التفاصيل / التحرير على اليمين أو الأسفل
• البحث والـ filter والأوامر الرئيسية في الأعلى
• العمليّات المتكرّرة تدعم shortcut

وبالعكس، ما نريد تجنّبه:

• dialog لكلّ عملية
• أعمدة قليلة جدّاً وإلمام منخفض
• العمليات الرئيسية مدفونة في النقر الأيمن فقط
• محاولة التعبير عن المعنى بالأيقونات وحدها
• ترتيب tab فوضوي وعدم عمل Enter ولا Space

بالنسبة لأخطاء الإدخال أيضاً، إخراج أخطاء التحقّق المرتبطة بحقل ضمن الشاشة لا في dialog أكثر طبيعيّة. دليل dialog في Windows يُوصي أيضاً بأنّ أخطاء التحقّق المرتبطة بالسياق، مثل حقول كلمة المرور، لا تُستخدم لها dialog، بل عرض inline.¹⁰

4.3 ToB مراقبة / تشغيل

UX شاشات المراقبة والتشغيل، قبل «سهولة الاستخدام»، يكون عدم التفويت، وعدم الخطأ، وعدم التوقّف هو المهمّ.

ما نريد إعطاءه الأولوية هنا عادةً هو التالي:

• إمكانية معرفة وجود الشذوذ بنظرة واحدة
• إمكانية معرفة درجة أهمّية الشذوذ
• إمكانية تتبّع التغيّرات والتسلسل الزمني، لا القيمة الحالية فقط
• ألّا يكون مسار العمليات الخطرة خفيفاً بشكل مفرط
• إمكانية القفز فوراً إلى log والسجلّ والتحقيق في السبب

في هذا النوع من الشاشات، يكون التعبير عن الحالة هو محور UX.
من الأفضل التعبير عن الحالة بعناصر متعدّدة قدر الإمكان: اللون + النصّ + الأيقونة + الوقت.
التعبير بـ اللون فقط يُسبّب التفويت وأخطاء التمييز، ويضعف في مجال accessibility كذلك.¹¹

بالنسبة للملاحة، إذا كانت أهداف المراقبة كثيرة، فالملاحة اليسارية، والتعمّق في الأهداف الفردية بـ drill-down، والتفاصيل في log أو التسلسل الزمني، يكون هذا التنظيم سهل التعامل.
دليل ملاحة Windows يُشير أيضاً إلى أنّ الملاحة اليسارية تُلائم حالات كثرة العناصر العليا أو التكوينات التي لا يكثر فيها التبديل بين الصفحات.⁸

من ناحية التشغيل، وضع الأوامر في مكان واحد فقط أيضاً خطر.
دليل تصميم الأوامر في Windows يُوصي بأنّ الأوامر يمكن استخدامها من أوجه متعدّدة كالأزرار وcontext menu وshortcut وgesture، ويُوصي بأن تتضمّن جميع الأوامر ذات الصلة في context menu أو CommandBarFlyout. لأنّ الاعتماد على عمليّات تظهر فقط بـ hover يجعلها غير قابلة للاستخدام في الأجهزة اللمسية والتقنيات المساعدة.¹²¹³

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

• كتابة ما الذي سيحدث بوضوح في السطر الأول
• جعل نصّ الزرّ محدّداً مثل حذف / إيقاف / قطع بدلاً من OK / Yes
• وضع زرّ آمن دائماً

هذه الثلاثة هي الحدّ الأدنى الذي يجب الالتزام به.¹⁰

4.4 ToB أجهزة ميدانية / UI أجهزة / أكشاك

الأجهزة الميدانية نوع مختلف تماماً حتى ضمن UX تطبيقات Windows.

• ليس جالساً
• ربّما يلبس قفّازات
• يدٌ واحدة فقط حرّة
• لا ينظر إلى الشاشة بإمعان
• هناك ضغط زمني
• يُستخدم في ميدان مُضيء أو مكان صاخب

هذه الشروط طبيعية.

إرشادات accessibility من Microsoft تُشير أيضاً إلى أنّ تطبيق Windows الجيّد يأخذ في الحسبان، ليس فقط وجود الإعاقة من عدمها، بل أيضاً قيود البيئة بما فيها ضوء الشمس الساطع، الفضاءات المُشتركة، الضوضاء، الصمت، حالات مثل أثناء الطبخ.²

كذلك في تصميم اللمس،

• اللمس لا يحتوي hover
• الإصبع أو اليد يحجبان (occlusion) الـ UI
• بعض أجزاء الشاشة يصعب الضغط عليها بحسب وضعية اليد
• الـ feedback البصري مهمّ

هذه فروق موجودة.⁴

لذا في الأجهزة الميدانية، الاتّجاهات التالية قويّة عادةً:

• جعل الأزرار وعناصر القائمة كبيرة بشكل كافٍ
• تقريبها إلى شاشة واحدة بهدف واحد
• إظهار رد الفعل بعد التشغيل بوضوح
• تقسيم الـ flow إلى مراحل
• الميل في الإدخال قدر الإمكان إلى الاختيار والمسح والصيغ المُهيّأة، لا الإدخال الحرّ
• إخراج الحالة بوضوح في أعلى الشاشة أو وسطها

وبالعكس ما نريد تجنّبه:

• النصوص الصغيرة
• مناطق إصابة صغيرة
• الاعتماد على tooltip بافتراض hover
• الطبقات العميقة
• كميّة كبيرة من المعلومات في شاشة واحدة
• الإدخال الحرّ الطويل

التفكير الخشن «بما أنّه ToB، فكثافة أعلى أفضل» أكثر ما يخطئ في هذا المجال.
هنا في الواقع يُعطى الوضوح أولوية كبيرة حتى ضمن تطبيقات الأعمال.

4.5 أدوات التحرير والتحليل للخبراء

في الأدوات الموجّهة للخبراء، أحياناً يفوز «لا تُوقفني عن العمل» على «اجعله سهل الفهم».

مثلاً،

• CAD
• تحليل الموجات
• تحرير الفيديو
• معالجة الصور
• إنتاج الموسيقى
• دعم التطوير
• تحليل البيانات
• أدوات التدقيق / التشخيص

من هذه الأنواع.

في هذا النوع من التطبيقات، التالي مفيد:

• كثافة المعلومات
• panes متعدّدة
• tab
• context menu
• shortcut
• حفظ الـ layout
• تخصيص الأعمدة والعناصر المعروضة
• Undo / Redo
• استعادة حالة العمل

دليل ملاحة Windows يُشير أيضاً إلى أنّ tab تُلائم حالات الرغبة في فتح وإغلاق وإعادة ترتيب صفحات أو مستندات متعدّدة.⁸
كذلك في تصميم الأوامر في Windows، يُوصى بمشاركة الأوامر عبر أوجه UI متعدّدة، بحيث يمكن الوصول إلى نفس العمليّة حتى بأساليب إدخال مختلفة.¹²

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

لذلك في أدوات المستخدمين المتقدّمين،

• العمليّات عالية التكرار قريبة
• الميزات المُساعِدة في الداخل قليلاً
• الميزات المتقدّمة لا تُحذف بل تُنظّم
• حفظ layout العرض
• تكثيف تشغيل لوحة المفاتيح

هذا التصميم فعّال عادةً.

4.6 الأدوات المقيمة / tray apps

في الأدوات المقيمة، عدم إظهار وجود التطبيق بشكل مفرط، في حدّ ذاته UX.

مثلاً، في التطبيقات مثل،

• حالة المزامنة
• حالة الاتّصال
• النسخ الاحتياطي
• تبديل الصوت / الكاميرا / الجهاز
• VPN / agent / launcher
• مركز التنبيهات

كثيراً ما لا تكون الشاشة الرئيسية هي البطل.

ما نريد إعطاءه الأولوية هو،

• إمكانية اللمس فوراً من tray أو قائمة صغيرة
• معرفة الحالة الحالية
• التنبيه فقط عند الضرورة
• الانتقال مباشرة من التنبيه إلى العمليّة المطلوبة
• ألّا تستولي الشاشة الرئيسية على المقدّمة بشكل مفرط

ما نريد تجنّبه هو،

• إخراج dialog لأمور تافهة
• فتح الشاشة الرئيسية في كلّ تشغيل
• عدم رؤية حالة العمل في الخلفية
• كثرة التنبيهات إلى درجة تجاهلها كلّها

هذا النوع من التطبيقات، عدم الإزعاج يُؤثّر على UX أكثر من «امتلاك ميزات كثيرة».

5. جدول قرار الملاحة

دليل ملاحة Windows يُشير إلى أنّه ليس هناك تصميم ملاحة واحد فعّال لجميع التطبيقات، ويعتمد الاتّساق، البساطة، الوضوح كمبادئ. كذلك، وضع controls قياسية في الأماكن التي يتوقّعها المستخدم يجعل الـ UI قابلاً للتنبّؤ.⁸

عمليّاً، التنظيم بالجدول التالي عادةً ما يكون سهلاً.

دليل ملاحة Windows يُظهر التمييز التالي بشكل خاصّ:⁸

• الملاحة العلوية: حين نريد إظهار جميع عناصر الملاحة على الشاشة
• الملاحة اليسارية: حين تكون العناصر العليا كثيرة، حين لا يكثر التبديل بين الصفحات
• list/detail: حين يكثر تبديل العناصر، وحين يلزم عرض التفاصيل أو تحديثها
• tab: حين نريد فتح وإغلاق مستندات أو صفحات متعدّدة بشكل ديناميكي
• breadcrumb: حين نريد توضيح طريق العودة في طبقات عميقة

باختصار، الملاحة ليست «ذوقاً مظهرياً»، بل انعكاس بنية المعلومات وبنية العمل.

6. جدول قرار أجهزة الإدخال وتصميم الأوامر

تطبيقات Windows تصبح أكثر مرونة وسهولة استخدام كلّما دعمت أساليب إدخال أكثر. دليل Microsoft يُوصي أيضاً بأخذ أكبر عدد ممكن من الإدخالات في الاعتبار، مثل gesture، الصوت، اللمس، touchpad، الماوس، لوحة المفاتيح.¹⁴

كذلك، controls منصّة Windows تستوعب أساليب إدخال متعدّدة إلى حدّ ما، لذلك استخدام controls قياسية بشكل مباشر هو الأقوى أوّلاً.⁴⁸

التنظيم العملي السهل هو التالي.

في ما يتعلّق بلوحة المفاتيح، التالي مهمّ بشكل خاصّ:³⁹

• إمكانية الوصول إلى جميع الميزات بلوحة المفاتيح وحدها
• ألّا يبتعد ترتيب Tab كثيراً عن الترتيب البصري
• إمكانية ضغط العناصر التي يجب ضغطها بـ Enter / Space
• وجود shortcut للميزات المهمّة
• تجهيز access keys أو accelerator للعمليّات عالية التكرار

في ما يتعلّق باللمس، التالي مهمّ:⁴

• لا يوجد hover
• الإصبع أو اليد يحجبان الـ UI
• المكان القابل للضغط يبدو أضيق من المظهر
• يلزم feedback بصري
• الـ UI الذي يُلائم التشغيل المباشر يختلف عن الـ UI الذي يُلائم الإدخال غير المباشر

في تصميم الأوامر، دليل أوامر Windows مرجع جيّد جدّاً.
المهمّ بشكل خاصّ هو جعل الأوامر قابلة للاستخدام من أوجه UI متعدّدة.¹²

• يمكن الضغط من زرّ
• موجودة في context menu أيضاً
• يمكن استدعاؤها بـ shortcut
• إذا لزم الأمر، swipe أو gesture أيضاً

ويُوصى أيضاً بـ إدراج جميع الأوامر ذات الصلة في context menu أو CommandBarFlyout. الاعتماد على عمليّات تظهر فقط أثناء hover يجعلنا نعلق في أجهزة اللمس.¹²

7. عناصر UX التي لا نريد تفويتها كحدّ أدنى في تطبيقات Windows

من هنا، نُلخّص ما نريد التأكيد عليه كحدّ أدنى بصرف النظر عن الاستخدام.

7.1 هل يمكن الإنجاز بلوحة المفاتيح

في Windows desktop، لوحة المفاتيح ليست «مفيدة إذا وُجدت»، بل هي خطّ رئيسي إلى حدّ بعيد.

دليل Microsoft لـ keyboard accessibility أيضاً يُشير إلى أنّ دعم لوحة المفاتيح مهمّ، ليس فقط للمستخدمين ذوي القيود البصرية أو الحركية، بل أيضاً للمستخدمين الذين يختارون لوحة المفاتيح لغرض الكفاءة.³

ما نريد رؤيته كحدّ أدنى هو التالي:

• هل ترتيب Tab طبيعي
• هل هناك تصوير للـ focus
• هل يمكن الضغط بـ Enter / Space
• هل هناك shortcut
• هل يمكن استدعاء العمليّات المُكافئة للنقر الأيمن من لوحة المفاتيح

أمر متواضع، لكن إذا انكسر هنا، يتألّم UX في ToB كثيراً.

7.2 تكبير النص، themes ذات التباين، accessibility

في تطبيقات Windows، مجرّد التتبّع الصحيح لحجم النصّ والتباين يُثبّت UX بشكل ملحوظ.

دليل Microsoft يُوصي بأنّ نسبة التباين للنصّ المرئي 4.5:1 على الأقلّ، ويتطلّب أنّه عند تكبير النصّ، تُعاد أبعاد controls والحاويات وتُرتّب جنباً إلى جنب.⁵⁶

كذلك في themes ذات التباين،

• عدم تثبيت الألوان
• استخدام موارد SystemColor / Brush
• التجربة بأربعة أنواع من themes ذات التباين

يُوصى بذلك.⁷

ما يسهل انكساره هنا:

• labels بافتراض عرض ثابت
• ارتفاعات أزرار مُثبّتة بـ pixel
• تصميم ينقل المعنى باللون فقط
• UI بـ rendering مخصّص لا يتتبّع الـ theme

التفكير في هذه المنطقة كـ أعمال أساسية لصنع UI Windows لا ينكسر طويلاً أكثر من «دعم accessibility» يُلائم بشكل أكبر.

7.3 عدم الإفراط في dialog

dialog مفيد، لكن الإفراط فيه يُصبح عدوّ العمل.

دليل dialog في Windows يُشير إلى أنّ dialog هو UI modal عند الحاجة إلى التنبيه أو الموافقة أو إدخال معلومات إضافية، ويُوصى بوضع عمليّة آمنة وغير مدمّرة على الأقلّ (Close، Cancel، إلخ). كذلك، يُفضّل أن يكون نصّ الزرّ استجابة محدّدة.¹⁰

المهمّ هو عدم تحويل كلّ شيء إلى dialog.

بشكل خاصّ،

• أخطاء الإدخال على مستوى الحقل
• أخطاء الصيغ التي يمكن إصلاحها في مكانها
• التنبيهات المؤقّتة

من الطبيعي الميل قدر الإمكان إلى عرض inline.¹⁰

7.4 الأوامر المهمّة لها مسارات متعدّدة

في تصميم الأوامر في Windows، يُركَّز على إمكانية استدعاء الأوامر المهمّة من أساليب إدخال وأوجه UI متنوّعة.¹²¹³

هذا مهمّ جدّاً عمليّاً.

مثلاً «حذف»،

• toolbar
• context menu
• مفتاح Delete
• swipe إذا لزم

إذا توفّرت مسارات متعدّدة كهذه، تستقرّ سهولة الاستخدام.

وبالعكس،

• يظهر في الجانب الأيمن فقط عند hover
• يظهر فقط بالنقر الأيمن
• لا يمكن الوصول إليه أبداً بلوحة المفاتيح

هذا التصميم يضعف فجأة عند تغيير أسلوب الإدخال.

7.5 التحقّق بأدوات الاختبار

التحقّق من accessibility بالأدوات أسرع من التفكير في الرأس «على الأرجح بخير».

دليل اختبار accessibility من Microsoft يُقدّم Live Inspect وFastPass وTroubleshooting باستخدام Accessibility Insights for Windows، وكذلك يمكن التحقّق من خصائص UI Automation وبنية الملاحة بـ Inspect من الـ SDK.¹⁵

كحدّ أدنى،

• المسح السريع بـ Accessibility Insights
• التحقّق من اسم العنصر الرئيسي ودوره ونمطه بـ Inspect
• اجتياز الـ flow الرئيسي بلوحة المفاتيح وحدها
• تجربة تكبير النصّ وthemes ذات التباين

القيام بهذا القدر يُقلّل التراجع.

7.6 إدخال قابلية الاسترداد

هذا ليست قائمة تحقّق سطر واحد من Microsoft، بل قصّة فعّالة جدّاً عمليّاً في Windows desktop.

UX لا يتحدّد بـ «أزرار يُمتع الضغط عليها» وحدها، بل بـ إمكانية العودة حتى عند وقوع حادث.

مثلاً،

• Undo / Redo
• الحفظ التلقائي
• الاحتفاظ بحالة التحرير
• استعادة filter / فرز / عرض الأعمدة
• الإيقاف والاستئناف
• التقدّم وإلغاء العمليّات الطويلة

تُؤثّر على UX أكثر بكثير من المظهر.

في ToB والمستخدمين المتخصّصين بشكل خاصّ، ضغط إعادة العمليّة يصبح مباشرةً سوء UX.

8. أخطاء التصميم الشائعة

8.1 الاعتقاد بأنّ ToB يعني الكثافة العالية

هذا صحيح بشكل جزئي فقط.

في حال المُحترفين الذين يستخدمونه يوميّاً، قد تكون الكثافة العالية فعّالة.
لكن في الأجهزة الميدانية وأجهزة الاستقبال وUI الأجهزة، الكثافة في الواقع عدوّ.

النظر إلى مستوى الاحتراف وأسلوب الإدخال وبيئة الاستخدام، لا تسمية ToB، أقلّ خطأً.

8.2 إخفاء الميزات بشكل مفرط لأنّه ToC

حتى للأفراد، إذا كانت أداة للمحترفين، فالكفاءة هي الأولوية القصوى.

إذا انحرفنا في كلّ شيء نحو «إظهاره بسيطاً»،

• العمليّات عالية التكرار بعيدة
• الحفر في القائمة في كلّ مرّة
• الاستمرار في تبديل الشاشات

يبدأ جحيم هادئ.

8.3 صنع عمليّات بافتراض hover

اللمس لا يحتوي hover.
كذلك، الـ UI الذي يظهر فقط بالمؤشّر يميل إلى ضعف التوافق مع التقنيات المساعدة.⁴¹²

العمليّات المهمّة، إمّا أن تكون مرئيّة دائماً، أو على الأقلّ تمتلك مسارات متعدّدة، يكون أكثر أماناً.

8.4 نقل الحالة باللون فقط

هذا كثير في شاشات المراقبة بشكل خاصّ، لكن نقل المعنى بالأحمر / الأصفر / الأخضر فقط خطر.

الجمع بين النصّ والأيقونة والوقت والعدد والوصف يُقلّل التفويت والخطأ في التمييز.¹¹

8.5 جعل جميع أخطاء التحقّق dialog

كثير في أنظمة الإدخال المكتبي.
إذا ظهر dialog في كلّ إدخال، ينكسر إيقاع العمل تماماً.

الأخطاء المغلقة على السياق، إخراجها في مكانها داخل الشاشة أكثر طبيعيّة.¹⁰

8.6 الصنع بـ layout بحجم مُثبّت

حتى لو بدا أنيقاً في بيئة التطوير بعرض 100%،

• تكبير النصّ
• DPI عالٍ
• themes ذات التباين
• localization

ينكسر بسهولة.⁶⁷

كلّما رفعنا اكتمال المظهر، يُصبح افتراض التثبيت سامّاً بسهولة.

8.7 الإفراط في صنع controls مخصّصة

controls قياسية في Windows تمتلك سلوكيّات أكثر بكثير ممّا يبدو.

• focus
• لوحة المفاتيح
• تتبّع theme
• UI Automation
• الاتّصال بالتقنيات المساعدة

بما أنّها تتولّى ذلك كلّه، صنع كلّ شيء بشكل ذاتي بلا سبب يُزيد ديون UX وaccessibility.⁸³

9. ثمانية أسئلة نُحدّدها قبل البدء

أخيراً، نضع ثمانية أسئلة مفيدة لوضعها في بداية مراجعة التصميم.

إذا أجبنا على هذه الثمانية أسئلة أوّلاً،

• هل ينبغي أن تكون الملاحة سطحية
• هل إلمام + تفاصيل أفضل
• هل ينبغي تكثيف shortcut
• أين ينبغي استخدام dialog
• إلى أيّ مدى نسمح بالتخصيص

تتحدّد بشكل طبيعي إلى حدّ كبير.

10. الخلاصة

ما يهمّ في تصميم UX لتطبيقات Windows هو،
تحديد «هل يستطيع ذلك الشخص، في ذلك المكان، بأسلوب الإدخال ذلك، استخدامه دون توقّف» قبل «هل هو أنيق».

بالتنظيم الخشن، الأمر هكذا.

• ToC يُعطي الأولوية للفهم في المرّة الأولى والإحساس بالطمأنينة
• ToB المكتبي يُعطي الأولوية للكفاءة المستمرّة ودعم لوحة المفاتيح
• ToB المراقبة تُعطي الأولوية لمنع التفويت والتشغيل الآمن
• الأجهزة الميدانية ToB تُعطي الأولوية لأهداف التشغيل الكبيرة والمسار القصير
• أدوات الخبراء تُعطي الأولوية للكثافة وshortcut والتخصيص
• الأدوات المقيمة تُعطي الأولوية لعدم الإزعاج

والمشترك الفعّال بصرف النظر عن الاستخدام هو التالي:

1. استخدام controls قياسية بشكل مباشر
2. إنجاز العمليّات الرئيسية بلوحة المفاتيح
3. عدم الانحشار باللمس أو التقنيات المساعدة
4. عدم الانكسار بتكبير النصّ أو themes ذات التباين
5. تجهيز مسارات متعدّدة للأوامر المهمّة
6. إمكانية العودة حتى عند وقوع حادث

UX ليس زخرفة، بل عقد تشغيل.
كلّما تطابق ذلك العقد مع المستخدم والبيئة وأسلوب الإدخال، تصبح تطبيقات Windows سهلة الاستخدام بشكل متواضع لكنّه قويّ.

11. المراجع

مقالات ذات صلة

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

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

يركّز على تطوير برامج ويندوز، والاستشارات التقنية، والتحقيق في الأخطاء، ويتميّز في المشاريع التي تبقى فيها الأصول القديمة ناشطة، وفي تشخيص الأعطال التي يصعب تحديد سببها.