Красивая таблица: Как можно правильно и красиво оформить таблицу

Дизайн таблиц для чайников / Хабр

Привет, Хабр!

Меня зовут Костя, и я отвечаю за дизайн в AGIMA. Недавно, рассказывая коллеге, как надо было оформить таблицу, я словил дежавю: делал я это явно не первый раз. Поэтому я решил написать эту совсем базовую статью о том, как делать приличные таблицы, чтобы у меня всегда было куда послать следующего спрашивающего. Статья будет полезна как начинающим дизайнерам, так и просто жаждущим приподнять уровень своих документов чуть выше плинтуса. А в конце ссылки, которые помогут вам достичь табличного совершенства.

Таблица — это эргономика

Типичная таблица состоит из:

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

Видите? Дизайнеры приложения уже немного о нас позаботились =)

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

Ячейки, линии, серое, белое… много визуального шума. Зато выглядит привычно

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

Ничего лишнего: чистые данные!

Может показаться, что стало хуже. Вам не показалось! Но это временно. Сейчас все поправим парой надежных приемов. Но сначала:

Используйте моноширинный шрифт для цифр

«Моноширинный» значит, что у символов одинаковая ширина.

Посмотрите на картинку: слева кажется, что параметр А имеет меньшее значение, чем параметр Б. Но по факту он в ~100 раз больше. Просто ширина цифр разная и, если не считать разряды, создается ложное впечатление.

Внимательно выбирайте шрифт для цифр. Лучше использовать в таблицах моноширинные шрифты. Например, Courrier, который есть на любом компьютере (кажется). Или любой шрифт, в названии которого есть mono — например, бесплатный PT Mono от Paratype.

У таких шрифтов часто есть еще бонус: вы не перепутаете букву О и цифру 0, потому что в таких шрифтах ноль перечеркнут.

Можно, в принципе, использовать и шрифт типа Arial — у него ширина цифр хоть и не одинаковая, но разница между 1 и 0 всё же не такая кардинальная. (Но будьте бдительны всё равно.)

Числа выравниваем вправо

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

Текст выравниваем влево

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

Строки нужны

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

• линии;

• чересполосица.

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

Я предпочитаю линии: они менее «назойливые», но иногда чересполосица выглядит лучше чисто эстетически.

Что бы вы ни выбрали, важно подобрать такой цвет и яркость, чтобы они не мешали воспринимать данные, не «шумели». Но были достаточно заметны, чтобы помогать глазу бежать по строке:

Не растягивайте таблицу

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

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

Я обычно уменьшаю размер на 3–4 пункта и делаю его капсом.

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

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

Можно объединить несколько столбцов под одной шапкой. Или как-то еще включить креатив — не в ущерб информативности, конечно.

Never stop learning

Если вы вошли во вкус и хотите достичь табличного совершенства (а таблица, которая у нас тут получилась, пока далека от совершенства), то вот вам информация, где прокачаться:

На фундаметнальном курсе от Игоря Штанга. И не останавливайтесь на таблицах, Игорь давно ведет полезный блог. Там есть и про таблицы: раз два.

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

Илья Бирман в своем блоге периодически делает классные заметки.

А ещё, в нашем телеграм-канале AGIMA.design пробегала ссылка на перевод книги Эдварда Тафти Envisioning Information. Эта книга, которую должен прочитать каждый, кто имеет дело с данными. Один из читателей канала оставил альтернативную ссылку (но я ее не проверял). Это не совсем про таблицы, зато про совершенство.

Дизайн таблиц для постоянного использования

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

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

«Если бы у меня был час на решение проблемы, я бы потратил 55 минут на размышления о ней и 5 минут на поиск решения». Неизвестный

Это так заманчиво: сразу схватиться за бумагу, Sketch или Axure и начать дизайнить. В сферах, где скорость выполнения задач в приоритете, легко нырнуть в проект без подготовки. Исследования и стратегия выглядят, скорей, как барьеры для скорости выполнения заказа. Но что, если на самом деле они помогают ускорить продакшн?

Мы — Гавана и Ада, дизайнер взаимодействия и визуальный дизайнер соответственно в CareerBuilder. Наш руководитель по визуальному дизайну, Марк Паттерсон, поручил разработать шаблон стандартного табличного интерфейса, который можно использовать в нескольких продуктовых линейках с различными вариантами применения и целевыми пользователями. Наш подход заключался в том, чтобы перейти к сути задачи и проблемы сразу, на раннем этапе. Прогонять наши идеи через bullshit тесты заранее. Держать друг друга в курсе о прогрессе проекта. Мы смогли создать эффективное дизайнерское решение, быстро получить одобрение команды и проверить решение на пользовательском тестировании.

С таблицами сложно

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

Таблицы разных линеек продуктов компании

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

Наш Visual Design Lead делегировал команде отдельные элементы пользовательского интерфейса. Надо признать, что когда нам достались таблицы, мы насторожились. Это был паттерн, который использовался почти в каждом продукте. Что еще сложнее, продукты CareerBuilder обслуживали несколько типов пользователей: соискателей работы, рекрутеров и отдел кадров. Каждый продукт кардинально отличается в зависимости от сценариев использования, целей пользователя и функционала. Как можно создать что-то достаточно гибкое для всех этих целей?

В довершение всего, мы обе находились в разных городах, поэтому все сотрудничество было удаленным.

Начало

Как только нам доверили таблицы, мы организовали быструю часовую видеоконференцию. Мы поставили себе задачу отступить на шаг назад, чтобы увидеть общую картину:

1. Что пользователь вообще пытается сделать в таблице? На коллективном созвоне мы рассмотрели несколько примеров из patterns.com и попытались экстраполировать цели и задачи таблицы. В итоге мы пришли к выводу, что у пользователя при работе с таблицами 3 цели:

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

Примеры таблиц

2. Каковы главные вызовы дизайна таблиц?

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

3. Можем ли мы разбить таблицу на более мелкие части? Мы разделили ее на следующие составляющие:

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

Мы разделили компоненты между собой.

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

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

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

Также это с самого начала обеспечило поддержку команды.

Заметки и наброски таблиц

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

Для этого мы использовали Sketch и внутреннюю библиотеку стилей, которую загрузили с помощью Craft.

Наш процесс (Ада)

Компоненты таблицы

Если вы сами рисуете таблицу, смотрите, что мы сделали со всеми компонентами (здесь использованы несуществующие данные, чтобы сохранить UI независимым от контента):

Нумерация страниц

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

Нумерация

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

Поведение нумерации во время перехода пользователя по разным страницам

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

Разрабатывая что-то для использования во многих продуктах, вы должны быть гибкими.

Разные варианты отображения для нумерации страниц (Марк Паттерсон)

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

Режимы редактирования

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

Открытые текстовые поля для редактирования

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

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

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

Иконки редактирования — по умолчанию серые

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

Когда пользователь нажимает на карандаш, текстовое поле ввода появляется рядом с зеленой галочкой и красным «x». На наших тестовых сессиях пользователи легко поняли, как изменить содержимое ячейки, как только нажали на карандаш. Оказывается, такое упрощение дает результаты!

Мы беспокоились о размещении действия «Редактировать» вне столбца «Действие», поэтому протестировали это решение. 7/10 пользователей сразу же нажали на значок карандаша, несмотря на то, что выпадающий список с действиями был прямо перед их глазами. Впоследствии пользователи предложили сделать карандаш синим по умолчанию, поскольку некоторые из них не заметили его сразу.

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

Финальный вид «режима редактирования»

Внешний вид кнопок призывов к действию

Как упоминалось выше, вид call to action кнопок (CTA) менялся больше всего во всех прототипах. Иногда CTA находились в верхней части внутри таблицы, иногда вверху в виде кнопки, иногда в ячейках таблицы в виде кнопок или иконок, иногда в выпадающем меню — они были разбросаны повсюду.

Поскольку одна из целей при использовании таблицы — быстро выполнить определенное действие, мы знали, что нельзя заставить пользователей просматривать всю таблицу в поисках этого действия. Все нужно собрать в одном месте. Мы также задумались: будут ли CTA текстовыми ссылками в конце строки? Или вверху таблицы? Нужны ли им иконки? Что, если существует более 4 действий? Как сохранить полезное пространство для остальных столбцов? Мы взяли за правило размещать все действия в конце строки:

Таблица с одним действием в строке: отображается иконкой и подписью

Таблица с 2 действиями в строке: отображается как текстовая ссылка

Таблица с более, чем 2 действиями в строке: отображается в виде выпадающего меню.

Мы отобразили максимум 2 действия, чтобы предоставить пользователю оперативный доступ к ним. Но поскольку три действия занимают достаточно много места в таблице, мы помещаем их в выпадающий список. В течение нескольких раундов итераций мы обсуждали, использовать или не использовать иконки с подписями. Поскольку мы не знаем всех возможных вариантов использования таблицы в будущем, то решили, что иконки могут заставить дизайнера искать примеры для изображения довольно сложных действий, как, например, «[example. ]»

Режим редактирования

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

И, конечно, как насчет применения действий к нескольким строкам? Это был бы настоящий геморрой щелкать на столбец действия, а затем на него же еще в нескольких строках. Мы позаимствовали паттерн у Gmail, где при выборе хотя бы одной строки, сверху появляется панель «Применить к нескольким объектам». Внешний вид панели в Gmail был слишком неприметным, поэтому мы кардинально изменили цвет, чтобы привлечь внимание пользователя.

Применения действия к нескольким объектами

Настройка таблицы

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

Настройка таблицы

Ограничение ячейки

При ограниченном пространстве в некоторых из этих ячеек неизбежно возникают проблемы с длиной содержимого. Разрешаем ли мы перенос текста в ячейке? Первоначально нас вдохновил этот шот Вирджила Пана на Dribbble:

Сетка данных дизайнера Вирджина Пала (оригинальный шот на Dribbble)

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

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

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

Ограниченная ячейка таблицы и всплывающая подсказка

Использование изображений и иконок

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

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

Два варианта дизайна «предупреждений» в таблице (Рейчел Дудзяк)

Визуальные индикаторы для просмотренных и непросмотренных объектов

Мы занялись изучением цветных точек и вертикальных полос для обозначения непрочитанных объектов. Точка удачно вписалась в таблицу. Чтобы сделать ее более заметной, мы также выделили текст в строке точки. Затем наши коллеги задали еще один вопрос: как насчет флажков? Точка будет находиться рядом с первой ячейкой (с флажком) или второй (с текстом)?

Первое решение для «непросмотренных» объектов

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

Состояние «непрочитанного» объекта

Расширенный просмотр

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

Пример шаблона расширенного просмотра с Patternfly

Расширенная строка — серая. Она существенно отличается от остальных строк. Связанный контент находится в ограниченном прямоугольнике.

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

Расширенная таблица (Kosten Kos)

Мы решили применить оба варианта в дизайне нашей таблицы. Мы выделили расширенную строку синим цветом и добавили объединяющую полоску слева.

Первая и вторая итерации расширенной строки

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

Третья итерация расширенной строки: более жирная полоска

Сначала я решила увеличить ширину полоски, а также изменить ее цвет. Более жирная полоска выглядела неуместно, а темно-синий цвет все еще слишком напоминал состояние непрочитанного объекта. Мы показали наше решение команде, и коллеги предложили решение получше: сделайте ширину полоски такой же, как и в непрочитанном состоянии, но измените цвет на серый.

Четвертая итерация расширенной строки: серая полоска

Визуальные стандарты

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

Оформление отступов и полей (Ada)

Презентация и тестирование таблицы

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

Несмотря на положительный фидбек от нашей команды, мы хотели подтвердить наши предположения: так же это принципиально важно для пользователя извне, как и для нас? Будет ли пользователь знать о доступе к кнопкам действий из выпадающего списка? Запутывает ли пользователей исключение для действия «Редактировать»? Была ли понятна нумерация страниц? Мы объединились с исследователями пользовательского поведения, Кьяни Спеарманом и Майклом Пейтом, чтобы провести базовые тесты юзабилити через UserTesting.

com. Исследователи помогли нам разработать тест, который направит пользователя на выполнение 3 действий:

1. Попросите пользователя произвести некоторые действия над элементом.
2. Спросите пользователя, сколько элементов находится в списке и на какой странице они находятся.
3. Попросите пользователя отредактировать чей-то адрес электронной почты.

10 видео с UserTesting.com пришли к нам в течении 2 часов после публикации.

Результаты пользовательских тестов

Об обнаружении кнопок действий в выпадающем списке:

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

«Я знал о столбце действий [и предположил], что там будет находиться любое другое действие».

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

Главные выводы

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

1. Встречайтесь с коллегами на ранней стадии процесса и прописывайте план захвата. Делайте шаг назад, чтобы спросить себя «Почему?»
2. Вкладывайте больше времени на определение проблемы, чем на поиск решения.
3. Избавьтесь от плохих идей быстро. Покажите людям свои идеи на ранней стадии и проанализируйте ответную реакцию, критику, проблемы и т. д. Сразу предлагайте несколько вариантов, чтобы не тратить время на решения, которые не будут работать.
4. Разделите проект на небольшие, более выполнимые части и регулярно их обсуждайте. Разделите между участниками прорабатываемые компоненты, а затем сверьте результаты.
5. Не вмешивайте сюда эго! Поскольку мы заранее определили наши цели и задачи, то сразу на них и сосредоточились, отбросив эмоциональные привязанности к решениям. Это упростило принятие и внедрение замечаний.

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

Мега-благодарность Ариэлю Кейсону за столь тщательный обзор и редакцию этой статьи! Также благодарим Рине Андрееву и Тима Уорда.

С оригиналом статьи можно ознакомиться по ссылке.

Перевод — Катя Павлевич.

Projector Creative&Tech Online Institute

Beautifultable · PyPI

Введение

Этот пакет предоставляет класс BeautifulTable для простой печати табличные данные в визуально привлекательном формате на терминал.

Включенные функции, но не ограничивающиеся ими:

• Полная настройка внешнего вида стола

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

• Полная поддержка цветов , используя последовательности ANSI или любую вашу библиотеку. выбор. Это просто работает.

• Множество предопределенных стилей для различных вариантов использования и возможность создавать собственные.

• Поддержка символов Unicode .

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

Ссылки

• Документация

• Источник

• Справочник по API

Применение

Вот пример использования Beautifultable:

 >>> из импорта BeautifulTable BeautifulTable
>>> таблица = BeautifulTable()
>>> table.rows.append(["Иаков", 1, "мальчик"])
>>> table. rows.append(["Изабелла", 1, "девушка"])
>>> table.rows.append(["Итан", 2, "мальчик"])
>>> table.rows.append(["София", 2, "девушка"])
>>> table.rows.append(["Майкл", 3, "мальчик"])
>>> table.rows.header = ["S1", "S2", "S3", "S4", "S5"]
>>> table.columns.header = ["имя", "ранг", "пол"]
>>> распечатать(таблица)
+----+----------+------+--------+
| | имя | ранг | пол |
+----+----------+------+--------+
| С1 | Джейкоб | 1 | мальчик |
+----+----------+------+--------+
| С2 | Изабелла | 1 | девушка |
+----+----------+------+--------+
| С3 | Итан | 2 | мальчик |
+----+----------+------+--------+
| С4 | София | 2 | девушка |
+----+----------+------+--------+
| С5 | Майкл | 3 | мальчик |
+----+----------+------+--------+ 

Вы можете узнать больше о Beautifultable в этом уроке

Установка

 python3 -m pip установить красивую таблицу 

Список изменений

Разработка

v1.1.0

• Отказ от поддержки Python 3.4, 3.5 и 3.6

• Добавить официальную поддержку Python 3. 9 и 3.10

• Добавлен метод asdict и aslist для объекта строки. (Спасибо @Agent-Hellboy)

• Добавлены методы from_csv и to_csv для экспорта/импорта CSV-файла. (Спасибо @Agent-Hellboy)

• Добавлены методы from_df и to_df для экспорта/импорта фрейма данных. (Спасибо @Agent-Hellboy)

v1.0.1

v1.0.0

• В класс BeautifulTable добавлены две новые строки и столбцы представлений. Большинство существующих методы устарели. Методы вида {}_row и {}_column перемещены в просматривает строки.{} и столбцы.{}«(например, «append_row теперь является rows.append). Вызов старшего устаревшие методы теперь вызывают FutureWarning. Специальные методы, такие как __len__, __iter__, и т. д. также были перемещены в соответствующие представления. Для получения подробной информации см. Документация по API и обновленное руководство

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

• Добавлена ​​поддержка заголовков строк. В результате доступ к строкам теперь можно получить по их ключам, аналогичным к колоннам

• Добавлены два новых метода to_csv и from_csv для прямого экспорта/импорта в CSV-файл. (Спасибо @dinko-pehar)

• Добавлен метод BeautifulTable.rows.filter для создания новой таблицы только с определенными строками

• Добавлен новый атрибут формы в класс BeautifulTable, который возвращает кортеж формы (nrow, ncol)

• Добавлен новый атрибут BeautifulTable.columns.header.alignment, который можно использовать для отдельное выравнивание заголовка. Поведение по умолчанию — наследовать BeautifulTable.columns.alignment

• Метод BeautifulTable.rows.sort (ранее BeautifulTable.sort) обновлен. также принимать любые вызываемые объекты в качестве ключа.

• Обновлено поведение BeautifulTable.column.width (ранее BeautifulTable.column_widths). Он больше не переопределяет заданную пользователем ширину по умолчанию. Вы можете сбросить его по умолчанию установив его на «авто»

• Устаревшие атрибуты serialno и serialno_header. Теперь пользователь может легко реализовать эта функциональность с помощью заголовков строк, если требуется

• Устаревшие методы get_table_width(), copy() и get_string().

• Устаревшие аргументы конструктора и атрибуты класса с именами sign_mode, numeric_precision, max_width и переименованы в sign, precision и maxwidth соответственно

• Исправлена ​​ошибка, из-за которой таблица была искажена, если модуль благословений использовался для создания цветных строк.

• Исправлены проблемы с существующей реализацией __iter__, __copy__ и __deepcopy__, которые теперь должно работать надежнее.

• Исправлена ​​ошибка, из-за которой для заполнения по умолчанию нельзя было установить значение 0. (Спасибо @furlongm)

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

• Прекращена поддержка Python 2

v0.8.0

• Прекращена поддержка Python 3.3

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

• Выравнивание, отступы, ширина теперь могут быть установлены для всех столбцов с использованием упрощенного синтаксиса, такого как table.column_alignments = красивая таблица.ALIGN_LEFT

v0.7.0

• Добавлено 4 новых стиля, STYLE_BOX , STYLE_BOX_DOUBLED , STYLE_BOX_ROUNDED , STYLE_GRID .

• Переименован STYLE_RESTRUCTURED_TEXT в STYLE_RST

• wcwidth теперь является дополнительной зависимостью

• Обновлен алгоритм расчета ширины столбцов (лучшее разделение пространства между столбцами)

• Добавлена ​​поддержка абзацев (с использованием символа \n)

• Добавлен более точный контроль символов пересечения с использованием 12 новых атрибуты intersect_{top|header|row|bottom}_{left|mid|right}

• Добавлена ​​возможность также принимать строки байтов вместо юникода

• Устаревший атрибут cross_char

• Устаревшие методы get_top_border(), get_bottom_border(), get_header_separator(), get_row_separator(), auto_calculate_width()

• Исправлена ​​проблема с WEP_ELLIPSIS и WEP_STRIP при использовании многобайтовых символов

• Исправлена ​​ошибка, из-за которой таблица не отображалась в надлежащей форме, если ширина столбца была слишком мала

v0.

6.0

• Добавлена ​​поддержка обработки многобайтовых строк

• Добавлена ​​поддержка цветных строк с использованием управляющих последовательностей ANSI

• Добавлено ограничение, при котором все строки должны быть в Юникоде

• Исправлена ​​ошибка, из-за которой ширина иногда рассчитывалась больше, чем предполагалось

v0.5.3

v0.5.2

v0.5.1

v0.5.0

• Добавлено новое свойство serialno_header

• Устаревшие методы с ошибкой в ​​названии «разделитель» .

• Исправлена ​​ошибка, из-за которой таблица была повреждена, когда столбец_количества был слишком большим

v0.4.0

• Добавлены предопределенные стили для упрощения настройки

• Добавлен обратный аргумент в метод sort()

• Исправлена ​​зависимость enum34 для версий Python до 3. 4

v0.3.0

• Добавлено свойство serialno для автоматической печати серийного номера

• Исправлена ​​проблема с sign_mode, связанная с преобразованием str

• Исправлены ошибки, связанные с версией Python до 3.3

• Исправлено исключение для WEP_ELLIPSIS и длины токена менее 3

• Исправлены проблемы с печатью с пустой таблицей

v0.2.0

v0.1.3

• Исправлены мелкие проблемы

v0.1.2

• Добавлено новое свойство default_padding

• Добавлен новый метод update_row

• Исправлена ​​ошибка в auto_calculate_width()

v0.1.1

Пожертвовать

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

Лицензия

Этот проект находится под лицензией MIT License — подробности см.