x
 
Анастасия
19 марта 2019
Советы почтой каждую неделю
Пожалуйста, получите наше письмо, чтобы подтвердить свой адрес:
Вы подписаны на «Советы за неделю»:

Илья, здравствуйте!

Скажите, пожалуйста, как правильно организовать в интерфейсе выбор из четырех действий с разным приоритетом (указан цифрой: чем меньше цифра, тем выше приоритет), сгруппированных попарно по дополнительному условию?

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

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

Есть мысль перенести действия с самым низким приоритетом в другую часть интерфейса, сделав их менее заметными. Однако всё же важно дать пользователю понять, что при выполнении этих побочных действий операция не будет завершена, а при выполнении главных действий будет. Большой правильный заголовок спасёт положение?


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

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

Интерфейс и информация — дисциплина Школы дизайнеров. Набор открыт до 12 августа или пока есть свободные места.
 

Поделиться
Отправить

Комментарии

Николай Ефремов
19 марта 2019

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

Михаил Тучин
20 марта 2019

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


19 марта 2019

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

Мамадаев Николай
21 марта 2019

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

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

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

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

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

Константин Машанов
21 марта 2019

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

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

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


Цель рубрики — обсуждение вопросов дизайна всех видов, текста в дизайне и взаимоотношений дизайнеров с клиентами.

Мы публикуем комментарии, которые добавляют к уже сказанному новые мысли и хорошие примеры. Мы ожидаем, что такие комментарии составят около 20% от общего числа.

Решение о публикации принимается один раз; мы не имеем возможности комментировать или пересматривать свое решение, хотя оно может быть ошибочно. Уже опубликованные комментарии могут быть удалены через некоторое время, если без них обсуждение не становится менее ценным или интересным.

Вот такой веб 2.0.

Как озаглавить форму записи в парикмахерскую 2 4




Недавно всплыло

2 В бюро есть таймтрекинг для сотрудников? 5 Хочу научиться сторителлингу 9 Как в бюро верстают электронные письма и рассылки. Третья часть: рассылки Школы и Издательства бюро 1