таб бар в приложении это

Мобильные паттерны навигации

Как делать правильно и удобно

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

Начинающие свой путь в гуях и уиксах дизайнеры натыкаются на нее родимую сразу, а читать гайдлайны (где тоже про навигацию отведено где-то около 1/50 всего объема) никогда не было модно. Как и инструкцию от бытовой техники… Ну да Бог с ними, с гайдами, все равно потом прочтете и не один раз.

Какие паттерны бывают?

Как таковых, паттернов навигации не то чтобы вон как много. Давайте их перечислим:

Но прежде чем рассмотреть каждый из них, давайте разберемся с понятием “Погружение”.

Иерархия

Пользователь путешествует по аппу при помощи погружения внутрь (вниз по иерархии). Также этот термин зовут Pushin, drill down. Суть название не меняет ибо в 99.9% случаев в мобильных аппах навигация погружная.

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

Схематично выглядит это примерно так:

А теперь обратите внимание: слева на страницах “ООО “Рога и копыта” и “Профиль” есть стрелочка-кнопочка “Назад”! Тапнув по ней наш герой “поднимается” на уровень выше.

И самое главное! Кто заметил, что на главной странице “Контрагенты” нет кнопочки-стрелочки “Назад”?

Молодец, дорогой читатель, ее там просто НЕ МОЖЕТ БЫТЬ потому что подняться на уровень выше мы не сможем ибо некуда уже.

Это было просто. Но не все это понимают, к сожалению. Кстати, уровней иерархии может быть бесконечно много, но все же стоит спроектировать систему так, чтобы пользователь не мог гулять на 20 уровней иерархии вглубь аппа. 5–6 уровней вложенности будет за глаза иначе пользователь в какой-то момент гарантированно потеряется и будет страдать.

Источник

Базовые модели мобильной навигации

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

В своей статье Ник Бабич, специалист по разработке мобильных приложений и UX дизайну, рассматривает три базовых модели навигации — меню-гамбургер, Tab bar и управление жестами — и описывает их сильные и слабые стороны.

Меню-гамбургер

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

Как видите, собственно меню скрыто за иконкой.

Большое количество вариантов навигации. Главное преимущество навигационного меню в том, что с его помощью можно уместить большое количество вариантов на маленьком участке.

Аккуратный дизайн. Освободите место на экране, перенеся все варианты с него на боковое меню.

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

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

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

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

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

Если у вас небольшое количество пунктов меню с высоким приоритетом, подумайте о том, чтобы перенести их во вкладки или на Tab bar.

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

Tab bar

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

В Твиттере Tab bar позволяет пользователю переходить непосредственно на экран, связанный с выбранным объектом.

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

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

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

Логика и расположение панели вкладок у iOS и Android отличаются. У каждой из этих платформ свои правила и рекомендации, касающиеся UI и юзабилити; их следует принимать во внимание, создавая Tab bar для того или иного устройства. Панель может находиться в верхней (преимущественно на Android) или нижней (преимущественно на iOS) части страницы. Кроме того, на iOS нижняя панель часто используется, чтобы переключаться между экранами приложения. На Android же, напротив, принято отображать вкладки для визуального управления сверху. К тому же на нижнюю панель иногда выводятся действия.

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

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

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

Управление жестами

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

Жесты быстро приобрели популярность среди дизайнеров; появилось множество приложений, которые экспериментировали с управлением жестами.

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

Tinder совершил переворот в своей индустрии при помощи жеста swipe, который стал практически визитной карточкой продукта. У людей это приложение ассоциируется с «проведите вправо» и «проведите влево».

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

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

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

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

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

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

Источник

Как реализовать таб-бар с нестандартной кнопкой: CAShapeLayer и UIResponderChain

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

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

Представленный способ ориентирован на начинающих iOS-разработчиков.

Стандартная реализация

Подготовка

Отнаследуемся от UITabBarController вместо UIViewController :

В файле Main.storyboard у TabBarController укажем класс MainTabBarController :

В классе MainTabBarController создадим константу диаметра средней кнопки (по дизайну он равен 42), константы для цветов, с которыми предстоит работать, и свойство самой кнопки:

Создадим UIImageView для отображения иконки сердца внутри кнопки.

Объявим метод makeUI() для построения интерфейса:

Рассмотрим подробнее, что происходит в данном методе:

2. Активируем констрейнты для middleButton :

2.1. Фиксируем высоту и ширину в соответствии с дизайном;

2.2. Фиксируем центр по оси x и отступ от верхней границы: по дизайну кнопка выступаем над таб-баром на 10 пикселей.

3. Активируем констрейнты для heartImageView :

3.1. Фиксируем высоту и ширину в соответствии с дизайном;

Вызовем метод makeUI() в методе viewDidLoad() класса MainTabBarController :

Скомпилируем и запустим проект. У нас должно получиться следующее:

Работа с CAShapeLayer

В файле Main.storyboard выберем таб-бар на MainTabBarController и укажем, что он будет реализован классом CustomTabBar :

Внутри класса CustomTabBar объявим вычисляемые свойства для работы с таб-баром, а также константу для радиуса полукруга обводки:

Объявим метод для вычисления границ обводки таб-бара, который будет возвращать CGPath – буквально путь, по которому мы будем двигаться, рисуя обводку:

Рассмотрим подробнее, что происходит в данном методе:

Перемещаемся в точку начала системы координат, которая всегда находится в левом верхнем углу.

Добавляем линию в точку, которая соответствует правому верхнему углу таб-бара.

Добавляем линию в точку, которая соответствует правому нижнему углу таб-бара.

Добавляем линию в точку, которая соответствует левому нижнему углу таб-бара.

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

Аналогичным способом получим CGPath для обводки полукруга:

Рассмотрим подробнее, что происходит в данном методе:

Указываем радиус полукруга.

Указываем начальный угол.

Указываем конечный угол.

Указываем направление отрисовки полукруга – по часовой стрелке.

Объявляем константу shapeLayer типа CAShapeLayer для создания слоя обводки по периметру таб-бара. У нее указываем путь, цвет обводки, цвет заливки и ширину линии.

Сохраняем созданные слои в соответствующие свойства класса.

Данный метод будем вызывать в переопределяемом методе draw(_:) нашего класса:

Для тестирования вернемся в класс MainTabBarController и добавим следующий код в метод makeUI() :

Скомпилируем и запустим проект. У нас получилось воспроизвести задуманный дизайн:

Здесь можно увидеть довольно простую логику:

Фиксируем позицию нажатой кнопки.

Если да, меняем цвет кнопки на зеленый.

Если нет, меняем цвет кнопки на красный.

UIResponderChain

На данном этапе кажется, что цель достигнута, но мы можем заметить два интересных момента:

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

Почему же так происходит?

Что же делать с нажатием на область кнопки, которая выступает за границу таб-бара?

Проход по иерархии view реализован с помощью метода hitTest(_:with:)

UIKit uses view-based hit-testing to determine where touch events occur. Specifically, UIKit compares the touch location to the bounds of view objects in the view hierarchy. The hitTest(_:with:) method of UIView traverses the view hierarchy, looking for the deepest subview that contains the specified touch, which becomes the first responder for the touch event.

Returns a Boolean value indicating whether the receiver contains the specified point.

При этом официальная документация Apple гласит:

If a touch location is outside of a view’s bounds, the hitTest(_:with:) method ignores that view and all of its subviews.

То есть проход мы начнем не с subview таб-бара (круглая кнопка), а с корневой UIView ViewController ‘a, которая, естественно, никак не обработает касание, как и остальные объекты UIResponder в иерархии.

Чтобы обработать касание на части круглой кнопки, которая находится за пределами таб-бара, нам необходимо переопределить метод point(inside:with:) в классе CustomTabBar :

Здесь происходит следующее:

1. Проверяем, находится ли точка касания в границах ( bounds ) таб-бара (в нашем случае получаем false ).

2. Если касание произошло вне bounds таб-бара:

2.1. Проходимся по всем subview таб-бара.

2.3. Если касание произошло внутри subview :

2.3.1. Возвращаем true – subview может обработать касание.

Чтобы наша кнопка выполнила некое действие при обработке касания, вернемся в класс MainTabBarController и добавим следующую строку в замыкание, возвращающее middleButton :

Рассмотрим входные параметры метода addTarget(_:action:for:) :

target – в рамках этого объекта произведем поиск метода, который будет вызван при нажатии на кнопку;

action – selector метода, который будет вызван;

controlEvents – событие, при котором произойдет вызов метода.

Готово, мы получили полноценно функционирующую круглую кнопку в центре таб-бара.

Источник

Таб бар в приложении это

A tab bar appears at the bottom of a screen, helping people understand the types of information or functionality an app provides. Tabs let people quickly switch between top-level sections in your app while preserving the current navigation state within each section.

By default, a tab bar is translucent: It uses a background material only when content appears behind it, removing the material when the view scrolls to the bottom. A tab bar hides when a keyboard is onscreen.

The Photos tab bar uses a background material to distinguish itself while letting underlapping content show through.

When no content appears behind the tab bar, the background material doesn’t appear.

Depending on device size and orientation, the number of visible tabs can be smaller than the total number of tabs. If horizontal space limits the number of visible tabs, the trailing tab becomes a More tab, revealing the remaining items in a list on a separate screen.

For developer guidance, see UITabBar.

TIP Although tab bars and toolbars both appear at the bottom of a screen, each has a different purpose. A tab bar lets people navigate among different areas of an app, such as the Alarm, Stopwatch, and Timer tabs in the Clock app. A toolbar contains buttons for performing actions related to the screen, such as creating an item, filtering items, or marking up content. Tab bars and toolbars don’t appear together in the same view.

Use a tab bar only to enable navigation, not to help people perform actions. If you need to provide controls that act on elements in the current view, use a toolbar instead.

Use the minimum number of tabs required to clarify your information hierarchy and help people navigate your app. Too many tabs reduce the tappable area of each tab and might increase the complexity of your interface. Too few tabs can lead to categories or modes that are too broad to be useful, requiring people to select a tab to find out what it contains. Although a More tab displays additional tabs, it requires an extra tap to reveal them and can be a poor use of space. In general, use three to five tabs on iPhone; use a few more on iPad if necessary.

In an iPadOS app, consider using a sidebar instead of a tab bar. Because a sidebar can display a large number of items, it can make navigating an iPad app more efficient. You can also let people customize a sidebar’s items and let them hide it to make more room for content. For guidance, see Sidebars.

Avoid hiding the tab bar when people navigate to different areas in your app. The tab bar is a global navigation control for your app, so make sure it’s always visible. The exception is a tab bar within a modal view. Because a modal view gives people a separate experience that they dismiss when they’re finished, hiding the view’s tab bar doesn’t affect app navigation.

Avoid removing or disabling a tab when its content is unavailable. If tabs are enabled in some cases but not in others, your app’s interface might appear unstable and unpredictable. When necessary, explain why a tab’s content is unavailable. For example, even when there is no music on an iOS device, the Listen Now tab in the Music app remains available and offers suggestions for downloading music.

Ensure that tabs affect the view that’s attached to the tab bar, not views elsewhere onscreen. For example, selecting a tab on the left side of a split view shouldn’t cause the right side of the split view to change. Similarly, selecting a tab in a popover shouldn’t change a view behind the popover.

Use a badge to communicate unobtrusively. You can display a badge — a red oval containing white text and either a number or an exclamation point — on a tab to indicate that new information associated with that view or mode is available. For developer guidance, see UITabBarItem.

Consider using SF symbols to provide scalable, visually consistent tab bar items. When you use SF symbols, tab bar items automatically adapt to different contexts. For example, the tab bar can be regular or compact, depending on the current device and orientation. Also, tab bar glyphs can appear above tab titles in portrait orientation, whereas in landscape, the glyphs and titles can appear side by side. Prefer filled symbols or glyphs for consistency with the platform. If your app uses a sidebar instead of a tab bar when it runs on iPad, switch the filled symbols or glyphs to the outlined variant in the sidebar. For guidance, see SF Symbols.

If you need to create custom tab bar glyphs, create each glyph in two sizes so that the tab bar looks good in both regular and compact environments. Use the following metrics when creating tab bar glyphs in different shapes. For guidance, see Glyphs.

Target width and height (circular glyphs)

Target width and height (square glyphs)

Target width (wide glyphs)

Target height (tall glyphs)

Источник