У нас есть панель инструментов, которая суммирует доходы от приложения по месяцам.

Отрисовка всего представления основана на текущем выбранном месяце, но некоторые разделы его тела содержат обзор всего времени жизни приложения (от самого MVP до настоящего момента).

Недавно мы добавили возможность навигации по месяцам и годам, добавив:

  1. Элементы управления в шапке, со свободным выбором [доступных] месяцев и лет;
  2. Элементы управления в «В этом месяце» (сводка текущего месяца), с навигацией вперед и назад между месяцами (и годами, когда он в конечном итоге достигает максимального/минимального месяца);

Один из моих коллег указал, что 2 должно быть с 1, так как он управляет просмотром/навигацией по всей приборной панели и принадлежит «одному и тому же контексту».

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

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

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

View controls example

2
Rick Stanley 11 Мар 2020 в 05:08
Ваш вопрос можно было бы сформулировать по-другому: стоит ли доверять советам коллег по дизайну больше, чем моему собственному мнению? Ваш коллега прав. IMO, ваш дизайн может быть сделан с некоторой визуальной очисткой (кнопки «назад» и «вперед» расположены не очень удачно, не имеют отступов, плохо отличаются от соседних виджетов) и неоднозначен, если рассматривать его вместе с существованием навигации браузера назад и вперед.
 – 
straya
11 Мар 2020 в 10:25

1 ответ

Лучший ответ

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

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

Почему бы не воспользоваться законами близости и не связывать каждый раз контекст с помощью группировки? Вы также можете объединить месяц и год в один элемент выбора (для этого элемента управления доступны библиотеки) и предложить навигацию по месяцам прямо рядом с элементом управления временем.

enter image description here

2
Community 16 Июн 2020 в 13:51