Вопрос

Программное обеспечение, такое как OneNote, показало, что автоматическое сохранение может быть реализовано, и оно работает так же хорошо (или лучше), как кнопка ручного сохранения / CTRL + S.

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

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

И хорошая ли идея для нас внедрить автоматическое сохранение, по крайней мере, для того, чтобы начать какое-то развитие в нашей конкретной отрасли и среди наших конкурентов?

Это было полезно?

Решение

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

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

Проверьте определение "скеоморф" :)

Другие советы

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

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

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

Кроме того, вместе с "сохранить" обычно используется и "сохранить как ..".И то, и другое дает пользователю ощущение контроля и безопасности.Знание того, что они нажали сохранить, позволяет им знать, в каком состоянии они могут ожидать, что их данные будут находиться при их перезагрузке.

Все действительно сводится к этому: кнопку Сохранить дешевле внедрить и поддерживать, чем Отменить.

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

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

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

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

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

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

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

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

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

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

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

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

Я думаю, что ответ на этот вопрос заключается в том, что "это зависит"!

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

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

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

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

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

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

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

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

Итак, должны ли мы избавиться от кнопки Сохранить?Это зависит от обстоятельств.

Короткий ответ:"автоматическое сохранение" = "автоматическое уничтожение" / "авто <expletive>".

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top