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

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

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

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


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

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

डिज़ाइन → डेटा

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

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

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

दृश्य भाषा

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

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

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

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

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

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

सभी प्लेटफ़ॉर्म के लिए एकल यूआई

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

डेटा → विकास

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

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

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

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

चित्रलेख

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

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

पूर्वावलोकन

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

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

अभिलेख

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

निंदा करनेवाला

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

ग्राहक विकास

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

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

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

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

एप्लिकेशन जारी

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

परिणाम

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

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

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

स्रोत: www.habr.com