बचत बटन क्यों आवश्यक है?

OneNote जैसे सॉफ़्टवेयर ने दिखाया है कि ऑटो-सेव को कार्यान्वित किया जा सकता है, और यह मैन्युअल सेव बटन/CTRL + S के रूप में भी (या बेहतर) काम करता है।बचत बटन क्यों आवश्यक है?

वैसे भी जो भी आप काम करते हैं वह सहेजा जाता है। यह सिर्फ अगर आप कुछ विनाशकारी कोशिश कर रहे हैं कि आप बचत के बिना बंद कर देंगे।

तो प्रोग्रामर/उपयोगिता परिप्रेक्ष्य से, मैनुअल "सेव" सुविधा आज भी लगभग सभी सॉफ्टवेयर में क्यों देखी गई है? क्या ऐसा इसलिए है क्योंकि जब भी डेटा संशोधित होता है तो "ऑटो-सेव" लागू करने के लिए हर कोई आलसी है?

और क्या हमारे लिए हमारे विशिष्ट उद्योग और हमारे प्रतिस्पर्धियों में कुछ कर्षण शुरू करने के लिए ऑटो-सेव को लागू करना एक अच्छा विचार है?

स्रोत

2009-08-18 Robin Rodricks

+10

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

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

इस बिंदु पर मुझे एक नोट प्रकार की चीज है। मैं चीजों को स्पष्ट रूप से सहेजने में सक्षम होना चाहता हूं, ऑटो सेव एक आपातकालीन वसूली विकल्प होना चाहिए। – StingyJack

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

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

"skeuomorph" की परिभाषा :)

स्रोत

2009-08-18 17:09:31 Jason

मेरा मानना है कि जॉन स्कीट के कार्यक्रम केवल जब जॉन चाहते हैं तो ऑटो सेव करते हैं। –

"अधिक कमजोर" ... जिसे "कम बार-बार" भी कहा जाता है? – rmeador

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

ऑटोसव सामान्य रूप से परिभाषित अंतराल पर बचाता है। क्या होता है यदि आप अंतराल के बीच में बचत करना चाहते हैं?

आपको पर्यावरण में अन्य अनुप्रयोगों के साथ मिलकर रहने के लिए मैन्युअल सेव को कार्यान्वित करना चाहिए।

लोग फ़ाइल -> सेव, या CTRL + S मौजूद होने की अपेक्षा करते हैं।

स्रोत

2009-08-18 17:01:17 Erix

जब भी किसी विशेष सीमा से परे डेटा जोड़ा/संपादित किया जाता है तो ऑटोवॉव ट्रिगर नहीं किया जा सका? इस तरह आप हमेशा किसी भी महत्वपूर्ण बदलाव को पुनर्प्राप्त करेंगे। –

@ जेरेमी रुड: "महत्वपूर्ण" परिवर्तन जरूरी बड़े बदलाव नहीं हैं। – Kip

+1 "लोग उम्मीद करते हैं कि फ़ाइल -> मौजूद रहें"। IME यह सहेजने सहित किसी भी प्रतीत होता है अनावश्यक ऑपरेशन के लिए यह एकमात्र सबसे महत्वपूर्ण कारण है। –

शायद व्यक्तिपरक टैग किया जाना चाहिए?

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

उसने कहा, मुझे कुछ स्थितियों में इसे स्वीकार करने के लिए "प्रशिक्षित" किया गया है। OneNote, उदाहरण के लिए, या टॉम्बाय। एक बहुत सारे ओएस एक्स ऐप्स इस पैटर्न का पालन करते हैं, विशेष रूप से उपयोगिता ऐप्स जैसे डीबी सर्वर जीयूआई उपकरण।

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

स्रोत

2009-08-18 17:02:53

इसके अतिरिक्त "सहेजने" के साथ आमतौर पर "के रूप में सहेजें .." भी होता है। दोनों उपयोगकर्ता को नियंत्रण और सुरक्षा की भावना देते हैं। यह जानकर कि वे क्लिक पर क्लिक करते हैं, उन्हें यह बताते हैं कि वे किस स्थिति में अपने डेटा को फिर से लोड करते समय उम्मीद कर सकते हैं।

स्रोत

2009-08-18 17:04:11 BobBrez

चेक मुझे लगता है कि इसका जवाब है कि 'यह निर्भर करता है' है!

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

OneNote के लिए एक बहुत ही सामान्य उपयोग-मामला यह है कि कोई व्यक्ति कुछ जानकारी में डंप करने के लिए इसे खोलता है, जिस पर वे काम कर रहे हैं। उन्हें जल्दी से अंदर और बाहर जाने की जरूरत है। बचत के बारे में कोई संकेत एक उपद्रव होगा।

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

स्रोत

2009-08-18 17:11:49

जैसा कि लोगों ने यहां उल्लेख किया है, हालांकि, उनके उपयोग के मामले बहुत अलग नहीं हैं। लोग- कभी-कभी OneNote में किसी निश्चित स्थिति को स्पष्ट रूप से सहेजने में सक्षम होने के लिए, यह विकल्प उपलब्ध नहीं होता है। – Kzqai

ऑटो-सेव को कार्यान्वित करना मुश्किल नहीं है - केवल सामान्य बचत को लागू करें और जब कभी आवश्यकता हो या केवल टाइमर में कॉल करें (यदि आप आलसी हैं)।

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

डेटा या फ़ाइलों को लगातार मेमोरी में लगातार स्टोरेज से लोड करें।
मुख्य मेमोरी में डेटा को संशोधित करें।
संशोधित डेटा को एक सतत भंडारण में वापस सहेजें।

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

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

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

तो, हाँ, मैं वास्तव में गायब होने के लिए सहेजने (और लोड) बटन देखना पसंद करूंगा। मैं पूर्ववत जानकारी या यहां तक कि पूर्ण संपादन इतिहास भी जारी रखना चाहता हूं। लेकिन मुझे नहीं लगता कि यह परिवर्तन कुछ सालों में हो सकता है - अगर कभी।

स्रोत

2009-08-18 17:21:22

यह वास्तव में नीचे आता है: एक सहेजें बटन पूर्ववत से लागू करने और बनाए रखने के लिए सस्ता है।

स्रोत

2009-08-18 17:29:39

+1 मुझे लगता है कि यह सादगी के साथ संबंध है। यदि आपको मैन्युअल सेव विकल्प (शायद आप करते हैं) की आवश्यकता है तो ऑटो-सेव जोड़ना एक -extra- सुविधा बन जाता है, और हो सकता है कि वारंट के लिए ** पर्याप्त ** अतिरिक्त मूल्य न हो, जिसमें मैन्युअल सेव और ऑटो-सेव और दोनों के बीच आवश्यक संचार हो उन्हें। – Kzqai

प्रोग्रामर परिप्रेक्ष्य से ऑटोटोव लागू करने से एक बड़ा सौदा नहीं होगा। आपने बस एक टाइमर सेट किया है और कॉलबैक बचत करेगा।

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

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

स्रोत

2009-08-18 17:31:04 hhurtta

संक्षिप्त उत्तर: "ऑटो सेव" = "ऑटो नष्ट"/"ऑटो < अपूर्ण >"।

स्रोत

2009-08-18 17:37:43 Roboprog

नहीं, ऑटो-सेव ठीक है, जब तक कि इसका स्पष्ट रूप से बचाए जाने पर कोई प्रभाव नहीं पड़ता है। यदि ऑटो-सेव एक अलग सेव फ़ाइल है, तो यह मूल्य जोड़ा जा सकता है। – Kzqai

दिलचस्प। यह थोड़ा और सूक्ष्म है, लेकिन एक अच्छा मुद्दा है। एक वसूली बफर कहीं और रखें, लेकिन मुझे अपने डूडल की वर्तमान स्थिति कुछ ऐसा है जो बचाया जाना चाहिए या नहीं। – Roboprog

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

स्रोत

2009-08-18 17:44:15

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

आप निश्चित रूप से एक ऐसा ऐप्लिकेशन बना सकते हैं जो इनमें से किसी भी विचार को ध्यान में रखे, लेकिन क्या यह अतिरिक्त प्रयास के लायक होगा?

तो क्या हमें सहेजें बटन से छुटकारा पाना चाहिए? निर्भर करता है।

स्रोत

2009-08-18 19:20:24

विश्वविद्यालय में एक परियोजना के लिए, मेरे समूह और मैंने एक प्रयोग के रूप में स्पष्ट बचत के बिना एक आवेदन बनाया।

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

दो समस्याएं थीं: एक, हमारे पास इसे पूरी तरह से सही करने के लिए समय नहीं था (आह, युवा हब्रिज); दो, हर किसी (साथी छात्रों और, सबसे महत्वपूर्ण बात यह है कि टीए) ने पहले ही उल्लेख किए गए सभी कारणों से नफरत की है।

कभी-कभी, आपके सभी बेहतरीन इरादों के लिए, आप केवल संयोजित व्यवहारों को अनदेखा नहीं कर सकते हैं।

स्रोत

2009-08-18 20:11:35

बचत बटन क्यों आवश्यक है?

उत्तर

संबंधित मुद्दे