🚨 👽 🗄️ Perancangan Ulang Aplikasi - Tampilan Dalam 👶🏼 🐔 🤽🏿

Sepeda Mobius adalah layanan persewaan sepeda dan skuter yang dikembangkan untuk Tallinn (ekspansi geografis saat ini direncanakan).

Hipotesis rilis pertama adalah "aplikasi penyewaan sepeda akan diminati di pasar Eropa". Pada bulan Desember 2019, hipotesis utama direvisi dan sekarang terdengar seperti ini: "dapatkah layanan penyewaan sepeda dan skuter dimaksimalkan karena kenyamanan bagi pengguna akhir dan pemegang waralaba?" Untuk menjawab pertanyaan ini, perlu diterapkan hal-hal berikut:

melakukan pekerjaan untuk mengoptimalkan struktur aplikasi (baik internal - backend, dan eksternal - desain dan frontend) untuk memperkenalkan jenis transportasi baru dan kemungkinan penskalaan di masa depan
buat ketentuan sewa disesuaikan di panel admin

Lyubov Nikiforuk - manajer proyek

Layar utama aplikasi sepeda Mobius sebelum mendesain ulang.

Salah satu tugas pertama saya sebagai perancang produk adalah menyiapkan tata letak untuk memperkenalkan jenis transportasi baru - skuter listrik. Setelah selesai dengan tata letak, saya memutuskan untuk membuat beberapa perubahan pada desain dan aplikasi UX dan membuat konsep desain ulang kecil. Menunjukkan tata letak baru ke tim. Saya mendapat umpan balik: orang-orang memberi saran dan membagikan pendapat mereka. Akibatnya, sejumlah layar utama diketik.

Refactoring kode dua bulan yang direncanakan semakin dekat dan kami memutuskan untuk menunjukkan desain baru kepada pelanggan untuk mengoptimalkan kode untuk antarmuka baru, kecuali, tentu saja, pelanggan setuju untuk mendesain ulang. Kami menyajikan tata letak, menjelaskan bagaimana desain baru dapat menyederhanakan interaksi dengan aplikasi dan apa manfaatnya bagi bisnis. Dan sudah dalam proses presentasi, kami menyadari bahwa desain "berjalan". Desain ulang disetujui, dan sekarang kami mulai refactoring dengan antarmuka baru dan UX didesain ulang.

Varian layar utama yang dibuat selama proses desain ulang

Organisasi kerja

Karena kami tidak memiliki tugas teknis yang jelas dan layanan kami dikembangkan bersama dengan bisnis, kami harus memutuskan bagaimana kami akan melaksanakan pekerjaan: tugas apa yang harus diambil, cara melacak kemajuan dan mengevaluasi hasilnya. Yang terpenting, metode gesit cocok dengan tugas kami. Durasi setiap sprint yang kami tentukan dalam dua minggu. Setiap hari kami mengadakan stand-up - membahas masalah saat ini, berbagi ide, memecahkan masalah. Di akhir setiap sprint, sebuah demo dilakukan - mereka menunjukkan kepada klien hasil pekerjaan yang dilakukan untuk sprint.

Tangkas dalam semua skuter Uji kemuliaan

di kantor kami

Navigasi

Hal pertama yang kami putuskan untuk diubah adalah navigasi melalui aplikasi. Alih-alih "burger," kami membuat menu tab yang lebih rendah (navigasi bawah). Anda mungkin memperhatikan bahwa banyak aplikasi beralih ke jenis navigasi ini. Dan ini dapat dimengerti, karena menu tab menyederhanakan akses ke bagian utama aplikasi, bahkan jika seseorang memegang telepon dengan satu tangan. Tapi ini bukan satu-satunya alasan untuk menggunakan jenis navigasi ini. Aplikasi ini dikembangkan di React Native, jadi kami harus mempertimbangkan fitur-fitur platform ini:

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

— front-end

— «». — (bottom navigation)

, , UI-kit

Selain mengubah navigasi, kami meninggalkan kontrol skala pada layar aplikasi. Meninggalkan zoom dengan gerakan. Jendela modal yang diganti, dialog dan bagian layar dengan layar geser. Sekali lagi, karena lebih nyaman menggunakan aplikasi dengan satu tangan - layar seperti itu hanya dapat "digesek" ke bawah dan ditutup.

Contoh layar gesek dalam aplikasi sepeda Mobius setelah pendesainan ulang.

Kami juga menyederhanakan proses pendaftaran dalam aplikasi dengan masuk melalui Google dan Facebook. Selain menautkan kartu bank, mereka menambahkan kemampuan membayar menggunakan Apple Pay dan Google Pay.

Layar untuk memasuki aplikasi dan pembayaran menggunakan Apple Pay

Agar lebih mudah untuk menambahkan fitur baru ke aplikasi di masa depan, kami membuat perpustakaan komponen dan menjelaskan aplikasi dan prinsip interaksi mereka.

Aplikasi kit UI sepeda Mobius

Refactoring dan beralih ke GraphQL

Tujuan utama dari desain ulang adalah:

membuat sistem komponen yang lebih fleksibel dan dapat diskalakan yang dengan mudah memungkinkan penambahan fungsionalitas baru, misalnya, jenis transportasi lain, tanpa mengurangi tampilan dan logika umum interaksi dengan aplikasi
meringankan dan menyederhanakan antarmuka sebanyak mungkin
"Refresh" tampilan aplikasi

Tetapi selain memperbarui antarmuka aplikasi, sisi redesign yang terlihat, transisi dari RESTful API ke GraphQL adalah bagian yang sangat penting.

Sederhananya, GraphQL adalah sintaks yang menjelaskan bagaimana klien (telepon / aplikasi) menerima data dari server menggunakan permintaan khusus. Tergantung pada permintaan, server memberikan ini atau itu data.

Artyom Bukhtoyarov - Pengembang DevOps / Backend

GraphQL memiliki tiga karakteristik utama:

memungkinkan klien untuk menentukan dengan tepat data apa yang dia butuhkan
memfasilitasi agregasi data dari berbagai sumber
menggunakan sistem tipe untuk menggambarkan data

GraphQL bertindak sebagai lapisan adaptor antara antarmuka aplikasi dan layanan eksternal. Ini memungkinkan Anda untuk mentransfer pemrosesan berbagai permintaan ke belakang. Artinya, ketika Anda menghubungkan protokol transport baru, Anda harus menghubungkannya di belakang, dan tata letak akan menerima semua data dalam bentuk terpadu dari GraphQL. Dengan demikian, kami mengurangi kebutuhan untuk pekerjaan pengaturan huruf tambahan ketika menambahkan jenis transportasi baru dan mengurangi jumlah permintaan yang diproses dalam aplikasi.

Selain itu, dalam proses refactoring, kami menyoroti keuntungan menggunakan GraphQL berikut:

dokumentasi yang nyaman untuk pengembang
solusi yang bagus untuk WebSocket, baik untuk backend dan frontend
GraphQL memudahkan pengembang untuk menavigasi struktur kode
pengembangan yang lebih fleksibel, dibandingkan dengan RESTful API, memungkinkan Anda untuk menambahkan sesuatu yang baru dengan lebih cepat dan lebih mudah (dalam kasus kami, ini adalah jenis transportasi baru)

Itu lucu ketika kunci sepeda pertama dari Cina menentukan lokasi geografisnya di Cina, meskipun secara fisik di St. Petersburg. Dan perangkat lunak untuk kunci ini dienkripsi dan kami harus mencari metode dekripsi untuk membuat perubahan pada pengaturan.

Awalnya, ketika kami hanya memiliki satu jenis transportasi, server untuk menghubungkan sepeda bekerja bersama dengan backend utama. Kemudian, kami mengeluarkan server untuk kunci sepeda sebagai layanan independen yang dapat digunakan pada server terpisah - ini memungkinkan kami untuk mengurangi beban pada server utama dan memberikan peluang tambahan untuk penskalaan. Untuk mentransfer pesan antar layanan, kami menggunakan RabbitMQ. Dan sangat nyaman bahwa ia memiliki plugin untuk mqtt - protokol yang digunakan skuter kami, yang membuatnya mudah untuk menambahkan moda transportasi baru.

Pembayaran dalam aplikasi. Awalnya, kami berencana untuk menambahkan kartu bank dalam aplikasi itu sendiri, tetapi pada akhirnya kami menetapkan opsi pengalihan ke halaman bank dan seluruh proses penambahan kartu sudah terjadi di sana. Metode ini ternyata jauh lebih mudah diimplementasikan.

Waralaba dan Administrasi

Pemilik layanan memiliki persyaratan tertentu untuk panel admin aplikasi. Karena direncanakan bahwa layanan ini akan dijual sebagai waralaba, setiap franchisee harus dapat mengedit biaya perjalanan, parameter tarif, langganan, dll.

Oleh karena itu, kami mendesain ulang panel admin untuk kemampuan menghubungkan pemilik taman baru. Menambahkan peran yang berbeda - pemilik taman dan pemilik jaringan. Kami membuat seluruh bagian untuk menambah dan mengedit tarif, langganan, dan denda berbasis waktu. Di setiap kota, pemilik taman akan dapat menetapkan tarif mereka sendiri dan mengubahnya. Mereka juga memungkinkan untuk memoderasi perubahan oleh administrator jaringan. Kami memperluas struktur panel admin untuk menambahkan jenis transportasi baru.

Masalah

Tentu saja ada beberapa kesulitan. Kami menolak memvisualisasikan rute dalam sejarah perjalanan. Modul GPS di kunci sepeda tidak selalu mentransmisikan koordinat dengan benar. Dan alih-alih garis rute yang indah, seperti pada bidikan Dribble, kami mendapatkan ini:

Menunggu realitas VS

Ada masalah dalam implementasi teknis peta Google di bawah React Native. Penanda pada peta perlu digambar ulang secara konstan untuk mengubah posisinya di peta. Gambar ulang vektor dalam jumlah besar tidak dioptimalkan dan oleh karena itu, dengan pengaturan tertentu, semuanya sangat lambat. Dan kami memutuskan untuk mengganti penanda vektor pada peta dengan yang raster dalam format png. Ini memberi peningkatan signifikan dalam kecepatan aplikasi.

Banyak pertanyaan seputar penerapan sistem tarif dan berlangganan. Kami mencoba memberikan kasus yang berbeda: apa yang harus dilakukan jika langganan berakhir selama perjalanan, apakah akan memberi kesempatan untuk membeli langganan yang berbeda untuk satu jenis transportasi, apakah perlu melakukan pembaruan otomatis langganan, cara menghitung biaya perjalanan, dan sebagainya.

Akibatnya, kami menetapkan opsi peringkat berikut: waktu perjalanan dibagi menjadi segmen yang tidak sama dan setiap interval waktu dibebankan secara terpisah. Misalnya, 15 menit pertama dari perjalanan menelan biaya € 2, jika Anda naik lebih dari 15 menit, tetapi kurang dari setengah jam, maka biaya perjalanan adalah € 3,5, dari 30 menit hingga satu jam - € 5, dll. Dan untuk membuatnya lebih mudah bagi pengguna untuk menavigasi tarif, kami memutuskan untuk memvisualisasikan perhitungan biaya dan membuatnya menjadi bilah kemajuan. Sekarang pengguna dapat melihat bagaimana biaya perjalanan berubah secara waktu nyata.

Visualisasi penetapan biaya dalam bentuk Layar batang kemajuan

dengan tarif dan langganan

Beberapa pengguna menemukan opsi untuk tidak membayar perjalanan: mereka menambahkan kartu bank, kemudian menghapusnya dan mengendarainya secara gratis. Ketika kami menemukan ini, kami mulai memblokir € 1 untuk memeriksa solvabilitas kami dan menghapus kemampuan untuk mengeluarkan kartu selama perjalanan atau jika ada hutang yang belum dibayar.

Terkadang juga ada masalah dalam menyelesaikan perjalanan. Untuk menyelesaikan naik sepeda Anda harus menutup kunci, yang mentransfer informasi ke server. Tetapi kastil tidak selalu mengirimkan data tepat waktu. Dan pada akhirnya, orang bisa mengakumulasi hutang beberapa ratus euro untuk perjalanan yang seharusnya belum selesai. Kami memutuskan bahwa kami akan memeriksa jumlah besar secara manual dan menghapus rekaman otomatis untuk mereka. Hampir tidak ada keluhan, karena di Eropa beberapa orang memiliki peringatan SMS. Di Rusia akan berbeda.

temuan

Paling depan

Salah satu fitur utama pengembangan pada React Native adalah pelacakan kinerja komponen. Untuk mencegah penurunan fps, ada baiknya:

pantau jumlah penyaji (redraws). Sebuah komponen harus digambar ulang hanya jika data baru yang masuk benar-benar perlu mengubah keadaan antarmuka
menggunakan animasi asli asli dari paket React Native standar menggunakan kunci useNativeDrive dalam konfigurasi animasi atau paket Reanimated
tinjau kode JS paket atau komponen yang ditambahkan ke proyek. Tidak semua paket yang tersedia dapat dioptimalkan, atau dengan benar menggunakan fitur React Native. Juga dalam pengembangan pada React Native, ada baiknya mempertimbangkan perbedaan platform. Satu dan kode yang sama di iOS dan Android dapat bekerja dengan cara yang sangat berbeda

Kekuatan React Native dapat disebut fleksibilitasnya. Tidak perlu memiliki 2 tim pengembangan berbeda di iOS dan Android. Juga, seringkali, Anda dapat menerapkan konsep desain yang lebih sulit untuk dikembangkan di platform asli.

Kelemahan dari React Native bukanlah sifatnya yang penuh. Anda harus selalu memastikan bahwa Anda tidak membebani JS-thread. Rasa sakit memperbarui dan menginstal paket asli hingga versi 0,60 sampai autolinker diperkenalkan.

Backend

Beralih ke GraphQL dalam banyak kasus menyederhanakan pengembangan API. Ini menjadi lebih jelas bagi pengembang dan klien.

Keuntungan GraphQL:

dimungkinkan untuk secara otomatis mendokumentasikan API dan sangat nyaman
memungkinkan pekerjaan yang lebih fleksibel dengan API. Klien hanya memilih data yang ia butuhkan saat ini
dukungan di luar kotak untuk soket web, yang sangat penting karena kami sering memperbarui data waktu nyata
kita dapat dengan mudah menulis jenis skalar jika perlu dan menggunakannya kembali nanti

Kelemahan GraphQL:

lebih sulit untuk melakukan fitur berdasarkan tipe halaman. Saya harus menerapkan teknologi tambahan
Di luar kotak tidak ada ruang nama. Anda harus mengurus sendiri pemisahan API. Pada saat yang sama, ada dukungan untuk bidang yang sudah tidak digunakan lagi, yang selanjutnya menyederhanakan kehidupan pengembang
Anda perlu memantau level bersarang untuk kueri. Anda dapat menulis permintaan dengan banyak sarang dan kemudian menunggu jawaban yang lama

Antarmuka

Saat mengerjakan desain ulang, Anda harus ingat bahwa Anda tidak harus melakukan desain demi desain. Dalam kasus kami, antarmuka baru memungkinkan untuk menyederhanakan interaksi pengguna dengan aplikasi, termasuk jika seseorang memegang telepon dengan satu tangan. Kami memperhitungkan fitur React Native dan, untuk mengurangi bersarang, kami beralih dari "burger" ke navigasi bawah. Juga perlu untuk meletakkan kemungkinan penskalaan struktur aplikasi. Membuat perpustakaan komponen dan menerapkan desain atom dapat membantu di sini.

Kami berencana untuk memperkenalkan gamification (dapatkan bonus bagus untuk jarak tempuh), tema gelap, terhubung ke kontak telepon dan memberi tahu teman-teman yang bepergian di dekatnya dan memperkenalkan moda transportasi baru. Tetapi yang paling penting, desain ulang harus dibenarkan: untuk menguntungkan bisnis dan menyederhanakan pekerjaan dengan aplikasi untuk pengguna.

Perancangan Ulang Aplikasi - Tampilan Dalam