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

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

Интерфейс
Отправить
Поделиться
Запинить

Комментарии

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

19 мар 2019

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

19 мар 2019

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

20 мар 2019

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

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

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

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

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

21 мар 2019

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

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

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

21 мар 2019

Рекомендуем другие советы