Comme il faut उपयोगकर्ता इंटरफ़ेस

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

डिजाइन के लिए कौन जिम्मेदार है?

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

डिजाइन सिफारिशें

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

बटन

बटन कई रूपों में आते हैं:

• प्रत्यक्ष कार्रवाई बटन (कमांड बटन), किसी प्रकार की कार्रवाई शुरू करें;
• मेनू एक्सेस बटन, नाम खुद के लिए बोलता है;
• चेकबॉक्स और रेडियो बटन उपयोगकर्ता को विभिन्न विकल्पों में से चुनने की अनुमति देते हैं।

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

आकार:

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

स्थिति:

• बटन को एक-दूसरे के करीब रखने के लिए अवांछनीय है, उनके बीच एक खाली अंतर छोड़ना बेहतर है, क्योंकि यह एक ऐसी चीज है जब उपयोगकर्ता बटन को याद करता है, और काफी अन्य - अगर चूक गया है, तो वह गलती से एक और बटन दबाता है।
• यह उन बटनों को देखने के लिए पूरी तरह से अस्वीकार्य है जिन्हें दबाया नहीं जा सकता है; इसके बजाय, उन्हें निष्क्रिय किया जाना चाहिए, अन्यथा उपयोगकर्ता खो जाएगा ("मैं कसम खाता हूं, यह बटन अभी यहां है!")।
• समूह में दो रेडियो बटन से कम नहीं होना चाहिए (यह स्पष्ट है, हालांकि, मामले हैं ...)। इसके अलावा, कम से कम एक रेडियो बटन को डिफ़ॉल्ट रूप से जांचना चाहिए, यह अक्सर भूल जाता है।
• चेकबॉक्स और रेडियो बटन का ऊर्ध्वाधर क्रम वांछनीय है, दो या तीन स्तंभों में व्यवस्था स्वीकार्य है, लेकिन विभिन्न तरीकों से बिल्कुल नहीं। उपयोगकर्ता को तुरंत देखना चाहिए कि कौन से बटन किस समूह के हैं।

पाठ:

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

सूचियों

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

आकार:

• सूची की चौड़ाई कम से कम पर्याप्त होनी चाहिए ताकि उपयोगकर्ता इसके तत्वों के बीच अंतर कर सके।
• सूची की ऊंचाई 7-8 लाइनों से अधिक नहीं होनी चाहिए। तत्वों की यह संख्या याद रखना आसान है।

इनपुट फ़ील्ड

आकार:

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

पाठ:

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

मेन्यू

पाठ:

• मेनू का नाम सभी संभव सबसे प्रभावी होना चाहिए। आदर्श विकल्प एक शब्द का नाम है।
• यदि कोई मेनू आइटम एक संवाद बॉक्स लाता है, तो दीर्घवृत्त "..." नाम को सौंपा जाना चाहिए।
• किसी तत्व के लेबल को बदलने की तुलना में स्विचिंग तत्वों को एक चेक मार्क के साथ सबसे अच्छा चेक किया जाता है। मेनू को समय के साथ नहीं बदलना चाहिए।

माउस:

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

समूहीकरण:

• हमेशा समूह मेनू आइटम, सीमांकक के अत्यधिक उपयोग से डरो मत। आप केवल उपयोगकर्ता को अपने मेनू को तेज़ी से नेविगेट करने में मदद करेंगे।
• समूह आइटम यथासंभव तार्किक होना चाहिए, और उपयोगकर्ता के तर्क के आधार पर, न कि प्रोग्रामर।
• पारस्परिक रूप से अनन्य तत्वों को अधिमानतः एक अलग पदानुक्रम स्तर में रखा जाना चाहिए।

संदर्भ मेनू:

• संदर्भ मेनू फ़ंक्शन को कॉल करने का एकमात्र तरीका नहीं होना चाहिए।
• मेनू अधिमानतः विशेष रूप से लंबे, 7-8 आइटम नहीं बनाए गए हैं।
• संदर्भ मेनू में, आदेश विशेष रूप से महत्वपूर्ण है - पहला अधिक प्रासंगिक तत्व होना चाहिए।

अन्य

• क्षैतिज स्क्रॉलबार बहुत खराब हैं। उपयोगकर्ता उन्हें पसंद नहीं करता है।
• दस्तावेज़ का नाम खिड़की के शीर्षक बार में पहले जाना चाहिए, और उसके बाद ही आवेदन। एक ज्वलंत उदाहरण Microsoft Word 2003 है: "Microsoft Word - Document1.doc", और कार्य पट्टी में बड़ी संख्या में खुली खिड़कियों के साथ, दस्तावेजों के नाम अलग-अलग नहीं होंगे।
• स्टेटस लाइन को या तो सिस्टम की स्थिति के संकेतक के रूप में या उन्नत उपयोगकर्ताओं के लिए टूलबार के रूप में उपयोग किया जाना चाहिए। जब आप किसी विशेष विंडो तत्व पर होवर करते हैं तो सबसे खराब विकल्प टूल बार के रूप में स्टेटस बार का उपयोग करना है।
• टूलबार फ़ंक्शन को कॉल करने का एकमात्र तरीका अवांछनीय है।

सिस्टम प्रतिक्रिया:

• यदि सिस्टम एक लंबा ऑपरेशन करता है, तो कर्सर को "एक घड़ी के साथ कर्सर" में बदलना होगा। किसी भी स्थिति में, उपयोगकर्ता को सूचित किया जाना चाहिए कि सिस्टम कुछ कर रहा है, बेकार नहीं।
• लंबे समय तक संचालन के लिए, उपयोगकर्ता को ध्यान देना चाहिए। उदाहरण के लिए, एक प्रगति पट्टी आश्चर्यजनक है, लेकिन यह समय को गति देती है। आप किसी प्रकार की ध्वनि का उपयोग भी कर सकते हैं (उदाहरण के लिए, त्यागी में, जब आप सौदा करते हैं, तो कार्ड की आवाज़ सुनाई देती है)।
• जब सिस्टम ने एक लंबा ऑपरेशन पूरा किया है, तो आपको उपयोगकर्ता को सूचित करने की आवश्यकता है, उदाहरण के लिए, "स्क्वीक"।

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

साहित्य का इस्तेमाल किया

वी.वी. गोलोवच। "यूजर इंटरफेस डिजाइन । "
जेफ रस्किन। "इंटरफ़ेस: कंप्यूटर सिस्टम के डिजाइन में नई दिशाएं । "
जेनिफर टिडवेल। "उपयोगकर्ता इंटरफेस का विकास । "
एलन कूपर और स्टीव क्रूग की सिफारिशें।