Всем привет! Продолжаем серию про Bad-practice при создании отчетов в Power BI. На этот раз поговорим про использование таблиц (дальше в статье под словом «таблица» понимаем любой табличный визуальный элемент).
Мы не говорим, что таблицы это абсолютное зло и их не должно быть в отчетах Power BI, но при добавлении таблиц и матриц стоит задумываться о том, каким образом пользователи будут работать с отчетом и какие выводы они должны сделать.
Перед разбором плохих практик хотим напомнить, что в Power BI существуют два визуальных элемента «из коробки», которые позволяют отобразить данные в виде таблицы — это таблица (1 на рисунке ниже) и матрица (2 на рисунке ниже).
Рис. 1. Таблица и матрица
Если проводить аналогию с Microsoft Excel, то таблица близка к обычному листу Excel, а матрица — к сводной таблице.
Более подробно об этих визуальных элементах можно почитать в официальной документации Microsoft:
Bad Practice №1. Заставлять пользователя использовать полосы прокрутки (применимо к любым визуальным элементам)
Рис. 2. Использование полос прокрутки
Основные причины, по которым не стоит так делать:
В приведенном примере к тому же используется иерархия, причем состоящая из 4-х уровней. Посмотрите, что получается при раскрытии такой иерархии. Пользователь отчета видит только часть цифр, при этом абсолютно непонятно, что это за данные — не видно ни какой это период, на какая категория товара и т.д.
Рис. 3. Не самая удачная матрица с раскрытой иерархией
Как с этим жить?
Bad Practice №2. Использование длинных имен в заголовках столбцов и строк.
Эта ошибка очень тесно связана с ошибками именования мер и столбцов в модели данных. Начинающие разработчики отчётов как-правило бросаются в одну из двух крайностей — дают либо очень короткие, либо очень длинные имена мерам. При добавлении же меры или измерения в визуальный элемент — оставляют название как есть
Рис. 4. Слишком длинное название столбца
На примере видно, что слишком длинное название столбца приводит к тому, что половина пространства визуального элемента не используется, но при этом часть данных вышла за границы видимости и появилась горизонтальная полоса прокрутки… Думаем, что дополнительных комментариев здесь не требуется.
Что делать?
Рис. 5. Перенос слов в столбце
Рис. 6. Переименование поля в конкретном визуальном элементе
Рис. 7. Использование названия в таблице
Bad-practice № 3. Использовать различные языки в названиях и данных разных языков.
Эта ошибка относится не только к таблицам. В принципе — в отчете you must not использовать разные Sprachen.
Рис. 8. Использование различных языков в отчете
Что делать?
Рис. 9. Отключение автоматических даты и времени.
Bad-practice № 4. Использовать таблицы без условного форматирования
Таблица — далеко не самый наглядный инструмент показа данных — цифр и текста много, все сливается и непонятно что вообще происходит. Например, в таблице, показанной на рисунке — идут продажи хуже или лучше по сравнению с прошлым годом/планом?
Рис. 10. Пример таблицы без условного форматирования
Другой пример — если приглядеться, то можно понять, что происходит. Но это неправильно. Мы же ведь разрабатываем отчёты, чтобы упростить процесс принятия решений, а не для того, чтобы заставлять пользователей рассматривать цифры под лупой. Не так ли?
Рис. 11. Еще один пример таблицы без условного форматирования
Что делать?
Рис. 12. Как добавить условное форматирование для столбца в таблице
Рис. 13. Пример таблицы с условным форматированием
В целом тема условного форматирования достаточно глубокая и сегодня рассмотрим только самые основные моменты. Немного устаревшую, но очень информативную статью о настройке условного форматирования в таблицах можно найти в официальной документации: https://docs.microsoft.com/ru-ru/power-bi/desktop-conditional-table-formatting
Отличное видео о настройке условного форматирования по другому столбцу (англ.): https://www.youtube.com/watch?v=FgnPIaxpdJ0
Bad-Practice №5 Неверный подбор измерений для столбцов и строк.
Осмысленность подбора измерений для таблицы. Каждый раз, когда Вы создаете визуальный элемент или отчет, стоит задавать себе вопросы — «Какой вывод должен сделать пользовать этого отчета?», «Удобно ли мне работать с этим отчетом?». Как только Вы их начнете себе задавать — Вы обнаружите, что многие из визуальных элементов содержат избыточный или недостаточный набор данных или просто неудобны для работы.
На рисунке ниже показана матрица с использованием в иерархии двух разнородных измерений — даты и товаров. Не можем сказать, что это грубая ошибка. Скорее это пример бессмысленной таблицы. Обычно пользователи отчета анализируют либо несколько показателей внутри одной иерархии, либо один показатель в двух разрезах. В данном случае добавление иерархии товаров явно избыточно. Более целесообразно вынести ее либо в секцию фильтров, чтобы пользователь мог анализировать тренд по отдельной категории или товару, либо оставить один факт (Продажи итого) и переместить одну из иерархий в столбцы (например, даты).
Рис. 14. Не самый удачный подбор измерений
Выбор измерений для столбцов и строк — достаточно часто начинающие разработчики добавляют измерение с большим или часто меняющимся количеством или значениями в секцию столбцов. Это не совсем правильно, поскольку приводит либо к появлению «широкой таблицы», которая неудобна для анализа, либо ширина столбцов будет постоянно изменяться (поскольку обычно не отключают автоподбор ширины столбца в настройках). Так, например, календарные периоды стоит использовать в качестве измерения строк, а не столбцов.
Bad-Practice №6 Игнорирование форматов данных
К сожалению, часть разработчиков отчетов не уделяет достаточного внимания форматам данных. В результате встречаются подобные ляпы:
Рис. 15. Неверный выбор форматов данных
В этой таблице сразу несколько грубых ошибок связанных, с форматированием:
Форматы данных это также достаточно большая тема, поэтому выделим несколько основных моментов:
Рис. 16. Настройка форматирования поля на уровне визуального элемента
Продолжение следует...