Touch управление что это
Поддержка Touch в JavaScript
Какие проблемы могут быть у frontend-программиста, если тестировщик запустит его приложение на iPad с новой трекпад-клавиатурой, Windows-планшете, с неопределенным состоянием “режима планшета” или ноутбуке с подключенным к нему телевизором c поддержкой Multi-touch?
Это далеко не полный список допустимых конфигураций оборудования, которые мы поддерживаем при разработке системы СБИС. Сегодня СБИС — это не только знакомое многим решение для сдачи отчетности, ведения электронного документооборота и бухгалтерии, но и набор инструментов для автоматизации розницы, общепита, доставки и логистики. В этих сферах нужно уметь хорошо работать на самых разных планшетах и гаджетах с различными экранами и типами устройств ввода. И далеко не всегда проблемы могут быть связаны с экзотическим сочетанием настроек операционных систем и драйверов: если взять обычный iPad с браузером Safari, Android планшет или ноутбук-трансформер на Windows10 с последней версией Google Chrome — везде будет свой набор ошибок и особенностей обработки пользовательского ввода.
Эта статья о том, как, а главное, зачем вводить в обычных Web приложениях режим поддержки Touch.
Основными особенностями Touch режима при организации пользовательского взаимодействия является отсутствие указателя мыши и появление виртуальной клавиатуры.
Соответственно на уровне приложения необходимо предусмотреть:
Мы разрабатываем собственную библиотеку визуальных компонентов, поэтому стараемся решать все проблемы по максимуму на уровне фреймворка.
Определяем момент активации Touch-режима
Важно отметить, что при взаимодействии с одним и тем же устройством пользователь может переходить из одного режима взаимодействия в другой. Например открепить экран от ноутбука-трансформера, поработать с ним как с планшетом, а затем прикрепить обратно и продолжить работать с помощью мыши.
Это означает, что заведомо мы никогда не знаем в каком режиме используется устройство.
Еще пример: в наших переговорках к ноутбукам подключены телевизоры с поддержкой Multi-touch. Формально браузер на ноутбуке считает, что его устройство поддерживает Touch-события. Именно на этой конфигурации оборудования мы обнаружили проблему в нашем первом алгоритме определения Touch-режима по наличию поддержки специализированных событий. Несмотря на то, что телевизор закреплен на стене, а на ноутбуке мы работаем в обычном режиме с подключенной мышью, приложение переключилось в режим, адаптированный для работы на планшете.
Сегодня мы определяем Touch-режим путем анализа реакции на события touchstart и mousemove: если вызову mousemove не предшествовал touchstart, значит пользователь ведет мышкой, иначе нажал пальцем.
Исходный код примерно такой
В результате генерируется событие и мы сохраняем значение режима в объекте с информацией о текущем окружении, а также на body выставляем классы is-touch или is-hover.
Особенности поддержки :hover
В нашем приложении мы полностью отказываемся от поддержки :hover при работе в Touch режиме. Все стили с поддержкой :hover выглядят примерно так:
Этот способ работает надежнее стандартного @media (hover: hover), который не отключает поддержку hover свойства в Chrome и Firefox при управлении пальцами.
При такой организации стилей мы никогда не получим случайно подсвеченный через :hover элемент под виртуальным курсором мыши, оставшемся в точке последнего взаимодействия.
Следует обратить особое внимание на использование этого псевдокласса для управления видимостью блока.
Наши компоненты списков, таблиц и деревьев используют :hover-селекторы для показа операций над строкой при наведении (например редактировать, удалить и т.п.).
Подобное применение :hover на iOS приведет к тому, что первый клик по строке только изменит видимость элементов управления, поэтому пользователю придется делать второй клик. А вот на Android и Windows операции над строкой никто никогда не увидит.
При переходе в Touch-режим в списочных компонентах отключается поддержка :hover и включается поддержка управления жестами, например swipe или долгое нажатие.
Swipe-жесты мы обрабатываем самостоятельно по событию mousemove в touch-режиме при следующих условиях:
Особенности при работе с виртуальной клавиатурой
К сожалению, даже в последних версиях Google Chrome периодически возникают проблемы с виртуальной клавиатурой.
Иногда мы сами регистрируем ошибки:
Ссылка 1
Ссылка 2
Иногда находим на уже зарегистрированные:
Ссылка 1
Ссылка 2
В демо-примерах проблема может выглядеть безобидной, но в реально работающем приложении все скачет в разные стороны и по несколько раз. Поэтому, при наличии возможности, мы стараемся размещать поля ввода выше предполагаемой границы виртуальной клавиатуры. Это позволяет сгладить эффект от ряда существующих ошибок и минимизировать риски при появлении новых при обновлении браузера. В идеале уложиться в 300px по высоте, чтобы обеспечить комфортную работу даже на маленьких POS-терминалах.
Самый простой пример: как не нужно размещать поля логин и пароль на форме авторизации
Если устройство имеет экран побольше, то становится актуальным вопрос удобного отображения подсказок у поля ввода при вводе текста. Подсказки и обычные диалоги нужно по возможности позиционировать в видимой области экрана.
На первый взгляд задача выглядит не сложной, но до недавнего времени она не имела 100% работающего решения:
Во-первых, API браузера не предоставлял информации о том, показана виртуальная клавиатура или нет. Нам приходилось отслеживать приход и уход фокуса для каждого поля ввода. При этом клавиатуру можно просто скрыть и на состояние фокусировки это никак не повлияет.
Во-вторых, никто не знал реальный размер клавиатуры. Мы подобрали коэффициенты в зависимости от ориентации экрана: 0.3 для портретной и 0.55 для ландшафтной.
Но стоило к iPad подключить Smart Keyboard, как все вычисленные коэффициенты оказались бесполезными и даже вредными, т.к. высота виртуальной клавиатуры схлопнулась до одной строки.
К счастью, сегодня все современные браузеры получили поддержку VisualViewport. Прошло целых 12 лет с момента релиза iOS, прежде чем разработчики смогли получить информацию об изменении размера viewport при показе виртуальной клавиатуры.
Новое API позволяет решить сразу 2 проблемы:
День отказа от поддержки iOS12 станет нашим большим праздником, т.к. мы сможем окончательной перейти на поддержку VisualViewport, убрав из кода всю магию.
Не злоупотребляйте ручной фокусировкой
Старайтесь избегать ручного управления фокусом в коде с асинхронным стеком, например, связанного с загрузкой ресурсов или ожиданием ответа от сервиса. Система iOS может показать виртуальную клавиатуру только в рамках синхронной обработки события действия пользователя. В противном случае клавиатура будет появляться или убираться тогда, когда этого уже никто не ждет.
Подобные ошибки периодически встречаются во всех крупных веб-сервисах. Я лично видел проблемы на iPad в разное время и в Google при поиске картинок, когда клавиатура для поля поиска скрывалась сразу после показа и сама же открывалась обратно, и в Яндекс Маркете, когда клавиатура исчезала во время ввода текста в поле поиска.
Если исходный код вашего приложения полностью загружается при старте приложения, то часть проблем, связанная с асинхронной загрузкой ресурсов вас не касается.
Но если часть ресурсов грузиться по требованию, или после действия пользователя необходимо совершить асинхронный запрос за данными, то проблема становится актуальной. В таком случае, например, после перехода по навигации в SPA-приложении или после открытии диалога, нельзя устанавливать фокус в поле ввода на iOS.
Так у каждого нашего компонента есть метод activate для установки фокуса. По умолчанию активация не устанавливает фокус в поля ввода на iOS-устройствах. При этом можно передать параметр enableScreenKeyboard: true для показа клавиатуры. В этом случае программист должен обеспечить синхронный вызов метода в обработчике пользовательского ввода.
Touch — это просто
Таким образом, в современных браузерах с помощью нехитрого набора приемов достаточно легко можно организовать поддержку Touch-режима. Это те самые 20% усилий, которые помогут добиться 80% результата: у большинства пользователей приложение будет предсказуемо работать на их конфигурациях оборудования.
Конечно, в нашем коде есть еще много закладок на особенности работы режима Touch в разных браузерах, но все они имеют более глубокую специфику.
Например, как мы решаем проблему не всегда работающего клика при таче, почему поле ввода может улететь под виртуальную клавиатуру и что с этим делать, какая дополнительная поддержка должна быть при работе с резистивным экраном и как его определить, а также много других интересных задач.
Если эта тема будет интересна, я готов продолжить описывать их в следующей статье.
Touch управление что это
За последнее время много слов было сказано на тему юзабилити интерфейсов мобильных приложений. Тема, действительно, актуальная, учитывая насколько плотно смартфоны вошли в нашу жизнь. Наличие сенсорного экрана предлагает пользователю (предполагает) совершенно иной способ взаимодействия с устройством. В данной статье представлена подборка возможных жестов пользователя (touch-событий) и ответные реакции интерфейса на них.
Что такое multi-touch, и какие преимущества получает пользователь;
Какие платформы поддерживают технологию multi-touch;
Какие команды можно реализовать с помощью жестов;
Без чего жестовое управление бесполезно;
Включать жестовые команды в мобильное приложение или нет.
Одним движением
Представьте себе не обычный почтовик, как Outlook, например, а нечто новое, в котором можно удалять или архивировать письма при помощи проведения пальцем вправо-влево, отмечать письма зажатием и встряхиванием, отвечать, пересылать, или отмечать как прочитанные письма и много другое с помощью не кнопок, а жестов. Это реальность для мобильных устройств и тенденция в разработке интерфейсов многих современных приложений.
Таких приложений сейчас уже довольно много. В этой статье упомянем несколько самых ярких.
Управление посредством прикосновений (или, говоря техническим языком, touch-событий) имеет свои особенности. Реакция интерфейса на жесты пользователей достаточно разнообразна и зависит от 2-х факторов: от характера движения и от количества точек контакта. Коснулись пальцем экрана один раз и запустили приложение, провели пальцем по эрану вверх или вниз – прокрутили страницу (это действие носит название «скролл»), смахнули пальцем вправо или влево и перелистнули страницу («свайп»). Приведенные примеры прекрасно иллюстрируют вариант управления с помощью одного пальца (одной точки контакта). Подобные touch-события поддерживаются большинством мобильных платформ и браузеров.
Для описания ситуации, когда точек контакта несколько, используется достаточно популярный благодаря компании Apple термин multi-touch. Использование трекпадов с поддержкой multi-touch технологии в ноутбуках компании произвело революцию в сознании многих пользователей. Кроме того, тактильное взаимодействие носит эмоциональную окраску, что доказывает преимущества touch-управления перед кнопочным или управлением посредством стилуса.
Жестами принято называть объединенные в одну команду multi-touch события. Например, «сжимание» изображения с целью изменения его масштаба. При этом среди мобильных платформ распространены multi-touch события для ситуаций, когда точек контакта не более двух, то есть в управлении задействовано всего два пальца..
Поддержка
Технология multi-touch может быть использована только в нативных приложениях. Ниже представлен список мобильных платформ, поддерживающих multi-touch и жесты на 2013 год:
• Windows Mobile 6.5 и более поздние, включая приложения с Flash Player 10.1 и Adobe AIR 2;
• Apple iOS;
• Nokia Symbian 3 OS на флагманских моделях Nokia N8, Nokia C6-01, Nokia C7, Nokia E7, Nokia X7;
• Google Android;
• Samsung Bada;
• Palm webOS;
• Microsoft Windows Phone 7, 8;
• BlackBerry OS 6.0;
• Neprash Technology’s N-Touch Platform.
Варианты прикосновений
Варианты прикосновений прекрасно описаны в Touch Gesture Reference Guide (авторы Craig Villamor, Dan Willis, Luke Wroblewski). Я предлагаю Вашему вниманию выжимку. Полную версию можно скачать с сайта авторов:
Коротко коснуться одним пальцем экрана
Выбрать, в процессе прокрутки страницы – ускорить
Дважды быстро коснуться одним пальцем экрана
Открыть, изменить масштаб контента на экране
Провести одним пальцем по экрану вправо, не разрывая контакта.
Одним пальцем легко смахнуть по экрану вниз (движение напоминает мазок кистью по холсту)
Легко одним пальцем смахнуть вправо (движение напоминает мазок кистью по холсту)
Перелистнуть страницу, развернуть боковое меню
Коснуться экрана двумя слегка разведенными пальцами и соединить их
Обратный жест: коснуться экрана двумя соединенными пальцами и развести их
Коснуться экрана одним пальцем и зафиксировать это действие на несколько секунд (словно, нажать на экран).
Изменить состояние, выделить
Коснуться экрана одним пальцем, зафиксировать (нажать) и в тот же момент быстро коснуться экрана другим пальцем
Переместить, открыть контекстное меню
Нажать на экран одним пальцем и одновременно с этим другим пальцем провести по экрану, не теряя контакта вправо либо вверх/вниз
Коснуться экрана двумя разведенными пальцами и совершить вращательное движение по часовой стрелке (четверти оборота достаточно);
Нажать на экран одним пальцем, одновременно другим пальцем очертить полукруг по часовой стрелке;
Коснуться двумя сведенными вместе пальцами экрана и очертить полукруг по часовой стрелке, не разрывая контакта
В качестве примеров предлагаю посмотреть три приложения, в которых управление реализовано только с помощью жестов.
По мнению разработчиков такой жестовый калькулятор может быть на 200% более эффективным.
Простой планировщик дел, преимущественно для домашнего использования. Основная фишка: минималистический интерфейс и интуитивно понятное жестовое управление:
Чтобы добавить элемент достаточно потянуть список вниз
Для удаления или внесения отметки о выполнении задачи нужно провести пальцем вправо/влево
Чтобы вставить новый пункт в список между двумя другими необходиммо использовать жест, применяемый для увеличения
Чтобы закрыть текущий список и показать все списки нужно потянуть список чуть сильнее
Повторное движение позволит перейти к экрану настроек
Приложение Будильник, которое, разумеется, управляется жестами:
Чтобы настроить время достаточно потянуть
Функция Включить/выключить реализована свайпом
Чтобы отключить звонящий будильник при заблокированном экране необходимо потрясти телефон
Не злоупотреблять! Советы по применению
Несмотря на очевидные преимущества реализации touch-управления в интерфейсах, которые обеспечивают более полное взаимодействие с пользователем за счёт тактильных ощущений, использование только жестового управления не всегда оправдано. Ниже приведены рекомендации разработчику:
Используемые жестовые команды должны быть простыми и интуитивно понятными пользователю, реакция на жесты должна быть ожидаемой. Например: жесты «зачеркивание» и «листание».
При использовании более сложных жестовых моделей управления, которые не могут быть обнаружены пользователем самостоятельно, необходимо предусмотреть процесс обучения пользователя и реализовать подсказки. При этом рекомендуется обучать пользователя не только при первом знакомстве с приложением. Но и в процессе использования..
Не рекомендуется использовать только жесты для управления основными функциями приложения (лучше продублировать в интерфейсе кнопки, как более знакомый пользователю метод взаимодействия).
Выводы
Изменению восприятия смартфона в сознании пользователей, несомненно, дает и новые возможности разработчикам. Уже наметилась определенная тенденция обновления интерфейса в сторону упрощения взаимодействия с пользователем, что подтверждает недавний релиз концептуально новой для Apple операционной системы iOS 7. На мой взгляд, iOS 7 будит желание прикасаться к экрану телефона снова и снова.
А насколько полно Вы используете возможности touch-экрана в повседневной жизни?
При проектировании механизма управления жестами стоит обратить внимание на лидеров категории, к которой относится ваше приложение. Не самая лучшая идея — переучивать пользователя, вынуждая его отказаться от привычных жестов. Иначе говоря, ридер будет выглядеть странным и неудобным, если вы предложите пользователю листать страницы тремя пальцами. Особенно важна проработка жестов при создании приложений, поддерживающих такие девайсы, как Samsung Galaxy Gear или Google Glass, в которых предпочтение отдается альтернативным способам управления. Однако возможно, вы мыслите вне рамок и стандартов и ваша цель — создать новаторское приложение с уникальной системой ввода, наподобие калькулятора Rechner. В таком случае функционал можно расширить за счет использования нестандартных модификаций. Например, как поступили американские разработчики из Qeexo, научившие телефон отличить нажатие пальцем от нажатия ногтем или костяшками пальцев.
Все жесты мультитач, перемещения экрана или встряхивания интересны для игровых приложений. Использовать их в бизнес-приложениях не следует. Пользователь должен иметь возможность получить необходимую ему информацию быстро и сразу, не прибегая к дополнительным ухищрениям. Перед любой веб-студией как раз и должна стоять задача уместить весь необходимый функционал на небольшом экране смартфона так, чтобы у конечного потребителя не возникало проблем с его использованием и дополнительных вопросов к интерфейсу.
Ищете исполнителя для реализации проекта?
Проведите конкурс среди участников CMS Magazine
Узнайте цены и сроки уже завтра. Это бесплатно и займет ≈5 минут.
Сенсорное управление Touch Control
Система сенсорного управления Touch Control выводит технологию стирки на новый уровень. Функция позволяет предельно точно и быстро задавать, изменять или отменять определенные опции и параметры в стиральных машинах Korting. И если раньше на это требовалось сравнительно немало времени, то с Touch Control процесс управления стиралкой упрощается донельзя. Любую проблему удается решить буквально за пару прикосновений к сенсорному дисплею. Разобраться в принципе действия, по словам разработчиков, даже интуитивно очень просто, поэтому рядовой пользователь не будет испытывать никаких трудностей в эксплуатации.
Как это работает?
Инновационная технология принципиально отличается от стандартной сенсорной системы тем, что охватывает гораздо больше возможностей для хозяина. Ультрачувствительные сенсоры улавливают малейшее прикосновение – пользоваться стиральной машиной Korting еще никогда не было так просто. С помощью сенсорной системы Touch Control можно осуществлять следующие процессы:
Запуск или остановка стирки с возможностью дозагрузки белья. Очень удобно, если вы, например, забыли положить в бак какую-то вещь. Одно-два прикосновения – и проблема решается в кратчайшие сроки. Запуск программы «Легкая глажка», которая позволяет получить практически немятое и полусухое белье. Благодаря сверхделикатному отжиму и большему объему воды одежда гораздо меньше мнется, а потому максимально упрощен процесс глажки. Сенсорами Touch Control можно регулировать и интенсивность ополаскивания. Например, задавать большее количество воды для повышения интенсивности или же наоборот. Выбор количества оборотов барабана в стиральных машинах Korting.
Обратите внимание, что технология сенсорного управления Touch Control обеспечивает максимально точную регулировку всех параметров, что существенно повышает энергоэффективность стиралки. Так производитель Korting заботится не только о вашем удобстве, но и об экономии денежных средств. С такой техникой потребляется четкий объем воды и электроэнергии, без малейшего перерасхода.
Важно найти надежного реализатора, который предлагает минимальные цены на фирменные стиральные машины Korting. Наш интернет-магазин относится как раз к таким! Зайдите в каталог, чтобы найти модель с функцией сенсорного управления Touch Control, и непременно убедитесь, что с нами вам удастся хорошо сэкономить. Техника продается с официальной гарантией от производителя – звоните!
Особенности проектирования тачевых интерфейсов
Это перевод оригинальной статьи Designing for touch
Принципы управления привычными интерфейсами настольных систем оказываются перевернуты с ног на голову, когда дело касается интерфейсов сенсорных. В данной статье приводятся рекомендации специалиста по проектированию взаимодействий Джоша Кларка (Josh Clark) относительно разработки интерфейсов для сенсорных мобильных устройств и сравниваются сенсорные интерфейсы устройств Android, iPhone и iPad.
Чтобы добиться успеха при разработке мобильного интерфейса, недостаточно просто втиснуть его в рамки крошечного экрана мобильного устройства. Эффективные мобильные сенсорные интерфейсы позволяют приспособить для управления жесты наших неуклюжих пальцев. Особенности интерфейсов портативных устройств побуждают разработчиков выйти за пределы принципов графического и информационного дизайна и ступить на территорию дизайна промышленного. Здесь, в мире сенсорных устройств, на кону не что иное, как сама эргономика. Теперь на пиксели можно не только смотреть: их можно трогать, и они должны быть приятными на ощупь.
Правило большого пальца
При разработке интерфейса сенсорного устройства нужно ясно представлять себе, как это устройство лежит в руке и как пальцы пользователя его охватывают. Используя, к примеру, мобильный телефон, мы преимущественно орудуем большим пальцем (хотя, наверное, бывают оригиналы, которые держат телефон каким-то другим изощренным способом). Таким образом, при разработке интерфейса для телефона необходимо подстраиваться под большой палец пользователя.
О, большие пальцы! Именно они (да еще, наверное, любовь к сплетням о жизни знаменитостей) отличают нас от скотов бессловесных. К сожалению, большим пальцем не до всего можно дотянуться. Конечно, при должном усилии большим пальцем можно достать почти до любой точки экрана мобильного телефона (если не брать в расчет совсем уж гигантские модели), однако без лишнего напряжения можно работать только с третьей частью экрана — его нижней частью со стороны, противоположной большому пальцу.
Именно в этой зоне следует располагать основные элементы сенсорного интерфейса. Если вы возьмете телефон, например, в правую руку, то ваш большой палец окажется над левым нижним углом экрана.
По этой причине в интерфейсах мобильных устройств панели инструментов и навигационные элементы обычно располагаются внизу экрана, тогда как в интерфейсах традиционных настольных приложений они обычно расположены вверху экрана: меню настольных приложений вы, скорее всего, обнаружите вверху экрана или окна, а навигационные элементы веб-сайтов — вверху страниц. Однако использование большого пальца накладывает свои ограничения, переворачивая привычные настольные интерфейсы с ног на голову, — и навигационные инструменты вместе с основными элементами интерфейса перемещаются в нижнюю часть экрана.
Тяготение большого пальца к нижней части экрана мобильного устройства — гораздо более важный фактор при проектировании мобильных интерфейсов, чем выбор между левой и правой стороной экрана. Как выясняется, большинство пользователей мобильных телефонов с легкостью меняют руки при работе с устройством. Правши часто и с удовольствием «ходят налево» (порой доходит до того, что левая рука используется чаще, чем правая), а левши, соответственно, частенько изменяют левой с правой. Хотя считается, что средний пользователь с большей вероятностью будет использовать правую руку, нежели левую, здесь все же нет достаточно четкой тенденции, так что разработчики могут расслабиться и не ломать голову над вопросом «справа или слева?!».
Наше правило большого пальца работает вне зависимости от того, в какой руке пользователь держит устройство, и позволяет выстроить эффективную визуальную иерархию элементов интерфейса. Наиболее часто используемые кнопки следует размещать внизу экрана, где пользователю будет удобно их нажимать. Все остальные элементы управления стоит отодвинуть — от греха подальше. В приложениях для iOS, к примеру, кнопка «Изменить» обычно размещается в верхнем правом углу — т. е. в зоне видимости, но вне зоны прямой досягаемости, что позволяет избежать случайных нажатий.
Размещать основные элементы интерфейса внизу экрана устройства нужно не только затем, чтобы удобнее было управляться большим пальцем, но и просто потому, что иначе пальцы пользователя заслоняют экран. При расположении элементов интерфейса внизу ваши руки не перекрывают отображаемый контент. Чтобы контент разрабатываемого приложения был в зоне видимости, размещайте его над элементами управления. Этот логичный и привычный подход используется в большинстве физических устройств, таких как плееры iPod, калькуляторы, сотовые телефоны, напольные весы и так далее: контент — сверху, элементы управления — снизу.
Я, робот
Однако с этим правилом не все так просто, как хотелось бы: в частности, разработчики Android взяли и разместили внизу тесных экранов соответствующих устройств еще и системные кнопки (до выпуска Android 3 «Honeycomb» в устройствах использовались в том числе и физические кнопки, начиная с Android 4 «Ice Cream Sandwich» — только виртуальные). Безусловно, согласно описанным выше причинам эти кнопки и должны размещаться внизу экрана, однако это приводит к тому, что кнопки управления ОС и кнопки управления приложениями сбиваются в кучу, что существенно затрудняет работу с сенсорным интерфейсом. Размещение дополнительных элементов управления внизу экрана приводит к нагромождению панелей инструментов — и стоит признать, что в подобных интерфейсах, увы, пользователь постоянно рискует нажать куда-нибудь не туда. А на участках экрана, перекрываемых большим пальцем, избежать подобных ошибок практически невозможно. Посмотрите на этот главный экран устройства Android — он фактически не оставляет пользователю шанса на безошибочное управление.
При разработке сенсорных интерфейсов подобного нагромождения элементов управления (особенно в нижней части экрана) необходимо всеми силами избегать. К сожалению, это означает, что элементы управления приложениями для Android должны размещаться в верхней части экрана, дабы избежать столпотворения в нижней части, которую оккупировали системные элементы управления. Такой расклад далек от идеала: элементы навигации оказываются вне зоны прямой досягаемости большого пальца, и когда пользователь пытается до них дотянуться, его рука перекрывает весь экран. Но даже такие неудобства незначительны по сравнению с ситуацией, когда палец при нажатии постоянно задевает соседние кнопки.
В устройствах Android элементы навигации и управления должны размещаться вверху. Это принцип, противоположный используемому в устройствах iPhone, где кнопка Home не мешает работе с приложениями, как это происходит в случае с системными кнопками Android. Сравните приложения Foursquare для Android (слева) и для iPhone (справа).
Интернет: приложение внутри приложения
Стараясь избежать нагромождения элементов интерфейса на экранах мобильных устройств, мы также сталкиваемся с проблемами использования веб-сайтов. Как вы знаете, любые веб-сайты и веб-приложения функционируют в рамках другого приложения — веб-браузера. В браузерах многих мобильных платформ также присутствуют кнопки и элементы управления, которые могут затруднять работу с пользовательским интерфейсом при веб-навигации. Следовательно, в контексте работы с веб-сайтами необходимо избегать закрепления навигационных элементов в нижней части экрана, так как в противном случаем панель инструментов веб-сайта окажется в довольно тесном соседстве с панелью инструментов браузера (в пользу данной рекомендации говорит и тот факт, что фиксированное положение (position:fixed) не поддерживается в CSS всех мобильных браузеров в равной степени, что делает закрепление панели инструментов внизу довольно трудной задачей).
Решением проблемы будет не размещение элементов веб-навигации вверху экрана (как в случае с устройствами Android), а наоборот, перемещение их вниз страницы. Так как немалую часть ресурсов мобильных браузеров «съедают» разнообразные прибамбасы, ни в коем случае нельзя забивать верхнюю часть веб-страницы параметрами навигации, окончательно вытесняя контент с экрана.
Люк Вроблевски (Luke Wroblewski) в поистине великолепной книге «Mobile First» говорит: «Слишком часто взаимоотношения пользователя с мобильными веб-приложениями… начинаются не с собственно контента, а со списка параметров навигации. При работе с мобильными устройствами время может быть буквально на вес золота, а загрузка файлов — стоить реальных денег, так что постарайтесь дать людям то, что им нужно, как можно быстрее».
При работе с мобильными приложениями контент должен быть на первом плане, а основные навигационные элементы следует разместить внизу и не давать им расползаться по всему экрану. Вроблевски призывает использовать шаблон проектирования, в качестве примера которого можно рассмотреть мобильный веб-сайт Ad Age: все навигационные элементы скрыты и появляются при нажатии кнопки Menu на панели инструментов вверху экрана. Стоит нажать кнопку — и параметры навигации тут же отобразятся на экране устройства. Меню отображается мгновенно, как будто произошло наложение, но на самом деле это работает ссылка-привязка к навигационным элементам в нижней части страницы.
Люк Вроблевски подчеркивает следующие достоинства данного подхода:
«Здесь используется минимальный набор навигационных элементов (единственная ссылка вверху), при этом пользователи могут сперва спокойно ознакомиться с контентом, а уже потом разбираться с навигацией. Данное меню не дублирует какое-либо другое меню, и для его работы (самая приятная часть) требуется лишь простая ссылка-привязка. Да-да, никакого навороченного JavaScript, наложений или раздельных навигационных страниц — только привязка к нижней части страницы. Проще не бывает — это как HTML 0».
Контент сверху, элементы управления снизу — казалось бы, все так просто, но мы уже убедились, что результаты проектирования могут существенно различаться, так как разработчикам приложений приходится считаться с запросами, которые операционная система или браузер предъявляют к ресурсам. Можно сделать следующие выводы:
Но эти рекомендации в первую очередь касаются телефонов. А как насчет сенсорных устройств побольше? Когда речь заходит о таких устройствах, как iPad, правила проектирования снова меняются.
Планшеты — по углам
Правило большого пальца применяется и к устройствам iPad, однако зона прямой досягаемости тут несколько другая, ведь планшеты мы держим не так, как телефоны. То, как пользователь держит iPad, напрямую зависит от его позы. В положении стоя потребуется использовать обе руки. Сидя за столом, пользователь, скорее всего, будет поддерживать его одной рукой и управлять другой. Сидя за в кресле, он положит планшет на колени и будет управляться с устройством одной рукой. А если пользователь прилег или прислонился к чему-нибудь и находится в наклонном положении, то устройство он, скорее всего, расположит на животе, поддерживая его одной рукой и управляя другой.
Во всех этих положениях пальцы пользователя оказываются в разных частях экрана устройства. Кроме того, в каждой позе пользователь держит устройство на определенном расстоянии. Ближе всего он будет держать iPad в положении стоя и дальше всего — в положении лежа.
Из всего этого разнообразия можно вывести два общих принципа. Во-первых, iPad удобнее всего держать за верхнюю часть, при этом большие пальцы пользователя находятся над верхними углами экрана устройства. Во-вторых, довольно затруднительно с первого взгляда охватить весь контент, отображаемый на экране iPad, так как он попросту больше, чем экран телефона. Так как взгляд в первую очередь фокусируется на верхней части планшета (и отпечатанной страницы — этот принцип взят из области типографского дизайна), иерархия отображаемой информации должна быть организована соответствующим образом. Другими словами, при работе с iPad и взгляд, и пальцы пользователя оказываются на верхней части устройства (нижняя часть порой находится вне зоны видимости: при самом распространенном и уж точно самом расслабленном положении — лежа или полулежа — нижняя часть лицевой панели устройства утопает в складках одеял, свитеров и животиков пользователей).
В приложениях для планшетов iPad, в отличие от телефонов, основные элементы управления и кнопки следует размещать вверху, а именно в верхних углах, так как именно там располагаются большие пальцы пользователя, взявшего в руки iPad. В качестве положительных примеров приведем приложения Instapaper и Twitter для iPad.
При этом размещать элементы управления сверху по центру не стоит, так как при использовании данных кнопок рука пользователя будет закрывать отображаемый контент. Поскольку элементы управления в принципе не должны располагаться непосредственно над связанным с ними контентом, этот шаблон (размещение данных элементов по углам) довольно полезен. Например, в приложении The Daily для iPad вверху по центру расположен инструмент, позволяющий просматривать выпуск постранично, но при попытке им воспользоваться рука перекрывает миниатюры страниц, что усложняет задачу пользователя.
Подводя черту
Вышеописанный промах, допущенный разработчиками приложения The Daily, демонстрирует, что в любом правиле есть свои исключения и в некоторых случаях элементы управления следует размещать в нижней части экрана, а не вверху по углам. Элементы управления, отвечающие за отображение или изменение контента, всегда должны размещаться под этим контентом или сбоку от него, но никак не сверху. Вот, например, разработчики приложения The Sydney Morning Herald для iPad внедрили в него оригинальный инструмент навигации: пользователь может быстро просматривать все статьи текущего выпуска, просто проводя пальцем по указателю, состоящему из номеров страниц, внизу экрана. Данный инструмент управления выводит на экран длинный список заголовков, поэтому разумнее всего разместить его внизу экрана, так как в противном случае при использовании инструмента рука пользователя будет перекрывать отображаемый контент.
Так что же выбрать — верх или низ? Давайте разберемся.
Именно поэтому миниатюры страниц книг или журналов лучше всего размещать внизу. Еще один пример: предположим, что вы разрабатываете приложение для создания карт, которое помимо прочих функций содержит палитру объектов для добавления на создаваемую карту. Как вы уже догадались, данную палитру также следует разместить в нижней части экрана, чтобы при работе с картой рука пользователя не перекрывала экран.
Акелла не промахнется
Аналогично тому, как манера пользователей держать устройство определяет расположение элементов управления, размер пальцев пользователей, в свою очередь, определяет размер этих элементов. Элементы сенсорных интерфейсов должны быть достаточно большими для того, чтобы пользователь не промахнулся и мог попасть по ним, не вперивая напряженно глаза в экран.
Каков же достаточный размер элементов сенсорного интерфейса? Встречный вопрос: а каков размер кончика пальца? Для каждой платформы есть свои рекомендации. Apple, как обычно, проявляет наибольшую настойчивость и предлагает наилучшую (по мнению автора статьи) и универсальную для всех платформ рекомендацию: размер элементов сенсорного интерфейса должен составлять как минимум 44 точки (что равняется четверти дюйма или 7 мм). К веб-приложениям данное ограничение в 44 пикселя также отлично применяется.
Разработчикам, привыкшим к настольным интерфейсам, такие элементы управления могут показаться гигантскими и какими-то игрушечными, но к этому надо просто привыкнуть. По громадным кнопкам и гигантским элементам сенсорного интерфейса не только легко попасть — они еще и очень заметны: даже рассеянный пользователь без труда найдет нужную кнопку на экране мобильного устройства.
В идеале размер всех элементов сенсорного интерфейса должен составлять минимум 44 х 44. Но здесь, как и везде, зачастую приходится искать компромиссные решения. Даже размер стандартных элементов управления iPhone порой отклоняется от провозглашенных 44 пикселей. Например, размер клавиатурных кнопок составляет 44 точки в высоту и только 30 точек в ширину. При альбомной ориентации экрана ширина кнопок составляет 44 точки, а высота — 38 точек соответственно. Здесь у разработчиков Apple не так уже много пространства для маневра: крайне важно, чтобы вся QWERTY-клавиатура была на виду, а если задать для все клавиш размер 44 х 44, уместить их на одном экране не удастся. Чем-то приходится жертвовать.
Вот хорошее правило, которое помогает при разработке элементов сенсорного интерфейса в условиях ограниченного пространства. Если, например, ширина элемента интерфейса составляет хотя бы 44 точки, то высоту при необходимости можно ужать до 30 точек, и наоборот. Следовательно, реальный минимальный размер любого элемента сенсорного интерфейса должен составлять 44 х 30.
Не дави на меня
Автор данной статьи провел многие годы своей растраченной молодости в компании элегантных наручных часов-калькулятора Casio, с которыми окончательно расстался лишь в 1985 году. Кнопочки у них были просто крошечные, к тому же они помешали автору стать королем выпускного бала… но даже это нельзя назвать их главным недостатком. Дело в том, что вышеупомянутые кнопочки были расположены слишком уж тесно. Пытаешься нажать «5», а в итоге нажимаешь «2» или «8» — результат предугадать невозможно, чистая лотерея, а не калькулятор. Другими словами, размер кнопок — не единственный определяющий фактор: необходимо подумать и о расстоянии между кнопками.
Автор фотографии: Джон Роулинсон (Jon Rawlinson)
При разработке интерфейсов для устройств с маленькими экранами неизбежно приходится бороться с искушением решить проблему ограниченного пространства путем уплотненного расположения элементов интерфейса. «Подвинем вот это чуточку поближе… Добавим еще одну кнопочку к этой панельке инструментов. » Цитируя популярный девиз времен расцвета часов-калькуляторов: «Просто скажи «нет»».
Чем ближе расположены кнопки, тем больше они должны быть. Рассмотрим пару приложений для VoIP-телефонии для iPhone: Skype и Call Global App. В обоих приложениях кнопки клавиатуры расположены довольно тесно, но это компенсируется их размером, который значительно превосходит вышеуказанный минимум 44 х 44. Так что, несмотря на довольно тесное соседство кнопок, попасть по ним сравнительно легко.
Однако эти приложения не во всем идентичны: давайте посмотрим на нижнюю часть экрана. В обоих приложениях кнопки расположены поверх панели навигационных вкладок: такое расположение, как уже обсуждалось выше, всегда создает некоторые трудности для пользователя. Но в Skype (слева) за счет внушительного размера кнопок недостатки дизайна сглаживаются. А вот в приложении Call Global App кнопки над панелью закладок слишком узкие, и их тесное расположение приведет к ошибкам пользователей. Несмотря на то что фактически размер этих кнопок превышает заявленный минимум 44 х 30, недостаток пространства между ними и само их расположение внизу экрана играют свою роковую роль. Здесь нам нужны большие кнопки и более свободное расположении элементов интерфейса.
Давайте сделаем вывод. Хотя это может показаться противоречащим здравому смыслу, эффективность интерфейсов для устройств с небольшими экранами обеспечивается крупными элементами интерфейса и достаточным количеством пространства между ними. Да, экраны устройств могут быть действительно маленькими, но наши пальцы (как и объем нашего внимания) не так уж малы. Так что не забывайте о толстых пальцах при разработке.