कुछ प्रोग्रामर विकास के यूआई भाग से नफरत क्यों करते हैं? [बन्द है]


54

बहुत सारे प्रोग्रामर जो मुझे मिले हैं हमेशा कहते हैं कि "वह यूआई आदमी नहीं है।" तथ्य यह है कि आजकल विकास, चाहे वेब, विंडोज, लिनक्स, ओएसएक्स, या किसी अन्य प्रकार के विकास में अब एक अच्छा दिखने वाला यूआई वाला सॉफ्टवेयर शामिल है। क्यों कई डेवलपर्स यूआई काम पसंद नहीं करते हैं?


54
क्योंकि वे डिज़ाइनर नहीं हैं :)
महमूद होसाम

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

58
@ जोश - आपका मुख्य बिंदु स्पॉट-ऑन है, लेकिन मैं असहमत हूं कि "कोई भी कुछ अच्छा कर सकता है"। हम डेवलपर्स ऐसे लोगों से चिढ़ जाते हैं जो हमारे पेशे का मूल्यांकन करते हैं ("यह सिर्फ टाइपिंग है, यह कितना कठिन हो सकता है?"), तो चलो अन्य विषयों के लिए भी ऐसा न करें।
स्टीव एस

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

17
@ जोश के: "रोजमर्रा की चीजों का डिज़ाइन" पढ़ने के बाद मुझे लगता है कि यह दूसरा तरीका है। कुछ काम करना आसान हिस्सा है। इसे इतनी अच्छी तरह से काम करना उपयोगकर्ताओं को सहज रूप से समझ में आ जाएगा, इसे पसंद करें और इसे फिर से उपयोग करना चाहते हैं।
नीकी

जवाबों:


102

मैं यूआई व्यक्ति नहीं हूं। ठीक है, मैं अपने स्वयं के प्रोजेक्ट्स पर यूआई करता हूं, लेकिन काम पर मुझे इससे कोई लेना-देना नहीं है - मेरा काम ऐप के हिम्मत में है, फ्रंट एंड पर नहीं।

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


63
+1 "पिक्सल्स को संरेखित करने के लिए 'बस'", मुझे उससे नफरत है। यह 99.99999% परिपूर्ण है, लेकिन उपयोगकर्ता बॉक्स के चारों ओर की सीमा चाहता है, जो कि पहली जगह में नहीं होना चाहिए, 2 पिक्सेल चौड़ा होना चाहिए, 1 नहीं, और नीले रंग का "हल्का" शेड, लेकिन प्रकाश छाया नहीं। पहले 2 संशोधन हुए, उससे भी गहरे। और इतने पर, और आगे ... जो कि मैं अब गुजर रहा हूं। एप्लिकेशन 100% काम करता है, लेकिन मुझे इस टूलटिप के आवरण को बदलने के लिए थकाऊ अनुरोध मिल रहे हैं, और अवधि को हटा दें ... यह वही है जो मेरे "परीक्षकों" पर केंद्रित है ... सभी कार्यक्षमता पर नहीं।
कैफीक

3
@ रोबर्ट हार्वे, यह एक दैनिक संघर्ष है। काश हमारे यहाँ एक या दो समर्पित यूआई लोग होते ... यह हमारे प्रमुख ऐप्स में हमारे यूआई को मानकीकृत करने में हमारी अक्षमता को हल करने में भी मदद करता।
कैफीक

23
+1 यह ध्यान देने के लिए कि इसे बनाने के लिए GUI डिज़ाइन करना अधिक दिलचस्प है।
जेपर्ट

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

10
@ शानदार मुझे लगता है कि स्वचालन एक महान लक्ष्य है, लेकिन मुझे अभी तक एक स्वचालित यूआई लेआउट देखना है, जिसे डिजाइनर की दृष्टि या ग्राहक की पसंद के अनुकूल होने के लिए समायोजन की आवश्यकता नहीं है। और फिर बस सादा तकनीकी सीमाएँ हैं - यदि आप WinForms का उपयोग कर रहे हैं, उदाहरण के लिए, आपके ऑटो-लेआउट विकल्प सीमित होंगे। वेब ऐप्स के पास डेस्कटॉप ऐप्स की तुलना में बेहतर है, मुझे लगता है, लेकिन जब तक हम टेलीफ़ोन को UI लेआउट नहीं बना सकते और इसे वायर नहीं कर सकते, मुझे लगता है कि इसमें अभी भी काफी मात्रा में ड्रगरी शामिल होगी। मैं भविष्य में इस बिंदु पर गलत साबित होने की आशा करता हूं। :)
एडम लेअर

55

एक अच्छा यूआई बनाने में कुछ बैकएंड कोड लिखने की तुलना में बहुत सारे कौशल शामिल होते हैं।

बैक-एंड आवश्यकताओं को आमतौर पर एक ब्लैक बॉक्स की तरह निर्दिष्ट किया जा सकता है, x अंदर जाता है और उम्मीद की जाती है कि y बाहर आना चाहिए। इसे काम करने में तर्क को लागू करना शामिल है और आप प्रोग्राम कर सकते हैं कि यह काम करता है या नहीं।

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

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

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


3
बैकएंड कोड लिखने में बहुत सारे अलग-अलग कौशल भी शामिल हैं (इसके विपरीत आपकी पहली टिप्पणी का क्या मतलब है), यह कौशल का एक अलग सेट है।
मैथ्यू एम।

2
@ मैथ्यू यह करता है, और मैंने कभी नहीं कहा कि यह नहीं हुआ। क्या मैं मतलब यूआई कोडिंग एक शामिल था विभिन्न बैक-एंड कोडिंग से कौशल की बहुत। कृपया यह मत सोचिए कि मैं बैक-एंड कोडिंग पर विश्वास कर रहा था, यह वही है जो मैं ज्यादातर जीवित रहने के लिए करता हूं :)
Alb

+1: यह कठिन है, और सॉफ्टवेयर डिजाइन के लिए सामान्य दृष्टिकोण सिर्फ ग्राफिक्स के लिए काम नहीं करता है। अगर यह बदसूरत है, तो यह बदसूरत है।

18

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

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


15

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

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


2
मौके पर, "व्यक्तिपरक" कष्टप्रद है। दो लोगों को वहाँ से बाहर निकालें और उनके पास व्यापक रूप से अलग-अलग राय है कि एक अच्छा यूआई क्या है। आप GUI पहलू को इकाई-परीक्षण नहीं कर सकते (वास्तव में नहीं)। आदि ...
Matthieu M.

13

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

मैं जरूरी नहीं लगता कि कुछ प्रोग्रामर यूआई के डिजाइनिंग से नफरत करते हैं, क्योंकि वे उन चीजों को करने से नफरत करते हैं जो वे अच्छे नहीं हैं। यह सिर्फ ऐसा होता है कि बहुत सारे डेवलपर हैं जो UI विकास में अच्छे नहीं हैं।


+1 - "प्रोग्रामर उन चीजों से नफरत करते हैं जो वे अच्छे नहीं हैं।" सच है। जब आप इसे एक व्यक्तिगत परियोजना पर कर रहे हैं, तो यह अभ्यास है और मजेदार हो सकता है, लेकिन जब आप इसे अपनी नौकरी के लिए कर रहे हैं - यह प्रदर्शन है, और यदि आपके पास कौशल नहीं है, तो यह सिर्फ तनावपूर्ण है।
दोपहर का भोजन

11

यूआई डिजाइन के साथ समस्या यह है कि हर कोई एक राय है ... और कोई सही या गलत जवाब नहीं है। दूसरी ओर डेवलपर्स काले और सफेद और तर्क से प्यार करते हैं। किसी भी आकार की कंपनी में हर कोई इस बात से सहमत होगा 1+1=2, लेकिन पूछें कि कौन सा फ़ॉन्ट पढ़ना आसान बनाता है (Comic Sans Obviously)... बाढ़ के लिए तैयार रहें। दस हजार अलग-अलग उत्तर और हर कोई सही है, क्योंकि हर कोई अलग है।


6
हे भगवान, कॉमिक संस ...
मैक्सएम २

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

7

एक डेवलपर के रूप में जो वास्तव में यूआई पर काम करने का आनंद लेता है (विशेष रूप से, मैंने वेब डिजाइन का अपना उचित हिस्सा किया है), मैं सराहना करता हूं जब किसी के पास कौशल सेट नहीं होता है तो वह इससे बाहर रहता है।

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

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


6

मुझे लगता है कि यह अधिकांश प्रोग्रामर अपने मस्तिष्क के बाएं हिस्से का उपयोग करते हैं।

इस विषय के आगे पढ़ने के लिए एक अच्छा स्रोत

यहाँ छवि विवरण दर्ज करें


6
आप पुस्तक, व्यावहारिक सोच और सीखने का आनंद ले सकते हैं : रिफ्लेक्टर योर वेटवेयर , यह बाएं / दाएं मस्तिष्क के अंतर के बारे में सोचने का एक नया तरीका देता है। वास्तव में, यह उन्हें रैखिक-मोड और रिच-मोड का नाम देता है, और वास्तव में बहुत अच्छा पढ़ा है।
कैफीक

@ चाड थैंक्यू चाड! मैं इस पर विचार करूंगा!
आमिर रज़ाई

इसे लाने के लिए +1। बैकएंड ऐप देव अत्यधिक विश्लेषणात्मक है जबकि फ्रंटएंड काम बहुत अधिक रचनात्मक उन्मुख है। कुछ लोग दोनों को पसंद करते हैं, लेकिन बहुत से अपने संबंधितों से चिपकना पसंद करते हैं।
बंग

जो लोग दिलचस्पी ले सकते हैं, उनके लिए बस थोड़ी अतिरिक्त जानकारी: यह वास्तव में 100% स्पष्ट नहीं है जो गोलार्ध गणित की क्षमता निर्धारित करने में बड़ी भूमिका निभाता है
दान ताओ २ Dan

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

6

यूआई विकास जटिल हो जाता है क्योंकि आपको गलत लोगों से बहुत अधिक इनपुट मिलता है। वे सभी ग्राफिकल डिज़ाइन विशेषज्ञ हैं। जब आप किसी चीज़ के लिए फार्मूला जानना चाहते हैं तो वे नहीं होते।

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

आप इसे नहीं बना सकते। मैं एक बैठक में बैठा, जहाँ एक बड़ी लॉ फर्म के लिए लेखा विभाग (शीर्ष 500K / वर्ष वेतन) में शीर्ष दो लोगों ने वकीलों द्वारा इस्तेमाल किए गए बिलिंग वेबसाइट पेज पर एक लेबल पर बहस करते हुए आधे घंटे का समय बिताया। यह मान लिया गया था कि वकीलों को समझना आसान है। सिर्फ वकीलों से क्यों नहीं पूछा जाता? बहुत आसान। तो IT विभाग, WTF "अवशिष्ट शुद्ध बिलिंग राशि" जानना चाहता है, और यह उनके समय प्रवेश फॉर्म पर क्यों है, यह जानने के इच्छुक वकीलों से 50 फोन कॉल करने के लिए जाता है।


5

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

यूआई की तुलना में कोड करने के लिए अन्य चीजों के बहुत सारे हैं। वेब सेवाएँ, विंडोज़ सेवाएँ, एम्बेडेड (माइक्रोवेव में UI का अधिक हिस्सा नहीं), बस कुछ उदाहरणों को नाम देने के लिए।


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

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

भयानक रूपक। मुझे ब्रोकोली बहुत पसंद है लेकिन यूआई डिजाइनिंग से नफरत है। ;)
दान

4

ऐसा इसलिए हो सकता है क्योंकि - कुछ मामलों में - ऐसे उपकरण जो स्पष्ट रूप से कल्पना करने में आपकी मदद करते हैं कि यूआई को एक स्ट्रॉ के माध्यम से मृत शिशु बंदरों को चूसने में मदद मिलेगी।


4

UI विकास में कुछ चीजें हैं जो सही होना मुश्किल है।

लेआउट उनमें से एक है। मैं 15 वर्षों से UI का निर्माण कर रहा हूं और अभी तक लेआउट प्रबंधन के लिए एक अच्छा समाधान नहीं है।

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


3

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


4
आप अपने उपयोगकर्ता नाम के साथ वर्ग का उत्तर कैसे देते हैं? :)
रॉबर्ट हार्वे

@ रोबर्ट हार्वे: काफी साफ! फॉर्म्स डिज़ाइनर अच्छा है, लेकिन जब आप जेनेरिक यूआई कंटेनर के साथ फैंसी मिलना शुरू करते हैं, तो यह चोक होने लगता है। या कम से कम VS2008 किया। अभी तक 2010 की कोशिश नहीं की गई है, लेकिन मुझे संदेह है कि इसमें समान मुद्दे हो सकते हैं? किसी भी तरह से समस्या अंततः हल हो गई (एसओ पर मेरी पहली पोस्ट देखें)। अन्य चीजें भी हैं जो इसे भी चोक कर देती हैं लेकिन यह उन टेडियम को काफी हद तक हटा देती है जो मैं आमतौर पर यूआई डिजाइन / विकास का आनंद लेती हूं ।
FrustratedWithFormsDesigner

3

सभी शतरंज खिलाड़ियों को शतरंज की बिसात और उनके द्वारा खेले जाने वाले टुकड़े क्यों पसंद नहीं हैं?

यह अजीब नहीं है कि कुछ लोगों को यह पसंद नहीं है ... यह अजीब है कि आप हमें उम्मीद करनी चाहिए।


1
शतरंज के खिलाड़ी शतरंज बोर्ड और टुकड़े डिज़ाइन नहीं करते हैं क्योंकि उन डिज़ाइनों को एक सदी से अधिक समय तक अंतर्राष्ट्रीय शतरंज महासंघ (FIDE) द्वारा मानकीकृत किया गया है और उन मानकों को सार्वभौमिक रूप से अपनाया गया है।
jwenting

2

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


2

मैं यूआई काम से उतनी नफरत नहीं करता जितना कि मैं कुछ यूआई फ्रेमवर्क से नफरत करता हूं। उदाहरण के लिए> मैं 10 वर्षों के लिए .NET प्रोग्रामिंग कर रहा हूं। वेब एप्लिकेशन बनाने के लिए रूपरेखाएँ बहुत बढ़िया हैं (ASP.NET WebForms और ASP.NET MVC)। लेकिन डेस्कटॉप अनुप्रयोगों को लिखने के लिए रूपरेखा, ठीक है, मैं उन्हें (WinForms और WPF) के शौकीन नहीं हूं।

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

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

उदाहरण के लिए आवेदन डीटीओ वस्तुओं की एक श्रृंखला के माध्यम से जानकारी प्राप्त करता है। एप्लिकेशन तब डेटा का अपना मॉडल प्रतिनिधित्व बनाता है (सर्वर पर बनाए गए समान डोमेन कक्षाओं का पुन: उपयोग नहीं कर रहा है)। मॉडल कक्षाएं एक दृश्य मॉडल (एक WPF MVVM पैटर्न) द्वारा खपत होती हैं, जो मॉडल पर गुणों को उजागर करती हैं।

यह बहुत बार है कि एक ही डेटा को विभिन्न वर्गों द्वारा दर्शाया जाता है। और वह उबाऊ हो जाता है। लेकिन यह इस प्रकार के डेस्कटॉप एप्लिकेशन के लिए विशिष्ट समस्या है।

इस तरह के एप्लिकेशन में दिलचस्प चुनौतियां भी हैं, जैसे कि हमें एक क्लाइंट से दूसरे क्लाइंट पर तुरंत अपडेट करने के लिए कैसे बदलाव मिलते हैं।


++ मुझे पता है कि आपका क्या मतलब है। ग्राहकों के बीच अद्यतन के प्रचार के बारे में अंतिम बिंदु के लिए, मैं मतदान (आमतौर पर 1-सेकंड) का उपयोग करता हूं, लेकिन यह संभवत: केवल एक छोटे से DB और छोटी संख्या के ग्राहकों के लिए काम करता है।
माइक डनलैवी

2

मैं इन कारणों से UI विकास का बहुत बड़ा प्रशंसक नहीं हूं:

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

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

  3. मुझे लगता है कि यूआई बैक-एंड की तुलना में "प्लंबिंग" से अधिक है, अर्थात् चतुर एल्गोरिदम के लिए कम अवसर है और वास्तव में आपके मस्तिष्क को सीमा तक धकेलता है।


1

मैं यूआई (डेस्कटॉप, वेब नहीं) और आंतरिक हिम्मत दोनों करता हूं।

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

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

गैर-यूआई डोमेन में, मैंने कई उत्पादों से सबक लिया, जो कमांड लाइन से प्रयोग करने योग्य DSLs के रूप में शुरू हुआ, जिस पर बाद में UI का ग्राफ्ट किया गया था। वह विशेषज्ञ उपयोगकर्ता को कुछ ऐसा देता है जहां वे UI को बायपास कर सकते हैं, जबकि आकस्मिक उपयोगकर्ता को वे आकस्मिक रूप से उपयोग कर सकते हैं। (उदाहरण: R, SPlus, Matlab, SAS, WinBugs।) तो हमारे उत्पाद में विशेषज्ञों के लिए एक कमांड-लाइन भाषा है। मुझे ऐसी चीजों को विकसित करना पसंद है, जो एक पार्सर, कोड जनरेटर, प्री-कंपाइलर और रन-टाइम मॉडलिंग इंजन के साथ है। उस पर खर्च किया गया प्रयास यूआई पर खर्च किए गए प्रयास की तुलना में कम से कम 10 की शक्ति है।

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

तो आपका सवाल था "कुछ प्रोग्रामर यूआई के विकास के हिस्से से नफरत क्यों करते हैं?"। मुझे केवल उस "गोंद" के कारण घृणा है, जिसके लिए मेरे पास डीएसएल नहीं है।


1

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


1

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


1

कुछ और बिंदु:

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

2) कई प्रोग्रामर इस पर प्रशिक्षित नहीं हैं, और इसके बारे में ज्यादा नहीं जानते हैं।


1

तथ्य यह है कि बहुत सारे यूआई उपकरण / रूपरेखा / एपीआई खराब हैं, जटिल हैं, दूर तक सहज होने के लिए। मैं C / C ++ में Win32 API के साथ विकसित हुआ, javax.swing, CSS, आदि के साथ। तब से, मुझे यूआई विकास से संबंधित है ... Qt फ्रेमवर्क तक!


1
आपका मतलब है कि आप उन उपकरणों पर जल गए हैं जो अब आम उपयोग में नहीं हैं (अधिकांश लोग इन दिनों UI प्रोग्रामिंग के लिए Win32 का उपयोग नहीं करेंगे)? क्षमा करें, मैं इसे केवल एक वैध बिंदु नहीं मानता।
user16764

1

एक CS छात्र के रूप में आपको UI के अलावा डेटा संरचना, डेटाबेस, C ++ ... सिखाया जाएगा। तो आप शुरू से ही इसके अच्छे नहीं होंगे । यदि आप इसमें अच्छे नहीं हैं, तो आप इससे नफरत करेंगे।


कई विश्वविद्यालय और कॉलेज UX डिजाइन पाठ्यक्रम प्रदान करते हैं। अक्सर उनके सीएस पाठ्यक्रम के हिस्से के रूप में।
user16764

1

सिक्के के दोनों किनारों यानी UI डिज़ाइन और बैकएंड कोड पर काम करने के बाद, मैंने पाया कि सिक्के के दोनों किनारे मूल रूप से एक ही चीज़ हैं।

आवश्यकताएं जो आप दिन-प्रतिदिन करते हैं उससे अलग होती हैं जो हर समय नहीं आती हैं और अब उस युग में जहां सभी सेवाएं सीआरयूडी के चारों ओर घूमती हैं फिर उबाऊ हो जाती हैं।

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.