Как обращаться с кнопками «сохранить» и «отменить» и обратно

Мне интересно, как обрабатывать пользовательские формы ввода в моем приложении. (Реальный бюджет lite). Сейчас это то, что я делаю, но я не уверен, что это лучшая практика:

У меня есть две мягкие кнопки на большинстве моих действий, которые берут ввод пользователя: «сохранить» и «отменить».

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

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

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

Выбор, который я вижу, это:

  1. Сделайте это так, как я это делаю сейчас.
  2. Избавьтесь от кнопки «Сохранить» и рассчитывайте на пользователей, зная, что спина равна сохранению.
  3. Избавьтесь от обеих кнопок и выделите функцию отмены из клавиши меню.

Кстати, приложение google contacts предлагает кнопки «done» и «revert». Я думаю, что «возврат» означает отмену; Есть ли разница? Может быть, мне нужно, чтобы мои кнопки обозначались как «done» и «revert» вместо «save» и «cancel»? В gmail кнопка меню предоставляет варианты «save draft» и «discard». Мне кажется, что мы будем делать пользователям услугу, если у нас есть некоторая последовательность.

Заранее спасибо.

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

Единственное встроенное приложение, которое делает это, о котором я могу думать, – это приложение для контактов, и я считаю, что UX будет паршивым. Я просто проклинал это вчера, как это бывает.

Возможно, другие встроенные приложения тоже делают это, но я еще не сталкивался с этим, по крайней мере, не так, как я вспоминаю.

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

В документации нет инструкций UX такого характера. К сожалению.

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

Вы не получите от меня никаких аргументов.

Лично я думаю о кнопке НАЗАД, как о том, что она ведет себя как «отмена», или как бы отрицательный выбор. Например, диалоги обычно ведут себя таким образом на Android.

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

В крайнем случае, сделайте его настраиваемым. В идеале, для чего-то подобного, есть One True Right Answer, и, следовательно, конфигурация будет бессмысленной. Однако, если ваш опрос указывает на разделенное голосование, и в отсутствие рекомендаций платформы UX для Android, настройка может быть правильным решением для вас.


ОБНОВЛЕНИЕ: я написал сообщение в блоге об этой проблеме, поскольку я думаю, что это разумно важно и стоит немного больше прозы.

Я настоятельно рекомендую вам следовать модели, используемой стандартным Android и приложениями, где редактирование всегда происходит на месте. То есть, нет кнопки «сохранить» – изменения, которые вы делаете, эффективно сохраняются по мере их выполнения. (Реализация может быть несколько иной, но для пользователя это не должно быть видно.) Следуя этой модели, ваши кнопки должны быть чем-то вроде строк «done» и «revert». Это помогает с умственной моделью пользователя в том, что происходит, что отказ от деятельности вряд ли превратится в операцию «вернуться».

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

Так что начните с редактирования вашей базовой модели. Это согласуется с конвенцией, используемой стандартной платформой, и это было преднамеренно выбрано в дизайне платформы, поскольку в целом это приводит к гораздо более простому и согласованному и понятному UX. Создайте свой поток пользовательского интерфейса, чтобы подчеркнуть эту модель, избегая явных действий «сохранить».

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

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

  1. Насколько важна ваша операция «сохранить» (например, она будет размещать заказы!)
  2. Ваш пользователь ожидал, что отменит материал?

Очевидно, что если сохранение долго обрабатывается и критично, необходимо принять явный контроль. (И спина не спасет); И для второго пункта, я думаю, что GTask считал, что примечания по записи должны быть быстрыми и простыми, и это должно звучать как песнопение на бумаге – оно сохраняется, как только вы написали.

Ссылаясь на то, что вы сказали, вернитесь в веб-браузер, вернитесь и забудьте все. Но в то же время Google (например, Документы Google) также делает автоматическое сохранение на фоне, что он не «забыт», когда вы возвращаетесь.

Попытка решить универсальное действие, когда пользователь нажимает, делает этот вопрос намного сложнее (если не невозможно).

Более простой подход – это размышление о контексте, и я вижу две основные ситуации: пользователь взаимодействует с диалогом, и пользователь взаимодействует с регулярной деятельностью.

Взаимодействие с диалогом

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

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

Взаимодействие с деятельностью

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

Мои мысли как пользователя android

Поведение в диалоговом окне является простым и понятным. Думаю, мы не сомневаемся.

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

Если вы хотите что-то лучше, включите поведение по умолчанию в качестве предпочтения и / или покажите тост при отмене или сохранении информации.

Отменить vs revert

На практике они делают то же самое. Отмена должна, herr, отменить то, что вы делаете прямо сейчас (редактировать что-то). Это должно / могло бы привести вас к тому, что вы делали раньше (активность списка).

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

Эксперименты с применением контактов

  1. Нажатие назад при редактировании контакта сохранит изменения.
  2. При нажатии на дом во время редактирования контакта будут отменены изменения