اللبنات الأساسية لتطبيقات الويب التقدمية

يمكن أن تحل تطبيقات الويب محل جميع وظائف التطبيقات والمواقع الأصلية مرة واحدة. إنهم يبرزون أكثر فأكثر في المقدمة هذه الأيام ، لكن لا يزال هناك عدد كافٍ من الناس على دراية بهم أو يتبنونهم.

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

ما الذي يجعل تطبيق الويب تقدميًا؟

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

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

في الوقت نفسه ، يجب ألا تضحي بالأشياء التي تجعل الويب رائعًا ، مثل القدرة على الارتباط بعمق في التطبيق واستخدام عناوين URL لتمكين مشاركة المحتوى. مثل الويب ، يجب أن يعمل بشكل جيد عبر الأنظمة الأساسية ولا يركز فقط على الهاتف المحمول. يجب أن يتصرف بشكل جيد على جهاز كمبيوتر سطح المكتب كما هو الحال في عوامل الشكل الأخرى ، حتى لا نخاطر بوقوع حقبة أخرى من مواقع m.example.com غير المستجيبة.

تطبيقات الويب التقدمية ليست جديدة. تتمتع متصفحات الهاتف المحمول بالقدرة على وضع إشارة مرجعية على موقع ويب على الشاشة الرئيسية لهاتفك منذ عام 2011 (2013 على Chrome Android) ، مع وجود علامات وصفية في head تحدد مظهر صفحة الويب المثبتة. تستخدم Financial Times تطبيق ويب لتسليم المحتوى الرقمي على الأجهزة المحمولة منذ عام 2012.

أدى الانتقال إلى تطبيق ويب إلى تمكين Financial Times من استخدام نفس التطبيق للشحن عبر الأنظمة الأساسية في قناة توزيع واحدة. مرة أخرى عندما كنت أعمل في Financial Times ، من خلال بنية واحدة تمكنا من دعم ما يلي:

• iOS ،
• Android (4.4+) Chrome ،
• Android الأقدم (عبر غلاف) ،
• ويندوز 8،
• بلاك بيري،
• نظام تشغيل Firefox.

هذا يحقق حقًا "البناء مرة واحدة ، والنشر في أي مكان."

"ولكن ليس في متجر التطبيقات"

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

أود أن أزعم أن التواجد في متجر التطبيقات ليس له ميزة كبيرة لأنه تم إثبات أنه إذا لم تكن ضمن أعلى 0.1٪ من التطبيقات في متجر التطبيقات ، فلن تحصل على فائدة كبيرة من وجودك هناك.

يميل المستخدمون إلى العثور على تطبيقاتك من خلال إيجاد موقع الويب الخاص بك أولاً. إذا كان موقع الويب الخاص بك هو تطبيق ويب ، فعندئذٍ يكونون في وجهتهم بالفعل.

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

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

الخلفية والمناخ الحالي

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

منذ نشأة تطبيق الويب في عام 2011 ، والذي مكّن مواقع الويب من الإشارة المرجعية إلى الشاشة الرئيسية ، حدث عدد من التطورات لوضع المزيد من الأعمال الأساسية لإنشاء تطبيقات ويب تقدمية.

قدم Chrome 38 بيان تطبيق الويب ، وهو ملف JSON يصف تكوين تطبيق الويب الخاص بك. هذا سمح لنا بإزالة التكوين من head .

في Chrome 40 (ديسمبر 2014) ، بدأ عمال الخدمة في الانتشار عبر Firefox و Chrome. اختارت Apple حتى الآن عدم تنفيذ هذه الميزة في Safari اعتبارًا من وقت كتابة هذا التقرير ولكنها "قيد الدراسة". تتمثل وظيفة عامل الخدمة في تبسيط عملية جعل التطبيق غير متصل بالإنترنت ؛ كما أنه يضع الأساس لميزات شبيهة بالتطبيقات في المستقبل ، مثل دفع الإخطارات ومزامنة الخلفية.

التطبيقات التي تم إنشاؤها بناءً على عمال الخدمة الجدد وأصبح بيان تطبيق الويب يُعرف باسم تطبيقات الويب التقدمية.

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

• لديه عامل خدمة (يتطلب HTTPS) ؛
• يحتوي على ملف بيان تطبيق ويب (مع الحد الأدنى من التكوين على الأقل ومع display: "standalone" ) ؛
• قام بزيارتين متميزتين.

في هذه الحالة ، تعني كلمة "تقدمية" أنه كلما زادت الميزات التي يدعمها المتصفح ، كلما كانت التجربة شبيهة بالتطبيق.

تظهر المطالبة بتثبيت تطبيق الويب حاليًا في ظل ظروف مختلفة عبر متصفح Opera و Chrome و Samsung.

أشارت Apple إلى اهتمامها بتطبيقات الويب التقدمية لنظام iOS ، ولكنها في وقت كتابة هذا التقرير لا تزال تعتمد على العلامات الوصفية لتكوين تطبيقات الويب وذاكرة التخزين المؤقت للتطبيق (AppCache) للاستخدام في وضع عدم الاتصال.

في أي مرحلة يصبح موقع الويب تطبيق ويب؟

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

هنا سوف ندخل في مزيد من التفاصيل حول خصائص تطبيق الويب.

يجب أن يعرض تطبيق الويب التقدمي بعض الخصائص المشابهة للتطبيق ...

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

… لكن يجب أن تحتفظ بخصائص معينة شبيهة بالويب

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

أخذ موقع الويب الخاص بك دون اتصال

يؤدي نقل موقع الويب الخاص بك إلى وضع عدم الاتصال إلى بعض المزايا الرئيسية.

أولاً ، ستظل تعمل عندما يكون المستخدم على اتصال شبكة غير مستقر.

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

هناك طريقتان لجعل موقع الويب يعمل دون اتصال:

• الطريقة القديمة وضبطت
  كان دعم بدء تشغيل موقع الويب الخاص بك دون اتصال بالإنترنت موجودًا منذ سنوات في شكل AppCache. بالرغم من ذلك ، فإن AppCache به بعض العيوب الخطيرة ، وقد تم إهماله حتى من المواصفات. من الصعب العمل معه ، وإذا تم تكوينه بشكل خاطئ ، فقد يؤدي ذلك إلى تعطيل موقع الويب الخاص بك بشكل دائم. ومع ذلك ، فهي الطريقة الوحيدة للعمل دون اتصال بالإنترنت على نظام iOS ، على الأقل حتى تتخذ Apple خطوة لدعم العاملين في مجال الخدمة.
• درجة حرارة جديدة
  كما يتسم العاملون في الخدمة بالفعالية أيضًا ، والذين يتم دعمهم حاليًا في Chrome و Firefox و Opera وقريبًا جدًا في Edge. قام فريق WebKit التابع لشركة Apple بوضع علامة "قيد الدراسة".

يتشابه عمال الخدمة مع غيرهم من العاملين على الويب من حيث أنهم يعملون في سلسلة منفصلة ، لكنهم غير مرتبطين بأي علامة تبويب محددة. يتم تعيين نطاق عنوان URL لها عند إنشائها ، ويمكنهم اعتراض وإعادة كتابة أي طلبات في هذا النطاق. إذا كان عامل الخدمة الخاص بك يجلس على https://example.com/my-site/sw.js ، فسيكون قادرًا على اعتراض أي طلبات يتم إجراؤها إلى /my-site/ أو أقل ولكن لا يمكن اعتراض الطلبات إلى الجذر https://example.com/ .

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

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

نظرًا لأنه يتم إهمال AppCache ، فلن أناقشها أكثر في هذه المقالة.

إنشاء عامل الخدمة

(راجع أيضًا "إعداد عامل الخدمة" للحصول على إرشادات أكثر تفصيلاً.)

نظرًا لأن عامل الخدمة هو نوع خاص من عامل الويب المشترك ، فإنه يعمل في سلسلة منفصلة لصفحتك الرئيسية. هذا يعني أنه يتم مشاركتها من قبل جميع صفحات الويب على نفس المسار مثل عامل الخدمة. على سبيل المثال ، يمكن لعامل خدمة موجود في /my-page/sw.js التأثير على /my-page/index.html و my-page/images/header.jpg ، ولكن ليس /index.html .

يمكن للعاملين في الخدمة اعتراض وإعادة كتابة أو انتحال جميع طلبات الشبكة المقدمة على الصفحة ، بما في ذلك الطلبات المقدمة إلى data:// URLs!

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

يُسمح به فقط في السياقات الآمنة (مثل HTTPS) لأنه قوي جدًا. هذا يمنع الجهات الخارجية من تجاوز موقع الويب الخاص بك بشكل دائم باستخدام عامل خدمة محقون من نقطة وصول Wi-Fi مصابة أو ضارة.

قد يبدو إعداد HTTPS في الوقت الحاضر أمرًا شاقًا ومكلفًا ، ولكنه في الواقع لم يكن أسهل أو أرخص من أي وقت مضى. يوفر Let's Encrypt شهادات ونصوص SSL مجانية لتهيئة خادمك تلقائيًا. في حالة الاستضافة على GitHub ، يتم تقديم صفحات GitHub تلقائيًا عبر HTTPS. يمكن تكوين صفحات Tumblr لتعمل على HTTPS أيضًا. يمكن لـ CloudFlare طلبات وكيل للترقية إلى HTTPS.

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

أستخدم Service Worker Toolbox لاستخراج منطق التخزين المؤقت المعقد بعيدًا. يمكن تعيين هذه المكتبة للتعامل مع التوجيه من خلال توفير أربعة مسارات تم تكوينها مسبقًا ، والتي يمكن تهيئتها بطريقة نظيفة. يمكن استيرادها إلى عامل الخدمة الخاص بك.

حالة الاستخدام 1: التجهيز المسبق

تسحب المعالجة المسبقة الطلبات قبل أن يعمل موقع الويب الخاص بك على أنها مطلوبة. يمكن أن يؤدي هذا إلى تقليل وقت الرسم الأول بشكل كبير لأن موقع الويب الخاص بك لا يحتاج إلى تحليل /site.css قبل أن يبدأ تنزيل شعار موقع الويب الخاص بك ، /images/logo.png .

 toolbox.precache(['/index.html', '/site.css', '/images/logo.png']);

حالة الاستخدام 2: غير متصل

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

 toolbox.router.default = toolbox.networkFirst; toolbox.options.networkTimeoutSeconds = 5;

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

 toolbox.router.all('/images/*', toolbox.fastest);

في هذه الحالة ، عندما يقوم المستخدم بالمصادقة ، من المهم ألا نرجع استجابة مخزنة مؤقتًا فقط ؛ يجب أن نذكر أن الطلبات المقدمة إلى /auth/ يجب أن تكون خاصة بالشبكة فقط.

 toolbox.router.post('/auth/*', toolbox.networkOnly);

فيما يلي بعض الممارسات الجيدة للاتصال بلا اتصال بالإنترنت:

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

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

تصحيح أخطاء عامل الخدمة الخاص بك

إذا كنت تستخدم Chrome أو Opera ، فانتقل إلى chrome://serviceworker-internals . سيسمح لك ذلك بفحص البرنامج النصي الخاص بعامل الخدمة وإيقافه مؤقتًا وإلغاء تثبيته.

في الإصدارات الحديثة من Chrome و Opera ، يمكنك الحصول على عروض تفصيلية وأدوات تصحيح الأخطاء من خلال علامة التبويب "Application" في أداة الفحص.

أداء التفاعل والرسوم المتحركة

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

• عندما يفعل المستخدم شيئًا ما ، يجب أن يقوم التطبيق أيضًا بعمل شيء ما في غضون 100 مللي ثانية ؛ خلاف ذلك ، سيلاحظ المستخدم وجود تأخر. يتم احتساب هذا بالنسبة للصنابير والنقرات والسحب والتمرير.
• يجب أن يتم عرض كل إطار بمعدل 60 إطارًا في الثانية (16 مللي ثانية لكل إطار). حتى بعض الإطارات البطيئة ستكون واضحة.
• يجب أن يكون سريعًا على هاتف اقتصادي يبلغ من العمر ثلاث سنوات ويعمل على شبكة ضعيفة ، وليس فقط على جهاز التطوير اللامع.
• يجب أن تبدأ بسرعة. لطالما ركزنا على الحفاظ على تفاعل المستخدم من خلال جعل مواقعنا مرئية وقابلة للاستخدام في أقل من ثانية واحدة إلى ثانيتين. عندما يتعلق الأمر بتطبيقات الويب ، فإن وقت البدء مهم كما كان دائمًا. إذا تم تخزين محتوى التطبيق بالكامل في ذاكرة التخزين المؤقت ولا يزال المتصفح في ذاكرة الجهاز ، فيمكن أن يبدأ تطبيق الويب بشكل أسرع من التطبيق الأصلي. أحد الأخطاء التي ارتكبها مطورو التطبيقات والمواقع الأصلية على حد سواء هو طلب محتوى متصل بالشبكة حتى يعمل المنتج.
• يجب أن يكون تطبيق الويب صغيرًا للتنزيل والتحديث: 10 ميغابايت من متجر التطبيقات لا تبدو كثيرة ، ولكن 10 ميغابايت غير مخزنة يتم تنزيلها في كل مرة من المستحيل للغاية إدارتها لكثير من مستخدمي الأجهزة المحمولة.

بعيدًا عن الخفاش ، فإن العنصر الأكثر أهمية هو هذا ، في head المستند:

 <meta name="viewport" content="width=device-width">

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

منذ ظهور نظام التشغيل iOS 8 ، تكون النقرات سريعة افتراضيًا ولكنها قد تبدو بطيئة إذا كان النقر سريعًا ، وفقًا لبعض الاستدلالات. إذا كانت هذه مشكلة بالنسبة لك ، فإنني أوصي باستخدام FastClick لإزالة التأخير.

هناك أيضًا مسألة أداء الرسوم المتحركة. من المحتمل أن ترغب في تحريك الكثير من العناصر الجميلة للداخل والخارج ، والعناصر التي يمكن للمستخدم سحبها ، والتفاعلات الرائعة الأخرى.

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

ابحث أو اسأل أصدقائك أو عائلتك عن هاتف ذكي قديم. عادةً ما أقوم باستعارة جهاز Nexus 4 الخاص بشريكي.

قم بتوصيل الهاتف بجهاز الكمبيوتر الخاص بك ، وانتقل إلى chrome://inspect/#devices . سيؤدي هذا إلى فتح نافذة فحص ، والتي يمكنك استخدامها لفحص صفحات الويب التي تعمل على الهاتف. يمكنك استخدام التنميط وعرض الجدول الزمني للعثور على مصادر الأداء الضعيف ثم تحسينها بناءً على جهاز أساسي حقيقي.

يعد تحريك بعض خصائص CSS أحد أكبر أسباب الرسوم المتحركة المتوترة ، والمعروفة باسم jank. تعد CSS Triggers موردًا رائعًا لتحديد الخصائص التي يمكن تحريكها بأمان دون التسبب في إعادة رسم المتصفح أو إعادة تخطيط الصفحة بأكملها.

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

دفع الإخطارات

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

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

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

أفضل تجربة لإشعارات الدفع تحرر المستخدم من الاضطرار إلى فتح تطبيق الويب الخاص بك على الإطلاق ! "لديك رسالة جديدة" غير مجدية ومزعج مثل عنوان clickbait. اعرض الرسالة والمرسل.

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

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

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

تتطلب واجهة برمجة تطبيقات Push Notification عامل خدمة. نظرًا لإمكانية تلقي إشعارات الدفع عند عدم فتح علامة تبويب في المتصفح ، سيتعامل عامل الخدمة مع طلب الإشعار في سلسلة رسائل في الخلفية. يمكنه إجراء عمليات غير متزامنة ، مثل تقديم طلب جلب إلى واجهة برمجة التطبيقات (API) الخاصة بك قبل عرض الإشعار للمستخدم.

لإنشاء إشعار دفع ، قم بتقديم طلب إلى نقطة نهاية مقدمة من الشركة المصنعة للمتصفح. بالنسبة للمتصفحات المستندة إلى Chromium (Opera و Samsung و Chrome) ، سيكون هذا هو Firebase Cloud Messaging. تتصرف هذه المتصفحات أيضًا قليلاً خارج المواصفات.

يمكن للمرء العثور على تفاصيل هذا عن طريق طلب إذن إعلام الدفع:

 serviceWorkerRegistration .pushManager .subscribe({ // Required parameter as receiving updates // but not displaying a message is not supported everywhere. userVisibleOnly: true }) .then(function(subscription) { return sendSubscriptionToServer(subscription); })

الاشتراك هو كائن يشبه هذا:

 { "endpoint": "https://example.com/some/uuid" }

في المثال أعلاه ، يعرّف uuid بشكل فريد المتصفح المستخدم حاليًا.

ملاحظة: تتصرف المتصفحات القائمة على Chromium بشكل مختلف قليلاً. ستحتاج إلى معرف تطبيق Firebase ، والذي يجب إدخاله في ملف بيان تطبيق الويب (على سبيل المثال ، "gcm_sender_id": "90157766285" ).

أيضًا ، لن تعمل نقطة النهاية بالتنسيق المعطى لها. يحتاج الخادم الخاص بك إلى تشويشها قليلاً حتى تعمل. يجب أن يكون طلب POST ، مع وجود مفتاح API في head و uuid في body .

عند إرسال إشعار دفع ، من الممكن إرسال البيانات في نص إشعار الدفع نفسه. هذا معقد وينطوي على تشفير المحتويات في طلب API. يمكن لحزمة دفع الويب الخاصة بـ Node.js التعامل مع هذا الأمر ، لكنني لا أفضله.

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

ملاحظة: يمكن للمتصفح إغلاق عامل الخدمة في أي وقت. تخبر الدالة event.waitUntil في حدث الدفع عامل الخدمة بعدم الإغلاق حتى انتهاء الحدث.

 self.addEventListener('push', function(event) { event.waitUntil( // Makes API request, returns Promise getMessageDetails() .then(function (details) { self.registration.showNotification( details.title, { body: details.message, icon: '/my-app-logo-192x192.png' }) }) ); });

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

لا تتجاهل قدرات الويب

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

غالبًا ما تخفي تطبيقات الويب المثبتة غلاف المتصفح. لا يوجد شريط عنوان للمستخدم لمشاركة عنوان URL الحالي ، ولا يمكن للمستخدم حفظ الصفحة الحالية في وقت لاحق.

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

يتعلق الأمر بهذا: توفير طرق لمشاركة تطبيقك عبر إما أزرار المشاركة أو زر لفضح عنوان URL.

ماذا عن المتصفحات التي لا تدعم تطبيقات الويب التقدمية؟

تحقق من هل ServiceWorker جاهز؟ للوضع الحالي لدعم العاملين في الخدمة عبر المتصفحات.

ربما لاحظت طوال كل هذا أنني ذكرت Chrome و Firefox و Edge لكنني تركت Safari. قدمت Apple تطبيقات الويب للعالم وأبدت اهتمامًا بتطبيقات الويب التقدمية ، لكنها لا تزال لا تدعم العاملين في الخدمة أو بيان تطبيق الويب. ما الذي تستطيع القيام به؟

من الممكن إنشاء موقع ويب غير متصل بالإنترنت لـ Safari باستخدام AppCache ، لكن القيام بذلك صعب ومحفوف بحالات الحافة الغريبة التي يمكن أن تؤدي إلى كسر الصفحة أو إبقائها قديمة بشكل دائم بعد التحميل الأول.

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

أخيرًا ، يمكننا أن نتطلع إلى الكثير من التطورات المثيرة في عالم تطبيقات الويب ، مع زيادة الدعم للتقنيات التي تقف وراءها والميزات الجديدة القادمة إلى منصة الويب ، مثل Web Bluetooth API للتفاعل مع الأجهزة ، WebVR للافتراضية الواقع ، و WebGL 2 للألعاب عالية السرعة. الآن هو وقت رائع لاستكشاف إمكانيات تطبيقات الويب وللمشاركة في تشكيل مستقبل الويب.

الروابط

كتابة أخرى في تطبيقات الويب التقدمية

• "مدونة أخرى حول حالة ومستقبل تطبيقات الويب التقدمية" ، أدا روز إدواردز

الروابط المشار إليها في المادة

• "شكل متجر التطبيقات" تشارلز بيري
• مساعدو عامل الخدمة ، Google ، GitHub
• مربع أدوات عامل الخدمة ، Google ، GitHub
• "تأخير النقر 300 مللي ثانية ونظام التشغيل iOS 8" TJ VanToll
• "أفضل الممارسات في التخزين المؤقت وأقصى عمر مسكتك" ، جيك أرشيبالد