2008-09-09 19 views
34

डब्ल्यूपीएफ और सिल्वरलाइट की समृद्ध प्रस्तुति क्षमताओं का मतलब है कि मेरे जैसे डेवलपर इन दिनों अगले ग्राफिक डिजाइनरों के साथ मिलकर काम करेंगे, जैसा कि मेरी अगली परियोजना में मामला है।डिजाइनर और डेवलपर्स एक साथ काम कर रहे हैं

क्या किसी के पास कोई और सुझाव और अनुभव (दोनों बिंदुओं से) है जो इसे और अधिक आसानी से बनाने के लिए है?

उदाहरण के लिए, जब मैंने हाल ही में एक डिजाइनर को स्रोत नियंत्रण का उल्लेख किया, तो मुझे तुरंत बताया गया कि आप स्रोत नियंत्रण ग्राफिक्स, छवियों आदि नहीं कर सकते हैं, इसलिए यह समय बर्बाद है। तो मैंने जवाब दिया: ठीक है, लेकिन डब्ल्यूपीएफ/सिल्वरलाइट में एक्सएएमएल फाइलों के बारे में क्या?

स्कॉट Hanselman एक podcast में इस विषय के बारे में बात की थी, लेकिन वह उपकरण पर अधिक ध्यान केंद्रित है, जबकि मैं संचार मुद्दों/पहलुओं के बारे में अधिक दिलचस्पी रखता हूँ।

उत्तर

14

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

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

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

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

यह संचार और दोनों पक्षों के साथ समझौता करने के बारे में सब कुछ है।

10

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

+0

उस भाई के लिए आमीन! सेब टाइममैचिन ने यह स्पष्ट कर दिया है कि सभी प्रकार की फाइलों के लिए प्राथमिक संस्करण नियंत्रण भी उपयोगी है। – akmad

+0

TortoiseSVN एक साधारण ग्राफिक्स फ़ाइल तुलना टूल को स्पिन-अप करेगा यदि आप इसे दो छवियों को अलग करने के लिए कहते हैं। –

+0

एमकेएस आपको तृतीय-पक्ष diff उपकरण चुनने की अनुमति देता है, और BeyondCompare * कर सकते हैं * छवि diffs। – FrustratedWithFormsDesigner

6

प्रारंभिक डिज़ाइन और आर्किटेक्चर सत्रों में ग्राफिक डिज़ाइनर को शामिल करें।

आप उन्हें गलत तरीके से धारणाओं को प्रकट करने और दीवार पर आगे और पीछे फेंकने के बजाय एक साथ काम करने के पैटर्न को स्थापित करने के लिए शामिल करना चाहते हैं।

+0

मैं आगे जाऊंगा और कहूंगा कि आपके डिजाइनरों के साथ एक सहयोगी दृष्टिकोण भी बेहतर है। उन्हें हर समय शामिल करें। उन्हें अपनी परियोजना पर प्रथम श्रेणी का नागरिक बनाएं। – cplotts

0

स्पष्ट रूप से आपको डिजाइनर को यह बताना चाहिए कि छवियां, स्रोत और "नियंत्रण नियंत्रण में रखी जानी चाहिए!" :)

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

एक्सएएमएल स्रोत नियंत्रण में रखा जा सकता है (और चाहिए) और इसकी एक मार्कअप फ़ाइल के रूप में यह सभी सुविधाओं से लाभान्वित होगा।

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

+0

मैं आपकी स्माइली देखता हूं, लेकिन क्या आपको नहीं लगता कि कम आक्रामक दृष्टिकोण पूरी तरह से विपरीतता से अधिक प्राप्त करेगा? –

23

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

मैंने हाल ही में टेक एड ऑस्ट्रेलिया और न्यूजीलैंड में उन तकनीकों के बारे में एक बात की जो आप "डिजाइन के लिए डिजाइन" पर लागू कर सकते हैं। एक छोटी बैल सूची शामिल है:

  1. कोड लिखें जो डेटा बाइंडिंग का लाभ उठा सकता है। मॉडल-व्यू-व्यू मॉडेल या प्रेजेंटेशन पैटर्न इसके लिए एक अच्छा फिट है।

  2. आपकी सेवा निर्भरताओं के लिए "डिज़ाइन समय" स्टब्स की आपूर्ति करें। यदि आप जिस कक्षा के खिलाफ बाध्यकारी हैं, तो वेब सेवा कॉल वेब सेवा क्लाइंट को स्टब क्लास से प्रतिस्थापित करना सुनिश्चित करता है जो "डमी डेटा" देता है जो डिज़ाइनर मिश्रण के अंदर खपत करता है। यह आसानी से आईओसी और निर्भरता इंजेक्शन के माध्यम से किया जा सकता है, यदि HtmlPage.IsEnabled == झूठी हो तो एक कार्यान्वयन इंजेक्शन।

  3. डेटा बाइंडिंग का उपयोग करके आप अपने एक्सएएमएल फ़ाइल में "नामित तत्वों" की संख्या को सीमित कर सकते हैं। यदि आप अपने पीछे कोड का आवंटन लिखते हैं तो अपने सी # कोड को नामित तत्वों जैसे txtName या txtAddress के साथ जोड़ना, जिससे डिजाइनर के लिए "पेंच" करना आसान हो जाता है।

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

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

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

शुभकामनाएं!

पीएस: मैंने पैटर्न के बारे में बहुत कुछ लिखा है और http://jonas.follesoe.no पर अपने ब्लॉग पर डिजाइनर अनुकूल कोड बना दिया है। आप मेरी टेक एड टॉक की एक वीडियो रिकॉर्डिंग के साथ-साथ विषय पर आगे पढ़ने के लिए बहुत से लिंक के लिंक भी देख सकते हैं।

+0

संपादित करें आवश्यक: एस/बैल/बुलेट/ –

+0

उत्कृष्ट उत्तर। – cplotts

+0

+1, कुछ महान सुझाव। मैंने कुछ समय पहले इस सवाल से पूछा था और मैं हाल ही में सिल्वरलाइट से दूर चले गए हैं लेकिन जो भी आप कहते हैं वैसे भी आम तौर पर लागू होता है। – Ash

6

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

Real_World_WPF_DesignersAndDevelopersWorkingTogether

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

2

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

लॉरेन बग्नियन में post है जो इस बात का वर्णन करता है कि मैं किस बारे में बात कर रहा हूं। इस दृष्टिकोण में Robby Ingebretsen भी एक बड़ा आस्तिक है।

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

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

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

4

डिजाइनर/डेवलपर वर्कफ़्लो विवाह का माइक्रोसॉफ्ट का दृष्टिकोण निश्चित रूप से वास्तविक जीवन में टूटना प्रतीत होता है।मुझे काफी बड़े पैमाने पर डब्ल्यूपीएफ परियोजना पर काम करने का अनुभव है जिसमें लगभग 4 महीने के लिए 2 समर्पित डिजाइन संसाधन शामिल हैं। यहां कुछ तथ्य दिए गए हैं जो माइक्रोसॉफ्ट अक्सर भूल जाते हैं।

  • ब्लेंड (जहां तक ​​वी एम समाधान के रूप में किसी Mac नहीं चलता है - डिजाइनर आमतौर पर पसंद नहीं है -

    • डिजाइनर अक्सर Macs (0% विंडोज मेरी कंपनी में डिजाइनरों 100% मैक कर रहे हैं) का उपयोग करना पसंद एक विदेशी ओएस में अजीब अनुप्रयोग चलाने जैसे geeky समाधान)।
    • डिजाइनर व्यापार के अपने उपकरण - फ़ोटोशॉप और इलस्ट्रेटर का उपयोग करते हैं। अवधि।
    • आज के शेड्यूल की आक्रामकता आमतौर पर डिजाइनरों के लिए एक बिल्कुल नया एप्लिकेशन/डिज़ाइन वातावरण (जैसे मिश्रण) सीखने के लिए पर्याप्त समय प्रदान नहीं करती है।

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

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

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

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

  • 1

    मेरे अनुभव में, इंटीग्रेटर या "devsigner" भूमिका वास्तव में इस प्रक्रिया में शामिल होने की आवश्यकता है जब तक कि (छोटी) टीम पर हर कोई इस भूमिका को करने में सक्षम न हो। यह एक बहुत दुर्लभ परिस्थिति है। आम तौर पर आप पाएंगे कि डेवलपर्स विकास में बहुत अच्छे हैं लेकिन डिजाइन/उपयोगिता के साथ बहुत अच्छे नहीं हैं और डिजाइनर सौंदर्यशास्त्र/प्रयोज्यता के साथ महान हैं लेकिन कोड के लिए पर्याप्त शिक्षित नहीं हैं या नहीं। किसी ऐसे व्यक्ति को जो दोनों दुनिया में क्रॉसओवर कर सकता है और "भाषा बोलना" बहुत महत्वपूर्ण है।

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

    एप्लिकेशन के मुख्य ट्रंक से अलग समाधान में अपने एप्लिकेशन के लिए "देखो" बनाना और बाद में अपने संसाधन शब्दकोश को मुख्य ऐप में मर्ज करना बहुत उपयोगी है। आप अपूर्ण नियंत्रणों में अभी भी पकड़े बिना देखकर सही महसूस कर सकते हैं और महसूस कर सकते हैं।

    1

    मुझे लगता है कि आप एसएल के उल्लेख के बाद से आरआईए परियोजनाओं का उल्लेख करते हैं।

    मैंने एडोब डिजाइनिंग और अनुप्रयोगों और सेवाओं के विकास के साथ कुछ आरआईए परियोजनाओं का काम किया है।

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

    स्वीकार करें कि आप एक-दूसरे को समझ नहीं पाएंगे।

    प्रोग्रामर सोचता क्या कार्यक्षमता किया जाना चाहिए में, डिजाइनर में लगता है कि कैसे कार्यक्षमता व्यवहार करना चाहिए।

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

    इसलिए समझना सीखें कि आपकी ज़िम्मेदारी अलग है।

    आप डेवलपर को यह सोचने की ज़रूरत है कि आपका कोड कितना सामान्य है और अद्वितीय और हार्डकोडेड संरचना के रूप में सब कुछ का इलाज करने का जोखिम नहीं उठा सकता है। यह तब तक है जब तक कि आप किसी विशिष्टता को स्वचालित रूप से स्वचालित नहीं कर सकते।

    डिजाइनर डीओ को किसी भी तरह अद्वितीय या एप्लिकेशन के बारे में सोचना चाहिए। इसका मतलब यह हो सकता है कि एक बटन बटन नहीं है। विभिन्न आकार या रंग या अन्य परेशानियां हो सकती हैं।

    तो सुनिश्चित करें कि आप डिजाइनर की ज़िम्मेदारी समझते हैं और सुनिश्चित करते हैं कि वह आपकी समझ को समझता है, तो आप डिजाइनर के साथ अच्छे संबंध विकसित करते हैं।

    ऐसा नहीं है कि आप दुनिया में सर्वश्रेष्ठ एप्लिकेशन बनाने में रूचि नहीं रखते हैं। यह सिर्फ इतना है कि इनमें से कुछ डिजाइन निर्णयों में काफी समय लगता है।

    सुनिश्चित करें कि आपको डिज़ाइनर को आपको कैसे पहुंचाया जाए, इस बारे में बहुत स्पष्ट हो गया है कि आप अपना या अपना समय बर्बाद न करें। क्या प्रारूप, संपत्ति? नामकरण?

    सभी चीजें जो एक प्रतिमान से दूसरे में वितरण में शामिल हैं।

    और सबसे महत्वपूर्ण बात यह है कि वे जावास्क्रिप्ट कैसे करें या सीवीएस के बुनियादी विचारों को कैसे समझें, उन्हें सबसे महत्वपूर्ण रूप से संवाद और सम्मान नहीं है।

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

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

    और सबसे महत्वपूर्ण बात यह है कि। मैक बनाम पीसी पर बहस शुरू नहीं करें :) इस वजह से परियोजना रद्द कर दी गई है।

    +0

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

    +0

    हाहा हाँ एक परियोजना को मारने का एक अच्छा तरीका है। – ThomPete

    3

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

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

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

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

    alt text

    किसी भी विशिष्ट सवालों के जवाब देने की शुभकामनाएं!

    ps आप नहीं चाहते 100Mb + .psd स्रोत नियंत्रण में फ़ाइलों;)

    +0

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

    +0

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

    +0

    ग्राफिक से प्यार करो! –

    2

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

    डिजाइनर समुदाय में बड़े पैमाने पर विशेषज्ञता का विकास सॉफ्टवेयर विकास उद्योग का सामना करने वाली सबसे बड़ी औद्योगिक परिपक्वता समस्याओं में से एक है। यह विशेषज्ञता की एक सीमा है जो अनुमानतः अधिक पुनर्विक्रय और लंबे चक्र के समय बनाती है।

    यह डेवलपर्स की एंटाइटेलमेंट की भावना के बारे में भी सच है, जो कि इंटरैक्शन डिज़ाइन और कार्यान्वयन से अनजान है।

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

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

    नतीजतन, डेवलपर जो परीक्षण नहीं कर सकता है और परीक्षक जो कोड नहीं कर सकता वह एक ही औद्योगिक अपरिपक्वता का एक लक्षण है।

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

    +0

    एक डिजाइनर पहले पैराग्रा को सभ्य काउंटर तर्क दे सकता है। फिर भी एक +1 प्राप्त करें :) –

    संबंधित मुद्दे