Поведение адаптивного интерфейса при изменении размера экрана

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

Технически этот слой часто описывают через resize behavior, semantic back и state preservation. Общую модель см. в статье про адаптивный интерфейс, а роли панелей — в материале про многопанельную компоновку.

Почему изменение размера — это событие приложения

Изменение размера часто воспринимают как техническое событие браузера или окна. Для сложного интерфейса это продуктовый переход: приложение меняет рабочую поверхность. Если на expanded были видны список, карточка и inspector, а на compact осталась только форма, пользователь должен понимать, где остальные области и как к ним вернуться.

Поэтому resize должен проходить через модель layout state. Сначала приложение определяет новое состояние, затем решает, какие панели остаются видимыми, какие переходят в stack, какие закрываются как временные, и только после этого меняет визуальное представление. Данные пользователя при этом остаются стабильными.

Размеры панелей: min, ideal и max

Панели лучше описывать не одним breakpoint, а диапазоном. Min — минимальная ширина, где панель ещё работает. Ideal — комфортная ширина. Max — предел, после которого панель не должна бесконечно растягиваться. Если места меньше min, панель должна перейти в stack, sheet или скрыться по правилам роли.

Возврат назад: история, стек и временные слои

В web-приложении есть несколько похожих, но разных механизмов: история браузера, внутренний navigation stack, открытые временные слои и фокус внутри формы. Пользователь воспринимает их как один back. Если команда не задаёт приоритеты, back начинает вести себя непредсказуемо: то закрывает модальное окно, то уводит на прошлую страницу, то сбрасывает выбранный объект.

Практический порядок обычно такой: сначала закрыть временный слой, затем вернуть предыдущий смысловой уровень внутри текущего сценария, затем уже выполнять переход по истории. Но этот порядок нужно подтвердить для конкретного продукта и протестировать на compact, medium и expanded состояниях.

Временные слои стоит описывать отдельно от основной навигации. В Material Design bottom sheet используется как поверхность для действия поверх текущего контекста, а в Apple Human Interface Guidelines sheets описываются как способ временно представить задачу или выбор. Для приложения это означает простое правило: слой можно закрыть ожидаемым действием, а основной объект и контекст должны остаться на месте.

Смысловой возврат назад

Back должен возвращать пользователя по смысловым уровням. На compact он часто ведёт из detail в list. На expanded он может закрывать временную область, убирать inspector или возвращать фокус, не разрушая весь multi-pane layout. Это нужно тестировать отдельно, потому что browser history и UI stack не всегда совпадают.

Что хранить в состоянии

Минимальный набор state preservation зависит от сценария, но почти всегда включает selection, filters, draft, scroll position и focus. Для таблиц также важны сортировка, выбранные строки и раскрытые группы. Для редакторов — режим редактирования, несохранённые изменения и текущая вкладка. Для панелей — видимость, порядок и пользовательская ширина, если она настраивается.

Не всё нужно хранить в URL. Часть состояния адресуемая, часть локальная, часть пользовательская. Важно не место хранения само по себе, а гарантия: при допустимом resize и back пользователь продолжает работу без неожиданных сбросов.

Для данных полезно держать отдельное правило: если локальное состояние уже известно приложению, пользователь не должен видеть пустой экран только из-за сетевого обновления. Android guidance по offline-first прямо описывает ожидание, что приложение остаётся usable без надёжной сети и показывает локальные данные сразу. На уровне интерфейса это превращается в требование: обновление может уточнять данные, но не должно стирать текущий рабочий контекст.

State holder или аналогичный слой отвечает не за красивое название в архитектуре, а за предсказуемость: экран получает состояние, пользовательские события меняют его явно, а resize/back не превращаются в скрытый сброс формы, списка или выбранного объекта. См. также Android guidance по state holders and UI state.

Где хранить состояние

Нет единственного правильного места хранения. URL подходит для адресуемого состояния: выбранный раздел, id объекта, иногда фильтр. Глобальный store подходит для shell state и состояния между панелями. Локальное состояние компонента подходит для временных UI-деталей, которые можно безопасно потерять. Серверное состояние нужно для данных, которые должны пережить перезагрузку или работу с другого устройства.

Ошибка начинается тогда, когда место хранения выбирают до определения смысла. Сначала нужно понять, должно ли состояние пережить resize, reload, navigation, закрытие панели или передачу ссылки. После этого становится понятнее, где его хранить и как тестировать.

Что нельзя сбрасывать при изменении размера экрана

Особенно осторожно нужно обращаться с несохранёнными изменениями. Если resize или back закрывает форму, приложение должно либо сохранить черновик, либо предупредить пользователя, либо оставить форму доступной в stack. Тихая потеря ввода — один из самых болезненных дефектов адаптивного интерфейса.

Фильтры и сортировка тоже важны. Для пользователя это не декоративное состояние, а способ сузить рабочую область. Если после возврата список сбрасывается, человек вынужден заново восстанавливать контекст. То же относится к scroll position, раскрытым группам, выбранным вкладкам и focus внутри сложной формы.

Временный слой тоже не должен становиться причиной скрытого сброса. Если пользователь открыл короткое действие поверх текущего объекта, изменение ширины, back или свайп закрытия должны вернуть его к тому же месту работы. Если это невозможно, поведение нужно явно описать в acceptance criteria и показать в тестовом сценарии.

Что проверить после изменения ширины экрана

QA-сценарии для state preservation

Выбор объекта. Выбрать строку, открыть detail, изменить ширину окна и вернуться к списку.

Черновик формы. Ввести данные, открыть supporting pane, изменить layout state и проверить сохранение ввода.

Фильтры и scroll. Отфильтровать список, проскроллить, открыть объект и вернуться назад.

Временный слой. Открыть inspector или sheet, нажать back и проверить, что основной контекст остался.

Тестовые сценарии

• Compact → expanded → compact с выбранным объектом.
• Открытая форма с черновиком и resize окна.
• Supporting pane открыт, затем места стало меньше.
• Inspector открыт поверх detail, затем пользователь нажал back.
• Фильтр списка активен, пользователь переходит в detail и возвращается.
• Keyboard focus остаётся в логичном месте после перестройки layout.

Как превратить правила в тесты

Каждое правило resize/back/state должно иметь проверочный сценарий. Если правило говорит «черновик сохраняется», тест должен открыть форму, ввести значение, изменить размер окна, закрыть временную панель и убедиться, что значение осталось. Если правило говорит «back возвращает в список», тест должен проверить, что выбранная строка и scroll position восстановились.

Такие тесты можно начать как ручные acceptance scenarios, а самые стабильные перенести в автоматизацию. Главное — проверять не только DOM или URL, но и пользовательский смысл: где находится фокус, какая панель активна, может ли пользователь продолжить работу без повторного поиска объекта.

Автоматизация проверок

Часть сценариев можно проверять unit- или component-тестами: сохранение selection, draft и filters после изменения layout state. Часть лучше проверять end-to-end: реальный resize окна, нажатие back, восстановление focus и отсутствие потери ввода. Даже если автоматизация появится позже, сценарии нужно описать до реализации, чтобы дефекты не зависели от личной памяти тестировщика.

Особенно полезны regression-тесты для уже исправленных проблем: сброшенный фильтр, потерянный черновик, неправильный back из inspector, исчезнувший focus после смены ширины.

Acceptance criteria

• У каждой панели описаны min/ideal/max размеры.
• Back закрывает временный слой раньше, чем меняет основной уровень.
• Navigation stack восстанавливается после resize.
• Selection, filters, draft и scroll не сбрасываются без явного действия пользователя.
• Error/loading/empty states проверены отдельно для compact и expanded.

Что фиксировать в acceptance criteria

В acceptance criteria стоит писать конкретные переходы: из какого layout state в какой, какая панель закрывается, какой объект остаётся выбранным, что происходит с черновиком и куда попадает focus. Такие критерии легко проверить вручную и проще автоматизировать позже. Общая формулировка «состояние сохраняется» слишком слабая: она не говорит, какое именно состояние и при каком событии.

• Адаптивный интерфейс: как проектировать приложение под разные экраны
• Каркас приложения: как связать панели, навигацию и состояние
• Многопанельный интерфейс: когда показывать список и детали рядом