Как проектировать адаптивные таблицы

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

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

В примерах используется вымышленная очередь проектов на проверку: название проекта, ответственный, статус, срок и число открытых комментариев.

Найдите связь, которую необходимо сохранить

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

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

У проверяющего, который открывает назначенный ему проект, другая потребность. Для него могут быть важны название, статус и понятное действие, а прочие подробности можно показать позже. Компактная сводка с раскрытием здесь может подойти. Набор данных тот же, но необходимое первоначальное представление отличается.

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

Отделите ширину таблицы от ширины страницы

Широкая таблица не обязана заставлять всю страницу прокручиваться вбок. В CSS обёртка с overflow-x: auto может дать адаптивной таблице собственную область прокрутки, пока заголовок, описание, фильтры и окружающий текст помещаются в области просмотра. Сама обёртка тоже должна иметь возможность сжиматься внутри макета: дочерний элемент на всю ширину в негибкой колонке сетки всё равно способен раздвинуть всю страницу. Так двумерная область остаётся локальной для содержимого, которому она нужна.

В объяснении критерия Reflow W3C допускает исключение для контента, чей смысл или использование требуют двух измерений, включая таблицы данных. При этом различаются сама таблица и содержимое отдельных ячеек, которое всё равно должно соответствующим образом перестраиваться. Это исключение не даёт основания выводить за границы каждую подпись или окружающий абзац. Объяснение критерия Reflow от W3C.

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

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

По возможности держите название таблицы и контекст задачи вне прокручиваемой области. Заголовок «Проекты, ожидающие проверки» объясняет, что объединяет записи. Короткое примечание может пояснять исходную сортировку или значимый часовой пояс. Это ориентиры, а не дополнительные столбцы, которым нужно конкурировать за место.

USWDS показывает два действительно разных способа адаптации

Компонент таблицы U.S. Web Design System предлагает варианты с прокруткой и вертикальным расположением записей. Пример с прокруткой сохраняет матрицу; вертикальный вариант на узкой ширине представляет подписанные значения внутри отдельных записей. Работающие примеры наглядно показывают различие.

Это различие важнее названий компонентов. Матрица передаёт связь между двумя столбцами через положение. Вертикальная запись повторяет подписи, чтобы один объект можно было прочитать независимо. Данные могут быть одинаковыми, а усилия, требуемые для их сравнения, — существенно разными.

Попробуйте на очереди проверки: найдите самый поздний срок среди проектов, у которых больше пяти комментариев. В таблице можно вместе просматривать столбцы количества и даты. На карточках, возможно, придётся проходить каждую запись, удерживая в памяти предыдущего кандидата. Теперь измените задачу: «Прочитайте ответственного и срок проекта Cedar Lodge». Вертикальный вариант может оказаться удобным, потому что сравнение больше не главное.

Выбирайте преобразование с учётом затрат читателя

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

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

Четыре способа адаптации и их компромиссы

1. Сохранить таблицу и горизонтальную прокрутку

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

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

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

Пересечения закреплённых элементов требуют внимательного визуального оформления. Верхняя левая ячейка может находиться одновременно над закреплённой строкой заголовков и над закреплённым первым столбцом. Без понятного порядка слоёв и непрозрачного фона значения могут просвечивать или накладываться. Такая деталь способна хорошо выглядеть на неподвижном изображении и ломаться при прокрутке.

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

2. Показать приоритетные столбцы, остальные раскрывать

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

Для проверяющего название проекта, статус и срок могут составить полезное компактное представление. Ответственный и число комментариев могут появляться в раскрытой строке. Для руководителя, который ищет просроченную работу с нерешёнными комментариями, скрывать количество было бы неудачным решением. Универсального списка «мобильных столбцов», независимого от задачи пользователя, нет.

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

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

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

3. Превратить каждую запись в карточку с подписями

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

В вымышленной таблице проектов карточка могла бы иметь заголовок Cedar Lodge, за которым идут статус, срок, ответственный и открытые комментарии. Как одну запись это читать удобно. Но для сравнения числа комментариев у десяти проектов теперь придётся снова и снова искать одну подпись на гораздо более длинной странице.

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

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

Не добавляйте подписи только декоративным генерируемым содержимым, не проверив результат для доступности. Видимая подпись «Срок» и программно определимая связь — отдельные вопросы. Итоговая разметка должна связно передавать данные и тем, кто не смотрит на визуальную карточку.

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

4. Дать людям выбрать, что сравнивать

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

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

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

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

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

Сохраняйте смысл подписей, чисел и пустых ячеек

Адаптация часто выявляет слабые правила оформления контента. Дата «04/05» неоднозначна и на большом экране, но без места для окружающего объяснения проблема заметнее. Предпочитайте формат, подходящий аудитории, и указывайте часовой пояс или контекст относительных дат там, где они влияют на задачу.

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

Решите, как представлять отсутствие данных. «Не назначен», «Нет комментариев» и «Недоступно» описывают разные состояния. Пустая ячейка этого не делает. В примере проверки ещё не назначенный ответственный не должен выглядеть так же, как поле, которое не загрузилось.

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

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

Сохраняйте правильную область действия элементов управления

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

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

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

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

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

Проверяйте с неудобным контентом и реальными задачами

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

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

Проверяйте масштаб браузера наряду с узкими ширинами устройств. Пользователь компьютера, увеличивающий содержимое, может получить такой же ограниченный макет по другой причине. Убедитесь, что текст остаётся читаемым, элементы управления — доступными, а закреплённые области не закрывают бо́льшую часть полезного пространства.

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