Ввод данных и сенсоры

Ввод данных и сенсоры

Файлы к данной лекции Вы можете скачать здесь.

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

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

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

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

Windows спроектирована для хорошей работы со всеми формами ввода – для отличной работы с сенсорным экраном, мышью, клавиатурой, и все это – на разном аппаратном обеспечении! (И сертификация для Магазина Windows требует, чтобы все приложения обладали этими возможностями.) По этоим причинам, Windows предоставляет унифицированную, основанную на указателе (pointer) модель, где вы можете дифференцировать различные способы ввода, если нужно, но можете обрабатывать их все равнозначно. Так же вы можете сосредоточиться на жестах высокого уровня, которые могут исходить из многих источников ввода, и совсем не беспокоиться об исходных событиях указателя. На самом деле, тот факт, что мы не поднимали до сих пор этот вопрос, показывает, как естественно можно работать со всеми видами указателей ввода и не беспокоиться о них: элементы управления и другие части пользовательского интерфейса, которые мы использовали, выполняют за нас всю подобную работу. Необходимость в обработке подобных событий возникает преимущественно при создании собственных элементов управления или для выполнения прямых манипуляций с объектами, которые не являются элементами управления.

Клавиатура – это важный инструмент для ввода данных, это относится и к аппаратной клавиатуре, и к экранной "программной" клавиатуре. Последней уделяется много внимания в наше время, в плане устройств, обладающих лишь возможностями сенсорного взаимодействия с пользователем, но, на самом деле, основные вопросы касались доступности. В Windows, так же, программная клавитура включает в себя возможности распознавания рукописного текста, иногда приложения просто включают в себя эту возможность. И когда приложение нуждается в более плотной работе с исходными данными рукописного ввода (ink), оно так же может воспользоваться этими возможностями.

Другая тема, которой мы коснемся в этой лекции, касается датчиков (сенсоров). До тех пор, пока вы не узнаете, что это за датчики, может показаться непоследовательным помещать эту тему вместе с темой о вводе данных. Датчики, вместе с сенсорным экраном – это еще один способ ввода данных. Сенсоры сообщают приложению, что происходит с устройством во внешнем мире: как оно расположено в пространстве (относительно некоторого количества опорных точек), как оно перемещается в пространстве, как оно расположено по отношению к "нормальной" ориентации, и даже то, насколько яркий свет освещает устройство. Видя сенсоры в таком свете (преднамеренный каламбур), мы начинаем видеть возможности прямой интеграции приложений с окружающим миром вместо того, чтобы нуждаться в том, что пользователь сообщит приложению о внешних условиях каким-то абстрактным способом. Хочу предупредить вас, что как только вы увидите, как легко использовать API WinRT для работы с датчиками, вам может захотеться купить новое устройство, которое хорошо ими оснащено!

Ввод данных с помощью мыши, прикосновений и пера

Когда речь идет о вводе данных, основанном на указателе, что включает в себя ввод данных с помощью мыши, касаний, ручки и пера – особое сообщение от Microsoft имело и имеет актуальность: "Дизайн приложений, использующих мышь, касания, перо – без дополнительных усилий". Это – очень важно, как мы увидим дальше, но мы так же обнаружили, что фразы вроде "дизайн, ориентированный на касания" ("first-touch design"), хорошо звучащие для потребителей, может выглядеть пугающей для разработчиков! Когда все внимание обращено на взаимодействие с помощью касаний, нужно учитывать, что пользователи весьма требовательны в своих ожиданиях, и для соответствия продукта этим ожиданиям может потребоваться много работы.

К счастью, Windows 8 предоставляет единую платформу для обработки указателя ввода из всех источников, в итоге, вам не нужно особо задумываться об их различиях до тех пор, пока у вас не будет особых причин сделать это. Таким образом, проектирование приложений с учетом соображений дизайна, ориентированного на касания, это – больше вопрос дизайна, чем вопрос программирования.

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

• Во-первых – используйте шаблоны и стандартные элементы управления, и вы получите возможности сенсорного ввода без дополнительных усилий, вместе с поддержкой мыши, ручки, пера и клавиатуры. Если вы создаете собственный пользовательский интерфейс на основе стандартных элементов управления, установите соответствующие атрибуты tabindex для тех пользователей, которые будут применять клавиатуру, назначьте обработчики для стандартных событий DOM, наподобие click, и все готово. Элементы управления наподобие элемента для контекстного масштабирования уже обрабатывают различные виды ввода (как мы видели в лекции 5 курса "Введение в разработку приложений для Windows 8 с использованием HTML, CSS и JavaScript"), CSS-стили, наподобие точек прикрепления и масштабирования контента обрабатывают различные жесты взаимодействия с приложением.
• Во-вторых, если вам нужно обрабатывать жесты самостоятельно, например, в пользовательском элементе управления, или в других элементах, с которыми пользователь может взаимодействовать напрямую, используйте события жестов, наподобие MsGestureTap и MsGestureHold, вместе с последовательностями событий для жестов, использующих инерцию (MSGestureStart, MSGestureChange, и MSGestureEnd). Преимущество здесь в том, что эти жесты представляют собой высокоуровневую интерпретацию низкоуровневых событий указателя, что означает, что вам не нужно выполнять подобную интерпретацию самостоятельно. Например, касание (down) с последующим отрывом, поднятием (up) указателя в пределах определенного порога передвижения (для того, чтобы учеcть шевеление пальцев) становится единым жестом касания (tap). Касание, за которым следует короткое перетаскивание (drag), после чего указатель поднимается, становится жестом прокрутки (swipe), которое вызывает последовательность событий, возможно, включающих события, указывающие на инерцию (те, которые продолжают вызываться, даже после того, как указатель, наподобие точки касания, физически освобожден). Обратите внимание на то, что если вы хотите захватить и сохранить данные ввода указателя, не обращая внимание на жесты, есть встроенная возможность для рукописного ввода (inking), позже мы ее рассмотрим.
• В-третьих, если вам нужно напрямую обрабатывать события указателя, используйте унифицированные события указателя, наподобие MsPointerDown, MsPointerMove и так далее.Это – события более низкого уровня, чем события жестов, и они, преимущественно, подходят для приложений, которые не нуждаются в интерпретации жестов. Например, приложению для рисования нужно просто отследить различные указатели и отобразить их на экране, здесь концепции наподобие прокрутки и инерции значения не имеют. События указателя так же предоставляют специфическую информацию от устройств – такую, как давление, поворот, сдвиг, и они отражаются в событиях указателя. Напомню, возможно реализовать обработку жестов на основе прямой обработки событий указателя, как делает большое количество встроенных элементов управления.
• И, наконец, приложение может работать напрямую со средством распознавания жестов (gesture recognizer) для того, чтобы обеспечить собственный перевод событий указателя в жесты.

А что же о традиционных событиях DOM, которые мы знаем и любим, помимо click? Можете ли вы продолжать работать с mousedown, mouseup, mouseover, mousemove, mouseout, и mousewheel? Ответ положителен, так как события указателя от всех источников ввода данных автоматически транслируются в эти традиционные события. Это может быть полезно при портировании кода веб-приложения в код приложения для Магазина Windows, например. Подобная трансляция занимает, однако, дополнительное процессорное время, поэтому новый код, не использующий данные события, отличается лучшей производительностью из-за прямого использования жестов и событий указателя. Традиционные события мыши, кроме того, подразумевают наличие единственного указателя и генерируются только для основной точки касания (с установленным свойством isPrimary ( http://msdn.microsoft.com/library/windows/apps/Hh972358.aspx )). Используйте в коде жесты и события указателя так часто, как сможете.

Примечание. Визуальная обратная связь для сенсорного ввода – это одно из требований к сертификации приложений для Windows 8 (раздел 3.5., http://msdn.microsoft.com/library/windows/apps/hh694083.aspx ), она применима везде в ваших приложениях, так же, как и к любому веб-содержимому, которые вы можете отображать в элементе iframe. Предоставление обратной связи подразумевает исполнение короткой анимации, которая подтверждает касание. Для этих целей вы можете использовать библиотеку анимаций WinJS или, напрямую, CSS-анимации и переходы, как описано в "Мультимедиа" .