Стили кнопок: Buttons Основные стили кнопок CSS уроки для начинающих академия

Как избежать типичных ошибок в дизайне кнопок — Дизайн на vc.ru

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

882 просмотров

Далее текст от лица автора

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

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

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

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

Распространенные ошибки при проектировании кнопок

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

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

Группа кнопок 1

Чтобы помочь людям со слабым зрением различать компоненты интерфейса (например, границы полей формы для заполнения, кнопки и вкладки), сделайте так, чтобы коэффициент контрастности цветов был не менее 3:1. Декоративные стили, которые не нужны для выделения компонентов интерфейса, могут иметь более низкий коэффициент контрастности.

В данном примере коэффициент контрастности заливки вторичной кнопки («Secondary») по отношению к фону составляет менее 3:1. Это слишком мало для того, чтобы люди со слабым зрением могли чётко видеть форму кнопки. Кто-то может возразить, что заливка вторичной кнопки — декоративная и ей необязательно соответствовать коэффициенту контрастности 3:1, чтобы быть доступной. Но я считаю, что заливка необходима для того, чтобы пользователь мог идентифицировать вторичную кнопку как интерактивный элемент. Без заливки это просто обычный синий текст, единственной характеристикой которого является цвет. Мы можем добавить обводку к вторичной кнопке, чтобы решить эту проблему.

Группа кнопок 2

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

Группа кнопок 3

Для того, чтобы широкая аудитория могла прочитать мелкий текст (18 px и меньше), коэффициент контрастности цветов должен составлять не менее 4,5:1.

Проблемы со стилями кнопок в этом примере:

• Коэффициент контрастности текста вторичной кнопки слишком низкий, а должен быть не менее 4,5:1, чтобы обеспечить доступность восприятия
• Главная («Primary») и вторичная кнопки конфликтуют из-за схожего стиля и недостаточного контраста. Это нарушает визуальную иерархию, и пользователю будет непонятно, какое действие наиболее важное. Поскольку у кнопок одинаковый стиль, для того, чтобы они чётко отличались друг от друга, необходимо применить коэффициент контрастности, равный не менее 3:1

Группа кнопок 4

В этом примере у стилей кнопок есть проблемы, аналогичные тем, которые мы рассмотрели в предыдущем примере:

• Пользователь может ошибочно принять вторичную кнопку за неактивную из-за её заливки светло-серого цвета
• Коэффициент контрастности текста вторичной кнопки слишком низкий, а чтобы обеспечить доступность восприятия, он должен быть не менее 4,5:1
• Главная и вторичная кнопки также конфликтуют из-за схожего стиля и недостаточного контраста

Группа кнопок 5

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

Коэффициент контрастности между кнопками — единственный способ отличить их друг от друга, но в данном случае он слишком низкий (контрастность должна быть не менее 3:1). Кнопки должны иметь чёткую визуальную иерархию, которая зависит не только от цвета.

Группа кнопок 6

Здесь присутствуют те же проблемы со стилями кнопок, что и в примере выше:

• Стили кнопок слишком похожи по контрасту и стилю, поэтому слабовидящие люди не смогут отличить их друг от друга
• Коэффициент контрастности обводки третичной кнопки («Tertiary») должен быть не менее 3:1, чтобы пользователи без труда считывали её и чётко идентифицировали как интерактивный элемент

Группа кнопок 7

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

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

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

Группа кнопок 8

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

Группа кнопок 9

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

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

Советы по дизайну кнопок

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

• Придерживайтесь чёткой визуальной иерархии в дизайне кнопок, которая зависит не только от цвета
• Используйте коэффициент контрастности между цветом кнопки и цветом фона вокруг неё, равный не менее 3:1, чтобы люди могли идентифицировать её как интерактивный элемент
• Применяйте коэффициент контрастности текста кнопки, равный не менее 4,5:1, чтобы он отвечал требованиям доступности WCAG 2.0 уровня AA
• Если вы сделали кнопки в одинаковом стиле, придерживайтесь коэффициента контрастности между ними, равного не менее 3:1, чтобы люди с ослабленным зрением могли отличить их друг от друга
• Проектируйте достаточно большую область нажатия (не менее 48 px), чтобы пользователи могли с лёгкостью нажимать на кнопки
• Убедитесь, что между кнопками достаточно места, чтобы люди по ошибке не нажали не ту кнопку. Как правило, для перестраховки я использую интервал, равный 16 px

Предложение по улучшению дизайна кнопок

Я предлагаю использовать следующие стили кнопок. Пользователи знакомы с ними, они доступны для восприятия и имеют чёткую визуальную иерархию, которая зависит не только от цвета.

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

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

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

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

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

Все, что вам нужно знать о дизайне кнопок в интерфейсе

Все, что вам нужно знать о дизайне кнопок, одном из основных интерактивных строительных блоков интерфейса

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

«Вы нажимаете кнопку, а мы делаем все остальное», – так, посредством броского и четкого слогана, Kodak обратились к потенциальным покупателям своих фотоаппаратов.

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

Кнопки vs Ссылки

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

• Ссылки используются при переходе в другое место, например: страница «просмотреть все», страница профиля и т. д.
• Кнопки используются при выполнении действия, например: «отправить», «объединить», «создать новый», «загрузить» и т. д.

Состояние кнопки сообщает ее статус пользователю

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

Normal — сообщает, что компонент интерактивен и включен.

Focus — сообщает, что пользователь выделил элемент, используя клавиатуру или другой метод ввода.

Hover — сообщает, когда пользователь навел курсор на интерактивный элемент.

Active — Активное или нажатое состояние сообщает о том, что пользователь нажал на кнопку.

Progress/Loading — используется, когда действие не выполняется немедленно и сообщает, что компонент находится в процессе завершения действия.

Disabled — сообщает, что компонент в настоящее время не является интерактивным, но может быть включен в будущем.

Кнопки бывают разных цветов, форм и размеров

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

Стили сообщают о важности действия

Стили в основном используются для отличия более важных действий от менее важных. Создайте иерархию действий, которая будет направлять пользователя там, где есть множество вариантов. Обычно у вас может быть одна заметная кнопка (этот стиль часто называется «основной»), несколько средних «второстепенных» и слабо заметных «третичных» действий.

Иногда нет кнопки «по умолчанию»

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

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

Не заставляйте меня думать

«Не заставляй меня думать» – это название книги юзабилити-инженера Стива Круга. Один из многих моментов, которые он затрагивает – насколько важно сделать интерфейс понятным для пользователей, а не создавать головоломки или лабиринты. Опираясь на многолетний опыт использования различных устройств и других продуктов, мы сформировали определенное ожидание, как кнопки выглядят и функционируют. Значительное отклонение от того, что считается «стандартным», вызовет задержку и замешательство у пользователей.

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

Согласованность повышает скорость и точность

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

— Якоб Нильсен

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

Сделайте кнопки достаточно большими для надежного взаимодействия

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

Для большинства платформ рассмотрите возможность создания сенсорных целей как минимум 48 x 48 dp. Сенсорная цель такого размера дает физический размер около 9 мм, независимо от размера экрана. Рекомендуемый целевой размер для сенсорных элементов составляет не менее 7–10 мм.

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

Проектируйте для доступности

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

Дизайнеры должны тесно сотрудничать с командами разработчиков, чтобы убедиться, что кнопки работают с программами чтения с экрана. Роль кнопки должна использоваться для кликабельных элементов, которые запускают ответ при активации пользователем. Добавление role=”button” приведет к тому, что элемент отобразится для программы чтения с экрана, как элемент управления кнопками.

Жесты становятся достаточно широко распространенными

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

Хорошая метка кнопки приглашает пользователей действовать

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

Хорошая метка кнопки приглашает пользователей действовать. Лучше всего использовать глаголы и пометить кнопку тем, что она на самом деле делает. Как будто кнопка спрашивает пользователя: «Вы хотите (добавить в корзину)?» или «Хотите (подтвердить заказ)?».

Избегайте использования «Да», «Нет» или слишком общих меток, таких как «Отправить».

Ok/Cancel или Cancel/Ok? Оба варианта хороши

Оба варианта – идентичны, и дизайнеры могут часами спорить о своих предпочтениях.

• Размещая на первом месте действие OK, вы поддерживаете естественный порядок чтения. Это может помочь сэкономить время, если мы знаем, что, скорее всего, именно это и выберет пользователь. Windows ставит ОК на первое место.
• Размещая кнопку OK в конце, вы улучшаете юзерфлоу. Кто-то может поспорить, что OK, как кнопка «Следующий», переместит пользователя вперед. Если поставите OK в конце, вы поможете пользователям оценить все варианты, прежде чем предпринимать действия, и поможете избежать ошибок и поспешных решений. Apple ставит ОК на последнее место

Любой из вариантов имеет аргументы в свою пользу, и ни один из этих вариантов не приведет к катастрофическим последствиям для юзабилити. Я в основном ставлю ОК в списке действий на последнее место. Например, в диалоговом окне (возможно, потому что я преимущественно использую Mac).

Отключенные кнопки — отстой

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

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

О каких компонентах вы хотели бы узнать в следующей статье? Дайте знать в комментариях.

7 основных правил проектирования кнопок

Дизайн и проектирование лучших кнопок

PS: Я хочу убедиться, что мой контент доступен, как можно большему количеству читателей. Если вам понравилась статья, не стесняйтесь поддержать автора на Patreon https://www.patreon.com/tarasbakusevych.

---

Перевод статьи uxdesign.cc

Изучение стилей кнопок SwiftUI | ПЯТЬ ЗВЕЗД

SwiftUI

26 января 2021 г.

Федерико Занетелло @zntfdr

Button , без сомнения, является одним из самых популярных элементов SwiftUI, он также очень особенный, поскольку это единственный компонент с двумя разными протоколами стилей: ButtonStyle и PrimitiveButtonStyle .

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

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

Запуск

SwiftUI поставляется с тремя встроенными стилями: DefaultButtonStyle , BorderlessButtonStyle и PlainButtonStyle .

При объявлении простой кнопки применяется DefaultButtonStyle :

 Button("Простая кнопка") {
  // кнопка нажата
  ...
}
 

DefaultButtonStyle не является стилем как таковым: это наш способ позволить SwiftUI выбрать стиль за нас (на основе контекста, платформы, родительских представлений и т. д.).

Фактический стиль по умолчанию — это BorderlessButtonStyle , который применяет синий оттенок поверх нашей кнопки или цвет акцента приложения, если мы работаем на iOS 14, а также некоторые визуальные эффекты при нажатии, фокусировке и т. д.

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

 Button("Простая кнопка") {
  ...
}
Кнопка("Простая кнопка") {
  ...
}
.buttonStyle(DefaultButtonStyle())
Кнопка("Простая кнопка") {
  ...
}
.buttonStyle(BorderlessButtonStyle())
 

В iOS 13 (синий) оттенок применяется к изображениям, объявленным в нашей кнопке label , поэтому нам нужно либо добавить модификатор рендеринга к нашим изображениям (например, Image("image"). renderingMode(. original) ) или объявите правильный рендеринг в каталоге активов изображений. Начиная с iOS 14 по умолчанию будут тонироваться только шаблонные изображения.

Наконец, SwiftUI предлагает PlainButtonStyle , который отображает метку кнопки без оттенка, но по-прежнему применяет визуальные эффекты в разных состояниях:

 Кнопка ("Обычная кнопка") {
  // кнопка нажата
  ...
}
.buttonStyle(PlainButtonStyle())
 

Это все стили, которые SwiftUI предоставляет нам в iOS: к счастью, мы можем создавать новые с помощью ButtonStyle и PrimitiveButtonStyle , давайте начнем с ButtonStyle .

ButtonStyle

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

 общедоступный протокол ButtonStyle {
  связанный тип Тело: Представление
  func makeBody (конфигурация: Self. Configuration) -> Self.Body
  typealias Configuration = ButtonStyleConfiguration
}
 

Единственным требованием ButtonStyle является возврат представления из makeBody(configuration:) , функция принимает экземпляр ButtonStyleConfiguration :

 public struct ButtonStyleConfiguration {
  общедоступная метка let: ButtonStyleConfiguration.Label
  публичный let isPressed: Bool
}
 

Эта конфигурация имеет два свойства:

• метка — это кнопка метка , например, если наша кнопка — Button(action: {}, label: { Text("Hello world") }) , затем Text("Hello world") будет нашей меткой эффекты

Давайте определим несколько примеров:

 struct RoundedRectangleButtonStyle: ButtonStyle {
  func makeBody (конфигурация: Конфигурация) -> некоторый вид {
    ХСтэк {
      Прокладка ()
      configuration.label.foregroundColor (.черный)
      Прокладка ()
    }
    . заполнение()
    .background(Цвет.желтый.уголРадиус(8))
    .scaleEffect (configuration.isPressed? 0,95: 1)
  }
}
 

 структура ShadowButtonStyle: ButtonStyle {
  func makeBody (конфигурация: Конфигурация) -> некоторый вид {
    метка конфигурации
      .тень(
        цвет: конфигурация.isPressed ? Цвет.синий : Цвет.черный,
        радиус: 4, х: 0, у: 5
      )
  }
}
 

Обратите внимание, что эти новые кнопки не имеют эффектов по умолчанию при нажатии, фокусировке и т. д. Теперь мы должны добавить такие эффекты в наши кнопки.

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

• может применять один и тот же стиль к нескольким кнопкам без дублирования кода
• доступ к событию isPressed
• сохраняет стандартное взаимодействие/поведение

Применение и составление нескольких стилей

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

Согласно нашим текущим объявлениям, применение нескольких ButtonStyle не имеет никакого эффекта, и будет использоваться только ближайший стиль ( makeBody(configuration:) других стилей даже не будет вызываться):

 // Применяется только RoundedRectangleButtonStyle
Button("Стиль кнопки прямоугольника со скругленными углами") {
  // кнопка нажата
  ...
}
.buttonStyle(RoundedRectangleButtonStyle())
.buttonStyle(ShadowButtonStyle())
.buttonStyle(BorderlessButtonStyle())
.buttonStyle(DefaultButtonStyle())
 

«Обходной путь» для этого ограничения — вернуть новую Button в нашу ButtonStyle makeBody(configuration:) функцию, например, мы можем обновить RoundedRectangleButtonStyle следующим образом:

 struct RoundedStyleRectangle
  func makeBody (конфигурация: Конфигурация) -> некоторый вид {
    Кнопка (действие: {}, метка: {
      ХСтэк {
        Прокладка ()
        configuration. label.foregroundColor (.черный)
        Прокладка ()
      }
    })
    // 👇🏻 переводит все нажатия на исходную кнопку
    .allowsHitTesting(ложь)
    .заполнение()
    .background(Цвет.желтый.уголРадиус(8))
    .scaleEffect(configuration.isPressed? 0,95 : 1)
  }
}
 

С этим новым определением работает предыдущий пример почти :

 Button("Прямоугольник со скругленными углами + стиль кнопки тени") {
  // кнопка нажата
  ...
}
.buttonStyle(RoundedRectangleButtonStyle())
.buttonStyle(ShadowButtonStyle())
 

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

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

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

 struct RoundedRectangleWithShadowedLabelButtonStyle: ButtonStyle {
  func makeBody (конфигурация: Конфигурация) -> некоторый вид {
    ХСтэк {
      Прокладка ()
      configuration. label.foregroundColor (.черный)
        .тень(
          цвет: конфигурация.isPressed ? Цвет.красный : Цвет.черный,
          радиус: 4, х: 0, у: 5
        )
      Прокладка ()
    }
    .заполнение()
    .background(Цвет.желтый.уголРадиус(8))
    .scaleEffect(configuration.isPressed? 0,95 : 1)
  }
}
 

Которые мы можем использовать следующим образом:

 Кнопка («Прямоугольник со скругленными углами + стиль кнопки тени») {
  // кнопка нажата
  ...
}
.buttonStyle(RoundedRectangleWithShadowedLabelButtonStyle())
 

Напоминаем, что это техническая статья, а не статья о дизайне.

PrimitiveButtonStyle

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

Определение PrimitiveButtonStyle почти идентично ButtonStyle :

 открытый протокол PrimitiveButtonStyle {
    связанный тип Тело : Представление
    func makeBody (конфигурация: Self.Configuration) -> Self.Body
    typealias Configuration = PrimitiveButtonStyleConfiguration
}
 

Отличие только в параметр makeBody(configuration:) , который теперь является PrimitiveButtonStyleConfiguration type:

 public struct PrimitiveButtonStyleConfiguration {
  общедоступная метка let: PrimitiveButtonStyleConfiguration.Label
  триггер публичной функции ()
}
 

Эта конфигурация снова содержит кнопку label в качестве свойства, однако isPressed теперь заменена функцией trigger() : теперь дело за нами, чтобы определить правильное время для этого.

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

 struct DoubleTapOnlyStyle: PrimitiveButtonStyle {
  func makeBody (конфигурация: Конфигурация) -> некоторый вид {
    метка конфигурации
      . onTapGesture (количество: 2, выполнение: configuration.trigger)
  }
}
 

Который затем мы можем использовать как любой другой стиль:

 Button("Дважды коснись меня") {
  // кнопка дважды нажата
  ...
}
.buttonStyle(DoubleTapOnlyStyle())
 

Применение и составление нескольких (примитивных) стилей

В отличие от ButtonStyleConfiguration , Button имеет инициализатор, принимающий экземпляр PrimitiveButtonStyleConfiguration , что позволяет нам создавать/применять несколько (примитивных) стилей к одной и той же кнопке.

Например, рассмотрим следующие стили:

 // Действие кнопки срабатывает при двойном нажатии.
структура DoubleTapStyle: PrimitiveButtonStyle {
  func makeBody (конфигурация: Конфигурация) -> некоторый вид {
    Button(configuration) // <- Button вместо configuration.label
      .onTapGesture (количество: 2, выполнение: configuration.trigger)
  }
}
// Действие кнопки срабатывает при свайпе. 
// (даже при завершении вне кнопки)
структура SwipeButtonStyle: PrimitiveButtonStyle {
  func makeBody (конфигурация: Конфигурация) -> некоторый вид {
    Кнопка(конфигурация)
      .жест(
        Жест Перетаскивания()
          .onEnded { _ в
            конфигурация.триггер()
          }
      )
  }
}
 

Поскольку каждый стиль возвращает кнопку, их можно комбинировать и без проблем работать вместе:

 Кнопка(
  "Двойное касание или смахивание",
  действие: {
    // здесь обрабатывается действие
    ...
  }
)
.buttonStyle(DoubleTapStyle())
.buttonStyle(SwipeButtonStyle())
 

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

 структура PlainNoTapStyle: PrimitiveButtonStyle {
  func makeBody (конфигурация: Конфигурация) -> некоторый вид {
    Кнопка(конфигурация)
      .buttonStyle(PlainButtonStyle()) // удаляет любой внешний вид по умолчанию
      . allowsHitTesting(false) // больше не срабатывает при нажатии
      .contentShape(Rectangle()) // разрешить другим взаимодействиям работать
  }
}
 

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

 Кнопка(
  "Двойное касание или смахивание",
  действие: {
    // здесь обрабатывается действие
    ...
  }
)
.buttonStyle(DoubleTapStyle())
.buttonStyle(SwipeButtonStyle())
.buttonStyle(PlainNoTapStyle())
 

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

Использование PrimitiveButtonStyle и ButtonStyle

Мы рассмотрели, как каждый ButtonStyle можно считать полным переопределением предыдущих стилей, в то время как PrimitiveButtonStyle позволяет нам составлять несколько стилей (при правильном определении), как насчет их объединения?

Мы можем одновременно применить и активировать как ButtonStyle , так и (несколько) PrimitiveButtonStyle , например:

 Button(
  "Примитивный стиль + кнопка",
  действие: {
    // здесь обрабатывается действие
    . ..
  }
)
// 👇🏻 запускает кнопку, даже когда мы убираем палец с кнопки
.buttonStyle(SwipeButtonStyle())
.buttonStyle(RoundedRectangleButtonStyle())
 

В таких ситуациях важно, чтобы ButtonStyle ( RoundedRectangleButtonStyle выше) был объявлен последним, иначе PrimitiveButtonStyle также сотрет .

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

Выводы

Кнопки — это компонент SwiftUI с самым простым взаимодействием: нажмите, чтобы вызвать их.

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

Вы когда-нибудь расширяли действие кнопки? Какие другие применения/потребности вы видите для таких стилей? Пожалуйста, дайте мне знать!

Спасибо за чтение и следите за новостями.

Примеры стилей кнопок SwiftUI | Sarunw

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

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

В этой статье я покажу вам все 5 стилей кнопок, которые вы можете использовать с кнопкой SwiftUI в iOS.

Встроенные стили кнопок в iOS.

Стиль кнопки по умолчанию

По умолчанию , если мы не укажем стиль кнопки, SwiftUI будет использовать .automatic стиль кнопки .

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

Стиль кнопки .automatic преобразуется в стиль кнопки без рамки в iOS , тогда как macOS, tvOS и watchOS используют стиль кнопки с рамкой .

Один и тот же код может привести к разным стилям в зависимости от контекста.

 Button("Название кнопки") { 
 } 
 

Вот как это выглядит на iOS и macOS.

Стиль кнопок по умолчанию в iOS и macOS.

Как изменить стиль кнопки SwiftUI

Вы можете управлять стилем кнопки с помощью buttonStyle(_:) Модификатор.

В этом примере я установил стиль кнопки borderedProminent .

 Button("Выдающаяся кнопка с рамкой") { 
  }.buttonStyle(.borderedProminent)  
 

Если вы примените стиль кнопки к представлению контейнера , все кнопки в контейнере будут использовать этот стиль.

 HStack { 
 Кнопка ("Войти") {} 
 Кнопка ("Регистрация") {} 
 } 
  .buttonStyle(.borderedProminent)  

Примените стиль кнопки к представлению-контейнеру, все кнопки в этом представлении получат этот стиль.

5 iOS ButtonStyles

SwiftUI получил пять стилей кнопок следующим образом.

1. автоматический
2. без полей
3. обычный
4. с рамкой
5. с окантовкойВидный

Автоматический

Если мы не указываем стиль кнопки . SwiftUI будет использовать стиль кнопки .automatic .

Как мы узнали из раздела «Стили кнопок по умолчанию», SwiftUI использует .borderless стиль для iOS.

Вот пример автоматического стиля кнопки, автоматического или DefaultButtonStyle.

 Button("Автоматическая кнопка") { 
 } 
 .buttonStyle(.automatic) 
 // Или 
 Button("Автоматическая кнопка") { 
 
 } 
 

Automatic

Borderless

Это стиль, который . automatic используется в iOS.

Пример стиля кнопки без полей, без полей или BorderlessButtonStyle

 Кнопка ("Кнопка без полей") { 
 }.buttonStyle(.borderless) 
 

Без полей

Обычная

Пример стиля простой кнопки, простая кнопка или PlainButtonStyle

 Button("}P
 Button" .buttonStyle(.plain) 
 
обычная
 Bordered 
 Пример стиля кнопки с рамкой,  bordered  или  BorderedButtonStyle  .
 Кнопка ("Кнопка с рамкой") { 
 }.buttonStyle(.bordered) 
 
с рамкой
 Bordered Prominent 
 Пример стиля выделенной кнопки с рамкой,  borderedProminent  или  BorderedProminentButtonStyle  .
 Button("Bordered Prominent Button") { 
 }.buttonStyle(.borderedProminent) 
 
borderedProminent
 Сводка 
 Вот  пять стилей кнопок для сравнения  .
 Все пять стилей кнопок iOS.