Выбор из четырех действий с разным приоритетом

Илья, здравствуйте! Скажите, пожалуйста, как правильно организовать в интерфейсе выбор из четырех действий с разным приоритетом (указан цифрой: чем меньше цифра, тем выше приоритет), сгруппированных попарно по дополнительному условию? Кажется, что первый вариант логичен благодаря сохранению последовательности действий. Однако пользователь может не понять, что включение или выключение чекбокса «Завершить операцию» распространяется и на кнопку «Покинуть приложение». Плюс выполнение действий с низким приоритетом потребует два клика. Второй вариант заключается в том, чтобы спрятать первоначальный выбор под одну кнопку (т. к. действие «Покинуть приложение» встречается в обоих сценариях), а при клике на неё показывать попап с кнопками «Завершить операцию» — «Не завершать операцию». Однако в этом случае два клика потребует действие с самым высоким приоритетом. Есть мысль перенести действия с самым низким приоритетом в другую часть интерфейса, сделав их менее заметными. Однако всё же важно дать пользователю понять, что при выполнении этих побочных действий операция не будет завершена, а при выполнении главных действий будет. Большой правильный заголовок спасёт положение?

В том, как вы описываете задачу — главная ошибка проектирования: Вы думаете о каких‑то приоритетах и попарных группировках, а надо думать о сценариях. Что человек делает на этом экране? какими вопросами задаётся? что хочет сделать дальше? У вас об этом ни слова; даже не сказано, о какой операции речь, что было на предыдущем экране и что ждёт на следующем.

Чтобы не выдумывать абстрактный интерфейс, я решил, что будет так. «Операция» — это покупка Айфона. Следующий экран, на который можно и не ходить — это выбор чехольчика. А на предыдущем экране человек выбирал, какую именно модель покупать. Тогда можно так:

Интерфейс

Отправить

Запинить

Твитнуть

«Заказать» подразумевает завершение действия оформления покупки. «Заказать, выбрать чехол» может быть воспринято как выполнение действий именно в таком порядке, что приведёт к необходимости звонить оператору магазина и просить объединить два заказа. Возможно, стоит поменять порядок «Выбрать чехол и заказать»?

Николай Товеровский

Предлагаю сделать попроще — чехлы предлагаем всем :‑)

Михаил Тучин

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

Мамадаев Николай

Это похоже на какой‑то визард, поэтому нужны обычные кнопки: "Назад" и "Далее". И само собой кнопка "Покинуть приложение" или "Закрыть".
Переключатель и вообще текст про завершение операции изначально выводить, не нужно.

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

В данном случае при нажатии на "Назад" и нужно показать диалог с текстом: "Операция не будет завершена! Продолжить?"; при нажатии на "Далее" нужно просто продолжать без всяких диалогов. Можно ещё блокировать эту кнопку, пока юзер не сделает всё что нужно.

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

Но. Если у вас не визард и юзер может спокойно переключаться между экранами и связи между экранами нет, то лучше отказаться от формулировок типа "Следующий экран" и "Предыдущий экран" и сделать не кнопки, а обычные табы с названиями экранов и на каждом разместить кнопку — "Сохранить".

Константин Машанов

Без контекста очень сложно понять хоть что‑то.

Предположу, что лучше будет, когда группировка действий будет зависеть от типа сущности. В вашем случае сущности это приложение, которое включает в себя сущность операции, которая в свою очередь включает предыдущий и следующий экраны. Соответственно, к приложению относится действие с возможностью закрыть его, к операции — возможность завершить её, вернуться на предыдущий или перейти на следующий экран.

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