x
 
Сергей Тищенко
23 января 2012

Это кусок интерфейса службы поддержки (в примере выдуманные названия). Список состоит из ~ 100-150 записей-сервисов, снабжён фильтром.

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

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

  • Спрашиваю мнения уважаемых советчиков:
  • Правильно ли сделано, что переключение шлюза и изменение статуса сделано в виде ссылок на его названии?
  • Можно ли использовать цветовое кодирование управляющих ссылок? В некоторых случаях, если текущий статус объекта является критичным, предполагается его отображать красным.
  • Правильно ли сделано, что статусы, когда их только два, переключаются простым нажатием с подтверждением, а не выбором статуса в выпадающем списке/чекбоксом или как-то ещё?
  • Что должно быть написано в окне подтверждения изменения статуса в таком случае?


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

Кроме того, слова «активен» и «выключен» излишни — вы уже хорошо показали состояние шлюзов цветом.

Поэтому я убрал бы колонку статусов, упростив первоначальную задачу до поиска:


А после выбора открывать простую панель, не требующую дополнительных подтверждений:


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

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


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

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

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

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

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

Зачем читать книги из совета о «науке» юзабилити, когда приглашать дизайнера в проект и как определить хороший референс для тренировки насмотренности 3 1 2




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

3 О тексте как базовом элементе 6 Выбранные элементы списка, как не забывать принципы из советов бюро и когда нужен логотип 1 1