هل تحتاج تطبيقاً، أم يكفيك موقع

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

الجواب الصادق لأي نشاط صغير هو أن يبدأ بموقع. وهذا هو المنطق وراءه، ثم الحالات التي لا ينطبق فيها.

عقبة التثبيت هي الكلفة الحقيقية

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

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

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

التكاليف التي تأتي بعد الإطلاق

التطبيق ليس شيئاً تبنيه مرة واحدة.

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

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

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

ما يستطيعه الويب اليوم

كثير مما يريد الناس تطبيقاً من أجله يفعله الموقع الحديث.

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

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

متى يكون التطبيق هو الجواب فعلاً

أربع حالات، ومن السهل نسبياً تمييزها.

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

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

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

إشعارات تستحق أن يُسمح بها. هذا أكثر سبب يذكره العملاء وهو يستحق تحفّظاً. الإشعارات لا تعمل إلا إذا سمح بها الناس، وهم يسمحون بها لأشياء يهتمون بها أصلاً. الإشعار مكافأة على كونك مفيداً، لا وسيلة لتصبح مفيداً.

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

كيف تقرّر

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

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