Я очень люблю, когда мне участники тренингов задают разные дополнительные вопросы, пусть даже косвенно относящиеся к теме. (Кстати, не только участники тренингов — вы тоже можете меня спрашивать, например в чате к этому каналу).
Вот, например, вопрос про лучшие практики построения админок. На удивление, толковых публикаций на эту тему мало, в основном либо пустые SEO-тексты, либо реклама своих фреймворков/шаблонов. И пишут чаще всего про дизайн, а не про функции.
К хорошим (но очень коротким!) относятся рекомендации от дизайнеров британских правительственных сервисов:
https://designnotes.blog.gov.uk/2015/09/25/design-principles-for-admin-interfaces/ , но это редкость, да и мало там инсайтов.
Поэтому я взял на себя смелость собрать несколько идей и принципов, с которыми лично сталкивался. Надеюсь, будет вам полезно, если вы занимаетесь админками. Не значит, что вам все эти практики нужны, но просто знайте про них, вдруг пригодятся.
Итак, что я узнал про админки за 25 лет:
— Общий обзор: вытащите на главную страницу админки несколько самых актуальных показателей, последних событий и алертов, чтобы сразу было понятно, что в системе происходит и за что браться в первую очередь;
— Админы — разные. Дайте им возможность настроить админку лично для себя. Скорее всего, ваши админы выполняют разные задачи, поэтому хорошо бы предусмотреть виджеты и возможность вытащить на первую страницу разные данные и действия;
— Разные и многоуровневые права доступа, а не один админ со всеми правами. Админы бывают разные, и в больших системах доступ админов может быть очень гранулировано нарезан — как по доступу к разным типам данных и разным действиям, так и по содержанию данных. Например, по категориям клиентов, или как у меня было на учебной платформе: админ учебных групп отдельного вуза, админ одного курса, админ вуза с доступом ко всем курсам, админ всех студентов, админ всех курсов, админ всей системы. Только на назначение прав доступа три роли несовмещаемые должны быть, в идеале: один создает группы с правами, другой заводит пользователей, третий назначает пользователей в группы по идентификаторам. Чтобы один админ не мог создать супер-пользователя.
— Журналирование всех действий админа (в том числе на просмотр, фильтры и поиск; в том числе — с оповещениями более старшего админа о подозрительных действиях);
— Поиск, фильтры и сортировка (в админке бывают большие объемы данных);
— Серьезные подтверждения для опасных необратимых действий (не кнопка "Да, продожить", а в виде ручного ввода длинной строки текста, "Я понимаю, что я собираюсь удалить бэкап базы данных, и это действие невозможно отменить" или согласия старшего админа);
— Возможность отменить действия. Вообще сохранение истории и возможность просмотра предыдущих состояний (и связей!) объекта.
— "Мягкое удаление" везде, где возможно (если это не противоречит регуляторным требованиям). Следите также за каскадным удалением, оно опасно!
— Функции для пакетных операций! Когда можно выделить несколько элементов и с ними что-то сделать одним действием.
— Инлайн-редактирование прямо в строке таблицы. Часто бывает трудно реализовать чисто технически, но в некоторых случаях сильно упрощает работу.
— Связки всего со всем и переходы — когда можно легко из одного объекта в другой связанный провалиться, или перейти от общего к деталям (drill down) и вернуться обратно.
— Подсветка тревожных и подозрительных событий (когда они ещё не стали сбоем и проблемой). Например,
— Принцип "один экран — одно действие" в админках не работает. Там наоборот — лучше побольше контекстных действий уместить на экране.
— Ширина экрана и плотность информации. Используйте экран по полной! В админках не очень нужен дизайнерский "воздух", чаще важнее число отображаемых элементов.
— Адрес админки. Должен быть неочевидным! Никаких /admin и тому подобного. Ещё можно ограничить IP-адреса, с которых можно заходить в админку.
Как-то так, что сходу вспомнилось. Если есть ещё идеи, или вы сами с чем-то сталкивались — пишите в комментарии!
>>Click here to continue<<