لماذا مطلوب زر حفظ؟
https://stackoverflow.com/questions/1295178
-
18-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
لقد أظهر برنامج مثل OneNote أن حفظ التلقائي يمكن تطبيقه، ويعمل أيضا (أو أفضل) كشروع حفظ اليدوي / CTRL + S.
على أي حال كل ما تعمل عليه تريد المحفوظة. انها فقط إذا كنت تحاول الخروج شيء مدمرا ستغلق بدون إنقاذ.
لذلك من منظور المبرمجين / قابلية الاستخدام، لماذا لا يزال ميزة "حفظ" اليدوي في جميع البرامج تقريبا اليوم؟ هل هذا لأن الجميع كسول للغاية لتنفيذ "حفظ تلقائي" كلما تم تعديل البيانات؟
وهي فكرة جيدة بالنسبة لنا تنفيذ حفظ تلقائي، على الأقل لبدء بعض الجر في صناعةنا المحددة ومن بين منافسينا؟
المحلول
يعد Save Button ميزة واجهة مستخدم مريحة معروفة أن كل شخص من Jon Skeet إلى الجدة على دراية به. إذا تخلصت منه، فسيكون الأمر مثل إزالة زر إغلاق على نافذة لبعض الأشخاص. منحت، وسوف تعتاد في النهاية على ذلك، ولكن بعض الناس لن يفهموا أن بياناتهم قد تم حفظها تلقائيا.
أيضا، إذا كنت تقوم بالتحويل التلقائي على الويب، فلا تقم فقط بأخذ مساحة كبيرة على الخادم الخاص بك مع كل هذه الحالات، فأنت تستخدم أيضا الكثير من عرض النطاق الترددي مع محفظات دورية. على الأقل مع توفير اليدوي، فإنك تستخدم فقط المساحة وعرض النطاق الترددي عندما يعتزم المستخدم، والذي يمكن أن يكون أكثر نادرة، وبالتالي توفير عرض النطاق الترددي. الميزة، بالطبع، للتحويل التلقائي هو الاحتفاظ بالعمل يجب أن يذهب شيء ما.
تحقق من تعريف "skeuomorph." :)
نصائح أخرى
الحفظ التلقائي عادة يحفظ على فاصل محدد. ماذا يحدث إذا كنت ترغب في الحفظ بين الفواصل الزمنية؟
يجب أن تنفذ دليل حفظ للاحتفاظ بالتفكيك مع التطبيقات الأخرى في البيئة أيضا.
يتوقع الأشخاص ملف -> حفظ أو CTRL + S إلى الوجود.
بالإضافة إلى ذلك مع "حفظ" هناك عادة "حفظ كما .." كذلك. كلاهما يمنح المستخدم شعور السيطرة والأمن. مع العلم أن النقر فوق حفظ يتيح لهم معرفة ما يمكن أن يتوقعوا أن تكون بياناتهم عند إعادة تحميلها عند إعادة تحميلها.
انه حقا يأتي إلى هذا: زر حفظ أرخص لتنفيذ وصيانة من التراجع.
ليس من الصعب تنفيذ حفظ تلقائي - مجرد تطبيق حفظ عادي واتصل به عند الحاجة أو فقط في مؤقت (إذا كنت كسولا).
حفظ الأزرار شائعة بسبب النمط المشترك الذي تعلمه المستخدمون منذ عقود.
- تحميل البيانات أو الملفات من تخزين مستمر في الذاكرة الرئيسية.
- تعديل البيانات في الذاكرة الرئيسية.
- احفظ البيانات المعدلة مرة أخرى إلى وحدة تخزين مستمرة.
يأتي هذا النمط من التمييز القديم بين محرك الأقراص الصغير والذاكرة الرئيسية. إذا كنت تفكر في الأمر بطريقة أخرى (مثل بعض أنظمة التشغيل التجريبية)، فلا حاجة لتحميل الملفات وحفظها - فقط فكر في محرك أقراص ثابت كذاكرة رئيسية والذاكرة الرئيسية كمستوى ذاكرة التخزين المؤقت الأخرى وبعد نتيجة كل الملفات (وليس على الوسائط القابلة للإزالة) هي دائما في الذاكرة ولن تحتاج مرة أخرى إلى تحميل الملفات أو حفظها.
لكن القيام بهذا التغيير ليس بالأمر السهل لأن المستخدمين معتادون على النمط القديم لسنوات. علاوة على ذلك، فإن الحمل القديم وحفظ نمط هو وسيلة سهلة للغاية للحصول على نوع من نظام تراجع Primitve.
يتطلب التوفير التلقائي نظام التراجع، أيضا، وليس ذلك تافهة لبناء واحدة. Esspecialy إذا قمت بإجراء الصور أو الصوت أو التحرير المرئي وأنت تنتج الكثير من البيانات من الصعب العثور على مفاضلة وقت جيد للذاكرة. وهناك خطر أن يحاول المستخدم التراجع عن الأشياء عن طريق إغلاق التطبيق ثم تدرك أن هذا لم ينجح. لذلك قد تكون فكرة جيدة أن تستمر في معلومات التراجع عن حماية المستخدمين من هذا الخطأ أو حفظ التغييرات غير المرغوب فيها في حالة تعطل.
لذلك، نعم، أود حقا أن أرى أزرار حفظ (والتحميل) لتختفي. أود أن استمر في التراجع عن المعلومات أو حتى تاريخ التعديل الكامل أيضا. لكنني لا أعتقد أن هذا التغيير يمكن أن يحدث في غضون بضع سنوات - إذا كان أي وقت مضى.
أعمل في المجال الطبي وهناك مواقف ترغب فيها للمستخدم في تحمل مسؤولية حفظ شيء ما. إذا كان لديك EHR وكنت تدخل وصفة طبية للمريض، فأنت لا تريد بالضرورة من التلقائي - فأنت تريد أن يكون المستخدم يدرك وتتحمل المسؤولية عن أفعالهم. أيضا، التقويم التلقائي قيمة في نظام حرج مثل هذا يمكن أن يكون كارثية لأسباب واضحة ...
يجب أن تكون الموسومة ذاتية ربما؟
كمطور، أنا دائما غير مستقر قليلا حول التطبيقات من هذا القبيل. أنا مثل وجود سيطرة على متى يتم حفظ بياناتي، على الرغم من أن هذه هي سنوات فقط من تكييفها في العمل. أحصل على هذا الشعور قليلا "اه أوه" كلما أغلقت نافذة دخلت فيها بيانات دون الضغط صراحة على زر إغلاق (أو اختصار).
ومع ذلك، كنت "مدربة" لقبولها في حالات معينة. OneNote، على سبيل المثال، أو tomboy. العديد من تطبيقات OS X رائعة تتبع هذا النمط، وخاصة تطبيقات الأداة المساعدة مثل أدوات خادم واجهة المستخدم الرسومية DB.
لذلك، بأدوات مختلفة مختلفة عن المواقف المختلفة. IMO، معظم البرامج هذه الأيام لن تستفيد من الانتقال من دليل حفظ إلى حفظ تلقائي.
أعتقد أن الإجابة على هذا هو "ذلك يعتمد"!
يجب أن تفكر في عدم توقعات المستخدم الخاصة بك فقط من حيث الاتساق مع التطبيقات الأخرى، ولكن أيضا الطريقة التي سيستخدم فيها المستخدم الخاص بك.
حالة الاستخدام الشائعة للغاية ل ONENOTE هي أن شخصا ما يفتحه لتفريغ بعض المعلومات تقريبا كعمل على ما يعمل عليه. يحتاجون إلى الدخول والخروج بسرعة. أي مطالبات حول الحفظ سيكون مصدر إزعاج.
توقع تطبيقات مثل Word، من ناحية أخرى، أن يقضي المستخدمون قدرا من الوقت المناسب للعمل في وثيقة. في هذه الحالة، سيتم اعتبار Chore التوفير يدويا واستجابة صناديق التأكيد وما إلى ذلك مهمة صغيرة نسبيا.
من منظور المبرمجين تنفيذ الحفظ التلقائي لن يكون صفقة ضخمة. لقد قمت فقط بإعداد مؤقت وإعادة الاتصال سيفعل الادخار.
ومع ذلك، من نقطة قابلية الاستخدام من وجهة نظر الحفظ التلقائي مشكلة للغاية. بادئ ذي بدء استخدام جميع المستخدمين لإنجاز توفير يدوي ولا يقدمها لهم سيتخلطون بأغلبية المستخدمين وأشعر بالسيطرة بعيدا.
حتى القضية الأكبر ستكون تلك الحفظ التلقائي الكتابة فوق محتويات الملف الأساسي ما إذا كنت تريد ذلك أم لا. بالطبع هل يمكن أن يكون لديك ميزة AutoSave وتوفير ملف مؤقت ولكن قرار الكتابة فوق المستند الأصلي يجب أن تأتي دائما من المستخدم, ليس من البرنامج. ولأنك ستحتاج على أي حال إلى المستخدم للبدء في توفير يدوي واحد على الأقل، فلماذا لا يمكن تتيح توفير يدوي دائما؟
ميزة AutoSave رائعة عندما تتعامل مع مستند. ماذا عن تطبيق الأعمال؟ إذا قمت بتحرير حساب العميل، إذا قمت بتحديث الحساب كعلامة التبويب من الحقول المحررة؟ إذا كان الأمر كذلك، فما الذي يجب أن يفعله عندما يكون الحساب في حالة غير صالحة؟ متى تنفذ قواعد الأعمال وكيف فرضها؟ كيف سيتم تنفيذها عندما تضطر إلى اتخاذ قواعد الأعمال في الاعتبار في كل تعديل؟
يمكنك بالتأكيد إنشاء تطبيق سيأخذ أي من هذه الاعتبارات في الاعتبار، ولكن هل سيكون الأمر يستحق الجهد الإضافي؟
لذلك يجب أن نتخلص من زر حفظ؟ هذا يعتمد.
إجابة قصيرة: "حفظ السيارات" = "تدمير السيارات" / "السياراتu003Cexpletive> ".
لمشروع واحد في الجامعة، قامت مجموعتي وبصمت تطبيقا دون توفير صريح كتجربة.
قمنا بتنفيذ مكدس تراجع لا حصر له وتسليط مكدس التراجع بالبيانات الفعلية حتى إذا أغلقت التطبيق وإعادة فتحه، فيمكنك دائما التراجع عن تشغيلك الأخير. كتبت كل عملية إدخال جديد إلى قائمة الإجراءات على القرص بحيث كان الملف ثابتا دائما (جيد، معظمها ...)، حتى لو فشلت الطاقة. كان القليل من التقاطع بين نظام التحكم في الإصدار ونظام ملفات يومية.
كان هناك مشكلتان: واحد، لم يكن لدينا وقت للحصول عليه بشكل صحيح تماما (آه، هوبريس الشباب)؛ اثنان، الجميع (زملائه الطلاب، والأهم من ذلك، TAS) يكرهون ذلك، بسبب كل الأسباب المذكورة بالفعل.
في بعض الأحيان، لجميع أفضل النوايا الخاصة بك، لا يمكنك تجاهل السلوكيات غير المتلألئة.
