यूआई-किट से लेकर डिजाइन सिस्टम तक

आइवी ऑनलाइन मूवी अनुभव

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


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


प्रत्येक प्लेटफ़ॉर्म के लिए अलग लेआउट सेट

परंपरागत रूप से, हमने उन समस्याओं के साथ शुरुआत की जो डिजाइन प्रणाली को हल करने में मदद करेगी और इसके डिजाइन के लिए आवश्यकताओं को तैयार करेगी। एकल दृश्य भाषा बनाने के अलावा, प्रोटोटाइप और विकास की गति को बढ़ाना, उत्पाद की गुणवत्ता में समग्र रूप से सुधार करना, जितना संभव हो उतना डिजाइन को एकजुट करना आवश्यक था। यह आवश्यक है ताकि कार्यक्षमता का विकास हमारे सभी प्लेटफार्मों पर एक साथ तुरंत संभव हो सके: वेब, आईओएस, एंड्रॉइड, स्मार्ट टीवी, टीवीओएस, एंड्रॉइड टीवी, विंडोज 10, एक्सबॉक्स वन, पीएस 4, रोकू - उनमें से प्रत्येक पर व्यक्तिगत रूप से काम किए बिना। । और हमने यह किया!

डिजाइन → डेटा

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

मामला छोटा रहा: डेटा को कहां और कैसे स्टोर करना है, इसे विकास में कैसे स्थानांतरित करना है, और हमारे द्वारा समर्थित सभी प्लेटफार्मों पर विकास में इसकी व्याख्या कैसे करें। शाम ख़त्म हो गई ... वर्किंग ग्रुप की नियमित बैठकों का नतीजा, प्रत्येक मंच से डिजाइनरों और टीम के नेताओं से मिलकर, निम्नलिखित पर समझौता हुआ।

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

दृश्य भाषा

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

इससे पहले, हम विंडोज 10 के लिए एक एप्लिकेशन में अधिकांश डिजाइन तत्वों को "रन" के माध्यम से प्रबंधित करते थे, जो उस समय हमारे लिए एक नया मंच था, अर्थात्, खरोंच से प्रतिपादन और विकास की आवश्यकता थी। इसे चित्रित करके, हम अधिकांश घटकों को तैयार करने और उनका परीक्षण करने में सक्षम थे और यह समझने में सक्षम थे कि उनमें से कौन से भविष्य के आइवी डिज़ाइन सिस्टम में शामिल किए जाने थे। सैंडबॉक्स के बिना, इस तरह के अनुभव को पहले से ही काम कर रहे प्लेटफार्मों पर बड़ी संख्या में पुनरावृत्तियों द्वारा प्राप्त किया जा सकता है, और इसमें एक वर्ष से अधिक समय लगेगा।

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

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


अब आपको सभी बड़े स्क्रीन को लेआउट के समान आकार में लाने और उन्हें सामान्य ग्रिड में फिट करने की आवश्यकता है। ऐप्पल टीवी और रोकु को 1920x1080 के आकार में विकसित किया जा रहा है, एंड्रॉइड टीवी - 960x540, स्मार्ट टीवी, विक्रेता के आधार पर वे समान हैं, और 1280x720 हैं। जब एप्लिकेशन पूर्ण HD स्क्रीन पर प्रस्तुत और प्रदर्शित होता है, तो 960 को 2 से गुणा करके, 1280 को 1.33 से, और 1920 के रूप में प्रदर्शित किया जाता है।

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


सभी प्लेटफार्मों के लिए एकीकृत यूआई

अब, एक नई सुविधा बनाने के लिए, हमें प्रत्येक प्लेटफॉर्म के लिए लेआउट बनाने की आवश्यकता नहीं है, साथ ही उनमें से प्रत्येक के लिए अनुकूलन क्षमता विकल्प भी हैं। यह किसी भी चौड़ाई के सभी प्लेटफार्मों और उपकरणों के लिए एक लेआउट और इसकी अनुकूलन क्षमता दिखाने के लिए पर्याप्त है: फोन - 320–599, बाकी सब - 600-1280।

डेटा → विकास

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

तो rounding: 8 की संपत्ति rounding: 8 , विंडोज 10 एप्लिकेशन CornerRadius="8" , वेब - border-radius: 8px , एंड्रॉइड - android:radius="8dp" , आईओएस - self.layer.cornerRadius = 8.0 ।
ऑफसेटसेट offsetTop: 12 एक ही वेब क्लाइंट को अलग-अलग मामलों में top , margin-top , padding-top या transform रूप में समझा जा सकता है।

विवरण की घोषणात्मक प्रकृति यह भी बताती है कि यदि मंच तकनीकी रूप से किसी भी संपत्ति या उसके मूल्य का उपयोग करने में असमर्थ है, तो वह इसे अनदेखा कर सकता है। शब्दावली के संदर्भ में, हमने एक तरह की एस्पेरान्तो भाषा बनाई: हमने एंड्रॉइड से कुछ लिया, एसवीजी से कुछ, सीएसएस से कुछ।

यदि किसी विशेष प्लेटफ़ॉर्म पर अलग तरीके से तत्वों को प्रदर्शित करना आवश्यक है, तो हमने संबंधित डेटा पीढ़ी को एक अलग एलएसएन फ़ाइल के रूप में स्थानांतरित करने की क्षमता को लागू किया है। उदाहरण के लिए, राज्य स्मार्ट टीवी के लिए "फोकस में" है, यह पोस्टर के नीचे पाठ की स्थिति में बदलाव को निर्देशित करता है, इसलिए इस प्लेटफॉर्म के लिए "इंडेंट" संपत्ति के मूल्य में इस घटक में 8 इंडेंट बिंदुओं की आवश्यकता होगी। यद्यपि यह डिजाइन प्रणाली के बुनियादी ढांचे को जटिल करता है, यह एक अतिरिक्त डिग्री की स्वतंत्रता देता है, जिससे हमें प्लेटफार्मों के दृश्य "असमानता" का प्रबंधन करने का अवसर मिलता है, और हमारे द्वारा बनाई गई वास्तुकला के लिए बंधक नहीं बन सकता है।

pictograms

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


ग्लिफ़ को वेक्टर SVG प्रारूप में लोड किया जाता है, और रंग मानों को स्वचालित रूप से चर के साथ बदल दिया जाता है। क्लाइंट एप्लिकेशन उन्हें किसी भी प्रारूप और रंग में - उपयोग करने के लिए तैयार कर सकते हैं।

पूर्वावलोकन

डेटा के साथ JSON के शीर्ष पर, हमने घटकों के पूर्वावलोकन के लिए एक उपकरण लिखा - एक जेएस एप्लिकेशन जो मक्खी पर अपने मार्कअप और स्टाइल जनरेटर के माध्यम से JSON डेटा को पारित करता है और ब्राउज़र में प्रत्येक घटक के विभिन्न रूपों को प्रदर्शित करता है। वास्तव में, पूर्वावलोकन बिल्कुल प्लेटफ़ॉर्म अनुप्रयोगों के समान क्लाइंट है, और समान डेटा के साथ काम करता है।

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

प्रलेखन

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

Deprekator

एक और जरूरत मौजूदा घटकों को समय के साथ बदलने और उन्नत करने की थी। डिज़ाइन सिस्टम ने डेवलपर्स को यह बताने के लिए सीखा है कि कौन से गुणों या पूरे घटकों का उपयोग नहीं किया जा सकता है और जैसे ही वे सभी प्लेटफार्मों पर उपयोग नहीं किए जाते हैं उन्हें हटा दें। इस प्रक्रिया में अभी भी बहुत सारे "मैनुअल" श्रम हैं, लेकिन हम अभी भी खड़े नहीं हैं।

ग्राहक विकास

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

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

एंड्रॉइड प्रोजेक्ट में शैलियों को उत्पन्न करने के लिए, हम ग्रैडल का उपयोग करते हैं, डिजाइन सिस्टम डेटा को XML प्रारूप शैलियों में बदलते हैं। इसी समय, हमारे पास विभिन्न स्तरों के कई जनरेटर हैं:

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

आवेदन जारी

डिजाइनरों द्वारा एक नया घटक तैयार करने या किसी मौजूदा को फिर से तैयार करने के बाद, ये परिवर्तन डिज़ाइन सिस्टम में आते हैं। प्रत्येक प्लेटफ़ॉर्म के डेवलपर अपनी कोड पीढ़ी को अंतिम रूप दे रहे हैं, जो परिवर्तनों के लिए समर्थन प्रदान कर रहे हैं। उसके बाद, इसका उपयोग नई कार्यक्षमता के कार्यान्वयन में किया जा सकता है, जहां यह घटक आवश्यक है। इस प्रकार, डिजाइन प्रणाली के साथ बातचीत वास्तविक समय में नहीं होती है, बल्कि केवल नए रिलीज को इकट्ठा करने के समय होती है। यह दृष्टिकोण आपको डेटा स्थानांतरण की प्रक्रिया को बेहतर ढंग से नियंत्रित करने की अनुमति देता है और ग्राहक विकास परियोजनाओं में कोड के प्रदर्शन की गारंटी देता है।

परिणाम

जल्द ही, एक डिजाइन प्रणाली के रूप में, एक वर्ष आईवी ऑनलाइन सिनेमा के विकास की सेवा करने वाले बुनियादी ढांचे का एक हिस्सा बन गया, और कुछ निष्कर्ष पहले ही निकाले जा सकते हैं:

• यह लागू करने के लिए एक बड़ी और कठिन परियोजना है, जिसके लिए निरंतर आवंटित संसाधनों की आवश्यकता होती है।
• इसने हमें अपनी अनूठी क्रॉस-प्लेटफ़ॉर्म दृश्य भाषा बनाने की अनुमति दी जो ऑनलाइन वीडियो सेवा के उद्देश्यों को पूरा करती है।
• अब हमारे पास नेत्रहीन और कार्यात्मक रूप से लैगिंग प्लेटफ़ॉर्म नहीं हैं।

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