В этой статье речь пойдет о видах представления данных. Некоторые из них вам уже знакомы по используемым продуктам, некоторые будут в новинку.
Зная, какие бывают виды организации данных в интерфейсе, при проектировании или заказе информационной системы вы сможете с уверенностью сказать: “Хочу, чтобы это показывалось вот так”. Когда мы проектируем интерфейс, то предлагаем разные варианты и часто заказчик удивляется : а что, можно и так сделать? Бывает и обратное — хочу именно так, как нарисовано у меня на листочке, я к этому привык. Был такой случай. Сделали прямо как на листочке, пользователю стало удобно и он остался доволен. Бывает и другой вариант, когда заказчик затрудняется определиться, как он хочет и все варианты считает неудобными. Тогда необходимо особо внимательно отнестись к прототипам, чтобы “неудобно” не всплыло уже после презентации готовой системы.
Карточка с данными
Кажется, что это — самый простой интерфейс. На самом деле, зависит от карточки и от данных. Карточка может быть двух видов, в виде окна или в виде страницы. При использовании разных систем вы, скорее всего, замечали, что если редактируете список статусов или создаете новый тег для сделки, в общем, редактируете запись, содержащую одно или несколько полей, то для редактирования вам не открывается целая страница с одним или двумя полями. Для этого, как правило, используются всплывающие окна.
Если данных много, например, редактирование информации о проекте или о контрагенте, где куча всего, полные названия, неполные названия, названия внутри компании, ИНН, ОГРН, адрес фактический, адрес юридический — то используется полноценная страница с большим количеством полей. Для редактирования большого количества данных окна недостаточно, это будет неудобно и некрасиво.
Также страницы используются, если есть поля для ввода полноценного текста (например, в системах администрирования сайтов).
Составные страницы
Бывает, что на странице редактируется не только одна сущность, например контрагент, но и происходит отображение или управление разного рода данными. Такая организация карточки используется для удобства. Например, сделки или заказы на работы. Достаточно неудобно при создании сделки сначала идти в контрагенты, чтобы создать нового, а потом возвращаться в сделку и искать контрагента, чтобы его туда добавить. Также, когда на странице проекта нужно видеть выполняемые по проекту задачи, статус проекта, основанный на включенных в проект данных. На такие страницы иногда выводится история действий, если это необходимо для пользователя, а также блок комментариев.
Подобные компоновки встречаются во всем известных CRM-системах, например AMOCRM — интерфейс сделки. На нем можно и добавить организацию, и новые контакты, и комментировать, а также поставить задачу.
При проектировании такого интерфейса необходимо четко понимать, какие данные нужны пользователю для эффективной работы, чтобы не выполнять лишних действий. Для того, чтобы получать всю информацию для выполнения бизнес-функции в одном месте.
Например, интерфейс для контроля состояния этапа проекта. Все данные на картинке придуманы дизайнером при проектировании интерфейса.
Списки
Как и карточки, это вторая нога того, что всем знакомо и есть в любой системе. То есть, перед тем, как редактировать какую-то карточку, надо сначала на нее кликнуть в списке, чтобы открыть. Именно это представление предшествует карточкам. Списки — стандартный вид, может быть в двух вариантах. Непосредственно список и таблица в виде списка.
Список содержит столбцы (столбец может быть одним, если редактируется только название). Управление списком происходит через применение фильтров. Фильтры, как правило, располагаются над листингом, но фильтры, это отдельная история.
Списки имеют сортировку по столбцам. Как правило, в простых системах этого нет, но в наших мы делаем управление столбцами. Ненужные столбцы можно отключать. Каждый пользователь может настроить их под себя. Для удобства. 
Списки могут содержать элементы группового выбора для групповых операций. Это такие галочки в левой части перед каждой записью, которые позволяют отметить сразу несколько строк, а потом нажать одну кнопку “Утвердить” или “Готово”. Все эти вещи, наличие группового выбора или действия проектируются и продумываются с точки зрения минимизации кликов для выполнения.
Фильтры
Важным фактором работы с фильтрами, кроме скорости выбора нужного элемента фильтрации является занимаемый ими размер. Мы подсмотрели хорошую практику в разных системах и используем вариант, когда сначала выбирается то, что фильтруем, потом по какому значению. Получается даже три клика, сначала на добавить фильтр, потом выбираем по какому признаку, потом значение. Казалось бы, что эти три клика и дольше, чем просто на фильтр и значение, но для ускорения добавляется еще строка универсального поиска, которая ищет по тексту тех значений, по которым нужно искать.
Строка быстрого поиска накладывает ограничения по скорости работы с базой данных, но если такие нагрузки предвидятся, то используются специальные технологии, такие как проксирование значений, если таблица включает сборные данные с разных таблиц или технические решения для ускорения полнотекстового поиска по базе данных.
Канбан
Данное представление можно использовать не только для воронки продаж, как многие подумали. Использование такого решения хорошо применено, например, в Trello. При разработке индивидуальных систем такой подход позволяет достаточно удобно работать со статусами любых вещей, операций, производственных задач, проектов.
Это подходит для небольшого количества данных, которые представляются в виде карточек.
Как правило, в индивидуальных системах у карточки чего-либо, кроме статуса есть еще несколько классификаторов. Например, можно организовать несколько досок Канбан по разным признакам, в зависимости от того, кто работает с сущностью. А также по группам статусов, если движение карточки не параллельное, а прямое.
Например, документ. Для руководителя он может быть в статусах на утверждение, утвержден, на подписание, подписан. Для юриста — новый, на составлении, на утверждение, на подписание, подписан. Для менеджера — новый, на составлении (все статусы юриста), на подписании (включающий все статусы руководителя), подписан. Далее логика такая, менеджер составляет карточку документа в столбце новый, перемещает в статус на составлении. У юриста документ появляется на доске в столбце новый. Когда юрист готов его взять в работу, перемещает в статус на составление. Когда документ составлен, добавляет его в карточку и перемещает в столбец на подписание. Документ появляется у руководителя в столбце на утверждение, у остальных карточка сама перемещается туда, куда нужно. Ну и так далее.
Классически Канбан применяется для простановки статусов, но может применяться и для просто визуального разделения. Например, программисты могут использовать доску Канбан в системе для классификации по типам задач. Этот способ позволяет быстро распределить задачи по типам, а также наглядно продемонстрировать, какой блок работ опаздывает.
Пример работы в Канбан со статусами. Все данные на картинке придуманы дизайнером при проектировании интерфейса.
Часто Канбан используется в CRM-системах и системах ведения задач для быстрого переноса задачи на другую дату. Это распространенное и удобное использование. В индивидуальных системах, естественно, на сколько дней переносить и прочие нюансы проектируются и настраиваются. Все данные на картинке придуманы дизайнером при проектировании интерфейса.
В индивидуальных системах совсем необязательно делать распределение по столбцам по одному критерию, это может быть набор критериев, либо часть столбцов для одного критерия, часть для другого, а также отдельная визуальная зона для отдельных параметров. Например, опять к программистам. Есть статусы — новая задача, в работе, на проверке, готова. Но здесь требуется внимание менеджера, либо требуется оценка задачи. Это отдельные параметры, не влияющие на статус. На доске может быть сделана специальная область, куда попадают задачи, не меняя при этом статус. Но тут добавляется параметр, при этом в системе происходит какое-то действие, например отправляется уведомление менеджеру или руководителю.
Гантт
Это всем известное представление, расписывать его особо нечего, потому что ничего нового тут не написать. Как правило, используется для визуализации связанности задач и ведения проекта.
Индивидуальные представления
Существуют узкоспециализированные или совсем индивидуальные виды интерфейсов. Например, это может быть схема столов в ресторане с возможностью переносить заказы со стола на стол, либо другие области на экране, между которыми можно перемещать заказы. Классическим примером узкого распространения является шахматка, используемая в информационных системах застройщиков. На ней показываются стояки и этажи, а в ячейках данные по квартирам.
Как говорилось в начале статьи, бывает так, что заказчик имеет своё представление, как необходимо показывать данные. При разработке индивидуальных систем можно реализовать практически любое представление, которое можно придумать.