تصميم UX لتطبيقات Windows - أولويات حسب بيئة الاستخدام

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

في سطح مكتب Windows، لا يتحدد UX بالمظهر وحده.

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

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

flowchart TB
    accTitle: UX لا يتحدد بالمظهر وحده
    accDescr: مخطّط يبيّن أن إكمال العمل بلوحة المفاتيح، وماوس أم لمس، ومدة الاستخدام والغرض، وأثر الخطأ أو الخسارة، وإمكان التشغيل مع تقنيات مساعدة مثل قارئ الشاشة، كلها مجتمعة تشكّل UX.
    a1["أسلوب الإدخال ومدى اكتمال التشغيل"] --> a4["كلها مجتمعة UX"]
    a2["مدة الاستخدام والغرض"] --> a4
    a3["تكلفة الخطأ والتقنيات المساعدة"] --> a4
    a4 -.-> a5["البدء من «هل يبدو حديثاً» يخطئ الترتيب"]

الشكل 1: UX سطح مكتب Windows يُحسم بحزمة سياق الاستخدام قبل المظهر.

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

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

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

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

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

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

تختلف كثافة الواجهة ومتطلبات الاختصارات اختلافاً تاماً.

flowchart TB
    accTitle: الشروط تختلف حتى داخل التسمية نفسها
    accDescr: مخطّط يبيّن أن شروط UX الجيد تختلف كثيراً داخل BtoB بين تطبيق مكتبي وجهاز ميداني وشاشة تشغيل، وأن الكثافة ومتطلبات الاختصارات تختلف تماماً داخل BtoC بين أداة صغيرة وأداة متقدمة.
    b0["تسمية BtoB نفسها"] --> b1["مكتبي وجهاز ميداني وشاشة تشغيل"]
    b1 --> b2["شروط UX الجيد تختلف كثيراً"]
    c0["تسمية BtoC نفسها"] --> c1["أداة خدمة وأداة متقدمة"]
    c1 --> c2["الكثافة ومتطلبات الاختصارات تختلف"]

الشكل 2: حتى داخل تسمية BtoC / BtoB نفسها تنقسم شروط UX الجيد.

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

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

القارئ المستهدف والافتراضات في هذه المقالة

مصطلحات مستخدمة في هذه المقالة

1. الخلاصة أولاً

بصيغة خشنة مسبقاً، الأمر هكذا.

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

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

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

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

flowchart TB
    accTitle: خمسة أسئلة نُصيغها أولاً
    accDescr: مخطّط يبيّن أنه إذا اتضح من يستخدم، وأين، وبماذا، وكم، وما تكلفة الخطأ، يسهل تحديد أولويات كثافة الواجهة والتنقل ومربعات التأكيد.
    q1["1. من يستخدمه"] --> q2["2. أين يُستخدم"]
    q2 --> q3["3. بماذا يُشغَّل"]
    q3 --> q4["4. كم يُستخدم"]
    q4 --> q5["5. ما تكلفة الخطأ"]
    q5 --> q6["تُحسم أولويات الكثافة والتنقل والمربعات"]

الشكل 3: صياغة الأسئلة الخمسة قبل BtoC أو BtoB تحسم الأولويات.

في المخطّط، يشير الخطّ المتّصل إلى علاقة قائمة دائماً، ويشير الخطّ المتقطّع إلى علاقة مشروطة (شروط قيامها مذكورة في شرح كلّ علاقة في الصفحة التفصيليّة). القائمة الكاملة للعلاقات (المجموع 23، مع الأدلّة ودرجة اليقين) وتعريفات المفاهيم الرئيسة مجمّعة في صفحة تفاصيل خريطة المعرفة (باليابانية). البيانات: JSON-LD / Turtle

2. BtoC / BtoB مدخل، لكنه ليس الجواب

تقسيم BtoC / BtoB مريح كمدخل أول. لكن القوة التي تحسم جواب UX الصحيح أقوى في نوع الاستخدام منها في نوع المشتري.

مثلاً بمحورين خشنين الأمر هكذا.

أي أن:

• BtoC = واجهة خفيفة دائماً
• BtoB = واجهة عالية الكثافة دائماً

لا يصح.

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

flowchart TB
    accTitle: نوع الاستخدام أقوى من نوع المشتري
    accDescr: مخطّط يبيّن أن معادلة BtoC = واجهة خفيفة دائماً و BtoB = واجهة عالية الكثافة دائماً لا تصح، وأن القوة التي تحسم جواب UX الصحيح أقوى في نوع الاستخدام.
    e1["BtoC = واجهة خفيفة دائماً"] --> e3["هذه المعادلة لا تصح"]
    e2["BtoB = واجهة عالية الكثافة دائماً"] --> e3
    e3 --> e4["ما يحسم الجواب نوع الاستخدام"]
    e4 -.-> e5["نفكّر حتى بقيود البيئة"]

الشكل 4: ما يحسم جواب UX الصحيح نوع الاستخدام لا نوع المشتري.

لذا بعد النظر إلى BtoC / BtoB نوصي بالقطع أيضاً بهذه المحاور.

قطع هذا مسبقاً يقلّل كثيراً نقاش «حديث بطريقة ما» و«يشبه الأعمال بطريقة ما» أثناء الاجتماع.

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

نضع أولاً الجدول الأسهل استخداماً في العمل.

بهذا الجدول وحده يتضح الاتجاه تقريباً. المهم خصوصاً أن حتى في BtoB ليست الواجهة عالية الكثافة جواب أجهزة الميدان، وأن حتى في BtoC تصبح الكفاءة أعدل من الخفة في أدوات المتقدمين.

flowchart TB
    accTitle: مثالان تنعكس فيهما التسمية والجواب
    accDescr: مخطّط يبيّن مثالين ينعكس فيهما الجواب المتخيَّل من التسمية: أجهزة الميدان BtoB ليست الواجهة عالية الكثافة جوابها، وأدوات المتقدمين BtoC الكفاءة فيها أعدل من الخفة.
    f1["جهاز ميداني BtoB"] --> f2["الواجهة عالية الكثافة ليست الجواب"]
    f3["أداة متقدمة BtoC"] --> f4["الكفاءة أعدل من الخفة"]
    f2 --> f5["نحسم بالاستخدام لا بالتسمية"]
    f4 --> f5

الشكل 5: الصفّان الأهم في جدول القرار، حيث تنعكس التسمية والجواب.

إن كنت مستعجلاً يجوز التوقف عند هذا الفصل. الفصل 4 التالي يوسّع كل صف في هذا الجدول حتى «لماذا يصير كذلك» و«ماذا نضع تحديداً». يمكن استخدامه لقراءة مواد الحكم التي لم يتسع لها الجدول، دون تكرار الخلاصة نفسها.

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

4.1 أداة خدمة / تطبيق أفراد BtoC

في تطبيق Windows صغير BtoC، أقوى ما يكون أولاً «يمكن استخدامه فور التشغيل».

ما نريد التركيز عليه خصوصاً هذه الناحية.

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

ما يسهل الوقوع فيه هنا صفّ كل ما يمكن تقنياً. لكن في أداة BtoC خفيفة، كثيراً ما تكون قيمة «يمكن استخدامه فوراً» أكبر من «متعدد الوظائف».

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

لذا في الموجّه إلى BtoC غالباً يكفي ترتيب من قبيل:

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

flowchart TB
    accTitle: اتجاه الترتيب الموجّه إلى BtoC
    accDescr: مخطّط يبيّن أنه في الموجّه إلى BtoC غالباً يكفي ترتيب محوره إمكان الاستخدام فور التشغيل: شاشة واحدة إن كان صغيراً، وتنقل علوي إن كانت الأقسام متوازية، وعرض الإعدادات تدريجياً، وإضاءة الإجراء الرئيس وهدوء الباقي.
    g1["يمكن استخدامه فور التشغيل"] --> g2["إن كان صغيراً فشاشة واحدة"]
    g1 --> g3["إن كانت متوازية فتنقل علوي"]
    g1 --> g4["الإعدادات تُعرض تدريجياً"]
    g4 -.-> g5["الإجراء الرئيس مضيء والباقي هادئ"]

الشكل 6: الأداة الخفيفة BtoC تُرتَّب بالميل إلى «يمكن استخدامه فوراً» قبل «متعدد الوظائف».

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

4.2 إدخال مكتبي / مكتب خلفي BtoB

في تطبيق BtoB مكتبي، أهم من خفة المظهر هو ألا يتوقف العمل.

المستخدم اليومي يعتاد الواجهة في أيام. ما يؤثّر بعد ذلك هذه الأجزاء.

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

حتى إرشاد إمكانية الوصول بلوحة المفاتيح من Microsoft يعد مهماً أن يصل التطبيق إلى كل الوظائف بلوحة المفاتيح، ويوصي بتنفيذ ترتيب Tab والتركيز والتشغيل بـ Enter / Space والاختصارات.³

كذلك مفاتيح الوصول ليست لإمكانية الوصول فقط، بل تفيد أيضاً رفع كفاءة المستخدمين الأقوياء الذين يفضّلون لوحة المفاتيح. في المواضع المناسبة يُوصى بدعم مفاتيح الوصول حتى في العناصر المخصصة.⁹

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

أي أن تكويناً كهذا صريح.

• يساراً تصنيف الوظائف
• في الوسط قائمة
• يميناً أو أسفل تفاصيل / تحرير
• أعلى بحث ومرشّح وأوامر رئيسة
• التشغيل كثير الاستخدام يدعم الاختصارات

flowchart TB
    accTitle: تكوين صريح للإدخال المكتبي
    accDescr: مخطّط يبيّن تكويناً صريحاً لإدخال مكتبي: أعلى بحث ومرشّح وأوامر رئيسة، يساراً تصنيف وظائف، في الوسط قائمة، يميناً أو أسفل تفاصيل وتحرير، والتشغيل كثير الاستخدام يدعم الاختصارات.
    h1["أعلى: بحث ومرشّح وأوامر رئيسة"] --> h2["يسار: تصنيف وظائف"]
    h2 --> h3["وسط: قائمة"]
    h3 --> h4["يمين أو أسفل: تفاصيل وتحرير"]
    h4 -.-> h5["التشغيل كثير الاستخدام يدعم الاختصارات"]

الشكل 7: تكوين شاشة إدخال مكتبي صريح محوره قائمة/تفاصيل.

وبالعكس نذكر أيضاً أنماطاً نريد تجنّبها.

• مربع لكل عملية
• أعمدة قليلة جداً فتنخفض قابلية القائمة
• التشغيل الرئيس في عمق النقر الأيمن فقط
• محاولة تمثيل المعنى بالأيقونة وحدها
• ترتيب Tab فوضوي ولا يعمل Enter ولا Space

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

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

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

الأولويات هنا تقريباً هكذا.

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

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

flowchart TB
    accTitle: الحالة تُمثَّل بعناصر متعددة
    accDescr: مخطّط يبيّن أن تعبير الحالة مركز UX في شاشة المراقبة والتشغيل، وأن التمثيل باللون وحده يسهل التفويت وخطأ التمييز، لذا أأمن التمثيل بلون ونص وأيقونة ووقت.
    i1["تمثيل الحالة باللون وحده"] --> i2["يسهل التفويت وخطأ التمييز"]
    i2 -.->|"بدلاً من ذلك"| i3["تمثيل بلون + نص + أيقونة + وقت"]
    i3 --> i4["يقل التفويت وسوء الفهم فيصير أأمن"]

الشكل 8: حالة شاشة المراقبة تُمثَّل بمجموعة عناصر متعددة لا باللون وحده.

التنقل إن كثرت أهداف المراقبة فتنقل أيسر، والحفر في هدف فردي drill-down، والتفاصيل بسجلات أو سلسلة زمنية، هذا الترتيب سهل التعامل. حتى دليل تنقل Windows يعد التنقل الأيسر مناسباً عندما تكون البنود العليا كثيرة أو لتكوين لا تتبدّل فيه الصفحات بلا انقطاع.⁸

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

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

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

.¹⁰

flowchart TB
    accTitle: ثلاثة مبادئ لمربع التأكيد
    accDescr: مخطّط يبيّن أن ما يستحق التأكيد حقاً عمليات أقرب إلى غير قابلة للعكس مثل إيقاف وحذف وقطع، فإن أظهرت مربعاً فاكتب ما سيحدث في السطر الأول، واجعل نص الزر محدداً، وضع دائماً زراً في جهة الأمان.
    j1["أكّد العمليات الأقرب إلى غير قابلة للعكس فقط"] --> j2["ما سيحدث في السطر الأول"]
    j1 --> j3["نص الزر محدّد"]
    j1 --> j4["ضع دائماً زراً في جهة الأمان"]
    j2 -.-> j5["«نؤكّد كل شيء مؤقتاً» أثر عكسي"]

الشكل 9: مربعات التأكيد تُضيَّق إلى عمليات غير قابلة للعكس، مع حفظ ثلاثة حدود دنيا.

4.4 جهاز ميداني / واجهة جهاز / kiosk BtoB

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

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

هذه شروط شائعة.

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

كذلك في تصميم اللمس فروق مثل:

• لا hover في اللمس
• الواجهة تُحجب (occlusion) بالإصبع أو اليد
• جزءاً من الشاشة يصعب ضغطه بسبب وضع اليد
• التغذية الراجعة البصرية مهمة

.⁴

flowchart TB
    accTitle: أربعة فروق في تصميم اللمس
    accDescr: مخطّط يبيّن فروقاً في التصميم: لا hover في اللمس، والواجهة تُحجب بالإصبع أو اليد، وجزءاً من الشاشة يصعب ضغطه بسبب الوضع، والتغذية الراجعة البصرية مهمة.
    k1["تشغيل لمس"] --> k2["لا hover"]
    k1 --> k3["الواجهة تُحجب بالإصبع أو اليد"]
    k1 --> k4["أماكن يصعب ضغطها بسبب الوضع"]
    k4 -.-> k5["تصير التغذية الراجعة البصرية مهمة"]

الشكل 10: اللمس يختلف في افتراض hover والحجب، وطريقة إظهار التغذية الراجعة تصير أساسية.

لذا في جهاز الميدان نميل تقريباً بهذا الاتجاه.

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

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

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

.

أخطر فكرة خشنة تفوت هنا: بما أنه BtoB فالأفضل كثافة أعلى. هنا بالعكس عالم إعطاء الأولوية للوضوح خصوصاً حتى داخل تطبيقات الأعمال.

flowchart TB
    accTitle: جهاز الميدان أولويته الوضوح
    accDescr: مخطّط يبيّن اتجاه إعطاء الأولوية للوضوح خصوصاً حتى داخل تطبيقات الأعمال: الاقتراب من غرض واحد لكل شاشة، وإمالة الإدخال نحو اختيار ومسح وقالب، وإظهار رد الفعل بعد التشغيل بوضوح.
    l1["جهاز ميداني وواجهة جهاز"] --> l2["الاقتراب من غرض واحد لكل شاشة"]
    l1 --> l3["إمالة الإدخال نحو اختيار ومسح وقالب"]
    l1 --> l4["إظهار رد الفعل بعد التشغيل بوضوح"]
    l2 --> l5["أولوية وضوح خصوصاً حتى داخل تطبيقات الأعمال"]
    l3 --> l5
    l4 --> l5

الشكل 11: جهاز الميدان يُمال إلى الوضوح وأهداف تشغيل كبيرة ومسار قصير لا الكثافة.

4.5 أدوات تحرير وتحليل متخصصة

في الأدوات الموجّهة إلى متخصصين قد ينتصر «لا أريد أن تتوقف اليد» على «أريد أن يكون مفهوماً».

مثلاً أشياء مثل:

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

.

في هذا النوع من التطبيقات تؤثّر عناصر كهذه.

• كثافة المعلومات
• ألواح متعددة
• تبويبات
• قائمة سياق
• اختصارات
• حفظ التخطيط
• تخصيص الأعمدة وبنود العرض
• Undo / Redo
• استعادة حالة العمل

حتى دليل تنقل Windows يعد التبويبات مناسبة لحالة نريد فيها فتح صفحات أو مستندات متعددة وإغلاقها وإعادة ترتيبها.⁸ كذلك تصميم أوامر Windows يوصي بمشاركة الأوامر عبر أوجه واجهة متعددة حتى يمكن بلوغ العملية نفسها حتى لو اختلف أسلوب الإدخال.¹²

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

لذا في الموجّه إلى متقدمين يؤثّر تصميم من قبيل:

• التشغيل عالي التكرار قريب
• الوظائف المساعدة أعمق قليلاً
• الوظائف المتقدمة تُرتَّب دون محوها
• حفظ تخطيط العرض
• تغليظ تشغيل لوحة المفاتيح

flowchart TB
    accTitle: فكرة الوضع الموجّه إلى متمرس
    accDescr: مخطّط يبيّن أن المتمرس ينفّذ العملية نفسها مئات المرات يومياً، فالمهم ألا يتعب بعد 100 ساعة أكثر من لطف الدقائق الخمس الأولى، فيُوضع التشغيل عالي التكرار قريباً والمساعد أعمق قليلاً والمتقدم يُرتَّب دون محوه.
    n1["المتمرس ينفّذ العملية نفسها مئات المرات يومياً"] --> n2["التشغيل عالي التكرار يُوضع قريباً"]
    n1 --> n3["الوظائف المساعدة أعمق قليلاً"]
    n1 --> n4["المتقدم يُرتَّب دون محوه"]
    n2 -.-> n5["صعوبة التعب بعد 100 ساعة قبل لطف الدقائق الخمس"]

الشكل 12: الأداة المتخصصة تضع الوظائف على مسافة تناسب تكرار التشغيل.

4.6 أداة مقيمة / تطبيق علبة

في المقيم، ألا تُفرط في إظهار وجود التطبيق هو UX بالأحرى.

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

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

غالباً ليست الشاشة الرئيسة هي البطلة.

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

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

.

ما نريد تجنّبه:

• إظهار مربع لأمر تافه
• فتح الشاشة الرئيسة في كل تشغيل
• حالة عمل الخلفية غير مرئية
• إشعارات كثيرة جداً فيُتجاهل الكل

.

هذا النوع من التطبيقات أسهل أن يُحسم UX فيه بـ هل يزعج أكثر من «هل يحمل وظائف كثيرة».

flowchart TB
    accTitle: UX الأداة المقيمة ألا تزعج
    accDescr: مخطّط يبيّن أن المقيم يعطي الأولوية لللمس فوراً من العلبة أو قائمة صغيرة، وفهم الحالة الآن، والإشعار عند الحاجة فقط، وأن كثرة الإشعارات تجعل الكل يُتجاهل.
    r1["اللمس فوراً من العلبة"] --> r4["ألا تزعج هو UX"]
    r2["فهم الحالة الآن"] --> r4
    r3["إشعار عند الحاجة فقط"] --> r4
    r4 -.-> r5["كثرة الإشعارات تجعل الكل يُتجاهل"]

الشكل 13: الأداة المقيمة تصير UX بعدم الإفراط في إظهار الوجود.

5. جدول قرار التنقل

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

flowchart TB
    accTitle: مبادئ تصميم التنقل
    accDescr: مخطّط يبيّن أنه لا يوجد نمط تنقل واحد صحيح لكل التطبيقات، فالمبادئ الاتساق والبساطة والوضوح، ووضع عناصر قياسية حيث يُتوقع لتصير الواجهة سهلة التوقع.
    s0["لا يوجد نمط جواب واحد"] --> s1["اتساق"]
    s0 --> s2["بساطة"]
    s0 --> s3["وضوح"]
    s3 -.-> s4["وضع عناصر قياسية حيث يُتوقع"]

الشكل 14: لا جواب واحد للتنقل، فيُسهَّل التوقع بثلاثة مبادئ وأماكن قياسية.

في العمل يسهل التفكير بالقطع بهذا الجدول تقريباً.

دليل تنقل Windows يعرض خصوصاً توزيع استخدام كهذا.⁸

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

5.1 هيكل سلكي للهيكل وحده

يصعب ربط الصورة بالكلام وحده، فنرتّب أربعة هياكل تمثيلية. تجاهل التفاصيل وانظر فقط إلى ماذا يوضع أين.

[ تنقل علوي ]  عندما نريد إظهار صفحات بالمستوى نفسه كلها
+-------------------------------------------------------------
| AppName        الرئيسية | تحويل | سجل | إعداد
+-------------------------------------------------------------
|
|    المحتوى الرئيس
|    الميل إلى غرض واحد لكل شاشة
|
+-------------------------------------------------------------


[ تنقل أيسر ]  عندما تكون البنود العليا كثيرة
+-------------------------------------------------------------
| AppName                                 بحث [           ]
+-------------------------------------------------------------
| لوحة معلومات   |
| قائمة أجهزة    |    المحتوى الرئيس
| تنبيهات        |
| وظائف          |
| تقارير         |
| إعداد          |
+-------------------------------------------------------------


[ قائمة/تفاصيل ]  تبديل بنود مع رؤية التفاصيل وتحديثها
+-------------------------------------------------------------
| بحث [          ]  تصفية: غير معالَج / الكل      [جديد] [حذف]
+-------------------------------------------------------------
| قائمة            |  تفاصيل / تحرير
|  > قسيمة 1001    |    رقم القسيمة   1001
|    قسيمة 1002    |    الجهة         ...
|    قسيمة 1003    |    بنود التفاصيل ...
|    قسيمة 1004    |
|                  |    [ حفظ ]   [ إلغاء ]
+-------------------------------------------------------------


[ لوحة معلومات + drill-down ]  إيجاد الشذوذ والحفر
+-------------------------------------------------------------
| الكل   سليم 22    انتباه 3    شذوذ 1        تحديث قبل 0.5 ثانية
+-------------------------------------------------------------
| شذوذ 1
|   ! خط B جهاز فحص    لا استجابة    قبل 48 ثانية    [ تفاصيل ]
| انتباه 3
|   - خط A كاميرا      القيمة قديمة    قبل 12 ثانية    [ تفاصيل ]
|   ...
+-------------------------------------------------------------
              |
              |  اضغط [ تفاصيل ]
              v
+-------------------------------------------------------------
| < عودة إلى القائمة       خط B جهاز فحص / لا استجابة
+-------------------------------------------------------------
| القيمة الحالية | رسم سلسلة زمنية | سجل أحداث | تشغيل
+-------------------------------------------------------------

بصفّ الأربعة يتضح محور الاختيار.

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

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

flowchart TB
    accTitle: حد الفصل بين التنقل العلوي والأيسر
    accDescr: مخطّط يبيّن أن حد الفصل بين التنقل العلوي والأيسر هو عدد البنود العليا: إن أمكن صفّها كلها أفقياً فالعلوي وإلا فالأيسر، وأن التنقل انعكاس لبنية المعلومات وبنية العمل.
    t1{"هل يمكن صف البنود العليا أفقياً كلها؟"} -->|"يمكن"| t2["تنقل علوي"]
    t1 -->|"لا يمكن"| t3["تنقل أيسر"]
    t2 -.-> t4["التنقل انعكاس لبنية المعلومات وبنية العمل"]
    t3 -.-> t4

الشكل 15: اختيار الهيكل يُحسم من بنية المعلومات لا من ذوق المظهر.

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

تطبيق Windows يصير أكثر مرونة وسهولة استخدام كلما دعم أكبر عدد ممكن من أساليب الإدخال. حتى دليل Microsoft يوصي بمراعاة أكبر قدر ممكن من الإدخال مثل إيماءة، صوت، لمس، لوحة لمس، ماوس، لوحة مفاتيح.¹⁴

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

flowchart TB
    accTitle: العناصر القياسية قوية أولاً
    accDescr: مخطّط يبيّن أنه يُوصى بمراعاة أكبر قدر ممكن من الإدخال مثل إيماءة وصوت ولمس وماوس ولوحة مفاتيح، وأن عناصر المنصة القياسية تمتص أساليب متعددة إلى حد ما، لذا استخدامها بصراحة قوي أولاً.
    u1["دعم أساليب إدخال متنوعة"] --> u2["العناصر القياسية تمتصها إلى حد ما"]
    u2 --> u3["استخدام العناصر القياسية بصراحة قوي أولاً"]

الشكل 16: أقصر طريق لأساليب الإدخال المتنوعة امتصاصها في العناصر القياسية.

إذا صغناه بشكل سهل الاستخدام في العمل يصير هكذا.

في ناحية لوحة المفاتيح النقاط التالية مهمة خصوصاً.³⁹

• إمكان بلوغ كل الوظائف بلوحة المفاتيح وحدها
• ألا ينزاح ترتيب Tab كثيراً عن الترتيب البصري
• أن يمكن ضغط العناصر التي ينبغي ضغطها بـ Enter / Space
• وجود اختصارات للوظائف المهمة
• توفير مفاتيح وصول أو مسرّعات للتشغيل عالي التكرار

وللمس خصائص كهذه.⁴

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

6.1 لا «كبيراً بما يكفي» بل نحدد برقم

ما يسهل النزاع في مراجعة التصميم هو التوقف عند «كبير بما يكفي» و«واضح». البنود التي يضع دليل Microsoft لها أرقاماً، جعل تلك الأرقام معيار قبول كما هي يقصّر النقاش.

إذا ثبت الرقم تتغيّر أيضاً طريقة الكلام في المراجعة. عندما تستطيع أن تقول لا «أليست هذا الزر صغيرة؟» بل «هذا الزر 32px فلا يبلغ معيار 7.5mm»، ينتهي حكم الإصلاح في المكان.

flowchart TB
    accTitle: التحديد برقم يسرّع المراجعة
    accDescr: مخطّط يبيّن أن التوقف عند «كبير بما يكفي» و«واضح» يسبب نزاعاً في المراجعة، وأن جعل أرقام الدليل معيار قبول كما هي ينهي الحديث ببلوغ المعيار من عدمه فينتهي حكم الإصلاح في المكان.
    v1["التوقف عند «كبير بما يكفي»"] --> v2["نزاع في المراجعة"]
    v2 -.->|"بدلاً من ذلك"| v3["جعل الرقم معيار قبول كما هو"]
    v3 --> v4["يمكن القول ببلوغ المعيار من عدمه"]
    v4 --> v5["ينتهي الحكم في المكان"]

الشكل 17: جعل الرقم معيار قبول ينهي نقاش الحجم في المكان.

كذلك عناصر WinUI القياسية مصنوعة افتراضياً لتتبع حجم الهدف هذا.¹⁵ وبالعكس، موضع العناصر المصنوعة ذاتياً والرسم المخصص وحده هو الخطر.

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

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

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

flowchart TB
    accTitle: الأوامر من أوجه متعددة
    accDescr: مخطّط يبيّن جعل الأمر قابلاً للاستخدام من أوجه واجهة متعددة: يُضغط من زر ويوجد في قائمة سياق ويُستدعى باختصار، وأن الاعتماد على تشغيل يظهر أثناء hover فقط يتعثر على جهاز لمس فقط.
    w1["الأمر نفسه"] --> w2["زر"]
    w1 --> w3["قائمة سياق"]
    w1 --> w4["اختصار"]
    w2 --> w5["يمكن البلوغ بأي أسلوب إدخال"]
    w3 --> w5
    w4 --> w5
    w1 -.-> w6["اعتماد hover يتعثر باللمس"]

الشكل 18: الأوامر المهمة تُوضع على أوجه واجهة متعددة، ويُتجنَّب اعتماد hover.

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

من هنا نجمع ما نريد تثبيته كحد أدنى بغض النظر عن الاستخدام.

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

في سطح مكتب Windows، لوحة المفاتيح ليست شيئاً «من اللطيف وجوده»، بل وسيلة إدخال في المسار الرئيس.

حتى دليل إمكانية الوصول بلوحة المفاتيح من Microsoft يعد توافق لوحة المفاتيح مهماً لا لمستخدمين بقيود بصرية أو حركية فحسب، بل أيضاً لمستخدمين يختارون لوحة المفاتيح لغرض الكفاءة.³

ما نريد النظر إليه كحد أدنى هذه النقاط الخمس.

• هل ترتيب Tab طبيعي
• هل إظهار التركيز موجود
• هل يمكن الضغط بـ Enter / Space
• هل الاختصارات موجودة
• هل يمكن استدعاء تشغيل يعادل النقر الأيمن بلوحة المفاتيح أيضاً

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

7.2 تكبير النص، سمات التباين، إمكانية الوصول

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

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

وعلاوة على ذلك في سمات التباين يُوصى بـ:

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

.⁷

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

• تسميات تفترض عرضاً ثابتاً
• ارتفاع زر ثابت بالبكسل
• تصميم ينقل المعنى باللون وحده
• واجهة برسم مخصص لا تتبع السمة

.

هذه الناحية أليق أن تُفكَّر لا كـ «توافق إمكانية وصول» بل كـ أعمال أساس لصنع واجهة Windows لا تنكسر طويلاً.

flowchart TB
    accTitle: أعمال أساس تحتمل التكبير والسمة
    accDescr: مخطّط يبيّن أن تسميات العرض الثابت والارتفاع الثابت بالبكسل ونقل المعنى باللون وحده والرسم المخصص الذي لا يتبع السمة تنكسر بسهولة، وأن عدم ترميز اللون بشكل ثابت واستخدام موارد والتجربة بأربعة أنواع من سمات التباين أعمال أساس لواجهة Windows لا تنكسر طويلاً.
    y1["تسمية عرض ثابت وارتفاع ثابت بالبكسل"] --> y3["تنكسر عند التكبير أو تبديل السمة"]
    y2["نقل معنى باللون وحده ورسم خاص"] --> y3
    y3 --> y4["عدم ترميز اللون بشكل ثابت واستخدام موارد"]
    y4 --> y5["التجربة بأربعة أنواع من سمات التباين"]
    y5 -.-> y6["أعمال أساس لواجهة لا تنكسر طويلاً"]

الشكل 19: متابعة تكبير النص وسمات التباين تعادل أعمال أساس للواجهة.

7.3 لا تُفرط في استخدام المربعات

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

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

المهم ألا نجعل كل شيء مربعاً.

خصوصاً:

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

أكثر طبيعية أن تُمال قدر الإمكان إلى عرض داخل السطر.¹⁰

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

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

هذا يؤثّر جيداً أيضاً في العمل.

مثلاً «حذف» إن وُجدت عدة مسارات مثل:

• شريط أدوات
• قائمة سياق
• مفتاح Delete
• سحب إن لزم

يثبت سهولة الاستخدام.

وبالعكس تصميم مثل:

• يظهر في الحافة اليمنى فقط عند hover
• لا يظهر إلا بالنقر الأيمن
• بلوحة المفاتيح لا يُبلغ أبداً

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

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

إمكانية الوصول أسرع بالنظر بأداة من التفكير في الرأس «ربما بخير».

دليل اختبار إمكانية الوصول من Microsoft يعرض Live Inspect و FastPass و Troubleshooting باستخدام Accessibility Insights for Windows، ويمكن علاوة على ذلك تأكيد سمات UI Automation وبنية التنقل بـ Inspect في SDK.¹⁷

حتى كحد أدنى، تنفيذ نحو:

• مسح سريع بـ Accessibility Insights
• تأكيد أسماء العناصر الرئيسة وأدوارها وأنماطها بـ Inspect
• تمرير التدفق الرئيس بلوحة المفاتيح وحدها
• تجربة تكبير النص وسمات التباين

يقلّل الرجوع.

flowchart TB
    accTitle: إجراء تأكيد إمكانية الوصول
    accDescr: مخطّط يبيّن تدفق التأكيد: مسح بـ Accessibility Insights، وتأكيد الأسماء والأدوار والأنماط بـ Inspect، وتمرير التدفق الرئيس بلوحة المفاتيح وحدها، وتجربة تكبير النص وسمات التباين.
    z1["مسح بـ Accessibility Insights"] --> z2["تأكيد الاسم والدور والنمط بـ Inspect"]
    z2 --> z3["تمرير التدفق الرئيس بلوحة المفاتيح وحدها"]
    z3 --> z4["تجربة التكبير وسمات التباين"]
    z4 -.-> z5["أسرع من «ربما بخير» في الرأس"]

الشكل 20: إمكانية الوصول تُؤكَّد بمسح الأداة ثم التدفق الرئيس يدوياً.

7.6 أدخل قابلية الاستعادة

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

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

مثلاً:

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

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

خصوصاً في BtoB والموجّه إلى متخصصين، إجهاد إعادة التشغيل يصير كما هو سوء UX.

flowchart TB
    accTitle: قابلية الاستعادة تحسم UX
    accDescr: مخطّط يبيّن أن UX يتحدد لا بزر يُضغط بمتعة فقط بل بإمكان الرجوع حتى عند الحادث، وأن Undo و Redo والحفظ التلقائي واستعادة الحالة وتقدّم معالجة طويلة والإلغاء يقلّل إجهاد إعادة التشغيل.
    ba1["Undo / Redo وحفظ تلقائي"] --> ba4["يمكن الرجوع حتى عند الحادث"]
    ba2["استعادة حالة التحرير والعرض"] --> ba4
    ba3["عرض تقدّم وإلغاء"] --> ba4
    ba4 -.-> ba5["إجهاد إعادة التشغيل يصير كما هو سوء UX"]

الشكل 21: UX يُحسم لا بسهولة الضغط فقط بل بقابلية الاستعادة حتى عند الحادث.

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

8.1 الظن أنه بما أنه BtoB يكفي رفع الكثافة

هذا نصف صحيح فقط.

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

أبعد عن الخطأ أن ننظر إلى درجة التمرّس وأسلوب الإدخال وبيئة الاستخدام لا إلى تسمية BtoB.

8.2 إخفاء الوظائف أكثر مما ينبغي لأنه BtoC

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

إن مِلنا بكل شيء نحو «إظهاره بسهولة»، يبدأ جحيم هادئ من:

• التشغيل عالي التكرار بعيد
• الحفر في القائمة في كل مرة
• مواصلة تبديل الشاشات

flowchart TB
    accTitle: فخان لوهم التسمية
    accDescr: مخطّط يبيّن فخين: وهم أنه بما أنه BtoB يكفي رفع الكثافة يفوت في جهاز الميدان، وإخفاء الوظائف أكثر مما ينبغي لأنه BtoC يبعّد التشغيل عالي التكرار عن المتمرس.
    ca1["كثافة عالية لأنه BtoB"] --> ca2["في جهاز الميدان الكثافة عدو"]
    ca3["إخفاء لأنه BtoC"] --> ca4["التشغيل عالي التكرار يبعد عن المتمرس"]
    ca2 --> ca5["ننظر إلى التمرّس وأسلوب الإدخال وبيئة الاستخدام"]
    ca4 --> ca5

الشكل 22: وهم «BtoB كثافة عالية» و«BtoC بسهولة» يفوت في الاتجاه المعاكس.

8.3 صنع تشغيل يفترض hover

لا hover في اللمس. علاوة على ذلك، الواجهة التي لا تظهر إلا بالمؤشر يسهل أن تسوء أيضاً ملاءمتها للتقنيات المساعدة.⁴¹²

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

Before: الأزرار تظهر في الطرف الأيمن على الصف الذي عليه hover فقط
  قسيمة 1001   2026-03-18   غير معالَج                        <- لا يظهر شيء
  قسيمة 1002   2026-03-18   غير معالَج        [ تحرير ][ حذف ] <- الصف الذي عليه الماوس فقط

After: ظاهرة دائماً + زيادة المسارات
  قسيمة 1001   2026-03-18   غير معالَج        [ تحرير ][ حذف ]
  قسيمة 1002   2026-03-18   غير معالَج        [ تحرير ][ حذف ]
     نقر أيمن  -> تحرير / حذف
     لوحة مفاتيح  -> Enter للتحرير، Delete للحذف

8.4 نقل الحالة باللون وحده

شائع خصوصاً في شاشة المراقبة، لكن نقل المعنى بأحمر / أصفر / أخضر وحده خطر.

الجمع بين نص وأيقونة ووقت وعدد وشرح يقلّل التفويت وسوء الفهم.¹¹

8.5 جعل كل أخطاء التحقق مربعات

شائع في الإدخال المكتبي. إظهار مربع كلما أُدخل يكسر إيقاع العمل تماماً.

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

Before: مربع نمطي لكل حقل
  الرمز البريدي  [ 1234        ]        +------------------------------+
  العنوان        [             ]        | صيغة الرمز البريدي غير صحيحة
                                        |                       [ OK ]
                                        +------------------------------

After: داخل السطر في المكان
  الرمز البريدي  [ 1234        ]
                 ! أدخل 7 أرقام. مثال 1234567
  العنوان        [             ]

8.6 البناء بتخطيط حجم ثابت

حتى لو كان جميلاً في بيئة تطوير بعرض 100%، ينكسر بسهولة مع:

• تكبير النص
• DPI عالٍ
• سمات تباين
• الأقلمة

.⁶⁷

Before: تسمية عرض ثابت + زر ارتفاع ثابت. عند تكبير النص
  [ شحن مقر... ][ 2026-03-1  ]      <- التسمية تُقطع والقيمة تفيض
  [ تس ][ إل ]                        <- نص الزر يُقطع من الأعلى والأسفل

After: تخطيط يمتد مع المحتوى
  تاريخ الشحن المقرر
  [ 2026-03-18              ]
  [ تسجيل ]   [ إلغاء ]                 <- الارتفاع يُحدد بالمحتوى + الهامش

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

8.7 صنع عناصر مخصصة أكثر مما ينبغي

العناصر القياسية في Windows تحمل سلوكاً أكثر مما يظهر.

• تركيز
• لوحة مفاتيح
• متابعة سمة
• UI Automation
• اتصال بتقنيات مساعدة

تتولاها حتى النهاية، فإن صُنع الكل ذاتياً بلا سبب يزيد دين UX وإمكانية الوصول.⁸³

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

أخيراً نضع ثمانية أسئلة مريحة إن وُضعت في أول مراجعة تصميم.

إذا أجبنا عن هذه الثمانية مسبقاً، يُحسم طبيعياً:

• هل الأفضل تنقل أضحل
• هل الأفضل قائمة + تفاصيل
• هل ينبغي تغليظ الاختصارات
• أين ينبغي استخدام المربعات
• إلى أي حد نسمح بالتخصيص

flowchart TB
    accTitle: ما يُحسم من الأسئلة الثمانية
    accDescr: مخطّط يبيّن أن الإجابة مسبقاً عن الأسئلة الثمانية قبل البدء تحسم طبيعياً عمق التنقل وتكوين القائمة والتفاصيل وسُمك الاختصارات ومواضع المربعات ونطاق التخصيص.
    da1["الإجابة عن الأسئلة الثمانية قبل البدء"] --> da2["عمق التنقل وتكوين القائمة والتفاصيل"]
    da1 --> da3["سُمك الاختصارات"]
    da1 --> da4["نطاق المربعات والتخصيص"]
    da2 --> da5["يُحسم طبيعياً"]
    da3 --> da5
    da4 --> da5

الشكل 23: الإجابة مسبقاً عن الأسئلة الثمانية تحسم الاختيارات الرئيسة في التصميم طبيعياً.

10. الخلاصة

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

flowchart TB
    accTitle: ما يُحسم قبل الجمال
    accDescr: مخطّط يبيّن أن المهم في تصميم UX حسم ما إذا كان ذلك الشخص في ذلك المكان بذلك أسلوب الإدخال يستطيع الاستخدام بلا توقف قبل الجمال، وأن UX عقد تشغيل لا زخرفة.
    ea1["ذلك الشخص"] --> ea2["في ذلك المكان"]
    ea2 --> ea3["بذلك أسلوب الإدخال"]
    ea3 --> ea4["هل يستطيع الاستخدام بلا توقف"]
    ea4 -.-> ea5["UX عقد تشغيل لا زخرفة"]

الشكل 24: قبل «هل هو جميل» نحسم ألا يتوقف الشخص والمكان وأسلوب الإدخال.

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

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

وما يؤثّر مشتركاً بغض النظر عن الاستخدام هذه الستة.

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

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

11. روابط مرجعية

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

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

أين يتصل هذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

هل يجب أن يكون تطبيق الأعمال BtoB واجهة عالية الكثافة محشوة بالمعلومات؟

نصف صحيح فقط. في إدخال مكتبي يومي موجّه إلى متمرسين، الكثافة العالية في القوائم وإكمال العمل بلوحة المفاتيح يؤثّران في الكفاءة المستمرة. أما أجهزة الميدان في المصانع والمستودعات والاستقبال وواجهات الأجهزة فالكثافة عدو، وينبغي إعطاء الأولوية لأهداف تشغيل كبيرة ومسار قصير ووضوح. أبعد عن الخطأ أن ننظر إلى التمرّس وأسلوب الإدخال وبيئة الاستخدام لا إلى تسمية BtoB. وبالمقابل حتى في BtoC، أدوات متقدمة مثل تحرير الصور وتحليل الاستثمار تعطي الأولوية لكثافة المعلومات والاختصارات وقابلية التخصيص قبل البساطة.

ما الذي يجب حسمه أولاً في تصميم UX لتطبيق Windows؟

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

كيف نختار نمط التنقل؟

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

إلى أي حد نُظهر مربع تأكيد؟

المهم ألا نجعل كل شيء مربعاً. أخطاء الإدخال المرتبطة بحقل أو أخطاء الشكل التي تُصلح في المكان أميل إلى عرضها داخل الشاشة لا في مربع. ما يستحق التأكيد حقاً عمليات أقرب إلى غير قابلة للعكس: إيقاف، حذف، قطع، إعادة كتابة. إن أظهرت مربعاً فاحفظ ثلاثة حدود دنيا على الأقل: اكتب ما سيحدث في السطر الأول بوضوح، واجعل نص الزر محدداً مثل حذف أو إيقاف لا OK/Yes، وضع دائماً زراً آمناً غير مدمّر.

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

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

غو كومورا

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

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