Удобство использования: Сохранить изменения с помощью кнопки «Применить» или после каждого отдельного изменения?

Question

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

Общий подход состоит в том, чтобы позволить пользователям настраивать параметры и после того, как форма становится «грязной», активировать кнопку «Применить», и у пользователя есть возможность отступить, нажав «Отмена». Это наиболее распространенный подход на платформе Windows (я полагаю, что в рекомендациях по юзабилити MS также говорится об этом).

Другой способ - применить изменения после каждого изменения, внесенного в параметры. Например, пользователь устанавливает флажок, и изменение применяется. Пользователь изменяет значение некоторого текстового поля, и изменение применяется после того, как поле теряет фокус и т. Д. Вы получаете точку. Этот подход наиболее распространен в Mac OSX.

Независимо от моего личного мнения (а именно то, что Apple лучше справляется с юзабилити, но программное обеспечение, которое я обычно пишу, ориентировано на пользователей Windows), как вы думаете, люди?

Редактировать: Я полностью осознаю, что это не реальный вопрос, а скорее вопрос для обсуждения, и что это может быть не в SO, политика которого состоит в том, чтобы иметь только ответы и вопросы. Но я считаю, что это может быть полезным обсуждением, в основном потому, что я не смог найти ничего подобного, прежде чем спрашивать.

Answer 1

Оба имеют свои места, и они оба используются на многих платформах (на самом деле они не различают ПК и Mac).

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

Диалог с мгновенным эффектом позволяет пользователю экспериментировать и видеть «живые» обновления, основанные на их выборе. Это замечательно, когда пользователь хочет поэкспериментировать с опциями, чтобы увидеть, какой эффект они будут иметь. Вы должны быть осторожны с визуальным стилем, чтобы дать понять пользователю, что они работают «вживую», и они должны быть осторожны, потому что они не могут отменить свои изменения. Подход Microsoft для этого типа диалога состоит в том, чтобы иметь одну кнопку «Закрыть», что делает подход с мгновенным эффектом очевидным. Эти диалоги часто не являются модальными, то есть они рассматриваются как «панели редактирования в реальном времени», а не как диалоги.

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

Однако, в конечном счете, выбор между этими двумя вариантами действительно зависит от того, каким типом настроек вы хотите управлять. то есть, если вы устанавливаете стили шрифта для некоторого текста, то вы действительно хотите быть на экспериментальном конце спектра, но если вы настраиваете важные и связанные группы информации (например, адрес вашего DNS-сервера и маску подсети) вы можете захотеть использовать то, что требует от вас думать / знать и сознательно применять свои изменения (чтобы пользователи могли вводить и перепроверять информацию, чтобы они могли изменять несколько связанных частей информации «одновременно». Кроме того, если вы совершите Адрес DNS-сервера жив, как его вводит пользователь, он потеряет свое сетевое соединение, пока не получит правильные цифры - жить просто не имеет смысла).

Answer 2

Соответствие ожиданиям платформы.

Я также согласен с тем, что Apple превосходит по удобству использования, но ваши решения должны основываться на наиболее распространенном поведении, которое демонстрирует ваша целевая платформа.Вы всегда должны делать все, что меньше всего удивляет пользователей, и для большинства пользователей Windows я предполагаю, что это соответствует поведению OK/Apply/Cancel.

Если у вас есть кроссплатформенные приложения, используйте отдельные графические интерфейсы, которые уважают1008 * соответствует ожиданиям платформы мантра.Да, это дополнительная работа, но это показывает, что вы заботитесь.

Answer 3

+ 1 для сохранения изменений после того, как заполнена вся форма, а не каждое поле.

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

Answer 4

Я могу вспомнить только две веские причины наличия кнопки «Применить»:

1. Изменения не могут быть применены мгновенно, но они заблокируют графический интерфейс на заметное время.
2. Изменения имеют смысл только вместе (как транзакция).

Ни один из них не очень распространен. Исторически 1 был правдой почти для любого варианта. Но в наши дни компьютеры работают быстрее, а 1 редко актуален. Если эффект изменения можно увидеть мгновенно, почему бы кому-то не захотеть этого? Таким образом, графический интерфейс (но часто не код) можно упростить, пропустив шаг применения. Я не думаю, что это очень часто, что пользователь действительно нуждается в кнопке отмены также, частично потому что это отчасти неоднозначно. Чего следует ожидать, если я внесу одно изменение, подам заявление, внесу другое изменение и нажму "Отмена"? Будет ли отменено первое изменение (в большинстве приложений ответ отрицательный, потому что его легче реализовать)?

Если да, то какой смысл иметь кнопку «Применить», тогда все будет отменено, а затем нажать «OK / Отмена»? Или нам нужно рассмотреть еще один вариант, когда окно закрыто, и в этом случае первое изменение сохраняется, а второе возвращается?

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

Разумно ли сохранять такую ​​сложность исторических причин, потому что пользователи (как полагают) ожидают этого? Я видел, как пользователи всегда нажимают «Применить», затем «ОК». Зачем? Возможно, только потому, что графический интерфейс слишком сложен. Или потому, что не уверены, что «применить» означает «применить и отклонить диалог» (что он делает в некоторых приложениях) и что «ОК» может не применить изменения (я видел приложения с ошибками, где «ОК» просто закрывает окно без применения и, возможно, они есть тоже). По крайней мере, я не думаю, что пользователи в целом правы по поводу точных логик этих сложных решений, поэтому им это не нужно, и этого не должно быть. Люди в основном различают «положительные» (да, хорошо, идти вперед, применить) и «отрицательные» (нет, отменить, отменить, вернуться назад) действия в диалогах, когда более одного из них требует большего внимания со стороны пользователя. Интересно, что обмен одним положительным действием с другим, похоже, не сильно влияет на восприятие пользователей. Если диалоговое окно с кнопками «да / нет» изменено на «ОК / Отмена», многие пользователи даже не заметят.

Это о юзабилити (что гораздо важнее, ИМХО). Мгновенное применение с точки зрения ремонтопригодности может быть очень грязным, если сделано неправильно, но также очень чистым и ремонтопригодным, если все сделано правильно. Если приложение написано с применением метода «применить все сразу», обычно есть одна функция. Вызов такой функции для каждого небольшого изменения, конечно, не очень эффективен. То, что я видел, часто решается разделением функции на несколько разных функций для применения разных вещей, в идеале одну выделенную функцию для каждого вида изменений, которые могут быть сделаны. Это сделает приложение намного более отзывчивым, но поддерживать его ужасно. Так что не ходи туда. Оптимальное решение заключается в использовании MVC (Model-View-Controller) и создании модели для каждого элемента конфигурации и привязке их к полям в форме конфигурации, а также к соответствующим частям приложения (и к хранилищу конфигурации). конец, поэтому каждое изменение сохраняется автоматически). Если в рассматриваемой среде нет MVC, его обязательно стоит написать.

Answer 5

Я согласен, что в целом вам нужно соответствовать ожиданиям платформы.

Лично я, как правило, предпочитаю использовать применить / сохранить по двум причинам: 1) Частично примененное изменение может быть разрушительным (с задержкойили в реальных артефактах экрана) 2) Некоторые состояния или комбинации могут быть недействительными (или они могут быть недействительными в восприятии пользователя).3) Если вы предоставляете какой-либо способ развертывания изменений или сохранения изменений со значимыми именами, то имеет смысл сгруппировать их логически в зависимости от того, когда пользователь решил нажать «Применить» или «Сохранить».Как разработчик, мне нравится подход коммит / откат к вещам, и он мне нравится в моих интерфейсах.