Dari UI-kit hingga sistem desain

Pengalaman bioskop online Ivy

Ketika di awal tahun 2017 kami pertama kali berpikir untuk membuat sistem pengiriman desain-ke-kode kami sendiri, banyak yang sudah membicarakannya dan bahkan ada yang melakukannya. Namun, hingga saat ini, hanya sedikit yang diketahui tentang pengalaman membangun sistem desain lintas platform, dan belum ada resep yang jelas dan terbukti yang menjelaskan teknologi dan metode untuk mengubah proses implementasi desain menjadi produk yang sudah berfungsi. Dan yang dimaksud dengan “komponen dalam kode” sering kali memiliki arti yang sangat berbeda.

Sementara itu, perusahaan menggandakan stafnya dari tahun ke tahun - departemen desain perlu ditingkatkan dan mengoptimalkan proses pembuatan dan transfer tata letak untuk pengembangan. Kita mengalikan semua ini dengan “kebun binatang” platform yang perlu didukung, dan kita mendapatkan kemiripan dengan kekacauan Babilonia, yang tidak mampu “melakukannya secara normal” dan menghasilkan pendapatan. Pengembangan platform sering kali berjalan secara paralel, dan fungsi yang sama dapat dirilis pada platform berbeda dengan jeda beberapa bulan.


Kumpulan tata letak terpisah untuk setiap platform

Secara tradisional, kami memulai dengan masalah yang dapat dipecahkan oleh sistem desain dan merumuskan persyaratan untuk desainnya. Selain menciptakan bahasa visual yang terpadu, meningkatkan kecepatan tata letak dan pengembangan, serta meningkatkan kualitas produk secara keseluruhan, penting untuk menyatukan desain sebanyak mungkin. Hal ini diperlukan agar pengembangan fungsionalitas dapat dilakukan di semua platform kami secara bersamaan: Web, iOS, Android, Smart TV, tvOS, Android TV, Windows 10, xBox One, PS4, Roku - tanpa mengerjakan masing-masing platform secara terpisah. Dan kami berhasil!

Desain → data

Ketika kesepakatan mendasar antara departemen produk dan pengembangan tercapai, kami duduk untuk memilih tumpukan teknologi dan mengerjakan detail keseluruhan proses - mulai dari tata letak hingga rilis. Untuk sepenuhnya mengotomatiskan proses transfer desain ke pengembangan, kami menjelajahi opsi penguraian parameter komponen langsung dari file Sketsa dengan tata letak. Ternyata menemukan potongan kode yang kami perlukan dan mengekstraksi parameter yang kami perlukan adalah pekerjaan yang rumit dan berbahaya. Pertama, desainer harus sangat berhati-hati dalam memberi nama semua lapisan kode sumber, kedua, ini hanya berfungsi untuk komponen paling sederhana, dan ketiga, ketergantungan pada teknologi orang lain dan struktur kode tata letak Sketsa asli membahayakan masa depan keseluruhan. proyek. Kami memutuskan untuk meninggalkan otomatisasi di bidang ini. Ini adalah bagaimana orang pertama muncul dalam tim sistem desain, yang masukannya adalah tata letak desain, dan keluarannya adalah data yang menjelaskan semua parameter komponen dan diurutkan secara hierarkis sesuai dengan metodologi desain atom.

Satu-satunya hal yang harus dilakukan adalah di mana dan bagaimana menyimpan data, bagaimana mentransfernya ke pengembangan, dan bagaimana menafsirkannya dalam pengembangan di semua platform yang kami dukung. Malam pun tak lagi lesu... Hasil pertemuan rutin kelompok kerja yang terdiri dari desainer dan pimpinan tim dari masing-masing platform adalah kesepakatan sebagai berikut.

Kami secara manual mengurai visual menjadi elemen atom: font, warna, transparansi, indentasi, pembulatan, ikon, gambar, dan durasi animasi. Dan kami mengumpulkan dari sini tombol, masukan, kotak centang, widget kartu bank, dll. Kami menetapkan nama non-semantik ke gaya level mana pun, kecuali ikon, misalnya, nama kota, nama nimfa, Pokemon, mobil merek... Hanya ada satu syarat - daftarnya tidak boleh habis sebelumnya , bagaimana gaya berakhir - pertunjukan harus dilanjutkan! Anda tidak boleh terbawa oleh semantik, sehingga Anda tidak perlu menambahkan tombol tengah antara “kecil” dan “sedang”, misalnya.

bahasa visual

Pengembang harus memikirkan cara menyimpan dan mentransfer data dengan cara yang sesuai untuk semua platform, dan desain harus merancang elemen antarmuka yang terlihat bagus dan bekerja secara efektif di seluruh armada perangkat yang didukung.

Sebelumnya, kami telah berhasil “menguji” sebagian besar elemen desain dalam aplikasi untuk Windows 10, yang pada saat itu merupakan platform baru bagi kami, sehingga memerlukan rendering dan pengembangan “dari awal”. Dengan menggambarnya, kami dapat mempersiapkan dan menguji sebagian besar komponen serta memahami komponen mana yang seharusnya disertakan dalam sistem desain Eevee masa depan. Tanpa sandbox seperti itu, pengalaman seperti itu hanya dapat diperoleh melalui sejumlah besar iterasi pada platform yang sudah berfungsi, dan ini akan memakan waktu lebih dari satu tahun.

Penggunaan kembali komponen yang sama pada platform yang berbeda mengurangi jumlah tata letak dan susunan data sistem desain secara signifikan, sehingga desain harus memecahkan masalah lain yang sebelumnya tidak dijelaskan dalam praktik desain dan pengembangan produk - bagaimana, misalnya, dapatkah tombol untuk ponsel dan tablet digunakan kembali di TV? Dan apa yang harus kita lakukan dengan ukuran font dan elemen pada platform yang berbeda?

Tentu saja, perlu merancang grid modular lintas platform yang akan mengatur ukuran teks dan elemen yang kami perlukan untuk setiap platform tertentu. Sebagai titik awal untuk grid, kami memilih ukuran dan jumlah poster film yang ingin kami lihat di layar tertentu dan, berdasarkan ini, kami merumuskan aturan untuk membuat kolom grid, dengan syarat lebar satu kolom sama. dengan lebar poster.

Sekarang kita perlu membawa semua layar besar ke ukuran tata letak yang sama dan memasukkannya ke dalam grid yang sama. Apple TV dan Roku didesain dalam ukuran 1920x1080, Android TV - 960x540, Smart TV, tergantung vendornya, sama, tapi terkadang 1280x720. Saat aplikasi dirender dan ditampilkan pada layar Full HD, 960 dikalikan 2, 1280 dikalikan 1,33, dan 1920 dikeluarkan apa adanya.

Melewatkan detail yang membosankan, kami sampai pada kesimpulan bahwa secara umum semua layar, termasuk layar televisi, dalam hal elemen dan ukurannya, tercakup dalam satu tata letak desain, dan semua layar televisi adalah kasus khusus dari jaringan lintas platform umum, dan terdiri dari lima atau enam kolom, seperti rata-rata tablet atau desktop. Siapa yang tertarik dengan detailnya, buka komentar.

UI tunggal untuk semua platform

Sekarang, untuk menggambar fitur baru, kita tidak perlu menggambar tata letak untuk setiap platform, ditambah opsi kemampuan beradaptasi untuk masing-masing platform. Cukup dengan menunjukkan satu tata letak dan kemampuan beradaptasinya untuk semua platform dan perangkat dengan lebar berapa pun: ponsel - 320-599, yang lainnya - 600-1280.

Data → pengembangan

Tentu saja, meskipun kami ingin mencapai desain yang sepenuhnya terpadu, setiap platform memiliki fitur uniknya sendiri. Meskipun web dan Smart TV menggunakan tumpukan ReactJS + TypeScript, aplikasi Smart TV berjalan pada klien WebKit dan Presto lama sehingga tidak dapat berbagi gaya dengan web. Dan buletin email sepenuhnya dipaksa untuk bekerja dengan tata letak tabel. Pada saat yang sama, tidak ada platform non-html yang menggunakan atau berencana menggunakan React Native atau analognya, karena takut akan penurunan kinerja, karena kami memiliki terlalu banyak tata letak khusus, koleksi dengan logika pembaruan, gambar, dan video yang kompleks. Oleh karena itu, skema umum pengiriman gaya CSS atau komponen React yang sudah jadi tidak cocok untuk kami. Oleh karena itu, kami memutuskan untuk mengirimkan data dalam format JSON, menggambarkan nilai dalam bentuk deklaratif abstrak.

Jadi properti rounding: 8 Aplikasi Windows 10 dikonversi menjadi CornerRadius="8", jaring - border-radius: 8px, Android- android:radius="8dp", iOS- self.layer.cornerRadius = 8.0.
Properti offsetTop: 12 klien web yang sama dalam kasus yang berbeda dapat diartikan sebagai top, margin-top, padding-top или transform

Deklaratifnya deskripsi juga menyiratkan bahwa jika platform secara teknis tidak dapat menggunakan properti atau nilainya, maka platform dapat mengabaikannya. Dari segi terminologi, kami membuat semacam bahasa Esperanto: ada yang diambil dari Android, ada yang dari SVG, ada yang dari CSS.

Jika pada platform tertentu Anda perlu menampilkan elemen secara berbeda, kami telah menerapkan kemampuan untuk mentransfer pembuatan data terkait dalam bentuk file JSON terpisah. Misalnya, status “dalam fokus” untuk Smart TV menentukan perubahan posisi teks di bawah poster, yang berarti untuk platform ini komponen dalam nilai properti “indentasi” akan berisi 8 titik indentasi yang diperlukan. Meskipun hal ini mempersulit infrastruktur sistem desain, hal ini memberikan tingkat kebebasan tambahan, memberikan kita kesempatan untuk mengelola sendiri “ketidaksamaan” visual dari platform, dan tidak tersandera oleh arsitektur yang kita buat.

Piktogram

Ikonografi dalam produk digital selalu merupakan subproyek yang banyak dan bukan yang paling sederhana, seringkali memerlukan perancang tersendiri. Selalu ada banyak mesin terbang, masing-masing memiliki beberapa ukuran dan warna, dan platform biasanya membutuhkannya dalam format berbeda. Secara umum, tidak ada alasan untuk tidak memasukkan semua ini ke dalam sistem desain.

Mesin terbang dimuat dalam format vektor SVG, dan nilai warna secara otomatis diganti dengan variabel. Aplikasi klien dapat menerimanya siap digunakan - dalam format dan warna apa pun.

едпросмотр

Di atas data JSON, kami menulis alat untuk melihat pratinjau komponen - aplikasi JS yang meneruskan data JSON dengan cepat melalui generator markup dan gayanya, dan menampilkan berbagai variasi dari setiap komponen di browser. Pada dasarnya, pratinjau adalah klien yang sama persis dengan aplikasi platform dan bekerja dengan data yang sama.

Cara termudah untuk memahami cara kerja komponen tertentu adalah dengan berinteraksi dengannya. Oleh karena itu, kami tidak menggunakan alat seperti Buku Cerita, namun membuat pratinjau interaktif - Anda dapat menyentuh, mengarahkan, mengklik... Saat menambahkan komponen baru ke sistem desain, komponen tersebut akan muncul di pratinjau sehingga platform memiliki sesuatu untuk difokuskan saat menerapkannya.

Документация

Berdasarkan data yang dipasok ke platform dalam bentuk JSON, dokumentasi untuk komponen dibuat secara otomatis. Daftar properti dan kemungkinan jenis nilai di masing-masing properti dijelaskan. Setelah pembuatan otomatis, informasi dapat diklarifikasi secara manual dan deskripsi teks dapat ditambahkan. Pratinjau dan dokumentasi direferensikan silang satu sama lain di tingkat masing-masing komponen, dan semua informasi yang disertakan dalam dokumentasi tersedia bagi pengembang dalam bentuk file JSON tambahan.

pencela

Kebutuhan lainnya adalah kemampuan untuk mengganti dan memperbarui komponen yang ada seiring berjalannya waktu. Sistem desain telah belajar untuk memberi tahu pengembang properti atau bahkan seluruh komponen mana yang tidak dapat digunakan dan menghapusnya segera setelah tidak lagi digunakan di semua platform. Masih banyak pekerjaan “manual” dalam proses ini, namun kami tidak tinggal diam.

Pengembangan klien

Tidak diragukan lagi, tahap yang paling rumit adalah interpretasi data sistem desain dalam kode semua platform yang kami dukung. Jika, misalnya, jaringan modular di web bukanlah sesuatu yang baru, maka pengembang aplikasi seluler asli untuk iOS dan Android bekerja keras sebelum mereka menemukan cara untuk menggunakannya.

Untuk menata layar aplikasi iOS, kami menggunakan dua mekanisme dasar yang disediakan oleh iviUIKit: tata letak elemen gratis dan tata letak kumpulan elemen. Kami menggunakan VIPER, dan semua interaksi dengan iviUIKit terkonsentrasi di View, dan sebagian besar interaksi dengan Apple UIKit terkonsentrasi di iviUIKit. Ukuran dan susunan elemen ditentukan dalam bentuk kolom dan struktur sintaksis yang bekerja di atas batasan SDK iOS asli, sehingga lebih praktis. Ini sangat menyederhanakan hidup kami saat bekerja dengan UICollectionView. Kami telah menulis beberapa pembungkus khusus untuk tata letak, termasuk yang cukup rumit. Ada kode klien minimum dan menjadi deklaratif.

Untuk menghasilkan gaya dalam proyek Android, kami menggunakan Gradle, mengubah data sistem desain menjadi gaya dalam format XML. Pada saat yang sama, kami memiliki beberapa generator dengan level berbeda:

• Dasar. Data primitif untuk generator tingkat yang lebih tinggi diurai.
• Sumber. Unduh gambar, ikon, dan grafik lainnya.
• Komponen. Mereka ditulis untuk setiap komponen, yang menjelaskan properti apa dan bagaimana menerjemahkannya ke dalam gaya.

Rilis aplikasi

Setelah desainer menggambar komponen baru atau mendesain ulang komponen yang sudah ada, perubahan ini dimasukkan ke dalam sistem desain. Pengembang setiap platform menyempurnakan pembuatan kode mereka untuk mendukung perubahan. Setelah ini, dapat digunakan dalam implementasi fungsionalitas baru yang memerlukan komponen ini. Dengan demikian, interaksi dengan sistem desain tidak terjadi secara real time, tetapi hanya pada saat perakitan rilis baru. Pendekatan ini juga memungkinkan kontrol yang lebih baik atas proses transfer data dan memastikan fungsionalitas kode dalam proyek pengembangan klien.

Hasil

Sudah setahun sistem desain menjadi bagian dari infrastruktur pendukung perkembangan bioskop online Ivy, dan beberapa kesimpulan sudah bisa kita ambil:

• Ini adalah proyek besar dan kompleks yang memerlukan sumber daya khusus yang konstan.
• Hal ini memungkinkan kami membuat bahasa visual lintas platform unik kami sendiri yang memenuhi tujuan layanan video online.
• Kami tidak lagi memiliki platform yang tertinggal secara visual dan fungsional.

Pratinjau komponen sistem desain Ivy - desain.ivi.ru

Sumber: www.habr.com