UI- ნაკრებიდან დიზაინის სისტემამდე

აივის ონლაინ კინოს გამოცდილება

როდესაც 2017 წლის დასაწყისში ჩვენ პირველად ვიფიქრეთ საკუთარი დიზაინის კოდის მიწოდების სისტემის შექმნაზე, ბევრი უკვე საუბრობდა ამაზე, ზოგიც კი აკეთებდა. თუმცა, დღემდე ცოტაა ცნობილი კროს-პლატფორმული დიზაინის სისტემების მშენებლობის გამოცდილების შესახებ და არ არსებობს მკაფიო და დადასტურებული რეცეპტები, რომლებიც აღწერს ტექნოლოგიებსა და მეთოდებს დიზაინის განხორციელების პროცესის უკვე მოქმედ პროდუქტად ტრანსფორმაციისთვის. და "კომპონენტები კოდში" ისინი ხშირად ძალიან განსხვავებულ რამეებს გულისხმობენ.

იმავდროულად, კომპანია ყოველწლიურად აორმაგებდა პერსონალს - საჭირო იყო დიზაინის განყოფილების მასშტაბირება და განლაგების შექმნისა და განვითარებისთვის გადაცემის პროცესების ოპტიმიზაცია. ჩვენ ამ ყველაფერს ვამრავლებთ იმ პლატფორმების „ზოოპარკზე“, რომელსაც მხარდაჭერა სჭირდება და მივიღებთ ბაბილონის პანდემიის მსგავსებას, რომელსაც უბრალოდ არ შეუძლია „ნორმალურად ამის გაკეთება“ და შემოსავლის გამომუშავება. პლატფორმების განვითარება ხშირად პარალელურად მიმდინარეობდა და ერთი და იგივე ფუნქციონალობა შეიძლება გამოშვებულიყო სხვადასხვა პლატფორმაზე რამდენიმე თვის დაგვიანებით.


განლაგების ცალკეული ნაკრები თითოეული პლატფორმისთვის

ტრადიციულად, ჩვენ დავიწყეთ ისეთი პრობლემებით, რომელთა გადაჭრასაც საპროექტო სისტემა დაგვეხმარება და მისი დიზაინის მოთხოვნების ჩამოყალიბება. გარდა ერთიანი ვიზუალური ენის შექმნის, განლაგებისა და განვითარების სიჩქარის გაზრდისა და მთლიანობაში პროდუქტის ხარისხის გაუმჯობესებისა, სასიცოცხლოდ მნიშვნელოვანი იყო დიზაინის მაქსიმალურად გაერთიანება. ეს აუცილებელია იმისათვის, რომ ფუნქციონალობის განვითარება შესაძლებელი გახდეს ჩვენს ყველა პლატფორმაზე ერთდროულად: Web, 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. როდესაც აპი რენდერია და ნაჩვენებია Full HD ეკრანებზე, 960 მრავლდება 2-ზე, 1280 მრავლდება 1,33-ზე და 1920 გამოდის როგორც არის.

მოსაწყენი დეტალების გამოტოვებით, მივედით დასკვნამდე, რომ ზოგადად ყველა ეკრანი, მათ შორის სატელევიზიო ეკრანები, ელემენტებითა და მათი ზომებით, დაფარულია ერთი დიზაინის განლაგებით, და ყველა სატელევიზიო ეკრანი არის ზოგადი ჯვარედინი პლატფორმის ბადის განსაკუთრებული შემთხვევა. და შედგება ხუთი ან ექვსი სვეტისგან, როგორიცაა საშუალო ტაბლეტი ან დესკტოპი. ვისაც აინტერესებს დეტალები, დაწერეთ კომენტარებში.

ერთი UI ყველა პლატფორმისთვის

ახლა, ახალი ფუნქციის დასახატად, ჩვენ არ გვჭირდება თითოეული პლატფორმის განლაგების დახატვა, პლუს თითოეული მათგანისთვის ადაპტაციის ვარიანტები. საკმარისია აჩვენოთ ერთი განლაგება და მისი ადაპტირება ნებისმიერი სიგანის ყველა პლატფორმისა და მოწყობილობისთვის: ტელეფონები - 320-599, დანარჩენი ყველაფერი - 600-1280.

მონაცემები → განვითარება

რა თქმა უნდა, რამდენადაც ჩვენ გვსურს მივაღწიოთ სრულიად ერთიან დიზაინს, თითოეულ პლატფორმას აქვს თავისი უნიკალური მახასიათებლები. მიუხედავად იმისა, რომ ვებ და სმარტ ტელევიზორი იყენებს 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

აღწერილობის დეკლარატურობა ასევე გულისხმობს, რომ თუ პლატფორმა ტექნიკურად ვერ გამოიყენებს საკუთრებას ან მის ღირებულებას, მას შეუძლია უგულებელყოს იგი. ტერმინოლოგიის თვალსაზრისით, ჩვენ გავაკეთეთ ერთგვარი ესპერანტო ენა: ზოგი ანდროიდიდან იყო აღებული, ზოგი SVG-დან, ზოგიც CSS-დან.

თუ კონკრეტულ პლატფორმაზე გჭირდებათ ელემენტების განსხვავებულად ჩვენება, ჩვენ განვახორციელეთ შესაბამისი მონაცემთა გენერირების შესაძლებლობა ცალკე JSON ფაილის სახით. მაგალითად, Smart TV-სთვის „ფოკუსში“ მდგომარეობა კარნახობს პოსტერის ქვეშ ტექსტის პოზიციის ცვლილებას, რაც ნიშნავს, რომ ამ პლატფორმისთვის ეს კომპონენტი „შეწევის“ თვისებაში შეიცავს მისთვის საჭირო 8 შეწევის წერტილს. მიუხედავად იმისა, რომ ეს ართულებს დიზაინის სისტემის ინფრასტრუქტურას, ის იძლევა დამატებით თავისუფლების ხარისხს, რაც გვაძლევს შესაძლებლობას თავად ვმართოთ პლატფორმების ვიზუალური „განსხვავებები“ და არ ვიყოთ ჩვენ მიერ შექმნილი არქიტექტურის მძევლები.

პიქტოგრამები

იკონოგრაფია ციფრულ პროდუქტში ყოველთვის არის მოცულობითი და არა უმარტივესი ქვეპროექტი, რომელიც ხშირად მოითხოვს ცალკე დიზაინერს. ყოველთვის ბევრი გლიფია, თითოეულ მათგანს აქვს რამდენიმე ზომა და ფერი და პლატფორმებს ჩვეულებრივ სჭირდებათ ისინი სხვადასხვა ფორმატში. ზოგადად, არ არსებობდა მიზეზი, რომ ეს ყველაფერი არ ჩასვა დიზაინის სისტემაში.

გლიფები იტვირთება SVG ვექტორულ ფორმატში და ფერის მნიშვნელობები ავტომატურად იცვლება ცვლადებით. კლიენტის აპლიკაციებს შეუძლიათ მიიღონ ისინი გამოსაყენებლად მზად - ნებისმიერ ფორმატში და ფერში.

გადახედვა

JSON მონაცემების თავზე, ჩვენ დავწერეთ ინსტრუმენტი კომპონენტების გადახედვისთვის - JS აპლიკაცია, რომელიც გადასცემს JSON მონაცემებს მისი მარკირებისა და სტილის გენერატორების მეშვეობით და აჩვენებს თითოეული კომპონენტის სხვადასხვა ვარიაციებს ბრაუზერში. არსებითად, გადახედვა არის ზუსტად იგივე კლიენტი, როგორც პლატფორმის აპლიკაციები და მუშაობს იგივე მონაცემებით.

უმარტივესი გზა იმის გასაგებად, თუ როგორ მუშაობს კონკრეტული კომპონენტი, არის მასთან ურთიერთობა. ამიტომ, ჩვენ არ ვიყენებდით Storybook-ის მსგავს ინსტრუმენტებს, არამედ გავაკეთეთ ინტერაქტიული გადახედვა - შეგიძლიათ შეეხოთ, მიუთითოთ, დააწკაპუნოთ... დიზაინის სისტემაში ახალი კომპონენტის დამატებისას, ის ჩნდება წინასწარ გადახედვაში, რათა პლატფორმებს ჰქონდეს რაიმე ფოკუსირება, როდესაც მისი განხორციელება.

დოკუმენტაცია

JSON-ის სახით პლატფორმებზე მიწოდებულ მონაცემებზე დაყრდნობით, კომპონენტების დოკუმენტაცია ავტომატურად გენერირდება. აღწერილია თვისებების სია და მნიშვნელობების შესაძლო ტიპები თითოეულ მათგანში. ავტომატური გენერირების შემდეგ, ინფორმაციის დაზუსტება შესაძლებელია ხელით და შეიძლება დაემატოს ტექსტის აღწერა. წინასწარი გადახედვა და დოკუმენტაცია ერთმანეთთან არის დაკავშირებული თითოეული კომპონენტის დონეზე და დოკუმენტაციაში შეტანილი ყველა ინფორმაცია ხელმისაწვდომია დეველოპერებისთვის დამატებითი JSON ფაილების სახით.

დეპრეკატორი

კიდევ ერთი აუცილებლობა იყო არსებული კომპონენტების დროთა განმავლობაში შეცვლისა და განახლების შესაძლებლობა. დიზაინის სისტემამ ისწავლა აცნობოს დეველოპერებს რომელი თვისებების ან თუნდაც მთლიანი კომპონენტების გამოყენება შეუძლებელია და ამოიღონ ისინი, როგორც კი აღარ იქნება გამოყენებული ყველა პლატფორმაზე. ამ პროცესში ჯერ კიდევ ბევრია „ხელით“ შრომა, მაგრამ ჩვენ არ ვდგავართ.

კლიენტის განვითარება

უდავოდ, ყველაზე რთული ეტაპი იყო დიზაინის სისტემის მონაცემების ინტერპრეტაცია ყველა პლატფორმის კოდში, რომელსაც ჩვენ მხარს ვუჭერთ. თუ, მაგალითად, მოდულური ბადეები ინტერნეტში არ არის რაიმე ახალი, მაშინ iOS და Android-ის მშობლიური მობილური აპლიკაციების დეველოპერები ბევრს მუშაობდნენ, სანამ გაერკვნენ, როგორ ეცხოვრათ მათთან.

iOS აპლიკაციის ეკრანების განლაგებისთვის, ჩვენ ვიყენებთ iviUIKit-ის მიერ მოწოდებულ ორ ძირითად მექანიზმს: ელემენტების უფასო განლაგება და ელემენტების კოლექციების განლაგება. ჩვენ ვიყენებთ VIPER-ს და iviUIKit-თან მთელი ურთიერთქმედება კონცენტრირებულია View-ში და ყველაზე მეტი ურთიერთქმედება Apple UIKit-თან კონცენტრირებულია iviUIKit-ში. ელემენტების ზომები და განლაგება მითითებულია სვეტებისა და სინტაქსური სტრუქტურების მიხედვით, რომლებიც მუშაობენ iOS SDK-ის ძირითადი შეზღუდვების ზემოთ, რაც მათ უფრო პრაქტიკულს ხდის. ამან განსაკუთრებით გაამარტივა ჩვენი ცხოვრება UICollectionView-თან მუშაობისას. ჩვენ დავწერეთ რამდენიმე მორგებული შეფუთვა განლაგებისთვის, მათ შორის საკმაოდ რთული. იყო მინიმალური კლიენტის კოდი და გახდა დეკლარაციული.

Android პროექტში სტილის გენერირებისთვის, ჩვენ ვიყენებთ Gradle-ს, რომელიც აქცევს დიზაინის სისტემის მონაცემებს სტილებად XML ფორმატში. ამავდროულად, ჩვენ გვაქვს სხვადასხვა დონის რამდენიმე გენერატორი:

• ძირითადი. პრიმიტივების მონაცემები უფრო მაღალი დონის გენერატორებისთვის გაანალიზებულია.
• რესურსი. ჩამოტვირთეთ სურათები, ხატები და სხვა გრაფიკა.
• Კომპონენტი. ისინი დაწერილია თითოეული კომპონენტისთვის, რომელიც აღწერს რა თვისებებს და როგორ გადაითარგმნოს ისინი სტილებად.

განაცხადის რელიზები

მას შემდეგ, რაც დიზაინერებმა შეადგინეს ახალი კომპონენტი ან გადააკეთეს არსებული, ეს ცვლილებები შეიტანება დიზაინის სისტემაში. თითოეული პლატფორმის დეველოპერები ახდენენ სრულყოფილად რეგულირებას მათი კოდის გენერაციას ცვლილებების მხარდასაჭერად. ამის შემდეგ, ის შეიძლება გამოყენებულ იქნას ახალი ფუნქციონირების განხორციელებისთვის, სადაც ეს კომპონენტია საჭირო. ამრიგად, დიზაინის სისტემასთან ურთიერთქმედება არ ხდება რეალურ დროში, არამედ მხოლოდ ახალი გამოშვებების შეკრების დროს. ეს მიდგომა ასევე იძლევა უკეთეს კონტროლს მონაცემთა გადაცემის პროცესზე და უზრუნველყოფს კოდის ფუნქციონირებას კლიენტის განვითარების პროექტებში.

შედეგები

უკვე ერთი წელია, რაც დიზაინის სისტემა გახდა Ivy ონლაინ კინოს განვითარების ხელშემწყობი ინფრასტრუქტურის ნაწილი და უკვე შეგვიძლია გარკვეული დასკვნების გამოტანა:

• ეს არის დიდი და რთული პროექტი, რომელიც მოითხოვს მუდმივ გამოყოფილ რესურსებს.
• ამან მოგვცა საშუალება შეგვექმნა ჩვენი უნიკალური კროს-პლატფორმული ვიზუალური ენა, რომელიც აკმაყოფილებს ონლაინ ვიდეო სერვისის მიზნებს.
• ჩვენ აღარ გვაქვს ვიზუალურად და ფუნქციურად ჩამორჩენილი პლატფორმები.

Ivy დიზაინის სისტემის კომპონენტების გადახედვა - design.ivi.ru

წყარო: www.habr.com