Всем привет!

Меня зовут Наташа. Последние 10 лет я так или иначе работаю с данными и программирую визуализации.

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

В России область визуализации данных (в отличие от того же дизайна) развита не очень хорошо. Хочется начать это менять. Присоединяйтесь!

​​Начать я хочу с примера, который немного рифмуется с текущими событиями.

В 1854 году в центральном Лондоне была вспышка холеры. Британский врач, доктор Джон Сноу (который очень много знал и даже стал основоположником эпидемиологии) исследовал эту вспышку и придумал нанести на карту точки в местах домов, где умирали люди. На получившейся картинке стало видно, что все смерти сконцентрированы на одной улице (Broad Street) вокруг одного колодца, снабжавшего водой весь район (обозначен крестиком посередине улицы). Когда колодец закрыли, эпидемия пошла на спад и вскоре закончилась.

#пример

​​Эдвард Тафти и его правила создания визуализаций

История и картинка выше взяты из книги Эдварда Тафти "The Visual Display of Quantitative Information". Эта книга — это, пожалуй, главная базовая книга в мире по визуализациям данных.

Эдвард Тафти — американский статистик и профессор Йельского университета. Он известен своими работами по информационному дизайну, придуманному им графику спарклайну (такие маленькие линии, рисуемые сразу в тексте, часто используются для отображения изменения курсов акций) и выпущенной серии книг. Первая редакция первой книги (именно её я упомянула выше) вышла ещё в 1983 году. Я покупала в 2013 году на американском Амазоне уже второе издание 2001 года.

Главное, что продвигал в своих книгах Тафти — чистота и честность отображения информации. На первом месте в любой визуализии должны быть данные, а не дизайн или интерпретация. Изучив множество примеров хороших и плохих графиков, Тафти придумал понятие "data-ink ratio", то есть коэффициент соотношения данных и чернил. Он вычисляется как отношение чернил, используемых для данных, ко всем чернилам графика.

Цель дизайнера при придумывании визуализации — максимизировать этот коэффициент. Тафти приводит несколько примеров разных графиков и их преобразований без потери смысла и данных. Например, графика свечей на картинке ниже. Я не всегда согласна с подобными радикальными изменениями. На мой взгляд, на восприятие и понимание графиков влияет их узнаваемость в том числе. Но я однозначно за убирание ненужного объёма, бессмысленных сеток и сплошных штриховок.

#книга #теория

​​Визуализации сортировок

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

А вот три ссылки на очень классные визуализации, которые мне совершенно не надоедает рассматривать:

1. sorting.at — пошаговое сравнение разных алгоритмов, считает количество необходимых шагов.

2. Часть большой статьи Майка Бостока (автора библиотеки d3.js) про алгоритмы. Мне здесь очень нравится идея с сортировкой наклонённых палочек.

3. Видео сортировок в закрашенном разноцветными плитками квадрате с достаточно подробными объяснениями.

#алгоритмы #пример

Выбор цвета

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

Так я узнала, что радужная палитра не подходит ни в одной визуализации. У неё есть две основные проблемы:

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

2. Нет установленного порядка цветов, они зациклены. Если кодировать диапазон значений, то непонятно, какой цвет означает минимум, а какой — максимум.

В любом цвете есть три составляющих: оттенок (hue), насыщенность (saturation) и значение (value). Эти параметры собираются в цветовую модель HSV. Иногда вместо насыщенности цвета используют параметр светлоты (lightness), это модель HSL. Модель HSV более интуитивно описывает цвет, чем известная всем RGB. Не «сколько в этом цвете красного или зелёного?», а «какой у этого цвета оттенок, насколько он насыщенный?».

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

1. Стараюсь учитывать стандартные стереотипы. Синий цвет — холодный, красный — горячий, оттенки голубого и синего — глубина, оттенки коричневого — высота, зелёный — успех, красный — ошибка и т.д.

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

3. Цвет, как и дизайн в целом, не должны отвлекать от данных. Если визуализация непонятна в чёрно-белом варианте, то выбор цвета ничего не изменит.

А чтобы каждый раз не придумывать палитры самостоятелько, их можно подсматривать в сервисе Color Brewer.

#теория #цвет

Таймлайн основания европейских городов

В прошлые выходные я доделала новую визуализацию:
🔗 таймлайн основания европейских городов

Идея пришла мне в голову зимой в поездке по Золотому кольцу. Мне стало интересно проследить историю возникновения и развития городов древней Руси. Я попробовала найти данные, но тут возникли проблемы. Без вдумчивого и детального исследования выяснить состояние городов почти тысячу лет назад оказалось практически невозможно. Поэтому для начала я решила упростить задачу и взять только года основания. В итоге ограничиваться только Русью мне показалось скучным, и я расширила задумку на Европу.

Я выбрала 64 города (из них 11 российских) — столицы или крупные центры, существующие в настоящее время. Решила ограничить временной период, поэтому Древняя Греция в данные не вошла, а Римская империя уже вошла. Все данные я взяла из англоязычной википедии. До нашей эры года в основном приблизительные и округлённые, после нашей эры нашлись уже более точные значения.

Весь код написан на чистом JavaScript. Для рисования карты я использую Leaflet с Stamen тайлами. Последнее время они мне нравятся больше всего, потому что у них очень мало деталей и есть чёрно-белый вариант, который не акцентирует на себе внимание.

#визуализация

Оптимизация скорости

Хочу оставить здесь две ссылки, которые регулярно приходится искать:
https://gist.github.com/paulirish/5d52fb081b3570c81e3a
https://csstriggers.com/

Они про оптимизацию скорости отрисовки страницы в браузере при изменении разных свойств элементов в JS и CSS.

Каждый раз, когда что-то меняется в коде, браузер делает операции reflow (перестроение дерева DOM элементов) и repaint (изменение внешнего вида элементов). Иногда эти операции могут быть очень тяжёлыми и могут очень сильно замедлить отрисовку.

Например, вычисление element.offsetWidth в цикле может иногда привести к заметным зависаниям. А изменение свойств transform или opacity работает обычно быстрее, чем абсолютное позиционирование, потому что не влияет на элементы вокруг и использует аппаратное ускорение.

Если подробнее, то вот это хороший курс на тему, который я когда-то сама смотрела:
https://www.udacity.com/course/browser-rendering-optimization--ud860

#практика #оптимизация

Для вдохновения

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

Ещё иногда я люблю рассматривать генеративную графику. И тут у меня есть 2 сайта с крутыми примерами: Tyler Hobbs и Generated Space.

#ссылки

Как инвертировать фото с помощью HTML5 canvas

Сегодня работа как-то не клеилась, поэтому я решила поучаствовать в еженедельном Codepen Challenge. В этот раз тема — эффекты наведения на изображениях.

https://codepen.io/gnykka/pen/LYpxJEe

Это небольшой пример инвертирования части картинки. Я загружаю фото, рисую его на HTML5 canvas, попутно сохраняя и инвертируя цвета. При наведении мышки я определяю, какая часть изображения попала в область, и рисую её в инвертированном варианте.

Похожий подход я использовала, когда делала один из проектов в прошлогоднем Парке Интуиции, MDWRLD. Там все фото и картинки рисуются на наскольких canvas. Они смещаются с разной скоростью и этим создают эффект параллакса. Быстрой перерисовки и плавности скролла удалось добиться благодаря предобработке фото при загрузке. Каждое фото загружается, запоминается в виде последовательности своих пикселей и на всякий случай сразу же инвертируется. А потом уже очень просто при любом сдвиге поместить эту последовательность в новое место.

Главная проблема canvas в том, что обычно при любых изменениях перерисовывать приходится сразу всё. В svg проще — изменил один элемент и всё готово. Ну и векторная графика прекрасно масштабируется, а на canvas вечно надо ухищряться, чтобы избежать размытости.

#практика #canvas

Визуализации коронавируса

Главная тема последних месяцев — коронавирус. И в визуализациях тоже. Дня не проходит, чтобы я не наткнулась на десяток новых графиков: лайнграфы, карты, сравнения стран, сложная аналитика, и прочее, и прочее.

Сначала я тоже думала: о, прекрасная тема для анализа, большой масштаб, полно официальных данных — идеально же! А потом, размышляя над этим подробнее, я поняла, что в подобной ситуации делать визуализации — плохая мысль. Даже, можно сказать, вредная.

Любая аналитика, особенно в виде красочной картинки, оказывает влияние на людей. Если анализ драматичен и эффектен, то это бесспорно вызовет вау эффект. А ещё это может заставить кого-то нервничать. Или вселить надежду, возможно даже опасно ложную.

Ещё есть проблема в самих данных. Не очень понятно, как сравнивать страны между собой. Китай скорее всего врёт (у них даже умершие задним числом прибавляются), в Германии и США тесты делаются всем подряд, а в каких-нибудь Камбодже или Индонезии вообще нормальной медицины в их местных джунглях нет. Я была в Камбодже, какие там самодистанцирование и официальная статистика?

Или взять процент смертности. Немцы делают огромное количество тестов, поэтому выявляют много бессимптомных случаев. А в Италии тесты вначале делали только в больницах, поэтому процент положительных тестов был выше, тяжёлых случаев больше, смертность выше. Я сейчас сижу в Турции, она на седьмом месте по общему числу случаев заражения, но почти все они в Стамбуле. Означает ли это, что в Турции сейчас опасно?

Если честно, у меня нет ответов на подобные вопросы. Я сама смотрю официальную статистику, но стараюсь ориентироваться и сравнивать внутри одной страны. Вот что было бы интересно сделать — изучить данные на предмет аномалий и попробовать понять, где и что неточно. Но тут тоже возникает вопрос — как понять, что что-то неточно, когда сравнить не с чем?

#мысли

Сравнение библиотек для рисования

На прошлой неделе я углубилась в изучение существующих библиотек рисования графики. Их оказалось просто огромное количество под совершенно разные нужды. Например, PixiJS — очень мощный и популярный движок для создания игр, а Draw2d заточен под рисование диаграмм или графов.

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

Результат можно найти тут: benchmarks.slaylines.io
Код — здесь: github.com/slaylines/canvas-engines-comparison

Почему такой выбор? Нужна была библиотека, которая умела бы быстро перерисовывать весь экран, а значит, нужен был canvas (желательно с поддержкой webgl). PixiJS — очень популярная штука, вокруг которой есть большое комьюнити (это обычно безумно важно при разработке чего-то не одноразового). Two.js на первый взгляд показался очень симпатичным, простым и минималистичным. Paper.js приглянулся направленностью на работу с векторной графикой.

А выводы из сравнения у меня такие:

1. PixiJS — очень крутой и шустрый движок, который умеет без проседания fps рисовать тысячи элементов. При этом он довольно сложный, с огромным количеством всего. Не стала бы брать его на маленькие и простые проекты, но вот для больших и долгих он в самый раз.

2. Two.js умеет переключаться между webgl, canvas и svg. В режиме webgl может без заметных тормозов перерисовывать 5 тысяч элементов. Но первый раз рисует эти 5 тысяч очень долго.

3. У Paper.js нет поддержки webgl, поэтому даже 2 тысячи элементов начинают тормозить. Ещё там можно использовать специальный тип скриптов для быстрого создания сцены, хотя я этим не воспользовалась и писала всё в обычном JS коде.

#практика #canvas

Моё вчерашнее демо вызвало довольно активное обсуждение на Hacker News:

Show HN: Canvas engines performance comparison – PixiJS, Two.js, and Paper.js

Выделю интересный тредик про рисование текстур. Есть пример использования PixiJS для рисования огромного количества зайцев. Можно добавить больше 50 тысяч зайцев и не просесть в fps. Это действительно впечатляюще, хотя вполне объяснимо: там загружается всего 5 текстур зайцев, потом они просто переиспользуются. Текстуры работают быстрее чистого рисования графики, можно было бы сделать текстуру квадрата и добавлять её на поле. Хотя это было бы нечестно по отношению к другим библиотекам.

Вот ещё полезное обсуждение, почему все эти фреймворки не используются в обычных веб сайтах, раз они так быстро всё рисуют. Если кратко: из-за недоступности элементов, когда они просто отрисованы на канвасе и недоступности технологий типа webgl на всех устройствах.

И немного дискуссии про циклы и что лучше читается в коде: map, forEach и тд или старый добрый for loop. Мне тут справедливо указали на то, что обычный цикл for быстрее моего любимого функционального подхода.

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

Напишите мне, если было бы интересно посмотреть какую-то ещё библиотеку.

#практика #обсуждения

​​Самокаты в Вашингтоне

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

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

Сейчас, благодаря Мише (@ohblog), ко мне в руки попала база с данными по перемещениям самокатов разных компаний в трёх городах США (Вашингтон, Атланта и Провиденс). Всего в базе больше полумиллиона строк с координатами и уровнем заряда всех самокатов в каждом городе каждые 5 минут.

Я пока ещё думаю, что и как я хочу сделать с этими данными. Но вот, например, картинка с положением всех самокатов в течение одного дня (1 августа, 1 сентября и 1 октября) в Вашингтоне. Если что, это не количество всех самокатов, а все места, откуда они сообщали свои координаты.

#визуализация

Код и искусство

Миша скинул мне сегодня очень классную лекцию The Art of Code. Она про использование кода для создания бесполезных на первый взгляд вещей, про написание кода как вид искусства, не ради результата, а ради самого процесса. Это не совсем техническая лекция, если что, хотя там есть код в виде сонетов Шекспира, например.

А вот несколько особенно интересных и классных мест в видео:

4:36 — знаменитая игра «Жизнь» Джона Конвея (Conway's Game of Life). Это клеточный автомат, живущий по нескольким простым правилам. С его помощью можно создавать паттерны, живущие вечно, повторяющиеся во времени или генерирующие новые паттерны.

20:00 — как работает распознавание изображений и какие безумные картинки можно получить, если поиграться с ним.

25:43 — про написание программ, где сам текст программы выглядит как произведение искусства. Например, код в виде фрактала Мандельброта.

36:41 — можете представить себе язык в стиле сонетов Шекспира? А такой есть — Shakespeare Programming Language! Или язык, где программы — реальные рецепты, по которым можно приготовить шоколадный торт, например.

39:42 — язык Piet (назван в честь Пита Мондриана). Программы на нём пишутся с помощью цветных блоков и похожи скорее на абстрактные картины. Можно писать картины, в которых будут зашифрованы стихи (написанные на языке из сонетов Шекспира, ага).

43:27 — язык Sonic Pi, придуманный для создания электронной музыки.

46:40 — а это прям самая офигенная часть! В 2018 году автор лекции придумал на салфетке в баре свой язык Rockstar, где весь код похож на тексты песен из heavy metal. Например: Rockstar is a big bad monster — присвоение переменной Rockstar значения 1337.

Сегодня у меня появилась новая цель в жизни: теперь я хочу стать certified rockstar developer!

#ссылки

Видеоподкаст про визуализации

Рома Бунин, автор канала Reveal the Data, запустил видеоподкаст про визуализации данных и позвал меня во второй выпуск.

Мы там говорим про программирование, визуализации в вебе, разные инструменты и технологии. А ещё я рассказываю, как я вообще дошла до жизни такой и как делала аналог D3 в 2010 году, когда это всё ещё не было мейнстримом!

#подкаст

​​DataFest Tbilisi

В прошедшие выходные я участвовала в онлайн конференции DataFest Tbilisi. Вернее, я скорее следила за ней, чем полноценно участвовала, но что-то интересное почерпнула.

Понравился второй день, особенно вокршоп Valentina D'Efilippo про карты (Maps in the Time of Corona). Задание было забавное: сначала нужно было по памяти от руки нарисовать карту мира, а потом на ней нарисовать визуализацию чего-то повседневного из жизни. Я в итоге показала все свои чаты и созвоны за май, аж 10 разных городов набралось.

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

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

#ссылки #визуализация

SVG анимации

Последние 2 недели я активно делала проект для Парка Интуиции. О нём я пока молчу до публичной публикации, но расскажу про некоторые особенности разработки. Я делала для него много svg анимаций в том числе зависящих от скролла. Решила собрать несколько небольших примеров и поделиться ими.

1. https://codepen.io/gnykka/pen/KKVVXMv
Самый простой способ сделать анимацию — нативный, в самом svg. Наряду со стандартными и привычными всем элементами типа path, circle и т.д. в svg есть элемент animation. Можно сделать автоматическую анимацию какого-то свойства (например, прозрачности) или запускать анимацию из кода. Можно взять элемент animateMotion и сделать анимацию движения по траектории.

2. https://codepen.io/gnykka/pen/QWyyqJQ
Второй простой и стандартный способ — анимация в css с помощью keyframes. Тут уже svg ничем не отличается от любого другого html элемента. Удобство в том, что можно делать сложные анимации относительно просто без написания кода. Здесь, кстати, может помочь отличная шпаргалка про easing functions.

3. https://codepen.io/gnykka/pen/ZEbqraW
Ну и сложный способ для ценителей — через код можно сделать практически всё, что угодно. Например, морфинг объектов. Или можно привязывать изменение свойств элементов к положению скролла. Или объединить и делать морфинг по скроллу (как раз наш случай). В примере выше я тестировала плагин Greensock, но потом выяснила, что он доступен только по подписке. Ещё я попробовала KUTE.js, но там морфинг какой-то ограниченный и не очень красивый. Так и не нашла удобного инструмента, посоветуйте мне, если знаете такой!

А то, что у нас получилось, покажу на следующей неделе.

#практика #svg #анимации

Проект «Искажения»

Неделю назад я обещала рассказать про проект в Парке Интуиции. Мы делали его целый месяц и сегодня наконец-то опубликовали. Это рассказ про когнитивные искажения и человеческие заблуждения с анимированными иллюстрациями и интерактивными задачками.

bias.slaylines.io

Началась история с моего желания сделать что-то со скроллителлингом. У ребят из нашей команды в свою очередь было желание рассказать про разные обманки мозга. На этом мы объединились и сузили тему до реализуемой за месяц. Вова Тупикин и Никита Ларионов нашли материал и придумали весь текст. Даша Колесникова нарисовала иллюстрации, связанные визуально и по смыслу с разными абзацами текста. А я всё это собрала в единую штуковину.

Steamgraph

Давненько не брала я в руки шашек! То есть не кодила красивых и бессмысленных графиков на d3. Вчера мне внезапно захотелось сделать steamgraph. Получился такой динамический пример:

https://codepen.io/gnykka/pen/ZEQJOmG

#практика #d3

​​Моё главное развлечение последней недели — генерация лабиринтов. Уже полгода у меня на ноуте лежит книга Mazes for Programmers, но добралась я до неё только сейчас.

Книга оказалась интересной, в ней объясняются алгоритмы построения и решения лабиринтов. Объясняются просто, в картинках и описаниях без лишних математических формул. Пока я освоила первую главу из четырёх. Там рассматриваются основные 6 алгоритмов для генерации идеальных (perfect) лабиринтов. Это в которых нет недоступных клеток, то есть из любой выбранной клетки можно попасть в любую другую.

Самые простые алгоритмы это Binary Tree и Sidewinder. Они создаются абсолютно случайно (фактически подбросом монетки в каждой клетке), поэтому имеют очень предсказуемую структуру. Противоположны им Aldous-Broder и Wilson's. С их помощью лабиринты получаются сложными и без угадываемой структуры, но создаются очень долго из-за большого числа случайных блужданий. Два последних алгоритма, Hunt and Kill и Recursive Backtracker, ограничивают блуждания, поэтому работают быстрее и эффективнее. А ещё у них меньше всего тупиков.

В следующих главах рассматриваются другие алгоритмы, лабиринты сложной или необычной формы, трёхмерные лабиринты и прочее. Буду ещё рассказывать. А это лабиринт, созданный методом Hunt and Kill

#алгоритмы #лабиринты