تطوير إضافة للمتصفح: المهام والصلاحيات والنشر

إضافة المتصفح برنامج صغير يعمل مباشرة داخل Chrome أو Edge أو Firefox أو Safari: تضيف زرًا، وتقرأ البيانات المطلوبة من الصفحة، وتملأ النماذج، أو تربط الموقع المفتوح لدى الموظف بنظام CRM وخدماتك. تستغرق الإضافة البسيطة ذات السيناريو الواحد عادة من أسبوع إلى أسبوعين، إضافة إلى بضعة أيام لمراجعة متاجر الإضافات.

ما المهام التي تؤديها الإضافة

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

• جمع البيانات: تُحفظ بطاقة المنتج أو جهة الاتصال أو الإعلان في CRM أو جدول بضغطة واحدة دون نسخ يدوي.
• تلميحات على الصفحة: تعرض الإضافة بجانب الحقل المطلوب الحالة أو السعر أو سجل العميل من نظامك.
• ملء النماذج: تُملأ الحقول المتكررة في لوحات التحكم من بياناتك.
• الربط بوكيل ذكاء اصطناعي: يُرسل النص المحدد أو الصفحة المفتوحة إلى الوكيل ويعود الجواب في لوحة جانبية — انظر «وكيل الذكاء الاصطناعي للأعمال».
• منتج للعملاء: إضافة مستقلة كمنتج قائم بذاته أو مرافقة لخدمتك على الويب.

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

كيف تُبنى الإضافة الحديثة

تقبل متصفحات Chrome وEdge وغيرها من متصفحات Chromium الإضافات بصيغة Manifest V3، ويدعم Firefox الصيغة نفسها مع فروق بسيطة، أما في Safari فتُحزَّم الإضافة داخل تطبيق عبر Xcode. لذلك تغطي قاعدة شيفرة واحدة عادة المتصفحات الأربعة، وتُعالَج الفروق بإعدادات بناء بسيطة.

• عامل الخلفية (service worker) يستقبل الأحداث ويتواصل مع خادمك.
• سكربت المحتوى يقرأ ويغيّر ما يلزم فقط على مواقع محددة.
• النافذة المنبثقة أو اللوحة الجانبية هي واجهة الإضافة.
• صفحة الإعدادات لتسجيل الدخول واختيار الوضع واللغة.

يمنع Manifest V3 الشيفرة البعيدة: يمر منطق الإضافة كله بمراجعة المتجر معها، بينما تأتي البيانات والقواعد من خادمك.

الصلاحيات والأمان

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

• طلب الوصول فقط إلى المواقع التي تعمل عليها الإضافة.
• عدم تخزين كلمات المرور والمفاتيح في الإضافة — يتم الدخول عبر خادمك.
• توضيح البيانات التي تُجمع وسبب جمعها في سياسة الخصوصية.
• التحقق من كل حقل وارد على الخادم بدل الثقة ببيانات الصفحة.

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

النشر في متاجر الإضافات

تُنشر الإضافة في Chrome Web Store وMicrosoft Edge Add-ons وFirefox Add-ons وApp Store (لـ Safari). يحتاج كل متجر إلى وصف ولقطات شاشة وأيقونات وسياسة خصوصية وتبرير لكل صلاحية مطلوبة. تستغرق المراجعة عادة من بضع ساعات إلى بضعة أيام، وأكثر عند الصلاحيات الواسعة.

لا يلزم نشر أداة الشركة الداخلية علنًا: يمكن تثبيتها عبر رابط خاص أو عبر إدارة المتصفحات في الشركة.

المدة والتكلفة

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

الأفضل البدء بسيناريو واحد لمتصفح واحد وإضافة الباقي في الإصدارات التالية: هكذا تظهر الفائدة أسرع وتُختبر القرارات على مستخدمين حقيقيين. المزيد في «تطوير MVP».

إضافة أم خدمة ويب أم بوت: ماذا تختار

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

كثيرًا ما يكون الحل الصحيح مزيجًا: خدمة الويب تحفظ البيانات والقواعد، والإضافة تضع زرًا في الصفحة المطلوبة، والبوت يرسل الإشعارات. المزيد عن جانب الويب في صفحة تطوير تطبيقات الويب، وعن البوتات في دليل بوت Telegram للأعمال.

مراحل تطوير الإضافة

يسير العمل بخطوات قصيرة، وتنتهي كل خطوة بنتيجة يمكن تجربتها بنفسك.

1. تحليل المهمة. نحدد سيناريو رئيسيًا واحدًا: على أي مواقع تعمل الإضافة، وماذا تقرأ، وإلى أين ترسل البيانات، وماذا يرى المستخدم. وهنا أيضًا نقرر الصلاحيات المطلوبة فعلًا.
2. النموذج الأولي. نبني زرًا أو لوحة جانبية تعمل على موقع واحد وفي متصفح واحد للتأكد من أن بيانات الصفحة تُقرأ بشكل موثوق.
3. جانب الخادم. نُعدّ تسجيل الدخول بالحساب واستقبال البيانات والتحقق من الحقول والكتابة إلى نظام CRM أو الجداول أو الأنظمة الأخرى.
4. الواجهة والنصوص. النافذة المنبثقة والإعدادات ورسائل الأخطاء الواضحة ولغات الواجهة.
5. الاختبار. نختبر على صفحات حقيقية وفي إصدارات مختلفة من المتصفح وعلى اتصال بطيء، ونتحقق بشكل منفصل من سلوك الإضافة إذا غيّر الموقع تصميمه.
6. النشر. نُعدّ الوصف ولقطات الشاشة وسياسة الخصوصية وتبرير الصلاحيات، ثم نرسل الإضافة إلى مراجعة المتجر أو نوزعها عبر رابط خاص.

ما الذي يجب فحصه عند استلام كل مرحلة مشروح بالتفصيل في دليل استلام المشروع البرمجي.

التحديثات بعد النشر

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

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

نُدرج الدعم بعد الإطلاق في الخطة من البداية: فحص قصير بعد تحديثات المتصفحات وإصلاحات بحسب سجل الأخطاء أقل تكلفة من الإصلاح العاجل.

أخطاء شائعة

معظم مشكلات الإضافات لا تأتي من الشيفرة، بل من قرارات تُتخذ في البداية.

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

كيف نعمل

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

الخبرة التي نعتمد عليها تأتي من منتجاتنا الخاصة Wallet وLegal ومصنع المحتوى: جانب الخادم وتسجيل الدخول بالحساب ووظائف الذكاء الاصطناعي والنشر في متاجر التطبيقات والدعم بعد الإطلاق. ونطبق القواعد نفسها على الإضافات: أقل الصلاحيات، والمفاتيح على الخادم فقط، وسجل الأخطاء، والإصدارات المخططة.

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