यूआय-किटपासून ते डिझाइन सिस्टमपर्यंत

आयव्ही ऑनलाइन सिनेमाचा अनुभव

जेव्हा 2017 च्या सुरुवातीला आम्ही आमची स्वतःची डिझाइन-टू-कोड वितरण प्रणाली तयार करण्याचा विचार केला, तेव्हा बरेच लोक आधीच याबद्दल बोलत होते आणि काही ते करत होते. तथापि, आजपर्यंत क्रॉस-प्लॅटफॉर्म डिझाइन सिस्टम तयार करण्याच्या अनुभवाबद्दल फारसे माहिती नाही आणि डिझाइन अंमलबजावणीच्या प्रक्रियेचे आधीच कार्यरत उत्पादनात अशा परिवर्तनासाठी तंत्रज्ञान आणि पद्धतींचे वर्णन करणारे कोणतेही स्पष्ट आणि सिद्ध पाककृती नाहीत. आणि "कोडमधील घटक" द्वारे त्यांचा अर्थ बर्‍याच वेगळ्या गोष्टी असतात.

दरम्यान, कंपनीने वर्षानुवर्षे आपले कर्मचारी दुप्पट केले - डिझाइन विभागाचे प्रमाण वाढवणे आणि विकासासाठी लेआउट तयार करणे आणि हस्तांतरित करण्याच्या प्रक्रियेस अनुकूल करणे आवश्यक होते. आम्ही हे सर्व प्लॅटफॉर्मच्या "प्राणीसंग्रहालय" द्वारे गुणाकार करतो ज्यांना समर्थन देणे आवश्यक आहे आणि आम्हाला बॅबिलोनियन पॅन्डेमोनिअमचे स्वरूप मिळते, जे "सामान्यपणे ते" करू शकत नाही आणि उत्पन्न मिळवू शकत नाही. प्लॅटफॉर्मचा विकास बर्‍याचदा समांतरपणे पुढे जात असे आणि तीच कार्यक्षमता अनेक महिन्यांच्या अंतराने वेगवेगळ्या प्लॅटफॉर्मवर सोडली जाऊ शकते.


प्रत्येक प्लॅटफॉर्मसाठी स्वतंत्र मांडणी संच

पारंपारिकपणे, आम्ही अशा समस्यांपासून सुरुवात केली ज्या डिझाईन प्रणाली सोडवण्यास मदत करेल आणि त्याच्या डिझाइनसाठी आवश्यकता तयार करेल. युनिफाइड व्हिज्युअल लँग्वेज तयार करणे, मांडणी आणि विकासाचा वेग वाढवणे आणि एकूणच उत्पादनाची गुणवत्ता सुधारणे यासोबतच डिझाइनला शक्य तितके एकत्रित करणे अत्यावश्यक होते. हे आवश्यक आहे जेणेकरून कार्यक्षमतेचा विकास आमच्या सर्व प्लॅटफॉर्मवर एकाच वेळी शक्य होईल: वेब, iOS, Android, स्मार्ट टीव्ही, tvOS, Android TV, Windows 10, xBox One, PS4, Roku - त्या प्रत्येकावर स्वतंत्रपणे कार्य न करता. आणि आम्ही ते केले!

डिझाइन → डेटा

जेव्हा उत्पादन आणि विकास विभागांमधील मूलभूत करार झाले, तेव्हा आम्ही एक तंत्रज्ञान स्टॅक निवडण्यासाठी बसलो आणि संपूर्ण प्रक्रियेचे तपशील तयार केले - लेआउटपासून प्रकाशनापर्यंत. डिझाईनला डेव्हलपमेंटमध्ये हस्तांतरित करण्याची प्रक्रिया पूर्णपणे स्वयंचलित करण्यासाठी, आम्ही लेआउटसह स्केच फाइल्समधून थेट घटक पॅरामीटर्स पार्स करण्याचा पर्याय शोधला. असे दिसून आले की आम्हाला आवश्यक असलेले कोडचे तुकडे शोधणे आणि आम्हाला आवश्यक असलेले पॅरामीटर्स काढणे हे एक जटिल आणि धोकादायक उपक्रम होते. प्रथम, डिझायनर्सना सोर्स कोडच्या सर्व स्तरांना नाव देण्यात अत्यंत सावधगिरी बाळगावी लागेल, दुसरे म्हणजे, हे फक्त सर्वात सोप्या घटकांसाठी कार्य करते आणि तिसरे म्हणजे, इतर कोणाच्या तंत्रज्ञानावर अवलंबून राहणे आणि मूळ स्केच लेआउटच्या कोड स्ट्रक्चरमुळे संपूर्ण भविष्य धोक्यात येते. प्रकल्प आम्ही या क्षेत्रातील ऑटोमेशन सोडण्याचा निर्णय घेतला. अशा प्रकारे डिझाईन सिस्टम टीममध्ये पहिली व्यक्ती दिसली, ज्याचे इनपुट डिझाइन लेआउट्स आहे आणि आउटपुट हा घटकांच्या सर्व पॅरामीटर्सचे वर्णन करणारा डेटा आहे आणि अणू डिझाइन पद्धतीनुसार श्रेणीबद्धपणे क्रमबद्ध आहे.

डेटा कुठे आणि कसा संग्रहित करायचा, डेव्हलपमेंटमध्ये कसा हस्तांतरित करायचा आणि आम्ही सपोर्ट करत असलेल्या सर्व प्लॅटफॉर्मवर डेव्हलपमेंटमध्ये त्याचा अर्थ कसा लावायचा एवढीच गोष्ट बाकी आहे. संध्याकाळ निस्तेज होणे थांबले... प्रत्येक प्लॅटफॉर्मवरील डिझाइनर आणि टीम लीड्सचा समावेश असलेल्या कार्यगटाच्या नियमित बैठकांचा परिणाम खालीलप्रमाणे करार होता.

आम्ही व्हिज्युअलला अणू घटकांमध्ये व्यक्तिचलितपणे पार्स करतो: फॉन्ट, रंग, पारदर्शकता, इंडेंट्स, गोलाकार, चिन्ह, चित्रे आणि अॅनिमेशनसाठी कालावधी. आणि आम्ही या बटणांमधून, इनपुट, चेकबॉक्सेस, बँक कार्ड विजेट्स इ. गोळा करतो. आम्ही चिन्हांशिवाय कोणत्याही स्तराच्या शैलींना गैर-अर्थपूर्ण नावे नियुक्त करतो, उदाहरणार्थ, शहरांची नावे, अप्सरांची नावे, पोकेमॉन, कार ब्रँड्स... फक्त एकच अट आहे - यादी आधी संपली जाऊ नये, शैली कशी संपेल - शो मस्ट गो! तुम्ही शब्दार्थासोबत वाहून जाऊ नये, जेणेकरून तुम्हाला "लहान" आणि "मध्यम" मधील मधले बटण जोडावे लागणार नाही.

दृश्य भाषा

सर्व प्लॅटफॉर्मला अनुकूल अशा प्रकारे डेटा कसा संग्रहित आणि हस्तांतरित करायचा याबद्दल विकासकांना विचार करणे बाकी होते आणि डिझाइनला इंटरफेस घटक डिझाइन करावे लागले जे चांगले दिसू शकतील आणि समर्थित डिव्हाइसेसच्या संपूर्ण फ्लीटमध्ये प्रभावीपणे कार्य करू शकतील.

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

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

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

आता आम्हाला सर्व मोठ्या स्क्रीन्स समान लेआउट आकारात आणण्याची आणि त्यांना एका सामान्य ग्रिडमध्ये बसवण्याची गरज आहे. ऍपल टीव्ही आणि रोकू 1920x1080, Android TV - 960x540, विक्रेत्यावर अवलंबून स्मार्ट टीव्ही समान आहेत, परंतु कधीकधी 1280x720 आकारात डिझाइन केलेले आहेत. जेव्हा अॅप पूर्ण HD स्क्रीनवर रेंडर केले जाते आणि प्रदर्शित केले जाते, तेव्हा 960 ला 2 ने गुणाकार केला जातो, 1280 ला 1,33 ने गुणाकार केला जातो आणि 1920 आउटपुट आहे.

कंटाळवाणा तपशील वगळून, आम्ही निष्कर्षापर्यंत पोहोचलो की सर्वसाधारणपणे टेलिव्हिजन स्क्रीन्ससह सर्व स्क्रीन, घटक आणि त्यांच्या आकाराच्या बाबतीत, एका डिझाइन लेआउटने कव्हर केल्या जातात आणि सर्व टेलिव्हिजन स्क्रीन सामान्य क्रॉस-प्लॅटफॉर्म ग्रिडचे एक विशेष प्रकरण आहेत, आणि सरासरी टॅबलेट किंवा डेस्कटॉपप्रमाणे पाच किंवा सहा स्तंभांचा समावेश होतो. तपशीलांमध्ये कोणाला स्वारस्य आहे, टिप्पण्यांमध्ये जा.

सर्व प्लॅटफॉर्मसाठी एकल UI

आता, नवीन वैशिष्ट्य काढण्यासाठी, आम्हाला प्रत्येक प्लॅटफॉर्मसाठी लेआउट, तसेच प्रत्येकासाठी अनुकूलता पर्याय काढण्याची आवश्यकता नाही. सर्व प्लॅटफॉर्म आणि कोणत्याही रुंदीच्या डिव्हाइसेससाठी एक लेआउट आणि त्याची अनुकूलता दर्शविणे पुरेसे आहे: फोन - 320-599, बाकी सर्व - 600-1280.

डेटा → विकास

अर्थात, आम्‍हाला जेवढे पूर्णत: युनिफाइड डिझाईन मिळवायचे आहे, तितकेच प्रत्येक प्‍लॅटफॉर्मची स्वतःची खास वैशिष्ट्ये आहेत. वेब आणि स्मार्ट टीव्ही दोन्ही ReactJS + TypeScript स्टॅक वापरत असले तरीही, स्मार्ट टीव्ही अॅप लेगेसी वेबकिट आणि प्रेस्टो क्लायंटवर चालतो आणि त्यामुळे वेबसह शैली शेअर करू शकत नाही. आणि ईमेल वृत्तपत्रे पूर्णपणे सारणी मांडणीसह कार्य करण्यास भाग पाडतात. त्याच वेळी, आमच्याकडे खूप सानुकूल मांडणी, जटिल अपडेट लॉजिक, प्रतिमा आणि व्हिडिओ असलेले संग्रह असल्यामुळे, कार्यक्षमतेत ऱ्हास होण्याच्या भीतीने, html नसलेले कोणतेही प्लॅटफॉर्म रिऍक्ट नेटिव्ह किंवा त्याचे कोणतेही अॅनालॉग वापरत नाहीत किंवा वापरण्याची योजना करत नाहीत. त्यामुळे, तयार सीएसएस शैली किंवा प्रतिक्रिया घटक वितरित करण्याची सामान्य योजना आमच्यासाठी योग्य नाही. म्हणून, आम्ही अमूर्त घोषणात्मक स्वरूपात मूल्यांचे वर्णन करून 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

वर्णनाची घोषणात्मकता हे देखील सूचित करते की जर प्लॅटफॉर्म तांत्रिकदृष्ट्या मालमत्ता किंवा त्याचे मूल्य वापरू शकत नसेल तर ते त्याकडे दुर्लक्ष करू शकते. शब्दावलीच्या संदर्भात, आम्ही एक प्रकारची एस्पेरांतो भाषा बनवली: काही Android वरून, काही SVG वरून, काही CSS वरून.

एखाद्या विशिष्ट प्लॅटफॉर्मवर तुम्हाला घटक वेगळ्या पद्धतीने प्रदर्शित करायचे असल्यास, आम्ही संबंधित डेटा जनरेशन वेगळ्या JSON फाइलच्या स्वरूपात हस्तांतरित करण्याची क्षमता लागू केली आहे. उदाहरणार्थ, स्मार्ट टीव्हीसाठी "इन फोकस" स्थिती पोस्टरखालील मजकुराच्या स्थितीत बदल दर्शवते, याचा अर्थ या प्लॅटफॉर्मसाठी "इंडेंट" गुणधर्माच्या मूल्यातील या घटकामध्ये आवश्यक असलेले 8 इंडेंटेशन पॉइंट असतील. जरी हे डिझाइन सिस्टमच्या पायाभूत सुविधांना गुंतागुंतीत करते, तरीही ते अतिरिक्त प्रमाणात स्वातंत्र्य देते, ज्यामुळे आम्हाला प्लॅटफॉर्मची व्हिज्युअल "असमानता" व्यवस्थापित करण्याची संधी मिळते आणि आम्ही तयार केलेल्या आर्किटेक्चरला ओलिस न ठेवता.

चित्रे

डिजिटल उत्पादनातील आयकॉनोग्राफी हा नेहमीच मोठा असतो आणि सर्वात सोपा सबप्रोजेक्ट नसतो, ज्यासाठी अनेकदा स्वतंत्र डिझायनरची आवश्यकता असते. तेथे नेहमीच भरपूर ग्लिफ असतात, त्या प्रत्येकाचे अनेक आकार आणि रंग असतात आणि प्लॅटफॉर्मला सामान्यत: वेगवेगळ्या स्वरूपात त्यांची आवश्यकता असते. सर्वसाधारणपणे, हे सर्व डिझाइन सिस्टममध्ये न ठेवण्याचे कोणतेही कारण नव्हते.

ग्लिफ SVG वेक्टर फॉरमॅटमध्ये लोड केले जातात आणि रंग मूल्ये स्वयंचलितपणे व्हेरिएबल्ससह बदलली जातात. क्लायंट ऍप्लिकेशन्स त्यांना वापरण्यासाठी तयार प्राप्त करू शकतात - कोणत्याही स्वरूपात आणि रंगात.

पूर्वावलोकन

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

एखादा विशिष्ट घटक कसा कार्य करतो हे समजून घेण्याचा सर्वात सोपा मार्ग म्हणजे त्याच्याशी संवाद साधणे. म्हणून, आम्ही स्टोरीबुक सारख्या साधनांचा वापर केला नाही, परंतु परस्परसंवादी पूर्वावलोकन केले - तुम्ही स्पर्श करू शकता, पॉइंट करू शकता, क्लिक करू शकता... डिझाइन सिस्टममध्ये नवीन घटक जोडताना, ते पूर्वावलोकनात दिसते, जेणेकरून प्लॅटफॉर्मवर लक्ष केंद्रित करण्यासाठी काहीतरी असेल. त्याची अंमलबजावणी करताना.

दस्तऐवजीकरण

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

निरुपयोगी

आणखी एक गरज म्हणजे कालांतराने विद्यमान घटक पुनर्स्थित आणि अद्यतनित करण्याची क्षमता. डिझाईन सिस्टीमने विकासकांना सांगायला शिकले आहे की कोणते गुणधर्म किंवा अगदी संपूर्ण घटक वापरले जाऊ शकत नाहीत आणि ते सर्व प्लॅटफॉर्मवर वापरले जाणार नाहीत म्हणून ते काढून टाका. या प्रक्रियेत अजूनही बरेच "मॅन्युअल" श्रम आहेत, परंतु आम्ही स्थिर नाही.

ग्राहक विकास

निःसंशयपणे, आम्ही समर्थन करत असलेल्या सर्व प्लॅटफॉर्मच्या कोडमधील डिझाइन सिस्टम डेटाचे स्पष्टीकरण हा सर्वात जटिल टप्पा होता. उदाहरणार्थ, वेबवरील मॉड्यूलर ग्रिड काही नवीन नसल्यास, iOS आणि Android साठी नेटिव्ह मोबाइल अॅप्लिकेशन्सच्या विकसकांनी त्यासह कसे जगायचे हे शोधण्यापूर्वी कठोर परिश्रम केले.

iOS ऍप्लिकेशन स्क्रीनचे लेआउट करण्यासाठी, आम्ही iviUIKit द्वारे प्रदान केलेल्या दोन मूलभूत यंत्रणा वापरतो: घटकांचे विनामूल्य लेआउट आणि घटकांच्या संग्रहांचे लेआउट. आम्ही VIPER वापरतो आणि iviUIKit सह सर्व परस्परसंवाद दृश्यामध्ये केंद्रित आहे आणि Apple UIKit सोबतचा बहुतांश संवाद iviUIKit मध्ये केंद्रित आहे. घटकांचे आकार आणि मांडणी स्तंभ आणि सिंटॅक्टिक स्ट्रक्चर्सच्या संदर्भात निर्दिष्ट केली आहे जी मूळ iOS SDK मर्यादांवर कार्य करतात, त्यांना अधिक व्यावहारिक बनवतात. UICollectionView सह काम करताना हे विशेषतः आमचे जीवन सोपे करते. आम्‍ही लेआउटसाठी अनेक सानुकूल रॅपर लिहिले आहेत, ज्यात बरेच जटिल आहेत. किमान क्लायंट कोड होता आणि तो घोषणात्मक झाला.

अँड्रॉइड प्रोजेक्टमध्ये शैली निर्माण करण्यासाठी, आम्ही ग्रेडल वापरतो, डिझाइन सिस्टम डेटा XML फॉरमॅटमध्ये शैलींमध्ये बदलतो. त्याच वेळी, आमच्याकडे विविध स्तरांचे अनेक जनरेटर आहेत:

• बेसिक. उच्च स्तरीय जनरेटरसाठी आदिम डेटाचे विश्लेषण केले जाते.
• संसाधन. चित्रे, चिन्ह आणि इतर ग्राफिक्स डाउनलोड करा.
• घटक. ते प्रत्येक घटकासाठी लिहिलेले आहेत, जे कोणत्या गुणधर्मांचे वर्णन करतात आणि त्यांचे शैलींमध्ये कसे भाषांतर करावे.

अनुप्रयोग प्रकाशन

डिझायनर्सनी नवीन घटक काढल्यानंतर किंवा विद्यमान घटक पुन्हा डिझाइन केल्यानंतर, हे बदल डिझाइन सिस्टममध्ये दिले जातात. प्रत्येक प्लॅटफॉर्मचे डेव्हलपर बदलांना समर्थन देण्यासाठी त्यांच्या कोड जनरेशनला चांगले ट्यून करत आहेत. यानंतर, या घटकाची आवश्यकता असलेल्या नवीन कार्यक्षमतेच्या अंमलबजावणीमध्ये याचा वापर केला जाऊ शकतो. अशा प्रकारे, डिझाइन सिस्टमसह परस्परसंवाद रिअल टाइममध्ये होत नाही, परंतु केवळ नवीन रिलीझ एकत्र करताना. हा दृष्टीकोन डेटा ट्रान्सफर प्रक्रियेवर चांगले नियंत्रण ठेवण्यास देखील अनुमती देतो आणि क्लायंट डेव्हलपमेंट प्रकल्पांमध्ये कोड कार्यक्षमता सुनिश्चित करतो.

परिणाम

आयव्ही ऑनलाइन सिनेमाच्या विकासाला आधार देणाऱ्या पायाभूत सुविधांचा भाग बनून डिझाईन सिस्टीमला एक वर्ष झाले आहे आणि आम्ही आधीच काही निष्कर्ष काढू शकतो:

• हा एक मोठा आणि जटिल प्रकल्प आहे ज्यासाठी सतत समर्पित संसाधनांची आवश्यकता असते.
• यामुळे आम्हाला ऑनलाइन व्हिडिओ सेवेच्या उद्दिष्टांची पूर्तता करणारी आमची स्वतःची अनोखी क्रॉस-प्लॅटफॉर्म व्हिज्युअल भाषा तयार करण्याची परवानगी मिळाली.
• आमच्याकडे यापुढे व्हिज्युअल आणि फंक्शनली लॅगिंग प्लॅटफॉर्म नाहीत.

आयव्ही डिझाइन सिस्टम घटकांचे पूर्वावलोकन - design.ivi.ru

स्त्रोत: www.habr.com