Самые простые техники адаптивной верстки / Хабр

Сайтов с адаптивной разметкой с каждым месяцем становится все больше, заказчики кроме кроссбраузерности все чаще требуют адаптивность, но многие разработчики не спешат обучаться новым техникам. Но адаптивный дизайн — это просто! В этой статье представлено 5 примеров адаптивной разметки различных элементов веб-страниц.

1. Видео (демо)

Очень простой CSS и HTML, и ваше embed-видео будет масштабироваться в соответствии с шириной страницы:

<div>
	<iframe src="http://player.vimeo.com/video/6929537"frameborder="0"></iframe>
</div>

.video {
	position: relative;
	padding-bottom: 56.25%;
	height: 0;
	overflow: hidden;
}
.video iframe,  
.video object,  
.video embed {
	position: absolute;
	top: 0;
	left: 0;
	width: 100%;
	height: 100%;
}

2. Максимальная и минимальная ширина (демо)

Max-width помогает определить максимально возможную ширину объекта. В примере ниже ширина div’а — 800 пикселей при возможности, но не более 90% ширины:

.container {
	width: 800px;
	max-width: 90%;
}

Так же можно масштабировать изображение:

img {
	max-width: 100%;
	height: auto;
}

Такая конструкция будет работать в IE 7 и IE 9, а для IE 8 делаем такой хак:

@media \0screen {
  img { 
  	width: auto; /* for ie 8 */
  }
}

Min-width — противоположность max-width, позволяет задать минимальную ширину объекта. В примере ниже благодаря min-width масштабируется текстовое поле:

3. Относительные значения (демо)

Если в адаптивной верстке использовать относительные значения в нужных местах, можно значительно сократить CSS код страницы. Ниже представлены примеры.

Относительный margin

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

Относительный размер шрифта

При использовании относительных значений (em или %) шрифта наследуются также относительные значения межстрочного пространства и отступов:

Относительный padding

На скриншоте ниже хорошо видно преимущества относительных значений padding перед абсолютными:

4.

Трюк с overflow:hidden (демо)

Можно очистить float от предыдущего элемента и оставить контент внутри контейнера, используя overflow:hidden, что бывает очень полезно в адаптивной разметке. Наглядно — в демо.

5. Перенос слов (демо)

При помощи CSS можно переносить непереносимые текстовые конструкции:

.break-word {
		word-wrap: break-word;
}

Адаптивная вёрстка — Блог HTML Academy

В чём разница между резиновой, адаптивной и отзывчивой вёрсткой? — спрашивают наши зрители Екатерина и Константин — как правильно их применять? Давайте разберёмся в отличиях подходов и попробуем сформулировать один общий вместо трёх.

Когда мобильного веба не было даже в самых смелых фантазиях, весь интернет был на десктопных компьютерах с небольшими экранами. Оптимизирован для разрешения 1024 на 768 и браузера Internet Explorer 5! — гордо писали тогда на сайтах. Но прошло время, экраны подросли и пришлось к этому как-то подстраиваться. Сначала это были просто резиновые таблицы: колонки по 25%, содержимое 50%, а в отдельной строке colspan=3 и распорка для минимальной ширины. Надеюсь, вы не поняли о чём я сечас говорил.

Резиновая вёрстка

Резиновая вёрстка — это когда вы задаёте всему макету и отдельным его частям не фиксированную ширину, а эластичную — в процентах. За исключением минимальной и максимальной ширины. Высоту в вебе в принципе не принято задавать — обычно она подстраивается под содержимое. Фикс или резина? — спрашивали верстальщики 2000-х про макет и втайне надеялись на второе, поинтереснее. Сейчас сложно представить, но когда-то это было прорывной идеей, которая усложнила вёрстку, но сделала первый шаг в правильном пути.

Таблицы для раскладки ушли, а резиновая вёрстка осталась. Если у вас эластичные флоаты, флексы… да хоть гриды! — это всё равно резиновая вёрстка. Но если ширина внешнего контейнера зафиксирована — это уже фикс, сколько бы ни было резины внутри. Чуть более универсальный фикс, но всё равно. В общем, главное чтобы сайт двигался так или иначе вместе с окном, а не торчал кирпичом где-то в центре или с краю.

Когда расширился круг устройств с интернетом и появились первые мобильные браузеры — встала задача как-то подстраиваться под них. Простая резина здесь уже не справлялась — нужно было переписывать стили. Одной из первых, в 2006 году появилась техника адаптивной раскладки Марка ван ден Доббельстина. В статье на A List Apart Марк предложил добавлять классы при загрузке или ресайзе окна и на каждый диапазон вешать стили. До первой реализации медиавыражений в Safari оставалось два года.

Адаптивная вёрстка

Когда в начале десятых годов появилось для чего адаптировать и чем адаптировать — мобильные браузеры и медиавыражения — вышли книги, давшие названия подходам: «Адаптивный веб-дизайн» Аарона Густавсона и «Отзывчивый веб-дизайн» Итана Маркота. Подходы Аарона и Итана продолжали идеи Марка, но с более современными технологиями и несколько отличались направлением мысли.

«Адаптивный веб-дизайн» Аарона предлагал гибко адаптировать сайты к возможностям устройств и браузеров. Важной частью этой философии был ненавязчивый JavaScript с прогрессивным улучшением — и всё это поверх семантической разметки. Хотя Аарон писал не совсем об этом, сегодня принято считать, что главное в адаптивной вёрстке — привязка к конкретным разрешениям и устройствам. Стили переключаются от одного брейкпоинта к другому, то есть у вас есть фиксированные макеты для iPad и iPhone, а то, что между ними вас не волнует.

Отзывчивая вёрстка

«Отзывчивый веб-дизайн» Итана ставил во главу три вещи: резиновый макет, гибкие картинки и медиавыражения. Все размеры и отступы Итан предлагал указывать в процентах с сумасшедшими дробями для точности. Отличительной чертой подхода стало плавное изменение сайта, с ориентацией не на конкретные устройства, а на содержимое. То есть ваш резиновый макет хорошо выглядит не только на iPhone и iPad, но и в любой точке между ними.

Чуть позже Итан сформулировал ещё один важный принцип в книге «Сначала мобильные». Если до тех пор отправной точкой для адаптации вёрстки служила десктопная версия, то он предложил перевернуть схему и начинать с мобильной версии, а потом её улучшать. Почему так? Потому, что усложнять простое проще, чем упрощать сложное. Вдуматесь! А ещё потому, что нет соблазна просто спрятать сложно адаптируемое и обделить мобильных пользователей.

Ну как, стало понятно?

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

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

Ну и как теперь верстать?

Просто! Сначала делаете мобильный резиновый макет, который хорошо вписывается в небольшие устройства. А когда размеры экрана или окна начинают расти — начинаете использовать появившееся пространство для улучшения интерфейса. Появляется боковая колонка, вторая, растут размеры картинок и подгружаются новые разрешения и так далее. То есть медиавыражения меняют стили не когда вы дошли до экрана самого модного телефона, а когда это нужно для содержимого сайта и удобства пользователя. Мы именно так и учим делать на интенсиве по продвинутой вёрстке.

Чтобы сделать хороший адаптивный сайт, нужно понимать много нюансов: вьюпорт, медиавыражения, адаптивные картинки и другое. Сегодня мы сделали первый шаг и разобрались с подходами: он оказывается всего один. Про остальное ещё поговорим!

• An Adaptive Layout Technique
• Adaptive Web Design
• Сначала мобильные!
• Отзывчивый веб-дизайн
• This Is Responsive

Создание адаптивных макетов | Jetpack Compose

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

В качестве декларативного инструментария пользовательского интерфейса Jetpack Compose хорошо подходит для проектирования и
реализация макетов, которые настраиваются для отображения контента по-разному
по самым разным размерам. Этот документ содержит некоторые рекомендации о том, как вы
можно использовать Compose, чтобы сделать ваш пользовательский интерфейс отзывчивым.

Сделать большие изменения компоновки для корневых составных объектов явно

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

Ключевые термины:

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

Избегайте использования физических аппаратных значений для принятия решений о компоновке. Возможно
быть заманчивым принимать решения, основанные на фиксированной материальной ценности (является ли устройство
планшет? Имеет ли физический экран определенное соотношение сторон?), но
ответы на эти вопросы могут оказаться бесполезными для определения пространства вашего
Пользовательский интерфейс может работать с.

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

Вместо этого вы должны принимать решения, основываясь на реальной части экрана.
выделенное вашему приложению, например, текущие метрики окна, предоставленные
библиотека Jetpack WindowManager. Увидеть
как использовать WindowManager в приложении Compose, ознакомьтесь с примером JetNews.

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

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

 класс перечисления WindowSizeClass {Компактный, Средний, Расширенный}
@составной
весело MyApp (windowSizeClass: WindowSizeClass) {
    // Выполняем логику над классом размера, чтобы решить, показывать ли
    // верхняя панель приложения.
    val showTopAppBar = WindowSizeClass != WindowSizeClass.Compact
    // MyScreen ничего не знает о размерах окон и выполняет логику
    // на основе логического флага.
    Мой Экран(
        showTopAppBar = показатьTopAppBar,
        /* . .. */
    )
}
 

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

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

Составные элементы можно использовать повторно, если их можно размещать в различных местах.
места. Если составной объект предполагает, что он всегда будет помещен в определенное
местоположение с определенным размером, то будет сложнее повторно использовать его в другом месте в
в другом месте или с другим доступным пространством. Это также
означает, что некорневых, многократно используемых компонуемых элементов следует избегать неявной зависимости
на «глобальной» информации о размере .

Давайте рассмотрим пример: представьте себе вложенный компонуемый объект, который реализует
макет списка-подробности,
который может отображать одну панель или две панели рядом друг с другом.

Снимок экрана приложения, показывающий типичный макет списка/деталей. 1 это список
area, 2 — область деталей.

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

 @Composable
весело AdaptivePane(
    showOnePane: логическое значение,
    /* ... */
) {
    если (showOnePane) {
        Одна панель (/* ... */)
    } еще {
        Две панели (/* ... */)
    }
}
 

Что, если вместо этого мы хотим, чтобы компонуемый объект самостоятельно менял свой макет в зависимости от доступного места? Например, карта, которая хочет показать дополнительные детали, если позволяет место. Мы хотим выполнить некоторую логику на основе некоторого доступного размера, но какого конкретно размера?

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

Поскольку компонуемый объект не является компонуемым на корневом уровне, мы также не должны использовать
текущие метрики окна напрямую, чтобы максимизировать возможность повторного использования. Если
компонент размещается с отступом (например, для вставок) или если есть
такие компоненты, как навигационные панели или панели приложений, количество места, доступного для
компонуемый может значительно отличаться от общего пространства, доступного для
приложение.

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

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

Если вы хотите изменить то, что вы показываете , вы можете использовать BoxWithConstraints в качестве
более мощная альтернатива. Этот составной обеспечивает измерение
ограничения
которые вы можете использовать для вызова различных составных объектов на основе пространства
это доступно. Однако за это приходится платить, так как Коробка с ограничениями
откладывает композицию до фазы макета, когда эти ограничения известны,
заставляя выполнять больше работы во время компоновки.

 @Составной
веселая карта(/* ... */) {
    BoxWithConstraints {
        если (maxWidth < 400.dp) {
            Столбец {
                Изображение(/* ... */)
                Заголовок(/* ... */)
            }
        } еще {
            Строка {
                Столбец {
                    Заголовок(/* . .. */)
                    Описание(/* ... */)
                }
                Изображение(/* ... */)
            }
        }
    }
}
 

Убедитесь, что все данные доступны для разных размеров

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

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

 @Составной
прикольная карта(
    URL-адрес изображения: строка,
    название: Строка,
    описание: Строка
) {
    BoxWithConstraints {
        если (maxWidth < 400. dp) {
            Столбец {
                Изображение (URL-адрес изображения)
                Название (название)
            }
        } еще {
            Строка {
                Столбец {
                    Название (название)
                    Описание (описание)
                }
                Изображение (URL-адрес изображения)
            }
        }
    }
}
 

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

Постоянная передача данных упрощает адаптивные макеты, делая их менее зависимыми от состояния,
и позволяет избежать побочных эффектов при переключении между размерами (что может
произойти из-за изменения размера окна, изменения ориентации или складывания и развертывания
устройство).

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

 @Composable
прикольная карта(
    URL-адрес изображения: строка,
    название: Строка,
    описание: Строка
) {
    var showMore запомнить { mutableStateOf(false) }
    BoxWithConstraints {
        если (maxWidth < 400.dp) {
            Столбец {
                Изображение (URL-адрес изображения)
                Название (название)
            }
        } еще {
            Строка {
                Столбец {
                    Название (название)
                    Описание(
                        описание = описание,
                        показать больше = показать больше,
                        onShowMoreToggled = { новое значение ->
                            показать больше = новое значение
                        }
                    )
                }
                Изображение (URL-адрес изображения)
            }
        }
    }
}
 

Подробнее

Чтобы узнать больше о настраиваемых макетах в Compose, см. следующие дополнительные
Ресурсы.

Примеры приложений

• JetNews.
  показывает, как разработать приложение, которое адаптирует свой пользовательский интерфейс для использования доступного пространства

Видео

• Создание пользовательского интерфейса Android для экрана любого размера

Адаптивный и адаптивный дизайн и ключевые аспекты

Иллюстрация Кайла Вебстера

В чем разница между адаптивным и адаптивным дизайном?

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

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

Изображение предоставлено сообществом SAP UX.

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

«Точки останова» — это термин, обычно используемый для обозначения различных размеров экрана, используемых в адаптивном дизайне. Например, целевая страница веб-сайта будет создана для просмотра на мобильном устройстве, планшете и компьютере. Это 3 точки останова, которые показывают, как будет адаптироваться дизайн. Поэтому вам не нужно проектировать для конкретных устройств, но вы можете настроить шаблон для определенной группы устройств.

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

Дизайн для различных устройств

Дизайн цифровых продуктов постоянно меняется. Постоянно появляются новые достижения, которые влияют на пользовательский опыт и трансформируют отрасли. Недостаточно просто учитывать разные размеры экрана. Мы должны учитывать устройство и то, как с ним взаимодействуют. От различных операционных систем и их встроенной функциональности до среды, в которой пользователь взаимодействует с устройством. Все это может повлиять на восприятие дизайна пользователем.

Различные устройства предоставляют услуги по-разному в зависимости от контекста. Проектирование, обеспечивающее одинаковое взаимодействие с пользователем на разных устройствах, может быть сложной задачей. Контекст, в котором используется устройство, может повлиять на проектные решения. Например, планшет в основном используется для потребления контента, тогда как настольный компьютер обычно используется в качестве инструмента для более сложных рабочих процессов, таких как редактирование видео или ввод данных. Чтобы создать лучший опыт для пользователя, важно разработать эффективные стратегии.

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

Рекомендации по межплатформенному дизайну

При разработке цифровых продуктов важно учитывать возможность использования различных функций устройств. Мобильные устройства могут использовать такие функции, как GPS, биометрический идентификатор, сканирование банковских карт и считывание QR-кода, которые могут значительно улучшить UX.

Жесты

Изображение предоставлено Powermockup.

Мобильные устройства и планшеты позволяют пользователям взаимодействовать с контентом уникальным способом. Возможность сжимать, масштабировать, перемещать изображения по экрану и принудительно касаться элементов позволяет пользователю по-новому взаимодействовать с контентом. Длинная повторяющаяся строка контента может отлично смотреться на настольном компьютере, но для мобильного устройства может быть более целесообразно позволить пользователю прокручивать карусель один за другим. Также важно подумать о размере пальца человека и о том, как это отражается на мобильных взаимодействиях. Элементы пользовательского интерфейса должны быть удобного размера. Если пользователь изо всех сил пытается выбрать или коснуться элемента, это может привести к разочарованию.

Иерархия

Изображение предоставлено Райаном Джонсоном.

При проектировании для разных устройств дизайнер всегда должен смотреть на иерархию компоновки. Мобильные приложения имеют ограниченное пространство. Дизайнер хочет, чтобы ключевые сообщения сохраняли одинаковую значимость на всех устройствах. Важно спросить, какое самое важное действие на странице. Если призывом к действию на странице является кнопка регистрации, убедитесь, что она отображается на всех устройствах.

Навигация

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

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

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

Изображение предоставлено Крисом Баннистером.

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

Вкладки

Изображение предоставлено Адрианом Гойей.

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

Значки меню

Изображение предоставлено Flip Justic.

Гамбургер-меню часто можно найти на мобильных устройствах, хотя оно становится все более популярным и на настольных веб-приложениях. Значок меню гамбургера состоит из 3 строк, и его можно щелкнуть или коснуться, чтобы открыть дополнительные параметры навигации.

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

Заключение

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

This entry was posted in Популярное