Daripada UI-kit kepada sistem reka bentuk

Pengalaman pawagam dalam talian Ivy

Apabila pada awal tahun 2017 kami mula-mula berfikir tentang mencipta sistem penghantaran reka bentuk kepada kod kami sendiri, ramai yang sudah bercakap mengenainya dan ada juga yang melakukannya. Walau bagaimanapun, sehingga hari ini sedikit yang diketahui tentang pengalaman membina sistem reka bentuk merentas platform, dan tidak ada resipi yang jelas dan terbukti yang menerangkan teknologi dan kaedah untuk transformasi proses pelaksanaan reka bentuk kepada produk yang sudah berfungsi. Dan dengan "komponen dalam kod" mereka sering bermaksud perkara yang sangat berbeza.

Sementara itu, syarikat itu menggandakan kakitangannya tahun demi tahun - adalah perlu untuk menskalakan jabatan reka bentuk dan mengoptimumkan proses mencipta dan memindahkan susun atur untuk pembangunan. Kami melipatgandakan semua ini dengan "zoo" platform yang perlu disokong, dan kami mendapat kemiripan keadaan Babylonia, yang tidak mampu "melakukannya secara normal" dan menjana pendapatan. Pembangunan platform sering berjalan selari, dan fungsi yang sama boleh dikeluarkan pada platform yang berbeza dengan ketinggalan beberapa bulan.


Set susun atur berasingan untuk setiap platform

Secara tradisinya, kami bermula dengan masalah yang sistem reka bentuk akan membantu menyelesaikan dan merumuskan keperluan untuk reka bentuknya. Di samping mencipta bahasa visual yang bersatu, meningkatkan kelajuan reka letak dan pembangunan, dan meningkatkan kualiti produk secara keseluruhan, adalah penting untuk menyatukan reka bentuk sebanyak mungkin. Ini adalah perlu supaya pembangunan fungsi menjadi mungkin pada semua platform kami secara serentak: Web, iOS, Android, Smart TV, tvOS, Android TV, Windows 10, xBox One, PS4, Roku - tanpa bekerja pada setiap satu daripadanya secara berasingan . Dan kami melakukannya!

Reka bentuk → data

Apabila perjanjian asas antara jabatan produk dan pembangunan dicapai, kami duduk untuk memilih timbunan teknologi dan menyelesaikan butiran keseluruhan proses - daripada reka letak hingga keluaran. Untuk mengautomasikan sepenuhnya proses pemindahan reka bentuk kepada pembangunan, kami meneroka pilihan untuk menghuraikan parameter komponen terus daripada fail Lakaran dengan reka letak. Ternyata mencari kepingan kod yang kami perlukan dan mengekstrak parameter yang kami perlukan adalah satu usaha yang rumit dan berbahaya. Pertama, pereka bentuk perlu berhati-hati dalam menamakan semua lapisan kod sumber, kedua, ini hanya berfungsi untuk komponen paling mudah, dan ketiga, pergantungan pada teknologi orang lain dan struktur kod reka letak Sketch asal menjejaskan masa depan keseluruhan projek. Kami memutuskan untuk meninggalkan automasi dalam bidang ini. Beginilah cara orang pertama muncul dalam pasukan sistem reka bentuk, yang inputnya ialah reka letak reka bentuk, dan outputnya ialah data yang menerangkan semua parameter komponen dan disusun mengikut hierarki mengikut metodologi reka bentuk atom.

Satu-satunya perkara yang perlu dilakukan ialah di mana dan cara menyimpan data, cara memindahkannya ke pembangunan dan cara mentafsirnya dalam pembangunan pada semua platform yang kami sokong. Petang itu tidak lagi membosankan... Hasil mesyuarat tetap kumpulan kerja yang terdiri daripada pereka bentuk dan ketua pasukan dari setiap platform adalah persetujuan mengenai perkara berikut.

Kami menghuraikan visual secara manual kepada unsur atom: fon, warna, ketelusan, inden, pembulatan, ikon, gambar dan tempoh untuk animasi. Dan kami mengumpul daripada butang ini, input, kotak semak, widget kad bank, dll. Kami menetapkan nama bukan semantik kepada gaya mana-mana peringkat, kecuali ikon, contohnya, nama bandar, nama peri, Pokemon, kereta jenama... Hanya ada satu syarat - senarai itu tidak boleh habis sebelum ini, bagaimana gaya berakhir - persembahan mesti pergi! Anda tidak seharusnya terbawa-bawa dengan semantik, supaya anda tidak perlu menambah butang tengah antara "kecil" dan "sederhana," sebagai contoh.

Bahasa visual

Pembangun dibiarkan memikirkan cara menyimpan dan memindahkan data dengan cara yang sesuai dengan semua platform, dan reka bentuk perlu mereka bentuk elemen antara muka yang boleh kelihatan baik dan berfungsi dengan berkesan merentas keseluruhan kumpulan peranti yang disokong.

Sebelum ini, kami telah berjaya "menguji" kebanyakan elemen reka bentuk dalam aplikasi untuk Windows 10, yang pada masa itu merupakan platform baharu untuk kami, iaitu, ia memerlukan rendering dan pembangunan "dari awal." Dengan melukisnya, kami dapat menyediakan dan menguji kebanyakan komponen dan memahami yang mana antara mereka sepatutnya dimasukkan dalam sistem reka bentuk Eevee masa hadapan. Tanpa kotak pasir sedemikian, pengalaman sedemikian hanya boleh diperolehi melalui sejumlah besar lelaran pada platform yang sudah berfungsi, dan ini akan mengambil masa lebih daripada satu tahun.

Menggunakan semula komponen yang sama pada platform yang berbeza mengurangkan bilangan susun atur dan susunan data sistem reka bentuk dengan ketara, jadi reka bentuk terpaksa menyelesaikan satu lagi masalah, yang sebelum ini tidak diterangkan dalam amalan reka bentuk dan pembangunan produk - bagaimana, sebagai contoh, bolehkah butang untuk telefon dan tablet digunakan semula pada TV? Dan apakah yang perlu kita lakukan dengan saiz fon dan elemen pada platform yang berbeza itu?

Jelas sekali, adalah perlu untuk mereka bentuk grid modular merentas platform yang akan menetapkan teks dan saiz elemen yang kami perlukan untuk setiap platform tertentu. Sebagai titik permulaan untuk grid, kami memilih saiz dan bilangan poster filem yang kami mahu lihat pada skrin tertentu dan, berdasarkan ini, kami merumuskan peraturan untuk membina lajur grid, dengan syarat lebar satu lajur adalah sama. kepada lebar poster.

Sekarang kita perlu membawa semua skrin besar ke saiz susun atur yang sama dan muatkannya ke dalam grid biasa. Apple TV dan Roku direka dalam saiz 1920x1080, Android TV - 960x540, TV Pintar, bergantung pada vendor, adalah sama, tetapi kadangkala 1280x720. Apabila apl dipaparkan dan dipaparkan pada skrin HD Penuh, 960 didarab dengan 2, 1280 didarab dengan 1,33 dan 1920 adalah output seperti sedia ada.

Melangkau butiran yang membosankan, kami membuat kesimpulan bahawa secara amnya semua skrin, termasuk skrin televisyen, dari segi elemen dan saiznya, diliputi oleh satu susun atur reka bentuk, dan semua skrin televisyen adalah kes khas grid merentas platform umum, dan terdiri daripada lima atau enam lajur, seperti tablet atau desktop biasa. Siapa yang berminat untuk butiran, pergi dalam komen.

UI tunggal untuk semua platform

Kini, untuk melukis ciri baharu, kami tidak perlu melukis reka letak untuk setiap platform, serta pilihan kebolehsuaian untuk setiap platform. Ia cukup untuk menunjukkan satu susun atur dan kebolehsuaiannya untuk semua platform dan peranti dengan lebar apa pun: telefon - 320-599, semua yang lain - 600-1280.

Data → pembangunan

Sudah tentu, walaupun kami ingin mencapai reka bentuk yang bersatu sepenuhnya, setiap platform mempunyai ciri uniknya sendiri. Walaupun kedua-dua web dan TV Pintar menggunakan timbunan ReactJS + TypeScript, apl TV Pintar berjalan pada klien WebKit dan Presto warisan dan oleh itu tidak boleh berkongsi gaya dengan web. Dan surat berita e-mel terpaksa sepenuhnya berfungsi dengan susun atur jadual. Pada masa yang sama, tiada satu pun daripada platform bukan html menggunakan atau merancang untuk menggunakan React Native atau mana-mana analognya, bimbang kemerosotan prestasi, kerana kami mempunyai terlalu banyak reka letak tersuai, koleksi dengan logik kemas kini yang kompleks, imej dan video. Oleh itu, skema biasa untuk menyampaikan gaya CSS siap sedia atau komponen React tidak sesuai untuk kami. Oleh itu, kami memutuskan untuk menghantar data dalam format JSON, menerangkan nilai dalam bentuk deklaratif abstrak.

Jadi harta rounding: 8 Apl Windows 10 bertukar kepada CornerRadius="8", web - border-radius: 8px, Android - android:radius="8dp", iOS - self.layer.cornerRadius = 8.0.
Harta benda offsetTop: 12 pelanggan web yang sama dalam kes yang berbeza boleh mentafsir sebagai top, margin-top, padding-top atau transform

Perisytiharan perihalan juga membayangkan bahawa jika platform secara teknikal tidak boleh menggunakan harta atau nilainya, ia boleh mengabaikannya. Dari segi istilah, kami membuat sejenis bahasa Esperanto: ada yang diambil dari Android, ada yang dari SVG, ada yang dari CSS.

Jika pada platform tertentu anda perlu memaparkan elemen secara berbeza, kami telah melaksanakan keupayaan untuk memindahkan penjanaan data yang sepadan dalam bentuk fail JSON yang berasingan. Sebagai contoh, keadaan "dalam fokus" untuk TV Pintar menentukan perubahan dalam kedudukan teks di bawah poster, yang bermaksud untuk platform ini komponen dalam nilai sifat "inden" ini akan mengandungi 8 titik lekukan yang diperlukannya. Walaupun ini merumitkan infrastruktur sistem reka bentuk, ia memberikan tahap kebebasan tambahan, memberikan kami peluang untuk menguruskan sendiri "perbezaan" visual platform, dan tidak menjadi tebusan kepada seni bina yang kami cipta.

Piktogram

Ikonografi dalam produk digital sentiasa merupakan subprojek yang banyak dan bukan subprojek yang paling mudah, selalunya memerlukan pereka bentuk yang berasingan. Sentiasa terdapat banyak glyph, setiap daripadanya mempunyai beberapa saiz dan warna, dan platform biasanya memerlukannya dalam format yang berbeza. Secara umum, tidak ada sebab untuk tidak meletakkan semua ini ke dalam sistem reka bentuk.

Glyphs dimuatkan dalam format vektor SVG, dan nilai warna digantikan secara automatik dengan pembolehubah. Aplikasi pelanggan boleh menerimanya sedia untuk digunakan - dalam sebarang format dan warna.

Pratonton

Di atas data JSON, kami menulis alat untuk pratonton komponen - aplikasi JS yang menghantar data JSON dengan cepat melalui penanda dan penjana gayanya serta memaparkan pelbagai variasi setiap komponen dalam penyemak imbas. Pada asasnya, pratonton adalah pelanggan yang sama seperti aplikasi platform dan berfungsi dengan data yang sama.

Cara paling mudah untuk memahami cara komponen tertentu berfungsi adalah dengan berinteraksi dengannya. Oleh itu, kami tidak menggunakan alatan seperti Buku Cerita, tetapi membuat pratonton interaktif - anda boleh menyentuh, menunjuk, mengklik... Apabila menambah komponen baharu pada sistem reka bentuk, ia muncul dalam pratonton supaya platform mempunyai sesuatu untuk difokuskan apabila melaksanakannya.

Dokumentasi

Berdasarkan data yang dibekalkan kepada platform dalam bentuk JSON, dokumentasi untuk komponen dijana secara automatik. Senarai sifat dan kemungkinan jenis nilai dalam setiap daripada mereka diterangkan. Selepas penjanaan automatik, maklumat boleh dijelaskan secara manual dan penerangan teks boleh ditambah. Pratonton dan dokumentasi dirujuk silang antara satu sama lain pada tahap setiap komponen, dan semua maklumat yang disertakan dalam dokumentasi tersedia untuk pembangun dalam bentuk fail JSON tambahan.

Penghina

Satu lagi keperluan ialah keupayaan untuk menggantikan dan mengemas kini komponen sedia ada dari semasa ke semasa. Sistem reka bentuk telah belajar untuk memberitahu pembangun sifat atau keseluruhan komponen mana yang tidak boleh digunakan dan mengalih keluarnya sebaik sahaja ia tidak lagi digunakan pada semua platform. Masih terdapat banyak kerja "manual" dalam proses ini, tetapi kami tidak berdiam diri.

Perkembangan pelanggan

Tidak dinafikan, peringkat paling kompleks ialah tafsiran data sistem reka bentuk dalam kod semua platform yang kami sokong. Jika, sebagai contoh, grid modular di web bukanlah sesuatu yang baharu, maka pembangun aplikasi mudah alih asli untuk iOS dan Android bekerja keras sebelum mereka mengetahui cara untuk menggunakannya.

Untuk susun atur skrin aplikasi iOS, kami menggunakan dua mekanisme asas yang disediakan oleh iviUIKit: susun atur percuma elemen dan susun atur koleksi elemen. Kami menggunakan VIPER, dan semua interaksi dengan iviUIKit tertumpu dalam View, dan kebanyakan interaksi dengan Apple UIKit tertumpu dalam iviUIKit. Saiz dan susunan elemen ditentukan dari segi lajur dan struktur sintaksis yang berfungsi di atas kekangan SDK iOS asli, menjadikannya lebih praktikal. Ini terutamanya memudahkan kehidupan kami apabila bekerja dengan UICollectionView. Kami telah menulis beberapa pembungkus tersuai untuk reka letak, termasuk yang agak rumit. Terdapat minimum kod pelanggan dan ia menjadi deklaratif.

Untuk menjana gaya dalam projek Android, kami menggunakan Gradle, menukar data sistem reka bentuk kepada gaya dalam format XML. Pada masa yang sama, kami mempunyai beberapa penjana pelbagai peringkat:

• Asas. Data primitif untuk penjana tahap lebih tinggi dihuraikan.
• Sumber. Muat turun gambar, ikon dan grafik lain.
• Komponen. Ia ditulis untuk setiap komponen, yang menerangkan sifat dan cara menterjemahkannya ke dalam gaya.

Keluaran permohonan

Selepas pereka bentuk telah melukis komponen baharu atau mereka bentuk semula komponen sedia ada, perubahan ini dimasukkan ke dalam sistem reka bentuk. Pembangun setiap platform sedang memperhalusi penjanaan kod mereka untuk menyokong perubahan. Selepas ini, ia boleh digunakan dalam pelaksanaan fungsi baharu di mana komponen ini diperlukan. Oleh itu, interaksi dengan sistem reka bentuk tidak berlaku dalam masa nyata, tetapi hanya pada masa memasang keluaran baharu. Pendekatan ini juga membolehkan kawalan yang lebih baik ke atas proses pemindahan data dan memastikan kefungsian kod dalam projek pembangunan pelanggan.

Keputusan

Sudah setahun sejak sistem reka bentuk menjadi sebahagian daripada infrastruktur yang menyokong pembangunan pawagam dalam talian Ivy, dan kami sudah boleh membuat beberapa kesimpulan:

• Ini adalah projek yang besar dan kompleks yang memerlukan sumber khusus yang berterusan.
• Ini membolehkan kami mencipta bahasa visual merentas platform unik kami sendiri yang memenuhi objektif perkhidmatan video dalam talian.
• Kami tidak lagi mempunyai platform ketinggalan secara visual dan berfungsi.

Pratonton komponen sistem reka bentuk Ivy - design.ivi.ru

Sumber: www.habr.com