HIFDocs
HIF / Документация / Представление доказательств

Визуализация данных

Статус: нормативная основа и инженерный справочник

Версия: 0.1

Этот документ определяет, как HIF преобразует данные в проверяемые представления для анализа, объяснения, мониторинга и принятия решений. Визуализация является интерфейсом к процессу формирования данных, а не декором, нанесённым на числа.

1. Цели

Соответствующая HIF визуализация MUST позволять целевой аудитории:

  • определить, что представлено и что не представлено;
  • восстановить релевантные значения, отношения, неопределённость и provenance;
  • различать наблюдения, оценки, прогнозы и цели;
  • выполнять необходимые сравнения без устранимого перцептивного искажения;
  • получать эквивалентный смысл без зрения или различения цвета;
  • проверять преобразования, filters и определения;
  • обнаруживать устаревшие, отсутствующие, скрытые и недопустимые данные;
  • не действовать на основе точности или причинности, не подтверждённой свидетельствами.

Красота, новизна, плотность, engagement и animation вторичны относительно правдивости, соответствия задаче и доступности.

2. Контракт представления

До выбора chart зафиксируйте:

решение или вопрос
аудитория и data literacy
задачи: найти, определить, сравнить, ранжировать, оценить, проследить, объяснить, предсказать
сущности и единица наблюдения
меры, единицы и определения
типы данных и допустимые операции
выборка и процесс формирования данных
неопределённость и missingness
охват времени, географии и населения
преобразование и агрегация
обязательные сравнения
последствия ошибки
каналы представления и режимы доступности

Визуализация MUST NOT подразумевать более сильную шкалу измерений, чем есть у данных. Идентификаторы не являются количествами; упорядоченные категории не обязательно имеют равные интервалы; rate без denominator неполон.

3. Данные, задача и кодирование

3.1. Семантика данных

Классифицируйте каждое поле:

  • nominal category;
  • ordered category;
  • quantitative interval или ratio;
  • temporal instant, duration или sequence;
  • spatial position, region или topology;
  • network relation или hierarchy;
  • text или unstructured content;
  • uncertain distribution, interval или ensemble.

Также определите, является ли оно observed, derived, imputed, modelled, forecast, target или benchmark. Один и тот же числовой storage type может требовать другого представления из-за различной семантики.

3.2. Сначала задача

Типовые классы задач:

  • получить известное значение;
  • найти экстремум или аномалию;
  • сравнить два или более значений;
  • оценить распределение, association или изменение;
  • проследить path, hierarchy или provenance;
  • контролировать threshold или service state;
  • объяснить вывод;
  • исследовать гипотезы;
  • принять решение и действовать.

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

3.3. Expressiveness и effectiveness

Mackinlay различает expressiveness — представляет ли графический язык все и только предусмотренные факты — и effectiveness — хорошо ли он использует носитель и перцептивные способности. HIF применяет их как контрольные этапы:

  1. отклонить encodings, подразумевающие отсутствующие в данных факты;
  2. среди expressive candidates выбрать лучше всего поддерживающий задачу по точности и эффективности;
  3. проверить выбор в целевом контексте.

3.4. Перцептивное кодирование

Оригинальные эксперименты graphical perception Cleveland и McGill продемонстрировали систематические различия в элементарных перцептивных оценках. В их исследованных задачах position на общей шкале обычно давал более точную количественную оценку, чем area, volume или colour saturation.

Их результаты MUST NOT превращаться в неизменный рейтинг charts. Точность зависит от задачи, marks, scale, density, expertise, устройства и взаимодействия. Используйте работу для формирования проверяемых предпочтений:

  • используйте выровненное положение для точного сравнения, где это практично;
  • используйте длину от общей исходной линии для сравнения величин;
  • применяйте угол, площадь и объём, только если их меньшая точность допустима;
  • отводите hue преимущественно категориям, а не точному количеству;
  • используйте lightness или другой ordered channel, только если его воспринимаемый порядок сохраняется в контексте;
  • добавляйте подписи или таблицу, когда важны точные значения.

Трёхмерная перспектива, pictorial area и volume MUST NOT кодировать обычные значения, если создают устранимые occlusion или нелинейный кажущийся размер.

4. Выбор chart

Аналитическая потребностьСильное начальное представлениеОбязательный проверочный вопрос
Точный поискТаблицаУспешны ли также просмотр и сравнение?
Сравнение категорийТочечный график или столбцы на общей исходной линииИмеет ли нулевое значение смысл; читаются ли подписи?
Тренд по упорядоченному времениЛиния или выровненные малые множественные графикиЧестны ли интервалы, пробелы и неопределённость?
РаспределениеDot/strip, histogram, ECDF, box/violin с контекстомВидны ли sample size и предположения о распределении?
ОтношениеДиаграмма рассеяния с подходящей моделью и интерваломУчтены ли наложение, смешивающие факторы и масштаб?
Часть от целогоСоставное положение или длина, часто таблица или столбцыСтабилен ли знаменатель и возможно ли сравнение?
ГеографияКарта плюс непространственное сравнениеНе доминирует ли площадь над величиной; нормализованы ли показатели?
Network или hierarchyNode-link, adjacency matrix или tree по задачеВажнее ли topology, чем сравнение значений?
Мониторинг статусаValues, trend, thresholds и exceptionsОбоснован ли threshold и видна ли свежесть?

Эта таблица даёт гипотезы, а не автоматические предписания. Форма chart MUST следовать сравнению и процессу формирования данных, а не названию из gallery.

5. Scales, axes и координаты

5.1. Контракт scale

Каждая scale MUST определять:

  • domain и range;
  • transformation;
  • единицы и опорный период;
  • нулевое значение, исходная линия или центр;
  • включение boundaries;
  • обработку вне domain;
  • ticks, rounding и точность labels;
  • missing, infinite и invalid values.

5.2. Linear, logarithmic и transformed scales

Logarithmic scale MAY поддерживать мультипликативное сравнение, но:

  • MUST быть явно обозначена;
  • MUST NOT содержать zero или беззнаковые отрицательные значения без определённого transformation;
  • SHOULD предоставлять интерпретируемые ticks;
  • MUST объясняться аудитории, которая может предполагать равные аддитивные интервалы.

Любая normalisation, indexing, smoothing, cumulative transformation, per-capita conversion или inflation adjustment MUST раскрываться рядом с представлением или в непосредственно доступной methodology.

5.3. Baselines

Длина столбца обычно кодирует величину от общей нулевой линии; усечение исходной линии может значительно преувеличить различия и требует другого способа кодирования или заметного обоснования. Line chart может использовать non-zero range, когда задача касается изменения внутри этого диапазона, если axis и контекст честно показывают величину.

Dual axes SHOULD избегаться, когда независимое scaling создаёт визуальное отношение, отсутствующее в данных. При использовании их association, units, transformations и sensitivity MUST быть явными и проверенными.

5.4. Aspect и projection

Aspect ratio может изменять кажущиеся slopes и correlation. Map projection меняет area, shape, direction или distance. Выбранная геометрия MUST соответствовать аналитической задаче, а consequential interpretations SHOULD тестироваться при разумных альтернативных aspects или projections.

6. Статистическая добросовестность

6.1. Агрегация

Агрегация может скрывать вариативность, изменение состава и парадокс Симпсона. Фиксируйте и раскрывайте:

  • unit of analysis;
  • aggregation function;
  • denominator и weighting;
  • определения групп;
  • time window и timezone;
  • suppression и privacy rules;
  • sample size и coverage;
  • релевантную disaggregation.

Mean, median, rate, percentile и total не взаимозаменяемы. Dashboard metric MUST ссылаться на своё operational definition.

6.2. Отсутствующие и censored data

Missing data MUST NOT молча превращаться в zero. Различайте:

  • not collected;
  • not applicable;
  • suppressed;
  • below detection;
  • delayed;
  • invalid;
  • estimated или imputed.

Visual gaps, symbols, labels и accessible descriptions SHOULD сохранять эти различия. Метод MUST объяснять любую imputation и её uncertainty.

6.3. Association и causality

Correlation, temporal sequence и visual alignment не доказывают causality. Если заявляется причинный вывод, представление MUST ссылаться на design, допущения и анализ, поддерживающие идентификацию. Соответствие модели MUST NOT показываться без остаточной неопределённости, релевантной диагностики и границ вывода.

6.4. Точность

Показываемые цифры MUST соответствовать точности измерения и модели. Rounding MUST быть согласованным с сохранением значений, использованных в вычислении. Кажущаяся точность, созданная tooltips, плавными curves или pixel resolution, MUST NOT превышать свидетельства.

7. Неопределённость

7.1. Что представлять

Релевантная uncertainty может возникать из:

  • sampling;
  • measurement;
  • missingness и imputation;
  • model parameters и specification;
  • forecast scenarios;
  • revision и data latency;
  • classification и linkage;
  • natural variability.

Point estimate MUST NOT представляться как определённый результат, если uncertainty может изменить интерпретацию или действие.

7.2. Представление

В зависимости от задачи используйте:

  • intervals или bands с указанными coverage и method;
  • distributions, densities или quantiles;
  • ансамбли или графики гипотетических исходов;
  • диапазоны и наборы сценариев;
  • sensitivity analysis;
  • калиброванные словесные утверждения, связанные с числами;
  • явную неизвестную или неколичественную uncertainty.

Error bar MUST называть, что он представляет: standard deviation, standard error, confidence interval, credible interval, prediction interval или другую величину. Они не взаимозаменяемы.

7.3. Понимание

Представления uncertainty могут быть неправильно поняты. Проверьте, может ли аудитория:

  • определить центральное утверждение и диапазон;
  • отличить неопределённость индивидуального результата от неопределённости параметра;
  • сравнить неопределённость между группами;
  • не интерпретировать interval как бинарный significance test;
  • принять предусмотренное решение на объявленном threshold.

Не удаляйте uncertainty лишь потому, что первый дизайн оказалось сложно объяснить; переработайте представление и поддержку решения.

8. Цвет

Используйте политики из COLOR_AND_THEMING.md. В частности:

  • qualitative, sequential, diverging и cyclic schemes MUST соответствовать типу данных;
  • ordered palettes MUST иметь подходящий перцептивный порядок;
  • diverging centre MUST быть аналитически значимым;
  • цвет MUST дублироваться для consequential distinctions;
  • marks MUST тестироваться при отрисованном размере и фоне;
  • missing и selected values требуют semantic roles;
  • legends MUST сохранять порядок и symbols;
  • внешние palettes требуют записей licence и provenance.

Corporate palette не является автоматически data palette. Brand colours MAY определять издателя или выделять focal series, но MUST NOT превосходить точность, различение или доступность.

9. Annotation, язык и narrative

Titles SHOULD указывать предмет, population, measure и period. Subtitles, annotations и captions MAY сообщать подтверждённый свидетельствами вывод, но MUST отличать наблюдение от интерпретации.

Каждая визуализация SHOULD предоставлять:

  • data source и дату получения/пересмотра;
  • определение measure и unit;
  • filters и coverage;
  • transformations;
  • метод оценки неопределённости;
  • автора, ответственного и путь исправления;
  • доступную выгрузку данных, где это законно.

Порядок narrative MUST NOT скрывать существенные опровергающие свидетельства. Аннотация не должна обрезать временной диапазон, выбирать исходную линию или подчёркивать одно сравнение без раскрытия решения.

10. Взаимодействие

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

  • filter и reset;
  • sort и group;
  • zoom и pan с overview;
  • select и compare;
  • inspect value и provenance;
  • change measure или normalisation;
  • annotate, save и share воспроизводимого state;
  • download data и methodology.

Требования:

  • default view MUST иметь смысл;
  • текущие filters, time, units и selection MUST оставаться видимыми;
  • state SHOULD быть адресуемым и доступным для share;
  • keyboard и non-pointer operation MUST быть полными;
  • focus order и announcements MUST соответствовать визуальной операции;
  • hover-only values запрещены;
  • zoom MUST NOT молча изменять aggregation или semantics;
  • состояния loading, partial, stale, empty и error MUST быть явными;
  • animation MUST быть interruptible и учитывать reduced motion;
  • действие, влияющее на внешнее решение, MUST сохранять audit record.

11. Доступность и мультимодальный доступ

11.1. Многоуровневый доступ

Accessible visualisation SHOULD предоставлять согласованные уровни:

  1. заголовок и назначение;
  2. краткую сводку главного паттерна и исключений;
  3. структурированное описание осей, переменных и способов кодирования;
  4. доступ с клавиатуры к значимым группам и значениям;
  5. доступную таблицу или эквивалентное представление данных;
  6. исходные данные и методику;
  7. необязательные sonification или tactile output, если они поддерживают задачу.

Альтернативный доступ MUST сообщать те же существенные факты и uncertainty, а не только тип chart.

11.2. Семантика

Предпочитайте нативный HTML для заголовков, элементов управления, таблиц и раскрываемых областей. SVG может содержать структурированный текст и семантику, но требует проверенных подписей и порядка чтения. Canvas MUST предоставлять содержательную резервную версию и управляемые альтернативы; пиксели не образуют дерево доступности.

Не добавляйте ARIA roles, поддержка которых предполагается, но не проверена. Объявите поддерживаемую матрицу browser/assistive technology и проверьте фактический output.

11.3. Таблицы

Data tables MUST:

  • определять caption, row/column headers и units;
  • сохранять значимый порядок;
  • раскрывать missing и suppressed values;
  • поддерживать navigation без избыточного повторения;
  • избегать visual-only merged structures, разрушающих связь header;
  • соответствовать активным filters и transformations;
  • оставаться доступными без precision pointer use.

Большие наборы данных MAY использовать постраничную навигацию, группировку или выгрузку, но сводка и текущее подмножество MUST оставаться доступными.

11.4. Sonification

Sonification отображает данные на неречевые аудиопеременные вроде pitch, timing, location или timbre. Она MAY раскрывать trend и pattern или давать альтернативный режим, но MUST:

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

Сонификация не является автоматической заменой доступности.

12. Dashboards и мониторинг

Dashboard — operational interface, а не коллекция плиток charts. Он MUST определять:

  • решения и владельцев;
  • update frequency, last successful refresh и latency;
  • service-level targets и обоснование threshold;
  • normal variation и alert policy;
  • drill-through и recovery action;
  • data quality и outage states;
  • role-based access и обработку sensitive data.

Приоритет:

  1. текущее состояние и существенные exceptions;
  2. trend и сравнение, необходимые для интерпретации состояния;
  3. причина, provenance и затронутая population;
  4. доступное действие и последствие;
  5. более глубокое исследование.

Красный цвет MUST NOT быть единственным alert. Один KPI MUST NOT скрывать distribution, denominator, uncertainty или компенсирующий harm. Показывайте targets отдельно от forecasts и actuals.

13. Вводящие в заблуждение и запрещённые практики

Если документированная аналитическая потребность и ясное объяснение их не обосновывают, HIF запрещает:

  • усечённые baselines величины для сравнения length/area;
  • неравные интервалы, отрисованные как равные spacing;
  • скрытые log или index transformations;
  • 3D perspective и volume для обычного количественного сравнения;
  • scaling dual-axis, выбранный для создания correlation;
  • cherry-picked dates, groups или denominators;
  • cumulative totals, представленные как period rates;
  • missing values, представленные как zero;
  • smoothing, скрывающий reversals или outliers;
  • area maps totals, когда релевантным denominator является population exposure;
  • rainbow order для величины без надёжного перцептивного порядка;
  • animation, мешающую сравнению с предыдущим state;
  • pictograms, area которых растёт в двух измерениях для одномерного значения;
  • декоративную точность или unlabelled extrapolation;
  • dashboards, где stale или failed data выглядят текущими;
  • interaction defaults, выбранные для максимизации предпочтительного вывода.

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

14. Инженерная архитектура

14.1. Объект specification

Каждая поддерживаемая visualisation SHOULD иметь machine-readable specification:

VIS-ID и версия
вопрос и задача
dataset/schema/version
transformations и filters
определения mark и encoding
scales, axes и legends
annotations
машина состояний взаимодействия
структура доступности и сводка
ссылки на тему и токены
адаптивные преобразования
правила экспорта и печати
проверки и доказательства
ответственный и дата пересмотра

14.2. Воспроизводимость

При одинаковых data, specification, token set и версии renderer output SHOULD быть детерминированным. Храните:

  • snapshot source data или immutable identifier;
  • query и transformation code;
  • locale, timezone и rounding;
  • версии library и browser;
  • начальное значение генератора случайных чисел, если применяется выборка;
  • версию сгенерированной доступной сводки;
  • контрольную сумму экспортированных артефактов.

14.3. Адаптивный дизайн

Адаптивная визуализация является сохраняющим задачу преобразованием. Она MAY:

  • переходить от side-by-side к vertically aligned small multiples;
  • сокращать tick density без сокрытия endpoints или существенных events;
  • перемещать legends или использовать direct labels;
  • заменять обзор с деталями на поэтапное раскрытие;
  • предлагать таблицу как основное представление для узкого экрана.

Она MUST NOT лишь уменьшать labels и targets или молча удалять существенную series.

15. Протокол проверки

15.1. Тесты данных и статистики

  • Schema, units и categorical domains валидированы.
  • Aggregates сверяются с доверенным независимым вычислением.
  • Filters, timezone, denominators и missingness проверены.
  • Scale domain и transformation обрабатывают boundary values.
  • Расчёты uncertainty воспроизводят объявленный метод.
  • Подсказки, подписи, таблица и экспорт совпадают с учётом объявленного округления.
  • Состояния stale, partial, failed и revised data воспроизведены.

15.2. Проверки восприятия и доступности

  • Предусмотренные сравнения выполняются точно.
  • Проверены интерпретация chart и понимание uncertainty.
  • Работают клавиатура, масштабирование, перекомпоновка, принудительные системные цвета и уменьшение движения.
  • Проверены структура для программы экранного доступа, сводка, элементы управления и таблица.
  • Проверены диагностика вариантов цветового зрения и нецветовые cues.
  • Sonification, если есть, task-tested и управляема.
  • Проверены small screen, print и репрезентативный display output.

15.3. Проверка враждебных сценариев

Reviewers SHOULD пытаться:

  • прийти к правдоподобному, но неверному выводу;
  • найти скрытые transformations или исключённые populations;
  • воссоздать metric из source;
  • сравнить разумные альтернативные baselines, aspects и aggregations;
  • обнаружить недоступные факты;
  • определить, может ли stakeholder настроить defaults в свою пользу.

Существенные проблемы MUST блокировать выпуск либо публиковаться вместе с ответственным, риском и датой исправления.

16. Источники

Все источники являются англоязычными оригинальными исследованиями, стандартами или официальными спецификациями. Дата обращения: 30 июля 2026 года.