2009-04-23 7 views
9

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

अन्य उपयोगकर्ताओं/संपादन जोड़ा जा सकता:

सवाल तरह बातें कर रहे हैं?

ग्राहकों को हटा सकते हैं?

जाहिर है इस सेटिंग को एक द्विआधारी सेटिंग है और सबसे यूआई "विशेषज्ञ" जोर देते हैं कि एक चेकबॉक्स का उपयोग करने के लिए उचित रूप तत्व है।

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

मैं स्वरुप को परिवर्तित बजाय दो रेडियो बटन का उपयोग करें:

  • हाँ ओ नहीं

व्यक्तिगत तौर पर मैं, इस आसान प्रक्रिया करने के लिए लगता है के रूप में विकल्प वास्तव में करने के लिए उत्तर दिए गए हैं बाईं तरफ सवाल पूछा।

क्लिक करने के मामले में उपयोगकर्ता को कोई फर्क नहीं पड़ता है, यह सेटिंग बदलने के लिए प्रत्येक बार एक क्लिक है।

रेडियो बटन के इस उपयोग के बारे में आप क्या सोचते हैं? क्या यह चेकबॉक्स से बेहतर या बदतर है और क्यों?

उत्तर

11

"कर सकते हैं" जैसे कुछ के लिए मैं एक रेडियो सेट के बजाय एक चेकबॉक्स का उपयोग करूंगा क्योंकि Can Do/Can not Do चेकबॉक्स की ऑन-ऑफ़ प्रकृति से संबंधित नहीं है। अधिकांश उपयोगकर्ता हां के लिए टिक टिक को समझते हैं और

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

+0

मैं निश्चित रूप से आपके दूसरे पैराग्राफ से सहमत हूं। मुझे लगता है कि मेरी विशेष स्क्रीन के साथ एक समस्या यह है कि 2 कॉलम प्रारूप सभी चेकबॉक्स को प्रश्नों से दूर ले जाता है और ऐसा लगता है कि मैपिंग में निर्मित उपयोगकर्ताओं के प्रभाव को कम करना प्रतीत होता है। (मैपिंग जिसे आप अनुच्छेद 1 में संदर्भित करते हैं)। – James

+1

सहमत, +1। चेकबॉक्स यहां प्राकृतिक विकल्प हैं। जेम्स, आप उन्हें प्रश्न के रूप में वाक्यांश नहीं मान सकते हैं, उदा। उपयोग करें [[] उपयोगकर्ताओं को जोड़ें/संपादित करें, [v] उचित शीर्षक के साथ ग्राहकों को हटाएं। – peterchen

0

एक ux परिप्रेक्ष्य से मैं कहूंगा कि चेक बॉक्स सत्य/झूठा अर्थात् प्रतिनिधित्व करता है; क्वेस्ट क्या आप चाहते हैं कि XXX समान हद तक हां के लिए टिक टिके) लेकिन एक विकल्प के लिए मैं रेडियो पसंद करूंगा (उदा। ए या बी)। अन्य रूपक हैं जैसे धक्का/पॉप आउट बटन।

1

मुझे लगता है कि अगर रेडियो हमेशा हाँ/नहीं होते हैं तो रेडियोबूटन जीयूआई को अव्यवस्थित करेंगे। रेडियोबूटन विकल्प को थोड़ा कठिन बनाने के लिए कीबोर्ड का उपयोग भी कर सकते हैं।

1

यह संदर्भ और लक्षित दर्शकों पर निर्भर करता है: आप इसका उत्तर देने के लिए आवश्यक विचार प्रक्रियाओं को कम करने का लक्ष्य रख रहे हैं।

यदि यह एक प्रश्नावली है, उदाहरण के लिए, आप शायद पूर्ण वाक्यों में पूछना चाहेंगे। स्कैन-रीडिंग के लिए एक विकल्प स्क्रीन को लक्षित किया जाएगा (इसलिए हाँ/नहीं के बजाय अनुमति दें/अस्वीकार करें), जबकि टूलबार (कुछ बार सेट/अनसेट) टॉगल का उपयोग करेगा। किसी भी मामले में, मैं स्थिरता के पक्ष में गलती करूंगा।

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

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

0

क्या आपने बाईं ओर दिए गए प्रश्न के बिना "अन्य उपयोगकर्ताओं को जोड़/संपादित कर सकते हैं" जैसे लेबल चेकबॉक्स का उपयोग करने का प्रयास किया है?

+0

नहीं, क्योंकि मैं एक मानक फॉर्म डिज़ाइन का उपयोग करने की कोशिश कर रहा हूं जिसमें हमेशा बाएं कॉलम में टेक्स्ट प्रॉम्प्ट होता है और दाईं ओर फॉर्म तत्व होते हैं। – James

1

मैं मानता हूं कि चेकबॉक्स में अधिक अंतर्निहित "सत्य"/"झूठा" अर्थ है, दूसरा बिंदु यह है कि रेडियो बटन के लिए आप उपयोगकर्ता को न तो विकल्प चुनकर सक्रिय विकल्प बनाने के लिए मजबूर कर सकते हैं। इसलिए, महत्वपूर्ण क्षेत्रों के लिए रेडियो बटन का उपयोग करना बेहतर विचार हो सकता है ताकि उपयोगकर्ता गलती से इसे याद न करे।

+0

आपकी "सक्रिय पसंद" बिंदु अच्छी है, हालांकि मेरी विशेष स्थिति के लिए आवश्यक नहीं है। धन्यवाद। – James

6

हमें वृद्धावस्था समूह के ग्राहक आधार के साथ एक अनुभव था, वे "हाँ"/"नहीं" रेडियो बटन बेहतर चेकबॉक्स को समझते हैं। और हमें चेकबॉक्स को हटाने और हर जगह रेडियो बटन डालने के लिए मजबूर होना पड़ा। गैर आईटी समझदार लोगों के लिए यह बेहतर है।

+0

हम्म, बहुत दिलचस्प है। मेरे उपयोगकर्ता आईटी समझदार नहीं हैं। – James

5

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

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

अब एक ही परिदृश्य पर विचार करते हुए चेकबॉक्स के साथ। यदि उपयोगकर्ता चेकबॉक्स को याद करता है तो हमें पता नहीं है कि उनका इनपुट इरादा या अनचाहे था या नहीं। डिफ़ॉल्ट के साथ रेडियो के लिए भी यही सच है।

परिणामस्वरूप, मैं दृढ़ता से सुझाव देता हूं कि एक फॉर्म में डिफ़ॉल्ट रूप से डिफ़ॉल्ट नहीं होना चाहिए। यदि जानकारी का एक टुकड़ा किसी उपयोगकर्ता से लेने के लिए पर्याप्त महत्वपूर्ण है तो यह सही होने के लिए पर्याप्त महत्वपूर्ण है। एक चेकबॉक्स के माध्यम से या एक चेक के साथ रेडियो के सेट के माध्यम से डिफ़ॉल्ट प्रदान करना, उपयोगिता की थोड़ी मात्रा के लिए बड़ी मात्रा में सटीकता बलिदान देता है। इसलिए, मुझे लगता है कि हाँ/नहीं रेडियो का उपयोग चेकबॉक्स से काफी बेहतर है।

मेरी राय में, चेकबॉक्स एकमात्र जगह मान्य है, जहां आपके पास विकल्पों का एक छोटा संग्रह है जिसके उपयोगकर्ता एक से अधिक का चयन कर सकते हैं। यदि संग्रह बड़ा है, तो, इसके बजाय एक चयन (बिना रिक्त डिफ़ॉल्ट विकल्प के) का उपयोग किया जाना चाहिए।

0

मुझे रेडियो बटनों का समर्थन करना या दस्तावेज़ करना वास्तव में मुश्किल लगता है।

आप लोगों को टिकबॉक्स पर टिक टिकाने के लिए कह सकते हैं, और यह उन्हें समझ में आता है।

लेकिन "रेडियो बटन" थोड़ा समझ में आता है, और "सबसे अधिक लागू होने वाले विकल्प को दबाएं" कहने के लिए सिर्फ एक बकवास बात है।

3

मेरी भावना यह है कि एक चेकबॉक्स का उपयोग किया जाना चाहिए जहां उत्तर केवल हां या नहीं हो सकता है - कुछ और नहीं, उदा। क्या आप पंजीकरण करना चाहते हैं?

रेडियो बटन जहां अन्य विकल्प हैं। जैसे क्या आप ओप्लेन टेक्स्ट ओएचटीएमएल में न्यूजलेटर चाहते हैं - कोई डिफ़ॉल्ट

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

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

0

मेरे मामले में, क्योंकि हम स्पष्ट जवाब, एक स्पष्ट हाँ की जरूरत है या नहीं, मैं दोनों एक हां और ना के लिए चेक बॉक्स का उपयोग करें:

Yes [ ]  No [ ] 

लाभ यह है कि फार्म के रूप में अच्छी तरह से कागज पर मान्य है (कभी कभी फैक्स/हस्ताक्षर आवश्यक हैं)। मुझे लगता है कि आप रेडियो बटन को चेकबॉक्स के रूप में भी स्टाइल कर सकते हैं!

+2

उर, यह भयानक है। आप डिफ़ॉल्ट चयन के बिना रेडियो बटन का उपयोग कर सकते हैं। – James

संबंधित मुद्दे