उपयोगकर्ता को किसी त्रुटि के बारे में कितनी जानकारी दिखाई जानी चाहिए?


38

अनुप्रयोग हमेशा त्रुटियों को फेंक सकते हैं। यदि ऐसी त्रुटि होती है, तो उपयोगकर्ता को सूचित किया जाना चाहिए, क्योंकि उसने जो आवेदन करने के लिए कहा था वह सफल नहीं हुआ है।

हालांकि, उपयोगकर्ता को कितनी जानकारी दी जानी चाहिए? मुझे लगता है कि हम में से अधिकांश स्टैक ट्रेस नहीं दिखाने पर सहमत हैं ( उपयोगकर्ता को प्रस्तुत त्रुटि संदेश में एक स्टैक ट्रेस होना चाहिए? ), लेकिन मुझे बाकी त्रुटि सामग्री या क्या दिखाना है, इस बारे में कोई प्रश्न नहीं मिल सकता है। उपयोगकर्ता।

उदाहरण के लिए, अपवादों का समर्थन करने वाली भाषा (.net, java) के पास अपवाद प्रकार साझा करने के लिए है, जहां अपवाद हुआ, और अपवाद के साथ जाने के लिए कुछ हद तक स्पष्ट संदेश। क्या यह भी उपयोगकर्ता से छिपा होना चाहिए? या फिर हमें यह दिखाना चाहिए? या हमें एक सामान्य संदेश दिखाना चाहिए? या हमें अंतर्निहित अपवाद क्या है, इसके आधार पर कई संदेशों में से एक दिखाना चाहिए?

जवाबों:


34

उपयोगकर्ता को क्या दिखाना है। क्या यह भी उपयोगकर्ता से छिपा होना चाहिए?

आप उपयोगकर्ता को दिखाते हैं कि उनके लिए क्या करने योग्य है।

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

या फिर हमें यह दिखाना चाहिए? या हमें एक सामान्य संदेश दिखाना चाहिए?

प्राथमिक त्रुटि संदेश सामग्री के रूप में अपवाद दिखाना अधिकांश उपयोगकर्ताओं के लिए व्यर्थ है । शायद अगर आपका लक्षित उपयोगकर्ता आधार डेवलपर्स है तो आप सूचना को हर समय पूर्ण त्रुटि के रूप में दिखा सकते हैं (शायद आपके पास स्वचालित परीक्षण के लिए आंतरिक अनुप्रयोग है)। लेकिन आम तौर पर उपयोगकर्ता उस ज्ञान के साथ भी कुछ अलग नहीं कर सकते हैं।

क्या हमें एक संदेश दिखाना चाहिए कि अंतर्निहित अपवाद क्या है?

निम्नलिखित करने के लिए सबसे अच्छी रणनीति है:

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

उदाहरण

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

  1. यह "यहाँ क्या हुआ" (अप्रत्याशित त्रुटि) दिखाता है
  2. उपयोगकर्ता को बताता है कि क्या करना है (मेल फिर से खोलें, यहां तक ​​कि ऐसा करने के लिए एक शॉर्टकट भी शामिल है)
  3. यदि किसी को पूर्ण तकनीकी त्रुटि देखने के लिए उत्सुक है, तो "दृश्य विवरण" भी रखें
  4. त्रुटि सूचना त्रुटि रिपोर्ट दर्ज की गई है (नीचे देखें)

ध्यान दें कि कुछ मामलों में आप त्रुटि रिपोर्ट को मैन्युअल बनाम स्वचालित बनाने की इच्छा कर सकते हैं।


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

3
@JonBentley आप इसे एक डेवलपर के रूप में देख रहे हैं, जो इस सामान को समझना चाहता है। औसत उपयोगकर्ता केवल चिंतित है कि वे बन जाएगा चाहिए यह समझ, जो वे की जरूरत नहीं है।
डेवॉर्ड

12
@deworde इसके विपरीत, मैं इसे एक उपयोगकर्ता के रूप में मान रहा हूं । एक उपयोगकर्ता के रूप में, मैं इसे तकनीकी रूप से समझना नहीं चाहता हूं, लेकिन मैं पर्याप्त जानकारी चाहता हूं कि मुझे ऐसा महसूस न हो कि सॉफ्टवेयर लिखने वाला व्यक्ति अक्षम है ("कोई त्रुटि उत्पन्न हुई है" यह धारणा देता है कि डेवलपर ने नहीं किया था ' टी पता है कि वे क्या कर रहे थे), और ताकि मैं जवाब खोज सकूं। यदि हर एक दुर्घटना कहती है "एक त्रुटि हुई है" तो Google खोज मेरी मदद करने वाली नहीं है। प्रत्येक स्थिति के लिए एक अनूठा संदेश मुझे एक ऐसे मंच पर ले जाने की अधिक संभावना है जहां किसी और को एक ही समस्या थी, और शायद इसे हल कर दिया।
जॉन बेंटले

3
@JonBentley विचार के लिए कुछ बिंदु। सबसे पहले, इस उत्तर का प्राथमिक बिंदु यह है कि आप उपयोगकर्ता को कार्रवाई योग्य जानकारी दें। यदि यह एक त्रुटि है तो वे इसे हल करने के लिए उन्हें जानकारी बताने की आवश्यकता को ठीक कर सकते हैं। यह गिर जाता है You show the user what is actionable for them। यदि आप समस्या का कारण जानते हैं, तो आप वर्णन में उपयोगकर्ता को दिखाते हैं। लेकिन आम तौर पर यदि आप किसी त्रुटि का कारण जानते हैं , तो आप उपयोगकर्ता को सूचित करने के लिए समस्या समाधान जान पाएंगे ।
एंडरलैंड

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

12

यह निर्भर करता है कि उपयोगकर्ता कौन है, और वे जानकारी के साथ क्या कर सकते हैं।

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

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

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


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

1
@piedar: यह एक अच्छी बात है।
FrustratedWithFormsDesigner

4
@piedar: त्रुटि डायलॉग में "अधिक विवरण देखें" बटन, या एप्लिकेशन लॉग फ़ाइल का लिंक संभवत: उन सूचनाओं को चाहने वाले पॉवरसुअर को सभी gory विवरण प्रस्तुत करने का एक अच्छा तरीका है। यहां तक ​​कि "डिफ़ॉल्ट रूप से विवरण दिखाएं" चेकबॉक्स, यदि आप इसे कोडिंग की परेशानी पर जाना चाहते हैं। लेकिन सभी उपयोगकर्ता ऐसा नहीं देखना चाहेंगे, और कुछ उपयोगकर्ता इसे बंद कर देंगे
FrustratedWithFormsDesigner

2
@ डंडी: आप सही हैं, लेकिन: 1) यह एक उदाहरण है। : पी 2) शायद मैं ऐसे कोड को ठीक कर रहा हूं और साफ कर रहा हूं, यही वजह है कि यह मेरे दिमाग में ताजा है ...
FrustratedWithFormsDesigner

2
@NateKerkhofs "और अगर वह डेवलपर है, तो वह बग को दोहरा सकता है" .. - ओह, यदि केवल यही सच था :(
Blorgbeard

1

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

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

बेशक वहाँ अधिक "वांछित कार्रवाई करने में असमर्थ" संदेश होने की तुलना में वहाँ जा रहे हैं कि उपयोगकर्ता वास्तव में ठीक कर सकते हैं, लेकिन यह सिर्फ जीवन है - अधिकांश अपवाद हैं क्योंकि हमने गलती की है, इसलिए नहीं कि उपयोगकर्ता पर्यावरण को सेटअप करता है गलत तरीके से।


1

यह एक सामान्य विषय है:

आप एक ही समय में अनियंत्रित / कंप्यूटर अनपढ़ों की मदद कैसे कर सकते हैं, यह दिखाने के लिए कि प्रोग्रामर, डेवलपर, परीक्षक आदि जैसे अधिक उन्नत उपयोगकर्ता उपयोग कर सकते हैं।

मुझे लगता है कि जवाब आप दोनों है!

आदेश महत्वपूर्ण है, हालांकि मैं आपको सलाह देता हूं:

  • क्या हुआ।
  • अब क्या करे
  • तकनीकी जानकारी

तकनीकी विवरण वह हिस्सा है जिसमें किसी समस्या के बारे में उन्नत आदेशों या नियमित उपयोगकर्ताओं के लिए जानकारी होती है


0

आप जो दिखाना चाहते हैं, वह इस बात पर निर्भर करता है कि आप पर शिकंजा कसा हुआ है।

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


0

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

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

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

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

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

try
{
     load_file(file_name);
}
catch (const exception& ex)
{
     exception_dialog("Failed to load file: '{1}'.", file_name);
}

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

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


खैर, यह है पक्षपातपूर्ण नज़रिए। औसत उपयोगकर्ता इस बात की परवाह नहीं करता है कि वे ऐसा क्यों नहीं कर सकते जो वे नहीं कर सकते। उन्हें केवल इस बात की परवाह है कि वे अपनी समस्या को ठीक कर सकते हैं या नहीं।
gnasher729

"औसत उपयोगकर्ता इस बात की परवाह नहीं करता है कि वे ऐसा क्यों नहीं कर सकते जो वे नहीं कर सकते। वे केवल इस बात की परवाह करते हैं कि वे अपनी समस्या को ठीक कर सकते हैं या नहीं।" यदि औसत उपयोगकर्ता को यह भी समझ में नहीं आता है कि फ़ाइल या सर्वर क्या है, तो शायद ऐसा है, लेकिन फिर भी जो "कार्रवाई योग्य" है, उस पर टिक सकता है, क्योंकि वे आपको कंधे पर टैप करने और कहने में सक्षम हो सकते हैं, "अरे , इस एप्लिकेशन का कहना है कि यह इस आवश्यक कॉन्फिग फाइल को नहीं खोज सकता है ", या इस आशय के लिए कुछ, जहां आप तब समस्या की खोज करने में सक्षम हो सकते हैं और जल्दी से इसे उनके लिए ठीक कर सकते हैं, जैसे
ड्रैगन एनर्जी
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.