Когда-то давным давно угораздило меня попасть в мир учетных систем, да не просто учетных, а работающих через Web. Много воды утекло с тех пор, много систем родилось, некоторые из них уже погибли. Это очень динамичный мир. В этом мире множество систем, от брутальной, умудренной сединами 1С, до совсем молодой Acumatica. Есть гламурненькие Эльба с FinoBox, есть и крутой Мегаплан, есть мой любимый, суровый, но симпатишный Oreodor. Во всех них очень умные формы, ещё более умная (чем пользователь) навигация, ну, и таблицы! Давайте подойдем ещё ближе.
Все это Web, все это работает, все функционально, а функционала много.
Не так давно, по долгу службы, я делал обзор различных платформ и ERP систем. Моей задачей было разобраться в особенностях реализации интерфейсов, понять почему было сделано так, а не иначе. Обзор был полезен по работе, теперь я им смело тыкаю в коллег, когда те хотят что-то испортить. Не долго думая я решил адаптировать свой обзор в статью, дополнить, обрезать и поделиться с вами, уважаемые Хабровчане.
Сортировка
Как правило, она реализуется кликом по заголовку колонки, как, например, в 1C, Мегаплан или Oreodor. При этом на колонке появляется указатель на направление сортировки. Бывает опция дублируется в меню колонки, если такое есть (как в Oreodor). Впрочем в некоторых системах (например FinoBox) сортировка естественная — по датам расходов, элементов управления ею нет, и не нужно.
Кстати, большинство систем дают возможность задавать сортировку из интерфейса лишь по одной колонке единовременно. Удобное управление множественной сортировкой увы, задача нетривиальная, и никто её не осилил. Если сортировать множественно и можно, то это задается из настроек списка, как в 1С.
Навигация по списку
Три самых распространенных пути:
- Постраничный просмотр (paging). Такой путь у Acumatica и Oreodor. Главный плюс постраничного просмотра — возможность быстро перейти к нужной позиции в списке.
Все данные разбиты на страницы, известно общее количество записей, известно окно просмотра. Настолько классика, что и добавить нечего, разве что окно просмотра можно рассчитывать динамически, по размеру области отображения списка. Это позволяет избавиться от вертикального скроллинга на совсем. - Бесконечный скролл (Infinity Scroll) — это когда данные подгружаются и отображаются в процессе скроллинга. Т.е. фактически позиция начала (skip) выборки определяется текущим положением скорлла, а размер выборки (limit) — размером области отображения, вроде этого. Замечен в 1С. Штука крайне крутая, позволяет экономить трафик, разгрузить DOM браузера, и все такое. Но, увы, требует очень много усилий для хорошей реализации. И ввиду своей бесконечности порождает проблемы перехода на конкретную позицию в списке (этот недостаток компенсируется фильтрацией).
Способ хорош если данных не много (2-3 окна просмотра), или очень много, но они либо фильтруются в процессе просмотра до двух-трех окон просмотра, или каждая запись сама по себе не так важна, а важна обобщенная информация, тенденция (поток задач в багтрекере к примеру).Вообще суть этого метода в облегчении DOM за счет уменьшения одновременно отображаемых элементов на странице. В один момент времени рендерятся только записи в окне, что позволяет создать иллюзию единовременного отображения огромного объема данных за счет полосы прокрути и быстрого отклика на её перемещение.
Так же способ благодатен на кеширование, эвристику и серверную оптимизацию.
- Нативный скролл браузера — путь тех, кто не спорит с браузером. Это когда мы скролим не конкретно этот список, а целиком страницу. При этом может быть какая-то реализация Infinity Scroll. Этот вариант используют в FinoBox, Эльба, Мегаплан. Если верстка и организация системы позволяет избавиться от горизонтального скроллинга, или же если горизонтальный скроллинг не приносит проблем с ориентированием в системе — это лучший выбор. Он очевиден, прозрачен и быстр. Минусом метода является то, что активно скроллить можно только один список, и вообще, одну панель (форму, меню, таблицу).
К сожалению реально большой объем данных за раз показать в браузере затруднительно, хотя бы из-за неподъемного DOM, которы растет пропорционально удобству подачи информации (много возможностей — много элементов на ячейку).
Быстрое открытие и выделение
Открытие по двойному клику (это стандарт). Не стоит путать двойной клик с открытием ссылки, т.к. ссылки, как правило, открываются на значение ячейки, как в Oreodor, Мегаплан, Эльба. Что интересно, в 1С ссылок нет (возможно это обусловлено их оконной организацией).
В некоторых системах есть выделение, в том числе и множественное Тут есть два подхода в интерфейсе — галочки и выделение. Не так важно как это делается, важно зачем. Множественное выделение позволяет реализовать групповые операции над указанными записями, например одновременная проводка множества документов.
Выделение Мегаплана, Oreodor, 1С реализовано подобно таковому в настольных приложениях (с зажатым Ctrl помечаются записи):
FinoBox же идет по пути галочек. В общем-то это более наглядно, но чуть менее удобно при большом количестве колонок (нежелателен горизонтальный скроллинг):
В некоторых системах, например Эльбе, вообще нет выделения записи. Это не минус, а скорее особенность, ведь функциональность именно Эльбы не страдает от этого. Не мало сил потратили аналитики и разработчики, чтоб довести бизнесс процесс до такого состояния, что не нужно выделять элементы.
Контекстное меню
Вообще, есть два типа ERP систем в Web — те, что пытаются быть браузерными, и те, что пытаются вести себя как настольные. Контекстное меню это нативный браузерный элемент управления, перехватывать его дерзко, но многие этим грешат, к примеру 1С и Oreodor.
Это накладывает определенные проблемы с операциями копирования, вставки и т.п., однако позволяет реализовывать действия в контексте элемента, на котором было вызвано меню. Пока не устоялся стандарт расширения контекстного меню браузера у этого решения есть очевидные минусы, но в перспективе это перестанет быть проблемой.
Большинство (например Мегаплан, Эльба и ФиноБокс) систем все же не перехватывают контекстное меню, оставляя его во власти браузера.
Фильтрация и поиск
Сердце любого списка, гоняющее в венах данные — это фильтрация, ну, и поиск. Эти штуки уже сами по себе нетривиальные. Дело в том, что на фильтрах сходится два противоречия — функциональность и простота. Простота — это удобство, функциональность — это возможность получить то, что нужно. В некоторых системах, как таковых, пользовательских фильтров нет. В смысле совсем нет. В них список открывается уже подфильтрованный по какому-то признаку, допустим активные счета, или пассивные счета, список называется “Мои активы”, “Мои пассивы”, или же переключатель режима где-то в списке “Показать документы”, “Показать акты”. С одной стороны это белый флаг, капитуляция перед лицом заведомо нерешаемой задачи легкого в использовании и функционального фильтра. С другой же — это отточенный бизнесс процесс, который за счет минимизации позволил отказаться от произвольных фильтров в принципе. Хорошим примером хорошей реализации этого является Эльба.
Те же, кто решился сделать фильтры, а это FinoBox, 1C, Oreodor, Мегаплан, разделились на две группы — фильтры через форму и фильтры через меню.
Фильтры через форму
Фильтр задается на форме, где-то рядом со списком. Форма сложная. Клинический случай развития идеи — использование формы с табличной частью для полноценного дерева выражений, приводящего в ужас гуманитарно-экономический склад ума. Но даже форма (за исключением формы с деревом выражений) не позволяет сложно сочитать условия объединения фильтров. И главная проблема — эта форма занимает безумно много места. Пространство, выделенное под неё, прямо пропорционально возможностям фильтров из интерфейса и сложности установленного фильтра. Наиболее красиво и изящно этот подход реализован в Мегаплан, им удалось сделать полноценную динамическую форму с хорошим откликом. Чуть по брутальнее сделано в FinoBox. Картинка для сравнения:
Фильтры через меню
Это попытка решить задачу элегантно ценою функционала. Как правило жертвуют условиями объединения фильтров, объединяя все фильтры через “И”. При этом появляется возможность фильтровать из разных мест, ведь элементы управления фильтром так же упрощаются. Например фильтр можно встроить в меню колонки, или контекстное меню ячейки. Вот как это выглядит в Oreodor:
Отказ от условий объединения влечет перемещение этой логики в сам фильтр, т.е. некоторые типы данных, например мультилинки, могут объединяться через ИЛИ, хотя все прочие фильтры через И.
Практически все системы позволяют сохранять преднастроенные фильтры, а некоторые и делиться ими с коллегами по системе. Особенно хорошо это сделано в Atlassian JIRA, хоть это и другая тема, но отличный пример для подражания.
Цвета, иконки, выделения
Типовая задача — выделить запись в списке цветом. Это может быть акцент на новой записи, подсвечивание аннулированной и т.п. Как правило, это выделение документа на том, или ином статусе. Возможность довольно распространенная и встречается везде, где это может понадобиться. Когда цвета мало — используют пиктограмму, которая призвана символизировать душевное состояние строки в текущий момент времени. Примеры этого в разных системах:
В некоторых системах дополнительно используют разные шрифты, кегли и ДЕКОР. Все, чем можно сделать нечитаемой любую таблицу, или убить эпилепсика. Однако, при умеренном использовании это незаменимый функционал для выделения записи среди её подруг.
Агрегации и группировки
Что может быть милее бухгалтеру строки “Итого”? А если ещё и с красной циферкой “- 0 руб. 17 коп.”… Бурю эмоций вызывает эта строка у чувственных, прекрасных повелительниц дебета и кредита. Большинство ERP систем умеет строить итоговую строку с различными функциами агрегации. Важной фичей является её динамическое перестроение по фильтру. Вот как это выглядит в Эльбе:
Пожалуй Эльба тут всех заткнула за пояс по удобству и осмысленности. В FinoBox все гораздо суровее:
Ну, и Oreodor совсем сурово:
Про группировку сложно сказать что-то новое. Группировка идет рука об руку с фильтрацией и сортировкой. Так же её можно эмулировать иерархией (о ней чуть позже), но, конечно, лучше когда она является возможностью списка, а не чем-то иным.
Отображение данных
Любопытно посмотреть плотность отображаемых данных на квадратный сантиметр экрана в разных системах:
Заметно четкое разделение двух лагерей — тех кто пытается показать как можно больше (more, more, MORE DATA!!!), и тех, кто пытается показать как можно меньше понятнее. Вообще не все данные воспринимаются пользователем, по этому нет большого смысла показать сразу все, гораздо важнее сколько информации будет усвоено.
Логичным продолжением этой тенденции будет развитие вариаций отображения данных. Красивый рендер на денежные типы, красивый на даты, на картинки и иконки. Особенно в этом хорош Мегаплан, но и FinoBox не уступает. В Oreodor есть реверанс в эту сторону. А вот Acumatica и 1С в этом плане сильно стиснены (в прямом смысле этого слова). Красиво и развернуто что-то показать там — проблематично.
Особое отображение данных в таблице — это первый шаг на пути к редактируемости этой таблицы. Поясню, чтоб красиво отобразить что-то рано или поздно потребуется отделить данные от их представления. А когда мы отделяем данные от представления — у нас появляется возможность работать с данными по разному, ведь они уже не являются сами по себе представлением этих данных. Т.е. теперь мы передаем не строку даты, красиво оформленную, а объект даты, с которым вполне себе можно что-то сделать. Редактируемая таблица вообще очень сложная штука, полная ограничений, костылей и условностей. Чем проще система, тем легче она дается и в большей мере реализуется. Например в FinoBox это выглядит так:
Любопытно как выделяются ячейки, которые доступны для редактирования. Очень красивый эффект. А вот в Oreodor все достаточно аскетично (красным уголком помечаются ещё не сохраненные изменения):
В 1С тоже есть редактируемые таблицы, но их возможности несколько ограничены:
Не таблицами едиными живет список
По сути таблица — это лишь один из вариантов представления набора данных. Накладывая на данные какой-то интерфейс, контракт, мы можем отобразить их в другом виде. Например имея диапазон дат в наборе, мы можем представить набор в виде календаря, а имея ссылку на родительский элемент — в иерархии. Эти два вида наиболее распространенные, хотя список можно показать и на карте, и вообще в полном 3D, графиком с зелеными пятнами на фоне (которые тоже что-то, да значат).
Автор: Selmaril