जवाबों:
उचित इनपुट सत्यापन की कमी उन चीजों में से एक है जो उपयोगकर्ताओं को आपके आवेदन के साथ "खराब" चीजें करने के लिए बहुत तेज़ी से नेतृत्व करती है, जब इसे प्रोग्रामर द्वारा वास्तव में नियंत्रित किया जाना चाहिए।
मैंने लीगेसी ऐप्स देखे हैं जहाँ उपयोगकर्ताओं को इसके लिए प्रशिक्षित किया गया है:
a-z0-9,emailफ़ील्ड में दर्ज किया जा रहा है , अन्यथा उस उपयोगकर्ता को बाद की मेलिंग फ़ील्ड में जो भी है उसका उपयोग करेगी और विफल हो जाएगीhttp://" वेब पते से पहले रखा गया हैआदि आदि
उपरोक्त सभी मुद्दे ऐसे हैं, जिन्हें एक एप्लिकेशन डेवलपर द्वारा नियंत्रित किया जाना चाहिए । जब आपका इनपुट सत्यापन अनिवार्य रूप से होता है "सुनिश्चित करें कि उपयोगकर्ता जानता है कि यह फ़ील्ड किस प्रारूप में होनी चाहिए और जो उन्होंने दर्ज किया है वह सही है पर भरोसा करें", तो अप्रत्याशित चीजें ऐप में अपना रास्ता खोजने के लिए बाध्य हैं। स्पष्ट सुरक्षा निहितार्थ के अलावा, उपयोगकर्ता गलतियाँ करते हैं। प्रोग्रामर के रूप में हम अक्सर यह सुनिश्चित करने के लिए पीछे की ओर झुककर अपने सर्वश्रेष्ठ उत्पादों का उत्पादन करते हैं कि उपयोगकर्ता इसे गलत नहीं कर सकते , चाहे वे कितनी भी कोशिश कर लें!
http://सत्यापन बिंदु के लिए एक ही कहानी । एक उदाहरण के रूप में, ASDFयह एक भोली तरीके से करता है, और इसका परिणाम यह है कि आप उन डोमेन पर पैकेज होस्ट नहीं कर सकते हैं जो उपयोग करते हैं https://।
मुझे एक बार एक ग्राहक सहायता कॉल मिली क्योंकि मेरा ऐप अभी गायब हो गया। पता चला कि उन्होंने इसके ऊपर एक और ऐप खोला है।
... मैंने यह सुनिश्चित करने का निर्णय लिया कि यह फिर से न हो, क्योंकि यह उपयोगकर्ता कंप्यूटर निरक्षरता था जो समस्या का कारण था, ऐप नहीं। मैं इसे ठीक करने के लिए जो कुछ भी कर सकता था, वह दूसरों के लिए एक खराब उपयोगकर्ता अनुभव होगा।
लगभग हर कार्यक्रम जो मैं लिखता हूं उसे कमांड लाइन से सख्ती से लागू किया जाता है। मैंने कुछ कट्टर बातें भी लिखी हैं जो सीएलआई इंटरफेस के रूप में शुरू हुई हैं और तेजी से कुछ की तुलना में अधिक शेल में बढ़ी हैं।
इसलिए, मैं केवल वही जानता हूं जो मैं जानता हूं। यहाँ कमांड लाइन प्रोग्राम के साथ कुछ सामान्य मुद्दे हैं:
बहुत सारे विकल्प
जब तक आप एक संकलक या एक पंक्ति संपादक नहीं लिख रहे हैं, तब तक 80x25 फ्रेम बफर पर एक स्क्रीन तक सीमित विकल्पों को रखने की कोशिश करें जब --helpया /?पास हो। इससे अधिक विकल्प होना पूरी तरह से ठीक है, लेकिन उन्हें उप श्रेणियों में तोड़ दें। उदाहरण के लिए
foo --help
foo --help option_name
कोई लंबा विकल्प नहीं
इसे याद रखना जितना आसान है याद रखना foo --attach_to [argument] --volatile --verboseउससे कहीं ज्यादा आसान है foo -a [arg] -v +V। यह हमेशा संभव नहीं है, लेकिन ज्यादातर मामलों में, यह है।
कोई इनपुट सत्यापन नहीं
लगभग हर प्लेटफ़ॉर्म में कई पुस्तकालय होते हैं जिन्हें पार्स करने और तर्कों को मान्य करने की कोशिश की जाती है, परीक्षण किया जाता है और सच होता है। लगभग हर प्लेटफ़ॉर्म में एक आजमाया हुआ, परीक्षण किया हुआ और सच्चा अक्षर होता है जो एक CLI से इनपुट को मान्य करता है। एक, दूसरे या दोनों का उपयोग करें। यदि आपका प्रोग्राम किसी उपयोगकर्ता द्वारा प्रदान की गई चीज़ों के कारण शून्य से विभाजित या विभाजित होता है, तो यह शर्मनाक है।
आपको एक लेक्सर के रूप में जटिल के रूप में कुछ की आवश्यकता नहीं हो सकती है, शायद आप स्ट्रिंग को टोकन कर सकते हैं यदि आप एक निश्चित क्रम में सामान के साथ कुछ निश्चित स्थानों में सामान की उम्मीद कर रहे हैं।
मुझे वास्तव में एक बग रिपोर्ट मिली जहां एक पूर्णांक की उम्मीद थी और किसी f*** my lifeने उद्धरण में टाइप किया। मैंने उस कार्यक्रम को नहीं लिखा था, मुझे इसे विरासत में प्राप्त करने का दुर्भाग्य था।
कोई 'क्रिया' घुंडी नहीं
अनुभवी उपयोगकर्ताओं को आसानी से यह पता लगाने की अनुमति दें कि आपके कार्यक्रम से अधिक शोर प्राप्त करने का तरीका अधिकांश लोगों की तुलना में बर्दाश्त करेगा, लेकिन केवल गंभीर और महत्वपूर्ण सामानों को मुद्रित करने के लिए डिफ़ॉल्ट। मैं आपको यह नहीं बता सकता कि कितनी बार मुझे straceबस यह महसूस करना पड़ा कि कुछ सेगफ़ॉल्ट हुआ क्योंकि यह NULL फाइल स्ट्रीम पर संचालित होता है।
आप अभिकथन को भी लपेट सकते हैं ताकि NDEBUG या अन्य साधनों के माध्यम से उन्हें बंद कर दें, फिर भी उपयोगकर्ता को खोजने के लिए कुछ मुद्रित या लॉग इन किया जाता है।
लॉग फ़ाइलों की बात करते हुए, यह सुनिश्चित करने का प्रयास करें कि आप उनमें जो भी जगह रखते हैं, वह आपके अलावा किसी और को (कम से कम थोड़ा) समझ में आता है। यदि प्रत्येक प्रविष्टि की शुरुआत एक यूनिक्स युग की तारीख है, तो आप किसी ऐसे व्यक्ति में निराशा को जा रहे हैं जो वास्तव में बग को पुन: पेश करने में आपकी सहायता करना चाहता है।
डिबग मोड में कोई 'बग मित्र' नहीं है
बहुत सारे कार्यक्रम कुछ प्रकार के 'डिबग' स्विच प्रदान करते हैं जो कार्यक्रम के साथ चल रहे अतिरिक्त चैटर की पेशकश करते हैं, लेकिन बहुत कम ही निम्नलिखित प्रस्ताव देते हैं:
या, शायद आप लोगों को फोन पर निम्नलिखित पढ़ते हुए सुनना पसंद करते हैं:
यह कहते हैं कि अप्रत्याशित स्थिति में शून्य eff ओह चार शून्य ओह .... ठीक है lemme पढ़ा है कि आप को वापस ...
अत्यधिक जटिल कॉन्फ़िगरेशन फ़ाइलें
बहुत सारे सिंटैक्टिक शुगर पर चर्चा करने के लिए एक बहाने के रूप में एक कॉन्फ़िगरेशन को पार्स करने की आवश्यकता को उचित न करें। एक प्रारूप का उपयोग करने का प्रयास करें जो लोग वास्तव में जानते हैं, भले ही इसका मतलब है कि जब पार्स करते समय अतिरिक्त काम किया जाए। मैं जब भी संभव हो INI शैली प्रारूप का उपयोग करने का प्रयास करता हूं। आप चकित होंगे कि आप एक साधारण कुंजी-> मूल्य शब्दकोश के साथ क्या खींच सकते हैं।
कोई कॉन्फ़िगरेशन फ़ाइल नहीं
लोगों को केवल अपने प्रोग्राम का उपयोग करने के लिए शेल स्क्रिप्ट या बैच फाइल न लिखें, जब तक कि यह किसी भी कार्य के लिए एक उपकरण न हो। मुझे अपने सामान्य विकल्पों वाली फ़ाइल को इंगित करने का एक साधन दें और कुछ अतिरिक्त तर्क प्रदान करें।
कोई 'गीला तल' संकेत नहीं
यदि कुछ सुविधा उपयोगकर्ता को परेशानी में डाल सकती है (शायद यह उन्नत उपयोगकर्ताओं के लिए है), तो इसे स्पष्ट रूप से चिह्नित करें। इसके अतिरिक्त, यदि कोई व्यक्ति मोटी उंगलियों के इनपुट या कुछ भूल जाता है, तो क्या आपने ऑन-लाइन प्रलेखन के लिए एक बहुत ही अनुकूल लिंक प्रिंट किया है। आप केवीएम के माध्यम से अपने प्रोग्राम का उपयोग करने वाले किसी व्यक्ति के साथ व्यवहार कर सकते हैं और कट और पेस्ट नहीं कर सकते।
जब संभव हो, (यह इनपुट सत्यापन के साथ मेल खाता है) Google apporach का उपयोग करें:
क्या आपका मतलब foo --bar FILENME है, आपने केवल foo --bar टाइप किया है
विनाशकारी निर्देशों से बाहर का रास्ता पेश करें
लक्ष्य उपयोगकर्ता को यह बताना है कि यह क्यों काम नहीं किया और उन्हें कुछ और समय देने की कोशिश की, जबकि यह सुनिश्चित करना कि आप संभावित रूप से विनाशकारी कुछ भी नहीं करते हैं जब तक कि यह प्रतीत नहीं होता है कि उपयोगकर्ता वास्तव में आपको ऐसा करना चाहता है। उदाहरण के लिए, 'नेगिंग' को बंद करने वाले स्विच को अनुमति दें -Yया /Yअन्यथा किसी ऐसे व्यक्ति को बाहर निकलने की अनुमति दें जिसके पास बस 'मोटी उंगलियां' हों।
मैं शायद कुछ संकेत भूल रहा हूँ। मैं अक्सर इससे निपटता हूं क्योंकि यह बहुत मुश्किल है, कुछ लोगों के लिए 'लो लेवल' इंटरफेस को सहज बनाने के लिए, ज्यादातर लोग गलतियों से बचने के लिए।
"क्या आप वाकई इस फ़ाइल / रिकॉर्ड को हटाना चाहते हैं? हां / नहीं"। हाँ पर क्लिक किया गया और फिर एक कॉल आया कि उसने "गलती से" रेड डिलीट बटन पर क्लिक कर दिया और उसे उस डेटा को वापस चाहिए :)
मुझे ऐसा नहीं लगता है कि विशिष्ट ब्रेक / फिक्स उदाहरण प्राप्त करना उतना ही महत्वपूर्ण है जितना कि इसे साकार करना:
अगर उस अन्वेषण के माध्यम से वे कुछ तोड़ते हैं, तो एक प्रोग्रामर के रूप में यह आपका काम है कि वे या तो उन्हें खतरे से आगाह करें या इसे पहले स्थान पर होने से रोकें। मुझे याद नहीं है कि मैंने इसे अभी कहां देखा है, लेकिन मेरे दिमाग के पीछे मैं हमेशा अपने सॉफ़्टवेयर के उपयोगकर्ता के लिए " सही काम करना आसान बनाने " की कोशिश करता हूं।
यदि आप उदाहरणों पर जोर देते हैं:
देखें यह कहाँ जा रहा है? :)
यहाँ एक मैं इस सप्ताह सुना है। एक उपयोगकर्ता एक सुविधा के लिए पूछता है "जब कोई घटना होती है तो मुझे एक अधिसूचना भेजें"। पर्याप्त सरल और डेवलपर आगे बढ़ता है और इसे लागू करता है। निश्चित रूप से, पहला प्रश्न "इस अधिसूचना द्वारा संबोधित करने की कोशिश कर रहे हैं?" होना चाहिए था। मैं इसमें नहीं जाऊंगा कुछ दिनों बाद डेवलपर द्वारा उपयोगकर्ता बंद हो जाता है और पूछता है "मुझे यह सूचना मिली है। मुझे इसके साथ क्या करना चाहिए?"।
मुझे यह दिलबर्ट कॉमिक याद आया और डेवलपर को सुझाव दिया गया कि "उपयोगकर्ता को उस अधिसूचना के साथ क्या करना चाहिए, यह जानने के लिए एक ऐप लिखें"।
जैसे मपेटरसन ने कहा, उपयोगकर्ता विशेषज्ञता के अपने क्षेत्र में बहुत प्रतिस्पर्धी है। वे सिर्फ एक सॉफ्टवेयर डेवलपर या डिजाइनर की तरह नहीं सोचते हैं।
मुझे नहीं लगता कि उपयोगकर्ता बेवकूफ हैं। वे आपके या किसी भी कार्यक्रम का उपयोग नहीं करना चाहते हैं। वे चाहते हैं कि उनकी चीजें पूरी हों। उनकी मदद करें और रास्ते में उनके साथ होने वाले नुकसान को रोकें।
एक अच्छा उपयोगकर्ता इंटरफ़ेस होना और पर्याप्त सीखने का अनुभव प्रदान करना उपयोगकर्ताओं को बुरे काम करने से रोकने की दिशा में एक लंबा रास्ता तय करता है।
अच्छा उपयोगकर्ता इंटरफ़ेस घर्षण रहित होना चाहिए।
एक डायलॉग बॉक्स (एक महंगा ऑपरेशन, और एक जिसे उपयोगकर्ता थोड़ी देर के बाद नजरअंदाज करते हैं) को हटाने के बजाय हटाए जाने की पुष्टि करते हैं, हटाते हैं, और पूर्ववत करने का एक तरीका प्रदान करते हैं।
अच्छा उपयोगकर्ता इंटरफ़ेस खोज योग्य होना चाहिए।
हालाँकि Microsoft Office में रिबन को बहुत अधिक परत मिलती है क्योंकि यह Word के पुराने उपयोगकर्ताओं को अपने तरीके बदलने के लिए मजबूर करता है, रिबन इस बात का एक चमकदार उदाहरण है कि आप एक इंटरफ़ेस को खोज योग्य कैसे बना सकते हैं (यानी खोज करना आसान)।
अच्छा उपयोगकर्ता इंटरफ़ेस, अच्छे कोड की तरह, आत्म-व्याख्यात्मक होना चाहिए।
कोई भी मैनुअल नहीं पढ़ता है। एकमात्र मैनुअल जो मुझे कभी पढ़ने के लिए मिला, वह था एक पॉवरपॉइंट प्रस्तुति जिसमें सॉफ्टवेयर के चरण-दर-चरण वॉकथ्रू शामिल थे। मैंने इन्हें Camtasia जैसे वीडियो टूल्स के साथ देखा है, लेकिन PowerPoints बेहतर हैं क्योंकि आप आसानी से पीछे की ओर और आगे की ओर कदम बढ़ा सकते हैं।
उपयोगकर्ता गलतियाँ नहीं करते। प्रोग्रामर के साथ गलतियाँ होती हैं जो प्रयोग करने योग्य इंटरफ़ेस बनाने में विफल रहीं।
इसलिए प्रत्येक रिलीज के साथ प्रयोज्य परीक्षण करें!