Почему кнопка сохранения необходима?

Для одного проекта в университете мы с моей группой создали приложение без явного сохранения в качестве эксперимента.

Мы реализовали бесконечный стек отмены и сериализовали стек отмены с фактическими данными, так что даже если вы закроете приложение и снова откроете его, вы всегда сможете отменить последнюю операцию. Каждая операция записывала новую запись в список действий на диске, чтобы файл всегда был согласован (ну, в основном ...), даже если отключилось питание. Это было чем-то средним между системой контроля версий и журнальной файловой системой.

Было две проблемы: во-первых, у нас не было времени, чтобы все исправить (ах, юношеское высокомерие); во-вторых, все (сокурсники и, что наиболее важно, ТА) ненавидели его по всем уже упомянутым причинам.

Иногда, несмотря на все ваши лучшие намерения, вы просто можете ».

Краткий ответ: "auto save" = "auto destroy" / "auto ".

Функция автосохранения очень удобна, когда вы работаете с документом. А как насчет бизнес-приложения? Если я редактирую учетную запись клиента, должен ли он обновлять учетную запись, когда я выхожу из отредактированных полей? Если да, что делать, если учетная запись находится в недействительном состоянии? Когда вы обеспечиваете соблюдение бизнес-правил и как вы обеспечиваете их соблюдение? Как это будет работать, если вам придется учитывать бизнес-правила при каждом редактировании?

Вы, конечно, можете создать приложение, которое будет учитывать любое из этих соображений, но стоило ли оно дополнительных усилий?

Так стоит ли избавиться от кнопки «Сохранить»? Это зависит.

Я думаю, ответ на этот вопрос таков: «это зависит»!

Вы должны учитывать не только ожидания вашего пользователя с точки зрения согласованности с другими приложениями, но также и то, как пользователь собирается использовать ваше приложение.

Очень распространенный вариант использования OneNote состоит в том, что кто-то открывает его, чтобы выгрузить некоторую информацию почти в стороне от того, над чем они работают. Им нужно быстро входить и выходить. Любые запросы о сохранении будут неудобными.

Приложения, такие как Word, с другой стороны, ожидают, что пользователи будут тратить согласованное количество времени на работу с документом. В этом случае рутинная работа по сохранению вручную и реагированию на окна подтверждения и т. Д. Будет рассматриваться как относительно небольшая задача.

Может быть, стоит пометить как субъективный?

Как разработчик, я всегда немного беспокоюсь о подобных приложениях. Мне нравится иметь контроль над тем, когда мои данные сохраняются, хотя, возможно, это всего лишь годы тренировок на работе. У меня возникает это маленькое чувство «ох» всякий раз, когда я закрываю окно, в которое ввел данные, не нажимая явно кнопку закрытия (или ярлык).

Тем не менее, меня «обучили» принимать это в определенных ситуациях. . OneNote, например, или Tomboy. Очень многие приложения OS X следуют этому шаблону, особенно служебные приложения, такие как инструменты GUI сервера БД.

Короче говоря, разные инструменты для разных ситуаций. IMO, большинство программ в наши дни не выиграют от перехода от ручного сохранения к автосохранению.

С точки зрения программистов реализация автосохранения не будет огромное дело. Вы просто устанавливаете таймер, и обратный вызов сделает сохранение.

Однако с точки зрения удобства использования автосохранение очень проблематично. Прежде всего, пользователи привыкли к ручному сохранению, и отказ от его предложения сбил бы с толку большинство пользователей и лишил бы ощущения контроля.

Еще более серьезной проблемой было бы то, что автосохранение перезаписывает содержимое файла-основы , хотите вы этого или нет. Конечно, у вас может быть функция автосохранения во временный файл, но решение о перезаписи исходного документа всегда должно исходить от пользователя , а не от программного обеспечения. И поскольку вам в любом случае потребуется, чтобы пользователь инициировал хотя бы одно сохранение вручную, почему бы не сделать так, чтобы сохранение вручную было всегда доступным?

Реализовать автосохранение несложно - просто реализуйте обычное сохранение и вызывайте его, когда когда-нибудь понадобится, или просто в таймере (если вы ленивы).

Кнопки сохранения - обычное дело из-за общей схемы, усвоенной пользователями на протяжении десятилетий.

1. Загрузить данные или файлы из постоянного хранилища в основную память.
2. Изменить данные в основной памяти.
3. Сохранить измененные данные обратно в постоянное хранилище.

Эта закономерность происходит от старого различия между жестким диском и основной памятью. Если вы подумаете об этом по-другому (как некоторые экспериментальные операционные системы), то нет необходимости загружать и сохранять файлы - просто подумайте о жестком диске как о вашей основной памяти, а основная память как о другом уровне кеша для жесткого диска. . В результате все файлы (не на съемных носителях) всегда находятся в памяти, и вам больше никогда не придется загружать или сохранять файлы.

Но сделать это изменение непросто, потому что пользователи привыкли к старому шаблону в течение многих лет. Кроме того, старый шаблон загрузки и сохранения - очень простой способ получить своего рода примитивную систему отмены.

Автосохранение также требует системы отмены, и создать ее не так уж и тривиально. Особенно, если вы выполняете редактирование изображений, аудио или видео и производите много данных, трудно найти хороший компромисс между временем и памятью. И есть риск, что пользователь попытается отменить что-то, закрыв приложение, а затем поймет, что это не сработало. Так что было бы даже неплохо сохранить информацию об отмене, чтобы защитить пользователей от этой ошибки или сохранить нежелательные изменения в случае сбоя.

Итак, да, Я бы действительно хотел, чтобы кнопки сохранения (и загрузки) исчезли. Я также хотел бы сохранить информацию об отмене или даже полную историю редактирования. Но я не думаю, что это изменение может произойти через несколько лет - если вообще когда-либо.

На самом деле все сводится к следующему: кнопку «Сохранить» дешевле реализовать и поддерживать, чем кнопку «Отменить» .

Кроме того, при «сохранении» обычно используется «сохранить как ..». Оба дают пользователю ощущение контроля и безопасности. Информация о том, что они нажали кнопку «Сохранить», позволяет им узнать, в каком состоянии они могут ожидать, что их данные будут находиться при их перезагрузке.

автосохранение обычно сохраняет в заданном интервале. Что произойдет, если вы захотите сохранить в промежутках между интервалами?

Вы должны реализовать сохранение вручную, чтобы оставаться согласованным с другими приложениями в среде.

Люди ожидают, что файл -> сохранить или CTRL + S существует.

Я работаю в области медицины, и бывают ситуации, когда вы хотите, чтобы пользователь взял на себя ответственность за сохранение чего-либо. Если у вас есть электронная записная книжка и вы вводите рецепт для пациента, вам необязательно, чтобы оно сохранялось автоматически - вы хотите, чтобы пользователь знал о своих действиях и брал на себя ответственность за них. Кроме того, автосохранение значения в такой критически важной системе, как эта, может иметь катастрофические последствия по очевидным причинам ...