في السابق، كان تثبيت التطبيقات ممكنًا فقط في سياق التطبيقات المخصّصة للمنصة. في الوقت الحالي، توفّر تطبيقات الويب الحديثة تجارب قابلة للتثبيت توفّر المستوى نفسه من الدمج والموثوقية الذي توفّره التطبيقات المخصّصة للمنصة.
يمكنك تحقيق ذلك بطرق مختلفة:
- تثبيت تطبيق الويب التقدّمي من المتصفّح
- تثبيت تطبيق الويب التقدّمي من متجر التطبيقات
إنّ توفُّر قنوات توزيع مختلفة هي طريقة فعّالة للوصول إلى عدد كبير من المستخدمين، ولكن قد يكون من الصعب اختيار الاستراتيجية المناسبة للترويج لتثبيت تطبيقك المتوافق مع الأجهزة الجوّالة.
يتناول هذا الدليل أفضل الممارسات لدمج خيارات التثبيت المختلفة لزيادة معدّلات التثبيت وتجنُّب المنافسة بين المنصات وتأثيرها السلبي على التطبيقات. تشمل عروض التثبيت التي يتم تناولها تطبيقات الويب المتقدّمة (PWAs) التي يتم تثبيتها من المتصفّح وApp Store، بالإضافة إلى التطبيقات المخصّصة للنظام الأساسي.
ما أهمية جعل تطبيق الويب قابلاً للتثبيت؟
يتم تشغيل تطبيقات الويب التقدّمية المثبَّتة في نافذة مستقلة بدلاً من علامة تبويب في المتصفّح. ويمكن تشغيلها من الشاشة الرئيسية للمستخدم أو من شريط التطبيقات المضمّنة أو شريط التطبيقات أو الرف. ومن الممكن البحث عنها على جهاز والانتقال بينها باستخدام أداة تبديل التطبيقات، ما يجعلها تبدو كجزء من الجهاز المثبَّت عليه.
ولكن قد يكون من المربك للمستخدمين توفُّر تطبيق ويب قابل للتثبيت وتطبيق خاص بنظام التشغيل. قد تكون التطبيقات المخصّصة للمنصة هي الخيار الأفضل لبعض المستخدمين، ولكن قد تتسبب في بعض المشاكل للآخرين:
- قيود مساحة التخزين: قد يؤدي تثبيت تطبيق جديد إلى حذف تطبيقات أخرى أو إخلاء بعض المساحة من خلال إزالة محتوى قيّم. ويعود ذلك بالضرر على المستخدمين الذين يستخدمون الأجهزة ذات الإمكانيات المنخفضة بشكل خاص.
- النطاق الترددي المتاح: يمكن أن يكون تنزيل التطبيق عملية مكلفة وبطيئة، خاصةً للمستخدمين الذين يستخدمون اتصالات بطيئة وخطط بيانات باهظة الثمن.
- المشاكل: يؤدي مغادرة موقع إلكتروني والانتقال إلى متجر لتنزيل تطبيق إلى حدوث مشاكل إضافية وتأخير إجراء المستخدم الذي يمكن تنفيذه مباشرةً على الويب.
- دورة التحديث: قد يتطلّب إجراء تغييرات في التطبيقات المخصّصة للمنصة اجتياز عملية مراجعة التطبيق، ما قد يؤدي إلى إبطاء التغييرات والتجارب (اختبارات أ/ب على سبيل المثال).
في بعض الحالات، قد تكون النسبة المئوية للمستخدمين الذين لن ينزّلوا تطبيقك المخصّص للنظام الأساسي كبيرة، على سبيل المثال: المستخدمون الذين يعتقدون أنّهم لن يستخدموا التطبيق بشكل متكرّر أو لا يمكنهم تبرير استخدام عدة ميغابايت من مساحة التخزين أو البيانات. يمكنك تحديد حجم هذه الشريحة بعدة طرق، على سبيل المثال باستخدام إعدادات إحصاءات لتتبُّع النسبة المئوية لمستخدمي "الموقع الإلكتروني المتوافق مع الأجهزة الجوّالة فقط".
إذا كان حجم هذا الجزء كبيرًا، هذا مؤشر جيد على أنّك بحاجة إلى توفير طرق بديلة لتثبيت تجاربك.
الترويج لتثبيت تطبيقك المتوافق مع الأجهزة الجوّالة على الويب من خلال المتصفّح
إذا كان لديك تطبيق ويب تقدّمي (PWA) عالي الجودة، قد يكون من الأفضل الترويج لتثبيته بدلاً من تطبيقك المخصّص للمنصة. على سبيل المثال، إذا كان التطبيق المخصّص للمنصة لا يتضمّن وظائف يوفّرها تطبيق الويب التقدّمي، أو إذا لم يتم تحديثه منذ فترة. قد يكون من المفيد أيضًا الترويج لتثبيت تطبيق الويب التقدمي إذا لم يتم تحسين التطبيق المخصّص للمنصة للتوافق مع الشاشات الأكبر حجمًا، مثل شاشات ChromeOS.
بالنسبة إلى بعض التطبيقات، يشكّل جذب عمليات تثبيت التطبيق المخصّصة للنظام الأساسي جزءًا أساسيًا من نموذج النشاط التجاري، وفي هذه الحالة، يكون من المنطقي من وجهة نظر النشاط التجاري الترويج لتثبيت تطبيقك المخصّص للنظام الأساسي. ولكن قد يشعر بعض المستخدمين بالراحة عند البقاء على الويب. إذا كان بالإمكان تحديد هذه الشريحة، يمكن عرض طلب تطبيق الويب التقدّمي لها فقط (ما نُطلق عليه "تطبيق الويب التقدّمي كخيار احتياطي").
تطبيق الويب التقدّمي كتجربة قابلة للتثبيت بشكل أساسي
بعد أن يستوفي تطبيق الويب التقدّمي معايير قابلية التثبيت، تعرض معظم المتصفّحات إشارة تفيد بأنّه يمكن تثبيت تطبيق الويب التقدّمي. على سبيل المثال، يعرض متصفّح Chrome لأجهزة الكمبيوتر المكتبي رمزًا قابلاً للتثبيت في شريط العناوين، ويعرض على الأجهزة الجوّالة شريط معلومات مصغّرًا:
قد يكون ذلك كافيًا لبعض التجارب، ولكن إذا كان هدفك هو زيادة عمليات تثبيت تطبيق الويب التقدّمي، ننصحك بشدة بالاستماع إلى BeforeInstallPromptEvent واتّباع أنماط الترويج لتثبيت تطبيق الويب التقدّمي.
منع تطبيقك المتوافق مع الويب من التأثير سلبًا في معدّل تثبيت تطبيقك على المنصة
في بعض الحالات، يمكنك اختيار الترويج لتثبيت تطبيقك المخصّص للمنصة بدلاً من تطبيقك المتوافق مع الويب، ولكن في هذه الحالة، ننصحك بتوفير آلية للسماح للمستخدمين بتثبيت تطبيقك المتوافق مع الويب. يتيح خيار النسخ الاحتياطي هذا للمستخدمين الذين لا يمكنهم تثبيت تطبيقك المخصّص للمنصة أو لا يريدون تثبيته الحصول على تجربة مماثلة.
الخطوة الأولى لتنفيذ هذه الاستراتيجية هي تحديد طريقة استقرائية لتحديد الحالات التي ستعرض فيها للمستخدم عرضًا ترويجيًا للتثبيت لتطبيقك المتوافق مع الأجهزة الجوّالة.
على سبيل المثال: مستخدِم تطبيق الويب التقدّمي هو مستخدِم شاهد طلب تثبيت التطبيق المخصّص للمنصة ولم يثبِّت التطبيق المخصّص للمنصة. وقد عاد إلى الموقع الإلكتروني خمس مرّات على الأقل، أو نقر على بانر التطبيق، ولكنّه استمر في استخدام الموقع الإلكتروني بدلاً من ذلك.
بعد ذلك، يمكن تنفيذ المنهج التجريبي على النحو التالي:
- عرض بانر تثبيت التطبيق المخصّص للمنصة
- إذا أغلق المستخدِم البانر، اضبط ملفّ تعريف ارتباط يتضمّن هذه المعلومات (مثل
document.cookie = "app-install-banner=dismissed"). - استخدِم ملفّ تعريف ارتباط آخر لتتبُّع عدد زيارات المستخدِمين إلى الموقع الإلكتروني (مثل
document.cookie = "user-visits=1"). - اكتب دالة، مثل
isPWAUser()، تستخدِم المعلومات المخزّنة سابقًا في ملفات تعريف الارتباط مع واجهة برمجة التطبيقاتgetInstalledRelatedApps()لتحديد ما إذا كان المستخدم "مستخدم تطبيق متوافق مع الأجهزة الجوّالة". - عندما ينفِّذ المستخدِم إجراءً ذا مغزى، استخدِم
isPWAUser(). إذا كانت الدالة تعرض القيمة "صحيح" وتم حفظ طلب تثبيت تطبيق الويب التقدّمي (PWA) سابقًا، يمكنك عرض زر تثبيت تطبيق الويب التقدّمي (PWA).
الترويج لتثبيت تطبيقك المتوافق مع الأجهزة الجوّالة من خلال متجر تطبيقات
يمكن إنشاء تطبيقات لمتاجر التطبيقات باستخدام تقنيات مختلفة، بما في ذلك تقنيات تطبيقات الويب التقدمية. في مقالة دمج التطبيقات المتوافقة مع الويب في البيئات الأصلية، يمكنك العثور على ملخّص للتقنيات التي يمكن استخدامها لتحقيق هذا الغرض.
في هذا القسم، سنصنّف التطبيقات في المتجر إلى مجموعتَين:
- التطبيقات المخصّصة للنظام الأساسي: يتم إنشاء هذه التطبيقات في الغالب باستخدام رموز مخصّصة للنظام الأساسي. وتعتمد أحجامها على النظام الأساسي، ولكنّها عادةً ما تكون أكبر من 10 ميغابايت على Android و30 ميغابايت على iOS. قد تحتاج إلى الترويج لتطبيقك المخصّص للمنصة إذا لم يكن لديك تطبيق متوافق مع تقنية PWA أو إذا كان التطبيق المخصّص للمنصة يقدّم مجموعة ميزات أكثر اكتمالاً.
- التطبيقات البسيطة: يمكن إنشاء هذه التطبيقات باستخدام رمز برمجي خاص بالمنصة أيضًا، ولكن يتم إنشاؤها عادةً باستخدام تكنولوجيا الويب، ويتم حزمها في حزمة خاصة بالمنصة. ويمكن أيضًا تحميل تطبيقات الويب التقدّمية الكاملة إلى المتاجر. (يتمّ مناقشة هذا الأمر لاحقًا في هذه المقالة). واختارت بعض الشركات تقديم هذه التطبيقات كإصدارات "خفيفة"، وطبّقت شركات أخرى هذا النهج على تطبيقاتها الرئيسية أيضًا.
الترويج للتطبيقات الخفيفة الوزن
وفقًا لدراسة أجراها فريق Google Play، فإنّه مع كل زيادة في حجم حزمة APK تبلغ 6 ميغابايت، ينخفض معدّل الإحالات الناجحة بنسبة %1. وهذا يعني أنّ نسبة إكمال تنزيل تطبيق حجمه 10 ميغابايت قد تكون أعلى بنسبة% 30 تقريبًا من نسبة إكمال تنزيل تطبيق حجمه 100 ميغابايت.
لحلّ هذه المشكلة، تستفيد بعض الشركات من تطبيقات الويب التقدّمية لتقديم إصدار خفيف من تطبيقاتها في "متجر Play" باستخدام أنشطة الويب الموثوق بها (TWA). تُغلِّف هذه التطبيقات تطبيقات الويب التقدّمية في مكوّن يشبه WebView، ويكون حجم التطبيق الناتج عادةً بضعة ميغابايت فقط.
أنشأت شركة Oyo، وهي إحدى أكبر شركات الضيافة في الهند، إصدارًا Lite من تطبيقها، وجعلته متاحًا في "متجر Play" باستخدام حزمة تطوير تطبيقات الويب (TWA). في وقت كتابة هذه المقالة، كان حجم تطبيق Oyo 850 كيلوبايت فقط، أي 7% فقط من حجم تطبيق Android. وبعد تثبيته، لا يمكن تمييزه عن تطبيق Android:
أبقت Oyo على إصدارَي التطبيق الرئيسي و "الإصدار البسيط" في المتجر، ما وفّر خيارًا للمستخدمين.
توفير تجربة ويب خفيفة الوزن
من البديهي أنّ المستخدمين الذين يستخدمون الأجهزة المنخفضة المستوى قد يميلون أكثر إلى تنزيل إصدارات التطبيقات الخفيفة مقارنةً بالمستخدمين الذين يستخدمون الهواتف الراقية. لذلك، إذا كان من الممكن تحديد جهاز المستخدم، يمكنك منح الأولوية للإعلان البانر الخفيف لتثبيت التطبيق على إصدار التطبيق الأكبر حجمًا والمخصّص للمنصة.
على الويب، من الممكن الحصول على إشارات الجهاز وربطها تقريبًا بفئات الأجهزة (مثل "عالٍ" أو "متوسط" أو "منخفض"). يمكنك الحصول على هذه المعلومات بطرق مختلفة، إما باستخدام واجهات برمجة تطبيقات JavaScript أو تلميحات العميل.
استخدام JavaScript
باستخدام سمات JavaScript، مثل navigator.hardwareConcurrency وnavigator.deviceMemory وnavigator.connection، يمكنك الحصول على معلومات عن وحدة المعالجة المركزية للجهاز والذاكرة وحالة الشبكة على التوالي. على سبيل المثال:
const deviceCategory = req.get('Device-Memory') < 1 ? 'lite' : 'full';`
استخدام تعديلات العميل
يمكن أيضًا استنتاج إشارات الجهاز في رؤوس طلبات HTTP من خلال إشارات العميل. في ما يلي كيفية تنفيذ الرمز السابق لذاكرة الجهاز باستخدام إشارات العميل:
أولاً، أخبِر المتصفّح بأنّك مهتم بتلقّي إشارات حول ذاكرة الجهاز في عنوان استجابة HTTP لأي طلب من جهة خارجية:
HTTP/1.1 200 OK
Content-Type: text/html
Accept-CH: Device-Memory
بعد ذلك، ستبدأ في تلقّي معلومات Device-Memory في عنوان طلب طلبات HTTP:
GET /main.js HTTP/1.1
Device-Memory: 0.5
يمكنك استخدام هذه المعلومات في الخلفيات لتخزين ملفّ تعريف ارتباط يتضمّن فئة جهاز المستخدِم:
app.get('/route', (req, res) => {
// Determine device category
const deviceCategory = req.get('Device-Memory') < 1 ? 'lite' : 'full';
// Set cookie
res.setCookie('Device-Category', deviceCategory);
…
});
أخيرًا، أنشئ منطقك الخاص لربط هذه المعلومات بفئات الأجهزة، وعرض طلب تثبيت التطبيق المقابل في كل حالة:
if (isDeviceMidOrLowEnd()) {
// show "Lite app" install banner or PWA A2HS prompt
} else {
// show "Core app" install banner
}
الخاتمة
إنّ إمكانية عرض رمز التطبيق على شاشة المستخدم الرئيسية هي إحدى الميزات الأكثر جاذبية للتطبيقات. وبما أنّ هذا الإجراء لم يكن ممكنًا في السابق إلا للتطبيقات المثبَّتة من متاجر التطبيقات، قد تعتقد الشركات أنّ عرض بانر تثبيت من متجر التطبيقات سيكون كافيًا لإقناع المستخدمين بتثبيت تجاربهم. تتوفّر حاليًا المزيد من الخيارات للسماح للمستخدمين بتثبيت تطبيق، بما في ذلك توفير تجارب تطبيقات خفيفة الوزن في المتاجر والسماح للمستخدمين بإضافة تطبيقات الويب التقدمية إلى الشاشة الرئيسية من خلال مطالبتهم بتنفيذ ذلك مباشرةً من الموقع الإلكتروني.