Saka UI-kit kanggo sistem desain

Pengalaman bioskop online Ivy

Nalika ing awal 2017 kita pisanan mikir babagan nggawe sistem pangiriman desain-kanggo-kode dhewe, akeh sing wis ngomong babagan iki lan ana uga sing nindakake. Nanging, nganti dina iki, ora ana sing ngerti babagan pengalaman mbangun sistem desain lintas platform, lan ora ana resep sing jelas lan bukti sing njlentrehake teknologi lan cara kanggo transformasi proses implementasi desain dadi produk sing wis digunakake. Lan kanthi "komponen ing kode" asring tegese beda banget.

Sauntara kuwi, perusahaan tikel kaping pindho stafe saben taun - perlu kanggo skala departemen desain lan ngoptimalake proses nggawe lan nransfer tata letak kanggo pembangunan. Kita multiply kabeh iki dening "zoo" saka platform sing kudu didhukung, lan kita njaluk semblance saka pandemoni Babylonia, kang mung ora bisa kanggo "nindakake biasane" lan generate income. Pangembangan platform asring ditindakake kanthi paralel, lan fungsi sing padha bisa diluncurake ing platform sing beda-beda kanthi telat sawetara wulan.


Set tata letak sing kapisah kanggo saben platform

Cara tradisional, kita miwiti masalah sing sistem desain bakal mbantu ngatasi lan ngrumusake syarat kanggo desaine. Saliyane nggawe basa visual sing manunggal, nambah kacepetan tata letak lan pangembangan, lan ningkatake kualitas produk sakabèhé, iku penting kanggo nyawiji desain sabisa-bisa. Iki perlu supaya pangembangan fungsionalitas bisa ditindakake ing kabeh platform kanthi bebarengan: Web, iOS, Android, Smart TV, tvOS, Android TV, Windows 10, xBox One, PS4, Roku - tanpa bisa digunakake kanthi kapisah . Lan kita nindakaken!

Desain → data

Nalika persetujuan dhasar antarane departemen produk lan pangembangan wis tekan, kita lungguh kanggo milih tumpukan teknologi lan ngrampungake rincian kabeh proses - saka tata letak kanggo release. Kanggo ngotomatisasi proses nransfer desain menyang pembangunan, kita njelajah opsi parsing paramèter komponen langsung saka file Sketsa kanthi tata letak. Ternyata nemokake potongan kode sing dibutuhake lan ngekstrak paramèter sing dibutuhake minangka tugas sing rumit lan mbebayani. Kaping pisanan, desainer kudu ati-ati banget kanggo menehi jeneng kabeh lapisan kode sumber, sing nomer loro, iki mung bisa digunakake kanggo komponen sing paling gampang, lan kaping telu, gumantung marang teknologi lan struktur kode wong liya saka tata letak Sketsa asli mbebayani masa depan kabeh. proyek. Kita mutusake kanggo ninggalake otomatisasi ing wilayah iki. Iki minangka cara wong pisanan muncul ing tim sistem desain, sing input yaiku tata letak desain, lan output yaiku data sing njlèntrèhaké kabeh paramèter komponen lan disusun miturut metodologi desain atom.

Siji-sijine perkara sing kudu ditindakake yaiku ing ngendi lan carane nyimpen data, carane nransfer menyang pembangunan lan carane napsirake ing pembangunan ing kabeh platform sing kita ndhukung. Ing wayah sore mandhek dadi languid ... Asil saka rapat-rapat reguler saka kelompok kerja dumadi saka desainer lan tim mimpin saka saben platform ana persetujuan ing ngisor iki.

Kita kanthi manual ngurai visual menyang unsur atom: fonts, werna, transparan, indents, roundings, lambang, gambar lan durasi kanggo animasi. Lan kita ngumpulake saka tombol iki, input, kothak centhang, widget kertu bank, etc. Kita nemtokake jeneng non-semantik kanggo gaya sembarang tingkat, kajaba lambang, contone, jeneng kutha, jeneng nymphs, Pokemon, mobil. merek ... Ana mung siji kondisi - dhaftar ngirim ora kesel sadurunge , carane gaya pungkasan - nuduhake kudu pindhah! Sampeyan ora kudu digawa karo semantik, supaya sampeyan ora kudu nambah tombol tengah antarane "cilik" lan "sedheng", contone.

Basa visual

Pangembang ditinggalake kanggo mikir babagan carane nyimpen lan nransfer data kanthi cara sing cocog karo kabeh platform, lan desain kudu ngrancang unsur antarmuka sing bisa katon apik lan bisa digunakake kanthi efektif ing kabeh armada piranti sing didhukung.

Sadurunge, kita wis bisa "nguji" umume unsur desain ing aplikasi kanggo Windows 10, sing nalika iku minangka platform anyar kanggo kita, yaiku, mbutuhake rendering lan pangembangan "saka awal." Kanthi nggambar, kita bisa nyiyapake lan nguji sebagian besar komponen lan ngerti sapa sing kudu dilebokake ing sistem desain Eevee ing mangsa ngarep. Tanpa kothak wedhi kuwi, pengalaman kuwi mung bisa dipikolehi liwat nomer akeh iterasi ing platform wis digunakake, lan iki bakal njupuk luwih saka setahun.

Nggunakake maneh komponen sing padha ing platform sing beda-beda nyuda jumlah tata letak lan susunan data sistem desain kanthi signifikan, saengga desain kasebut kudu ngrampungake masalah liyane, sing sadurunge ora diterangake ing praktik desain lan pangembangan produk - kepiye, contone, tombol kanggo telpon lan tablet bisa digunakake maneh ing TV? Lan apa sing kudu ditindakake kanthi ukuran font lan unsur ing platform sing beda-beda?

Temenan, perlu ngrancang kothak modular lintas platform sing bakal nyetel ukuran teks lan unsur sing dibutuhake kanggo saben platform tartamtu. Minangka titik wiwitan kanggo kothak, kita milih ukuran lan jumlah poster film sing arep kita deleng ing layar tartamtu lan, adhedhasar iki, kita ngrumusake aturan kanggo mbangun kolom kothak, kasedhiya yen jembaré siji kolom padha. nganti ambane poster.

Saiki kita kudu nggawa kabeh layar gedhe menyang ukuran tata letak sing padha lan pas menyang kothak umum. Apple TV lan Roku dirancang ing ukuran 1920x1080, Android TV - 960x540, Smart TV, gumantung ing vendor, padha, nanging kadhangkala 1280x720. Nalika app render lan ditampilake ing layar Full HD, 960 pingan dening 2, 1280 pingan dening 1,33, lan 1920 minangka output.

Nglewati rincian mboseni, kita teka menyang kesimpulan sing umume kabeh layar, kalebu layar televisi, ing syarat-syarat unsur lan ukuran sing, dijamin dening siji tata letak desain, lan kabeh layar televisi minangka kasus khusus saka kothak salib-platform umum. lan kalebu lima utawa enem kolom, kaya tablet utawa desktop rata-rata. Sing kasengsem ing rincian, bukak ing komentar.

UI tunggal kanggo kabeh platform

Saiki, kanggo nggambar fitur anyar, kita ora perlu nggambar tata letak kanggo saben platform, uga opsi adaptasi kanggo saben platform. Cukup kanggo nuduhake siji tata letak lan daya adaptasi kanggo kabeh platform lan piranti apa wae jembaré: telpon - 320-599, kabeh liya - 600-1280.

Data → pangembangan

Mesthi wae, kaya sing dikarepake kanggo entuk desain sing lengkap, saben platform duwe fitur unik dhewe. Sanajan web lan Smart TV nggunakake tumpukan ReactJS + TypeScript, aplikasi Smart TV mlaku ing klien WebKit lan Presto warisan lan mulane ora bisa nuduhake gaya karo web. Lan buletin email pancen kepeksa nggarap tata letak tabular. Ing wektu sing padha, ora ana platform non-html sing nggunakake utawa ngrancang nggunakake React Native utawa analoge, amarga wedi degradasi kinerja, amarga kita duwe tata letak khusus, koleksi kanthi logika nganyari, gambar lan video sing rumit. Mulane, skema umum ngirim gaya CSS sing wis siap utawa komponen React ora cocok kanggo kita. Mula, kita mutusake ngirim data ing format JSON, nggambarake nilai kasebut ing wangun deklaratif abstrak.

Dadi properti rounding: 8 Windows 10 app dikonversi menyang CornerRadius="8", web- border-radius: 8px, Android - android:radius="8dp", iOS - self.layer.cornerRadius = 8.0.
Properti offsetTop: 12 klien web padha ing kasus beda bisa kokwaca minangka top, margin-top, padding-top utawa transform

Deklarasi deskripsi uga nuduhake yen platform kasebut kanthi teknis ora bisa nggunakake properti utawa regane, mula bisa ditolak. Ing babagan terminologi, kita nggawe jinis basa Esperanto: sawetara dijupuk saka Android, sawetara saka SVG, sawetara saka CSS.

Yen ing platform tartamtu sampeyan kudu nampilake unsur kanthi beda, kita wis ngetrapake kemampuan kanggo nransfer generasi data sing cocog ing wangun file JSON sing kapisah. Contone, negara "ing fokus" kanggo Smart TV ndhikte owah-owahan ing posisi teks ing poster, kang tegese kanggo platform iki komponen ing Nilai saka "indent" property bakal ngemot 8 TCTerms indentation perlu. Senajan iki complicates infrastruktur saka sistem desain, menehi gelar tambahan saka kamardikan, ninggalake kita karo kesempatan kanggo ngatur visual "dissimilarity" saka platform dhewe, lan ora dadi sandera kanggo arsitektur kita digawe.

Piktogram

Ikonografi ing produk digital tansah dadi subproyek sing akeh banget lan dudu subproyek sing paling gampang, asring mbutuhake desainer sing kapisah. Ana mesthi akeh glyphs, saben wong duwe sawetara ukuran lan werna, lan platform biasane mbutuhake ing macem-macem format. Umumé, ora ana alesan kanggo ora sijine kabeh iki menyang sistem desain.

Glyphs dimuat ing format vektor SVG, lan nilai warna kanthi otomatis diganti karo variabel. Aplikasi klien bisa nampa siap digunakake - ing format lan warna apa wae.

Pratinjau

Ing ndhuwur data JSON, kita nulis alat kanggo pratinjau komponen - aplikasi JS sing ngliwati data JSON kanthi cepet liwat generator markup lan gaya, lan nampilake macem-macem variasi saben komponen ing browser. Ateges, pratinjau persis klien sing padha karo aplikasi platform lan bisa digunakake kanthi data sing padha.

Cara paling gampang kanggo ngerti cara kerja komponen tartamtu yaiku kanthi sesambungan karo komponen kasebut. Mulane, kita ora nggunakake alat kaya Storybook, nanging nggawe pratinjau interaktif - sampeyan bisa ndemek, nunjuk, ngeklik ... Nalika nambah komponen anyar menyang sistem desain, katon ing pratinjau supaya platform bisa fokus nalika ngleksanakake.

Dokumentasi

Adhedhasar data sing diwenehake menyang platform ing wangun JSON, dokumentasi kanggo komponen digawe kanthi otomatis. Dhaptar properti lan kemungkinan jinis nilai ing saben kasebut diterangake. Sawise nggawe otomatis, informasi kasebut bisa dijlentrehake kanthi manual lan deskripsi teks bisa ditambahake. Pratinjau lan dokumentasi kasebut saling referensi ing tingkat saben komponen, lan kabeh informasi sing kalebu ing dokumentasi kasedhiya kanggo pangembang ing wangun file JSON tambahan.

Deprecator

Keperluan liyane yaiku kemampuan kanggo ngganti lan nganyari komponen sing ana sajrone wektu. Sistem desain wis sinau kanggo ngandhani pangembang properti utawa komponen apa wae sing ora bisa digunakake lan mbusak kasebut sanalika ora digunakake maneh ing kabeh platform. Isih akeh tenaga kerja "manual" ing proses iki, nanging kita ora mandheg.

Pangembangan klien

Mesthi, tahap paling rumit yaiku interpretasi data sistem desain ing kode kabeh platform sing kita dukung. Yen, contone, kothak modular ing web dudu sing anyar, mula pangembang aplikasi seluler asli kanggo iOS lan Android kerja keras sadurunge ngerti carane urip.

Kanggo tata layar aplikasi iOS, kita nggunakake rong mekanisme dhasar sing diwenehake dening iviUIKit: tata letak unsur gratis lan tata letak koleksi unsur. Kita nggunakake VIPER, lan kabeh interaksi karo iviUIKit klempakan ing View, lan paling interaksi karo Apple UIKit klempakan ing iviUIKit. Ukuran lan susunan unsur ditemtokake ing syarat-syarat kolom lan struktur sintaksis sing bisa digunakake ing ndhuwur watesan iOS SDK native, nggawe luwih praktis. Iki utamané nyederhanakake urip kita nalika nggarap UICollectionView. Kita wis nulis sawetara bungkus khusus kanggo tata letak, kalebu sing cukup rumit. Ana minimal kode klien lan dadi deklaratif.

Kanggo ngasilake gaya ing proyek Android, kita nggunakake Gradle, ngowahi data sistem desain dadi gaya ing format XML. Ing wektu sing padha, kita duwe sawetara generator saka macem-macem tingkat:

• Dhasar. Data primitif kanggo generator tingkat sing luwih dhuwur diurai.
• sumber daya. Download gambar, lambang, lan grafis liyane.
• Komponen. Iki ditulis kanggo saben komponen, sing nggambarake sifat apa lan carane nerjemahake menyang gaya.

Rilis aplikasi

Sawise desainer nggambar komponen anyar utawa ngrancang maneh komponen sing wis ana, owah-owahan kasebut disedhiyakake menyang sistem desain. Pangembang saben platform nyempurnakake generasi kode kanggo ndhukung owah-owahan kasebut. Sawise iki, bisa digunakake ing implementasine fungsi anyar ing ngendi komponen iki dibutuhake. Mangkono, interaksi karo sistem desain ora kedadeyan ing wektu nyata, nanging mung nalika ngumpulake rilis anyar. Pendekatan iki uga ngidini kontrol sing luwih apik babagan proses transfer data lan njamin fungsi kode ing proyek pangembangan klien.

Hasil

Wis setaun wiwit sistem desain dadi bagean saka infrastruktur sing ndhukung pangembangan bioskop online Ivy, lan kita wis bisa nggawe sawetara kesimpulan:

• Iki minangka proyek gedhe lan kompleks sing mbutuhake sumber daya khusus.
• Iki ngidini kita nggawe basa visual lintas-platform unik dhewe sing cocog karo tujuan layanan video online.
• Kita ora duwe platform lagging visual lan fungsional maneh.

Pratinjau komponen sistem desain Ivy - design.ivi.ru

Source: www.habr.com