Впервые вместе снова
Введение
На протяжении почти тридцати лет настольные компьютеры концентрировались вокруг клавиатуры и мыши или трекпада в качестве основных устройств пользовательского ввода. Однако за последнее десятилетие смартфоны и планшеты принесли новую парадигму взаимодействия: прикосновение. С появлением компьютеров под управлением Windows 8 с сенсорным экраном, а теперь и с выпуском потрясающего Chromebook Pixel с сенсорным экраном, сенсорное управление теперь становится частью ожидаемого взаимодействия с настольным компьютером. Одной из самых больших проблем является создание интерфейса, который работает не только на сенсорных устройствах и устройствах с мышью, но и на этих устройствах, где пользователь будет использовать оба метода ввода — иногда одновременно!
Эта статья поможет вам понять, как сенсорные возможности встроены в браузер, как можно интегрировать этот новый механизм интерфейса в существующие приложения и как сенсорный ввод может хорошо сочетаться с вводом с помощью мыши.
Состояние взаимодействия с веб-платформой
iPhone был первой популярной платформой, в веб-браузер которой были встроены специальные сенсорные API. Несколько других поставщиков браузеров создали аналогичные интерфейсы API, созданные для совместимости с реализацией iOS, которая теперь описывается спецификацией «Touch Events version 1» . События касания поддерживаются Chrome и Firefox на настольном компьютере, а также Safari на iOS и Chrome и браузером Android на Android, а также другими мобильными браузерами, такими как браузер Blackberry.
Мой коллега Борис Смус написал отличное руководство по HTML5Rocks по событиям Touch , которое по-прежнему является хорошим способом начать работу, если вы раньше не изучали события Touch. На самом деле, если вы раньше не работали с событиями касания, прочитайте эту статью сейчас, прежде чем продолжить. Давай, я подожду.
Все сделано? Теперь, когда у вас есть базовые знания о сенсорных событиях, проблема с написанием сенсорных взаимодействий заключается в том, что сенсорные взаимодействия могут сильно отличаться от событий мыши (и эмулирующих мышь трекпада и трекбола) – и хотя сенсорные интерфейсы обычно пытаются подражать мышам, эта эмуляция не идеальна и не полна; вам действительно придется работать с обоими стилями взаимодействия и, возможно, придется поддерживать каждый интерфейс независимо.
Самое главное: у пользователя может быть сенсорный экран и мышь.
Многие разработчики создают сайты, которые статически определяют, поддерживает ли среда события касания, а затем делают предположение, что им нужно поддерживать только события касания (а не мыши). Теперь это ошибочное предположение — вместо этого наличие событий касания не означает, что пользователь в первую очередь использует это устройство сенсорного ввода. Такие устройства, как Chromebook Pixel и некоторые ноутбуки с Windows 8, теперь поддерживают ОБЕИ методы ввода: мышью и сенсорным вводом, а в ближайшем будущем их станет еще больше. На этих устройствах для пользователей вполне естественно использовать и мышь, и сенсорный экран для взаимодействия с приложениями, поэтому «поддерживает сенсорное управление» — это не то же самое, что «не требует поддержки мыши». Вы не можете думать о проблеме так: «Мне нужно написать два разных стиля взаимодействия и переключаться между ними», вам нужно продумать, как оба взаимодействия будут работать как вместе, так и независимо. На моем Chromebook Pixel я часто использую трекпад, но я также протягиваю руку и прикасаюсь к экрану — в том же приложении или на странице я делаю то, что кажется наиболее естественным в данный момент. С другой стороны, некоторые пользователи ноутбуков с сенсорным экраном редко, если вообще когда-либо, используют сенсорный экран, поэтому наличие сенсорного ввода не должно отключать или препятствовать управлению мышью.
К сожалению, бывает сложно узнать, поддерживает ли среда браузера пользователя сенсорный ввод или нет; в идеале браузер на настольном компьютере всегда должен указывать поддержку событий касания, чтобы сенсорный дисплей можно было подключить в любое время (например, если сенсорный экран, подключенный через KVM, станет доступным). По всем этим причинам ваши приложения не должны пытаться переключаться между сенсорным экраном и мышью — просто поддерживайте оба!
Поддержка мыши и сенсорного экрана вместе
№1. Щелканье и постукивание — «естественный» порядок вещей
Первая проблема заключается в том, что сенсорные интерфейсы обычно пытаются имитировать щелчки мыши — очевидно, поскольку сенсорные интерфейсы должны работать с приложениями, которые раньше взаимодействовали только с событиями мыши! Вы можете использовать это как ярлык, потому что события «щелчка» будут продолжать запускаться независимо от того, щелкнул ли пользователь мышью или постучал пальцем по экрану. Однако с этим ярлыком есть несколько проблем.
Во-первых, вы должны быть осторожны при разработке более сложных сенсорных взаимодействий: когда пользователь использует мышь, она реагирует посредством события щелчка, но когда пользователь касается экрана, возникают события как касания, так и щелчка. Для одного клика порядок событий следующий:
- сенсорный старт
- сенсорное перемещение
- касание
- наведение курсора мыши
- перемещение мыши
- мышь вниз
- наведение курсора мыши
- щелкнуть
Это, конечно, означает, что если вы обрабатываете события касания, такие как Touchstart, вам необходимо убедиться, что вы также не обрабатываете соответствующее событие нажатия кнопки мыши и/или щелчка. Если вы можете отменить события касания (вызов метода предотвращения Default() внутри обработчика событий), тогда никакие события мыши не будут генерироваться для касания. Одно из наиболее важных правил обработчиков касаний:
Однако это также предотвращает другое поведение браузера по умолчанию (например, прокрутку) - хотя обычно вы полностью обрабатываете событие касания в своем обработчике и ХОТИТЕ отключить действия по умолчанию. В общем, вы либо захотите обрабатывать и отменять все события касания, либо избегать обработчика этого события.
Во-вторых, когда пользователь нажимает на элемент веб-страницы на мобильном устройстве, страницы, не предназначенные для мобильного взаимодействия, имеют задержку не менее 300 миллисекунд между событием Touchstart и обработкой событий мыши (mousedown). Это можно сделать с помощью Chrome. Вы можете включить «Эмулировать события касания» в инструментах разработчика Chrome, чтобы помочь вам тестировать сенсорные интерфейсы в системе без сенсорного управления!
Эта задержка предназначена для того, чтобы дать браузеру время определить, выполняет ли пользователь другой жест, в частности масштабирование двойным касанием. Очевидно, что это может быть проблематично в тех случаях, когда вы хотите иметь мгновенную реакцию на прикосновение пальца. Продолжается работа по ограничению сценариев, в которых эта задержка возникает автоматически.
Первый и самый простой способ избежать этой задержки — «сообщить» мобильному браузеру, что масштабировать вашу страницу не потребуется. Это можно сделать, используя фиксированную область просмотра, например, вставив на страницу:
<meta name="viewport" content="width=device-width,user-scalable=no">
Конечно, это не всегда уместно — это отключает масштабирование, которое может потребоваться из соображений доступности, поэтому используйте его экономно, если вообще используете (если вы отключите пользовательское масштабирование, вы можете предоставить какой-либо другой способ увеличения текста читаемость в вашем приложении). Кроме того, эта задержка не применяется к Chrome на устройствах класса настольных компьютеров, поддерживающих сенсорный ввод, и других браузерах на мобильных платформах, когда на странице имеются области просмотра, которые не масштабируются.
#2: События Mousemove не запускаются при прикосновении
На этом этапе важно отметить, что эмуляция событий мыши в сенсорном интерфейсе обычно не распространяется на эмуляцию событий перемещения мыши — поэтому, если вы создадите красивый элемент управления, управляемый мышью, который использует события перемещения мыши, он, вероятно, не будет работать с прикосновением. устройство, если вы специально не добавите обработчики TouchMove.
Браузеры обычно автоматически реализуют соответствующее взаимодействие для сенсорного взаимодействия с элементами управления HTML, поэтому, например, элементы управления диапазона HTML5 будут работать только тогда, когда вы используете сенсорное взаимодействие. Однако если вы реализовали свои собственные элементы управления, они, скорее всего, не будут работать при взаимодействии типа «щелкни и перетащи». на самом деле, некоторые часто используемые библиотеки (например, jQueryUI) еще не поддерживают такое сенсорное взаимодействие (хотя для jQueryUI существует несколько исправлений этой проблемы). Это была одна из первых проблем, с которыми я столкнулся при обновлении моего приложения Web Audio Playground для работы с сенсорным управлением — ползунки были основаны на jQueryUI, поэтому они не работали с взаимодействием щелчка и перетаскивания. Я перешел на элементы управления диапазоном HTML5, и они заработали. В качестве альтернативы, конечно, я мог бы просто добавить обработчики touchmove для обновления ползунков, но здесь есть одна проблема…
№3: Touchmove и MouseMove — это не одно и то же
Ловушка, в которую, как я видел, попадают некоторые разработчики, заключается в том, что обработчики touchmove и mousemove вызывают одни и те же кодовые пути. Поведение этих событий очень похоже, но слегка отличается — в частности, события касания всегда нацелены на элемент, где это касание НАЧАЛОСЬ, тогда как события мыши нацелены на элемент, который в данный момент находится под курсором мыши. Вот почему у нас есть события mouseover и mouseout, но нет соответствующих событий touchover и touchout — только touchend.
Самый распространенный способ, которым это может вас укусить, — это удалить (или переместить) элемент, к которому начал прикасаться пользователь. Например, представьте себе карусель изображений с обработчиком касания на всей карусели для поддержки пользовательского поведения прокрутки. По мере изменения доступных изображений вы удаляете некоторые элементы <img> и добавляете другие. Если пользователь начнет касаться одного из этих изображений, а затем вы удалите его, ваш обработчик (который находится в предке элемента img) просто перестанет получать события касания (поскольку они отправляются на цель, которая больше не является в дереве) — будет выглядеть так, будто пользователь удерживает палец в одном месте, даже если он переместил его и в конечном итоге убрал.
Конечно, вы можете избежать этой проблемы, избегая удаления элементов, которые имеют (или имеют предков, которые имеют) обработчики касания, пока касание активно. С другой стороны, лучшее руководство — вместо того, чтобы регистрировать статические обработчики touchend/touchmove, дождитесь получения события touchstart, а затем добавьте обработчики touchmove/touchend/touchcancel к цели события touchstart (и удалите их при завершении/отмене). Таким образом, вы продолжите получать события касания, даже если целевой элемент будет перемещен/удален. Вы можете немного поиграть с этим здесь — коснитесь красного поля и, удерживая клавишу Escape, удалите его из DOM.
№ 4. Нажмите и наведите указатель мыши.
Метафора указателя мыши отделяла положение курсора от активного выбора, и это позволяло разработчикам использовать состояния наведения, чтобы скрывать и показывать информацию, которая может иметь отношение к пользователям. Однако большинство сенсорных интерфейсов сейчас не распознают «наведение» пальца на цель, поэтому предоставление семантически важной информации (например, предоставление всплывающего окна «Что это за элемент управления?») на основе наведения — нет-нет, если вы также не дадите сенсорный способ доступа к этой информации. Вам нужно быть осторожным с тем, как вы используете наведение курсора для передачи информации пользователям.
Однако достаточно интересно то, что псевдокласс CSS :hover МОЖЕТ запускаться сенсорными интерфейсами в некоторых случаях — нажатие на элемент делает его :активным, пока палец опущен, а также приобретает состояние :hover. (В Internet Explorer :hover действует только тогда, когда палец пользователя опущен; в других браузерах :hover действует до следующего касания или движения мыши.) Это хороший подход к тому, чтобы всплывающие меню работали при касании. интерфейсы — побочным эффектом активации элемента является то, что также применяется состояние :hover. Например:
<style>
img ~ .content {
display:none;
}
img:hover ~ .content {
display:block;
}
</style>
<img src="/awesome.png">
<div class="content">This is an awesome picture of me</div>
При касании другого элемента элемент перестает быть активным, и состояние наведения исчезает, как если бы пользователь использовал указатель мыши и переместил его за пределы элемента. Возможно, вы захотите обернуть содержимое в элемент <a> , чтобы сделать его также вкладкой - таким образом, пользователь может переключать дополнительную информацию при наведении курсора мыши или щелчке, сенсорном касании или нажатии клавиши без использования JavaScript. необходимый. Когда я начал работать над тем, чтобы моя веб-аудио площадка хорошо работала с сенсорными интерфейсами, я был приятно удивлен тем, что мои всплывающие меню уже хорошо работали при касании, потому что я использовал такую структуру!
Вышеупомянутый метод хорошо работает как для интерфейсов на основе указателя мыши, так и для сенсорных интерфейсов. Это отличается от использования атрибутов «title» при наведении курсора, которые НЕ будут отображаться при активации элемента:
<img src="/awesome.png" title="this doesn't show up in touch">
№5: Точность касания и мыши
Хотя мыши концептуально оторваны от реальности, оказывается, что они чрезвычайно точны, поскольку базовая операционная система обычно отслеживает точную точность пикселей для курсора. Разработчики мобильных устройств, с другой стороны, поняли, что прикосновения пальцев к сенсорному экрану не столь точны, в основном из-за размера поверхности пальца при контакте с экраном (и частично потому, что ваши пальцы загораживают экран).
Многие люди и компании провели обширные исследования пользователей о том, как разрабатывать приложения и сайты, поддерживающие взаимодействие с помощью пальцев, и на эту тему было написано множество книг. Основной совет — увеличить размер сенсорных объектов за счет увеличения отступов и снизить вероятность неправильных касаний за счет увеличения полей между элементами. (Поля не учитываются при обнаружении касаний и щелчков, а заполнение включено.) Одним из основных исправлений, которые мне пришлось внести в Web Audio Playground, было увеличение размеров точек подключения, чтобы к ним было легче прикасаться. точно.
Многие производители браузеров, которые работают с сенсорными интерфейсами, также ввели в браузер логику, которая помогает нацеливаться на правильный элемент, когда пользователь касается экрана, и снижает вероятность неправильных щелчков мышью - хотя обычно это корректирует только события щелчка, а не перемещения (хотя Internet Explorer похоже, также изменяет события mousedown/mousemove/mouseup).
#6: Держите обработчиков касаний под контролем, иначе они сорвут ваш свиток
Также важно, чтобы обработчики касаний ограничивались только теми элементами, где они вам нужны; сенсорные элементы могут иметь очень высокую пропускную способность, поэтому важно избегать обработчиков касания на элементах прокрутки (поскольку ваша обработка может помешать оптимизации браузера для быстрой сенсорной прокрутки без зависаний — современные браузеры пытаются прокручивать поток графического процессора, но это невозможно). если им сначала нужно проверить с помощью javascript, будет ли каждое событие касания обрабатываться приложением). Вы можете посмотреть пример такого поведения.
Чтобы избежать этой проблемы, следует следовать одному совету: убедитесь, что если вы обрабатываете события касания только в небольшой части вашего пользовательского интерфейса, вы присоединяете обработчики касания только там (а не, например, в <body> страницы). ; Короче говоря, максимально ограничьте область действия ваших обработчиков касаний.
#7: Мультитач
Последняя интересная проблема заключается в том, что, хотя мы называем его «сенсорным» пользовательским интерфейсом, почти повсеместно на самом деле поддерживается Multi-touch, то есть API обеспечивают более одного сенсорного ввода одновременно. Когда вы начнете поддерживать сенсорный ввод в своих приложениях, вам следует подумать о том, как множественные касания могут повлиять на ваше приложение.
Если вы создавали приложения, в основном управляемые мышью, то вы привыкли создавать их не более чем с одной точкой курсора — системы обычно не поддерживают несколько курсоров мыши. Для многих приложений вы будете просто сопоставлять события касания с одним интерфейсом курсора, но большая часть аппаратного обеспечения, которое мы видели для сенсорного ввода на рабочем столе, может обрабатывать как минимум два одновременных ввода, а большинство нового оборудования, по-видимому, поддерживает как минимум 5 одновременных вводов. . Разумеется, при разработке экранной фортепианной клавиатуры вам понадобится возможность поддерживать несколько одновременных сенсорных вводов.
Реализованные в настоящее время API-интерфейсы W3C Touch не имеют API для определения количества точек касания, поддерживаемых оборудованием, поэтому вам придется использовать наилучшую оценку того, сколько точек касания понадобится вашим пользователям - или, конечно, обращать внимание на то, сколько точек касания точки вы видите на практике и адаптируете. Например, если в приложении для фортепиано вы никогда не видите более двух точек касания, вы можете добавить немного «аккордового» пользовательского интерфейса. API PointerEvents имеет API для определения возможностей устройства.
Подкрашивание
Надеемся, что эта статья дала вам некоторые рекомендации по общим проблемам при реализации сенсорного взаимодействия с мышью. Конечно, более важным, чем любой другой совет, является то, что вам необходимо протестировать свое приложение на мобильных устройствах, планшетах и комбинированных средах настольных компьютеров с мышью и сенсорным управлением. Если у вас нет оборудования с сенсорным экраном и мышью, используйте Chrome « Эмулировать события касания », чтобы протестировать различные сценарии.
Следуя этим рекомендациям, не только возможно, но и относительно легко создать привлекательный интерактивный интерфейс, который хорошо работает с сенсорным вводом, вводом с помощью мыши и даже с обоими стилями взаимодействия одновременно.