В течение этого времени я в основном занимался публикацией в веб-среде. У меня был опыт работы с адаптивным веб-дизайном, но впервые я полностью приступил к созданию и реализации UI в мобильной среде.
В мобильной среде необходимо учитывать не только структуру макета, но и различные элементы, такие как способ ввода пользователя, метод расчета высоты экрана, обработка прокрутки и доступность. Особенно часто способы, которые использовались в вебе, не могут применяться в мобильной среде, что было процессом постоянного изучения новых стандартов.
Первое отличие, которое я отметил в мобильной среде, было связано с способом ввода пользователя. В веб-среде взаимодействие, основанное на мыши, делает использование состояния hover очень обычным.
.button:hover{
background-color: #f5f5f5;
}Состояние hover предоставляет визуальную обратную связь, когда пользователь наводит курсор на элемент, и является важным элементом взаимодействия в настольном UI. Однако в мобильной среде мышь отсутствует, и все вводимое происходит на основе касания. В результате состояние hover фактически не работает или работает очень ограниченно на мобильных устройствах. Поэтому в мобильных интерфейсах обычно строится UI на основе активного состояния или состояния выбора, а не состояния hover.
.button:active{
background-color: #f5f5f5;
}Из этого различия стало очевидно, что даже с одинаковым UI проектировка состояния может радикально отличаться в зависимости от способа ввода. Важно не просто изменить стиль, а заново определить состояние UI на основе поведения пользователя.
Согласованные различия можно было также заметить при использовании чекбоксов и радиокнопок. В веб-среде достаточно просто кликнуть на маленькие элементы управления, но в мобильной среде точность касания играет важную роль. Так как управление пальцем означает, что если область, на которую можно кликнуть, недостаточно велика, пользовательский опыт быстро ухудшается. Особенно если доступна только маленькая область для клика, как у чекбокса, вероятность неправильно выполненных действий возрастает. Для решения этой проблемы используется способ объединения чекбокса и метки в одну кликабельную область.
<FormControlLabel
control={<Checkbox />}
label="자동 로그인"
/>Эта структура не только расширяет площадь касания, позволяя выбирать метку вместе с чекбоксом, но и обеспечивает эффект расширения зоны касания. В результате пользователи могут выполнять одно и то же действие по большему пространству, и точность UI увеличивается вместе с пользовательским опытом.
При работе с мобильным UI структура Bottom Sheet также являлась одним из важных паттернов. Bottom Sheet — это панель UI, которая появляется снизу экрана, и часто используется в мобильной среде.
В вебе чаще используют модальные окна, отображаемые в центре, но на мобильных устройствах нижняя часть экрана считается зоной с наибольшей доступностью для пальцев. По этой причине функции, такие как выбор опций, фильтры, входные формы и загрузка файлов, часто предлагаются в виде Bottom Sheet.
Кроме того, Bottom Sheet может предоставлять функциональность без перехода к полному экрану, что дает пользователю возможность выполнять дополнительные действия, сохраняя текущий контекст. Это является очень важным элементом в мобильном UX.
<Изображение Bottom Sheet, используемое в проекте Панель капитана>
В процессе реализации макета концепция Safe Area также стала важным элементом. В последние годы мобильные устройства обычно используют весь экран, и поэтому существует физическая UI-область сверху и снизу.
Вверху располагается область выреза (Notch), где находятся камера и сенсоры, а внизу находится индикатор домашней кнопки (Home Indicator) для жестов. Эти области классифицируются как зоны, в которые содержимое не должно вторгаться.
Таким образом, при разработке мобильного UI необходимо обязательно учитывать полосу для Safe Area.
.mobile-layout{
padding-top: var(--safe-area-top);
}Если не учитывать Safe Area, контент может перекрываться UI устройства, что ухудшит читаемость или некоторые элементы могут быть скрыты. Особенно это влияние становится более очевидным в среде iOS.
Способы обработки высоты экрана также были одним из важных отличий между вебом и мобильными устройствами.
В вебе обычно высота экрана формируется следующим образом:
html,
body,
#root{
height: 100%; // 또는 height: 100vh;
}height: 100% рассчитывается на основе высоты родительского элемента, тогда как 100vh рассчитывается на основе высоты вьюпорта (Viewport). Вьюпорт — это область экрана, которую пользователь в данный момент видит. То есть это становится основой для фактически видимой области на экране. Однако в мобильной среде адресная строка, нижняя панель и т.д. динамически появляются и исчезают, что постоянно изменяет фактически доступную высоту экрана. Это может привести к проблеме, при которой 100vh не полностью соответствует фактическому экрану. Для решения этой проблемы в настоящее время обычно используется единица dvh (Динамическая высота вьюпорта).
html,
body,
#root{
height: 100dvh;
}dvh учитывает изменения пользовательского интерфейса браузера и рассчитывает фактически доступную высоту экрана, что позволяет более стабильно формировать макет в мобильной среде. Особенно это играет важную роль в макете со скроллом, уменьшая шатания макета.
Действие скролла также было одним из важных элементов в мобильной среде.
.mobile-content{
overflow-y: auto;
-webkit-overflow-scrolling: touch;
overscroll-behavior: contain;
}Особенно -webkit-overflow-scrolling: touch — это свойство для применения инерционного скролла в среде iOS. При применении этой настройки, когда пользователь быстро прокручивает и затем отпускает палец, возникает эффект плавного продолжения скролла. Это важная настройка для реализации поведения, схожего с опытом скролла в нативных приложениях, и в веб-среде. Плавность скролла в мобильном UX непосредственно влияет на пользовательский опыт, поэтому она имеет значение, превышающее простые стилистические свойства.
Единица шрифта также была структурно изменена с учетом мобильной среды. Изначально шрифты в коде определялись единицей px в соответствии с определенными дизайн-токенами.
$fz-10: 10px;
$fz-11: 11px;
$fz-12: 12px;
…px — интуитивно понятная и простая в использовании единица, но это абсолютная единица. В мобильной среде размер шрифта пользователя может изменяться в зависимости от настроек доступности, поэтому более уместно использовать относительные единицы.
В проекте была разработана утилита, которая позволяет единообразно преобразовывать различные размеры шрифтов, определенные в дизайн-токенах, в rem.
// rem 변환 함수 정의(Base size: 16px 기준)
@function rem($px) {
@return math.div($px, 16px) * 1rem;
}
$fz-10: rem(10px);
$fz-11: rem(11px);
$fz-12: rem(12px);
$fz-13: rem(13px);
…Это не просто преобразование единиц, а структурный подход для поддержания согласованности в стилистической системе, основанной на дизайн-токенах.
Преимущества следующие.
Во-первых, можно поддерживать дизайн-токены в пикселях, но при этом единообразно использовать rem в самом коде.
Во-вторых, логика преобразования единиц сосредоточена в одной функции, что улучшает поддержку и обслуживание.
В-третьих, это сокращает вероятность случайного написания неправильно рассчитанных единиц.
В-четвертых, это позволяет гибко реагировать на изменения в настройках доступности или на изменение базового шрифта в будущем.
В конфигурации макета также произошли важные изменения.
В вебе часто высота элементов карточек или списков устанавливается как фиксированное значение.
.card{
height: 120px;
}Однако в мобильной среде размер шрифта или длина контента могут изменяться в зависимости от настроек пользователя. Фиксированная высота может привести к обрезанию текста или разрушению макета. Поэтому для мобильных устройств более подходящей является структура, которая естественно расширяется на основе отступов и потока контента, вместо фиксированной высоты.
.card{
padding: 16px;
}Этот подход может более гибко реагировать на различные размеры экрана и изменения контента, а также предлагает стабильную структуру с точки зрения обслуживания.
Главная мысль, которую я отметил в этом опыте мобильной верстки, заключается в том, что мобильная среда — это не просто уменьшенная версия веба. Необходимы совместные соображения таких факторов, как способ ввода, структура макета, способ расчета высоты экрана, поведение прокрутки и методы доступности, и можно подтвердить, что каждый из этих факторов прямо влияет на пользовательский опыт.
В будущем я хочу расширить свой опыт, чтобы реализовать более стабильный и последовательный интерфейс пользователя, учитывая разнообразные условия устройств.
KKAMJJING