لماذا لا تكفي الـ ComboBox وحدها
أنت تبني تطبيقات أعمال. أنت تحل المشكلات نفسها مراراً وتكراراً.
تبني عمليات بحث عن العملاء. تبني حقول الإكمال التلقائي للمنتجات. تبني نوافذ الاختيار المنبثقة.
تتعامل معظم مكتبات واجهة المستخدم (UI) مع هذه العناصر كأدوات (widgets) منفصلة. يطلقون عليها مسميات مثل lookups أو autocomplete boxes. وهذا خطأ.
هذه ليست مشكلات مختلفة، بل هي المشكلة ذاتها. أنا أسمي هذا المفهوم Locator.
تعتمد تطبيقات الأعمال على المراجع (references).
- يشير أمر البيع إلى عميل.
- تشير الفاتورة إلى مورد.
- تشير المعاملة إلى منتج.
تخزن قواعد البيانات هذه البيانات كمعرفات (IDs). لكن المستخدمين لا يفكرون بالمعرفات، بل يفكرون بالأسماء أو الأكواد أو الرموز الشريطية (barcodes).
المشكلة الحقيقية ليست في كيفية تخزين المعرف (ID). المشكلة هي في كيفية عثور المستخدم على الكيان الصحيح باستخدام ما يعرفه.
تعمل الـ ComboBox مع القوائم الصغيرة. استخدمها للدول أو العملات؛ فهذه القوائم تحتوي على بضع عشرات من الصفوف فقط.
أما الـ ComboBox فتفشل مع مجموعات البيانات الضخمة. لا يمكنك التمرير عبر 100,000 عميل. عند هذا النطاق، أنت لا تختار من قائمة، بل تقوم بتحديد موقع سجل (locating a record).
الـ Locator ليس مجرد عنصر تحكم في واجهة المستخدم (UI control). إنه سلوك (behavior).
الـ Locator يفعل أكثر من مجرد إرجاع قيمة؛ فهو يقوم بمعالجة المرجع التجاري (resolving a business reference).
عندما يختار المستخدم منتجاً، يحتاج التطبيق إلى ما هو أكثر من مجرد ProductId. يحتاج إلى سعر الوحدة، ونسبة ضريبة القيمة المضافة (VAT)، ووحدة القياس.
يوفر الـ Locator كل هذا من خلال معالجة المرجع ضمن سياق محدد.
قد تتغير واجهة المستخدم:
- على سطح المكتب، تظهر كحقلين للبحث.
- في الشبكة (grid)، تظهر كمحرر مخصص (custom editor).
- على الهاتف المحمول، تظهر كشاشة بحث.
يتغير المظهر، ولكن السلوك يظل كما هو.
الـ Locator الجيد يحترم المستخدم. فالمستخدمون ذوو الخبرة يستخدمون لوحة المفاتيح. يجب أن يكمل الـ Locator عملية الاختيار فوراً إذا وجد تطابقاً فريداً، ولا ينبغي أن يطلب الاختيار إلا إذا وجدت تطابقات متعددة.
توقف عن التعامل مع البحث، والإكمال التلقائي، والنوافذ المنبثقة كأدوات (widgets) غير مترابطة. اعترف بالـ Locator كمفهوم أساسي لبرمجيات الأعمال.