Дизайн таблиц

https://uxdesign.cc/design-better-data-tables-4ecc99d23356
  • Перевод
Данные бесполезны без возможности визуализировать их и взаимодействовать с ними. Многие из отраслей будущего зачастую требуют более продвинутого сбора больших данных и улучшенных интерфейсов взаимодействия с таблицами.

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

Фиксированные заголовки


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

image

 

Горизонтальная прокрутка


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

image
 

Ширина столбцов


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

image
 

Вид строки


Уменьшение визуального шума в виде границы строк помогает при небольшом количестве данных в таблице. Если данных достаточно много, лучше отображать границы или использовать «зебру».

image
 

Плотность отображения данных


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

image
 

Визуальная сводка таблицы


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

image
 

Разбиение на страницы


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

image
 

Действия при наведении


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

image
 

Редактирование в строке


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

image
 

Расширяемые строки


Позволяют пользователю оценивать дополнительную информацию без потери контекста.

image
 

Быстрый просмотр


Как и расширяемые строки, позволяет просматривать дополнительную информацию, оставаясь в контексте.

image
 

Модальные окна


Такой просмотр позволяет сохранить первоначальный вид таблицы.

image
 

Мультимодальные окна


Мультимодальная функция является мощным средством для активного использования пользователями множества действий или сравнения деталей разрозненных элементов.

image
 

Подробный просмотр


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

image
 

Сортировка


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

image
 

Общие фильтры


Позволяют отображать только необходимые данные в таблице.

image
 

Фильтры колонок


Возможность фильтровать данные в колонке.

image
 

Поиск в колонках


Позволяет быстро совершать поиск непосредственно в заголовке столбца.

image
 

Добавление колонок


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

image
 

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


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

image
 

Почему таблицы важны


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

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

Обновление: опубликовал практические примеры реализации некоторых паттернов для табличных данных: Таблицы в адаптивном дизайне — 2.
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 74
  • +6
    Немало важен ещё и экспорт данных таблицы, хотя бы в csv, xml или json.
    • +2

      Возможно, я что-то не понимаю, но где способы?

      • 0
        Вот да.
        2/3 этого я использую в экселе, но про часть функционала — например модальные окна или предпросмотр в правой части окна — реализовать можно на сайтах или в приложениях, а это сложно передавать по электронке, да редактировать некомфортно.
        • –3
          Если кто знает как это делать в экселе-поделитесь, плз
          • –1
            В экселе есть поддержка VB скриптов, можно сделать практически что угодно. Есть даже стандартные средства http://www.dummies.com/software/microsoft-office/excel/how-to-add-records-to-a-data-list-in-excel-2016/
            • 0
              Очень желательно иметь почти в каждом отделе (экономисты, финансисты, инженеры, логисты, тпродажники и т.п.), как минимум одного человека, умеющего писать на VB. Самый трудным вопросом у меня было, это доказать кадровикам и своему руководству необходимость такого «непрофильного» (по их очень принципиальному, надо, сказать, мнению!) специалиста. Благодаря ему, весь Департамент стал ворочать таким объёмом информации, который ранее был просто не под силу. Теперь он ключевой и самый труднозаменимый сотрудник (это не очень хорошо, но на данном этапе развития подразделения и бизнеса, по другому — никак).
              • 0
                Скажем прямо: умение минимально автоматизировать свою работу — это признак просто продвинутого/опытного пользователя. Не важно, это дизайнер в фотошопе экшены делает, или офис менеджер бланки по шаблону из списка сотрудников заполняет.
          • 0
            Свеий Oracle APEX
            • 0
              А насколько удобно им пользоваться?
        • +6

          Таблицы имеют серьёзные проблемы с адаптивностью. Когда экран большой и все колонки влезают — ещё ладно, но чем меньше экран и больше колонок, тем неудобнее пользоваться таблицей. Мотать её туда-сюда — то ещё удовольствие. Всякие прилипающие шапки и возможность ручного изменения ширины колонок — костыли для решения этой проблемы. Кроме того, на iOS есть проблема с совмещением scroll-over и virtual-scroll — всё начинает прыгать, когда появляется оба скролла. Поэтому мы отказались от таблиц в пользу карточек. Например. На большом экране карточки вытягиваются в строчки, образуя таблицу. На маленьком, данные одной позиции переносятся, позволяя на одном экране обозреть всё. Но благодаря выравниванию и цветокодированию, глазами можно быстро перепрыгивать по одному и тому же свойству разных позиций. В примере, у каждого свойства есть лейбл, но в принципе можно сделать и плавающую карточку с лейблами, если колонок не слишком много.

          • +1
            пример по линку требует залогиниться
            • +9
              Пустой логин и пароль проходит.
            • +1
              С карточками не всегда можно удобно и понятно отобразить большую таблицу и что бы это сделать приходиться придумывать креативные ux решения. Таблица + мобайл версия более надёждый способ отображения данных.

              Интересная идея с файловым инпутом.
              • 0

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

                • +1
                  Решение: сохраняемые локально у пользователя профили настроек фильтров «под себя». Лучше, если в таблице имеется возможность навигации (в рамках фильтра) по группам вверх/вниз (открыть/скрыть конкретную группу). Пользователь также часто заинтересован регулярно видеть бОльшую локальную детализацию «по яблокам», но не «по грушам» в ситуации, когда доступный общий фильтр только «фрукты».
              • +3
                очень классно сделано
                • –1
                  А кто говорит что нужно делать table. Ведь все можно собрать и на div.
                  • +1

                    Да хоть на canvas, суть от этого не меняется :-)

                  • 0
                    Кроме того, на iOS есть проблема с совмещением scroll-over и virtual-scroll — всё начинает прыгать, когда появляется оба скролла.

                    Попробуйте добавить это правило в css
                    -webkit-overflow-scrolling: touch; 
                    
                    • 0

                      Без этого никак :-) Там в другом проблема — когда появляется скролловер, например, сбоку, а ты мотаешь вниз и по скроллу менешь дом, то скролловер на мгновение сбрасывается до нуля.

                    • +1

                      Не всегда нужно думать о мобилках, удобный/продуманные десктоп иногда полезнее адаптивности – например админка магазина/агенства.

                      • 0

                        А почему вы их противопоставляете? Можно сделать и удобно, и продуманно, и адаптивно.

                        • +3

                          Потому что это разные устройства, и иногда да — можно. Но не всегда, особенно когда информации много (таблицы же), в этом случае лучше выбрать десктоп (которым в случае админки будут пользоваться в 99% случаев) и потратить деньги/силы/время на его проработку, отбросив все другие платформы.

                          • –3

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

                            • +4
                              В вашем примере адаптивность далась ценой ухудшения юзабилити на больших экранах. Видимо не всё так просто…
                              • 0
                                Решение: не выводить на большие и малые экраны одинаковый уровень детализации одной и той же информации. Как вариант: полностью функциональную «мобильную версию» выводить оверлеем поверх высокодетализированной таблицы на большом экране. Первое нужно, чтобы «обсуждать одинаковые данные на одном языке», второе — более удобно для анализа и внесения изменений.
                                • 0
                                  Детализацией должна быть возможность удобно управлять скрывая/показывая нужные поля — это должно решить проблему в более общем виде и с меньшими жертвами в плане юзабилити.
                                  • +1
                                    Само собой. Я не отменял максимальную юзабилити и для больших таблиц. Просто мы пришли к простому выводу, что на малых экранах лучше только смотреть и обсуждать данные. А в больших таблицах — удобнее работать с данными.
                      • 0
                        Очень интересный пример. Возьмем «таблицу» Positions. На широком экране оно выглядит как таблица, но с повторяющимся заголовком в каждом ряду. Смотрится неплохо, но несколько громоздко. На узких экранах каждая «строка» «таблицы» складывается как бы в 2-3 ряда (бутербродом), но, поскольку, заголовки всё равно повторяются в каждой строке — всё равно выглядит неплохо. Мне кажется, было бы идеально, если бы в случае, когда нет необходимости складывать строки в бутерброды — убирать повторяющиеся заголовки. Тогда получится по сути обычная таблица, и не будет излишних повторений заголовков и потери места, улучшится обзор данных, глазом получится охватить в 2-3 раза больше позиций.
                        В общем ваш пример лучше таблиц на малых и средних экранах, но проигрывает им по всем параметрам (хотя и не катастрофически) на широких экранах, когда нет потребности в бутербродах. Должен отметить, что в целом идея бутербродизируемой таблицы мне нравится, только не хватает компактной небутербродной версии.
                        • +1

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


                          image

                          • 0
                            Да, неплохо, но всё же не так удобно/непривычно.
                            • 0

                              С горизонтальным скроллингом ещё не удобнее, а к хорошему привыкаешь быстро ;-)

                              • 0
                                не спорю, но лучшим вариантом считаю адаптивный, когда заголовок отделён и плавающий в широком формате, и интегрирован в бутерброд в узком.
                                • +1
                                  типа такого, только формат «карточек» у них, на мой взгляд, хуже вашего т.к. на средних экранах появляется куча пустоты, а на мелких две колонки всё равно не влазят.
                        • +1
                          Мы нашли два выхода:
                          1. Ставить мониторы с бОльшим разрешением. Это насущная необходимость для анализа данных и работы (изменения данных) с ними.
                          2. Объяснять, что на смартфонах/планшетах и т.п. «таблицы смотреть не стоит». Для этого давно придуманы удобные дашборды. Полноту и корректность данных на «низких разрешениях» лучше отслеживать через KPI, подтянутых напрямую из БД с исходниками (ни в коем случае, не из уже сформированных «кем-то» таблиц!). Тогда лучше понятно «с какой степенью доверия» стоит относиться к высокоуровневым показателям дашей.
                          • +1
                            Вот да, а то прям какой-то тренд «впихните нивпихуемое». Вроде бы итак должно быть понятно, что для анализа больших таблиц нужен соответствующий инструмент (монитор) и экран телефона для этого мало подходит.
                            Небоскребы ведь не строят в песочницах.
                        • 0
                          Ещё интересно было бы взглянуть на Ваше видение сортировки по нескольким полям, а также группировки по нескольким полям…
                          • 0
                            это же перевод
                            • 0
                              Обязательно стоит сделать минимум одну иерархическую группировку (для «стандартизованных» отчётов) и обеспечить возможность составлять пользовательские фасетные (по удобным пользователю атрибутам и признакам). Иерархическую группировку нужно обязательно составлять с пользователем (ещё лучше с ключевым или с руководителем — тоже ключевым, если их несколько). Без «фасетных возможностей» все будут пытаться засунуть свои «хотелки» в общую иерархическую иерархию. В этом случае, вы её никогда не составите или согласуете.
                            • 0
                              имхо, в фильтрах иногда не помешают логические операторы с группировкой (A=foo and (B=bar or C=baz)). вопрос только как удобный интерфейс для этого выглядит?
                              • 0
                                Мне больше всего досаждают слишком широкие таблицы, каждый раз мучаюсь как их правильно предоставить, может есть какие-то креативные советы? )
                                • +4
                                  Писал об этом пост с примерами решения несколько лет назад: Таблицы с данными в адаптивном дизайне . Если эта тема интересна, могу написать о новых решениях.
                                  • 0
                                    Спасибо, ссылка была очень полезной, если на эту тему есть что-то действительное новое, я бы с удовольствием почитал )
                                    • +2
                                      Да, напишите. Ждем продолжения и развития темы.
                                      • +1
                                        Тема актуальная, напишите, пожалуйста.

                                        "В табличках данные выступают рельефнее и компактнее." Была написана у нас на методичке по математической статистике цитата Ильича.
                                • –9
                                  какой сильный концентрат информации! это конспект урока?
                                  • –1
                                    Типовой американский формат подачи обучающей информации. Им своим не нужно объяснять и подробно разжёвывать «зачем это мне?».
                                  • +2

                                    Очень хочется готовый фреймворк для таких таблиц. Смотрел на Yii, твм есть ActiveGrid, но там не всё… Может, есть что-то ещё, заточенное конкретно под таблицы?

                                    • 0
                                      Я использую datatable со своими модификациями.
                                      • +1

                                        У вас чекбоксы слева. Хорошо бы упомянуть про возможность работы с ними с клавиатуры:
                                        Shift+Click — выбор диапазона
                                        Tab — переход на следующий (тут надо подумать, как быть с режимом редактирования строки)
                                        Ну и ясное дело — клик по чекбоксу в заголовке выделяет все на странице (или наоборот, снимает выделение).


                                        Статья полезная, оформлено красиво. Примеры реализации бы еще, желательно со ссылками на opensource-решения (ну и не только opensource)

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

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

                                            Следует добавить, что техники по работе с таблицами на столько круты и информативны, что я не знаю в каком виде вы собираетесь предоставить сводку, например по 100 объектам в самом сжатом виде, чтобы человек не терял Фокус и максимально быстро мог сложить А и Б. Пользователю надо анализировать данные, а вы предлагаете отчеты.

                                            • –1
                                              Вы подменяете понятия: никто не отрицает важность данных.

                                              Ситуация с ними примерно как в старом анекдоте:
                                              Вносит учительница к класс большой компьютер, ставит на стол:
                                              — Дети сколько компьютеров на столе?
                                              — Один.
                                              Вносит второй:
                                              — Дети, а теперь?
                                              — Два!
                                              Вытирая пот со лба:
                                              — Всё-таки с яблоками как-то проще было!

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

                                              С умным видом листать табличку с красиво всплывающими заголовками и т.п. — это как раз хипстерская тема ;-)

                                              В итоге чтобы просто посмотреть максимум, мы тупо сортируем всю таблицу. Чтобы оценить распределение — тыкаем примерно в середину полосы прокрутки. В основном этот подход обусловлен низкой квалификацией пользователя, но во многом это и просто единственный вариант предусмотренный разработчиком.
                                              • 0
                                                Похоже, меня минусуют в соседних постах ровно за такую же, как и у вас, идеологию. :)
                                                Всё верно вами сказано. Но недопонимание у вашего спорщика возникло из-за терминологии в предыдущем посте. Вы под таблицами понимали «выборку из мёртвых цифр, над которыми разработчик позволяет провести ряд предусмотренных им же математических манипуляций». Но те же таблицы Excel позволяют сделать много больше не омертвляя цифры, а оставляя все формулы и ссылки. Другими словами, Excel умеет сохранять «модель расчёта» любых финальных показателей, что очень сильно облегчает анализ и поиск проблем. Плюс, с моделью можно «поиграться», самому за 5 минут в соседней от таблице ячейке добавив пользовательский KPI (например, если я надумал с месяц лично поконтролировать объём продаж избранных продуктов в одном из наших магазинов).
                                                Похоже, разработчики не задумываются над тем, что мы перед тем, как сделать выборку, сначала проверяем, насколько данным «можно верить».
                                              • 0
                                                Вы с коллегой спорите о «разных ракурсах одного и того же». ;)
                                                Я ответил чуть выше на его сообщение.
                                            • +3
                                              Мы в своих проектах (корпоративный софт) вынуждены применять почти все способы из статьи.
                                              С большими таблицами иначе никак, падает производительность пользователя. А на упрощение данных или таблицы клиенты редко соглашаются.
                                              • –1
                                                Классификация и структуризация данных позволяет создавать очень удобные иерархии групп для детализации данных. По иерархии очень быстра и удобна навигация и от общего к частному и от частного к общему в пределах и таблицы и дэшборда. Нет необходимости подгружать всю высоко детальную матрицу данных. Всё равно вся она пользователю не нужна. Он анализирует всегда очень ограниченное число переменных и значений.
                                                • +1
                                                  Это всё теория.
                                                  Дома, ради интереса, можно делать красивые прогрессивные таблицы.

                                                  Но в профессиональной деятельности для клиента важна только эффективность их использования.
                                                  К примеру, как можно скорее вбить лид, а потом как можно быстрее его найти и обработать.
                                                  Т.е. все релевантные данные должны быть на виду, а не на расстоянии одного или более кликов.
                                                  Наиболее критичная часть этих данных должна редактироваться в строке, а не после её открытия в другом элементе (модальное окно).

                                                  Я к тому, что в реальных проектах, не мы решаем какие данные нам представлять в таблице.
                                                  Мы решаем как нам наиболее удобно для пользователя предоставить определённый им набор данных.
                                                  • –1
                                                    К вашему сведению, я эту теорию довёл до вполне конкретного и эффективного результата в одной из Российский нефтяных компаний. Пользуются — только в путь. Обратно не хотят.
                                                    Цитата: «а не на расстоянии одного или более кликов». Я не советовал отказаться от загрузки всей таблицы целиком. Я просто указал, что при наличии иерархии можно делать это на выбор пользователя: целиком таблицу грузить или только её локальную часть, через настроенный под себя фильтр на свой периметр данных. При правильной организации работы, когда каждый отвечает за свой участок данных, редко возникает необходимость пользователю обращаться к рандомным местам таблицы, что приходится загружать её всю целиком (особенно, если таблица огромна), не зная «куда тебя в ней дальше занесёт».

                                                    И я не про модальные окна. А про то, как в том же Excel скрываются/открываются группы. Это те же элементы той же таблицы. просто настраивается, что видно, а что скрыто. В скрытых данные можно не подгружать. Когда делается запрос на сравнительную выборку по многим отчётным периодам (бухгалтерия очень любит такие), то ради сравнения 10 цифр, подтягивать сразу все их 10 миллионов со всех таблиц — по меньшей мере, глупо.

                                                    Цитата: «не мы решаем какие данные нам представлять в таблице». Правильно. Решает Заказчик. Вот только сегодня ему одно нужно, а завтра уже другое. Поэтому мы у себя решили и сделали не готовые отчёты «по шаблону Заказчика» (потому что это мы же и были), а поняв суть проблемы — создали в Excel на базе сводных таблиц конструктор отчётов и объяснили, как им пользоваться (в определённых пределах). После этого, многочисленные вопросы к нашему подразделению о подготовке в том или ином виде разных отчётов и трата времени на долгие запросы/ответы по ним, отпали в принципе.
                                              • +1

                                                Кстати, по поводу фиксированных шапок и колонок. Недавно для прилажения на ионике понадобилось сделать и фиксированную шапку и фиксированную первую колонку. Спасло свойство position: sticky, которое пока не поддерживается IE, зато поддерживается остальными браузерами. Для того чтоб фиксированная колонка заработала в мобильном сафари, понадобилось добавить префикс position: -webkit-sticky. Без него пока никак.

                                                • +1

                                                  Примечание: в FIrefox position: sticky не работает для thead (или tr в thead) в таблице. В хроме всё работает.

                                                  • –6
                                                    Как представитель бизнеса (а не как специалист по ИТ) и потенциальный Заказчик для любого из вас, огорчу в части создания вами таблиц в чём-то менее функциональном, чем MS Excel. «Мёртвые» табличные данные (голые цифры), как во многих html форматах, без возможности произвести тут же рядом хотя бы простейшие математические действия типа «ячейка А + ячейка Б», нас не интересуют. Иначе, как не зря кто-то выше уже заметил «это прямолинейный неэффективный способ работы с данными», ибо остаётся на них только «тупо пялиться, делая умное лицо». К сожалению, это правда. Всегда видно, те, кто занят именно анализом — те всегда производят над данными вычисления. Остальные — лишь делают вид.
                                                    • –6
                                                      Нам (в первую очередь, руководителям) всегда интересно видеть историю «проблемной» цифры в отчёте, следуя по ссылке до формулы, как она была посчитана и далее. Иначе, большинство вопросов о подобных данных «умирает» прямо на совещании, ибо «хороша ложка к обеду». А потом (по результатам выданного поручения «разобраться») и актуальность уже много ниже, да и способов корректно «заиграть» вопрос, если начальник правильно «копнул больное место» — тоже вполне предостаточно.
                                                      • 0
                                                        поменьше чсв, друг :)
                                                        • –1
                                                          А его тут и нет. Читайте всё написанное, как есть. Вы же не знаете и не учитываете, где и с какими трудностями нам довелось реализовывать наш проект (в роли Заказчика и наполовину Подрядчика, одновременно). Всё вышеописанное, очень имеет место быть на практике и с этим надо считаться. Если же вам повезло пока с таким не встречаться — радуйтесь.
                                                  • –2
                                                    Все это есть в w2ui, jqgrid, jqgridphp,ag-Grid
                                                    Прямые руки и мозги — и можно сделать все что угодно.
                                                    • +1
                                                      А в какой программе можно рисовать такие симпатичные таблички? Хочу в хэлпе для своего проекта обезличенные и при этом анимационные примеры взаимодействия с интерфейсом сделать, и то, что в статье, — идеальный вариант.

                                                      Спасибо.
                                                    • –1
                                                      Вам стоит рассмотреть еще несколько кейсов с проблемой большого количества данных в рамках одного из столбцов таблицы, чаще всего такого избегаю просто обрезкой строки и добавлением в конце троеточия.
                                                      Но я на практике не раз сталкивался с требованиями отображать полный текст в столбце и в итоге таблица начинает выглядеть совершенно не так как на дизайне.
                                                      • +2

                                                        Для тех, кто обрезает контент ради "красивости" есть отдельный круг в аду :-)


                                                        Ожидание:


                                                        1. Регламент разработки.pdf
                                                        2. Регламент тестирования.pdf
                                                        3. Регламент внедрения.pdf

                                                        Реальность:


                                                        1. Протокол заседания от 10.05.2017 о ра...
                                                        2. Протокол заседания от 10.05.2017 о те...
                                                        3. Протокол заседания от 10.05.2017 о вн...
                                                        • 0
                                                          Вот потому, самому разработчику обрезать ничего и не нужно. И спрашивать Заказчика «надо или нет?» тоже. Вводится ограничение на длину записи в столбце и делается переключатель видов: «полный текст» или «многоточие». И эта фича просто доводится до сведения Заказчика, как данность. Захочет вводить текст длиной 999 символов в столбец, который даже один в экран не влезет — пусть сам задумывается, а надо ли ему «это» и пусть свыкается смотреть через многоточие. Если хватит терпения и дара убеждения — обговаривать это при написании ТЗ.
                                                      • 0
                                                        Еще одна проблема это выравнивание.

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