प्रोग्रामर अपने यूएक्स कौशल में सुधार कैसे कर सकते हैं? [बन्द है]

Question

प्रोग्रामर के रूप में हम बहुत जटिल समस्याओं को हल कर सकते हैं, लेकिन तब, जब हमें एक उपयोगकर्ता इंटरफ़ेस डिजाइन करना होता है जिसे हम उपयोग करने में आसान बनाने में विफल होते हैं।

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

समस्या क्या है? अच्छे उपयोगकर्ता अनुभवों को डिजाइन करने में डेवलपर्स अपने कौशल में सुधार कैसे कर सकते हैं?

Comments

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

— ग्रैंडमास्टरबी

मुझे लगता है कि आप पाएंगे कि यह कॉमिक उनके कई अन्य उत्पादों की तुलना में विफल है जो google.com खोज या iDevice नहीं हैं। कॉमिक में पहले और दूसरे दोनों फ्रेम 1-वे संचार का प्रतिनिधित्व करते हैं। तीसरा नहीं है। सभी 3 अतिरंजित हैं।

— स्टीवन एवर्स

@GrandmasterB, इसे इतनी गंभीरता से न लें। मैंने अत्यधिक सामान्यीकरण से बचने के लिए वैसे भी शीर्षक संपादित किया।

— jmservera

@SnOrfus, उदाहरण के लिए, Google का ऐडवर्ड्स इंटरफ़ेस एकदम दर्दनाक है।

— ग्रैंडमास्टरबी

FYI करें: मुझे UI साइट में एक समान प्रश्न मिला है: ui.stackexchange.com/questions/1863/…

— jmservera

Answer 1

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

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

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

मेरी टिप है:

• अपनी सीमाओं को स्वीकार करें
• उन लोगों से पूछें और सुनें जो इन चीजों के बारे में जानने का दावा करते हैं
• अनिश्चित होने पर, इसे Google करें और आधिकारिक उत्तरों की तलाश करें

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

Tl, डॉ: KISS

Comments

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

— जॉब

Answer 2

यह जैविक है।

• यूआई और अन्य सभी डिजाइन संबंधी कार्यों में सही मस्तिष्क शामिल है ।
• प्रोग्रामिंग कार्य में बाएं मस्तिष्क शामिल है ।

उनके अलग उद्देश्य हैं।

दोनों में अच्छा होना बहुत दुर्लभ है। कम से कम उसी समय।

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

Comments

क्या आप समर्थन कर सकते हैं "दोनों में अच्छा होना बहुत कम है। कम से कम एक ही समय में।" अध्ययन / लेख के साथ ऐसा कहते हैं?

— 21_23 बजे c_maker

"व्यापक सामान्यीकरण अक्सर लोकप्रिय मनोविज्ञान में एक तरफ या दूसरे में" तार्किक "या" रचनात्मक "जैसे विशिष्ट लेबल वाले होते हैं। इन लेबल को सावधानीपूर्वक व्यवहार करने की आवश्यकता होती है, हालांकि एक पार्श्व प्रभुत्व औसत दर्जे का है, ये विशेषताएं वास्तव में अस्तित्व में हैं। दोनों पक्ष, और प्रायोगिक साक्ष्य कार्यात्मक अंतर वाले पक्षों के बीच संरचनात्मक अंतर को सहसंबंधित करने के लिए बहुत कम समर्थन प्रदान करते हैं। " विकिपीडिया लेख en.wikipedia.org/wiki/Lateralization_of_brain_function से

— c_maker

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

— c_maker

@c_maker: दुर्भाग्य से, मेरे सभी मनोविज्ञान पाठ्यक्रम फ्रेंच में हैं। लेकिन मैं उन अध्ययनों का उल्लेख कर सकता हूं जो उनमें वर्णित हैं: गज़निगा 1976, स्पेरी 1968, जैडेल 1975।

जबकि मैं सम्मान करता हूं कि आप अपने तर्क का समर्थन कर सकते हैं, मेरा कहना है कि वे तारीखें बहुत पहले थीं। तब से बहुत कुछ बदल गया है। हम अभी भी अपने मस्तिष्क के बारे में बहुत कम जानते हैं लेकिन हम तब बहुत कम जानते थे।

— c_maker

Answer 3

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

1. प्रोग्रामर्स का काम उनका सॉफ्टवेयर है। वे इसकी परवाह करते हैं; वे इस पर अपना ध्यान समर्पित करते हैं; वे इसके बारे में उत्साहित हो सकते हैं। उपयोगकर्ताओं का काम कुछ और है ; सॉफ्टवेयर केवल कुछ और करने की सुविधा के लिए एक उपकरण है, और वे जितना संभव हो उतना कम समय इस पर ध्यान देना चाहते हैं ताकि वे इसके बारे में ध्यान केंद्रित कर सकें कि वे क्या परवाह करते हैं। जब तक प्रोग्रामर इसे गलत समझते हैं, वे यूआई डिजाइन में गलत ट्रेडऑफ बनाने जा रहे हैं। (इस विषय पर अधिक जानकारी के लिए, जोएल स्पोल्स्की के "अपने पर्यावरण को नियंत्रित करता है आपको खुश करता है" या डेविड एस। प्लाट के "मौलिक कानून" देखें ।)
2. प्रोग्रामर उनके सॉफ्टवेयर को गहनता से जानते हैं। वे इसके विस्तार और इसकी जटिलता के साथ सहज हैं; वे समझते हैं कि यह इस तरह से कार्य करता है क्योंकि उनके पास इसका पूरा मानसिक मॉडल है। उपयोगकर्ताओं के पास अवसर (या रुचि नहीं है; बिंदु # 1 देखें) प्रत्येक विवरण जानने के लिए, और उनके लिए पूर्ण मानसिक मॉडल होना असंभव है क्योंकि उनके पास स्रोत कोड तक पहुंच या समझने की आवश्यकता नहीं है। (मानसिक मॉडलों के महत्व के बारे में अधिक जानकारी के लिए, आप शायद डोनाड नॉर्मन की द डिज़ाइन ऑफ़ एवरीडे थिंग्स को पढ़ सकते हैं ; हालाँकि यह कंप्यूटर के लिए विशिष्ट नहीं है, यह इंटरफ़ेस डिज़ाइन पर एक अच्छी पुस्तक है।)
3. प्रोग्रामर के ट्रेडऑफ़ उपयोगकर्ता की तुलना में अलग हैं। एक प्रोग्रामर आसानी से एक सुविधा को अत्यधिक जटिल या केवल अर्ध-स्वचालित या अन्यथा उपयोग करने योग्य से कम छोड़ने का निर्णय ले सकता है क्योंकि प्रोग्रामर के लिए यह प्रयोज्य की कमी से निपटने के लिए आसान है जितना कि इसे ठीक से कोड करना है। उपयोगकर्ता परवाह नहीं करता है (बहुत) कितना प्रोग्रामर इसे ठीक से कोड करने के लिए प्रयास करता है और इसके बजाय यह पूरी तरह से उपयोग करने योग्य होगा।

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