Muhit: كيف يعمل قرار التصميم على الشاشة؟

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

تناولتُ Muhit في المقال الأول بوصفه لغة مشتركة للسلوك. فاتّساق الواجهة يتعلّق باستمرار عمل المستخدم بين الشاشات، بقدر ما يتعلّق بالألوان والخطوط.

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

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

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

قرارات حول سجل واحد

في المثال، تُحفظ مسودة كل سجل تحت معرّفه الخاص. لذلك لا تظهر الملاحظة المكتوبة لسجل في حقل سجل آخر. والعودة إلى القائمة لا تمسح المسودة، كما يحتفظ حقل البحث بالشرط الذي تركه المستخدم.

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

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

وهكذا يتحوّل مبدأ الحفاظ على الجهد إلى سؤال محدّد: ما المعلومات التي نحافظ عليها، وضمن أي نطاق، وإلى متى؟

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

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

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

الخطأ والإلغاء داخل المسار

يتضمّن المثال نفسه خياراً يجعل العملية تفشل عمداً. والهدف هو دراسة سلوك التعافي إلى جانب المسار الذي يعمل بسلاسة.

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

إذا فشلت العملية التجريبية، تبقى الملاحظة المكتوبة. وتشرح الرسالة ما حدث وكيف يمكن إعادة المحاولة. كما تتكيّف تسمية الزر مع الحالة الجديدة.

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

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

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

ويظهر هذا الحد أيضاً في تكاملات Muhit المرجعية مع React وVue. فعند إعادة إنشاء النموذج، تُنتَج إشارة إلغاء للعملية الجارية. ويُنتظر من التطبيق تمرير هذه الإشارة إلى طلب الشبكة، وألا يغيّر حالته استناداً إلى استجابة أُلغيت.

هنا تتلاقى مسؤوليات المكتبة والتطبيق. يدير المكوّن دورة حياة التفاعل، ويعرف التطبيق ما إذا كان السجل قد حُفظ فعلاً.

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

يجب أن يطابق نطاق التغذية الراجعة نطاق العملية التي حدثت بالفعل.

نقل النهج نفسه إلى شاشات أخرى

تزداد صعوبة تنفيذ هذه القرارات من جديد في كل مشروع مع مرور الوقت. فقد يلزم إعادة إنشاء المكوّنات، خصوصاً عند تغيير اللغة أو السمة أو العرض.

في الأمثلة المرجعية لـReact وVue في Muhit، تُلتقط صورة لحالة العرض الحالي قبل إعادة إنشاء الجدول. وفي المسارات المدعومة، تنتقل المرشّحات والتحديد وترتيب الأعمدة إلى المكوّن الجديد. وإذا قدّم التطبيق قيمة جديدة صراحةً، تكون لها الأولوية.

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

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

وتُتّخذ قرارات السمة وفق أدوار محدّدة أيضاً. لخلفية السطح، والنص المقروء، وإبراز الإجراء، وتركيز لوحة المفاتيح متغيّرات منفصلة. مثلاً، يُستخدم --mh-surface مع --mh-text، بينما يُختار --mh-on-accent للنص فوق زر ذي لون بارز.

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

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

ثم ينبغي تنفيذ المهمة نفسها في ظروف مختلفة: عند غياب النتائج، وفشل العملية، وتراجع المستخدم، وتغيير اللغة، والتنقّل بلوحة المفاتيح.

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

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

---

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

المصادر: الكود المصدري لـ Muhit · عقد واجهات JSON

المقال السابق: Muhit: ما الذي يجعل الواجهة متّسقة؟

مفاهيم الأطلس: التصميم · البرمجيات · السياق · الأنظمة