क्या त्रुटि संदेशों को माफ़ी माँगनी चाहिए? (2013)
इस पर मतभेद है कि सॉफ़्टवेयर को त्रुटि संदेशों में “sorry” कहना चाहिए या नहीं: कुछ लोग मानवीय, सहानुभूतिपूर्ण भाषा पसंद करते हैं, जबकि अन्य संक्षिप्त, मशीन-जैसी सटीकता चाहते हैं। कई लोगों का तर्क है कि माफ़ियाँ, चुटकुले, और चुलबुली भाषा असत्य या संरक्षकभावी लगती हैं, खासकर जब वे इस तरह की उपयोगी जानकारी को ढक देती हैं कि क्या गलत हुआ, आगे क्या करना है, या खोजने के लिए कोई error code क्या है। अन्य लोग नोट करते हैं कि स्वर और अप्रत्यक्षता सांस्कृतिक रूप से निर्भर हो सकती है, लेकिन व्यापक सहमति है कि विनम्रता से अधिक महत्वपूर्ण स्पष्टता, संक्षिप्तता, और समाधान की ओर मार्गदर्शन है।
क्या त्रुटि संदेशों को माफ़ी माँगनी चाहिए
- कई लोग तर्क देते हैं कि “sorry” आमतौर पर अनावश्यक भराव है। यह शायद ही कभी उपयोगकर्ताओं को समस्या से उबरने में मदद करता है और अक्सर असत्य या बनावटी लगता है, क्योंकि विफलता के क्षण में सॉफ़्टवेयर और इंजीनियर वास्तव में मौजूद नहीं होते या भावनात्मक नहीं होते।
- कुछ लोगों का मानना है कि माफ़ी केवल गंभीर या अपूरणीय समस्याओं के लिए उपयुक्त है (जैसे डेटा हानि, लंबा आउटेज) या जब संगठन ने स्पष्ट रूप से विफलता की हो और उसे ठीक करने के लिए काम कर रहा हो।
- अन्य लोग एक विनम्र माफ़ी को अच्छी ग्राहक सेवा का हिस्सा मानते हैं: यदि उपयोगकर्ता रुक गया है, तो उत्पाद ने उसे निराश किया है, भले ही उसने “गलत तरीके” से इस्तेमाल किया हो।
स्वर: मानवीकृत बनाम मशीन-जैसा
- चुलबुले, बचकाने, या अत्यधिक हँसमुख संदेशों (“oopsie”, mascots, स्माइली/फ्राउनी चेहरे) के प्रति तीव्र नापसंदगी है। इन्हें संरक्षकभावी, अव्यावसायिक, और विशेष रूप से चुभने वाला माना जाता है जब उपयोगकर्ता तनाव में हों।
- एक बड़ा समूह संक्षिप्त, निरपेक्ष, “मशीन-जैसे” त्रुटि संदेशों (Unix-शैली) को पसंद करता है जो मानवीकरण और बनावटी सहानुभूति से बचते हैं।
- कुछ लोग हल्के मानवीय स्वर (“we’re sorry, your email failed to send”) को पसंद करते हैं ताकि यह न लगे कि सॉफ़्टवेयर डाँट रहा है, बशर्ते वह संक्षिप्त और सम्मानजनक हो।
स्पष्टता, क्रियान्वयन योग्य होना, और विवरण
- व्यापक सहमति है कि मुख्य आवश्यकताएँ हैं:
- क्या गलत हुआ, इस बारे में संक्षिप्त और विशिष्ट रहें।
- अंतिम उपयोगकर्ताओं के लिए जार्गन से बचें या उसे समझाएँ।
- बताएं कि उपयोगकर्ता आगे क्या कर सकता है (पुनः प्रयास, प्रतीक्षा, इनपुट बदलना, किसी से संपर्क करना, लिंक का पालन करना)।
- ऐसे पहचानकर्ता या कोड दें जिन्हें खोजा जा सके या समर्थन को दिया जा सके।
- अस्पष्ट “Something went wrong. Sorry.” संदेशों की बहुत आलोचना होती है; वे उपयोगकर्ताओं को रोकते हैं और उपयोगी निदान छिपाते हैं।
दर्शक, ज़िम्मेदारी, और एजेंसी
- इनमे भेद किया जाता है:
- उपयोगकर्ता-मुखी संदेश (विनम्र, उच्च-स्तरीय, कार्रवाई-केंद्रित)।
- डेवलपर/प्रशासक संदेश (अधिक तकनीकी, इनमें stack traces, config paths, आदि शामिल हो सकते हैं)।
- एक लंबा उप-थ्रेड “कौन बोल रहा है” पर बहस करता है: उपयोगकर्ता का टूल, विक्रेता, या प्रशासक। मुक्त/ओपन-सोर्स संदर्भों में, माफ़ी माँगना ऐसा नियंत्रण संबंध संकेत कर सकता है जिसे कुछ लोग अनचाहा मानते हैं; मालिकाना/विक्रेता-नियंत्रित सॉफ़्टवेयर में, कंपनी की ओर से माफ़ी अधिक उपयुक्त मानी जाती है।
संस्कृति और भाषा
- कुछ अंग्रेज़ी बोलियाँ “sorry” का उपयोग दोष स्वीकार करने के बजाय सहानुभूति व्यक्त करने के लिए करती हैं; अन्य इसे गलती स्वीकार करना समझते हैं, जिससे त्रुटि-माफ़ियों को कैसे देखा जाता है, यह प्रभावित होता है।
- कई गैर-अमेरिकी वक्ता नोट करते हैं कि स्थानीयकृत UI अक्सर “please/sorry” को पूरी तरह हटा देते हैं क्योंकि वे अनावश्यक या सांस्कृतिक रूप से असंगत होते हैं।
हास्य और अपमान
- कम जोखिम वाले मामलों में हल्का हास्य या easter eggs सराहे जा सकते हैं।
- गंभीर विफलताओं में अत्यधिक चुलबुलापन या मज़ाक व्यापक रूप से नापसंद किया जाता है।
- कुछ लोग niche या game संदर्भों में जानबूझकर तंजभरे या आक्रामक त्रुटि संदेशों का आनंद लेते हैं, लेकिन मानते हैं कि यह सामान्य सॉफ़्टवेयर के लिए उपयुक्त नहीं है।