Котятки, добро пожаловать в эту пятничку!🐱
Сегодня я про психологию, -какие наиболее попсовые паттерны и ловушки есть у нашего сознания при восприятии дизайна) Ниже неплохая статья. Из всего того, что есть в статье, я всегда держу в голове, когда рисую макет дашборда, 2 ключевых "обманки":
-человек думает, что это должно работать хорошо, потому что это выглядит хорошо;
-"эффект ряда": человек запомнит то, что в начале ряда и то, что в конце. Поэтому по возможности в макете стараюсь в ряд ставить 2 диаграммы.
Линк: https://usabilitygeek.com/8-psychology-based-design-hacks-that-will-make-you-a-better-ux-designer/
P. S.
Для тех, кто здесь недавно - статья-"освежитель" с основными принципами, применяемыми при создании макетов далбордов - тык.

Когда-то давно у меня была идея реализовать геймификацию на дашборде, но увы, при изучении вопроса выяснилось, что визуализация рейтингов (пусть даже в виде аквариума с рыбками), -это предел возможностей BI -инструментов в этом направлении.
Однако тема игр волнует не только меня)
В статье ниже разработка дашборда сравнивается с разработкой игры. Потоки данных представляются как карта игровых уровней, дашборд раскладывается на артефакты, а выбор графика обосновывается заранее спроектированный "метафорой".
Линк:
https://medium.com/nightingale/designing-a-data-visualization-dashboard-like-it-was-a-game-b347858c1bce

В прошлый четверг я очень долго объясняла пользователю, почему его дашборд будет готовиться 3 месяца, хотя прототип мы сделали меньше, чем за неделю. Для этого пришлось погрузить его в архитектурное решение нашего BI, основанное на использовании хранилища данных.
Линк на статью с описанием типичного многослойного решения:
https://www.datapine.com/blog/data-warehousing-and-business-intelligence-architecture/

Power BI и его отдельные компоненты перманентно настигают меня в виде задач. Наверное, это карма за мою некогда трепетную любовь к excel.
Линк на описание архитектуры и компонентов Power BI:
https://data-flair.training/blogs/power-bi-architecture/amp/

Кстати, по Power BI есть уютный чатик энтузиастов. Там сейчас PBI сравнивают с Grafana, все идём туда и топчем за Tableau😈:
https://t.iss.one/PBI_Rus

Котятки🐱, я чувствую, сегодня у нас день Power BI ) Выше книжечка про архитектуру и не только, а ниже - поваренная книга дашиков на Power BI.
Я не люблю готовые рецепты, но порой без них никак😉

Иногда мы сталкиваемся с картиной: при наличии очевидной бизнес-связи сущностей, на уровне БД они не связаны (например, потому что в базу данных они попадают из разных систем, не интегрированных между собой, или из разных модулей одной IT -системы). Но так как дашборд должен решать бизнес-задачу пользователя вне привязки к it-ландшафту, приходится исследовать данные и достраивать связи и делать маппинги на уровне хранилища данных.
Перед исследованием данных я раскидываю сущности по модели Кенневин, чтобы понять, какие связи в данных наиболее понятны, а где область хаоса и неосознанности.
Линк:
https://m.habr.com/ru/company/hopox/blog/295934/

Котятки, с пятничной🐱)
Когда я выбираю способ визуализации данных, я чаще иду от потребностей и способностей зрителя, и лишь иногда иду от качества самих данных (дискретные/непрерывные, количество одновременных разрезов для представления/атрибутов и пр.).
В статье ниже как раз рассказывается о принципах организации выбора и различных классификациях диаграмм:
https://medium.com/multiple-views-visualization-research-explained/multiple-views-on-how-to-choose-a-visualization-b3ffc99fcddc

Сегодня я медитировала над задачей производственной иерархии и долго недоумевала, почему в моей IT-системе так хранятся иерархии.
Оказалось, это лишь один из способов хранения иерархий данных - materialized path.
В статье ниже вы узнаете, как с помощью join в Tableau быстро преобразовать такие materialized path в идеальные для анализа структуры данных.
Линк:
https://vizpainter.com/reshaping-your-data-in-tableau-working-with-materialized-path-hierarchies/

Если все истории мира можно подогнать под типовые сюжеты (количество разнится, от 4 у Борхеса до 36 у Польти), то почему бы не попробовать как-то упорядочить практики сторителлинга?😜
Интересная статья про типизацию историй данных в дашбордах, с примерами, советами и разбором:
https://help.tableau.com/current/pro/desktop/en-us/story_best_practices.htm

Котятки,
пусть выходные будут интересными)
Меня уже несколько раз просили порекомендовать обучалки по Tableau, как очные, так и дистанционные.
Мое мнение, - идеальных материалов не бывает. Но нужно же с чего-то начинать:)
С 3 февраля стартует курс BI разработчик. Основы работы в Tableau. Думаю, этот курс-прекрасное начало, чтобы просто преодолеть свои страхи перед BI.
В этом курсе вы узнаете, как подключаться к источникам данных, создавать дашборды и отдельные визуализации.

Один день из жизни московского наземного транспорта.

Котятки🐱 Завтра уже начинается рабочая неделя, а сегодня - время вдохновляться и вдохновлять)
Сделаем наши дашборды произведением искусства 🎨✍🎭
Линк: https://medium.com/theymakedesign/website-dashboard-ui-examples-inspiration-58a77503fdb7

Прекрасная статья о распознавании, запоминании и воспроизведении визуализации в нашем разуме👆

anoshin_d_et_al_tableau_2019_x_cookbook_over_115_recipes_to.pdf

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

https://pbpython.com/interactive-dashboards.html

Котятки, сегодня тема дня - бизнес-требования к дашбордам.
В отличие от функциональных ( например, масштабируемость или адаптация размера на любых устройствах) и информационных (например, преемственность данных или использование каких-то единых эталонных справочников) требований, они более свободны с точки зрения формулировок и имеют весьма условное ограничение с точки зрения характеристической области. Ибо почти всё в организации - бизнес)
Я встречала несколько удачных подходов (а по классике смотрим в BABOK):
-требования ограничены форматом дашборда (описание дашборда) ;
-требования ограничены форматом user story (роль+описание действий на дашборда);
-требования в виде метрик/разрезов (без требований к визуальным элементам и макету) ;
-требования в свободной форме, раскрывающие проблемный фактор(в формате "что у вас болит").
Можно пробовать делать микс и идти широкими мазками, как в статье:
https://medium.com/@karlwiegers/tell-me-whats-a-happening-defining-dashboard-reporting-requirements-c47d10a36960

Наверно, самая популярная визуализация с начала этого года:
https://gisanddata.maps.arcgis.com/apps/opsdashboard/index.html#/bda7594740fd40299423467b48e9ecf6