الأساسيات
بنية المعلومات
أربع قواعد تحكم كيف يُبنى التنقل والتسلسل الهرمي وتجميع المحتوى في ميركاتو.
القواعد الأربع، بنظرة واحدة
كل تنقل وتسلسل هرمي وتجميع للمحتوى في ميركاتو يتبع القواعد الأربع نفسها. أرِ المستخدم أين هو، اجعل لكل بيانة بابا واحدا وأبوابا كثيرة، لا تُغرق الشاشة، وابنِ لنمو لم يأتِ بعد.
كل قسم أدناه يشرح إحدى هذه القواعد بالتفصيل. هذا الجدول للمراجعة السريعة فقط.
| القاعدة | ماذا تعني |
|---|---|
| أرِ المستخدم أين هو | الموضع مرئي دائما، لا يُستنتج من السياق. |
| بيت واحد، أبواب كثيرة | كل بيانة مكانها واحد، وكل مدخل يقود إلى نفس الشاشة بفلتر. |
| تجنّب إغراق المعلومات | أظهر ما يكفي للقرار التالي، لا كل شيء تعرفه المنظومة. |
| خطّط للنمو | ابنِ للعنصر السابع قبل أن يُطلب، لا بعده. |
أرِ المستخدم أين هو
المندوب يقف بين صيدليتين، على شبكة بطيئة، ويده مشغولة بكيس. لا وقت لديه ليتساءل في أي خطوة هو.
الموقع يجب أن يكون مرئيا دائما، لا مستنتجا من السياق.
علامات موضع ثابتة
مؤشر الخطوة ظاهر طوال الوقت: ① المواد ← ② المذاخر ← ③ الإرسال. هذا عقد، لا زخرفة.
التبويب النشط مُظلَّل دائما بخط سفلي بلون العلامة الأساسي. الحالة تُقرأ بنظرة واحدة، لا بتخمين.
مسارات الخروج
أي شاشة يصلها المستخدم عبر أكثر من نقر واحد تحمل مسارا تفصيليا: الطلبيات > طلبية #1234 > تفاصيل.
وكل ورقة سفلية تحمل مقبضا وطريقة واضحة للإغلاق. المستخدم لا يُحاصر داخل طبقة عائمة لا يعرف كيف يخرج منها.
- أظهر مؤشر خطوة ثابتا في كل تدفق من أكثر من شاشة واحدة.
- اجعل مسار العودة (breadcrumb أو زر رجوع واضح المعنى) متاحا من أي شاشة عميقة.
- ثبّت تظليل التبويب النشط بلون العلامة، لا بتغيير طفيف في الوزن فقط.
- لا تعتمد على أن المستخدم "يتذكر" في أي خطوة هو من زيارة سابقة.
- لا تفتح ورقة سفلية بلا مقبض أو زر إغلاق واضح.
- لا تترك المستخدم يعتمد فقط على زر رجوع المتصفح للخروج من شاشة عميقة.
بيت واحد، أبواب كثيرة
البيانة توجد في مكان واحد فقط. الوصول إليها يأتي من أبواب كثيرة، لكنها كلها تقود إلى نفس الشاشة القانونية بفلتر مطبَّق عليها.
لا نسخة موازية تُبنى خصيصا لذلك المدخل.
مثالان
- النقر على "طلبيات" من بطاقة الصيدلية يفتح شاشة الطلبيات نفسها، مفلترة على تلك الصيدلية. لا توجد "أداة طلبيات" منفصلة.
- النقر على بطاقة إحصائية "جديد 14" يقود إلى شاشة الطلبيات مفلترة على status=جديد. ليس قائمة منفصلة تُبنى لكل حالة.
لماذا هذا مهم
- وجّه كل نقطة دخول إلى الشاشة القانونية نفسها، بفلتر مسبق مطبَّق.
- اجعل الفلتر جزءا من حالة الشاشة القابلة للعنونة، لا حالة مخفية داخل مكون خاص.
- لا تبني "ودجت" أو شاشة فرعية مخصصة لكل سياق يظهر منه نفس نوع البيانات.
- لا تكرر منطق العرض أو التصفية في أكثر من مكان لنفس البيانة.
كثافة البطاقة
البطاقة تُظهر ما يكفي لاتخاذ القرار التالي، لا كل شيء تعرفه المنظومة عن هذا الكيان. التفاصيل الكاملة تعيش بالداخل، خلف نقرة واحدة.
الحقول الستة لبطاقة الطلبية
- رقم الطلبية
- الصيدلية
- المندوب
- شارة الحالة
- التاريخ
- القيمة
ستة حقول، لا أكثر. أي حقل إضافي يريد الظهور يجب أن يبرر نفسه أمام هذه الستة، لا أن يُضاف بجانبها تلقائيا.
- اقصر البطاقة على الحقول التي تُبنى عليها قرارات فعلية.
- لا تطبع كل حقل معروف عن الكيان على بطاقته.
الإحصاءات والفلاتر
الإحصاءات تختصر
2M، وليس 2,000,000. 14k، وليس 14,000.
المندوب والإداري يقرآن أرقاما كثيرة في اليوم، والقراءة السريعة أهم من الدقة الحسابية الكاملة في واجهة الإحصاء.
الفلاتر والرقائق تطوي التعقيد
لا تُظهر ثمانية فلاتر افتراضيا. أظهر الأربعة الأكثر استخداما فقط.
خيار "المزيد" يفتح البقية عند الحاجة الفعلية، لا قبلها.
- اختصر الأرقام الكبيرة في أي سطح إحصائي (2M، 14k).
- اعرض الفلاتر الأربعة الأكثر استخداما فقط، وأخفِ الباقي خلف "المزيد".
- لا تعرض الأرقام الكاملة غير المختصرة في لوحات الإحصاء السريعة.
- لا تُحمّل شريط الفلاتر بكل خيار ممكن دفعة واحدة.
خطّط للنمو
صمّم المكونات لتستوعب نوع طلبية خامسا، ومذخرا سادسا، وحالة سابعة، قبل أن تُطلب فعليا.
التبويبات والرقائق والأقسام يجب أن تُبنى من البيانات، لا أن تُكتب أسماؤها ثابتة في الكود.
بطاقات معيارية
إضافة حقل جديد إلى بطاقة الطلبية لا تتطلب إعادة تصميم البطاقة من الصفر. البنية معيارية بما يكفي لاستيعاب حقل إضافي دون كسر إيقاعها البصري.
اختبار سريع
- ابنِ التبويبات والرقائق والأقسام من مصدر بيانات، لا من قائمة مكتوبة يدويا.
- اترك مساحة بصرية للبطاقة تستوعب حقلا إضافيا دون إعادة تصميم.
- لا تكتب أسماء الحالات أو المذاخر أو أنواع الطلبيات ثابتة داخل منطق العرض.
- لا تفترض أن عدد الحالات أو الأنواع الحالي هو العدد النهائي.
الرقائق والتجميع حسب النية
القواعد الأربع أعلاه تترجم إلى نموذج تنقل واحد، متكرر عبر تطبيقات ميركاتو كلها.
- تبويبات سفلية للأقسام الرئيسية.
- رقائق للتصفية داخل القسم.
- أوراق سفلية للإجراءات السياقية القصيرة.
لا تُخترع بنية تنقل جديدة لكل تطبيق جديد.
الرقائق لا التبويبات للتصفية
المندوب لا يُحبَس أبدا داخل عرض مُفلتر لا يستطيع الرؤية خلفه. الرقائق تبدّل الفلتر دون فقدان مكانه في التسلسل الهرمي للتنقل.
التبويبات مختلفة: هي تمثل أقساما منفصلة فعلا، لا فلاتر على نفس القسم.
التجميع حسب النية لا حسب البيانات
الأقسام في القائمة الجانبية أو في التنقل السفلي تُجمَّع حسب ما يريد المستخدم إنجازه (إنشاء طلبية، متابعة طلبياتي، إدارة الحساب)، لا حسب كيفية تخزين البيانات في الخلفية.
هذا هو الفرق بين بنية تخدم المستخدم وبنية تخدم قاعدة البيانات.
القابلية للاكتشاف تسبق الاختصار
أي إجراء يمكن الوصول إليه من مسار سريع (بطاقة إحصائية، اختصار، رابط عميق) يجب أن يكون قابلا للوصول أيضا من التسلسل الهرمي الطبيعي للتنقل.
الاختصار إضافة، لا بديل عن وجود الإجراء في مكانه المتوقع.
- اجعل كل اختصار يوصل إلى نفس الإجراء المتاح عبر التسلسل الهرمي الطبيعي.
- لا تجعل الاختصار الطريقة الوحيدة للوصول إلى إجراء موجود فعليا في مكان آخر.
قائمة تحقق سريعة
قبل شحن أي شاشة أو تدفق جديد، راجعه مقابل هذه القواعد الست: