تطبيق PWA الخاص بشركة MishiPay يزيد من المعاملات 10 مرات ويتيح إضافة الفيديوهات إلى "قائمة المحتوى التالي" لمدة سنتين ونصف

تعرَّف على كيفية استفادة النشاط التجاري لشركة MishiPay من التبديل إلى تطبيق الويب التقدّمي (PWA).

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

تعتمد تقنيتنا على إمكانات الجهاز، مثل أجهزة استشعار نظام تحديد المواقع العالمي (GPS) والكاميرات التي تتيح للمستخدمين تحديد أماكن المتاجر التي تستخدم MishiPay، ومسح الرموز الشريطية للسلعة ضوئيًا داخل المتجر الفعلي، ومن ثم الدفع باستخدام طريقة الدفع الرقمية التي يختارونها. كانت الإصدارات الأولية من تقنية Scan & Go تطبيقات نظامي التشغيل iOS وAndroid خاصة بنظام التشغيل، أحب المستخدمون الأوائل هذه التكنولوجيا. تابع القراءة لمعرفة كيف أدى التبديل إلى تطبيق الويب التقدّمي (PWA) إلى زيادة المعاملات بمقدار 10 مرات وتوفير 2.5 عام من الإضافة إلى "قائمة المحتوى التالي".

    10×

    المعاملات المتزايدة

    سنتان ونصف

    تم حفظ قائمة المحتوى التالي

التحدّي

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

الحلّ

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

مقارنة جنبًا إلى جنب لبدء تشغيل تطبيق الويب التقدّمي (PWA) مباشرةً (من اليسار، بشكل أسرع) مقابل تثبيت تطبيق Android وتشغيله (من اليمين، الأبطأ)
المعاملات حسب المنصة AVOS: 16397 (3.98%) نظام التشغيل Android: 13769 (3.34%) الويب: 382184 (92.68%).
تتم معظم المعاملات على الويب.

التفاصيل الفنية

تحديد مكان المتاجر التي تتيح استخدام MishiPay

لتفعيل هذه الميزة، نعتمد على واجهة برمجة التطبيقات getCurrentPosition() إلى جانب حل احتياطي مستند إلى عنوان IP.

const geoOptions = {
  timeout: 10 * 1000,
  enableHighAccuracy: true,
  maximumAge: 0,
};

window.navigator.geolocation.getCurrentPosition(
  (position) => {
    const cords = position.coords;
    console.log(`Latitude :  ${cords.latitude}`);
    console.log(`Longitude :  ${cords.longitude}`);
  },
  (error) => {
    console.debug(`Error: ${error.code}:${error.message}`);
    /**
     * Invoke the IP based location services
     * to fetch the latitude and longitude of the user.
     */
  },
  geoOptions,
);

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

  • الموقع الجغرافي غير دقيق في الحلول الاحتياطية المستندة إلى عنوان IP.
  • تتطلّب البيانات المتزايدة للمتاجر التي تتيح استخدام MishiPay لكل منطقة، من المستخدمين تصفُّح القائمة وتحديد المتجر الصحيح.
  • يختار المستخدمون من حين لآخر متجرًا غير صحيح عن طريق الخطأ، ما يؤدي إلى تسجيل عمليات الشراء بشكل غير صحيح.

لمعالجة هذه المشاكل، تم تضمين رموز استجابة سريعة فريدة يتم رصدها جغرافيًا على شاشات العرض المتوفّرة في المتجر لكل متجر. وقد مهّد الطريق الطريق أمام تجربة إعداد أسرع. يفحص المستخدمون ببساطة رموز الاستجابة السريعة المستندة إلى الموقع الجغرافي والمطبوعة على مواد تسويقية موجودة في المتاجر للوصول إلى تطبيق الويب Scan & Go. وبهذه الطريقة، يمكنهم تجنُّب كتابة عنوان الويب mishipay.shop للوصول إلى الخدمة.

تجربة المسح الضوئي في المتجر باستخدام تطبيق الويب التقدّمي (PWA)

جارٍ فحص المنتجات

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

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

مخطّط بياني يعرض طبقات سلسلة المحادثات الرئيسية الثلاث، وهي: بث الفيديو وطبقة المعالجة وطبقة فك الترميز

فيديو مضمّن

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

/**
 * Video Stream Layer
 * https://developer.mozilla.org/docs/Web/API/MediaDevices/getUserMedia
 */
const canvasEle = document.getElementById('canvas');
const videoEle = document.getElementById('videoElement');
const canvasCtx = canvasEle.getContext('2d');
fetchVideoStream();
function fetchVideoStream() {
  let constraints = { video: { facingMode: 'environment' } };
  if (navigator.mediaDevices !== undefined) {
    navigator.mediaDevices
      .getUserMedia(constraints)
      .then((stream) => {
        videoEle.srcObject = stream;
        videoStream = stream;
        videoEle.play();
        // Initiate frame capture - Processing Layer.
      })
      .catch((error) => {
        console.debug(error);
        console.warn(`Failed to access the stream:${error.name}`);
      });
  } else {
    console.warn(`getUserMedia API not supported!!`);
  }
}

طبقة المعالجة

لاكتشاف رمز شريطي في بث فيديو معيّن، نحتاج إلى التقاط الإطارات بشكل دوري ونقلها إلى طبقة برنامج فك الترميز. لالتقاط إطار، نرسم مجموعات البث من VideoElement إلى HTMLCanvasElement باستخدام طريقة drawImage() في Canvas API.

/**
 * Processing Layer - Frame Capture
 * https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/Manipulating_video_using_canvas
 */
async function captureFrames() {
  if (videoEle.readyState === videoEle.HAVE_ENOUGH_DATA) {
    const canvasHeight = (canvasEle.height = videoEle.videoHeight);
    const canvasWidth = (canvasEle.width = videoEle.videoWidth);
    canvasCtx.drawImage(videoEle, 0, 0, canvasWidth, canvasHeight);
    // Transfer the `canvasEle` to the decoder for barcode detection.
    const result = await decodeBarcode(canvasEle);
  } else {
    console.log('Video feed not available yet');
  }
}

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

طبقة برنامج فك الترميز

الطبقة الأخيرة هي طبقة فك الترميز المسؤولة عن فك ترميز الرموز الشريطية من الإطارات التي تلتقطها طبقة المعالجة. وبفضل واجهة برمجة التطبيقات Shape Detection API (التي لا تتوفر بعد على كل المتصفحات)، يفكّ المتصفّح نفسه الرمز الشريطي عن ImageBitmapSource، الذي يمكن أن يكون عنصر img أو عنصر SVG image أو عنصر video أو عنصر canvas أو كائن Blob أو كائن ImageData أو عنصر ImageBitmap.

رسم بياني يوضّح طبقات سلسلة المحادثات الرئيسية الثلاث، وهي: بث الفيديو وطبقة المعالجة وواجهة برمجة التطبيقات Shape Detection API

/**
 * Barcode Decoder with Shape Detection API
 * https://web.dev/shape-detection/
 */
async function decodeBarcode(canvas) {
  const formats = [
    'aztec',
    'code_128',
    'code_39',
    'code_93',
    'codabar',
    'data_matrix',
    'ean_13',
    'ean_8',
    'itf',
    'pdf417',
    'qr_code',
    'upc_a',
    'upc_e',
  ];
  const barcodeDetector = new window.BarcodeDetector({
    formats,
  });
  try {
    const barcodes = await barcodeDetector.detect(canvas);
    console.log(barcodes);
    return barcodes.length > 0 ? barcodes[0]['rawValue'] : undefined;
  } catch (e) {
    throw e;
  }
}

بالنسبة للأجهزة التي لا تتوافق مع واجهة برمجة تطبيقات Shape Detection حتى الآن، نحتاج إلى حل احتياطي لفك ترميز الرموز الشريطية. تعرض واجهة برمجة التطبيقات Shape Detection API طريقة getSupportedFormats() تساعد في التبديل بين واجهة برمجة التطبيقات Shape Detection API والحلّ الاحتياطي.

// Feature detection.
if (!('BarceodeDetector' in window)) {
  return;
}
// Check supported barcode formats.
BarcodeDetector.getSupportedFormats()
.then((supportedFormats) => {
  supportedFormats.forEach((format) => console.log(format));
});

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

الحل الاحتياطي

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

اسم المكتبة النوع محلول Wasm تنسيقات الرموز الشريطية
QuaggaJs برنامج مفتوح المصدر لا يوم واحد
ZxingJs برنامج مفتوح المصدر لا ثنائية الأبعاد وثنائية الأبعاد (محدودة)
CodeCorp Enterprise نعم ثنائية الأبعاد وثنائية الأبعاد
Scandit Enterprise نعم ثنائية الأبعاد وثنائية الأبعاد
مقارنة بين مكتبات فحص الرموز الشريطية المفتوحة المصدر والتجارية

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

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

مستقبل الفحص

بعد أن تصبح واجهة برمجة التطبيقات Shape Detection API متوافقة بالكامل مع جميع المتصفّحات الرئيسية، من المحتمل أن يكون لدينا عنصر HTML جديد <scanner> يحتوي على الإمكانات المطلوبة للماسح الضوئي للرموز الشريطية. يرى فريق الهندسة في MishiPay أن هناك حالة استخدام قوية لوظيفة مسح الرمز الشريطي ضوئيًا لتكون عنصر HTML جديدًا بسبب تزايد عدد البرامج المفتوحة المصدر والمكتبات المرخَّصة التي توفّر تجارب، مثل Scan & Go وغيرها الكثير.

الخلاصة

يعد إرهاق التطبيق مشكلة يواجهها المطورون عند دخول منتجاتهم إلى السوق. غالبًا ما يرغب المستخدمون في فهم القيمة التي يمنحها التطبيق قبل تنزيله. ففي المتاجر التي توفّر فيها خدمة MiishiPay وقت المتسوّقين وتُحسِّن تجربتهم، من غير البديهي الانتظار حتى يتمكّنوا من استخدام أحد التطبيقات. هذا هو المكان الذي يساعد فيه تطبيق الويب التقدّمي لدينا. من خلال إزالة الحاجز الذي يمنع الدخول، زاد حجم معاملاتنا بمقدار 10 مرات، وتمكّنا من توفير 2.5 عام من الانتظار في قائمة الانتظار للمستخدمين.

شكر وتقدير

راجع هذه المقالة جو ميدلي.