उन कार्यों के लिए प्रगति सलाखों जो समय की अनिश्चित राशि ले सकते हैं?

Question

एक और यादृच्छिक सवाल जिसने मुझे मारा (मैंने पिछले 5 घंटों में ~ 9 कप कॉफी पी ली है, इसलिए खेद है ...) - आप किस प्रकार की प्रगति पट्टी को उपयोगकर्ता के लिए एक शो के लिए दिखाएंगे जो आप करते हैं ' टी नहीं जानता कि यह कितना समय लगेगा, लेकिन आपके पास "औसत" समय का अच्छा विचार है। उदाहरण के लिए, आमतौर पर एक कार्य जो लगभग 30 सेकंड लेता है, लेकिन आपके पास प्रगति को जानने का कोई तरीका नहीं है (इसके बावजूद यह अभी भी चल रहा है या बस विफल रहा है)। सबसे अच्छा UX ?: होगा क्या

• एक प्रगति बार है कि तेजी से बाहर शुरू होता है और नीचे है कि औसत कार्य समय लगभग 50% हिट (शायद प्रगति एक 1/एक्स शैली asymptotic वक्र होने के साथ) (ग्रहण शैली धीमा कर देती है गाइड यह सुझाव देता है)।
• एक प्रगति पट्टी जो धीरे-धीरे, स्थिर दर पर प्रगति करती है और शायद "औसत समय" को 15% या कुछ (हिट/फ़ायरफ़ॉक्स प्रारंभ में एक डोमेन की तलाश करते समय) करती है)
• एक अनिश्चित squiggly बार (मैक यह सब जगह पर है, नए विंडोज संस्करणों में यह भी है) कि किसी भी प्रगति, स्पिनर या कुछ एनीमेशन का सुझाव दिए बिना कुछ प्रकार की गति दिखाती है जो उपयोगकर्ता को यह बताती है कि कुछ चल रहा है।

क्या उत्तर अलग-अलग होगा यदि औसत समय 30 सेकंड के बजाय 10 मिनट था?

धन्यवाद, रॉबर्ट

संपादित करें:

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

Answer 1

प्रयोज्यता अध्ययन (मुझे पीडीएफ नहीं मिल रहा है) से पता चला है कि सटीक उसी अवधि में, अलग-अलग पैटर्न (घातीय, रैखिक, लॉगरिटिग) के साथ सलाखों को लोड करना, वे "तेजी से महसूस करते हैं" जहां एक्सपोनेंसी पूर्ण हो गए थे। इसका मतलब है, जो धीमा शुरू करते हैं, लेकिन समय बीतने के साथ तेज़ हो जाते हैं।

क्या मैं सामान्य रूप से करते है:

• अगर मैं औसत समय पता प्रक्रिया एक छोटे से अधिक के लिए ले जा सकते हैं, Alocate, और पिछले 20% -10% तक धीमी गति से चलते है, तो प्रगति बार को गति और वास्तविक प्रगति के साथ पकड़ता है, इस तरह के समय के साथ कि इस प्रक्रिया में इस समय समाप्त होता है कि बार में सबसे तेज़ गति है।
• मैं नहीं जानता कि यदि यह कितनी देर तक ले सकता है, मैं कई बार मापने बॉलपार्क के लिए (सेकंड? मिनट? घंटे?)
  • अपने रन के बीच थोड़ी भिन्नता के साथ एक दोहराव आपरेशन है, मैं में रखना अंतिम रन समय खाता है।
  • यदि यह लंबे समय तक चलने वाला ऑपरेशन या उच्च परिवर्तनशीलता के साथ है, तो मैं प्रगति पट्टी का उपयोग नहीं करता, बल्कि यह दिखाने के लिए एक एनीमेशन कि मैं काम कर रहा हूं।

बस अपने उपयोगकर्ताओं के लिए झूठ मत बोलो। कभी भी उन्हें बताएं कि यह एक मिनट में खत्म हो जाएगा और आधे घंटे बाद भी चल रहा है।

Answer 2

प्रगति पट्टी में वृद्धि क्यों नहीं करते क्योंकि आप किसी विधि में कार्य पूरा करते हैं?

कार्य या प्रक्रिया कितनी देर तक अप्रासंगिक है, कार्य के वाई भाग को पूरा होने पर प्रगतिबार के मूल्य को एक्स राशि से बढ़ाया जा सकता है, या आप प्रक्रिया में बहुत दूर हैं। (यानी प्रत्येक 5 किलोबाइट जिन्हें 100 किलोबाइट फ़ाइल अपलोड में संसाधित किया जाता है)

Answer 3

निश्चित रूप से बार्बर ध्रुव प्रगति पट्टी। मुझे लगता है कि यह मैक मानव इंटरफेस दिशानिर्देश (एचआईजी) पर मानक है। मुझे यकीन है कि इसी तरह के "अपरिभाषित" प्रगति सलाखों के साथ-साथ अन्य प्लेटफार्मों के लिए भी मौजूद है।

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

Answer 4

मै मैक और विस्टा स्टाइल घूर्णन सर्कल का एक बड़ा प्रशंसक बन रहा हूं जो भ्रामक उपयोगकर्ता अपेक्षाओं को सेट किए बिना प्रगति को इंगित करता है।

xkcd हास्य
http://xkcd.com/612/

Answer 5

इससे कोई फर्क नहीं पड़ता अगर एक ठीक निरंतर दर से प्रगति बार ले जाता है। दरअसल, सचमुच लिया गया, यह निश्चित रूप से लगभग असंभव होगा। आप कैसे प्रगति करेंगे कि वास्तविक प्रगति को तेज करने या धीमा करने के लिए कौन से कारक खेल सकते हैं?

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

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

मैं अब एक सिस्टम पर काम कर रहा हूं जो नियमित रूप से एक दृष्टिकोण का उपयोग करता है जो मुझे लंगड़ा लगता है: वे किसी भी सुविधाजनक चेक पॉइंट पर पूरी तरह से मनमानी प्रतिशत संलग्न करते हैं। जैसे कि कोई फ़ंक्शन डेटा का एक गुच्छा पढ़ता है, इसे टाइप करता है, इसे प्रारूपित करता है, और प्रिंट करता है, पढ़ने के दौरान 25% कहेंगे, सॉर्टिंग होने पर 50%, स्वरूपण होने पर 75%, और फिर 100% प्रिंटिंग किया जाता है। मुझे लगता है कि यह कुछ भी नहीं है।

Answer 6

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

Answer 7

सबसे अच्छी रणनीति सादा, सरल और ईमानदार होना है। बताएं कि क्या ज्ञात है, और उम्मीद सही है।

यदि यह एक लंबा समय लग सकता है, यह इस तरह के रूप, वर्बोज़ होना बेहतर है:

============================================================================== 
    Executing command xyz.. 

    Started: 10:30 AM (usually requires about 20 minutes to complete) 

    Status: 10:35:10 AM.. Still working...{this line needs to update frequently} 

    [Send to background] [Cancel] 
============================================================================== 

मैंने कहीं कुछ बड़े संस्थापक में इस तरह के वर्बोज़ विवरण देखा है; बिल्कुल ठीक नहीं हो सकता है लेकिन यह शायद ऑपरेटिंग सिस्टम या सर्वर सॉफ्टवेयर था। "इस कार्य को पूरा करने में कई मिनट लग सकते हैं" जैसे वाक्यांश इंस्टॉलर में असामान्य नहीं हैं।

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

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

1. यह निर्धारित करना संभव नहीं है कि यह कितना समय लगेगा।

2. यह अगर डाटाबेस सर्वर अटक है या एक गतिरोध

3. सभी का सबसे बुरा, आप क्वेरी निष्पादन रद्द नहीं कर सकते में लटका निर्धारित करना संभव नहीं भी है।

इस मामले में, उपयोगकर्ता को "पृष्ठभूमि" कार्य को एकमात्र अच्छी बात होगी।