iOS Guidelines in Russian. Part №7

Гайдлайны Apple. Перевод.

Интерактивность и отклик приложения

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

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

Базовые жесты iOS:

• Нажатие (Tap)
• Произвольный перенос (Drag)
• Горизонтальный перенос за пределы экрана (Flick)
• Горизонтальный перенос в пределах экрана (Swipe)
• Двойное нажатие (Double tap)
• Перемещение двух пальцев в разные стороны по диагонали (Pinch)
• Долгое нажатие (Tap and Hold)
• Встряхивание устройства (Shake)

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

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

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

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

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

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

Интерактивные элементы.

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

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

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

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

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

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

• При работе с контентом добавляйте заливку или обводку только в крайнем случае. Если кнопки в панелях или всплывающих окнах в подавляющем большинстве случаев содержат именно управляющие элементы, естественно, что дополнительного выделения там не требуется, ведь и так интуитивно понятно, что можно нажать, а что нельзя. В областях с контентом управляющий элемент может действительно требовать дополнительного выделения, чтобы быть контрастным с неактивными информационными элементами. Такие приложения как Музыка, Часы, Фотографии и App Store используют дополнительное выделение в специфичном (исключительном) контексте.

Пустой экран у приложения Фотографии

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

• App Store использует обводку в ячейке таблицы, чтобы подчеркнуть различное поведение при нажатии на кнопку “Купить” (или “Бесплатно”). Нажатие непосредственно на ячейку будет приводить к переходу к дополнительной информации о потенциальной покупке, в то время как нажатие на “Купить” явно говорит о транзакции. Если убрать обводку, то пользователь может засомневаться, не приведет ли нажатие на саму ячейку к покупке. Не забывайте, любое действие, связанное с финансами, будет вызывать дополнительную осторожность у пользователей.

Понимание обратной связи.

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

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

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

Ввод информации

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

Сделайте выбор пользователя легче. Например, пользователи могут использовать пикер (picker) или выбор из списка вариантов вместо поля ввода, потому что выбрать из готового всегда легче, чем написать что-то свое. Старайтесь уменьшить количество полей для ввода до минимума, особенно если у вас имеется выбор из нескольких статичных вариантов.

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

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