स्केच + Node.js: कई प्लेटफार्मों और ब्रांडों के लिए आइकन उत्पन्न करना

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

समस्या हम हल कर रहे थे

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

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

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

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

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

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

आवश्यकताओं

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

कठिनाई यह थी कि ब्रांड के आधार पर एक ही आइकन के अलग-अलग पैरामीटर (रंग, आकार) होते हैं। नीचे हमारे अनुप्रयोगों के लिए कुछ आइकन दिए गए हैं। जैसा कि आप देख सकते हैं, कुछ बिल्कुल समान हैं, अन्य कई मापदंडों में भिन्न हैं, और अभी भी अन्य में कुछ भी सामान्य नहीं है।



कृपया ध्यान दें कि आइकन में उपयोग किए गए रंग केवल रंग नहीं हैं: वे बिल्कुल ब्रांड के रंगों और टोकन में इंगित विशिष्ट विशेषताओं के अनुरूप हैं।



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

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

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

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

मुझे नहीं पता कि आपको पीडीएफ कन्वर्टर्स के साथ काम करना था, लेकिन मेरा अनुभव कहता है कि यह एक बुरा सपना है। वे हमेशा लगभग काम करते हैं, लेकिन कभी भी इसे 100% नहीं करते हैं। इसलिए, रीढ़ की हड्डी, मुझे लगा कि हम फिसलन भरे रास्ते पर चल रहे हैं।

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

मुझे पता था कि स्केच फ़ाइल की आंतरिक संरचना मूल रूप से एक संग्रह है। .Zip का नाम बदलकर .Sip, आप फ़ाइल को डबल-क्लिक करके खोल सकते हैं; परिणामी फ़ोल्डर में, आपको JSON फ़ाइलों की सूची और PNG प्रारूप में एक पूर्वावलोकन फ़ाइल दिखाई देगी।



इसलिए, मैंने यह समझने के प्रयास में 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/

$/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. 

जैसा कि आप देख सकते हैं, उपकरण के चार मुख्य कार्य हैं:

read/dump - आंतरिक JSON फ़ाइलों के रीड / डंप मेटाडेटा डंप,
list - फ़ाइल संस्थाओं की एक सूची बनाएँ,
export - इन संस्थाओं को निर्यात करें,
run - प्लगइन द्वारा प्रदान की गई कमांड को चलाएं।

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



इसका मतलब यह है कि स्केचटूल आपको बाहरी कन्वर्टर्स का सहारा लिए बिना सीधे निर्यात के लिए स्केच (उदाहरण के लिए, एसवीजी से पीएनजी या पीडीएफ) का उपयोग करने की अनुमति देता है। बहुत बढ़िया!

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

स्केच फ़ाइल (ओं)

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

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

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



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

सामान्य शैलियों (और टोकन डिजाइन) का उपयोग करके माउस का गतिशील रंगीकरण

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

यहाँ एक उदाहरण दिया गया है कि किसी विशिष्ट परत पर शैली कैसे लागू की जाती है:



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



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

A / B टेस्टिंग के लिए उपयोग किए गए पेज और आर्टबोर्ड के नाम

यह समझने का समय है कि डिजाइनरों को माउस के ए / बी परीक्षण करने के लिए कैसे सक्षम किया जाए। एक बार फिर, हम नामकरण परंपरा (मैं KISS सिद्धांत का एक बड़ा प्रशंसक हूँ) का सहारा का फैसला किया है।

इस मामले में, हमने परीक्षण सेट ( XP_ उपसर्ग का उपयोग करके) निर्धारित करने के लिए पृष्ठों के नामों का उपयोग किया, और यह निर्धारित करने के लिए कि किस संसाधन का ए / बी परीक्षण है और इसके कौन से वेरिएंट (वर्ग कोष्ठक में दर्शाए गए हैं) के लिए आर्बरबोर्ड के नाम ।



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

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

आखिरी चीज जो हमें दिलचस्पी थी, वह थी कि विभिन्न ब्रांडों के लिए एक ही आइकन के विभिन्न रूपों को कैसे बनाए रखा जाए?



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



हमारी स्केच फाइलें तैयार हैं! कोड लिखने का समय आ गया है।

और पढ़ें