UI-kit देखि डिजाइन प्रणाली सम्म

आइवी अनलाइन सिनेमा अनुभव

जब 2017 को सुरुमा हामीले पहिलो पटक हाम्रो आफ्नै डिजाइन-टु-कोड डेलिभरी प्रणाली सिर्जना गर्ने बारे सोच्यौं, धेरैले पहिले नै यसको बारेमा कुरा गरिरहेका थिए र कोहीले यो गरिरहेका थिए। यद्यपि, आजसम्म क्रस-प्लेटफर्म डिजाइन प्रणालीहरू निर्माण गर्ने अनुभवको बारेमा थोरै थाहा छ, र पहिले नै काम गर्ने उत्पादनमा डिजाइन कार्यान्वयनको प्रक्रियालाई यस्तो रूपान्तरणको लागि प्रविधिहरू र विधिहरू वर्णन गर्ने कुनै स्पष्ट र प्रमाणित व्यञ्जनहरू छैनन्। र "कोडमा कम्पोनेन्टहरू" द्वारा तिनीहरू प्रायः धेरै फरक चीजहरू हुन्।

यसैबीच, कम्पनीले वर्ष पछि आफ्नो कर्मचारीलाई दोब्बर बनायो - यो डिजाइन विभाग मापन गर्न र विकासको लागि लेआउटहरू सिर्जना र स्थानान्तरण गर्ने प्रक्रियाहरू अनुकूलन गर्न आवश्यक थियो। हामी यो सबैलाई समर्थन गर्न आवश्यक प्लेटफर्महरूको "चिडियाघर" द्वारा गुणा गर्छौं, र हामीले बेबिलोनियन प्यान्डेमोनियमको झलक पाउँछौं, जुन "सामान्य रूपमा गर्न" र आय उत्पन्न गर्न सक्षम छैन। प्लेटफर्महरूको विकास प्रायः समानान्तरमा अगाडि बढ्यो, र एउटै कार्यक्षमता धेरै महिनाको ढिलोसँग विभिन्न प्लेटफर्महरूमा जारी गर्न सकिन्छ।


प्रत्येक प्लेटफर्मको लागि अलग लेआउट सेट

परम्परागत रूपमा, हामीले समस्याहरूसँग सुरु गर्यौं जुन डिजाइन प्रणालीले समाधान गर्न र यसको डिजाइनको लागि आवश्यकताहरू तयार गर्न मद्दत गर्दछ। एकीकृत दृश्य भाषा सिर्जना गर्न, लेआउट र विकासको गति बढाउने, र समग्र उत्पादनको गुणस्तर सुधार गर्नका साथै, डिजाइनलाई सकेसम्म एकताबद्ध गर्न महत्त्वपूर्ण थियो। यो आवश्यक छ ताकि कार्यक्षमताको विकास हाम्रा सबै प्लेटफर्महरूमा एकैसाथ सम्भव हुन्छ: वेब, आईओएस, एन्ड्रोइड, स्मार्ट टिभी, टिभीओएस, एन्ड्रोइड टिभी, विन्डोज १०, एक्सबक्स वन, PS10, रोकु - प्रत्येकमा छुट्टै काम नगरी। र हामीले यो गर्यौं!

डिजाइन → डाटा

जब उत्पादन र विकास विभागहरू बीच आधारभूत सम्झौताहरू पुगेका थिए, हामी टेक्नोलोजी स्ट्याक चयन गर्न बस्यौं र सम्पूर्ण प्रक्रियाको विवरणहरू - लेआउट देखि रिलीज सम्म काम गर्यौं। डिजाइनलाई विकासमा स्थानान्तरण गर्ने प्रक्रियालाई पूर्ण रूपमा स्वचालित गर्न, हामीले लेआउटहरूसँग स्केच फाइलहरूबाट सीधा कम्पोनेन्ट प्यारामिटरहरू पार्स गर्ने विकल्प खोज्यौं। हामीले आवश्यक पर्ने कोडका टुक्राहरू फेला पार्ने र हामीलाई चाहिने प्यारामिटरहरू निकाल्नु एउटा जटिल र खतरनाक कार्य थियो भन्ने कुरा बाहिर आयो। पहिलो, डिजाइनरहरूले स्रोत कोडका सबै तहहरूको नामकरण गर्न अत्यन्त सावधानी अपनाउनुपर्नेछ, दोस्रो, यो केवल सरल कम्पोनेन्टहरूको लागि काम गर्दछ, र तेस्रो, अरू कसैको प्रविधिमा निर्भरता र मूल स्केच लेआउटको कोड संरचनाले सम्पूर्णको भविष्यलाई खतरामा पार्छ। परियोजना। हामीले यस क्षेत्रमा स्वचालन छोड्ने निर्णय गर्यौं। यसरी पहिलो व्यक्ति डिजाइन प्रणाली टोलीमा देखा पर्‍यो, जसको इनपुट डिजाइन लेआउट हो, र आउटपुट भनेको घटकका सबै प्यारामिटरहरू वर्णन गर्ने डाटा हो र परमाणु डिजाइन पद्धति अनुसार क्रमबद्ध रूपमा क्रमबद्ध हुन्छ।

डाटा कहाँ र कसरी भण्डारण गर्ने, विकासमा कसरी स्थानान्तरण गर्ने र हामीले समर्थन गर्ने सबै प्लेटफर्महरूमा विकासमा यसलाई कसरी व्याख्या गर्ने भन्ने कुरा मात्र बाँकी थियो। साँझ ढिलो हुन छाड्यो... प्रत्येक प्लेटफर्मबाट डिजाइनर र टोली नेतृत्वहरू सम्मिलित कार्यदलको नियमित बैठकहरूको नतिजा निम्नमा सहमति थियो।

हामी म्यानुअल रूपमा दृश्यलाई परमाणु तत्वहरूमा पार्स गर्छौं: फन्टहरू, रंगहरू, पारदर्शिता, इन्डेन्टहरू, राउन्डिङहरू, आइकनहरू, चित्रहरू र एनिमेसनको लागि अवधिहरू। र हामी यस बटनहरू, इनपुटहरू, चेकबक्सहरू, बैंक कार्ड विजेटहरू, इत्यादिबाट सङ्कलन गर्छौं। हामी आइकनहरू बाहेक, कुनै पनि स्तरको शैलीहरूमा गैर-सिमान्टिक नामहरू तोक्छौं, उदाहरणका लागि, शहरहरूको नाम, अप्सराहरूको नाम, पोकेमोन, कार। ब्रान्डहरू... त्यहाँ एउटा मात्र सर्त छ - सूची पहिले समाप्त हुनु हुँदैन, शैलीहरू कसरी समाप्त हुन्छ - शो जानु पर्छ! उदाहरणका लागि तपाईंले "सानो" र "मध्यम" बीचको बीचको बटन थप्न नपरोस् भन्नका खातिर सिमान्टिक्सबाट टाढा जानु हुँदैन।

दृश्य भाषा

विकासकर्ताहरूलाई सबै प्लेटफर्महरूमा उपयुक्त हुने तरिकामा डाटा कसरी भण्डारण र स्थानान्तरण गर्ने भन्ने बारे सोच्न छोडियो, र डिजाइनले राम्रो देखिने र समर्थित यन्त्रहरूको सम्पूर्ण फ्लीटमा प्रभावकारी रूपमा काम गर्न सक्ने इन्टरफेस तत्वहरू डिजाइन गर्नुपर्दछ।

पहिले, हामीले विन्डोज 10 को लागी एप्लिकेसनमा धेरै जसो डिजाइन तत्वहरू "परीक्षण" गर्न व्यवस्थित गरिसकेका थियौं, जुन त्यस समयमा हाम्रो लागि नयाँ प्लेटफर्म थियो, त्यो हो, यसलाई "स्क्र्याचबाट" रेन्डरिंग र विकास आवश्यक थियो। यसलाई चित्रण गरेर, हामीले धेरैजसो कम्पोनेन्टहरू तयार गर्न र परीक्षण गर्न र ती मध्ये कुनलाई भविष्यको Eevee डिजाइन प्रणालीमा समावेश गर्नुपर्ने थियो भनेर बुझ्न सक्षम भयौं। यस्तो स्यान्डबक्स बिना, यस्तो अनुभव पहिले नै कार्यरत प्लेटफर्महरूमा पुनरावृत्तिहरूको ठूलो संख्या मार्फत मात्र प्राप्त गर्न सकिन्छ, र यो एक वर्ष भन्दा बढी लाग्नेछ।

बिभिन्न प्लेटफर्महरूमा एउटै कम्पोनेन्टहरू पुन: प्रयोग गर्दा लेआउटहरूको संख्या र डिजाइन प्रणालीको डाटाको एरेलाई उल्लेखनीय रूपमा घटाउँदछ, त्यसैले डिजाइनले अर्को समस्या समाधान गर्नुपर्‍यो, पहिले उत्पादन डिजाइन र विकासको अभ्यासहरूमा वर्णन गरिएको थिएन - कसरी, उदाहरणका लागि, के फोन र ट्याब्लेटको बटन टिभीमा पुन: प्रयोग गर्न सकिन्छ? र हामीले त्यस्ता विभिन्न प्लेटफर्महरूमा फन्ट र तत्वहरूको आकारसँग के गर्नुपर्छ?

जाहिर छ, क्रस-प्लेटफर्म मोड्युलर ग्रिड डिजाइन गर्न आवश्यक थियो जसले हामीलाई प्रत्येक विशिष्ट प्लेटफर्मको लागि आवश्यक पाठ र तत्व आकारहरू सेट गर्दछ। ग्रिडको लागि सुरूवात बिन्दुको रूपमा, हामीले चलचित्र पोस्टरहरूको साइज र संख्या छनोट गर्यौं जुन हामीले एक विशेष स्क्रिनमा हेर्न चाहन्छौं र, यसको आधारमा, हामीले ग्रिड स्तम्भहरू निर्माण गर्नको लागि नियम बनाएका छौं, बशर्ते एक स्तम्भको चौडाइ बराबर छ। पोस्टरको चौडाइमा।

अब हामीले सबै ठूला स्क्रिनहरूलाई एउटै लेआउट साइजमा ल्याउन र तिनीहरूलाई साझा ग्रिडमा फिट गर्न आवश्यक छ। Apple TV र Roku 1920x1080 को आकारमा डिजाइन गरिएको छ, Android TV - 960x540, Smart TVs, विक्रेताको आधारमा, उस्तै छन्, तर कहिलेकाहीँ 1280x720। जब एप रेन्डर गरिन्छ र पूर्ण HD स्क्रिनहरूमा प्रदर्शित हुन्छ, 960 लाई 2 ले गुणन गरिन्छ, 1280 लाई 1,33 ले गुणन गरिन्छ, र 1920 लाई आउटपुट हुन्छ।

बोरिंग विवरणहरू छोड्दै, हामी निष्कर्षमा पुग्यौं कि सामान्यतया टेलिभिजन स्क्रिनहरू सहित सबै स्क्रिनहरू, तत्वहरू र तिनीहरूको आकारहरूको सन्दर्भमा, एउटै डिजाइन लेआउटद्वारा कभर हुन्छन्, र सबै टेलिभिजन स्क्रिनहरू सामान्य क्रस-प्लेटफर्म ग्रिडको विशेष केस हुन्। , र औसत ट्याब्लेट वा डेस्कटप जस्तै पाँच वा छवटा स्तम्भहरू समावेश गर्दछ। विवरणमा कसलाई रुचि छ, कमेन्टमा जानुहोस्।

सबै प्लेटफर्महरूको लागि एकल UI

अब, नयाँ सुविधा कोर्नको लागि, हामीले प्रत्येक प्लेटफर्मको लागि लेआउटहरू कोर्न आवश्यक छैन, साथै तिनीहरू प्रत्येकको लागि अनुकूलन विकल्पहरू। यो एक लेआउट देखाउन पर्याप्त छ र सबै प्लेटफर्महरू र कुनै पनि चौडाइका यन्त्रहरूको लागि यसको अनुकूलनता: फोनहरू - 320-599, अरू सबै - 600-1280।

डाटा → विकास

निस्सन्देह, हामी जति पूर्ण रूपमा एकीकृत डिजाइन प्राप्त गर्न चाहन्छौं, प्रत्येक प्लेटफर्मको आफ्नै अद्वितीय सुविधाहरू छन्। वेब र स्मार्ट टिभी दुबैले ReactJS + TypeScript स्ट्याक प्रयोग गरे तापनि, Smart TV एप लेगेसी WebKit र Presto क्लाइन्टहरूमा चल्छ र त्यसैले वेबसँग शैलीहरू साझा गर्न सक्दैन। र इमेल न्यूजलेटरहरू ट्याबुलर लेआउटको साथ काम गर्न बाध्य छन्। एकै समयमा, कुनै पनि गैर-एचटीएमएल प्लेटफर्महरू प्रयोग गर्ने वा प्रयोग गर्ने योजना गर्दैन रिएक्ट नेटिभ वा यसको कुनै पनि एनालगहरू, कार्यसम्पादनमा गिरावट आउने डरले, किनकि हामीसँग धेरै अनुकूलन लेआउटहरू, जटिल अद्यावधिक तर्कहरू, छविहरू र भिडियोहरू भएका संग्रहहरू छन्। त्यसकारण, तयार CSS शैलीहरू वा प्रतिक्रिया कम्पोनेन्टहरू वितरण गर्ने साझा योजना हाम्रो लागि उपयुक्त छैन। त्यसकारण, हामीले JSON ढाँचामा डाटा प्रसारण गर्ने निर्णय गर्यौं, मानहरूलाई सार घोषणात्मक रूपमा वर्णन गर्दै।

त्यसैले सम्पत्ति rounding: 8 Windows 10 एप मा रूपान्तरण गर्दछ CornerRadius="8", वेब - border-radius: 8px, एन्ड्रोइड - android:radius="8dp", iOS - self.layer.cornerRadius = 8.0.
सम्पत्ति offsetTop: 12 एउटै वेब क्लाइन्टले विभिन्न केसहरूमा व्याख्या गर्न सक्छ top, margin-top, padding-top वा transform

वर्णनको घोषणात्मकताले यो पनि संकेत गर्छ कि यदि प्लेटफर्मले प्राविधिक रूपमा सम्पत्ति वा यसको मूल्य प्रयोग गर्न सक्दैन भने, यसले यसलाई बेवास्ता गर्न सक्छ। शब्दावलीको सन्दर्भमा, हामीले एक प्रकारको एस्पेरान्तो भाषा बनायौं: केही एन्ड्रोइडबाट, केही SVG बाट, केही CSS बाट लिइएका हुन्।

यदि कुनै विशेष प्लेटफर्ममा तपाईंले तत्वहरू फरक रूपमा प्रदर्शन गर्न आवश्यक छ भने, हामीले फरक JSON फाइलको रूपमा सम्बन्धित डाटा उत्पादन स्थानान्तरण गर्ने क्षमता लागू गरेका छौं। उदाहरणका लागि, स्मार्ट टिभीको लागि "फोकसमा" स्थितिले पोस्टर अन्तर्गत पाठको स्थितिमा परिवर्तनलाई निर्देशन दिन्छ, जसको मतलब यो प्लेटफर्मको लागि "इन्डेन्ट" गुणको मूल्यमा रहेको यो घटकले आवश्यक 8 इन्डेन्टेसन बिन्दुहरू समावेश गर्दछ। यद्यपि यसले डिजाइन प्रणालीको पूर्वाधारलाई जटिल बनाउँछ, यसले स्वतन्त्रताको अतिरिक्त डिग्री दिन्छ, जसले हामीलाई प्लेटफर्महरूको दृश्य "असमानता" व्यवस्थापन गर्ने अवसर दिन्छ, र हामीले सिर्जना गरेको वास्तुकलालाई बन्धक बनाउँदैन।

Pictograms

डिजिटल उत्पादनमा आइकोनोग्राफी सधैं ठूलो हुन्छ र सरल उप-प्रोजेक्ट होइन, प्राय: छुट्टै डिजाइनर चाहिन्छ। त्यहाँ सधैं धेरै ग्लिफहरू छन्, तिनीहरूमध्ये प्रत्येकसँग धेरै आकार र रङहरू छन्, र प्लेटफर्महरूलाई सामान्यतया तिनीहरूलाई विभिन्न ढाँचाहरूमा चाहिन्छ। सामान्यतया, यो सबै डिजाइन प्रणाली मा राख्न को लागी कुनै कारण थिएन।

ग्लिफहरू SVG भेक्टर ढाँचामा लोड हुन्छन्, र रङ मानहरू स्वचालित रूपमा चरहरूसँग बदलिन्छन्। क्लाइन्ट एप्लिकेसनहरूले तिनीहरूलाई कुनै पनि ढाँचा र रङमा प्रयोग गर्न तयार प्राप्त गर्न सक्छन्।

पूर्वावलोकन

JSON डेटाको शीर्षमा, हामीले कम्पोनेन्टहरू पूर्वावलोकन गर्नको लागि एउटा उपकरण लेख्यौं - JS अनुप्रयोग जसले JSON डेटालाई यसको मार्कअप र शैली जेनेरेटरहरू मार्फत फ्लाईमा पास गर्छ, र ब्राउजरमा प्रत्येक कम्पोनेन्टको विभिन्न भिन्नताहरू प्रदर्शन गर्दछ। अनिवार्य रूपमा, पूर्वावलोकन प्लेटफर्म अनुप्रयोगहरूको रूपमा ठ्याक्कै उही क्लाइन्ट हो र उही डेटासँग काम गर्दछ।

एउटा विशेष कम्पोनेन्टले कसरी काम गर्छ भनेर बुझ्ने सबैभन्दा सजिलो तरिका यसको साथ अन्तरक्रिया गर्नु हो। त्यसकारण, हामीले स्टोरीबुक जस्ता उपकरणहरू प्रयोग गरेनौं, तर एक अन्तरक्रियात्मक पूर्वावलोकन बनायौं - तपाईंले छोउन, पोइन्ट गर्न, क्लिक गर्न सक्नुहुन्छ... डिजाइन प्रणालीमा नयाँ कम्पोनेन्ट थप्दा, यो पूर्वावलोकनमा देखा पर्दछ ताकि प्लेटफर्महरूमा ध्यान केन्द्रित गर्न केहि हुन्छ। यसलाई कार्यान्वयन गर्दै।

दस्तावेज

JSON को रूपमा प्लेटफर्महरूमा आपूर्ति गरिएको डाटाको आधारमा, कम्पोनेन्टहरूका लागि कागजातहरू स्वचालित रूपमा उत्पन्न हुन्छ। गुणहरूको सूची र तिनीहरूमध्ये प्रत्येकमा सम्भावित प्रकारका मानहरू वर्णन गरिएका छन्। स्वत: उत्पादन पछि, जानकारी म्यानुअल रूपमा स्पष्ट गर्न सकिन्छ र पाठ विवरण थप्न सकिन्छ। पूर्वावलोकन र कागजातहरू प्रत्येक कम्पोनेन्टको स्तरमा एक अर्कामा क्रस-रेफरेन्स गरिएका छन्, र कागजातमा समावेश गरिएका सबै जानकारीहरू थप JSON फाइलहरूको रूपमा विकासकर्ताहरूलाई उपलब्ध छन्।

अवहेलना गर्ने

अर्को आवश्यकता भनेको समयसँगै अवस्थित कम्पोनेन्टहरू प्रतिस्थापन र अद्यावधिक गर्ने क्षमता थियो। डिजाइन प्रणालीले विकासकर्ताहरूलाई कुन गुणहरू वा सम्पूर्ण कम्पोनेन्टहरू प्रयोग गर्न सकिँदैन भनेर बताउन र तिनीहरूलाई सबै प्लेटफर्महरूमा प्रयोग नगर्ने बित्तिकै हटाउन सिकेको छ। यस प्रक्रियामा अझै धेरै "म्यानुअल" श्रम छ, तर हामी स्थिर छैनौं।

ग्राहक विकास

निस्सन्देह, सबैभन्दा जटिल चरण हामीले समर्थन गर्ने सबै प्लेटफर्महरूको कोडमा डिजाइन प्रणाली डेटाको व्याख्या थियो। यदि, उदाहरणका लागि, वेबमा मोड्युलर ग्रिडहरू कुनै नयाँ कुरा होइनन्, तब आईओएस र एन्ड्रोइडका लागि नेटिभ मोबाइल अनुप्रयोगहरूका विकासकर्ताहरूले यससँग कसरी बाँच्ने भनेर पत्ता लगाउनु अघि कडा मेहनत गरे।

iOS अनुप्रयोग स्क्रिनहरू लेआउट गर्न, हामी iviUIKit द्वारा उपलब्ध गराइएका दुई आधारभूत संयन्त्रहरू प्रयोग गर्छौं: तत्वहरूको नि: शुल्क लेआउट र तत्वहरूको संग्रहको लेआउट। हामी VIPER प्रयोग गर्छौं, र iviUIKit सँगको सबै अन्तरक्रिया दृश्यमा केन्द्रित छ, र Apple UIKit सँगको अधिकांश अन्तरक्रिया iviUIKit मा केन्द्रित छ। तत्वहरूको आकार र व्यवस्था स्तम्भहरू र सिन्ट्याक्टिक संरचनाहरूको सन्दर्भमा निर्दिष्ट गरिएको छ जुन नेटिभ iOS SDK अवरोधहरूको शीर्षमा काम गर्दछ, तिनीहरूलाई थप व्यावहारिक बनाउँछ। UICollectionView सँग काम गर्दा यसले हाम्रो जीवनलाई विशेष गरी सरल बनायो। हामीले लेआउटका लागि धेरै अनुकूलन र्यापरहरू लेखेका छौं, धेरै जटिलहरू सहित। त्यहाँ न्यूनतम ग्राहक कोड थियो र यो घोषणात्मक भयो।

एन्ड्रोइड प्रोजेक्टमा शैलीहरू उत्पन्न गर्न, हामी XML ढाँचामा डिजाइन प्रणाली डेटालाई शैलीहरूमा परिणत गर्दै Gradle प्रयोग गर्छौं। एकै समयमा, हामीसँग विभिन्न स्तरका धेरै जेनरेटरहरू छन्:

• आधारभूत। उच्च स्तरका जेनरेटरहरूको लागि आदिमको डाटा पार्स गरिएको छ।
• स्रोत। तस्बिरहरू, आइकनहरू, र अन्य ग्राफिक्स डाउनलोड गर्नुहोस्।
• कम्पोनेन्ट। तिनीहरू प्रत्येक कम्पोनेन्टका लागि लेखिएका छन्, जसले कुन गुणहरू र तिनीहरूलाई शैलीहरूमा कसरी अनुवाद गर्ने भनेर वर्णन गर्दछ।

आवेदन विज्ञप्ति

डिजाइनरहरूले नयाँ कम्पोनेन्ट कोरिसकेपछि वा अवस्थित एकलाई पुन: डिजाइन गरेपछि, यी परिवर्तनहरू डिजाइन प्रणालीमा फिड हुन्छन्। प्रत्येक प्लेटफर्मका विकासकर्ताहरूले परिवर्तनहरूलाई समर्थन गर्न तिनीहरूको कोड जेनरेशनलाई राम्रो-ट्यून गर्दैछन्। यस पछि, यो नयाँ कार्यक्षमता को कार्यान्वयन मा प्रयोग गर्न सकिन्छ जहाँ यो घटक आवश्यक छ। यसैले, डिजाइन प्रणालीसँग अन्तरक्रिया वास्तविक समयमा हुँदैन, तर नयाँ रिलीजहरू जम्मा गर्ने समयमा मात्र। यो दृष्टिकोणले डेटा स्थानान्तरण प्रक्रियामा राम्रो नियन्त्रणको लागि अनुमति दिन्छ र ग्राहक विकास परियोजनाहरूमा कोड कार्यक्षमता सुनिश्चित गर्दछ।

परिणामहरू

डिजाइन प्रणाली Ivy अनलाइन सिनेमाको विकासलाई समर्थन गर्ने पूर्वाधारको हिस्सा बनेको एक वर्ष भइसक्यो, र हामी पहिले नै केही निष्कर्ष निकाल्न सक्छौं:

• यो एक ठूलो र जटिल परियोजना हो जसलाई निरन्तर समर्पित स्रोतहरू चाहिन्छ।
• यसले हामीलाई हाम्रो आफ्नै अद्वितीय क्रस-प्लेटफर्म भिजुअल भाषा सिर्जना गर्न अनुमति दियो जुन अनलाइन भिडियो सेवाको उद्देश्यहरू पूरा गर्दछ।
• हामीसँग अब दृश्यात्मक र कार्यात्मक रूपमा ढिलो हुने प्लेटफर्महरू छैनन्।

आइवी डिजाइन प्रणाली घटकहरूको पूर्वावलोकन - design.ivi.ru

स्रोत: www.habr.com