“قد يبدو فلتر العقارات دقيقاً رغم نقص المعلومات أو قدمها. إطار لأربع حالات من الأدلة يجعل البحث أكثر وضوحاً ومصداقية.
ليست النتيجة الخطِرة دائماً تلك التي لا تعرض أي عقار؛ فقد تكون صفحة دقيقة المظهر تخفي ما لا يعرفه النظام.
يبحث زائر موقع عقاري عن شقة بغرفتين وشرفة وسعر ضمن حد معين، مع شرط يتعلق بحالة المشروع. تظهر ست بطاقات مرتبة، لكل منها صورة وسعر ووصف. يوحي المشهد بأن جميع النتائج تستوفي الشروط المختارة.
لكن لنتخيل أن بيانات وجود الشرفة لم تُسجّل بالطريقة نفسها في كل العقارات. بعض السجلات يذكر وجودها، وبعضها يؤكد عدم وجودها، وفي سجلات أخرى تُترك الخانة فارغة. أما حالة المشروع فقد جاءت من نظام مختلف، وتُحدَّث بوتيرة أبطأ من الأسعار.
هذا مثال افتراضي، وليس تقريراً عن خلل في موقع معروف. وهو يكشف فرقاً مهماً: وجود فلتر أنيق لا يثبت جودة البيانات التي يستند إليها.
تصميم عناصر التحكم نصف العمل. أما النصف الآخر فهو تحديد الادعاءات التي يحق للواجهة تقديمها.
الفلتر وعد بمعنى محدد
حين يختار المستخدم «شرفة»، فما الذي يعنيه هذا الشرط؟
قد يقصد مساحة خارجية خاصة مهما كان حجمها، أو شرفة مسجلة صراحة في قاعدة البيانات، أو تراساً، أو مساحة مشتركة على السطح. وقد تختلف التعريفات بين الوسطاء والمطورين. إذا لم تُحسم القاعدة، يبدو الفلتر دقيقاً بينما يجمع معاني مختلفة.
تنشر منظمة معايير العقارات «RESO» قاموس بيانات يحدد الموارد والحقول والقيم المستخدمة في تبادل المعلومات العقارية. ويشمل مورد العقار حقولاً مثل السعر المعلن والحالة القياسية للإدراج. تساعد هذه البنية على توحيد المسميات والأنواع، لكنها لا تضمن اكتمال كل حقل في كل مصدر أو حداثته.
توضح RESO أيضاً إمكانية تمديد القاموس بحقول محلية وإغفال حقول لا تنطبق على نظام معين. ولذلك لا يكفي اعتماد اسم قياسي حتى تختفي فجوات المعلومات.
يجب أن يستطيع فريق التصميم شرح ما يختبره الفلتر، وما السجلات التي تستوفيه، وكيف يعالج النقص والتعارض. وإذا اختلفت الإجابة بين العربية والإنجليزية، فلا تزال التجربة بحاجة إلى ضبط.
أربع حالات تختبئ خلف اختيار واحد
قد يحتاج وصف الخاصية العقارية إلى أكثر من «نعم» و«لا». ويمكن استعمال أربع حالات عمل:
وجود مؤكد: يثبت مصدر حديث موثوق أن الخاصية مشمولة في العرض.
غياب مؤكد: يثبت مصدر موثوق أن الخاصية غير موجودة أو غير مشمولة.
معلومة غير متاحة: لم يتلق النظام دليلاً كافياً أو لم يتحقق من البيانات.
معلومة قديمة أو متعارضة: توجد بيانات، لكن تاريخها أو اختلاف مصادرها أو تغير حالة المشروع يمنع عرضها دون تحفظ.
هذا تقسيم تحليلي مقترح، وليس تعداداً رسمياً تفرضه RESO. وقد تحتاج خصائص مثل حالة البناء أو التوافر أو الملكية إلى أوصاف أكثر تفصيلاً.
الخطأ الأساسي هو اعتبار المعلومة المفقودة دليلاً على النفي، أو قبولها دليلاً على الإثبات لأن ذلك يسهل البرمجة. إذا استبعد النظام عقاراً لم تُسجّل فيه بيانات الشرفة لأنه افترض أنها غير موجودة، فقد يُخفي خياراً مناسباً. وإذا أظهر السجل الناقص باعتباره مستوفياً للشرط، فقد يضلل الزائر.
ومن الأخطاء أيضاً عرض رقم دقيق للنتائج دون توضيح أن جزءاً من المخزون لا يمكن تقييمه وفق الشرط المختار.
يجب أن تتفق لغة البحث مع معنى السجل
قد يكتب الوسيط وصفاً من منظور التعاقد، ويستخدم المطور مصطلحاً متعلقاً بالبناء، بينما يبحث العميل عن قابلية الانتقال إلى السكن فوراً.
تتقاطع عبارات مثل «قريب التسليم» و«مكتمل» و«جاهز» و«متاح»، لكنها ليست حقائق متطابقة. اكتمال المبنى لا يعني توافر وحدة معينة. وظهور العقار في السوق لا يضمن استمرار شروط العرض المعروضة.
يعرف حقل StandardStatus في قاموس RESO حالة الإدراج في سياق العلاقة التعاقدية، مع قيم مثل Active وPending. ولا يقدم تعريفاً موحداً لاكتمال الإنشاء أو خلو الوحدة أو صلاحيتها للإشغال الفوري في جميع الأسواق.
لذلك يصبح فلتر «جاهز للسكن» خطراً عندما يجمع وضع البناء ووقت التسليم والتوافر للبيع في قيمة منطقية واحدة دون اتفاق واضح حول شروطها.
ينبغي أن تأتي تسمية الواجهة بعد تعريف البيانات، لا أن تحاول إخفاء غياب ذلك التعريف.
عدد النتائج قد يوحي بيقين غير موجود
تشرح أبحاث مجموعة نيلسن نورمان عن تصميم الفلاتر كيف تساعد الخيارات وأعداد النتائج والتغذية الراجعة المستخدم على تعديل البحث وتجنب الوصول إلى مجموعة فارغة. لكن قيمة هذه الأعداد تعتمد على معرفة ما الذي تحسبه بالفعل.
لنفترض أن الموقع يقول: «ست شقق بشرفة»، بينما توجد ستة سجلات تؤكد الميزة وخمسة أخرى لا تتوافر عنها معلومات موثوقة. قد تكون العبارة الدقيقة «ست نتائج مؤكدة»، لا «جميع العقارات المطابقة».
يمكن أن تُظهر تجربة البحث الصارمة النتائج المؤكدة فقط مع تنبيه إلى استبعاد السجلات غير المكتملة. ويمكن لتجربة استكشافية أن تعرض خيارات محتملة مع تمييز البيانات غير المؤكدة. أما جدول المقارنة فيستطيع استعمال عبارة «المعلومة غير متاحة» بدلاً من خانة فارغة.
لا توجد قاعدة واحدة لكل تطبيق. يجب النظر إلى ما إذا كان الزائر ينشئ قائمة أولية أم يتخذ قراراً ذا تبعات كبيرة. كلما زادت أهمية القرار، ازدادت الحاجة إلى بيان حدود الأدلة.
شارة «٦ نتائج» جذابة، لكنها ليست بديلاً عن هذا الحكم.
لماذا تتغير حالة التوافر بسرعة؟
تختلف المعلومات العقارية عن كثير من البيانات الثابتة؛ فقد تتغير أثناء جلسة التصفح نفسها.
يمكن حجز وحدة أو إيقاف عرضها أو تغيير سعرها. وقد تُحدّث منصة الوسيط معلوماتها في وقت يختلف عن النظام الداخلي للمطور. لذلك قد تكون البطاقة صحيحة عند إنشاء الفهرس، ثم تصبح قديمة عند فتحها.
على الواجهة أن تميز بين وقت جلب البيانات ووقت تأكيد الحالة. ويمكن لتاريخ حقيقي أن يوضح آخر مراجعة للمصدر، كما يمكن لوصف الحالة أن يشرح معنى «متاح». وعندما يستلزم الإجراء تأكيداً جديداً، ينبغي إظهار ذلك قبل أن يفهم القارئ البطاقة باعتبارها عرضاً نهائياً مضموناً.
لا يعني هذا تحويل كل بطاقة إلى صفحة تحذيرات. قد تكفي عبارة دقيقة تذكر تاريخ مراجعة الحالة وضرورة تأكيد الشروط، بشرط أن يأتي التاريخ من سجل حقيقي، لا من لحظة عرض الصفحة.
أما عبارة «تم التحديث الآن» التي يولدها الموقع تلقائياً دون وصول بيانات جديدة فقد تمنح ثقة لا أساس لها.
ليس كل شرط بحث دليلاً نهائياً
تصلح بعض الخصائص للاستكشاف الأولي. مثل الموقع العام ونوع الوحدة ونطاق السعر، بشرط وضوح التعاريف وأساس المقارنة. لكن تأكيد توافر وحدة بعينها أو استمرار إطلالة أو اكتمال مرفق مخطط قد يحتاج إلى وثيقة أو تحقق منفصل.
يمكن لتجربة جيدة أن تساعد الشخص على ترتيب الخيارات ومقارنتها، ثم توجيهه إلى طلب معلومات مؤكدة بخطوة واضحة. هذا أفضل من تقديم نتائج البحث وكأنها التزام تعاقدي نهائي.
ويحمي هذا التمييز فريق المبيعات من الاضطرار إلى مناقضة الموقع بعدما كوّن الزائر توقعاته منه.
ماذا يجب أن تقول صفحة «لا توجد نتائج»؟
قد تظهر الصفحة الخالية لأسباب مختلفة: لا توجد عقارات تطابق الشروط فعلاً، أو المخزون المتاح للموقع ناقص، أو تعريف الشرط أضيق مما فهمه القارئ، أو إحدى خدمات البيانات معطلة.
لا ينبغي أن تعرض جميع هذه الحالات الرسالة نفسها.
عبارة «لا توجد نتائج مطابقة في مخزوننا الحالي» تختلف عن «لا توجد عقارات بهذه المواصفات». الأولى تتحدث عن حدود سجلات الموقع، أما الثانية فتدّعي معرفة أوسع بالسوق.
وإذا كانت البيانات معطلة مؤقتاً، ينبغي وصف العطل بدلاً من إظهار بدائل عشوائية وكأنها اجتازت الشروط. وإذا كان تضييق البحث هو السبب، يمكن اقتراح تغيير شرط واحد مع الحفاظ على بقية اختيارات المستخدم.
الهدف هو تمكينه من مواصلة البحث دون اختلاق عقارات.
قد يخطئ الفلتر ثنائي اللغة مرتين
يمكن أن تكون ترجمة الكلمة صحيحة، لكن ربطها بالبيانات خاطئاً.
إذا فصلت القاعدة الإنجليزية بين balcony وterrace، بينما جمعت الواجهة العربية الاثنين تحت كلمة «شرفة»، فقد تتغير نتائج البحث المقيّد على نحو مؤثر. لا يُعالج ذلك بترجمة حرفية ولا بتعديل برمجي وحده؛ بل يحتاج إلى تنسيق المعنى المعتمد بين فريق المحتوى وقاعدة البيانات.
وتنشأ مخاطرة أخرى عند عرض الأسعار بعملة مختلفة عن العملة المستخدمة للمقارنة في الخلفية. قد يكون السعر المعروض تحويلاً تقريبياً بينما تُبرم العقود بعملة أصلية محددة. يجب توضيح الفرق وعدم تقديم التحويل بوصفه عرضاً ثابتاً.
لهذا يحتاج محرر اللغة إلى تعريف وظيفة الفلتر وقواعد البيانات التي تحكمه، لا إلى قائمة كلمات منفصلة عن السياق.
المراجعة الجادة تبدأ تحت سطح الواجهة
ابدأ بعينة من السجلات، لا بتغيير الألوان.
اختر خصائص تختلف في اكتمالها، وافحص مصدر كل معلومة وقاعدة الربط والتسمية المعروضة وكيفية التعامل مع القيم الناقصة وآلية التحديث. ثم اطلب من مستخدم أن يجد عقاراً وفق مجموعة شروط، وراقب ما ظهر، واسأله عمّا يعتقد أن النتائج تثبته.
كرر التجربة بعبارات عربية ذات معنى محلي. واختبر سجلاً خالياً، وحالة متعارضة، وتاريخاً قديماً، ومصطلحاً يختلف بين النظام الداخلي والموقع.
تقدم إرشادات نيلسن نورمان مبادئ مفيدة لتفاعل الفلاتر، كما تشرح إرشادات W3C تسمية عناصر النماذج وربط التسميات بعناصر التحكم. لكنها لا تصدّق وحدها صحة معلومات أي عقار؛ فهذا يتطلب الرجوع إلى مصدر البيانات ومسؤوليه.
يجب التمييز بين نوعين من الخلل: المستخدم لا يفهم الأداة، أو الأداة لا تستطيع إثبات ما تعرضه.
مؤشرات القياس قد تُساء قراءتها
يمكن متابعة عمليات البحث التي لا تعطي نتائج، وإزالة الشروط، وزيارات صفحات العقارات، وطلبات توضيح المعلومات. وتساعد هذه الإشارات على تحديد مواضع الحيرة.
لكن انخفاض نسبة النتائج الخالية ليس دليلاً تلقائياً على جودة النظام؛ فقد يكون سببه قبول عقارات غير مؤكدة لتجنب عرض كلمة «لا يوجد». كما أن كثرة النقرات قد تعني الاهتمام أو الارتباك.
ينبغي الجمع بين السلوك وجودة البيانات: اكتمال الحقول، وعمر التحديثات، وتعارض المصادر، ونسبة النتائج التي تستند إلى صفات مؤكدة بدلاً من افتراضات.
هذه مؤشرات تشغيلية مقترحة، وليست ادعاءات مثبتة بزيادة التحويلات أو المبيعات.
ماذا يقدم البحث الموثوق في النهاية؟
لا تقتصر فائدة البحث العقاري على تقليل عدد البطاقات. بل يجب أن يساعد القارئ على فهم ما يعرفه النظام، وما لا يعرفه، وما يستدعي تأكيداً قبل القرار.
قد تكون المعالجة الأفضل بسيطة بصرياً: تسمية أدق، أو تاريخ مراجعة، أو حالة «غير مؤكدة»، أو عدد نتائج يصف المطابقات المثبتة وحدها.
هذه التفاصيل أقل استعراضاً من صندوق بحث جديد، لكنها تعالج قيمة أعمق في تجربة المنتج.
الفلتر الأكثر خطورة ليس الذي يعترف بنقص البيانات، بل الذي يخفي النقص من الواجهة ويتركه قائماً في قاعدة البيانات.
المراجع والمنهج التحريري
الأمثلة افتراضية، والنموذج المقترح للحالات الأربع إطار مهني غير ملزم وليس تصنيفاً رسمياً في مواصفات RESO.