في السابق، كان تثبيت التطبيقات ممكنًا فقط في سياق التطبيقات المخصّصة للمنصة. في الوقت الحالي، توفّر تطبيقات الويب الحديثة تجارب قابلة للتثبيت توفّر مستوى الدمج والموثوقية نفسه الذي توفِّره التطبيقات الخاصة بنظام التشغيل الأساسي.
ويمكنك تحقيق ذلك بطرق مختلفة:
- تثبيت تطبيق الويب التقدّمي من المتصفّح
- تثبيت تطبيق الويب التقدّمي (PWA) من متجر التطبيقات
إنّ توفُّر قنوات توزيع مختلفة هي طريقة فعّالة للوصول إلى عدد كبير من المستخدمين، ولكن قد يكون من الصعب اختيار الاستراتيجية المناسبة للترويج لتثبيت تطبيقك المتوافق مع الأجهزة الجوّالة.
يتناول هذا الدليل أفضل الممارسات لدمج خيارات التثبيت المختلفة لزيادة معدّلات التثبيت وتجنُّب المنافسة بين المنصات وتأثيرها السلبي على التطبيقات. تشمل عروض التثبيت التي يتم تناولها تطبيقات الويب المتوافقة مع الأجهزة الجوّالة (PWAs) التي يتم تثبيتها من المتصفّح وApp Store، بالإضافة إلى التطبيقات المخصّصة للنظام الأساسي.
ما أهمية جعل تطبيق الويب قابلاً للتثبيت؟
يتم تشغيل تطبيقات الويب التقدّمية المثبَّتة في نافذة مستقلة بدلاً من علامة تبويب متصفّح. ويمكن تشغيلها من الشاشة الرئيسية للمستخدم أو شريط التطبيقات المضمّنة أو شريط التطبيقات أو الرف. ويمكن البحث عن التطبيق على أحد الأجهزة والانتقال بين التطبيقات باستخدام مبدِّل التطبيقات، ما يجعله يشعر وكأنّه جزء من الجهاز الذي تم تثبيته عليه.
ولكن استخدام تطبيق ويب قابل للتثبيت وتطبيق خاص بنظام أساسي قد يكون مربكًا للمستخدمين. بالنسبة لبعض المستخدمين، قد تكون التطبيقات الخاصة بنظام التشغيل هي الخيار الأفضل، ولكن بالنسبة إلى البعض الآخر، قد تكون هناك بعض العيوب:
- قيود مساحة التخزين: قد يؤدي تثبيت تطبيق جديد إلى حذف تطبيقات أخرى أو إخلاء بعض المساحة من خلال إزالة محتوى قيّم. وهذا غير مفيد بشكل خاص لمستخدمي الأجهزة المنخفضة التطور.
- النطاق الترددي المتاح: يمكن أن يكون تنزيل التطبيق عملية مكلفة وبطيئة، خاصةً للمستخدمين الذين يستخدمون اتصالات بطيئة وخطط بيانات باهظة الثمن.
- الاحتكاك: تؤدي مغادرة موقع إلكتروني والانتقال إلى متجر لتنزيل تطبيق إلى حدوث مشاكل إضافية وتؤدي إلى تأخير إجراء المستخدِم الذي يمكن تنفيذه مباشرةً على الويب.
- دورة التحديث: قد يتطلب إجراء التغييرات في التطبيقات الخاصة بالنظام الأساسي إجراء عملية مراجعة للتطبيق، ما قد يؤدي إلى إبطاء التغييرات والتجارب (على سبيل المثال، اختبارات أ/ب).
في بعض الحالات، قد تكون النسبة المئوية للمستخدمين الذين لن ينزّلوا تطبيقك المخصّص لمنصّة معيّنة كبيرة، على سبيل المثال: المستخدمون الذين يعتقدون أنّهم لن يستخدموا التطبيق بشكل متكرّر أو لا يمكنهم تبرير استخدام عدة ميغابايت من مساحة التخزين أو البيانات. يمكنك تحديد حجم هذه الشريحة بعدة طرق، على سبيل المثال باستخدام إعداد إحصاءات لتتبع النسبة المئوية لمستخدمي "ويب الجوّال فقط".
إذا كان حجم هذه الشريحة كبيرًا، هذا مؤشر جيد على أنّك بحاجة إلى توفير طرق بديلة لتثبيت تجاربك.
الترويج لتثبيت تطبيق الويب التقدّمي (PWA) من خلال المتصفّح
إذا كان لديك تطبيق ويب تقدّمي (PWA) عالي الجودة، قد يكون من الأفضل الترويج لتثبيته بدلاً من التطبيق الخاص بالنظام الأساسي. على سبيل المثال، إذا كان التطبيق الخاص بالنظام الأساسي لا يتضمّن الوظائف التي يوفّرها هذا التطبيق أو إذا لم يتم تحديثه منذ فترة. قد يكون من المفيد أيضًا الترويج لتثبيت تطبيق الويب التقدّمي (PWA) إذا لم يكن التطبيق الخاص بالنظام الأساسي متوافقًا مع الشاشات الأكبر حجمًا، كما هو الحال في ChromeOS.
بالنسبة إلى بعض التطبيقات، تشكّل زيادة عمليات تثبيت التطبيقات على مستوى نظام أساسي جزءًا أساسيًا من نموذج الأعمال، وفي هذه الحالة، من المنطقي الترويج لتثبيت تطبيقك الخاص بالنظام الأساسي، ولكن قد يكون بعض المستخدمين أكثر راحة في البقاء على الإنترنت. إذا كان بالإمكان تحديد هذه الشريحة، يمكن عرض طلب تطبيق الويب التقدّمي لها فقط (ما نُطلق عليه "تطبيق الويب التقدّمي كخيار احتياطي").
تطبيق الويب التقدّمي PWA كتجربة أساسية قابلة للتثبيت
بعد أن يستوفي تطبيق الويب التقدّمي معايير قابلية التثبيت، تعرض معظم المتصفّحات إشارة تفيد بأنّه يمكن تثبيت تطبيق الويب التقدّمي. على سبيل المثال، يعرض Chrome على سطح المكتب رمزًا قابلاً للتثبيت في شريط العناوين، بينما يعرض على الأجهزة الجوّالة شريط معلومات مصغّر:
قد يكون ذلك كافيًا لبعض التجارب، ولكن إذا كان هدفك هو زيادة عمليات تثبيت تطبيق الويب التقدّمي (PWA)، ننصحك بشدة بالاستماع إلى BeforeInstallPromptEvent
واتّباع الأنماط للترويج لتثبيت تطبيق الويب التقدّمي (PWA).
منع تطبيقك المتوافق مع الويب من التأثير سلبًا في معدّل تثبيت تطبيقك على المنصة
في بعض الحالات، يمكنك اختيار الترويج لتثبيت تطبيقك المخصّص للمنصة بدلاً من تطبيقك المتوافق مع الويب، ولكن في هذه الحالة، ننصحك بتوفير آلية للسماح للمستخدمين بتثبيت تطبيقك المتوافق مع الويب. يتيح خيار النسخ الاحتياطي هذا للمستخدمين الذين لا يمكنهم تثبيت تطبيقك المخصّص للمنصة أو لا يريدون تثبيته الحصول على تجربة مماثلة.
الخطوة الأولى لتنفيذ هذه الاستراتيجية هي تحديد طريقة استقرائية لتحديد الحالات التي ستعرض فيها للمستخدم عرضًا ترويجيًا للتثبيت لتطبيقك المتوافق مع الأجهزة الجوّالة.
على سبيل المثال: مستخدم تطبيق الويب التقدّمي (PWA) هو مستخدم اطّلع على طلب تثبيت التطبيق على مستوى النظام الأساسي ولم يثبِّت التطبيق الخاص بالنظام الأساسي. وقد عاد إلى الموقع الإلكتروني خمس مرات على الأقل، أو نقر على بانر التطبيق، ولكنه واصل استخدام الموقع الإلكتروني بدلاً من ذلك.
بعد ذلك، يمكن تنفيذ الإرشادي بالطريقة التالية:
- عرض بانر تثبيت التطبيق الخاص بالنظام الأساسي
- إذا أغلق أحد المستخدمين البانر، يمكنك إعداد ملف تعريف ارتباط يتضمّن هذه المعلومات (مثل
document.cookie = "app-install-banner=dismissed"
). - استخدِم ملفّ تعريف ارتباط آخر لتتبُّع عدد زيارات المستخدِمين إلى الموقع الإلكتروني (مثل
document.cookie = "user-visits=1"
). - اكتب دالة، مثل
isPWAUser()
، تستخدم المعلومات المخزَّنة سابقًا في ملفات تعريف الارتباط إلى جانب واجهة برمجة التطبيقاتgetInstalledRelatedApps()
لتحديد ما إذا كان المستخدم يُعتبَر مستخدم "مستخدم PWA". - عندما ينفِّذ المستخدِم إجراءً ذا مغزى، استخدِم
isPWAUser()
. إذا كانت الدالة تعرض القيمة "صحيح" وتم حفظ طلب تثبيت تطبيق الويب التقدّمي (PWA) سابقًا، يمكنك عرض زر تثبيت تطبيق الويب التقدّمي (PWA).
الترويج لتثبيت تطبيق الويب التقدّمي (PWA) من خلال متجر التطبيقات
ويمكن إنشاء تطبيقات متاجر التطبيقات باستخدام تكنولوجيات مختلفة، بما في ذلك تقنيات تطبيقات الويب التقدّمية (PWA). في مقالة دمج التطبيقات المتوافقة مع الويب في البيئات الأصلية، يمكنك العثور على ملخّص للتقنيات التي يمكن استخدامها لتحقيق هذا الغرض.
في هذا القسم، سنصنّف التطبيقات في المتجر إلى مجموعتَين:
- التطبيقات المخصّصة للنظام الأساسي: يتم إنشاء هذه التطبيقات في الغالب باستخدام رموز مخصّصة للنظام الأساسي. تعتمد أحجامها على النظام الأساسي، ولكنّها عادةً ما تكون أكبر من 10 ميغابايت على Android و30 ميغابايت على iOS. قد تحتاج إلى الترويج لتطبيقك المخصّص للمنصة إذا لم يكن لديك تطبيق متوافق مع تقنية PWA أو إذا كان التطبيق المخصّص للمنصة يقدّم مجموعة ميزات أكثر اكتمالاً.
- التطبيقات الخفيفة: يمكن إنشاء هذه التطبيقات باستخدام رمز خاص بالنظام الأساسي أيضًا، إلا أنه يتم إنشاؤها عادةً باستخدام تكنولوجيا الويب، وهي مضمّنة في برنامج تضمين خاص بالنظام الأساسي. ويمكن أيضًا تحميل تطبيقات الويب التقدّمية الكاملة إلى المتاجر. (يتمّ مناقشة هذا الأمر لاحقًا في هذه المقالة). واختارت بعض الشركات تقديم هذه التطبيقات كإصدارات "خفيفة"، وطبّقت شركات أخرى هذا النهج على تطبيقاتها الرئيسية أيضًا.
الترويج للتطبيقات الخفيفة
وفقًا لدراسة أجرتها Google Play، سينخفض معدّل الإحالات الناجحة لتثبيت APK بنسبة 1% مقابل كل زيادة مقدارها 6 ميغابايت إلى حجم حزمة APK. ويعني هذا أنّ معدّل إكمال تنزيل تطبيق بحجم 10 ميغابايت قد يكون أعلى بنسبة 30% تقريبًا من تطبيق بحجم 100 ميغابايت.
لحلّ هذه المشكلة، تستفيد بعض الشركات من تطبيق الويب التقدّمي (PWA) لتوفير إصدار خفيف من تطبيقاتها في "متجر Play" باستخدام أنشطة الويب الموثوقة (TWA). تُغلف هذه التطبيقات تطبيق الويب التقدّمي (PWA) في 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
}
الخاتمة
تعد القدرة على الحصول على أيقونة في الشاشة الرئيسية للمستخدم إحدى أكثر ميزات التطبيقات جاذبية. وبما أنّ هذا الأمر كان ممكنًا في السابق فقط مع التطبيقات المثبَّتة من متاجر التطبيقات، قد تعتقد الشركات أنّ عرض بانر لتثبيت التطبيقات في متجر التطبيقات سيكون كافيًا لإقناع المستخدمين بتثبيت تجارب التطبيقات. تتوفّر حاليًا المزيد من الخيارات للسماح للمستخدمين بتثبيت تطبيق، بما في ذلك توفير تجارب تطبيقات خفيفة الوزن في المتاجر والسماح للمستخدمين بإضافة تطبيقات الويب التقدمية إلى الشاشة الرئيسية من خلال مطالبتهم بتنفيذ ذلك مباشرةً من الموقع الإلكتروني.