कई व्यापार उपयोगकर्ताओं और ग्राहकों के बीच एक सामान्य धारणा है कि जब यह पूरा दिखता है , तो यह लगभग पूरा हो जाता है। जैसा कि आप जानते हैं, यह सच्चाई से बहुत दूर है। एक अच्छा लग सकता है, लेकिन कोई बैकएंड नहीं है और कुछ उपयोगकर्ताओं को लगता है कि यह अच्छा लग रहा है 80% काम है, न कि 20% ( या अन्य 80% )।
अनगिनत डेवलपर्स इसके बारे में डरावनी कहानियां बता सकते हैं - कुछ अन्य टूल के स्क्रीन शॉट्स का उपयोग करके माइक्रोसॉफ्ट वर्ड में किए गए पेजों का मखौल उड़ाना, और क्लाइंट यह कह रहा है "तो, आपने लगभग इसे पूरा कर लिया है?"
आपको इसे गति देने की आवश्यकता है ताकि इसके किए जाने पर सभी भाग किए जाएं। पहले सभी बैकएंड को करने की कोशिश करना और फिर सभी फ्रंट एंड को समाप्त करना होगा, यह सोचकर कि आप कुछ भी नहीं कर रहे हैं और पूछ रहे हैं कि जब आपको इसके लिए कुछ भी नहीं मिल रहा है, तो आपको भुगतान क्यों किया जा रहा है। दूसरी ओर, पहले अंत में और आप अंत उपयोगकर्ता को सभी बदलावों का उपभोग करते हुए और बदलाव करते हुए पाएंगे।
'एक पहले और दूसरे' के साथ सबसे खराब स्थिति यह है कि जब आप दूसरे हिस्से में पहुंचते हैं, तो आप पाते हैं कि यह डिजाइन बिल्कुल भी फिट नहीं है।
इस प्रकार, दोनों का निर्माण करें। सामने के अंत में प्रगति दिखाएं, आप जो निर्माण कर रहे हैं, उसके साथ अंतिम छोर का काम करें। कई मामलों में वृद्धिशील बिल्ड देने के लिए इसका एक अच्छा विचार है और सुनिश्चित करें कि आप ग्राहक क्या चाहते हैं (यह चुस्त हो जाता है)। बाहर 'दिखाई अग्रिम' के साथ बहुत लंबा जा रहे हैं ग्राहक संबंध (इस के लिए है चोट पहुंचा सकते हैं दोनों 'सब कुछ दिखता है जल्दी से किया' और 'कुछ भी नहीं बहुत अंत तक किया जाता है' के मामलों - ग्राहक के लिए अपनी हार्ड ढांचे लिखा जा रहा या देखने के लिए इकाई परीक्षण या प्रगति के रूप में डेटा स्वच्छता)।
जोएल ने द आइसबर्ग सीक्रेट, रिवील्ड में इस बारे में लिखा है :
महत्वपूर्ण कोरोलरी दो। यदि आप एक गैर-प्रोग्रामर स्क्रीन दिखाते हैं जिसमें एक उपयोगकर्ता इंटरफ़ेस है जो 100% सुंदर है, तो वे सोचेंगे कि कार्यक्रम लगभग हो चुका है।
जो लोग प्रोग्रामर नहीं हैं, वे केवल स्क्रीन को देख रहे हैं और कुछ पिक्सेल देख रहे हैं। और अगर पिक्सल जैसा दिखता है तो वे एक प्रोग्राम बनाते हैं जो कुछ करता है, वे सोचते हैं "ओह, गोश, वास्तव में काम करने के लिए कितना कठिन हो सकता है?"
यहां बड़ा जोखिम यह है कि यदि आप पहले यूआई का मजाक उड़ाते हैं, तो संभवत: इसलिए आप ग्राहक के साथ कुछ बातचीत कर सकते हैं, तो हर किसी को लगता है कि आप लगभग काम कर रहे हैं। और फिर जब आप अगले साल काम कर रहे हैं "कवर के तहत," तो बोलने के लिए, कोई भी वास्तव में नहीं देखेगा कि आप क्या कर रहे हैं और वे सोचेंगे कि यह कुछ भी नहीं है।
यह फिर से ब्लॉग पोस्ट में दोहराया जाता है कि डेमो लुक को पूरा न करें जिसमें यह सहायक ग्राफ है:
ध्यान दें कि दो विकल्प आम तौर पर 'यूआई करवाएं' को दर्शाते हैं (और फिर उम्मीद यह है कि आप जल्द ही हो जाएंगे) और 'बैकएंड हो गया' (और फिर ग्राहक आपके बारे में चिंतित है कि आपको समय सीमा याद आ रही है)।
कैसे किया गया 'कुछ दिखता है' कैसा होना चाहिए।
हर सॉफ्टवेयर डेवलपर ने अपने करियर में कई बार यह अनुभव किया है। लेकिन डेस्कटॉप प्रकाशन उपकरण तकनीकी लेखकों के लिए समान सिरदर्द का कारण बनते हैं - यदि आप किसी को एक मोटा मसौदा दिखाते हैं जो पूरी तरह से फ़ॉन्टबद्ध और स्वरूपित है, तो वे इसे उतना ही देखते हैं जितना आप चाहते हैं। हमें इस बात की ज़रूरत है कि हम कहाँ हैं और दूसरों को हम कहाँ हैं।
यह लेख उपयोगकर्ता इंटरफ़ेस के विभिन्न प्रकार के दान के साथ आपको प्राप्त होने वाले फीडबैक के प्रकार के बारे में एक महत्वपूर्ण बिंदु लाता है। यदि आपके पास ऐसा कुछ है जो पूर्ण दिखता है, तो आपको "यह लेआउट काम नहीं करता है" की तुलना में "क्या आप फ़ॉन्ट बदल सकते हैं" के बारे में प्रतिक्रिया प्राप्त करने की अधिक संभावना है - बहुत अधिक टैब हैं।
जो लोग जावा स्विंग दुनिया में इसके साथ लड़ रहे हैं, उनके लिए नैपकिन नामक एक लुक और फील है, जो इसे बनाता है ताकि यूआई पूरा न दिखे (भले ही यह हो)।
कुंजी यहाँ यह इतना बनाने के लिए है कि यह नहीं करता है देखो किया। UI का पूर्ण रूप से दिखना कई व्यावसायिक उपयोगकर्ताओं के लिए एक संकेत है कि आवेदन पूरा हो गया है (भले ही इसके कुछ स्थिर पृष्ठ इसके पीछे कोई तर्क हो या एक इंटरफ़ेस बिल्डर में निर्मित कुछ)।
आगे पढ़ने (और लेख से लिंक):
