UI-иж бүрдэлээс дизайны систем хүртэл

Ivy онлайн кино театрын туршлага

2017 оны эхээр бид өөрсдийн дизайнаас код руу хүргэх системийг бий болгох талаар анх бодож байх үед олон хүн энэ тухай ярьж, зарим нь бүр үүнийг хийж байсан. Гэсэн хэдий ч өнөөдрийг хүртэл платформ хоорондын дизайны системийг бий болгох туршлага бага байгаа бөгөөд дизайныг хэрэгжүүлэх үйл явцыг аль хэдийн ажиллаж байгаа бүтээгдэхүүн болгон хувиргах технологи, аргуудыг тодорхойлсон тодорхой, батлагдсан жор байдаггүй. Мөн "код дахь бүрэлдэхүүн хэсгүүд" гэдэг нь ихэвчлэн тэс өөр зүйлийг илэрхийлдэг.

Үүний зэрэгцээ тус компани ажилчдынхаа тоог жилээс жилд хоёр дахин нэмэгдүүлж, дизайны хэлтсийг өргөжүүлж, зураг төсөл боловсруулах, шилжүүлэх үйл явцыг оновчтой болгох шаардлагатай байв. Бид энэ бүхнийг дэмжих шаардлагатай платформуудын "амьтны хүрээлэн"-ээр үржүүлж, "хэвийн байдлаар" хийж, орлого олох боломжгүй Вавилоны тахалтай төстэй дүр төрхийг олж авдаг. Платформуудыг хөгжүүлэх нь ихэвчлэн зэрэгцээ явагддаг байсан бөгөөд ижил функцийг хэдэн сарын хоцрогдолтой өөр өөр платформ дээр гаргах боломжтой байв.


Платформ бүрийн хувьд тусдаа байршлын багц

Уламжлал ёсоор бид дизайны систем нь түүнийг шийдвэрлэхэд туслах асуудлаас эхэлж, түүний дизайны шаардлагыг томъёолсон. Нэгдмэл дүрслэлийн хэлийг бий болгох, зохион байгуулалт, боловсруулалтын хурдыг нэмэгдүүлэх, бүтээгдэхүүний чанарыг бүхэлд нь сайжруулахаас гадна дизайныг аль болох нэгтгэх нь амин чухал байв. Вэб, iOS, Android, Smart TV, tvOS, Android TV, Windows 10, xBox One, PS4, Roku зэрэг манай бүх платформ дээр тус тусад нь ажиллахгүйгээр функцийг хөгжүүлэх боломжтой болохын тулд энэ нь зайлшгүй шаардлагатай. Тэгээд бид үүнийг хийсэн!

Дизайн → өгөгдөл

Бүтээгдэхүүний болон хөгжүүлэлтийн хэлтсүүдийн хооронд үндсэн тохиролцоонд хүрэхэд бид технологийн стекийг сонгож, зохион байгуулалтаас эхлээд гаргах хүртэлх бүх үйл явцын нарийн ширийн зүйлийг боловсруулахаар суулаа. Дизайныг хөгжүүлэлт рүү шилжүүлэх үйл явцыг бүрэн автоматжуулахын тулд бид схем бүхий Sketch файлаас бүрэлдэхүүн хэсгийн параметрүүдийг шууд задлан шинжлэх сонголтыг судалсан. Бидэнд хэрэгтэй кодын хэсгүүдийг олж, шаардлагатай параметрүүдийг гаргаж авах нь төвөгтэй бөгөөд аюултай ажил байсан нь тодорхой болсон. Нэгдүгээрт, дизайнерууд эх кодын бүх давхаргыг нэрлэхдээ маш болгоомжтой байх хэрэгтэй, хоёрдугаарт, энэ нь зөвхөн хамгийн энгийн бүрэлдэхүүн хэсгүүдэд л ажилладаг, гуравдугаарт, Sketch-ийн анхны байршлын өөр хэн нэгний технологи, кодын бүтцээс хамааралтай байх нь бүхэл бүтэн хувилбарын ирээдүйг эрсдэлд оруулдаг. төсөл. Бид энэ чиглэлээр автоматжуулалтаас татгалзахаар шийдсэн. Дизайн системийн багт анхны хүн ийм байдлаар гарч ирсэн бөгөөд түүний оролт нь дизайны зохион байгуулалт, гаралт нь бүрэлдэхүүн хэсгүүдийн бүх параметрүүдийг тодорхойлсон өгөгдөл бөгөөд атомын дизайны аргачлалын дагуу эрэмбэлсэн байна.

Бидний дэмждэг бүх платформ дээр өгөгдлийг хаана, хэрхэн хадгалах, хөгжүүлэлт рүү хэрхэн шилжүүлэх, хөгжүүлэлтийн явцад хэрхэн тайлбарлах вэ гэдэг л үлдлээ. Орой нь тайвшрахаа больсон... Загвар зохион бүтээгчид, багийн ахлагч нараас бүрдсэн ажлын хэсэг индэр тус бүрээс ээлжит уулзалтын үр дүнд дараах асуудлаар тохиролцоонд хүрэв.

Бид визуал зургийг атомын элементүүдэд гараар задлан шинжилдэг: фонт, өнгө, ил тод байдал, догол мөр, дугуйрсан дүрс, дүрс, хөдөлгөөнт дүрс, үргэлжлэх хугацаа. Мөн бид эндээс товчлуурууд, оролтууд, чек хайрцагнууд, банкны картын виджетүүд гэх мэтийг цуглуулдаг. Бид дүрсээс бусад аль ч түвшний хэв маягт утгын бус нэр өгдөг, жишээлбэл, хотын нэр, нимфүүдийн нэр, Покемон, машин брэндүүд... Зөвхөн нэг нөхцөл бий - жагсаалт дуусахаас өмнө дуусах ёсгүй, загварууд хэрхэн төгсдөг вэ - шоу явах ёстой! Жишээлбэл, "жижиг" ба "дунд" гэсэн хоёрын хооронд дунд товчлуур нэмэх шаардлагагүй тул та семантикт автах ёсгүй.

Харааны хэл

Хөгжүүлэгчид бүх платформд тохирсон байдлаар өгөгдлийг хэрхэн хадгалах, дамжуулах талаар бодох үлдсэн бөгөөд дизайн нь дэмжигдсэн төхөөрөмжүүдийн бүх флот дээр сайн харагдах, үр дүнтэй ажиллах интерфейсийн элементүүдийг зохион бүтээх ёстой байв.

Өмнө нь бид Windows 10-д зориулсан програмын ихэнх дизайны элементүүдийг "туршиж" чадсан бөгөөд тэр үед бидний хувьд шинэ платформ байсан, өөрөөр хэлбэл "эхнээс нь" буулгах, хөгжүүлэх шаардлагатай байв. Үүнийг зурснаар бид ихэнх бүрэлдэхүүн хэсгүүдийг бэлтгэж, туршиж үзсэн бөгөөд тэдгээрийн алийг нь ирээдүйн Eevee дизайны системд оруулах ёстойг ойлгох боломжтой болсон. Ийм хамгаалагдсан хязгаарлагдмал орчингүйгээр ийм туршлагыг аль хэдийн ажиллаж байгаа платформ дээр олон тооны давталтаар л олж авах боломжтой бөгөөд энэ нь нэг жилээс илүү хугацаа шаардагдах болно.

Ижил бүрэлдэхүүн хэсгүүдийг өөр өөр платформ дээр дахин ашиглах нь дизайны системийн бүтцийн тоо, өгөгдлийн массивыг эрс багасгадаг тул дизайн нь өмнө нь бүтээгдэхүүний дизайн, хөгжүүлэлтийн практикт тайлбарлаагүй өөр нэг асуудлыг шийдэх шаардлагатай болсон - жишээ нь: утас, таблетын товчлуурыг зурагт дээр дахин ашиглаж болох уу? Ийм өөр платформ дээрх фонт, элементийн хэмжээг бид яах ёстой вэ?

Тодорхой платформ бүрт хэрэгтэй текст болон элементийн хэмжээг тохируулах платформ хоорондын модульчлагдсан сүлжээг зохион бүтээх шаардлагатай байсан нь ойлгомжтой. Сүлжээний эхлэлийн цэг болгон бид тодорхой дэлгэцэн дээр үзэхийг хүсч буй киноны зурагт хуудасны хэмжээ, тоог сонгож, үүн дээр үндэслэн нэг баганын өргөн нь тэнцүү байх тохиолдолд сүлжээний багана барих дүрмийг боловсруулсан. зурагт хуудасны өргөн хүртэл.

Одоо бид бүх том дэлгэцийг ижил хэмжээтэй болгож, нийтлэг сүлжээнд оруулах хэрэгтэй. Apple TV болон Roku нь 1920x1080 хэмжээтэй, Android TV - 960x540 хэмжээтэй, Ухаалаг ТВ нь үйлдвэрлэгчээс хамааран адилхан боловч заримдаа 1280x720 хэмжээтэй байдаг. Аппликейшнийг бүрэн HD дэлгэц дээр буулгах үед 960-ыг 2-оор, 1280-ыг 1,33-аар үржүүлж, 1920-ыг байгаагаар нь гаргана.

Уйтгартай нарийн ширийн зүйлийг алгасаад бид ерөнхийдөө бүх дэлгэц, түүний дотор телевизийн дэлгэц нь элемент, хэмжээнүүдийн хувьд нэг дизайны зохион байгуулалтаар бүрхэгдсэн байдаг бөгөөд бүх телевизийн дэлгэц нь ерөнхий хөндлөн платформ сүлжээний онцгой тохиолдол юм гэсэн дүгнэлтэд хүрсэн. бөгөөд дундаж таблет эсвэл ширээний компьютер гэх мэт тав, зургаан баганаас бүрдэнэ. Дэлгэрэнгүйг сонирхож буй хүмүүс коммент хэсэгт бичээрэй.

Бүх платформд зориулсан ганц UI

Одоо шинэ функцийг зурахын тулд бид платформ тус бүрийн загвар, тэдгээрийн дасан зохицох сонголтуудыг зурах шаардлагагүй. Ямар ч өргөнтэй бүх платформ, төхөөрөмжүүдийн хувьд нэг зохион байгуулалт, түүний дасан зохицох чадварыг харуулахад хангалттай: утас - 320-599, бусад бүх зүйл - 600-1280.

Өгөгдөл → хөгжүүлэлт

Мэдээжийн хэрэг, бид бүрэн нэгдсэн загварт хүрэхийг хүсч байгаа ч платформ бүр өөрийн гэсэн онцлог шинж чанартай байдаг. Хэдийгээр вэб болон Smart TV хоёулаа ReactJS + TypeScript стекийг ашигладаг ч Smart TV програм нь хуучин WebKit болон Presto үйлчлүүлэгчид дээр ажилладаг тул вэбтэй хэв маягаа хуваалцах боломжгүй. Мөн имэйл мэдээллийн товхимолууд нь хүснэгтийн загвартай ажиллахаас өөр аргагүй болдог. Үүний зэрэгцээ html бус платформуудын аль нь ч React Native эсвэл түүний аль нэг аналогийг ашигладаггүй эсвэл ашиглахаар төлөвлөдөггүй, учир нь бид хэт олон захиалгат зохион байгуулалт, цогц шинэчлэлтийн логик бүхий цуглуулгууд, зураг, видео бичлэгүүдтэй тул гүйцэтгэлийн бууралтаас айдаг. Тиймээс бэлэн CSS загварууд эсвэл React бүрэлдэхүүн хэсгүүдийг хүргэх нийтлэг схем нь бидний хувьд тохиромжгүй юм. Тиймээс бид утгыг хийсвэр тунхаг хэлбэрээр дүрслэн JSON форматаар өгөгдөл дамжуулахаар шийдсэн.

Тиймээс өмч rounding: 8 Windows 10 програмыг хөрвүүлдэг CornerRadius="8", вэб - border-radius: 8px, Android - android:radius="8dp", iOS - self.layer.cornerRadius = 8.0.
Өмч offsetTop: 12 өөр өөр тохиолдолд ижил вэб клиент гэж тайлбарлаж болно top, margin-top, padding-top буюу transform

Тайлбарын тунхаглал нь хэрэв платформ техникийн хувьд өмч эсвэл түүний үнэ цэнийг ашиглах боломжгүй бол үүнийг үл тоомсорлож болно гэсэн үг юм. Нэр томъёоны хувьд бид нэг төрлийн эсперанто хэл хийсэн: заримыг нь Android, заримыг нь SVG, заримыг нь CSS-ээс авсан.

Хэрэв та тодорхой платформ дээр элементүүдийг өөрөөр харуулах шаардлагатай бол бид холбогдох өгөгдлийг JSON файл хэлбэрээр дамжуулах боломжийг хэрэгжүүлсэн. Жишээлбэл, Smart TV-ийн "тодорхойлолт" төлөв нь зурагт хуудасны доорх текстийн байрлалыг өөрчлөхийг шаарддаг бөгөөд энэ нь энэ платформын хувьд "догол" шинж чанарын утга дахь энэ бүрэлдэхүүн хэсэг нь шаардлагатай 8 доголын цэгийг агуулна гэсэн үг юм. Энэ нь дизайны системийн дэд бүтцийг хүндрүүлдэг ч гэсэн нэмэлт эрх чөлөөг өгч, платформуудын харааны "ялгаагүй байдлыг" өөрсдөө удирдах боломжийг олгож, бидний бүтээсэн архитектурын барьцаанд орохгүй.

Пиктограммууд

Дижитал бүтээгдэхүүн дэх дүрс зураг нь үргэлж том хэмжээтэй бөгөөд хамгийн энгийн дэд төсөл биш бөгөөд ихэвчлэн тусдаа дизайнер шаарддаг. Үргэлж олон тооны глифүүд байдаг бөгөөд тэдгээр нь тус бүр нь хэд хэдэн хэмжээ, өнгөтэй байдаг бөгөөд платформууд нь ихэвчлэн өөр өөр форматтай байдаг. Ерөнхийдөө энэ бүхнийг дизайны системд оруулахгүй байх шалтгаан байгаагүй.

Глифүүдийг SVG вектор форматаар ачаалж, өнгөний утгыг автоматаар хувьсагчаар солино. Үйлчлүүлэгчийн програмууд нь тэдгээрийг ашиглахад бэлэн - ямар ч хэлбэр, өнгөөр ​​​​хүлээн авах боломжтой.

урьдчилан үзэх

JSON өгөгдлийн дээр бид бүрэлдэхүүн хэсгүүдийг урьдчилан харах хэрэгслийг бичсэн - JSON өгөгдлийг тэмдэглэгээ, загвар үүсгэгчээр дамжуулан шууд дамжуулж, бүрэлдэхүүн хэсэг бүрийн янз бүрийн хувилбаруудыг хөтөч дээр харуулдаг JS програм. Үндсэндээ урьдчилан харах нь платформын програмуудтай яг ижил клиент бөгөөд ижил өгөгдөлтэй ажилладаг.

Тодорхой бүрэлдэхүүн хэсэг хэрхэн ажилладагийг ойлгох хамгийн хялбар арга бол түүнтэй харилцах явдал юм. Тиймээс бид Storybook гэх мэт хэрэгслүүдийг ашиглаагүй, харин интерактив урьдчилан харахыг хийсэн - та хүрч, зааж, товшиж болно ... Дизайн системд шинэ бүрэлдэхүүн хэсэг нэмэх үед энэ нь урьдчилан харах хэсэгт гарч ирдэг бөгөөд ингэснээр платформууд хэзээ анхаарах зүйлтэй болно. түүнийг хэрэгжүүлж байна.

Баримт бичиг

JSON хэлбэрээр платформуудад нийлүүлсэн өгөгдөл дээр үндэслэн бүрэлдэхүүн хэсгүүдийн баримт бичгийг автоматаар үүсгэдэг. Эдгээр шинж чанаруудын жагсаалт, тэдгээрийн боломжит төрлүүдийг тайлбарласан болно. Автомат үүсгэсний дараа мэдээллийг гараар тодруулж, текстийн тайлбарыг нэмж болно. Урьдчилан үзэх болон баримтжуулалт нь бүрэлдэхүүн хэсэг бүрийн түвшинд бие биенээсээ хамааралтай бөгөөд баримт бичигт багтсан бүх мэдээллийг нэмэлт JSON файл хэлбэрээр хөгжүүлэгчид ашиглах боломжтой.

Хуурамчлагч

Өөр нэг шаардлага бол одоо байгаа бүрэлдэхүүн хэсгүүдийг цаг хугацааны явцад солих, шинэчлэх чадвар байв. Дизайн систем нь хөгжүүлэгчдэд аль шинж чанар, тэр ч байтугай бүхэл бүтэн бүрэлдэхүүн хэсгүүдийг ашиглах боломжгүйг хэлж, тэдгээрийг бүх платформ дээр ашиглахаа больсон даруйд нь устгаж сурсан. Энэ үйл явцад “гарын” хөдөлмөр их байгаа ч бид зүгээр зогсохгүй байна.

Үйлчлүүлэгчийн хөгжил

Бидний дэмждэг бүх платформуудын код дахь дизайны системийн өгөгдлийг тайлбарлах нь хамгийн төвөгтэй үе шат байсан нь эргэлзээгүй. Жишээлбэл, вэб дээрх модульчлагдсан сүлжээнүүд нь шинэ зүйл биш бол iOS болон Android-д зориулсан уугуул гар утасны програм хөгжүүлэгчид үүнтэй хэрхэн амьдрахаа олж мэдэхээсээ өмнө шаргуу ажилласан.

IOS програмын дэлгэцийг байрлуулахын тулд бид iviUIKit-ийн өгсөн хоёр үндсэн механизмыг ашигладаг: элементүүдийн үнэгүй зохион байгуулалт, элементүүдийн цуглуулгын зохион байгуулалт. Бид VIPER-ийг ашигладаг бөгөөд iviUIKit-тэй хийсэн бүх харилцан үйлчлэл нь View дээр төвлөрч, Apple UIKit-тэй харилцах ихэнх нь iviUIKit-д төвлөрдөг. Элементүүдийн хэмжээ, зохион байгуулалтыг iOS SDK-н үндсэн хязгаарлалт дээр ажилладаг багана, синтаксийн бүтцээр тодорхойлсноор тэдгээрийг илүү практик болгодог. Энэ нь ялангуяа UICollectionView-тэй ажиллахад бидний амьдралыг хялбаршуулсан. Бид зохион байгуулалтад зориулж хэд хэдэн захиалгат боодол, түүний дотор нэлээд төвөгтэй зүйлсийг бичсэн. Хамгийн бага үйлчлүүлэгчийн код байсан бөгөөд энэ нь тунхаглалтай болсон.

Андройд төсөлд загвар үүсгэхийн тулд бид дизайны системийн өгөгдлийг XML форматаар загвар болгон хувиргах Gradle програмыг ашигладаг. Үүний зэрэгцээ бид янз бүрийн түвшний хэд хэдэн генераторуудтай:

• Үндсэн. Дээд түвшний генераторуудын командуудын өгөгдлийг задлан шинжилнэ.
• Нөөц. Зураг, дүрс болон бусад графикуудыг татаж авах.
• Бүрэлдэхүүн хэсэг. Тэдгээр нь ямар шинж чанарууд, тэдгээрийг хэв маягт хэрхэн хөрвүүлэхийг тодорхойлсон бүрэлдэхүүн хэсэг тус бүрд зориулагдсан болно.

Хэрэглээний хувилбарууд

Загвар зохион бүтээгчид шинэ бүрэлдэхүүн хэсгийг зурсны дараа эсвэл одоо байгаа хэсгийг дахин зохион бүтээсний дараа эдгээр өөрчлөлтүүд нь дизайны системд ордог. Платформ бүрийн хөгжүүлэгчид өөрчлөлтийг дэмжихийн тулд кодын боловсруулалтыг нарийн тааруулж байна. Үүний дараа энэ бүрэлдэхүүн хэсэг шаардлагатай бол шинэ функцийг хэрэгжүүлэхэд ашиглаж болно. Тиймээс дизайны системтэй харилцах нь бодит цаг хугацаанд биш, харин шинэ хувилбаруудыг угсрах үед л тохиолддог. Энэ арга нь өгөгдөл дамжуулах үйл явцыг илүү сайн хянах боломжийг олгодог бөгөөд үйлчлүүлэгчийн хөгжүүлэлтийн төслүүдэд кодын ажиллагааг баталгаажуулдаг.

Үр дүн

Дизайн систем нь Ivy онлайн кино театрын хөгжлийг дэмжих дэд бүтцийн нэг хэсэг болсноос хойш нэг жил болж байгаа бөгөөд бид аль хэдийн зарим дүгнэлтийг хийж чадна.

• Энэ бол байнгын зориулалтын нөөц шаарддаг том бөгөөд төвөгтэй төсөл юм.
• Энэ нь онлайн видео үйлчилгээний зорилгод нийцсэн өөрийн өвөрмөц хөндлөн платформ харааны хэлийг бий болгох боломжийг бидэнд олгосон.
• Бидэнд харааны болон үйл ажиллагааны хувьд хоцрогдсон платформ байхгүй болсон.

Ivy дизайны системийн бүрэлдэхүүн хэсгүүдийг урьдчилан харах - design.ivi.ru

Эх сурвалж: www.habr.com