هذا مثير للاهتمام عندما تفكر في عدد تطبيقات تغليف ووردبريس المتوفرة.
@Aa7 أجد صعوبة في التفكير في المزايا، لكنني منفتح بالتأكيد للاستماع إلى أفكاركم. أعجبني ما ذكرته حول التركيز على المستخدم مقابل المسؤول، فهذا ذكي.
ربما يكون تقديم خدمة نشر مُعلَّمة بالعلامة التجارية الخاصة بوابة لذلك؟ السبب في قولي هذا هو أن الشخص الذي كان يقوم بذلك في وقت ما (اسمه يهرب مني) توقف.
أو ربما بناء التطبيق من خلال تحليل تجربة المستخدم (UX) لثيم الجوال. لقد لاحظت أن عددًا قليلًا من الأشخاص يقومون بتعطيل ثيم الجوال والاعتماد كليًا على النسخة المكتوبة في منتداي… لذا قد يكون هذا دليلًا.
كما أن جوجل اشتكت في بعض الأحيان من أن بعض مناطق اللمس صغيرة جدًا.
إذن، هل ستقوم أولاً بإعادة بناء الواجهة الأمامية بالكامل في تطبيق؟ أعتقد أنك تقلل بشكل كبير من تعقيد العمل وكمه الذي يجب إنجازه هناك.
ثم، في كل مرة يكون فيها تحديث غير متوافق لـ Discourse، ستحتاج إلى:
ملاحظة ذلك
فهم ما يحدث
تكييف الكود الخاص بك
تقديم التطبيق للمراجعة والخضوع لعملية موافقة غير مؤكدة وطويلة ربما
الانتظار حتى يكتشف مستخدمو المنتدى وجود تحديث، ويقومون بتحديث التطبيق على هواتفهم
إذن، كم من الوقت سيستغرق هذا؟ أظن أنه يتراوح بين يوم وثلاثة أسابيع؟ ربما خمسة أسابيع إذا كنت في إجازة؟
وفي هذه الأثناء، اعتمادًا على عملية العمل لديك، إما أن:
أ) لا يمكن تحديث المنتدى، مما قد يعرض قضايا أمنية
ب) لا يمكن استخدام المنتدى عبر التطبيق
لا أعتقد أن هذا سيعمل.
أعتقد أن هذه هي المشكلة الرئيسية التي يجب حلها: العثور على الوظيفة الحاسمة التي ستجعل آبل توافق على هذه التطبيقات المغلفة، ثم استخدام نهج التطبيقات المغلفة.
أعلم أنني قلت إن تحديث التطبيق سيأتي بعد ذلك، لكن تطوير الإصدارات الجديدة يحدث بشكل علني. يمكن لأي تكيف أن يحدث بالتزامن مع هذه التغييرات. علاوة على ذلك، فإن Discourse هو قاعدة كود ناضجة. لو كان شيئًا حديثًا مثل Talk (وهذا ليس مقارنة عادلة)، حيث تتغير الواجهة البرمجية كثيرًا، لاعتقدت أنني لن أفكر في ذلك.
أما فيما يتعلق بملاحظة التغييرات والبقاء على اطلاع، فأود القول إن هذا يتطلب وظيفة بدوام كامل.
لم أقدر العمل بشكل دقيق بعد. لقد عملت في تطوير البرمجيات لمدة 13 عامًا تقريبًا - وآمل ألا أرتكب خطأً فادحًا إذا اتخذت خطوات ملموسة في العمل على هذا الأمر.
أليست “المزايا” في الغالب للأشخاص الذين يديرون المواقع أو الخدمات وليس للمستخدمين؟ عندما يكون لديك تطبيق، يصبح مستخدموك أكثر “حصرًا”: يفتحون التطبيق ويكونون في بيئة مغلقة بدلاً من متصفح ويب يمكنهم من خلاله الذهاب إلى أي مكان في أي وقت. لديهم أيقونة تؤدي مباشرة إلى تطبيقك، بدلاً من إشارة مرجعية أخرى لموقعك (إذا كان لديهم واحدة، أو ربما سينسون عنوان URL الخاص بك في مرحلة ما). وعادة ما توجد إمكانية لإشعارات الدفع عند تثبيت تطبيق حتى لو لم يفتحه المستخدم منذ فترة.
الأمر دقيق، وهناك بالفعل حجج توضح لماذا لا يكون ذلك صحيحًا أو لماذا يمكن تحقيق نفس الشيء تقريبًا دون تطبيق. ولكن في البداية، أليس المزودون هم من دفعوا لتثبيت تطبيقاتهم (حتى لو لم تقدم شيئًا حقيقيًا للمستخدمين)، بدلاً من أن يطلب المستخدمون ذلك؟ (اتبع المستخدمون هذا المسار اعتادوا على هذه الطريقة في مرحلة ما، وربما الآن هم يطلبون التطبيقات، حتى لو لم يعرفوا السبب حقًا. ربما يجدونها مريحة الآن).
بصفتي كاتبًا لملحقات (plugins)، يمكنني إخبارك بأن الحفاظ على تحديث الكود ليتوافق مع النواة (core) ليس مهمة تافهة، بل يتطلب استراتيجية دقيقة. عادةً ما تُحافظ على الملحقات متزامنة مع فرع “اختبارات-ناجحة” (tests-passed). يمكنك اختيار فرع أبطأ، لكن هذا يعني أن عملائك سيتأخرون أيضًا. وهذا مقبول، لكنك ستحتاج إلى فترة زمنية مسبقة لتحديث تطبيقك بعد كل إصدار مستقر. سيكون هذا عملًا شاقًا وقد يؤدي إلى تأخيرات كبيرة في تحديثات العملاء.
مثل الملحقات، ستواجه دائمًا خطرًا مستمرًا بأن ينهار شيء ما بعد تغيير جوهري في النواة.
تذكر أن نواة Discourse مستقرة. ربما أكثر مما كانت عليه في البداية، لكن يرجى إلقاء نظرة دقيقة على المستودع (repo)، فهي تتحرك (وإن كان الكثير من ذلك قد يكون متعلقًا بتطبيق الويب). فقط انظر إلى عدد الالتزامات (commits) اليومية. انظر إلى عدد طلبات السحب المفتوحة (open PRs). خذ ملفًا واحدًا فقط، مثل Topic.hbs على سبيل المثال، وفكر في كيفية مواكبتك لهذا الملف وحده؟ حتى نسخ نواة Discourse الأساسية (forking) يُحذّر منها تمامًا لهذا التحدي. وهل هذا سيكون إعادة كتابة أصلية (native rewrite)؟
هل ستستخدم واجهة برمجة التطبيقات (API) الخاصة بهم فقط؟ حسنًا، لكن كيف ستطبق أيًا من الملحقات الشائعة؟ بعضها يحتوي على تغييرات بصرية كبيرة، ومعظمها يستخدم “تحوير القرد” (monkey-patching) باستخدام jQuery مثلًا أو منافذ الملحقات (plugin outlets) التي لن تتمكن من إعادة استخدامها إذا ذهبت نحو التطوير الأصلي. هل ستعيد تنفيذ هذه الميزات بكود أصلي؟
الملحقات هي مجرد قمة الجبل الجليدي. ما تقترحه هو على الأرجح النطاق الكامل لجميع وظائف واجهة المستخدم الأمامية. كل هذا سيحتاج إلى اختبار. وحالات اختبار. فقط “واو”.
كم حجم فريقك؟ مرة أخرى، انظر إلى عدد المطورين الذين يساهمون في النواة. أضف إلى ذلك عدد مؤلفي الملحقات ضمن النطاق. هذا يعطيك مقياسًا آخر لحجم التحدي.
ستحتاج إلى سرعة تتطابق مع إصدارات Discourse (!)، وإلا سيبدأ عملاؤك في الشعور بأنهم يُعاقبون عن ميزات جديدة.
ستحتاج إلى تبرير كل ساعة تقضيها واستردادها من خلال الإيرادات (وهذا مقبول، فأنت تحتاج إلى وضع الطعام على الطاولة مثلنا جميعًا).
لكن في أي حال، أعتقد أنه يمكنك تجربة تنفيذ هذا بهدف عرض نموذج أولي (demo). سأبدأ بـ “فقط” تطبيق النواة. هذا سيعطيك بسرعة إحساسًا بحجم المهمة. أو فقط احسب جميع مكالمات واجهة برمجة التطبيقات (API calls) التي ستحتاج إلى دعمها.
أنا متأكد من أنك فكرت في كل هذا. لا أقصد أن أفسد الحماس، لكن هذا عمل جاد تقترحه، وعلى أساس مستمر وقاسٍ بلا هوادة.
ماذا عن النظر في التطبيق الرسمي وما يمكنك فعله به؟
لقد فكرتُ أيضًا في كتابة تطبيق أصلي بالكامل (أنا مطور iOS بالمهنة). سأعتمد فيه على واجهة برمجة التطبيقات HTTP العامة لـ Discourse. هل توجد أي ضمانات بشأن استقرار واجهة برمجة التطبيقات هذه، أو ما إذا كانت مؤرشفة بإصدار معين، لمنع تعطل الإصدارات القديمة من التطبيق بشكل مفاجئ؟
يمكن للمجتمعات المستثمرة في التطبيق الأصلي أن تتابع الفرع البطيء (المعروف باسم “المستقر”). كما أننا لا نغير واجهات برمجة التطبيقات (APIs) بشكل متكرر، فهي مستقرة للغاية.
يمكن أن تستند التطبيقات إلى واجهة برمجة تطبيقات Discourse REST التي يُفترض أن تكون مستقرة إلى حد كبير. بعد ذلك، يمكن أن يكون لها أي واجهة مستخدم/تجربة مستخدم ترغب فيها، وربما تكون مختلفة حتى عن تطبيق الويب (قد يكون هذا أفضل أو قد يكون أسوأ). إذا اختار مؤلف التطبيق أي نهج آخر (لست متأكدًا مما إذا كان ذلك ممكنًا حتى الآن)، فسوف يواجه الألم الذي تصفه.
أجل. قد يُنظر إلى الاختلاف في المظهر مع الحفاظ على الاتساق بشكل إيجابي من قبل بعض الأشخاص، ولكن ربما فقط إذا كان تطبيقًا واحدًا يمكنك إضافة عدة نسخ منه، مثل التطبيق الرسمي. ومع ذلك، هذا ليس ما يهتم به الكثيرون. تخيّل أن للتطبيق المخصص لموقعك تنسيقًا مختلفًا تمامًا عن موقعك. هذا ليس جيدًا.
ولا أتخيل أن يكون أحد سعيدًا بتطبيق لا يدعم جميع ميزات موقعه. لذا، تبدأ الإضافات في أن تصبح مشكلة منذ البداية.
أتفق، قد يكون هذا هو الجزء المعقد. فقد تنتهي بتطبيق أصلي يبدو أسوأ من غلاف الويب إذا لم تكن الإضافات مدعومة. سيكون من المنطقي في المحاولة الأولى دعم أكثر الإضافات شيوعًا، ثم إضافة دعم لمزيد منها مع مرور الوقت.