Многопанельный интерфейс: когда показывать список и детали рядом

Многопанельный интерфейс нужен, когда пользователь работает не с одним экраном, а с несколькими связанными областями: списком, карточкой объекта, контекстом, свойствами или предпросмотром. В английской терминологии здесь встречаются list-detail и multi-pane layout.

Базовую рамку см. в статье про адаптивный интерфейс. Если нужно понять, кто управляет ролями панелей и состоянием, см. материал про каркас приложения.

Основные паттерны

Список и карточка как рабочая пара

List-detail хорошо подходит для интерфейсов, где пользователь выбирает объект из коллекции и работает с его содержимым. Это может быть файл, клиент, заявка, задача, документ, сервис или запись журнала. На expanded-ширине список и detail показываются рядом, поэтому пользователь быстрее сравнивает объекты и не теряет место в коллекции.

На compact-ширине этот же сценарий становится последовательным: сначала список, затем detail. Важно, чтобы это был тот же сценарий, а не отдельная мобильная версия с другими правилами. Пользователь должен вернуться к тому же списку, той же выбранной строке и тем же фильтрам.

Supporting pane и inspector

Supporting pane показывает контекст, который имеет смысл только рядом с главным объектом: историю, комментарии, вложения, связанные элементы. Inspector ближе к панели параметров: права, свойства, события, диагностика. Их не стоит смешивать: supporting pane помогает работать с содержанием, inspector помогает понять или настроить объект.

Sheet или другой временный слой не должен конкурировать с detail. Если действие короткое и должно вернуться к тому же объекту, его лучше описывать как временный слой. Если область нужна для самостоятельной работы с объектом, это уже detail или отдельный уровень навигации. Такое разделение помогает не перегружать expanded-экран и не терять смысл на compact.

Как не перепутать supporting pane и detail

Detail имеет самостоятельный смысл: карточку объекта можно открыть и без списка. Supporting pane зависит от главного контента: комментарии, история, вложения или подсказки полезны только рядом с объектом. Это различие влияет на compact-поведение. Detail обычно становится отдельным уровнем navigation stack, а supporting pane может открываться как временный слой или скрываться до запроса пользователя.

Inspector отличается ещё сильнее: он показывает параметры, состояние, права или диагностику. Его не стоит делать обязательной частью основного сценария. Если без inspector пользователь не может выполнить базовое действие, значит это уже не inspector, а часть detail или формы.

Примеры

• Файловый менеджер: sidebar с папками, list с файлами, detail/preview, inspector со свойствами.
• CRM: список клиентов, карточка, история взаимодействий, панель задач.
• Админка: таблица сущностей, форма редактирования, журнал событий, права доступа.
• Developer console: список сервисов, detail состояния, логи, inspector конфигурации.

Несколько панелей и приоритеты

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

Хорошая модель отвечает на вопросы: какая панель primary, какая secondary, какая temporary, какая может быть скрыта без потери смысла. Если таких правил нет, expanded-экран превращается в набор равных колонок, где всё конкурирует за внимание.

Критерии выбора панели

Sidebar. Используйте для устойчивой навигации между разделами, папками, модулями или рабочими областями.

List-detail. Используйте, когда главный сценарий начинается с выбора объекта из коллекции.

Supporting pane. Используйте для контекста, который помогает работать с выбранным объектом.

Inspector. Используйте для свойств, прав, диагностики и технических параметров.

Как выбрать паттерн

Если вторичная область понятна сама по себе, чаще подходит list-detail. Если вторичная область имеет смысл только рядом с главным объектом, это supporting pane. Если область нужна для технических параметров и диагностики, это inspector. Если область меняет раздел приложения, это navigation/sidebar.

Связь с платформенными guidance

Android adaptive guidance выделяет list-detail и supporting pane как canonical layouts для разных form factors. Microsoft описывает TwoPaneView и split view как способы управлять двумя связанными областями. Apple через split views и NavigationSplitView также отделяет sidebar, content и detail области. Эти рекомендации различаются в API, но сходятся в одном: сложный интерфейс нужно раскладывать по смысловым областям, а не просто масштабировать.

Поэтому в web, desktop, mobile и cross-platform приложениях полезно сначала назвать роли панелей, а уже потом выбирать конкретный компонент: CSS grid, SplitView, NavigationSplitView, Jetpack Compose scaffold или собственный layout.

Как это работает на compact и expanded

Паттерн list-detail полезен, когда список и карточка объекта постоянно связаны. На expanded пользователь видит обе области рядом и быстрее сравнивает элементы. На compact список и карточка становятся последовательными экранами. Важно сохранить выбранную строку, чтобы возврат из карточки не начинался заново.

Как читать схему панелей

На схеме сначала смотрите не на размеры, а на роли областей. Sidebar выбирает раздел, list выбирает объект, detail раскрывает выбранный объект, supporting pane добавляет контекст, inspector показывает параметры. После этого видно, какие области могут стоять рядом на expanded-экране, какие остаются на medium, а какие становятся отдельным шагом на compact.

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

Типовые ошибки multi-pane

• Слишком много равных колонок. Пользователь не понимает, где главный объект и куда смотреть после действия.
• Supporting pane становится обязательной. Базовый сценарий ломается на compact-экране, потому что часть нужных действий спрятана.
• Inspector используют как detail. Техническая панель начинает конкурировать с основным содержанием.
• Sidebar скрывают без альтернативы. На compact пользователь теряет навигацию между разделами.
• List сбрасывается при возврате. Пользователь возвращается не к выбранной строке, а в начало списка.

Как описать multi-pane в требованиях

В требованиях к multi-pane layout важно не только перечислить панели, но и указать их зависимость. Sidebar обычно независим: он меняет раздел. List зависит от выбранного раздела. Detail зависит от выбранной строки. Supporting pane зависит от detail. Inspector может зависеть от detail или от отдельного технического объекта. Эта цепочка помогает определить, что можно скрыть без потери смысла.

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

Проверка на лишнюю панель

Перед добавлением новой панели полезно спросить: помогает ли она выполнить основной сценарий быстрее или просто показывает дополнительные данные? Если панель редко нужна, её лучше открывать по действию. Если она нужна постоянно, ей стоит дать явную роль и место в layout state. Так multi-pane остаётся рабочей поверхностью, а не набором открытых окон.

Границы паттерна

Не каждый широкий экран требует multi-pane. Если пользователь выполняет один короткий шаг, дополнительная панель может только отвлекать. Multi-pane оправдан, когда рядом нужны связанные области: выбор и содержание, объект и контекст, данные и свойства. Если связь между областями слабая, лучше оставить отдельные страницы или вкладки.

Также не стоит переносить desktop-плотность на compact. Узкий экран должен получить последовательный сценарий с тем же смыслом, а не уменьшенную копию всех колонок.

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