Редизайн интерфейса WinForms- и VB6-приложения: как обновить UI без полного переписывания

Жалобы на старое десктопное приложение редко звучат как «у нас плохой код». Звучат они иначе: на ноутбуке с 4K-экраном всё мелкое и размытое, новые сотрудники неделю учатся находить нужную кнопку, а форма заказа с сорока полями не помещается на экран и прокручивается рывками. Логика при этом работает годами без сбоев, и переписывать её ради внешнего вида никто не хочет — и правильно.

Поэтому задачу стоит сразу разделить на две: что именно мешает пользователям и какими техническими средствами это исправить, не трогая проверенные расчёты. Первая часть — работа дизайнера интерфейсов: интервью, карта сценариев, прототипы экранов. Если своих специалистов нет, её разумно отдать на проектирование UI/UX-дизайна внешней команде, а разработчикам оставить реализацию. Вторая часть — инженерная, и о ней основная часть этой статьи.

Если приложение ещё живёт на .NET Framework или VB6, сначала прочитайте разборы переноса WinForms на современный .NET и миграции VB6 через COM: большая часть приёмов ниже доступна только после смены платформы или упрощается после неё.

Когда интерфейс пора обновлять, а когда нет?

Редизайн окупается, когда интерфейс мешает работе измеримо: растёт время обучения, пользователи ошибаются в одних и тех же полях, служба поддержки отвечает на одни и те же вопросы «где это найти». Если же приложение открывают раз в месяц три бухгалтера и никто не жалуется, деньги лучше потратить на тесты и сопровождение.

Признаки, что пора:

• Проблемы масштабирования. На мониторах с масштабом 150–200 % текст обрезается, контролы налезают друг на друга, иконки размыты.
• Перегруженные формы. Десятки полей на одном экране, вкладки внутри вкладок, кнопки без подписей с иконками 16×16 из Windows 98.
• Нет клавиатурного сценария. Оператор, который вводит сотни записей в день, вынужден постоянно хвататься за мышь.
• Новые требования к доступности. Корпоративные политики и госзаказчики всё чаще проверяют работу с экранным диктором и контрастность.
• Ошибки ввода. Одни и те же неверные значения в отчётах указывают не на пользователей, а на форму, которая их провоцирует.

Признак, что не пора: интерфейс устраивает пользователей, а раздражает только разработчиков. Модный внешний вид без изменения сценариев работы не сокращает ни время операций, ни число ошибок.

С чего начать: UX-аудит legacy-приложения

Любые технические решения принимаются после того, как понятно, какие экраны важны. В приложении на сотню форм реально используется, как правило, малая часть, и именно на ней сосредоточено почти всё время пользователей.

1. Соберите статистику. Если логирования открытия форм нет, добавьте его: одна строка в базовом классе формы или в обработчике Load покажет через месяц, какие экраны открывают чаще всего.
2. Понаблюдайте за работой. Час рядом с оператором даёт больше, чем неделя переписки. Записывайте, где он останавливается, что ищет, какие обходные пути придумал.
3. Составьте карту сценариев. «Принять заказ», «найти клиента», «закрыть месяц» — для каждого сценария перечислите экраны и шаги.
4. Оцените каждый экран. Частота использования, число ошибок, время операции, техническая сложность формы (сторонние контролы, рисование на форме, логика в обработчиках).
5. Сделайте прототипы. Для трёх-пяти самых нагруженных экранов нарисуйте новую компоновку и проверьте её на реальных пользователях до того, как писать код.

Результат аудита — приоритизированный список: какие экраны переделывать первыми, какие достаточно причесать, а какие оставить как есть. Он же становится основой сметы; как считать трудоёмкость по такому списку, мы разбирали в статье об оценке стоимости миграции.

Какие улучшения можно сделать без переписывания форм?

Значительную часть претензий к старому интерфейсу закрывают настройки и аккуратная доработка существующих форм. Это самые дешёвые изменения, и с них стоит начинать, пока идёт проектирование новых экранов.

High DPI. В WinForms на .NET Framework 4.7 и новее режим Per-Monitor V2 включается в app.config через секцию System.Windows.Forms.ApplicationConfigurationSection, а на современном .NET — вызовом Application.SetHighDpiMode(HighDpiMode.PerMonitorV2) или свойством проекта ApplicationHighDpiMode. После включения проверьте формы с жёстко заданными координатами: их придётся перевести на TableLayoutPanel, FlowLayoutPanel и привязки Anchor/Dock.

Шрифты и сетка. Замена шрифта по умолчанию на Segoe UI 9 pt и единые отступы между контролами уже меняют впечатление от приложения. Задайте шрифт на уровне базовой формы, чтобы его унаследовали все остальные.

Клавиатура. Правильный TabIndex, мнемоники через амперсанд в подписях, AcceptButton и CancelButton на диалогах, горячие клавиши для частых команд. Для операторов ввода это часто важнее любого визуального редизайна.

Доступность. Заполните AccessibleName и AccessibleDescription у контролов без текста, проверьте работу с Экранным диктором и контрастность в высококонтрастной теме Windows.

Тёмная тема. В .NET 9 у WinForms появился метод Application.SetColorMode, но он помечен как экспериментальный (предупреждение компилятора WFO5001), и сторонние контролы его часто не поддерживают. Включайте его только после проверки всех используемых компонентов.

Как подготовить код к новому интерфейсу?

Главное препятствие при обновлении интерфейса — не сами формы, а то, что в них живёт. В типичном legacy-приложении обработчик кнопки открывает соединение с базой, считает скидку, проверяет остатки и печатает накладную. Пока это так, любой новый экран придётся писать вместе с копией этой логики.

1. Зафиксируйте поведение тестами. Характеризационные тесты на расчёты и проверки — до любого рефакторинга; подход описан в статье о тестах для legacy VB.NET.
2. Вынесите логику в отдельную библиотеку. Обработчик формы должен только собрать данные, вызвать метод сервиса и показать результат.
3. Введите модель представления. Даже в WinForms паттерн MVP или упрощённая модель с привязкой данных отделяют состояние экрана от контролов.
4. Уберите прямой доступ к данным из форм. Репозитории или сервисы данных позволят одинаково обслуживать и старый, и новый экран.

' Было: расчёт и доступ к данным прямо в обработчике
' Стало: форма только передаёт данные сервису
Private Sub btnSave_Click(sender As Object, e As EventArgs) Handles btnSave.Click
    Dim order = BuildOrderFromControls()
    Dim result = _orderService.Save(order)
    If Not result.IsValid Then
        ShowErrors(result.Errors)
        Return
    End If
    lblTotal.Text = result.Total.ToString("N2")
End Sub

После такого разделения новый экран на любой технологии вызывает тот же _orderService, и вопрос «а правильно ли считает новая версия» снимается тестами на сервис, а не ручной сверкой экранов.

WPF, WebView2, Blazor Hybrid или Avalonia: что выбрать?

Для поэкранной замены у WinForms есть четыре рабочих пути. Все они позволяют встроить новый экран в работающее приложение, так что пользователи не замечают «большого переезда».

• WPF через ElementHost. Контрол из пространства имён System.Windows.Forms.Integration размещает WPF-элемент на форме WinForms; Microsoft описывает это в руководстве по размещению WPF-контрола в Windows Forms. Подходит командам, которые знают XAML; остаётся привязка к Windows. Примеры привязки данных в XAML есть в разделе WPF.
• Веб-разметка через WebView2. Контрол на движке Edge показывает HTML-страницу внутри формы и обменивается сообщениями с кодом .NET; старт описан в документации WebView2 для WinForms. Удобно, если такой же экран нужен и в браузере, но требует продумать обмен данными и безопасность загружаемого контента.
• Blazor Hybrid через BlazorWebView. Компоненты Razor работают внутри WinForms-приложения на .NET 6 и новее и вызывают .NET-код напрямую, без HTTP; см. руководство Microsoft по Blazor в Windows Forms. Лучший вариант, если в перспективе часть функций уедет в веб: компоненты потом переносятся в Blazor-приложение почти без изменений.
• Avalonia через WinFormsAvaloniaControlHost. Встраивает Avalonia-представление в форму WinForms и позволяет мигрировать экран за экраном с прицелом на Linux и macOS. Имеет смысл, когда кроссплатформенность — реальное требование, а не пожелание.

Короткое правило выбора: нужен только Windows и команда знает XAML — WPF; экран должен жить ещё и в браузере — Blazor Hybrid; нужен Linux или macOS — Avalonia; есть готовый веб-интерфейс, который надо показать в десктопе, — WebView2. Смешивать больше двух технологий в одном приложении не стоит: каждая добавляет свой цикл обновлений и свои особенности сборки.

Как быть с VB6-приложением?

У VB6 возможностей меньше: сама среда не умеет Per-Monitor DPI, не поддерживает современные контролы, а шаблоны оформления ограничены манифестом с Common Controls 6. Поэтому для VB6 обычно выбирают одну из двух стратегий.

Косметика без смены платформы. Манифест для визуальных стилей Windows, замена шрифтов и иконок, перекомпоновка самых нагруженных форм, режим совместимости DPI в свойствах исполняемого файла. Это продлевает жизнь интерфейсу на несколько лет, но не решает проблем с масштабированием на смешанных мониторах. Практика сопровождения такого приложения описана в статье о VB6 в 2026 году.

Новые экраны на .NET через COM. Новая форма пишется на .NET, регистрируется как COM-видимая сборка и вызывается из VB6. Пользователь работает в одном приложении, а экраны постепенно переезжают. Этот путь совпадает с поэтапной миграцией, поэтому редизайн и смена платформы делаются одним проектом, а не двумя.

План поэкранной модернизации

Обновление интерфейса лучше вести короткими итерациями, каждая из которых заканчивается выпуском. Тогда пользователи получают пользу каждые несколько недель, а команда — обратную связь.

1. Итерация 0. UX-аудит, статистика использования форм, прототипы трёх-пяти ключевых экранов, выбор технологии на одном пилотном экране.
2. Итерация 1. Сквозные улучшения без переписывания: High DPI, шрифты, клавиатура, доступность, замена самых устаревших иконок.
3. Итерация 2. Вынос логики пилотного экрана в сервис, тесты, новая реализация экрана, выпуск на группу пилотных пользователей.
4. Итерации 3 и далее. По одному-два экрана за итерацию в порядке приоритета из аудита. Старый экран остаётся в коде, пока новый не принят пользователями.
5. Завершение. Удаление неиспользуемых форм и сторонних компонентов, обновление документации и инструкций.

Чек-лист приёмки каждого нового экрана:

• все сценарии из карты проходят без мыши;
• экран корректно выглядит при масштабе 100, 150 и 200 % и при переносе окна между мониторами;
• Экранный диктор озвучивает поля и кнопки;
• расчёты дают тот же результат, что старый экран, на эталонных данных;
• время типовой операции не выросло по сравнению со старой версией.

Типичные ошибки при редизайне старого приложения

• Перерисовать всё сразу. Большой выпуск нового интерфейса без переходного периода гарантирует волну жалоб и откат.
• Повторить старую компоновку на новой технологии. Перенос сорока полей с одной формы на другую дорогим способом сохраняет все проблемы старого экрана.
• Не спросить пользователей. Опытные операторы опираются на привычные позиции полей и горячие клавиши. Их надо сохранить или осознанно заменить, предупредив заранее.
• Оставить логику в форме. Тогда новый экран получает копию бизнес-правил, и через год две версии считают по-разному.
• Выбрать технологию по моде. Решение принимают по требованиям (платформы, веб, компетенции команды), а не по тому, что обсуждают на конференциях.

Как это делают сегодня

Вопросы и ответы