Pengalaman Film Online IvyKetika pada awal 2017, kami pertama kali berpikir tentang menciptakan sistem kami sendiri untuk mengirimkan desain ke kode, banyak yang membicarakan hal ini dan seseorang bahkan melakukannya. Namun, sedikit yang diketahui tentang pengalaman membangun sistem desain lintas platform hingga hari ini, dan tidak ada resep yang jelas dan terbukti yang menggambarkan teknologi dan metode untuk transformasi proses implementasi desain menjadi produk yang sudah berfungsi. Dan "komponen dalam kode" seringkali memiliki arti yang sangat berbeda.
Sementara itu, perusahaan menggandakan stafnya dari tahun ke tahun - perlu untuk skala departemen desain dan mengoptimalkan proses menciptakan dan mentransfer layout untuk pengembangan. Kami melipatgandakan semua ini dengan "kebun binatang" platform yang perlu didukung, dan kami mendapatkan kemiripan dengan Babel crowding, yang sama sekali tidak mampu "secara normal" dan menghasilkan pendapatan. Pengembangan platform sering berjalan secara paralel, dan fungsionalitas yang sama bisa keluar pada platform yang berbeda dengan jeda beberapa bulan.
Set tata letak terpisah untuk setiap platformSecara tradisional, kami mulai dengan masalah bahwa sistem desain akan membantu memecahkan dan merumuskan persyaratan untuk desainnya. Selain menciptakan bahasa visual tunggal, meningkatkan kecepatan pembuatan prototipe dan pengembangan, meningkatkan kualitas produk secara keseluruhan, sangat penting untuk menyatukan desain sebanyak mungkin. Ini diperlukan agar pengembangan fungsionalitas dapat segera 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 secara terpisah . Dan kami berhasil!
Desain → Data
Ketika perjanjian utama dari departemen produk dan pengembangan tercapai, kami duduk untuk memilih tumpukan teknologi dan mempelajari detail dari seluruh proses - dari tata letak hingga rilis. Untuk sepenuhnya mengotomatiskan proses transfer desain ke pengembangan, kami menyelidiki opsi dengan parser parameter komponen langsung dari file Sketsa dengan tata letak. Ternyata menemukan potongan-potongan kode yang kami butuhkan dan mengekstraksi parameter yang kami butuhkan adalah pekerjaan yang rumit dan berbahaya. Pertama, desainer harus sangat berhati-hati dalam memberi nama semua lapisan kode sumber, kedua, itu hanya bekerja untuk komponen yang paling sederhana, dan ketiga, ketergantungan pada teknologi orang lain dan struktur kode tata letak Sketsa asli membahayakan masa depan seluruh proyek. Kami memutuskan untuk meninggalkan otomatisasi di bidang ini. Jadi, orang pertama muncul dalam tim sistem desain, di pintu masuk yang tata letak desain diajukan, dan pada output - data yang menggambarkan semua parameter komponen dan disusun secara hierarkis sesuai dengan metodologi desain atom.
Masalahnya tetap kecil: di mana dan bagaimana menyimpan data, bagaimana mentransfernya ke pengembangan, dan bagaimana menafsirkannya dalam pengembangan di semua platform yang didukung oleh kami. Malam itu berhenti menjadi lesu ... Hasil pertemuan rutin kelompok kerja, yang terdiri dari desainer dan pemimpin tim dari setiap platform, adalah kesepakatan sebagai berikut.
Kami mem-parsing visual menjadi elemen atom: font, warna, transparansi, indentasi, fillet, ikon, gambar, dan durasi untuk animasi. Dan kami kumpulkan dari tombol ini, input, kotak centang, widget kartu bank, dll. Kami menetapkan nama non-semantik untuk gaya level mana pun, kecuali untuk ikon, misalnya, nama kota, nama nimfa, Pokemon, merek mobil ... Hanya ada satu syarat - daftar tidak boleh kehabisan sebelumnya , gaya apa yang akan berakhir dengan - tunjukkan tiang pergi dia! Anda tidak boleh terbawa oleh semantik sehingga Anda tidak perlu menambahkan tombol tengah antara "kecil" dan "sedang", misalnya.
Bahasa visual
Para pengembang pergi untuk memikirkan bagaimana cara menyimpan dan mentransfer data sehingga sesuai dengan semua platform, dan desain harus merancang elemen antarmuka yang dapat terlihat sama baiknya dan bekerja secara efektif di seluruh armada perangkat yang didukung.
Sebelumnya, kami berhasil "menjalankan" sebagian besar elemen desain dalam aplikasi untuk Windows 10, yang pada saat itu merupakan platform baru bagi kami, yaitu, rendering dan pengembangan dari awal diperlukan. Dengan menggambarnya, kami dapat mempersiapkan dan menguji sebagian besar komponen dan memahami komponen mana yang akan dimasukkan dalam sistem desain Ivy mendatang. Tanpa kotak pasir seperti itu, pengalaman seperti itu hanya dapat diperoleh dengan sejumlah besar iterasi pada platform yang sudah bekerja, dan ini akan memakan waktu lebih dari satu tahun.
Menggunakan kembali komponen yang sama pada platform yang berbeda mengurangi jumlah tata letak dan susunan data dari sistem desain di kali, sehingga desain harus memecahkan masalah lain yang sebelumnya tidak dijelaskan dalam praktik desain dan pengembangan produk - bagaimana, misalnya, untuk menggunakan kembali tombol untuk ponsel dan tablet di TV? Dan apa yang secara prinsip seharusnya dengan ukuran font dan elemen pada platform yang berbeda?
Jelas, itu perlu untuk merancang grid modular lintas-platform yang akan mengatur ukuran teks dan elemen yang kami butuhkan untuk setiap platform tertentu. Untuk titik referensi untuk grid, kami memilih ukuran dan jumlah poster film yang ingin kami lihat di layar tertentu dan, berdasarkan ini, merumuskan aturan untuk membangun kolom grid, asalkan lebar satu kolom sama dengan lebar poster.
Sekarang Anda perlu membawa semua layar besar ke ukuran tata letak yang sama dan memasangkannya ke dalam kisi-kisi umum. Apple TV dan Roku sedang dikembangkan dalam ukuran 1920x1080, Android TV - 960x540, Smart TV, tergantung pada vendor mereka sama, dan ada 1280x720. Ketika aplikasi dirender dan ditampilkan pada layar Full HD, 960 dikalikan dengan 2, 1280 oleh 1.33, dan 1920 ditampilkan sebagaimana adanya.
Dengan mengabaikan detail yang membosankan, kami sampai pada kesimpulan bahwa secara umum semua layar, termasuk layar TV dalam hal elemen dan ukurannya, dicakup oleh satu tata letak desain, dan semua layar TV adalah kasus khusus dari grid lintas platform yang umum, dan terdiri dari lima atau enam kolom, seperti tablet rata-rata atau desktop. Siapa yang peduli dengan detailnya, buka komentar.
UI terpadu untuk semua platformSekarang, untuk menggambar fitur baru, kita tidak perlu menggambar tata letak untuk setiap platform, ditambah opsi adaptasi untuk masing-masing platform. Cukup untuk menunjukkan satu tata letak dan kemampuan beradaptasi untuk semua platform dan perangkat dengan lebar apa pun: telepon - 320-599, segalanya - 600-1280.
Data → Pengembangan
Tentu saja, tidak peduli bagaimana kami ingin sampai pada desain yang sepenuhnya terpadu, setiap platform memiliki fitur uniknya sendiri. Terlepas dari kenyataan bahwa baik web dan Smart TV menggunakan tumpukan ReactJS + TypeScript, aplikasi Smart TV berjalan pada klien WebKit dan Presto lama, dan karenanya tidak dapat menggunakan gaya umum dengan web. Dan buletin email sepenuhnya dipaksa untuk bekerja dengan tata letak tabel. Pada saat yang sama, tidak satu pun platform non-html menggunakan atau berencana untuk menggunakan React Native atau analognya, karena takut akan penurunan kinerja, karena kami memiliki terlalu banyak tata letak khusus, koleksi dengan logika pembaruan kompleks, gambar, dan video. Oleh karena itu, skema umum tidak cocok untuk kami - untuk menyediakan gaya CSS siap pakai atau komponen Bereaksi. Oleh karena itu, kami memutuskan untuk mentransfer data dalam format JSON, menggambarkan nilai-nilai dalam bentuk deklaratif abstrak.
Jadi properti rounding: 8 , aplikasi Windows 10 dikonversi ke CornerRadius="8" , web - border-radius: 8px , Android - android:radius="8dp" , iOS - self.layer.cornerRadius = 8.0 .
offsetTop: 12 OffsetTop offsetTop: 12 klien web yang sama dapat diartikan dalam kasus yang berbeda seperti top , margin-top , padding-top atau transform
Sifat deklaratif deskripsi juga menunjukkan bahwa jika platform secara teknis tidak dapat menggunakan properti atau nilainya, ia dapat mengabaikannya. Dalam hal terminologi, kami membuat semacam bahasa Esperanto: kami mengambil sesuatu dari Android, beberapa dari SVG, beberapa dari CSS.
Jika perlu untuk menampilkan elemen dengan cara berbeda pada platform tertentu, kami telah mengimplementasikan kemampuan untuk mentransfer pembuatan data terkait sebagai file JSON yang terpisah. Misalnya, statusnya “fokus” untuk Smart TV, ia menentukan perubahan posisi teks di bawah poster, jadi untuk platform ini komponen ini dalam nilai properti “indent” akan berisi 8 titik indent yang dibutuhkan. Meskipun ini merumitkan infrastruktur sistem desain, ini memberikan tingkat kebebasan tambahan, memberi kita kesempatan untuk mengelola "ketidaksamaan" visual dari platform itu sendiri, dan tidak menjadi sandera pada arsitektur yang kami buat.
Piktogram
Ikonografi dalam produk digital selalu merupakan sub proyek yang banyak dan tidak mudah, seringkali memiliki perancang yang terpisah. Selalu ada banyak mesin terbang, masing-masing memiliki beberapa ukuran dan warna, apalagi, platform membutuhkannya, sebagai aturan dalam format yang berbeda. Secara umum, tidak ada alasan untuk tidak membawa semua ini ke dalam sistem desain.
Mesin terbang dimuat dalam format vektor SVG, dan nilai warna secara otomatis diganti dengan variabel. Aplikasi klien dapat membuatnya siap digunakan - dalam format dan warna apa pun.
Pratinjau
Di atas JSON dengan data, kami menulis alat untuk melihat pratinjau komponen - aplikasi JS yang melewatkan data JSON melalui markup dan generator gaya dengan cepat dan menampilkan berbagai variasi setiap komponen di browser. Bahkan, pratinjau klien persis sama dengan aplikasi platform, dan bekerja dengan data yang sama.
Memahami cara kerja komponen tertentu paling mudah dengan berinteraksi dengannya. Oleh karena itu, kami tidak menggunakan alat seperti Storybook, tetapi melakukan pratinjau interaktif - Anda dapat menyentuh, mengarahkan, klik ... Ketika Anda menambahkan komponen baru ke sistem desain, itu muncul di pratinjau sehingga platform memiliki sesuatu untuk fokus ketika memperkenalkannya.
Dokumentasi
Berdasarkan data yang dikirimkan dalam bentuk JSON ke platform, dokumentasi komponen dihasilkan secara otomatis. Daftar properti dan kemungkinan jenis nilai di masing-masing dijelaskan. Setelah pembuatan otomatis, informasi dapat diklarifikasi secara manual, tambahkan deskripsi teks. Pratinjau dan dokumentasi dilengkapi dengan rujukan silang satu sama lain di tingkat masing-masing komponen, dan semua informasi yang termasuk dalam dokumentasi tersedia untuk pengembang dalam bentuk file JSON tambahan.
Deprecator
Kebutuhan lain adalah kemampuan untuk mengganti dan meningkatkan komponen yang ada seiring waktu. Sistem desain telah belajar memberi tahu pengembang mana properti atau bahkan seluruh komponen yang tidak dapat digunakan dan menghapusnya segera setelah mereka tidak lagi digunakan pada semua platform. Masih ada banyak pekerjaan “manual” dalam proses ini, tetapi kami tidak tinggal diam.
Pengembangan pelanggan
Tidak diragukan lagi, interpretasi data sistem desain dalam kode semua platform yang didukung oleh kami menjadi tahap yang paling luas dalam kompleksitas. Jika, misalnya, kisi modular di web bukanlah hal baru, maka pengembang aplikasi seluler asli untuk iOS dan Android berkeringat cukup keras sebelum mereka menemukan cara untuk hidup dengannya.
Untuk tata letak layar aplikasi iOS, kami menggunakan dua mekanisme dasar yang iviUIKit sediakan: tata letak elemen gratis dan tata letak koleksi elemen. Kami menggunakan VIPER, dan semua interaksi dengan iviUIKit terkonsentrasi di View, dan sebagian besar interaksi dengan Apple UIKit terkonsentrasi di iviUIKit. Ukuran dan pengaturan elemen ditentukan dalam hal kolom dan konstruksi sintaksis yang bekerja di atas konstanta SDK iOS asli, membuatnya lebih diterapkan. Ini terutama menyederhanakan hidup kita ketika bekerja dengan UICollectionView. Kami menulis beberapa tata letak yang dapat disesuaikan untuk tata letak, termasuk yang cukup rumit. Kode klien berubah minimum dan menjadi deklaratif.
Untuk menghasilkan gaya dalam proyek Android, kami menggunakan Gradle, mengubah data sistem desain menjadi gaya format XML. Pada saat yang sama, kami memiliki beberapa generator dari berbagai tingkatan:
- Dasar Parsing data primitif untuk generator tingkat yang lebih tinggi.
- Sumberdaya . Unduh gambar, ikon, dan grafik lainnya.
- Komponen Mereka ditulis untuk setiap komponen, yang menggambarkan properti apa dan bagaimana menerjemahkan ke gaya.
Rilis aplikasi
Setelah desainer menggambar komponen baru atau mengerjakan yang sudah ada, perubahan ini masuk ke dalam sistem desain. Pengembang setiap platform menyelesaikan pembuatan kode mereka, memberikan dukungan untuk perubahan. Setelah itu, dapat digunakan dalam implementasi fungsi baru, di mana komponen ini diperlukan. Dengan demikian, interaksi dengan sistem desain tidak terjadi secara real time, tetapi hanya pada saat merakit rilis baru. Pendekatan ini juga memungkinkan Anda untuk lebih mengontrol proses transfer data dan menjamin kinerja kode dalam proyek pengembangan klien.
Ringkasan
Segera, sebagai sistem desain, setahun menjadi bagian dari infrastruktur yang melayani pengembangan bioskop online Ivy, dan beberapa kesimpulan sudah dapat ditarik:
- Ini adalah proyek besar dan sulit untuk dilaksanakan, membutuhkan sumber daya yang dialokasikan konstan.
- Ini memungkinkan kami untuk 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 -
design.ivi.ru