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

Question

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

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

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

я могу думать только о двух хороших причин, за то, что кнопка применения:

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

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

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

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

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

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

Answer 5

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

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