Skip to content

ui-guidelines.md

Latest commit

 

History

History
69 lines (53 loc) · 6.83 KB

ui-guidelines.md

File metadata and controls

69 lines (53 loc) · 6.83 KB
Raw

UI-гайд проекта

Интерфейс Центр администрирования 1С строится как нативная Windows 11 админ-консоль на WinUI 3.

Основные ориентиры

  • Базовые правила: Windows app design guidelines.
  • Дизайн-язык: Fluent Design / Fluent 2.
  • Реализация: стандартные WinUI 3 controls and patterns.
  • Стандартные UI-паттерны не дублируем вручную: интерфейс строим на WinUI, Windows App SDK и Windows Community Toolkit.
  • Проверка решений: WinUI Gallery и реальные скриншоты приложения.

Полезные ссылки:

Характер интерфейса

  • Приложение должно ощущаться как рабочий инструмент администратора, а не как лендинг или сайт.
  • Главная ценность экрана: быстро понять состояние 1С и найти нужную службу, кластер, порт или путь.
  • Декор не должен конкурировать с данными. Mica, стандартная типографика Segoe UI и WinUI-контролы достаточны.
  • Окно приложения открывается большим, потому что это консоль управления с таблицами и диагностикой.

Готовые UI-блоки

  • По умолчанию любой новый UI-блок должен быть стандартным WinUI-контролом или контролом из Windows Community Toolkit.
  • Самописный визуальный контрол допускается только если готовой библиотечной замены нет; причину фиксировать рядом с кодом или в описании изменения.
  • Не писать собственные аналоги SettingsCard, SettingsExpander, NavigationView, InfoBar, ContentDialog, CommandBar, Button, ProgressRing и других стандартных блоков.
  • Для строк в стиле Windows 11 Settings использовать SettingsCard из CommunityToolkit.WinUI.Controls.SettingsControls.
  • Для групп с раскрытием использовать SettingsExpander из CommunityToolkit.WinUI.Controls.SettingsControls.
  • Для навигации использовать NavigationView, режимы Left, LeftCompact, LeftMinimal и явные breakpoints на уровне shell.
  • Для иконок использовать FluentIcon из FluentIcons.WinUI; ручные glyph-коды допустимы только если иконки нет в библиотеке.
  • Для состояния загрузки, ошибок и подтверждений использовать стандартные WinUI-контролы: ProgressRing, InfoBar, ContentDialog, CommandBar или Button.
  • Собственный XAML допускается только для page scaffold, адаптивной композиции и связывания готовых контролов в доменные сценарии 1С.

Таблицы и списки

  • Колонки должны быть стабильными и не съезжать при изменении данных.
  • Не использовать непонятные сокращения без подписи: 1540 / 1541 / 1550 / 1560:1591 хуже, чем Агент, Кластер, Отладка HTTP, Процессы.
  • Важное видно сразу: тип, состояние, версия, порты, PID, запуск, учетная запись.
  • Технические детали показываются компактно и постоянно, если экран большой и это не перегружает список.
  • Если деталей много, сначала пробовать структурировать их в строки поле -> значение, а не прятать за лишним кликом.
  • Общую расшифровку портов держать в верхней памятке, а в строке службы показывать только фактические значения конкретной службы.

Термины 1С и Windows

  • Различать отображаемое имя службы Windows и системное имя службы.
  • При регистрации новой службы агента оба имени должны совпадать. Использовать одно автоматически формируемое поле по шаблону 1C:Enterprise <основная версия> Server Agent <порт агента> <полная версия>, например 1C:Enterprise 8.3 Server Agent 1540 8.3.27.2170. При смене платформы или порта пересчитывать имя. Уже зарегистрированные службы показывать с их фактическими именами.
  • Подписывать явно:
    • Службы Windows - отображаемое имя из оснастки Windows Services.
    • Диспетчер задач - системное имя службы, видимое в Task Manager и командной строке.
  • Порты показывать по назначению:
    • Агент - порт агента кластера, например localhost:1540.
    • Кластер - порт главного менеджера кластера rmngr, параметр /regport, например server:1541.
    • RAS - порт сервера администрирования ras, обычно 1545.
    • Отладка HTTP - порт сервера отладки, параметр /debugServerPort, обычно 1550.
    • Процессы - диапазон портов рабочих процессов rphost и дополнительных менеджеров кластера.

Проверка UI

Перед коммитом UI-изменений нужно:

  • собрать проект;
  • запустить приложение;
  • сделать скриншот окна;
  • визуально проверить обычное состояние и состояния раскрытия/ошибки, если они есть;
  • убедиться, что текст не обрезан без необходимости и не дублируется.