मुझे अपने उपयोगकर्ताओं से सैन्य प्रारूप

Question

का उपयोग करके समय दर्ज करने के लिए क्यों नहीं पूछना चाहिए मेरे पास एक ऐसा फॉर्म है जो उपयोगकर्ताओं को किसी ईवेंट के लिए प्रारंभ और समाप्ति समय दर्ज करने के लिए कहता है। कई सालों से, हमने उन्हें तीन ड्रॉप डाउन बॉक्स से घंटा (1-12), मिनट (1-60), और एएम/पीएम चुनकर समय दर्ज करने की अनुमति दी है। इसने ग्राहकों से शिकायतों के बिना ठीक काम किया है। हालांकि, आज मुझे सैन्य समय में समय दर्ज करने के लिए इनपुट को एक टेक्स्ट बॉक्स में बदलने का अनुरोध किया गया था (उर्फ 0000 - 2359)। मेरे आंत में मेरा मानना ​​है कि यह एक बुरा विचार है लेकिन मुझे किसी भी कठिन तथ्यों के साथ परेशानी हो रही है।

मैं कौन से सबसे अच्छे कारण बता सकता हूं कि यह एक बुरा विचार होगा?

यदि समय दर्ज करने के लिए कोई बेहतर समाधान है, तो यह क्या होगा?

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

अद्यतन: मेरे सभी उपयोगकर्ता स्थानीय हैं और कोई अन्य रूप (वेब ​​या प्रिंट) मानक के रूप में सैन्य समय का उपयोग नहीं करते हैं।

Answer 1

ठीक है, एक यूजर इंटरफेस के दृष्टिकोण से, इस एक गलती बस Jakob Nielsen's user interface heuristics में से कुछ के अनुसार हो सकता है: "। प्रणाली और असली दुनिया के बीच मैच"

यदि आपके उपयोगकर्ताओं को सैन्य समय में तिथियों में प्रवेश करने के लिए उपयोग नहीं किया जाता है, तो उन्हें अपने ऐप के लिए ऐसा करने के लिए कहें, सबसे अच्छा विचलित हो सकता है, और सबसे खराब निराशाजनक हो सकता है।

"त्रुटि रोकथाम" आप त्रुटि-प्रवण स्थितियों को समाप्त नहीं कर रहे हैं, लेकिन संभवतः उन्हें पेश कर रहे हैं।

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

मेरी चिंता का विषय हो सकता है एक उपयोगकर्ता 3:30 PM प्रवेश करना चाहता है, और है, जबकि ज्यादा ध्यान नहीं, बस में प्रवेश करती है 330. यह अब 03:30 AM है, और उपयोगकर्ता कभी पता नहीं चलेगा अंतर, क्योंकि ऐप जानकारी लेता है और खुशी से मानता है कि इसका मतलब है।हालांकि, उपयोगकर्ता को "एक्सएक्स: एक्सएक्स" प्रारूप में समय दर्ज करने और "एएम/पीएम" चयन होने से अधिक समझदारी मिलती है।

जहां तक ​​कठिन तथ्य है, ठीक है, मेरे पास उनके पास भी नहीं है। लेकिन अगर आपके मालिक/ग्राहक को नील्सन की ह्युरिस्टिक्स द्वारा नहीं रोका जाएगा, तो मुझे यकीन नहीं है कि उनके दिमाग में क्या बदलाव हो सकता है।

Answer 2

तीन ड्रॉपडाउन एक दुःस्वप्न उपयोगिता-वार हैं। आप एएम/पीएम को खत्म करके और 24 घंटे के प्रारूप में जाकर इन दोनों को घटा सकते हैं, लेकिन फिर भी: 60 वस्तुओं के साथ एक ड्रॉपडाउन ओवरकिल है।

मैं, बहुत "मैन्युअल" समय दर्ज करने के लिए पसंद करते हैं चाहते प्रदान की है कि इन इनपुट बॉक्स पर्याप्त बुद्धिमान हो जाएगा (जैसे कि, वे, : एक विभाजक, आदि के रूप अनुमति देते हैं 0000 को 18 को 1800, 0 कन्वर्ट करने के लिए सक्षम होना चाहिए)। इसके अलावा उपयोगकर्ताओं को पहले स्थान पर गलत डेटा दर्ज करने की अनुमति न दें।

अपने प्रश्न का उत्तर देने के लिए: मुझे आपके उपयोगकर्ताओं को जो भी चाहिए वो करने के लिए अनुमति देने का कोई कारण नहीं दिखता है। सब के बाद, वे उपयोगकर्ता हैं।

Answer 3

मैं देख सकता हूँ तुम क्यों लगता है कि यह एक बुरा विचार है, मूर्ख उपयोगकर्ताओं इनपुट गलत प्रारूप आदि

हालांकि है आप एक jQuery Masked input box माना जाता है?

Answer 4

"वे सैन्य तरीके से संबंधित नहीं हैं।"

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

उस ने कहा, ड्रॉप-डाउन बॉक्स या तो महान नहीं हैं। मेरी राय में 2 इनपुट बॉक्स और एएम/पीएम ड्रॉपडाउन के साथ जाने के लिए सबसे अच्छा है।

Answer 5

ईमानदारी से, मुझे लगता है कि एएम/पीएम प्रारूप का उपयोग करना एक बुरा अभ्यास है, लेकिन ऐसा इसलिए हो सकता है क्योंकि मुझे 24 घंटे के पैमाने पर उपयोग किया जाता है।

एक कारण यह है कि यदि आपके सभी उपयोगकर्ता 12H पैमाने पर उपयोग किए जाते हैं, तो उनमें से अधिकतर 1:00 के लिए 13:00 के बजाय 1:00 दर्ज कर सकते हैं। चूंकि प्रधान मंत्री यहां नहीं हैं, इसके परिणामस्वरूप गलतियों का परिणाम होगा।

हालांकि, स्विच करने का एक अच्छा कारण यह है कि यह अंतरराष्ट्रीय मानक है।

जो आप जोर (गति या कार्यक्षमता) रखना चाहते हैं उसके आधार पर आप एक समय पिकर का उपयोग कर सकते हैं जो उपयोगकर्ता प्रारूप में समय को गति देने या घड़ी-जैसे नियंत्रण का उपयोग करने के लिए क्षेत्रीय सेटिंग पर निर्भर करेगा। यदि गति महत्वपूर्ण है, तो आप एक साधारण मास्क-टेक्स्टबॉक्स पसंद कर सकते हैं।

Answer 6

यह एक बुरा विचार नहीं हो सकता है। उस मामले की कल्पना करें जहां उपयोगकर्ताओं को उस जानकारी की कई बार दर्ज करना होगा, उदाहरण के लिए क्योंकि वे कॉल समर्थन में हैं। या वे ड्रॉपडाउन बक्से को पर्याप्त कोशिश नहीं कर सकते हैं, यहां तक ​​कि कोशिश करने के बाद भी। वे उस प्रारूप को पसंद कर सकते हैं।

आमतौर पर बात को हितधारक के लिए एक अच्छा विचार है और उससे पूछें: "आप इसे इस तरह क्यों चाहते हैं?" फिर आप अपने विचारों को अपने साथ जोड़ सकते हैं, लेकिन अगर आपका केवल इतना है कि आपके पास "आंत" महसूस हो रहा है कि यह सही नहीं है, तो अनुमान लगाएं कि तर्क कौन जीत जाएगा। आंत महसूस एक वैध व्यापार तर्क नहीं है - खासकर जब व्यापार आपका नहीं है।

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

Answer 7

आप jQuery timepicker (या टेलीफ़िक DateTimePicker WinForms के लिए समय-केवल मोड में) का उपयोग करने पर विचार करना चाहेंगे और जावास्क्रिप्ट अक्षम होने की स्थिति में कई प्रारूपों के लिए बैकएंड पर समर्थन में भी निर्माण करना चाहेंगे।

Answer 8

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

उदाहरण के लिए, दिनांक क्षेत्र में, मैं "01" को "01.12.2009" (वर्तमान माह + वर्ष) के रूप में स्वीकार करूंगा। एक समय बॉक्स में, मैं "1030", "10 30", "10.30" स्वीकार करूंगा (यानी मैं बस कुछ भी फ़िल्टर करता हूं जो संख्या नहीं है)। "01040 9 1125" बन जाता है 1. अप्रैल 200 9, 11:25 बजे।

Answer 9

चुनिंदा बक्से के माध्यम से दिनांक/समय इनपुट एक भयानक यूआई डिज़ाइन है।

लेकिन, यदि आपके कुछ उपयोगकर्ता कुछ देशों से आते हैं जो समय प्रारूप के लिए एएम/पीएम तक चिपके रहते हैं, तो कार्यक्रम से सहायता के बिना उन पर "सैन्य" प्रारूप को मजबूर करना भी बुरा है। jQuery masked input plugin जैसे कुछ का उपयोग करें।

अगर मैं ऐसा कर रहा था, तो मैं एक मुखौटा पाठ इनपुट और "पीएम" चेकबॉक्स का उपयोग करता हूं: यदि मान 1259 से अधिक है, तो चेकबॉक्स अक्षम है। अन्यथा, यह डिफ़ॉल्ट रूप से स्पष्ट है।

Answer 10

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

यह आपके उपयोगकर्ताओं पर निर्भर करेगा लेकिन मुझे लगता है कि समकालीन समाज में लोगों को 24 घंटे के समय के प्रारूप को समझने और उस प्रारूप का उपयोग करने में समय दर्ज करने में सक्षम होने के लिए उचित से अधिक उचित है (दिया गया है कि मैं - संभवतः नैतिक रूप से - उम्मीद है कि बस, ट्रेन, विमान और अन्य timemtables के लिए लगभग सामान्य रूप से सरल कारण के लिए प्रारूप का उपयोग किया जाना चाहिए)। शायद यह दुनिया भर में सच नहीं है - लेकिन यह यूरोप भर में निश्चित रूप से सच है।

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

Answer 11

संयुक्त राज्यों के बाहर कुछ शब्द "सैन्य समय" को जानते हैं। वे 24 घंटे का प्रारूप भी पसंद करते हैं।

आप भूमंडलीकरण चाहते हैं तो आपको दो में से एक कर सकते हैं: इस तरह के ISO8601 दिनांक स्वरूप, 24 घंटों समय के रूप में

• उपयोग को स्वीकार कर लिया और डी-कार्योत्तर मानक, और के दुःस्वप्न में
• गोता अंग्रेजी बोलते हैं विशाल क्षेत्रीय आधारित स्थानीयकरण जटिलता (कुछ दुर्भाग्यपूर्ण प्रोग्रामर वैसे भी यह करने के लिए की है। तब वे समर्थन AM/PM, यूनिकोड और कुछ संस्कृतियों के लिए कभी न दिखा पीले रंग)

Answer 12

क्यों की एक timepicker नियंत्रण का उपयोग नहीं किसी प्रकार?

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

Answer 13

मुझे विश्वास नहीं है कि इस विचार को कितना विचार मिला है। अपने उपयोगकर्ता को अपने तरीके से काम करने के लिए मजबूर करना, क्योंकि यह "अधिक कुशल" एक भयानक विचार है।

आपके फॉर्म दोनों सुव्यवस्थित होना चाहिए (पावर उपयोगकर्ता कुंजीपैड से डेटा दर्ज कर सकते हैं) और समेकित (पहली बार उपयोगकर्ता सफलतापूर्वक नेविगेट कर सकते हैं)। 24 घंटे के समय में रूपांतरण तुरंत लोगों को फेंक देगा। मैं लगभग छह वर्षों तक क्यूबेक में रहता था और अभी भी 24 घंटे से आगे और पीछे स्विचिंग की समस्याएं थीं। ऐसा मत करो।

Answer 14

बस बाकी सभी टिप्पणियों के अतिरिक्त आपको एक और चीज़ के बारे में बात करनी चाहिए।

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

बेशक, अंतिम निर्णय हमेशा भुगतान के रूप में होता है, लेकिन अगर आपको लगता है कि यह गलत है और आपको लगता है कि आप उनके से बेहतर व्यापार मॉडल जानते हैं, तो जो भी उन्होंने आपको बताया है उसे अंधाधुंध स्वीकार न करें।

Answer 15

ओह मेरा।

मेरी सलाह छोड़ना और एक अलग परियोजना ढूंढना है।

हमने "सैन्य ग्राहक" के लिए शेड्यूलिंग ऐप किया - और यहां तक ​​कि वे "सैन्य समय" के गठन पर सहमत नहीं हो सके। उनमें से आधे "ज़ुलू टाइम" नामक कुछ चाहते थे - दूसरा आधा "जीएमटी प्लस ऑफसेट" चाहता था - तब कुछ स्थानीय समय 24h प्रारूप में चाहते थे। हमारे अनुबंध को निर्दिष्ट करने के विपरीत, एक कर्नल ने जोर दिया कि हम "ज़ुलू" का उपयोग करें - हमने राजनीतिक कारणों (हमारे अनुबंध के उल्लंघन में) के लिए परिवर्तन किया - और फिर वह एक निर्धारित कार्यक्रम के लिए दिखाना चूक गया, क्योंकि उसने सोचा कि यह स्थानीय समय में था । फिर ईंटों की एक टन की तरह अनुबंध प्रबंधन नीचे आ गया।

(कभी भी ध्यान न दें कि प्रकाशित कार्यक्रम में एक अप्रचलित "ऑफसेट" भी इस्तेमाल किया गया था जो "रूसी लोगों को मूर्ख" करने के लिए एक शीत युद्ध धारक था)।

इसमें यह सिर्फ एक युद्ध-कहानी साझा करना है। । ।

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

Answer 16

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