2009-04-21 8 views
7

हमारी विकास टीम में हम कई छोटे अनुप्रयोग बनाते हैं, जो सभी हमारे ग्राहकों की एक बहुत ही विशिष्ट आवश्यकताओं पर लक्षित होते हैं।मैं कैसे सुनिश्चित कर सकता हूं कि एक टीम में सभी डेवलपर एक समान उपयोगकर्ता अनुभव बनाते हैं?

इसलिए हम अक्सर के बारे में एक समान उपयोगकर्ता अनुभव बनाने में समस्याएं आ रही:

  • माउस की पसंद (जीयूआई)
  • विन्यास फाइल का नामकरण
  • कॉन्फ़िगरेशन विकल्प
  • जीयूआई भाषा का
  • नामकरण (के रूप में में "औपचारिक या कम औपचारिक" या)
  • नामों की पसंद/"नौसिखिया/उन्नत उपयोगकर्ताओं के लिए" खिताब
  • जीन आरएएल जीयूआई लेआउट
  • ...

मैं इन समस्याओं के लिए कई दृष्टिकोण के बारे में सोच सकते हैं ...

  • बनाएं बहुत विस्तृत लिखित दिशा निर्देशों
  • चर्चा सब कुछ
  • एक डेवलपर को निर्णय लेने दें सब कुछ
  • ...

सामान्य रूप से एक समेकित उपयोगकर्ता अनुभव या वर्दी परिणाम प्राप्त करने का सबसे अच्छा तरीका क्या है? व्यक्तिगत रूप से मुझे अपने किसी भी दृष्टिकोण को पसंद नहीं है, लेकिन शायद यह एक गलतफहमी है, इसलिए उन्हें समर्थन देने में संकोच न करें :)

+0

मुझे यह समस्या एक की टीम पर है। वेब ऐप्स विशेष रूप से उनके पास बहुत लंबे जीवन चक्र हैं। हम चीजों को करने और उन्हें पेश करने के नए तरीकों को सीखते हैं लेकिन मौजूदा कोड को अपडेट करने की लागत बहुत अधिक है ... – JoshBerke

+0

इसकी अमेज़ॅन से अमेज़ॅन एक ही समस्या से कुछ हद तक पीड़ित है। कुछ शायद ही कभी इस्तेमाल किए गए पेज ऐसा लगता है कि उन्हें लंबे समय तक अपडेट नहीं किया गया है। –

उत्तर

11

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

विकल्प दिशानिर्देश लिखना होगा, लेकिन यह वास्तव में एक अच्छा GUI डिज़ाइन ज्ञान/एचसीआई कौशल होने जैसा नहीं है। कम से कम यह डेवलपर्स को आपकी कंपनी के कस्टम पुस्तकालयों/घटकों का उपयोग करने के लिए सिखा सकता है।

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

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

+0

+1: एक व्यक्ति जीयूआई डिज़ाइन गारंटी की देखरेख करता है, वे सभी समान दिखते हैं। चर्चा और दिशानिर्देश दृष्टि वाले एक व्यक्ति के आसपास काम करने के तरीके हैं। –

7

"तकनीकी नेतृत्व", "डिज़ाइन लीड" और/या क्यूए द्वारा व्यापक दिशानिर्देश और समीक्षा।

दिशानिर्देश "गतिशील" बनाएं और उन्हें सटीक और अद्यतित रखें, हमारी कंपनी में हम ऐसे सहयोग कार्यों के लिए विकी का उपयोग करते हैं।

3

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

+0

+1: टेम्पलेट्स बहुत मदद करते हैं। एक "चर्चा" काटा और चिपकाया नहीं जा सकता है। एक दिशानिर्देश सहायक नहीं है जब तक कि इसमें टेम्पलेट न हों। –

0

फ्रेड ब्रूक्स पौराणिक आदमी महीने में इस बारे में बहुत कुछ बोलता है जिसे मैं अत्यधिक पढ़ने की अनुशंसा करता हूं।

कार्ल

3

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

यदि आपको किसी भी प्रकार के टीम प्रयास को मानकीकृत करना है और सिस्टम डिज़ाइन के निहित "व्यक्तित्व" को बाहर निकालना है तो आपको हमेशा वर्बोज लिखित दिशानिर्देशों की आवश्यकता होगी।

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

आपके दिशानिर्देश दस्तावेज़ परियोजना के सभी हितधारकों के लिए आसानी से सुलभ होना चाहिए। एक "धोखा-चादर" तैयार संदर्भ बनाना अक्सर एक अच्छा विचार है।

0

आपको कुछ प्रकार के Dependency injection का उपयोग XML फ़ाइलों के साथ करना चाहिए जो Spring प्रदान कर सकते हैं।

सभी डेवलपर्स को प्रोग्राम में हार्ड-कोड किए गए जीयूआई भागों की अपनी पसंद को एकीकृत नहीं करना चाहिए, बल्कि इस विकल्प को एक्सएमएल फ़ाइल में छोड़ दें।

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

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

-1

एक ऐसा दस्तावेज़ बनाएं जो लेआउट के लिए सभी सामान्य प्रोवर्टीज का वर्णन करता हो।

इस दस्तावेज़ शामिल करना चाहिए:

पाठ की पृष्ठभूमि रंग सक्रिय पाठ की रंग निष्क्रिय पाठ की रंग टिप्पणी पाठ फ़ॉन्ट प्रकार फ़ॉन्ट आकार के रंग आदि

सुनिश्चित करें के रंग (परीक्षण करके) डेवलपर्स दिशानिर्देशों का पालन करते हैं।

यदि कोई डेवलपर नहीं करता है तो आप सजा (आग, कम वेतन, कोई पदोन्नति) लागू कर सकते हैं।

+0

'गोस' - क्या आपने वास्तव में जो कुछ कहा है, वह करने की कोशिश की है या क्या आप केवल कट्टरपंथी विचारों के बारे में बात कर रहे हैं जो आपको लगता है कि काम कर सकते हैं? – louism

2

एक दृष्टिकोण जो मेरे लिए पहले काम करता है वह मूल कक्षाओं के लिए साझा लाइब्रेरी है जो विषयों और लेआउट को लागू या लागू करता है।

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

1

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

+0

मैं सहमत हूं, लिखित चीजें भुला दी जाएंगी। दस्तावेजों को लंबा होने के बाद उस समस्या को जोड़ दिया जाता है (उदाहरण के लिए 20+ पेज)।और समस्या तब भी बदतर हो जाती है जब आप महसूस करते हैं कि प्रोग्रामर 60+ स्क्रीन पर लगातार यूआई डिज़ाइन के बारे में कम ख्याल रख सकते हैं। – louism

2

ive की स्थिति प्राप्त कर सकते हैं I यूई डिजाइनर था और उसने ठीक काम किया। नकली बनाने और उन्हें मास्टर स्टूडियो के रूप में दृश्य स्टूडियो में लाने की मेरी ज़िम्मेदारी थी।

प्रोग्रामर तब आएंगे और तर्क जोड़ देंगे।

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

वास्तविकता यह है कि ज्यादातर कंपनियां विशेष रूप से यूआई भूमिका के लिए किसी को किराए पर नहीं लेती हैं (हालांकि कुछ कंपनियां कुछ साल पहले ऐसा करने शुरू कर रही हैं)।

4 अलग-अलग कंपनियों में 5 साल के लिए प्रोजेक्ट मैनेजर होने के नाते, एक और दृष्टिकोण है।

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

यूआई स्टाइल गाइड प्रोग्रामर को धीमा कर देते हैं क्योंकि आप उन चीज़ों पर अच्छा होने की उम्मीद कर रहे हैं जिन पर वे अच्छे नहीं हैं। वे कोडिंग में अच्छे हैं - तो उन्हें कोड दें।

आपको क्या मिलता है? इंटरफ़ेस में असंगतताएं। यह तब भी होता है जब आप प्रोग्रामर को काम करने के लिए मॉकअप प्रदान करते हैं (उदा। आपके मॉकअप में प्रोग्रामर को एक त्रुटि संदेश नहीं हो सकता है)।

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

अगला प्रश्न यह है कि, समीक्षा कौन करनी चाहिए? फिर से, आसान - केवल एक व्यक्ति (स्थिरता के लिए), और वह व्यक्ति जो भी एचसीआई/यूआई डिज़ाइन के साथ सबसे प्रतिभाशाली होना चाहिए।

मेरा मुद्दा है; प्रोग्रामर को कोशिश न करें और यूआई डिज़ाइनर बनें। जब आप यूआई बग लॉग करते हैं, तो वहां पॉइंट ट्रैकर में, प्रोग्रामर आते हैं और अच्छे और तैयार होने पर उन्हें ठीक कर देते हैं। और वे आम तौर पर ठीक करने में वास्तव में आसान होते हैं ताकि वे प्रोग्रामर के लिए एक अच्छा ब्रेक के रूप में कार्य कर सकें जो उदाहरण के लिए गंभीर डेटा भ्रष्टाचार के मुद्दे को 2-3 घंटे बिता सकता है (हां, यूआई बग को ठीक करना वास्तव में तनाव राहत हो सकता है!)।

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

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