# Рекомендации по проектированию интерфейсов ```{note} Раздел находится в стадии разработки. ``` Разработка интерфейса системы строится на требованиях к простоте, интуитивной понятности и гибкости взаимодействия. Система должна быть построена на программном обеспечении с простым и интуитивно понятным интерфейсом. Ввод и вывод данных, прием управляющих команд и отображение результатов их исполнения должны выполняться в интерактивном или автоматическом режимах. Начиная с версии системы 1.26 в Global ERP внедряется обновленный графический интерфейс. При переносе существующих интерфейсов и разработке новых интерфейсных форм необходимо учитывать требования обновленного интерфейса и руководствоваться [Инструкцией по миграции на новый интерфейс](https://help.globalerp.ru/books/gs-docs-sphinx/master/guide/howto/new_interface_migration.html). Это позволяет заранее учитывать типовые ограничения и предотвращать распространенные ошибки при адаптации интерфейсов. Интерфейс должен обеспечивать: - удобный ввод и просмотр данных; - выполнение управляющих команд пользователем; - отображение результатов выполнения операций; - работу пользователя с данными в интерактивном режиме; - поддержку автоматических сценариев, если операция выполняется без непосредственного участия пользователя; - единый подход к взаимодействию пользователя с разными модулями системы. Технические сведения об интеграции с другими системами, каналах информационного обмена и менеджере регламентированных заданий приведены в статье: [Интеграция с другими системами](https://help.globalerp.ru/books/G4SysMDMDoc/SNAPSHOT/html/020_MDM-for-user/040_interation-external.html). ## Базовые требования к интерфейсу Интерфейс системы должен соответствовать следующим критериям. | Критерий | Описание | |---|---| | Простота навигации | Пользователь должен достигать цели с минимальным количеством действий. Функции должны быть сгруппированы логично. | | Интуитивная понятность | Назначение элементов управления должно быть очевидным. | | Адаптивность | Интерфейс должен корректно отображаться на различных устройствах и разрешениях экрана. | | Консистентность | В разных модулях системы должны использоваться единые подходы к стилю, терминологии и поведению элементов. | | Обратная связь | Пользователь должен получать информацию о статусе операции, результате действия или возникшей ошибке. | ## Режимы взаимодействия с системой Система поддерживает два основных режима взаимодействия: интерактивный и автоматический. Они различаются способом ввода данных, передачи команд и отображения результатов. | Режим | Назначение | |---|---| | Интерактивный режим | Используется для непосредственной работы пользователя через графический интерфейс. | | Автоматический режим | Используется для выполнения операций без непосредственного участия пользователя. | ### Интерактивный режим Интерактивный режим предназначен для работы пользователя с системой через графический интерфейс. В этом режиме: - ввод данных выполняется через формы, карточки объектов и карточно-сеточные интерфейсы; - управляющие команды передаются через кнопки, контекстные меню и горячие клавиши; - результаты выполнения операций отображаются в виде таблиц, диаграмм, уведомлений или обновленных полей; - поддерживаются отмена действий, пошаговая навигация и контекстные подсказки. Интерактивный режим должен быть ориентирован на понятность действий пользователя: пользователь должен понимать, какое действие он выполняет, какие данные изменяет и какой результат получает после выполнения операции. ### Автоматический режим Автоматический режим обеспечивает выполнение операций без непосредственного участия пользователя. В этом режиме команды и обработка данных могут запускаться по расписанию, событиям или через внешние сценарии обмена. Результаты выполнения должны быть доступны для контроля: через журналы, статусы, уведомления, дашборды или другие интерфейсные средства отображения. Подробное описание интеграционных механизмов приведено в разделе [Интеграция с другими системами](https://help.globalerp.ru/books/G4SysMDMDoc/SNAPSHOT/html/020_MDM-for-user/040_interation-external.html). ## Принципы проектирования пользовательского опыта При разработке интерфейсов необходимо учитывать особенности корпоративных систем: большое количество данных, сложные бизнес-процессы, разграничение прав доступа и необходимость регулярной работы пользователя с типовыми операциями. Рекомендуется придерживаться следующих принципов. | Принцип | Описание | |---|---| | Минимизация когнитивной нагрузки | Связанные функции должны быть сгруппированы. Сложные настройки следует раскрывать постепенно. | | Предсказуемость поведения | Элементы интерфейса должны реагировать ожидаемым образом и соответствовать привычным сценариям пользователя. | | Доступность | Необходимо учитывать клавиатурную навигацию, контрастность цветов и масштабируемость шрифтов. | | Контекстная помощь | Подсказки, тултипы и ссылки на документацию должны располагаться рядом с соответствующими элементами. | | Обработка ошибок | Сообщения об ошибках должны быть понятными и содержать рекомендации по исправлению. | При проектировании интерфейса важно не перегружать пользователя техническими деталями. Сложные настройки, служебные параметры и редко используемые действия должны быть доступны, но не должны мешать выполнению основных сценариев. ## Структура интерфейсных компонентов Типовые элементы интерфейса должны проектироваться единообразно. Это упрощает обучение пользователей и снижает риск ошибок при работе с разными разделами системы. Практические примеры реализации интерфейсов, настройки AVM-разметки и работы с отображениями приведены в [Руководстве разработчика](https://help.globalerp.ru/books/GlobalServerAppGuide/SNAPSHOT/html/090_appendix/practice/%D0%9F%D1%80%D0%B0%D0%BA%D1%82%D0%B8%D0%BA%D0%B0%20avm.html). ### Списки и карточки объектов Списки и карточки объектов используются для просмотра, поиска, отбора и редактирования данных. При проектировании таких интерфейсов необходимо учитывать следующие правила: - список должен отображать перечень записей в понятном для пользователя виде; - для записей должны быть доступны сортировка, фильтрация и группировка, если это требуется сценарием работы; - карточка объекта должна показывать основные характеристики выбранной записи; - часто используемые действия должны быть доступны без лишних переходов между формами; - пользовательские настройки отображения должны сохраняться при повторном открытии интерфейса. Интерфейс должен помогать пользователю быстро найти нужную запись, просмотреть ее состояние и выполнить доступные действия. Технические примеры настройки карточек, гридов, вкладок и присоединенных отображений приведены в [Руководстве разработчика](https://help.globalerp.ru/books/GlobalServerAppGuide/SNAPSHOT/html/090_appendix/practice/%D0%9F%D1%80%D0%B0%D0%BA%D1%82%D0%B8%D0%BA%D0%B0%20avm.html). ### Формы ввода данных Формы ввода используются для создания, изменения и просмотра данных. При разработке форм необходимо соблюдать следующие правила: - поля должны группироваться по логическим блокам; - для группировки могут использоваться вкладки или аккордеоны; - обязательные поля должны визуально выделяться; - валидация должна выполняться как при вводе, так и при отправке формы; - должны поддерживаться шаблоны значений, автозаполнение и подстановка по справочникам; - при необходимости должна быть предусмотрена возможность черновика и отложенной отправки формы. Форма должна быть построена так, чтобы пользователь понимал, какие данные нужно заполнить, какие поля являются обязательными и какие ошибки необходимо исправить перед сохранением. ### Панели управления и команд Панели управления используются для размещения команд, доступных пользователю в текущем контексте. При разработке командных панелей необходимо учитывать следующие правила: - часто используемые действия должны выноситься в верхнюю панель или контекстное меню; - кнопки должны иметь текстовые подписи; - при необходимости могут использоваться иконки для быстрого распознавания действия; - действия должны учитывать разграничение прав доступа; - недоступные действия должны скрываться или визуально блокироваться; - панель может настраиваться пользователем под индивидуальные задачи. Команды должны быть расположены так, чтобы пользователь мог быстро выполнить основное действие и при этом не путал основные операции со служебными или редко используемыми. Примеры настройки операций, подписей, описаний, горячих клавиш и всплывающих подсказок приведены в [Руководстве разработчика](https://help.globalerp.ru/books/GlobalServerAppGuide/SNAPSHOT/html/090_appendix/practice/%D0%9F%D1%80%D0%B0%D0%BA%D1%82%D0%B8%D0%BA%D0%B0%20avm.html). ## Отображение автоматических процессов в интерфейсе Автоматические процессы должны быть представлены в интерфейсе так, чтобы пользователь или администратор мог контролировать их состояние без анализа технической реализации. В интерфейсе должны быть предусмотрены средства, которые позволяют: - увидеть текущий статус выполнения операции; - определить, завершилась операция успешно или с ошибкой; - просмотреть результат выполнения; - перейти к журналу или карточке связанной операции; - понять, требуется ли действие пользователя или администратора. Если автоматический процесс связан с обменом данными с другими системами, в интерфейсе следует давать ссылку на соответствующие журналы, настройки или статусы обмена. Техническое описание механизмов см. в [Интеграция с другими системами](https://help.globalerp.ru/books/G4SysMDMDoc/SNAPSHOT/html/020_MDM-for-user/040_interation-external.html). ## Обработка ошибок и обратная связь Интерфейс должен предоставлять пользователю понятную обратную связь по результатам действий. Если пользовательская операция не может быть выполнена, система выводит сообщение с причиной ограничения. Такое сообщение помогает пользователю понять, почему действие недоступно: например, из-за состояния объекта, отсутствия необходимых прав, некорректных данных или другого ограничения, влияющего на выполнение операции. Если действие пользователя приводит к ошибке в работе системы, информация об ошибке отображается в виде сообщения или нотификации. Сообщение должно быть понятным для пользователя и не должно заменяться технической трассировкой или внутренним кодом ошибки. Сообщения об ошибках должны: - описывать проблему понятным языком; - указывать, какое действие не удалось выполнить; - по возможности объяснять причину ошибки; - содержать рекомендацию по исправлению; - не заменять пользовательское сообщение технической трассировкой или внутренним кодом ошибки. При некорректном вводе данных, неверном формате значений или выполнении недопустимой команды система обрабатывает ситуацию без нарушения дальнейшей работы интерфейса. После вывода сообщения пользователь возвращается к состоянию, в котором может исправить введенные данные, изменить команду или продолжить работу без повторного открытия интерфейса. Если ошибка возникла в автоматическом режиме, пользователь или администратор должен иметь возможность перейти к информации о статусе операции, журналу выполнения или связанному объекту. ## Рекомендации по проверке интерфейса Перед выпуском изменений необходимо проверять как интерактивные пользовательские сценарии, так и автоматические режимы взаимодействия. ### Проверка интерактивных сценариев Для интерактивного режима необходимо проверить: - полноту навигации: все функции доступны через ожидаемые пути; - корректность валидации: поля принимают только допустимые значения; - понятность сообщений об ошибках; - производительность интерфейса; - корректное отображение в поддерживаемых браузерах и версиях; - корректность отображения результатов выполнения операций; - работу кнопок, контекстных меню и горячих клавиш. - соответствие интерфейса требованиям обновленного графического интерфейса и рекомендациям [Инструкции по миграции на новый интерфейс](https://help.globalerp.ru/books/gs-docs-sphinx/master/guide/howto/new_interface_migration.html), если интерфейс разрабатывается или переносится для версии 1.26 и выше; Проверка должна подтверждать, что пользователь может выполнить основной сценарий без лишних действий и без необходимости обращаться к техническим деталям реализации. ### Проверка автоматических режимов Для автоматических сценариев необходимо проверить: - корректное отображение статусов выполнения; - фиксацию результата выполнения; - фиксацию ошибок и возможность их анализа; - возможность повторного запуска или перехода к связанному процессу, если это предусмотрено интерфейсом; - соответствие времени выполнения задач бизнес-требованиям и SLA. Проверка автоматического режима должна подтверждать, что фоновые и интеграционные сценарии не являются «невидимыми» для пользователя или администратора: результат их выполнения должен быть доступен для контроля через интерфейсные средства системы.