💓 🙋🏽 👩🏿‍💼 स्केच और एक Node.js स्क्रिप्ट के साथ मल्टी-ब्रांड मल्टी-प्लेटफ़ॉर्म आइकन बनाना

टीएल, डॉ

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

ठीक है, वास्तव में यह इतना आसान नहीं है, लेकिन यह निश्चित रूप से किया जा सकता है। यह पोस्ट एक विस्तृत विवरण है कि हमने इसे कैसे किया, और हमने रास्ते में क्या खोज की।

जिस समस्या को हम सुलझाने की कोशिश कर रहे थे

Badoo पर हम एक डेटिंग ऐप बनाते हैं। दरअसल, कई डेटिंग ऐप। कई टीमों के लिए कई प्लेटफार्मों ( iOS , Android , Mobile Web , Desktop Web ) के लिए।

हम अपने ऐप्स में सैकड़ों आइकन का उपयोग करते हैं। उनमें से कुछ अलग-अलग ऐप में समान हैं, कुछ उन ब्रांडों के लिए बहुत विशिष्ट हैं जो ऐप प्रतिबिंबित करते हैं। प्रतीक लगातार विकसित हो रहे हैं, डिजाइन के विकास के साथ सिंक में। कभी-कभी पूरी तरह से नए आइकन जोड़ दिए जाते हैं, जबकि अन्य अपडेट हो जाते हैं, और अभी भी दूसरों को गिरा दिया जाता है (हालांकि, वे अक्सर कोडबेस में रहते हैं)।

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

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

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

तो, उनका अगला सवाल (और अनुरोध) था: क्या आप संपत्ति के लिए कुछ ऐसा ही कर सकते हैं? और हमारा जवाब था: हाँ, हम (शायद) कर सकते हैं!

यह उस समय विश्वास की एक छलांग थी, मुझे स्वीकार करना होगा। यह कैसे करना है, इसके बारे में हमारे पास कुछ विचार थे, लेकिन तकनीकी रूप से यह संभव नहीं था कि हम सभी प्रतिबंधों के तहत काम करें। हम एमवीपी परियोजना के साथ शुरू करने के लिए सहमत हुए, लेकिन अंत तक सब कुछ इतना अच्छा हो गया कि यह हमारा अंतिम उत्पाद बन गया, सभी आवश्यक सुविधाओं के साथ।

आवश्यकताओं

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

यह जटिल है क्योंकि, हमारे उत्पादों में, एक आइकन में विभिन्न ब्रांडों / सफेद-लेबल के लिए कई अलग-अलग रंग और / या अलग-अलग आकार हो सकते हैं (हालांकि ऐप का कोडबेस समान है, साथ ही साथ आइकन का नाम भी है)।

हमारे अनुप्रयोगों में उपयोग किए गए कुछ आइकन देखें और आप देखेंगे कि कुछ समान हैं, कुछ एक-दूसरे के समान हैं, लेकिन कुछ विवरणों के लिए, जबकि अन्य काफी अलग हैं, दोनों अपने आकार और रंगों में:

विभिन्न ब्रांडों के लिए आइकन की तुलना

अब, आइकन में उपयोग किए जाने वाले रंग न केवल सादे रंग हैं, बल्कि उस ब्रांड और इसके विशिष्ट विशेषताओं के लिए डिज़ाइन टोकन में वर्णित सटीक रंगों से मेल खाते हैं:

विभिन्न ब्रांडों में रंगों की तुलना। रंग मान डिज़ाइन टोकन के रूप में निर्दिष्ट किए जाते हैं।

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

स्केच और स्केचटूल

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

तथ्य यह है कि, परियोजना की शुरुआत में हम यह भी सुनिश्चित नहीं कर रहे थे कि प्लेटफ़ॉर्म की अंतिम प्रारूप क्या उम्मीद कर रहे थे। हमारे दिमाग में, यह प्रक्रिया इस तरह से बहुत बुनियादी होने जा रही थी: स्केच फ़ाइल से SVG प्रारूप में आइकन निर्यात करें और फिर मोबाइल वेब और एंड्रॉइड में SVG फ़ाइलों का उपभोग करें, और iOS के लिए एक लाइब्रेरी ढूंढें जो SVGs को PDF में बदल सकती है। और वह यह है। वह योजना थी जब हमने शुरू किया था, हालांकि हमें नहीं पता था कि यह काम करेगा या अज्ञात अज्ञात लोगों के बारे में हमारा सामना हो सकता है (इसलिए, एमवीपी यह देखने के लिए कि क्या यह भी संभव था, और, यदि हां, तो यह कितना प्रयास हो सकता है )।

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

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

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

एक स्केच फ़ाइल की आंतरिक संरचना, एक बार असम्पीडित

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

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

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

{ "_class": "sharedStyle", "do_objectID": "49BA4E98-8D63-435C-81D9-E2F6CDB63136", "name": "name-of/the-style", "value": {     "_class": "style",     "endMarkerType": 0,     "fills": [         {             "_class": "fill",             "isEnabled": true,             "color": {                 "_class": "color",                 "alpha": 1,                 "blue": 0.7176470588235294,                 "green": 0.4627450980392159,                 "red": 0             },             "fillType": 0,             "noiseIndex": 0,             "noiseIntensity": 0,             "patternFillType": 1,             "patternTileScale": 1         }     ],     "miterLimit": 10,     "startMarkerType": 0,     "windingRule": 1 } }

इसने मुझे एक विचार दिया: कि शायद हम कलाकृतियों और पृष्ठों के नामों पर विशिष्ट सम्मेलनों का उपयोग कर सकते हैं, विभिन्न परिसंपत्तियों के बीच संबंधों के बारे में कुछ प्रकार की मेटा-जानकारी की घोषणा कर सकते हैं, और निर्माण समय पर उन्हें प्रोग्रामेटिक रूप से उपयोग कर सकते हैं।

Sketchtool

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

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

स्केचटूल एक आधिकारिक स्केच टूल (आधिकारिक रूप में: बोहेमियन कोडिंग द्वारा विकसित) है, जो प्रलेखन के अनुसार है :

... एक कमांड लाइन उपयोगिता है जिसे स्केच के साथ बांधा गया है, जो आपको स्केच दस्तावेजों के साथ कुछ संचालन करने की अनुमति देता है, जैसे कि उनका निरीक्षण करना या संपत्ति का निर्यात करना। यह आपको कमांड लाइन से स्केच को कुछ क्रिया करने के लिए नियंत्रित करता है (उदाहरण के लिए, रनिंग प्लग इन जैसे)।

रुको ... संपत्ति के निर्यात की तरह संचालन करने के लिए एक कमांड लाइन उपयोगिता ? बस, मैं क्या देख रहा था! इसके अलावा, एक आधिकारिक उपकरण होने के नाते, संस्करण, अप्रचलन, रखरखाव आदि की कोई समस्या नहीं होगी।

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

स्केचटूल को सीधे स्केच के साथ बांधा जाता है, और आप इसे स्केच के अंदर इस पथ पर पा सकते हैं: Sketch.app/Contents/Resources/sketchtool/ / Sketch.app/Contents/Resources/sketchtool/ / Sketch.app/Contents/Resources/sketchtool/ / Sketch.app/Contents/Resources/sketchtool/

जब आप इसे अपने CLI में कमांड के साथ लॉन्च करते हैं:
$ /Applications/Sketch.app/Contents/Resources/sketchtool/bin/sketchtool

यह वह आउटपुट है जिसे आप अपने टर्मिनल पर देखते हैं (मैंने इसे थोड़ा सरल किया है):

 Usage: sketchtool <command> [<args>] [--formats=<string>] [--use-id-for-name{=YES|NO}] [--export-page-as-fallback{=YES|NO}] [--serial{=YES|NO}] [--context=<string>] [--application=<path>] [--without-activating{=YES|NO}] [--item=<string>] [--items=<string>] [--safemode{=YES|NO} | --no-safemode | -S {<YES|NO>}] [--max-size=<float> | -m <float>] [--background=<string> | -g <string>] [--compression=<float> | -c <float>] [--new-instance{=YES|NO}] [--reveal{=YES|NO}] [--timeout=<float>] [--include-symbols{=YES|NO}] [--bounds=<rectangle>] [--outputJSON=<path>] [--filename=<string>] [--wait-for-exit{=YES|NO}] [--scales=<path>] [--overwriting{=YES|NO}] [--group-contents-only{=YES|NO}] [--trimmed{=YES|NO}] [--help] [--progressive{=YES|NO}] [--save-for-web{=YES|NO}] [--output=<path>] Commands: dump               Dump out the structure of a document as JSON. export artboards  Export one or more artboards export layers     Export one or more layers export pages      Export an area from one or more pages export preview    Export a preview image for a document export slices     Export one or more slices help              Show this help message. list artboards    List information on the document's artboards. list formats      List the supported export formats. list layers       List information on all of the document's layers. list pages        List information on the document's pages. list slices       List information on the document's slices. metadata          List the metadata for a document. run               Run a command from a plugin, inside Sketch. show              Show the location of the various sketch folders. See 'sketchtool help <command>' for more information on a specific command.

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

स्केच में "निर्यात" पैनल, उपलब्ध विकल्पों के साथ

इसका मतलब यह है कि स्केच को सीधे बाहरी कन्वर्टर्स (एसवीजी से पीएनजी या पीडीएफ तक) की आवश्यकता के बिना, स्केचटूल के माध्यम से निर्यात "इंजन" के रूप में इस्तेमाल किया जा सकता है। बड़ी बात!

स्केचटूल और एक सरल स्केच फ़ाइल का उपयोग करके कुछ आइकन के साथ एक त्वरित परीक्षण ने सभी प्रारंभिक अनुमानों की पुष्टि की: बस इस सरल उपकरण का उपयोग करके, हम तीसरे पक्ष के निर्यातकों का उपयोग करने और अपने स्वयं के कस्टम निर्यातकों के निर्माण से बच सकते हैं: स्केच यह सब करता है!

स्केच फ़ाइल

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

प्रारंभ में, हमने केवल एक सीमित सेट के साथ काम करने की योजना बनाई, जो कि एमवीपी परियोजना के लिए थे, लेकिन हमने जल्दी से महसूस किया कि इन सबको एक बार में एकत्र करना बेहतर होगा, तुरंत डुप्लिकेट, असंगतता, किसी भी चूक, आदि

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

स्केच फ़ाइल का अवलोकन जिसमें हमारे एप्लिकेशन में उपयोग किए गए आइकन हैं।

फ़ाइल में, प्रत्येक आइकन का अपना आर्टबोर्ड होता है, जिसे आइकन के वांछित नाम के साथ नामित किया जाता है (बाद में संपत्ति का निर्यात करते समय स्केच द्वारा फ़ाइल नाम के रूप में उपयोग किया जाता है)।

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

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

शेयर्ड स्टाइल्स (और डिज़ाइन टोकन) के साथ आइकनों को गतिशील रंग देना

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

इस तरह से एक शैली को परत पर लागू किया जाता है:

पूर्व-परिभाषित शैली (रंग भरें) के साथ स्केच में परत।

और इस तरह से शैलियों को घोषित किया जाता है और फिर एक तत्व पर लागू किया जाता है:

हमने स्केच में शैलियों को व्यवस्थित करने का फैसला कैसे किया है

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

एबी परीक्षण के लिए उपयोग किए गए पृष्ठ और आर्टबोर्ड नाम

इस बिंदु पर, यह समझने का समय था कि डिजाइनरों को आइकनों पर एबी परीक्षण करने में सक्षम कैसे सुनिश्चित किया जाएगा। एक बार फिर, अंत में हम सम्मेलनों (यहाँ KISS का बड़ा प्रशंसक) नामकरण पर भरोसा करने का फैसला किया।

इस मामले में, हमने पता लगाने के लिए पृष्ठ नामों का उपयोग किया था जब माउस का एक सेट एक एबी परीक्षण / प्रयोग (" XP_" उपसर्ग के रूप में) और एबीबोर्ड परीक्षण किस संपत्ति का उल्लेख कर रहा था, और इसके अलग-अलग वेरिएंट ( चौकोर कोष्ठक के भीतर संलग्न)।

पेज और आर्टबोर्ड पर नामकरण सम्मेलन का उपयोग एक एबी परीक्षण को "घोषित" करने के लिए कैसे किया जाता है। सूचना: प्रतीक विशेष रूप से परीक्षण उद्देश्यों के लिए बनाए गए उदाहरण मात्र हैं, वे किसी उत्पाद में उपयोग किए जाने वाले वास्तविक चिह्न नहीं हैं :)

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

कई ब्रांडों के लिए कई फाइलें

पहेली का अंतिम टुकड़ा था: हम विभिन्न ब्रांडों के लिए एक ही आइकन के विभिन्न आकारों का समर्थन कैसे करते हैं?

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

इस बिंदु पर स्केच फाइलें तैयार थीं। हम कोड लिखना शुरू करने के लिए तैयार थे।

जारी रखा जाए।

स्केच और एक Node.js स्क्रिप्ट के साथ मल्टी-ब्रांड मल्टी-प्लेटफ़ॉर्म आइकन बनाना - भाग # 1