تجاوز اختصار لوحة مفاتيح "ابحث في الصفحة" في المتصفح

مرحبًا، أنا من معجبي Discourse، وأتبع مجتمعًا صغيرًا يناقش الانتقال من vBulletin5. عارض شخص استخدام Discourse قائلاً: «اختطاف Ctrl+f أمر سيء»، وبعد فهم ما يقصده، لا بد أن أوافق. هناك مشكلة حقيقية في قابلية الاستخدام تتعلق بكيفية تعامل Discourse حاليًا مع Ctrl+f، وهو اختصار المتصفح للبحث عن نص داخل هذه الصفحة.

المشكلة

  • في بعض الأحيان، يعمل Ctrl+f كما ينبغي، ويستخدم Discourse وظيفة البحث المدمجة في المتصفح بحيث تنتقل الصفحة فورًا إلى أول نتيجة بمجرد الكتابة. وينقل Ctrl+G إلى النتيجة التالية.
    • الحياة جميلة.
  • في أحيان أخرى، لا يعمل Ctrl+f، وبدلًا من ذلك يعرض قائمة بنتائج بحث من قاعدة البيانات.
    • لا ينتقل بالصفحة إلى أول نتيجة أثناء كتابة المستخدم.
    • لا يتم تمييز عبارة البحث إلا إذا كانت موجودة بالفعل على الشاشة.
    • لا يسمح بالبحث عن مصطلحات قصيرة جدًا، مثل “UX”.
    • لا يقبل Ctrl+G لعرض النتيجة التالية.
    • يعرض نتائج لمواضيع غير ذات صلة لم يكن Ctrl+f ليعرضها لو لم يجد المصطلح في الصفحة.
  • سبب هذا التعطل غير مرئي تمامًا للمستخدمين، لكنه محبط للغاية. يشعرون بأن قدرة البحث داخل الصفحة قد أُزيلت دون أي تفسير.
  • لا يفيد إخبارهم أن الضغط مرتين على Ctrl+f سيجري بحث المتصفح، لأن ذلك سيفشل في العثور على منشورات موجودة فعليًا.

السبب الجذري

هذه ليست مشكلة شكلية، بل مشكلة أساسية في قابلية الاستخدام يجب على Discourse حلها من الجذر: الوهم بأن محادثة كاملة موجودة فعليًا في مستند نموذج الكائن (DOM) للمتصفح، بينما في الواقع يتم تحميلها ديناميكيًا.

عندما يكون هناك أكثر من عشرين منشورًا في موضوع، يرسل Discourse المنشورات إلى المتصفح فقط عند الحاجة. يمكنك عرض خيط يحتوي على أكثر من 1000 منشور مع حمل شبه معدوم على الخادم لأن معظم DOM عبارة عن مسودات فارغة. هذه فكرة رائعة، لكنها أيضًا ما يتسبب في تعطل Ctrl+f بشكل غامض.

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

ما يحتاجه Discourse ببساطة هو تحسين جعل هذا الوهم سلسًا.

الحلول

بصراحة، لا أعرف الحل الأمثل لهذه المشكلة، لكن لدي بعض الأفكار التي آمل أن تكون مفيدة.

كسر الوهم عمدًا

أولاً، إليك بعض الأفكار البسيطة والمعقولة إذا كان Discourse سيقوم بكسر الوهم بالتبديل إلى بحث في قاعدة البيانات:

  1. أخبر المستخدم بما يحدث. ضع ملاحظة صغيرة حيث يظهر عادةً صندوق البحث في المتصفح مع اعتذار وشرح.
  • «نعتذر، لكن هذا الموضوع يحتوي على 1002 منشور، لكن متصفحك يحتوي فقط على 7 منها محملة، لذا قد لا يعمل «البحث في الصفحة». إذا كنت ترغب في المحاولة على أي حال، اضغط على Ctrl+f مرة أخرى.»
  1. امنح المستخدم بعض التحكم. عندما يضغط المستخدم على Ctrl+f، أظهر زرًا يسمح للمستخدمين بتحميل نص جميع منشورات الموضوع يدويًا إلى DOM.
  • إذا كان ذلك مستحيلًا بسبب حد 100 منشور مخزنة في المتصفح في وقت واحد، فأظهر زرًا يسمح للمستخدمين بالعودة إلى الطريقة القديمة لعرض المواضيع: مقسمة حسب الصفحة.
  • «انقر هنا لعرض هذا الموضوع بطريقة تعمل مع Ctrl+f: [الصفحة 1] [2] [3] [4] [5] [6] [7] [8] [9] […] [>>]»
  1. زيادة حد القطع الافتراضي من 20 منشورًا إلى 100 منشور. قد لا يكون تغيير ذلك صعبًا جدًا، حيث يمكن لـ Discourse بالفعل تخزين ذلك العدد من المنشورات في DOM.

إصلاح الوهم

بالطبع، هذه الأفكار قبيحة وأعتبرها مجرد حلول مؤقتة. في النهاية، سيكون الحل الأفضل هو قيام Discourse بتنفيذ Ctrl+f بطريقة تعمل كما يتوقع الناس. تكرار ما يفعله المتصفح للبحث التفاعلي داخل Discourse يستحق العناء جدًا، لكنني أتخيل أنه سيكون صعبًا.

ومع ذلك، قد يكون هناك حل (نسبيًا) بسيط.

عدم اقتطاع النص من DOM

أعتقد أن أفضل حل لـ Discourse هو إزالة كائنات الوسائط فقط من المنشورات، وليس النص. عندئذٍ لن يكون هناك حاجة لـ «اختطاف Ctrl+f» واستبداله ببحث في قاعدة البيانات.

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

أنتم جميعًا تعرفون هذا أفضل مني، لكن لدي بعض التخمينات:

  • متوسط حجم المنشور: 5 كيلوبايت من النص.
  • متوسط طول الموضوع: 50 ردًا.
  • متوسط النص المراد نقله: 250 كيلوبايت، وهو ما يبدو معقولاً.

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

شكرًا

في حين أن تعطل Ctrl+f يكسر الوهم الذي ينشئه Discourse مشكلة خطيرة، إلا أنني معجب بالعمل الرائع الذي قام به مطورو Discourse في إنشاء هذا الوهم من الأساس. أنا واثق من أنهم سيصلون في النهاية إلى الإصلاح الصحيح لهذه المشكلة أيضًا.

شكرًا لك على تخصيص الوقت للنظر في مقترحاتي.

مع خالص التقدير،

Mx. F.N.

3 إعجابات

أتشاركك الشعور بأن تجربة المستخدم هنا محبطة ومفاجئة. بالنسبة لي أيضًا، فإن الإحراج يكمن في محاولة التمرير للأعلى والأسفل في موضوع بسيط يحتوي على 30 موضوعًا. إنها النقطة الوحيدة في Discourse التي تُشعرني بالإحراج.

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

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

أود معرفة ما إذا كان من الممكن عمليًا للمطور تخصيص:
(1) عدد المواضيع في كل جزء (مثل التباين حسب الجهاز)
(2) إبقاء المواضيع التي تم تصييرها بالفعل مرئية، بدلاً من إزالتها كما يحدث حاليًا (مما يجعل التمرير إلى الأعلى غير سلس).

أقدر أن هذا مجال معقد حقًا ولا توجد له حلول مثالية، وقد بُذل فيه الكثير من الجهد بالفعل.

إعجاب واحد (1)

كانت هناك الكثير من الأفكار الجيدة حول هذا الموضوع في هذا الخيط، التنفيذ الحالي (لا يزال) مروع.
لا تفعل ذلك، فقط لا تتجاوز الاختصارات القوية. حتى نهج لوحات الإعلانات القديم مع عدة أزرار بحث أكثر سهولة. ابحث عن طريقة جيدة للبحث عن موضوع أو اتركه للمستخدم لتحميل كل المحتوى ذي الصلة في DOM (وهو أمر مروع أيضًا). قدم أحد المؤسسين المشاركين أفضل نصيحة، اضغط عليه مرتين. يبدو أننا أذكى…