Контракт данных и визуализации

DFC Bridge рассматривает отображение данных как продуктовый контракт, а не как пример текста, разложенный по прямоугольникам. В переносимом макете понятно, что означают данные, откуда они поступают, как форматируются, что пользователь может с ними сделать и что происходит, когда идеальный набор недоступен.

Один пример месячной выручки даёт график и таблицу с одинаковыми actual и target; ниже — состояния данных — Читайте от примера к двум представлениям: факт 120 USD и план 150 USD сохраняют смысл в графике и таблице. До выбора представления задайте единицы, агрегацию, форматирование и другие преобразования; также опишите loading, empty, error, partial и stale. Пример иллюстрирует значения, но не задаёт рабочий источник или полный контракт данных. Открыть в полном размере.

У одного набора данных может быть несколько явно заданных представлений. Форматирование и адаптивная композиция не должны менять его смысл.

Что входит в контракт

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

Аспект	Обязательное решение
Назначение	На какой вопрос отвечает представление и какое решение помогает принять.
Схема	Ключи полей, типы значений, допустимость `null`, идентификаторы и связи.
Количество	Минимум, обычный и максимальный объём, пагинация или виртуализация, известность общего количества.
Происхождение	Система или владелец данных, способ агрегации, время обновления и правило устаревания.
Представление	Смысл колонок и рядов, порядок, группы, сортировка, фильтры, база сравнения и точность.
Формат	Локаль, часовой пояс, валюта, единицы, знак, округление, обозначение отсутствующего значения, формат дат и чисел.
Состояния	Загрузка, пустой результат, ошибка, частичные и устаревшие данные, работа без сети и отсутствие доступа.
Адаптивность	Одна структура либо объявленное преобразование с сохранением смысла.
Доступность	Название, описание, заголовки и связи, управление с клавиатуры, невизуальный эквивалент.
Доверие	Ограничения, оценки, размер выборки, приватность и подавление значений, время последнего обновления.

Примерные значения в Figma — тестовые данные. Они не заменяют схему, максимальную длину, правила точности и источник рабочих данных.

Роли: содержимое, данные и управление

Содержимое — продуктовый текст: заголовок, объяснение, сноска или аннотация.
Рабочие данные поступают из сервиса, CMS, вычисления, датчика или пользовательского ввода.
Представление данных отображает их в таблице, сетке, метрике, списке, карте или диаграмме.
Управление меняет запрос или представление: фильтр, сортировку, период, страницу, детализацию или видимость ряда.
Происхождение объясняет, почему данным можно доверять и насколько они свежие.

Не смешивайте роли. Заголовок диаграммы не является полем данных; выделенный максимум не становится новым значением; фильтр не входит в коллекцию результатов.

Короткие теги для слоёв, полный контракт — в структуре

В именах слоёв и существующих тегах DFC Bridge оставляйте только опорные идентификаторы:

revenue [section=revenue-overview]
  period-filter
  revenue-chart
  revenue-table
  data-status

Не кодируйте схему десятками тегов вроде [series-revenue], [currency-usd] и [timezone-utc]. Привяжите к revenue-chart единый структурированный контракт:

Неполный фрагмент модуля. Здесь показан только bridge.data, а обязательные поля оболочки намеренно опущены. Перед обменом или проверкой полного контракта вставьте его в обязательную оболочку bridge из контракта переноса.

{
  "bridge": {
    "data": {
      "displays": [{
        "displayId": "revenue-chart",
        "purpose": "Compare recognized revenue with target by month",
        "source": { "owner": "finance-analytics", "dataset": "recognized-revenue", "refresh": "daily", "staleAfter": "PT36H" },
        "dimensions": [{ "key": "month", "type": "year-month", "timeZone": "UTC" }],
        "measures": [
          { "key": "actual", "type": "decimal", "currency": "USD", "aggregation": "sum" },
          { "key": "target", "type": "decimal", "currency": "USD", "aggregation": "sum" }
        ],
        "format": { "locale": "user", "notation": "compact", "maximumFractionDigits": 1 },
        "states": ["loading", "empty", "error", "partial", "stale"],
        "accessibleEquivalent": "revenue-table"
      }]
    }
  }
}

В примере revenue-chart и revenue-table показывают одни и те же фактические и плановые значения. Для смены period-filter нужна ещё реакция: что загружается, что остаётся видимым и как сообщается ошибка. Запись данных сама по себе не описывает взаимодействие.

Структурированные метаданные можно версионировать и проверять независимо от целевой платформы. Они могут храниться в plugin data Figma, сопроводительном файле или структуре адаптера, но должны ссылаться на стабильные идентификаторы DFC Bridge и передаваться вместе с макетом.

Таблицы

Контракт таблицы задаёт:

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

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

Сетки, списки и повторяющиеся карточки

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

Число колонок не меняет количество элементов:

product-grid
  product-card-oak-chair
  product-card-wool-lamp
  product-card-steel-desk
  product-card-cork-stool

Это стабильные ключи экземпляров тестовых данных в макете, а не позиции массива и не идентификаторы рабочей базы. У повторяемого элемента разделены templateKey для шаблона карточки, designInstanceKey для подготовленного примера и runtimeDataKey (или другой продуктовый ключ записи) для сопоставления после сортировки, фильтрации, пагинации и живых обновлений. Связь задаёт структурированный контракт, а не суффиксы -1 и -2. Нельзя раскрывать конфиденциальный внутренний идентификатор только ради контракта.

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

Диаграммы и карты

Контракт каждой диаграммы задаёт:

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

Не кодируйте ряд или статус одним цветом. Метки и графические элементы должны иметь достаточный контраст, подсказки — открываться с клавиатуры и указателя, а SVG или canvas не должны быть единственным носителем информации. Подход к сложным изображениям описан в руководстве WAI.

Формат — часть смысла

Объявляйте региональное форматирование, а не копируйте видимые знаки:

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

Сокращение и округление не должны создавать противоречивые итоги. Там, где нужна точность, полное значение остаётся доступным.

Обязательные состояния данных

Состояние	Вопрос контракта
Загрузка	Сохраняются ли предыдущие данные, определён ли прогресс и что объявляется пользователю?
Пусто	Запрос корректен, но результатов нет? Какое действие помогает продолжить?
Ошибка	Какая операция не выполнена, что осталось доступно и возможен ли повтор?
Частично	Какой части нет и можно ли действовать по неполным данным?
Устарело	Насколько стары данные, почему они показаны и как запросить обновление?
Нет сети	Что закэшировано, какие действия отложены и как сообщается восстановление связи?
Нет доступа	Содержимое скрыто, отредактировано или заменено запросом прав?

Скелетон должен повторять будущую структуру, но не изображать настоящие данные. Обновление сохраняет фокус и выбор; озвучивается только изменение, значимое для задачи.

Адаптивные преобразования данных

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

Если представление действительно меняется — таблица превращается в карточки, несколько рядов в малые диаграммы, встроенные детали в раскрывающийся блок — объявите адаптивное преобразование. Оно фиксирует:

исходные и результирующие идентификаторы;
условие по контейнеру или области просмотра;
сопоставление полей и рядов без потери смысла;
порядок чтения, фокуса и действий;
расположение скрытых деталей и путь к ним;
сохранение состояния, выбора, фильтров и URL/истории;
доступный эквивалент каждого представления.

Узкий экран не разрешает удалять поля сравнения, происхождение данных или способы восстановления. См. правила адаптивов.

Условие готовности

Эти вопросы проверяют полноту контракта представления данных, а не присваивают всей странице статус «Готово» и не подтверждают реализацию:

Можно ли реализовать его без выдуманных полей и форматов?
Проверены ли ноль, один элемент, обычный и максимальный объём, длинные, отсутствующие, устаревшие, частичные и ошибочные данные?
Явны ли источник, обновление, единицы, точность и часовой пояс?
Полностью ли описаны реакции и состояния сортировки, фильтров, пагинации, выбора и детализации?
Сохраняются ли смысл и выполнение задачи на узкой ширине?
Получит ли пользователь клавиатуры или скринридера те же значения и выводы?
Видны ли необходимые ограничения, оценки, приватность и подавление данных?

Предыдущая
Контент Следующая
Состояния