Что должно быть на дашборде:
- Только актуальное и ключевое, а также ссылка на детали. Не нужно выводить Заказы, Проекты в статусе Закрыто.
- Дашборд - это часть навигации на ключевые разделы. Каждая часть дашборда может давать ссылку на связанный раздел. Дашборд по сути будет играть роль расширенного меню, где вместо названия пункта меню выводится более детальная информация (таблица).
- Ключевые показатели. Должна быть максимальная гибкость с получением этих данных. Они могут вычисляться не только на основе данных в базе, но и по API, на основе файловой системы и т.д. (в старом варианте дашборда показатель выводился только на основе SQL запроса). Пример нетипичного показателя на практике - размер папки /uploads, где хранится файловый контент сайта.
- Управляющие действия, запускающие основные бизнес-процессы. Что обычно делает Пользователь в личном кабинете?
Рабочий стол должен быть гибким. Его структура не должна жестко ограничиваться возможностями компонента:
- Данные могут выводиться по API.
- Какие-то отчеты могут не выводиться в определенных ситуациях
- Должна быть возможность вложить любое управляющее действие на дашборд.
- Главное - дашборд должен иметь возможность в будущем развиваться (новые узкие отчеты, новые процессы, новые идеи для контроля данных и т.д.)
Рабочий стол должен быть действительно хабом, центральным местом для пользователя - отсюда он должен всегда начинать работу в личном кабинете. Формат вывода данных на рабочем - таблица, диаграммы или произвольная разметка (в нашем случае это форма на чтение).
Настройка рабочего стола пользователя. Технические нюансы
Очень непросто отказываться от своего компонента, но практика показывает, что связка простая Bootstrap разметка и Таблицы, Формы работает гораздо гибче и проще в плане управления/развития рабочего стола.
Примечание: Компонент Таблица может выводить не только таблицу, но и данные в других форматах (графики, канбан, календарь и т.д.). Форма - может выводить как реальную форму, так и просто некую разметку, генерируемую на основе данных из БД.
Важное о дашбордах в техническом плане:
Дашборд должен грузиться относительно быстро (т.к. часто запрашиваемая страница). Старайтесь минимизировать обращения к очень большим таблицам с дашборда (если используете, то обязательно убедитесь, что запрос с большой таблицей с первого раза работает быстро).
Лучше делать отдельные версии таблиц, форм под дашборд, а не пытаться универсально задействовать существующие таблицы (просто
можно копировать их через инструменты платформы). Пример: в Auction у Исполнителя выводится таблица Проекты и на дашборде идет ее краткая версия. Я использую суффикс Short для кодов таблиц (т.е. сразу понятно, что это краткая версия такой-то таблицы для дашборда).
Подобный подход позволит вам настроить вывод таблицы именно под конкретную ситуацию, не боясь поломать что-то в выводе основной таблицы.
Дополнительное отличие этих таблиц - это вывод только актуальных на данный момент данных (например, только активные проекты, а не все подряд).
Если данных много - возможно надо их агрегировать. Т.е. не нужно выводить много строк на дашборде. Удобнее работать с показателем агрегированных данных со ссылкой на детализацию. Пример подобного подхода - мы выводим количество ошибок по типам, а не сами ошибки. Человек видит тип ошибки и принимает решение, нужно ли ему с этим разбираться. Если да, то переходит в раздел ошибки и начинает их изучать более детально.
Кнопки действия - это модальные формы. На дашборд можно вывести ключевые бизнес действия пользователя в виде модальных форм (as-form-modal). Примеры: создать проект, создать клиента, занести расход и т.д. В некоторых случаях ключевым действием может быть и простая ссылка (пример из Auction: для Заказчика есть действие Искать исполнителя с переходом на каталог исполнителей).
Рабочий стол администратора-разработчика
У админа-разработчика мы тоже заменили дашборд. Причем этот дашборд также может смотреть и бизнес-админ (за исключением доступа к SQL).
Первый разворот:
Нет комментариев