Правильные таблицы позволяют пользователям анализировать, сравнивать, фильтровать, сортировать и управлять содержащейся информацией. В этой статье описаны способы, с помощью которых можно упростить вид и структуру таблицы данных.
Фиксированные заголовки
Такие заголовки помогают ориентироваться при прокрутке длинной таблицы данных.
Горизонтальная прокрутка
Горизонтальный скролл неизбежен в таблицах с большим количеством столбцов. В таких случаях первую колонку можно сделать фиксированной. Кроме того, можно дать возможно так же фиксировать нужные пользователю колонки.
Ширина столбцов
Изменение ширины столбцов поможет полностью отображать ячейки с большим количеством данных.
Вид строки
Уменьшение визуального шума в виде границы строк помогает при небольшом количестве данных в таблице. Если данных достаточно много, лучше отображать границы или использовать «зебру».
Плотность отображения данных
Увеличенная плотность в таблице помогает отобразить больше данных без необходимости прокрутки, однако могут возникнуть проблемы восприятия пользователем. Поэтому можно дать возможность управления плотностью данных в таблице.
Визуальная сводка таблицы
Сводка визуальных данных дает обзор таблицы. Это позволяет пользователю определять закономерности и проблемы в целом, прежде чем приступить к обобщению итогов.
Разбиение на страницы
Помогает разделить больше таблицы на страницы. Иногда, особенно десктоп-версиях сайтов, целесообразно добавить бесконечную прокрутку.
Действия при наведении
Представление дополнительных действий при наведении, снижая визуальный беспорядок.
Тем не менее, это может вызвать проблемы, поскольку пользователю необходимо взаимодействовать с таблицей.
Редактирование в строке
Позволяет изменять данные без необходимости переходить на отдельную страницу.
Расширяемые строки
Позволяют пользователю оценивать дополнительную информацию без потери контекста.
Быстрый просмотр
Как и расширяемые строки, позволяет просматривать дополнительную информацию, оставаясь в контексте.
Модальные окна
Такой просмотр позволяет сохранить первоначальный вид таблицы.
Мультимодальные окна
Мультимодальная функция является мощным средством для активного использования пользователями множества действий или сравнения деталей разрозненных элементов.
Подробный просмотр
Клик по ссылке строки преобразует таблицу в список слева и дополнительные данные справа.
Позволяет пользователю анализировать большие наборы данных, а также ссылаться на многие элементы, не теряя при этом контекста.
Сортировка
Популярная функция, позволяющая нужным образом организовать данные в таблице.
Общие фильтры
Позволяют отображать только необходимые данные в таблице.
Фильтры колонок
Возможность фильтровать данные в колонке.
Поиск в колонках
Позволяет быстро совершать поиск непосредственно в заголовке столбца.
Добавление колонок
Позволяет пользователям добавлять столбцы из набора. Этот способ ограничивает данные таблицы только необходимой информацией.
Настраиваемые колонки
Позволяет пользователям выбирать столбцы, которые они хотят видеть, и сортировать их соответствующим образом. Функция может включать в себя возможность сохранения пресетов для последующего использования.
Почему таблицы важны
Данные не имеют смысла без возможности их визуализировать и взаимодействовать с ними. Поэтому компаниям следующего десятилетия просто необходимо уметь оперировать с данными.
Энергетика, СМИ, производство, логистика, здравоохранение, торговля, финансы и даже правительство претерпевают изменения. Данные становятся основным сырьем мировой экономики, что ведет к переосмыслению устаревших отраслей.
Обновление: опубликовал практические примеры реализации некоторых паттернов для табличных данных: Таблицы в адаптивном дизайне — 2.
Комментарии (74)
SirEdvin
08.05.2017 21:53+2Возможно, я что-то не понимаю, но где способы?
Ghool
09.05.2017 09:56Вот да.
2/3 этого я использую в экселе, но про часть функционала — например модальные окна или предпросмотр в правой части окна — реализовать можно на сайтах или в приложениях, а это сложно передавать по электронке, да редактировать некомфортно.Ghool
09.05.2017 09:56-3Если кто знает как это делать в экселе-поделитесь, плз
vlakarados
09.05.2017 11:10-1В экселе есть поддержка VB скриптов, можно сделать практически что угодно. Есть даже стандартные средства http://www.dummies.com/software/microsoft-office/excel/how-to-add-records-to-a-data-list-in-excel-2016/
AlexTOPMAN
09.05.2017 13:25Очень желательно иметь почти в каждом отделе (экономисты, финансисты, инженеры, логисты, тпродажники и т.п.), как минимум одного человека, умеющего писать на VB. Самый трудным вопросом у меня было, это доказать кадровикам и своему руководству необходимость такого «непрофильного» (по их очень принципиальному, надо, сказать, мнению!) специалиста. Благодаря ему, весь Департамент стал ворочать таким объёмом информации, который ранее был просто не под силу. Теперь он ключевой и самый труднозаменимый сотрудник (это не очень хорошо, но на данном этапе развития подразделения и бизнеса, по другому — никак).
Busla
10.05.2017 16:00Скажем прямо: умение минимально автоматизировать свою работу — это признак просто продвинутого/опытного пользователя. Не важно, это дизайнер в фотошопе экшены делает, или офис менеджер бланки по шаблону из списка сотрудников заполняет.
vintage
08.05.2017 22:57+6Таблицы имеют серьёзные проблемы с адаптивностью. Когда экран большой и все колонки влезают — ещё ладно, но чем меньше экран и больше колонок, тем неудобнее пользоваться таблицей. Мотать её туда-сюда — то ещё удовольствие. Всякие прилипающие шапки и возможность ручного изменения ширины колонок — костыли для решения этой проблемы. Кроме того, на iOS есть проблема с совмещением scroll-over и virtual-scroll — всё начинает прыгать, когда появляется оба скролла. Поэтому мы отказались от таблиц в пользу карточек. Например. На большом экране карточки вытягиваются в строчки, образуя таблицу. На маленьком, данные одной позиции переносятся, позволяя на одном экране обозреть всё. Но благодаря выравниванию и цветокодированию, глазами можно быстро перепрыгивать по одному и тому же свойству разных позиций. В примере, у каждого свойства есть лейбл, но в принципе можно сделать и плавающую карточку с лейблами, если колонок не слишком много.
G_tost
08.05.2017 23:31+1С карточками не всегда можно удобно и понятно отобразить большую таблицу и что бы это сделать приходиться придумывать креативные ux решения. Таблица + мобайл версия более надёждый способ отображения данных.
Интересная идея с файловым инпутом.vintage
08.05.2017 23:46Насчёт больших таблиц — это опять же, плохо. Пользователя же как правило интересуют далеко не все колонки. Поэтому имеет смысл смотреть в сторону удобного выбора колонок. Например, это может быть выбор сценария работы или показываем только общие для всех сценариев и добавляем кнопки вида "добавить такие-то колонки".
AlexTOPMAN
09.05.2017 13:36+1Решение: сохраняемые локально у пользователя профили настроек фильтров «под себя». Лучше, если в таблице имеется возможность навигации (в рамках фильтра) по группам вверх/вниз (открыть/скрыть конкретную группу). Пользователь также часто заинтересован регулярно видеть бОльшую локальную детализацию «по яблокам», но не «по грушам» в ситуации, когда доступный общий фильтр только «фрукты».
noodles
09.05.2017 00:43Кроме того, на iOS есть проблема с совмещением scroll-over и virtual-scroll — всё начинает прыгать, когда появляется оба скролла.
Попробуйте добавить это правило в css-webkit-overflow-scrolling: touch;vintage
09.05.2017 09:49Без этого никак :-) Там в другом проблема — когда появляется скролловер, например, сбоку, а ты мотаешь вниз и по скроллу менешь дом, то скролловер на мгновение сбрасывается до нуля.
Elfet
09.05.2017 07:46+1Не всегда нужно думать о мобилках, удобный/продуманные десктоп иногда полезнее адаптивности – например админка магазина/агенства.
vintage
09.05.2017 09:53А почему вы их противопоставляете? Можно сделать и удобно, и продуманно, и адаптивно.
Elfet
09.05.2017 10:01+3Потому что это разные устройства, и иногда да — можно. Но не всегда, особенно когда информации много (таблицы же), в этом случае лучше выбрать десктоп (которым в случае админки будут пользоваться в 99% случаев) и потратить деньги/силы/время на его проработку, отбросив все другие платформы.
vintage
09.05.2017 10:07-3Вы так говорите, будто адаптивность достигается неимоверными усилиями. Однако это не так. В отличие от "отдельной мобильной версии".
DaylightIsBurning
09.05.2017 11:20+4В вашем примере адаптивность далась ценой ухудшения юзабилити на больших экранах. Видимо не всё так просто…
AlexTOPMAN
09.05.2017 13:41Решение: не выводить на большие и малые экраны одинаковый уровень детализации одной и той же информации. Как вариант: полностью функциональную «мобильную версию» выводить оверлеем поверх высокодетализированной таблицы на большом экране. Первое нужно, чтобы «обсуждать одинаковые данные на одном языке», второе — более удобно для анализа и внесения изменений.
DaylightIsBurning
09.05.2017 13:59Детализацией должна быть возможность удобно управлять скрывая/показывая нужные поля — это должно решить проблему в более общем виде и с меньшими жертвами в плане юзабилити.
AlexTOPMAN
09.05.2017 17:24+1Само собой. Я не отменял максимальную юзабилити и для больших таблиц. Просто мы пришли к простому выводу, что на малых экранах лучше только смотреть и обсуждать данные. А в больших таблицах — удобнее работать с данными.
DaylightIsBurning
09.05.2017 11:19Очень интересный пример. Возьмем «таблицу» Positions. На широком экране оно выглядит как таблица, но с повторяющимся заголовком в каждом ряду. Смотрится неплохо, но несколько громоздко. На узких экранах каждая «строка» «таблицы» складывается как бы в 2-3 ряда (бутербродом), но, поскольку, заголовки всё равно повторяются в каждой строке — всё равно выглядит неплохо. Мне кажется, было бы идеально, если бы в случае, когда нет необходимости складывать строки в бутерброды — убирать повторяющиеся заголовки. Тогда получится по сути обычная таблица, и не будет излишних повторений заголовков и потери места, улучшится обзор данных, глазом получится охватить в 2-3 раза больше позиций.
В общем ваш пример лучше таблиц на малых и средних экранах, но проигрывает им по всем параметрам (хотя и не катастрофически) на широких экранах, когда нет потребности в бутербродах. Должен отметить, что в целом идея бутербродизируемой таблицы мне нравится, только не хватает компактной небутербродной версии.vintage
09.05.2017 12:08+1На маленьких экранах тоже можно сделать плавающую шапку и леблы в шапке будут переноситься синхронно с данными в карточках, что позволит их быстро сопоставлять.
DaylightIsBurning
09.05.2017 12:14Да, неплохо, но всё же не так удобно/непривычно.
vintage
09.05.2017 12:25С горизонтальным скроллингом ещё не удобнее, а к хорошему привыкаешь быстро ;-)
DaylightIsBurning
09.05.2017 12:50не спорю, но лучшим вариантом считаю адаптивный, когда заголовок отделён и плавающий в широком формате, и интегрирован в бутерброд в узком.
DaylightIsBurning
09.05.2017 13:21+1типа такого, только формат «карточек» у них, на мой взгляд, хуже вашего т.к. на средних экранах появляется куча пустоты, а на мелких две колонки всё равно не влазят.
AlexTOPMAN
09.05.2017 13:30+1Мы нашли два выхода:
1. Ставить мониторы с бОльшим разрешением. Это насущная необходимость для анализа данных и работы (изменения данных) с ними.
2. Объяснять, что на смартфонах/планшетах и т.п. «таблицы смотреть не стоит». Для этого давно придуманы удобные дашборды. Полноту и корректность данных на «низких разрешениях» лучше отслеживать через KPI, подтянутых напрямую из БД с исходниками (ни в коем случае, не из уже сформированных «кем-то» таблиц!). Тогда лучше понятно «с какой степенью доверия» стоит относиться к высокоуровневым показателям дашей.
Xtray
10.05.2017 10:04+1Вот да, а то прям какой-то тренд «впихните нивпихуемое». Вроде бы итак должно быть понятно, что для анализа больших таблиц нужен соответствующий инструмент (монитор) и экран телефона для этого мало подходит.
Небоскребы ведь не строят в песочницах.
semmaxim
08.05.2017 23:08Ещё интересно было бы взглянуть на Ваше видение сортировки по нескольким полям, а также группировки по нескольким полям…
AlexTOPMAN
09.05.2017 13:57Обязательно стоит сделать минимум одну иерархическую группировку (для «стандартизованных» отчётов) и обеспечить возможность составлять пользовательские фасетные (по удобным пользователю атрибутам и признакам). Иерархическую группировку нужно обязательно составлять с пользователем (ещё лучше с ключевым или с руководителем — тоже ключевым, если их несколько). Без «фасетных возможностей» все будут пытаться засунуть свои «хотелки» в общую иерархическую иерархию. В этом случае, вы её никогда не составите или согласуете.
cl0ne
08.05.2017 23:13имхо, в фильтрах иногда не помешают логические операторы с группировкой (A=foo and (B=bar or C=baz)). вопрос только как удобный интерфейс для этого выглядит?
Dimash2
08.05.2017 23:32Мне больше всего досаждают слишком широкие таблицы, каждый раз мучаюсь как их правильно предоставить, может есть какие-то креативные советы? )
grokru
08.05.2017 23:33+4Писал об этом пост с примерами решения несколько лет назад: Таблицы с данными в адаптивном дизайне . Если эта тема интересна, могу написать о новых решениях.
Dimash2
09.05.2017 01:44Спасибо, ссылка была очень полезной, если на эту тему есть что-то действительное новое, я бы с удовольствием почитал )
tov_jukov
09.05.2017 02:13+2Да, напишите. Ждем продолжения и развития темы.
AslanKurbanov
09.05.2017 12:43+1Тема актуальная, напишите, пожалуйста.
"В табличках данные выступают рельефнее и компактнее." Была написана у нас на методичке по математической статистике цитата Ильича.
SbWereWolf
08.05.2017 23:41-9какой сильный концентрат информации! это конспект урока?
AlexTOPMAN
09.05.2017 17:48-1Типовой американский формат подачи обучающей информации. Им своим не нужно объяснять и подробно разжёвывать «зачем это мне?».
iproger
09.05.2017 02:13Мне кажется, примером хороших таблиц могут быть таблицы из Magento 2. https://www.google.com/search?q=magento+2+admin&newwindow=1&client=safari&hl=ru-us&prmd=ivn&source=lnms&tbm=isch&sa=X&ved=0ahUKEwi65YyRqeHTAhVhzoMKHWxGDroQ_AUICSgB&biw=1024&bih=672#imgrc=SgnPSYFofiN7CM:
crocodile2u
09.05.2017 10:05+1У вас чекбоксы слева. Хорошо бы упомянуть про возможность работы с ними с клавиатуры:
Shift+Click — выбор диапазона
Tab — переход на следующий (тут надо подумать, как быть с режимом редактирования строки)
Ну и ясное дело — клик по чекбоксу в заголовке выделяет все на странице (или наоборот, снимает выделение).
Статья полезная, оформлено красиво. Примеры реализации бы еще, желательно со ссылками на opensource-решения (ну и не только opensource)
Busla
09.05.2017 10:43-4В подавляющем большинстве случаев большие таблицы — это прямолинейный неэффективный способ работы с данными. Признание разработчиком своего бессилия.
Заключение до смешного наивное: умение оперировать данными, это как раз не «тупо пялиться в сырые данные в табличной форме», а групповые обобщённые операции над ними.Dimash2
09.05.2017 17:15+4Ваше утверждение может быть верным разве что для «красивого обобщения» в корзине хипстерского магазина, есть программное обеспечение научное, финансовое, где сырые данные так же важны как и их результаты, и нет ничего более сжатого и связаного нежели таблица. Таблица это не только представление данных, но и инструмент для многих людей, которые не захотят использовать ваши обработанные данные в удобной и приятной форме, им нужна именно таблица.
Следует добавить, что техники по работе с таблицами на столько круты и информативны, что я не знаю в каком виде вы собираетесь предоставить сводку, например по 100 объектам в самом сжатом виде, чтобы человек не терял Фокус и максимально быстро мог сложить А и Б. Пользователю надо анализировать данные, а вы предлагаете отчеты.
Busla
10.05.2017 12:09-1Вы подменяете понятия: никто не отрицает важность данных.
Ситуация с ними примерно как в старом анекдоте:
Вносит учительница к класс большой компьютер, ставит на стол:
— Дети сколько компьютеров на столе?
— Один.
Вносит второй:
— Дети, а теперь?
— Два!
Вытирая пот со лба:
— Всё-таки с яблоками как-то проще было!
Отображение сырых данных в таблице на экране — это замена бумаги на «телевизор». Учёным и финансистам нужны не данные, а сумма, среднее, максимум, распределение, отклонение и прочие, куда более сложные обобщения и взаимосвязи. Квалифицированные операторы (типа кассиров РЖД) тоже не листают бесконечные таблицы, а запрашивают выборку по условиям.
С умным видом листать табличку с красиво всплывающими заголовками и т.п. — это как раз хипстерская тема ;-)
В итоге чтобы просто посмотреть максимум, мы тупо сортируем всю таблицу. Чтобы оценить распределение — тыкаем примерно в середину полосы прокрутки. В основном этот подход обусловлен низкой квалификацией пользователя, но во многом это и просто единственный вариант предусмотренный разработчиком.AlexTOPMAN
10.05.2017 13:49Похоже, меня минусуют в соседних постах ровно за такую же, как и у вас, идеологию. :)
Всё верно вами сказано. Но недопонимание у вашего спорщика возникло из-за терминологии в предыдущем посте. Вы под таблицами понимали «выборку из мёртвых цифр, над которыми разработчик позволяет провести ряд предусмотренных им же математических манипуляций». Но те же таблицы Excel позволяют сделать много больше не омертвляя цифры, а оставляя все формулы и ссылки. Другими словами, Excel умеет сохранять «модель расчёта» любых финальных показателей, что очень сильно облегчает анализ и поиск проблем. Плюс, с моделью можно «поиграться», самому за 5 минут в соседней от таблице ячейке добавив пользовательский KPI (например, если я надумал с месяц лично поконтролировать объём продаж избранных продуктов в одном из наших магазинов).
Похоже, разработчики не задумываются над тем, что мы перед тем, как сделать выборку, сначала проверяем, насколько данным «можно верить».
AlexTOPMAN
10.05.2017 14:01Вы с коллегой спорите о «разных ракурсах одного и того же». ;)
Я ответил чуть выше на его сообщение.
oren
09.05.2017 10:54+3Мы в своих проектах (корпоративный софт) вынуждены применять почти все способы из статьи.
С большими таблицами иначе никак, падает производительность пользователя. А на упрощение данных или таблицы клиенты редко соглашаются.AlexTOPMAN
09.05.2017 18:10-1Классификация и структуризация данных позволяет создавать очень удобные иерархии групп для детализации данных. По иерархии очень быстра и удобна навигация и от общего к частному и от частного к общему в пределах и таблицы и дэшборда. Нет необходимости подгружать всю высоко детальную матрицу данных. Всё равно вся она пользователю не нужна. Он анализирует всегда очень ограниченное число переменных и значений.
oren
09.05.2017 18:59+1Это всё теория.
Дома, ради интереса, можно делать красивые прогрессивные таблицы.
Но в профессиональной деятельности для клиента важна только эффективность их использования.
К примеру, как можно скорее вбить лид, а потом как можно быстрее его найти и обработать.
Т.е. все релевантные данные должны быть на виду, а не на расстоянии одного или более кликов.
Наиболее критичная часть этих данных должна редактироваться в строке, а не после её открытия в другом элементе (модальное окно).
Я к тому, что в реальных проектах, не мы решаем какие данные нам представлять в таблице.
Мы решаем как нам наиболее удобно для пользователя предоставить определённый им набор данных.AlexTOPMAN
09.05.2017 19:58-1К вашему сведению, я эту теорию довёл до вполне конкретного и эффективного результата в одной из Российский нефтяных компаний. Пользуются — только в путь. Обратно не хотят.
Цитата: «а не на расстоянии одного или более кликов». Я не советовал отказаться от загрузки всей таблицы целиком. Я просто указал, что при наличии иерархии можно делать это на выбор пользователя: целиком таблицу грузить или только её локальную часть, через настроенный под себя фильтр на свой периметр данных. При правильной организации работы, когда каждый отвечает за свой участок данных, редко возникает необходимость пользователю обращаться к рандомным местам таблицы, что приходится загружать её всю целиком (особенно, если таблица огромна), не зная «куда тебя в ней дальше занесёт».
И я не про модальные окна. А про то, как в том же Excel скрываются/открываются группы. Это те же элементы той же таблицы. просто настраивается, что видно, а что скрыто. В скрытых данные можно не подгружать. Когда делается запрос на сравнительную выборку по многим отчётным периодам (бухгалтерия очень любит такие), то ради сравнения 10 цифр, подтягивать сразу все их 10 миллионов со всех таблиц — по меньшей мере, глупо.
Цитата: «не мы решаем какие данные нам представлять в таблице». Правильно. Решает Заказчик. Вот только сегодня ему одно нужно, а завтра уже другое. Поэтому мы у себя решили и сделали не готовые отчёты «по шаблону Заказчика» (потому что это мы же и были), а поняв суть проблемы — создали в Excel на базе сводных таблиц конструктор отчётов и объяснили, как им пользоваться (в определённых пределах). После этого, многочисленные вопросы к нашему подразделению о подготовке в том или ином виде разных отчётов и трата времени на долгие запросы/ответы по ним, отпали в принципе.
search
09.05.2017 11:05+1Кстати, по поводу фиксированных шапок и колонок. Недавно для прилажения на ионике понадобилось сделать и фиксированную шапку и фиксированную первую колонку. Спасло свойство
position: sticky, которое пока не поддерживается IE, зато поддерживается остальными браузерами. Для того чтоб фиксированная колонка заработала в мобильном сафари, понадобилось добавить префиксposition: -webkit-sticky. Без него пока никак.
lexasss
09.05.2017 13:37+1Примечание: в FIrefox
position: stickyне работает дляthead(илиtrвthead) в таблице. В хроме всё работает.
AlexTOPMAN
09.05.2017 18:19-6Как представитель бизнеса (а не как специалист по ИТ) и потенциальный Заказчик для любого из вас, огорчу в части создания вами таблиц в чём-то менее функциональном, чем MS Excel. «Мёртвые» табличные данные (голые цифры), как во многих html форматах, без возможности произвести тут же рядом хотя бы простейшие математические действия типа «ячейка А + ячейка Б», нас не интересуют. Иначе, как не зря кто-то выше уже заметил «это прямолинейный неэффективный способ работы с данными», ибо остаётся на них только «тупо пялиться, делая умное лицо». К сожалению, это правда. Всегда видно, те, кто занят именно анализом — те всегда производят над данными вычисления. Остальные — лишь делают вид.
AlexTOPMAN
09.05.2017 19:21-6Нам (в первую очередь, руководителям) всегда интересно видеть историю «проблемной» цифры в отчёте, следуя по ссылке до формулы, как она была посчитана и далее. Иначе, большинство вопросов о подобных данных «умирает» прямо на совещании, ибо «хороша ложка к обеду». А потом (по результатам выданного поручения «разобраться») и актуальность уже много ниже, да и способов корректно «заиграть» вопрос, если начальник правильно «копнул больное место» — тоже вполне предостаточно.
Beyondtheclouds
10.05.2017 09:18поменьше чсв, друг :)
AlexTOPMAN
10.05.2017 09:48-1А его тут и нет. Читайте всё написанное, как есть. Вы же не знаете и не учитываете, где и с какими трудностями нам довелось реализовывать наш проект (в роли Заказчика и наполовину Подрядчика, одновременно). Всё вышеописанное, очень имеет место быть на практике и с этим надо считаться. Если же вам повезло пока с таким не встречаться — радуйтесь.
bagrintsev
09.05.2017 12:44-2Все это есть в w2ui, jqgrid, jqgridphp,ag-Grid
Прямые руки и мозги — и можно сделать все что угодно.
Igogo2012
10.05.2017 01:06-1Вам стоит рассмотреть еще несколько кейсов с проблемой большого количества данных в рамках одного из столбцов таблицы, чаще всего такого избегаю просто обрезкой строки и добавлением в конце троеточия.
Но я на практике не раз сталкивался с требованиями отображать полный текст в столбце и в итоге таблица начинает выглядеть совершенно не так как на дизайне.vintage
10.05.2017 10:00+2Для тех, кто обрезает контент ради "красивости" есть отдельный круг в аду :-)
Ожидание:
- Регламент разработки.pdf
- Регламент тестирования.pdf
- Регламент внедрения.pdf
Реальность:
- Протокол заседания от 10.05.2017 о ра...
- Протокол заседания от 10.05.2017 о те...
- Протокол заседания от 10.05.2017 о вн...
AlexTOPMAN
10.05.2017 13:20Вот потому, самому разработчику обрезать ничего и не нужно. И спрашивать Заказчика «надо или нет?» тоже. Вводится ограничение на длину записи в столбце и делается переключатель видов: «полный текст» или «многоточие». И эта фича просто доводится до сведения Заказчика, как данность. Захочет вводить текст длиной 999 символов в столбец, который даже один в экран не влезет — пусть сам задумывается, а надо ли ему «это» и пусть свыкается смотреть через многоточие. Если хватит терпения и дара убеждения — обговаривать это при написании ТЗ.
sofcase
Немало важен ещё и экспорт данных таблицы, хотя бы в csv, xml или json.