2009-04-14 4 views
16

मेरे अनुभव में, यूआई प्रोग्रामिंग बहुत समय लेने वाली, महंगी (डिजाइनर, ग्राफिक्स, आदि) और त्रुटि प्रवण है - और परिभाषा यूआई बग या ग्लिच बहुत ही कमजोर दिखाई दे रही हैं।UI प्रोग्रामिंग इतना समय लेने वाला क्यों है, और आप इसे कम करने के लिए क्या कर सकते हैं?

इस समस्या को कम करने के लिए आप क्या करते हैं?

क्या आप ऐसे समाधान के बारे में जानते हैं जो स्वचालित रूप से एक एपीआई को उपयोगकर्ता इंटरफ़ेस में परिवर्तित कर सकता है (अधिमानतः एक वेब उपयोगकर्ता इंटरफ़ेस?)।

शायद एक JMX कंसोल

  • अच्छा चूक
  • साथ की तरह कुछ, सीएसएस
  • जहां क्षेत्रों रेडियो बटन है या सूची, पाठ क्षेत्र या पाठ क्षेत्र ड्रॉप डाउन करने के लिए कॉन्फ़िगर किया जा सकता है के साथ बदलाव किया जा सकता है आदि
  • स्थानीयकृत किए जाने
  • आदि

उत्तर

10

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

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

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

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

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

कृपया एक उत्कृष्ट प्रश्न भी देखें: "Why is good UI design so hard for some developers?"

  • my own answer के लिए बेशर्म प्लग: कि कुछ बहुत ही व्यावहारिक और मूल्यवान जवाब, है विशेष रूप से।

  • Great answer कार्ल फास्ट द्वारा।

0

यदि आप पहले से ही जानते हैं या Ruby on Rails, ActiveScaffold का उपयोग करना सीख सकते हैं तो इसके लिए उत्कृष्ट है।

2

ऐसा लगता है कि आप 'नग्न ऑब्जेक्ट्स' वास्तुकला पैटर्न की तलाश में हैं। विभिन्न कार्यान्वयन उपलब्ध हैं।

http://en.wikipedia.org/wiki/Naked_objects

+0

मुझे यकीन नहीं है कि आपने यह जवाब "जवाब" एंडी के रूप में क्यों चुना होगा? यह उन सभी का सबसे सामान्य/अस्पष्ट उत्तर है। असल में मैं यह भी नहीं देखता कि दुनिया में आप संभवतः अपनी समस्या का समाधान कैसे पा सकते हैं और अपने यूआई विकास समय को नग्न ऑब्जेक्ट्स के साथ बढ़ा सकते हैं। क्या इस समाधान में आपने जो देखा है, उसके बारे में प्रतिक्रिया देना संभव होगा जिससे आपको लगता है कि यह आपके प्रश्न में आपकी समस्या का समाधान करता है? मैं व्यंग्यात्मक नहीं हूँ, मैं बस वास्तव में उत्सुक हूँ। धन्यवाद! – Jeach

+0

obvioiusly मैं ओपी के लिए बात नहीं कर सकता, लेकिन नग्न ऑब्जेक्ट फ्रेमवर्क ठीक वही करते हैं जो उन्होंने पूछा: वे एपीआई –

2

मैं एक समाधान प्रदान नहीं कर रहा हूँ, लेकिन मैं क्यों जवाब देने की कोशिश करेंगे।

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

7

मुझे विश्वास नहीं है कि यूआई प्रोग्रामिंग किसी अन्य प्रकार के प्रोग्रामिंग की तुलना में अधिक समय लेने वाली है, और न ही यह अधिक त्रुटि प्रवण है। हालांकि, यूआई में कीड़े अक्सर अधिक स्पष्ट होते हैं। एक कंपाइलर में एक त्रुटि को स्पॉट करना अक्सर अधिक कठिन होता है।

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

संपादित करें: "अप्रत्याशित" शायद एक अधिक उपयुक्त शब्द है।/जेस्पर

किसी एपीआई को उपयोगकर्ता इंटरफ़ेस में कनवर्ट करने का आपका प्रश्न मुझे समझ में नहीं आता है। तुम्हारी किस बारे में बोलने की इच्छा थी?

+0

से यूआई उत्पन्न करते हैं 'अच्छी तरह से निर्दिष्ट नहीं है और बहुत ही गलत तरीके से व्यवहार कर सकता है' - कितना सच है! +1 – Treb

+0

एपीआई क्या है यदि यह प्रोग्रामर के लिए यूजर इंटरफेस नहीं है। – Newtopian

+0

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

0

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

1

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

इसलिए मुझे नहीं लगता कि आपकी समस्या का वास्तविक समाधान है। यूआई डिज़ाइन एक जटिल कार्य है जो ठीक से करने में समय लगता है। एकमात्र ऐसा क्षेत्र जहां यह कुछ समय जीतने के लिए अपेक्षाकृत आसान है टूलिंग के साथ: यदि आपके पास उपयोगकर्ता इंटरफ़ेस के डिज़ाइन को लागू करने के लिए शक्तिशाली टूल हैं, तो आपको UI के प्रत्येक पिक्सेल को हाथ-कोड करने की आवश्यकता नहीं है।

0

ASP.NET Dynamic Data ऐसा कुछ है जिसे आप जांचना चाहिए। यदि आपकी सभी आवश्यकताओं

1

आप बिल्कुल सही हैं जब आप कहते हैं कि यूआई समय लेने वाली, महंगा और त्रुटि प्रवण है!

एक महान समझौता मैं पाया है इस प्रकार है ...

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

यह इतना तेज़ क्यों है?क्योंकि मैं एक पुन: प्रयोज्य ढांचा बनाने में सक्षम था जो कंक्रीट मॉडल का संग्रह स्वीकार कर सकता है और बिना किसी प्रयास के इन सभी मॉडलों को तालिका में प्रस्तुत कर सकता है। इतना कोड-पुन: उपयोग, यह अविश्वसनीय है।

विंडो के ऊपर एक टूलबार जोड़कर, मेरा ढांचा तालिका में प्रविष्टियों को जोड़, हटा या संपादित कर सकता है। जेटीबल्स की पूरी शक्ति का उपयोग करके, मैं विभिन्न वर्गों को विस्तारित करके (फ़िल्टर करके) छिपा सकता हूं (लेकिन केवल तभी/जब यह आवश्यक हो)।

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

ढांचे को करने के लिए पहले बहुत सारे काम और प्रयास की आवश्यकता थी, लेकिन अब यह बड़ा समय चुका रहा है।

मैं 30 से 50 विभिन्न मॉडलों के साथ पूरी तरह से नए एप्लिकेशन के लिए जीयूआई लिख सकता हूं, जिसमें मुझे 'कस्टम यूआई विधि' का उपयोग करने के समय के एक अंश में कई स्क्रीन शामिल हैं।

मैं आपको इस दृष्टिकोण का मूल्यांकन और पता लगाने की सलाह दूंगा!

+0

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

+0

मुझे यकीन नहीं है कि आप हाक्विन के बारे में क्या बात कर रहे हैं? मैं कार्यान्वयन पद्धति और सर्वोत्तम अभ्यास के बारे में बात करता हूं ... मैंने कभी-कभी उपयोगकर्ताओं, उनकी रुचि या उनके प्रयास का जिक्र नहीं किया। मेरी टिप्पणी फिर से पढ़ें। यदि आपके पास एमवीसी अनुभव है तो आप समझेंगे कि वास्तव में क्या मतलब है ... 1) कस्टम स्क्रीन और पैनलों के द्वारा जटिल यूआई से बचें 2) प्रस्तुति मानकीकृत करें (मैं जेटीबल्स का उपयोग करना पसंद करता हूं) 3) कोड/ढांचे, इस प्रकार तेजी से विकास और कम कीड़े – Jeach

0

यह कठिन है क्योंकि अधिकांश उपयोगकर्ता/ग्राहक गूंगा हैं और सीधे नहीं सोच सकते हैं! :) यह समय लेने वाला है क्योंकि यूआई देव/डिजाइनर इतने जुनूनी-बाध्यकारी हैं! :)