Как спроектировать сложную веб-таблицу

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

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

1. Систематизируйте потребности

Итак, вы опросили целевую аудиторию и выяснили ее потребности и желания. Теперь пришло время собрать воедино выводы и преобразовать их в структуру интерфейса. Например, один пользователь сказал: «Мне нужно посмотреть, как мои данные влияют на другие части приложения». Или, наблюдая, как другой человек работает со старым программным обеспечением, вы заметили, что он использует ярлыки и вообще не трогает мышь. Что это значит?

Первые слова пользователя касаются проверки ввода и подсказок. Вам нужно подумать о том, чтобы прикрепить к таблице предупреждение или справочную информацию. Или разработайте систему значимых цветов. Это зависит от предметной области и ментальной модели. Наблюдение за работой второго пользователя может быть признаком того, что вам нужно сделать все действия доступными с клавиатуры. И вам, вероятно, придется подумать о более глубоких сочетаниях клавиш, чем просто « Cmd + C » и « Cmd + V ».

Вот несколько пар наблюдения-предположения.

• « Мне нужно легко управлять десятками предметов одновременно ».
  Разрешить множественный выбор ячеек? Добавить флажки, чтобы выбрать много строк?
• « Теперь мы делаем все расчеты таким образом ». [ Показывает Microsoft Excel ]
  Эффективен ли Excel для этой цели? Какие функции мы можем позаимствовать?
• « Можем ли мы как-то заранее узнать, есть ли это имя уже на сервере ».
  Проверка данных на лету? Сообщения об ошибках или автокоррекция?
• « Обычно я ввожу эту информацию. Это довольно общее. ”
  Предложите значения по умолчанию, значения по умолчанию или шаблоны?
  

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

«Что помогает вам работать быстрее? Что может облегчить ваш выбор? Как эта функция влияет на эффективность вашей работы? Что изменится, если вы не сможете сделать Х?»

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

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

Дерево функций избавляет от лишней работы и помогает сосредоточиться на главном. Хорошо организованное дерево функций также полезно для команды разработчиков. Они могут сопоставить запланированные функции с доступными внешними библиотеками и найти лучший способ превратить проекты в код.

В одном из моих проектов мы использовали фреймворк Angular Material. К сожалению, таблицы Angular были слишком простыми. Мы нашли библиотеку ag-Grid, которая поддерживала нашу функциональность, но имела одно ограничение. У него не было возможности расширить строку и поместить дочерние строки внутрь. Мы выявили эту проблему до того, как приложили к ней какие-либо усилия и скорректировали дизайн.

В двух словах

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

Рекомендуемая литература : Шаблоны проектирования таблиц в Интернете Чен Хуэй Цзин

2. Станьте атомарным

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

Шрифты, цвета, иконки

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

Клетки и аксессуары

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

В одном из моих проектов у нас было восемь типов ячеек с собственным взаимодействием. Самыми простыми являются текстовые и числовые ячейки. В нашем случае было разрешено заполнять числовые ячейки нечисловым содержимым, таким как «N/A» (не применяется) и «N/C» (без контроля). Это была особенность домена. Выпадающие списки и средства выбора даты более сложны и имеют дочерние элементы. Наконец, у нас были ячейки таблицы, которые представляли внутристрочные команды.

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

Строки и заголовки

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

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

На следующем изображении вы можете видеть, что люди могут выбирать одну или несколько строк:

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

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

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

В моем примере есть три типа блоков фильтров. Алфавитно-цифровой фильтр позволяет осуществлять поиск по буквам и цифрам. Он поддерживает подстановочные знаки — неизвестное количество неизвестных символов. Например, если я наберу 45*A1 , это может привести к отображению строк с такими значениями, как 45A1 , 45982A1B , 45A109B и 096445-A1 .

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

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

Еще одна важная вещь — автоматически форматировать любой значимый ввод и не беспокоить людей ошибками «недопустимого формата». На одном из моих проектов мы разрешили вводить такие даты, как 01/25/2017 , 6.12.17 и September 4 2016 , а также фильтровать только по месяцу или году.

Столбцы

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

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

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

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

Верхняя панель

Что представляет собой таблица? Ячейки, столбцы, строки. Кроме того, сложные таблицы часто имеют верхнюю панель. Как и остальные компоненты, верхняя панель состоит из более мелких элементов — заголовка и команд.

Ниже я собрал список команд со всем разнообразием состояний, которые мы использовали в одном из продуктов. У нас были команды-значки для очевидных метафор, таких как plus = add / create , trash bin = remove , arrow = move . Неуниверсальные команды (например, назначить, архивировать, сбалансировать) требовали явного текстового именования. Более того, некоторые команды сопровождались выпадающим меню.

Теперь мы можем попробовать объединить разные элементы и посмотреть, работает ли это. Вот несколько примеров.

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

• Сортировка более чем по одному столбцу;
• Настраиваемый набор столбцов (возможность их переключения);
• Расширяемые строки (родительская строка может иметь дочерние строки);
• Логические операторы фильтрации и поиска («и», «или», «иначе» и т. д.).

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

Весь стол

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

Таблица только для чтения

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

Таблица поиска

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

Редактируемая таблица

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

В двух словах

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

Рекомендуемое чтение : Дизайн-системы Аллы Холматовой

3. Определите взаимодействие

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

Числовые данные

Сколько знаков после запятой должно быть в вашей таблице? Раз, два, пять? Каков оптимальный уровень точности? Я решаю, основываясь на точности, необходимой пользователям для принятия правильного решения. В некоторых профессиях колебание между 10932.01 и 10932.23 имеет значение, тогда как в других областях цифры 14 и 15 не имеют большого значения.

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

• Длина
  Два десятичных знака (57,53 м, 3,16 км); пространства используются как разделители тысяч (403 456,56 м).
• Масса
  Два десятичных знака (225,08 кг, 108,75 т); пространства используются как разделители тысяч (12 032,17 кг).
• Деньги
  Два десятичных знака (9,45 долларов США); запятые используются как разделители тысяч (16 408 989,00 долларов США).
• Диаметр
  Три десятичных знака (10,375 см); не нужны разделители.
• Широта и долгота
  Восемь десятичных знаков (26,4321121); знак минус, используемый для западной долготы и южной долготы (-78,05640132).
• По умолчанию
  Для единиц, не указанных выше, — два десятичных знака (32,05 г/м³, 86,13 °С).

Еще одна вещь, которую мы рассмотрели, — это разница между «истинными» данными, сохраненными на серверах, и «приблизительными» данными в интерфейсе. Система использовала чрезвычайно точные числа с десятками знаков после запятой во всех расчетах, но людям не нужно было видеть ее постоянно. Поэтому мы решили показывать количество десятичных знаков, описанное выше, и выставлять полное число только тогда, когда ячейка таблицы активна. Например, инженер мог ввести 134432.97662301 , и как только он нажал Enter , таблица показала 134 432.98 . Щелкнув еще раз, инженер снова увидит 134432.97662301 .

Проверка ввода

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

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

• Должно быть больше единицы measurement unit number . Optional explanation .
• Должно быть меньше единицы measurement unit number . Optional explanation .
• Должен быть между number 1 и number 2 measurement unit . Optional explanation .
• Минимальное значение должно быть меньше максимального значения.
• Максимальное значение должно быть больше минимального значения.
• Минимальное и максимальное значения не должны совпадать.

Команды

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

Итак, у нас есть таблица с некоторыми химическими веществами. В нем есть такие команды, как «Добавить строку», «Переместить вверх», «Переместить вниз», «Удалить», «Пересчитать» и «Настройки».

А вот и описание состояний команд. Оказывается, их доступность зависит от одного или нескольких условий.

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

Контейнер и отзывчивость

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

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

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

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

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

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

Доступность

Даже исключительно гладкий и красивый стол может стать кошмаром для пользователей. Поэтому так важно следовать принципам доступности. В Руководстве по обеспечению доступности веб-контента (WCAG 2.0) есть глава о таблицах. Большая часть материала посвящена правильному кодированию; впрочем, дизайнеру тоже есть над чем подумать.

Вот основные соображения дизайна с точки зрения доступности.

• Дайте название и подготовьте краткое изложение.
  Пользователь с ослабленным зрением должен иметь возможность получить представление о таблице без голосовой обработки всех ее ячеек.
• Обратите внимание на размер шрифта.
  Хотя официального минимального размера для Интернета не существует, оптимальным считается 16 пикселей (12 пунктов). Кроме того, пользователь должен иметь возможность увеличить его до 200%, не нарушая при этом всего макета.
• Тестовые цвета для людей с цветовой слепотой.
  Текст и элементы управления должны иметь достаточный контраст с фоном. Соотношение цветов 3:1 минимально необходимо (чем больше, тем лучше). Кроме того, цвет не должен быть единственным способом маркировки вещей. Например, сообщения об ошибках не должны основываться только на красном тексте, значок предупреждения даст дополнительные подсказки пользователям с цветовой слепотой.
• Избегайте маленьких и неоднозначных элементов управления.
  Кликабельные компоненты считаются сенсорными, если они имеют размер не менее 40×40 пикселей. Команды, представленные значками, должны быть либо помечены, либо иметь всплывающие подсказки и альтернативный текст. Дизайнеры не должны злоупотреблять иконками, потому что пользователи могут неправильно понять сложные метафоры.

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

В двух словах

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

Заключение

Мы только что рассмотрели процесс построения сложной таблицы. Разные проекты требуют разных подходов, но есть один универсальный принцип. Дизайнер должен заставить все элементы работать вместе в любой комбинации. Вот почему хорошо начинать со сбора потребностей и создания небольших блоков. И, конечно же, тестирование с пользователями, как только у вас появится что-то кликабельное и реалистичное.

Дальнейшее чтение

• «Атомный дизайн», Брэд Фрост
• «Создавайте лучшие таблицы данных», Эндрю Койл
• «Рефакторинг пользовательского интерфейса», Адам Ватан и Стив Шогер.