⛷️ 🤜 🤶🏼 إعادة تصميم التطبيق - نظرة من الداخل 🙆🏻 🤜🏽 👳🏿

Mobius bike عبارة عن خدمة تأجير دراجات وسكوترات تم تطويرها لتالين (المخطط الجغرافي للتوسع حاليًا).

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

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

ليوبوف نيكيفوروك - مدير المشروع

الشاشات الرئيسية لتطبيق Mobius للدراجات قبل إعادة التصميم كانت

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

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

متغيرات الشاشات الرئيسية التي تم إنشاؤها أثناء عملية إعادة التصميم

تنظيم العمل

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

رشيقة في كل سكوتر اختبار المجد

في مكتبنا

التنقل

أول شيء قررنا تغييره هو التنقل عبر التطبيق. بدلاً من "البرغر" ، قمنا بعمل قائمة تبويب أقل (التنقل السفلي). ربما لاحظت أن العديد من التطبيقات تتحول إلى هذا النوع من التنقل. وهذا أمر مفهوم ، لأن قائمة علامة التبويب تبسط الوصول إلى الأقسام الرئيسية للتطبيق ، حتى إذا كان الشخص يمسك بالهاتف بيد واحدة. ولكن هذا ليس السبب الوحيد لاستخدام هذا النوع من التنقل. تم تطوير التطبيق على React Native ، لذلك كان علينا أن نفكر في ميزات هذا النظام الأساسي:

(). , , , , , , . . . ,

— front-end

— «». — (bottom navigation)

, , UI-kit

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

أمثلة لشاشات التمرير لأعلى في تطبيق دراجة Mobius بعد إعادة التصميم ،

قمنا أيضًا بتبسيط عملية التسجيل في التطبيق من خلال تسجيل الدخول عبر Google و Facebook. بالإضافة إلى ربط البطاقات المصرفية ، أضافوا القدرة على الدفع باستخدام Apple Pay و Google Pay.

شاشة إدخال التطبيق والدفع باستخدام Apple Pay

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

تطبيقات موبيوس الدراجة UI- كيت

إعادة الهيكلة والتبديل إلى GraphQL

كانت الأهداف الرئيسية لإعادة التصميم:

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

ولكن إلى جانب تحديث واجهة التطبيق ، الجانب المرئي من إعادة التصميم ، كان الانتقال من RESTful API إلى GraphQL جزءًا مهمًا جدًا.

ببساطة ، GraphQL عبارة عن بناء جملة يصف كيف يتلقى العميل (الهاتف / التطبيق) البيانات من خادم باستخدام استعلامات خاصة. بناءً على الطلب ، يعطي الخادم هذه البيانات أو تلك.

Artyom Bukhtoyarov - مطور DevOps / Backend

يتميز GraphQL بثلاث خصائص رئيسية:

يسمح للعميل بتحديد البيانات التي يحتاجها بالضبط
يسهل تجميع البيانات من مصادر متعددة
يستخدم نظام نوع لوصف البيانات

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

بالإضافة إلى ذلك ، في عملية إعادة البناء ، سلطنا الضوء على المزايا التالية لاستخدام GraphQL:

وثائق ملائمة للمطور
حل جيد لـ WebSocket ، سواء للواجهة الخلفية أو الأمامية
يسهل GraphQL على المطورين التنقل في بنية التعليمات البرمجية
يسمح لك التطوير الأكثر مرونة ، مقارنة ب RESTful API ، بإضافة شيء جديد بشكل أسرع وأسهل (في حالتنا ، هذا نوع جديد من النقل)

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

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

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

الامتياز والإدارة

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

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

مشاكل

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

انتظار الواقع الافتراضي VS

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

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

نتيجة لذلك ، استقرنا على خيار التصنيف التالي: يتم تقسيم وقت السفر إلى أجزاء غير متساوية ويتم حساب كل فترة زمنية بشكل منفصل. على سبيل المثال ، أول 15 دقيقة من الرحلة تكلف 2 يورو ، إذا ركبت لأكثر من 15 دقيقة ، ولكن أقل من نصف ساعة ، فإن تكلفة الرحلة هي 3.5 يورو ، من 30 دقيقة إلى ساعة - 5 يورو ، إلخ. ولتسهيل على المستخدم التنقل في التعريفات ، قررنا تصور حساب التكلفة وجعلناها في شريط تقدم. الآن يمكن للمستخدم أن يرى كيف تتغير تكلفة الرحلة في الوقت الحقيقي.

تصور التكلفة في شكل شاشات شريط التقدم

مع التعريفات والاشتراكات

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

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

الموجودات

نهاية المقدمة

واحدة من السمات الرئيسية للتطوير على React Native هو تتبع أداء المكون. لمنع انخفاض في الثانية ، يجدر:

مراقبة عدد العارضين (إعادة رسم). يجب إعادة رسم المكون فقط إذا كانت البيانات الجديدة الواردة إليه تحتاج بالفعل إلى تغيير حالة الواجهة
استخدم الرسوم المتحركة الأصلية من حزمة React Native القياسية باستخدام مفتاح useNativeDrive في تكوين الرسوم المتحركة أو حزمة Reanimated
مراجعة كود JS للحزم أو المكونات المضافة إلى المشروع. قد لا يتم تحسين جميع الحزم المتاحة ، أو باستخدام ميزات React Native بشكل صحيح. أيضًا في التطوير على React Native ، يجدر النظر في اختلافات المنصات. يمكن أن يعمل رمز واحد ونفس الرمز على iOS و Android بطرق مختلفة تمامًا

يمكن تسمية قوة React Native بتعدد استخداماتها. لا حاجة لامتلاك فريقين مختلفين للتطوير على iOS و Android. في كثير من الأحيان ، يمكنك تنفيذ مفاهيم التصميم التي يصعب تطويرها على الأنظمة الأساسية الأصلية.

ضعف React Native ليس ميلاده الكامل. يجب عليك التأكد دائمًا من عدم تحميل JS-thread بشكل زائد. وجع تحديث وتثبيت الحزم الأصلية حتى الإصدار 0.60 حتى تم إدخال الرابط التلقائي.

الخلفية

أدى التبديل إلى GraphQL في معظم الحالات إلى تبسيط تطوير واجهة برمجة التطبيقات. لقد أصبح أكثر وضوحا لكل من المطور والعميل.

مزايا GraphQL:

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

نقاط ضعف GraphQL:

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

واجهه المستخدم

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

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

إعادة تصميم التطبيق - نظرة من الداخل