Мир, для которого мы разрабатываем, меняется довольно быстрыми темпами. На этот раз в прошлом году мобильная сеть была горячей темой. Мы все создавали оптимизированные версии наших сайтов и приложений для портативных устройств и удивлялись тому, насколько мы можем сделать их похожими на нативные приложения для iPhone.
Вскоре после этого, когда платформа Android стала популярной, мы поняли, что не следует привязывать наши интерфейсы так близко к конкретному устройству. Потому что, ну, не у всех есть iPhone. Дизайн мобильного сайта или приложения, как если бы он был частью армии Apple, может снизить общее восприятие для большинства наших пользователей. Таким образом, мы начали раскручивать себя в мобильном дизайне, так же, как и в случае с рабочим столом.
Методы, которые мы используем для обнаружения устройств, стали во многом стандартом, и их редко подвергают сомнению. Мы либо обнаруживаем серверную сторону и отправляем пользователя на другой сайт, оптимизированный для мобильного устройства, либо используем медиазапросы для определения размера экрана и соответствующей корректировки дизайна.
Но, как писал Бертран Рассел: «Во всех делах время от времени полезно ставить знак вопроса о вещах, которые вы давно считаете само собой разумеющимся».
Я здесь, чтобы сообщить вам, что есть еще один шаг к созданию идеального пользовательского опыта: обнаружение касаний.
Текущее состояние обнаружения
Существует два способа доминирования в сцене наилучшей практики для определения, находится ли пользователь на мобильном устройстве. Первый, который существует уже некоторое время, — это обнаружение на основе устройств на стороне сервера. И второе — использование медиазапросов CSS для определения размера экрана. Конечно, у обоих этих методов есть свои плюсы и минусы. Итак, давайте посмотрим, не так ли?
Обнаружение для устройства
Обнаружение устройства может быть очень эффективным способом нацеливания на конкретных пользователей. Обычно это делается путем ввода строки User-Agent и чтения ее по определенным ключевым словам (например, «iphone»). При этом вы можете указать, какое устройство используется для просмотра вашего сайта или приложения, и изменять свой дизайн для каждого случая.
Преимущества
Запуск сценария обнаружения на сервере определенно имеет свои преимущества. В любом случае, в 99 раз из 100 сервер будет работать быстрее, чем клиент, поэтому выигрыш в производительности очевиден, и вы получаете гораздо больший контроль над возвращаемыми данными. Как правило, если у вас нет контролируемой или целевой среды, ее редко следует оставлять технологии, которая иногда отсутствует, например JavaScript. Еще одним преимуществом является то, что вы можете специально ориентироваться на любое количество устройств в вашей пользовательской базе. Например, если вы хотите, чтобы ваш iPhone и Android-устройства видели ваш оптимизированный дизайн, очень легко реализовать этот метод.
Вытащить User-Agent очень легко с PHP. Здесь мы просто повторяем это для целей отладки:
<? php echo $ _SERVER ['HTTP_USER_AGENT']; ?>
Недостатки
Недостатки этого метода — именно то, что вызвало мой поиск другого пути. В идеале при разработке дизайна для мобильных устройств вы хотели бы нацелить их всех и создать гибкий и согласованный интерфейс. Вот в чем проблема. При использовании любого рода устройств обнаружения будет сложно эффективно масштабировать. Через некоторое время вы обнаруживаете, что пытаетесь управлять списком из 20-30 поддерживаемых устройств, и если устройство отсутствует в этом списке, оно не будет поднято.
Другая проблема, с которой вы можете столкнуться — частичные совпадения строк User-Agent . Я обнаружил это во время создания мобильного сайта и заметил, что Opera по каким-то причинам подбирает мой мобильный дизайн. Посмотрев его, я обнаружил, что строка Opera User-Agent содержит слово «Presto», которое является его механизмом рендеринга. К сожалению, это вызвало проблемы с User-Agent «Palm Pre» из-за пред. По мере расширения диапазона доступных устройств, я думаю, мы увидим гораздо больше проблем такого типа с обнаружением устройств на стороне сервера.
Определение размера экрана
В настоящее время определение размера экрана (или окна) выполняется с помощью медиазапросов CSS. Как правило, запросы встраиваются прямо в основную таблицу стилей (хотя они могут быть отдельными) и могут быть разбиты на столько размеров экрана, сколько вам нужно. Большинство людей работают с двумя или тремя. Если вы хотите узнать больше о медиа-запросах, ознакомьтесь со статьей Ethan Marcotte об отзывчивом веб-дизайне в A List Apart .
Преимущества
Использование медиазапроса — это очень быстрый и легкий способ нацелить пользователя на экран меньшего размера. Это здорово, потому что они применимы не только к мобильным устройствам, но и к любому устройству с меньшим экраном, например нетбуку. Они очень помогают в предотвращении горизонтальной прокрутки, не говоря уже о том, что пользователь, возможно, чувствует себя стесненным при использовании меньшего окна браузера, в то же время представляя удобный дизайн.
Недостатки
Как бы нам этого ни хотелось, маленький экран не обязательно означает сенсорное устройство. Даже небольшой экран, поддерживающий медиазапросы, может не быть сенсорным устройством. Таким образом, хотя этот метод может очень хорошо работать для общего дизайна и макета, он в основном не переносится в дизайн интерфейса. Некоторые взаимодействия с пользователем, такие как перетаскивание, отлично работают на устройстве с небольшим экраном — при условии, что есть указательное устройство. С устройством только для прикосновения перетаскивание крайне неадекватно. Существует также вероятность того, что медиа-запросы могут не поддерживаться данным устройством. В зависимости от вашей аудитории, вы можете изучить другой вариант.
Зачем нам нужен другой путь
Мы установили, что два наиболее популярных метода обнаружения мобильных устройств, которые у нас есть сейчас, имеют свои недостатки: один трудно масштабируется, а другой плохо поддается дизайну интерфейса.
Давайте сделаем шаг назад и спросим себя, с какими устройствами мы имеем дело. По сути, любое устройство, которое имеет небольшой размер экрана, сенсорный экран или оба, должно быть целью для специально адаптированного интерфейса. Технически это охватывает довольно много устройств, но на самом деле мы говорим об этих конкретных категориях:
-
сенсорные планшеты (включая iPad)
-
нетбуки
-
современные мобильные телефоны или устройства
Разница между iPad (или другими сенсорными планшетами) и нетбуками является прекрасным примером того, где одни только медиа-запросы не будут соответствовать дизайну интерфейса. IPad и обычный нетбук будут иметь примерно одинаковый размер экрана, поэтому медиа-запросы хорошо работают для макета; однако сенсорные возможности iPad мешают многим элементам интерфейса приложения, которые мы воспринимаем как должное. И мы должны учитывать это, чтобы создать наилучший возможный опыт.
Что мы теряем с сенсорным интерфейсом
Сенсорные интерфейсы потрясающие, верно? Они волна будущего. Но способ, которым мы взаимодействуем с устройством с сенсорным экраном, сильно отличается от того, как мы взаимодействуем с устройством без сенсорного экрана. Это выходит далеко за рамки обычных компенсаций, таких как добавление дополнительных отступов вокруг ссылки, чтобы создать большую область попадания для пальца человека, или учет отсутствия мыши.
При разработке в сенсорной среде мы теряем некоторые из более богатых элементов интерфейса, которые мы полюбили; например, состояния при наведении, перелистывание внутренних страниц и перетаскивание.
Если мы сосредоточимся на возможностях, а не на ограничениях, мы сможем избежать использования менее привлекательного интерфейса для учета этих новых устройств. Причина, по которой перетаскивание не работает на сенсорном устройстве, не в том, что это не имеет смысла; это потому, что действие нажатия пальца на экран и его перемещения уже имеет стандартное поведение: прокрутка. Тот же принцип действует для сжатия пальцев, чтобы действовать как масштабирование всей страницы на большинстве современных сенсорных устройств. Таким же образом мы можем предотвратить срабатывание ссылки с помощью оператора return false , мы можем предотвратить прокрутку или масштабирование движения пальца.
Создание богатого опыта
Так что у нас это. Медиа-запросы позволяют нам ориентироваться на размеры экрана устройства с помощью конкретных версий наших макетов, но они не работают, когда речь идет о предоставлении специализированных интерфейсов для сенсорных и не сенсорных устройств. После того, как мое разочарование достигло точки разрыва с iPad, я решил провести старомодное исследование, чтобы выяснить, есть ли способ определить, имеет ли устройство сенсорные возможности. После нескольких часов изучения документации для разработчиков Safari я обнаружил небольшой раздел, в котором описывается объект Touch и способы обработки определенных событий. Вот что я нашел.
Как обнаружить сенсорный
Safari предлагает нам JavaScript-объект события под названием Touch , и единственная обязанность этого маленького парня — сообщить вам, что устройство, с которым вы работаете, имеет адаптивный интерфейс с сенсорным экраном. Это был Святой Грааль, именно то, что я искал, когда начал возиться. Само собой разумеется, я выродил.
Реализация удивительно проста:
if (window.Touch) {/ * JavaScript для вашего сенсорного интерфейса * /}
После того, как вы обнаружите сенсорные возможности, вы можете внести всевозможные корректировки в дополнение к интерфейсу. Недостатком (вы не думали, что это будет так просто, не так ли?) Является то, что он работает только на устройствах Apple прямо сейчас.
Конечно, есть и другой способ: вы можете выполнять распознавание касаний при первом касании экрана. Это далеко от идеала, но это все еще эффективный способ обнаружения касания на устройстве. Этот метод также более широко поддерживается на большинстве современных устройств. Недостатком является то, что вы не можете положиться на него для серьезных изменений в вашем дизайне; это привело бы к внезапному преобразованию страницы, как только пользователь коснулся экрана. Но если, как мы уже говорили, вам нужно в основном обнаружение касаний, чтобы настроить расширенные взаимодействия, такие как состояния при наведении или перетаскивание, вы сможете это сделать:
var touch_detect = {обработчик: функция (событие) {/ * JavaScript для вашего сенсорного интерфейса * /}}; document.ontouchstart = touch_detect.handler;
Обнаруживая прикосновение таким образом, мы можем делать все: от переключения специальных классов до компенсации отсутствия элементов управления при наведении, до создания совершенно нового интерфейса, который фокусируется на использовании преимуществ богатых возможностей устройства.
Мы также можем отслеживать движение или поведение с помощью соответствующих событий JavaScript: ontouchmove , ontouchend , ontouchcancel , orientationchange , gesturestart , gesturechange и gestureend . Все эти события были доступны на устройствах Apple начиная с iPhone OS 2.0. Только некоторые из этих действий имеют поддержку Android на данный момент, например, ontouchstart , так что это безопасно для использования.
Когда мы объединяем этот метод обнаружения с медиазапросами CSS, мы можем создавать очень быстрые, быстро реагирующие и запоминающиеся приложения. Они не ограничиваются только телефонами, но могут быть развернуты везде одним махом. Сборка однажды и развертывание везде.
Поведение по умолчанию
Теперь, когда вы знаете, является ли устройство сенсорным или нет, вы можете приступить к созданию интерфейса специально для этого устройства. Но прежде чем мы это сделаем, есть несколько относительно глобальных поведений по умолчанию на сенсорных устройствах, которые нам нужно будет перезаписать, как уже упоминалось ранее (без каламбура). В основном это прокрутка пальцами и масштабирование, которые могут повлиять на любые операции перетаскивания или специальные действия по перемещению пальцев, которые мы можем захотеть создать. Тем не менее, мы хотим избежать глобального отключения этих режимов, потому что они все еще очень полезны. Вместо этого мы будем отключать их поэлементно, используя прослушиватели событий.
event.preventDefault() движение пальца и захватывая его, мы можем предотвратить прокрутку по умолчанию с помощью метода event.preventDefault() jQuery и вставить все, что захотим.
Вот пример, объединяющий обнаружение касания с прослушивателями событий для предотвращения действий по умолчанию:
$ (function () {if (window.Touch) {touch_detect.auto_detected ();} else {document.ontouchstart = touch_detect.surface;}}); // Завершить загрузку jQueryvar touch_detect = {auto_detected: function (event) {/ * добавить сюда все, что вы хотите сделать onLoad (например, активировать элементы управления при наведении) * / alert ('это было обнаружено автоматически'); activateTouchArea (); }, surface: function (event) {/ * добавьте все, что вы хотите сделать, на сенсорный запуск здесь (например, перетаскивание) - вы можете запустить это в обоих местах * / alert («это было обнаружено касанием»); activateTouchArea (); }}; // touch_detectfunction activTouchArea () {/ * убедитесь, что наш экран не прокручивается при перемещении «сенсорной области» * / var element = document.getElementById (' element_id '); element.addEventListener ("touchstart", touchStart, false);} функция touchStart (событие) {/ * modularize предотвращает поведение по умолчанию, поэтому мы можем использовать его снова * / event.preventDefault ();}
Вы можете видеть, что мы добавляем прослушиватель событий для события touchstart . Когда это происходит, мы вызываем функцию touchStart() , которая отключает поведение по умолчанию (прокрутка и масштабирование) для любого элемента, к которому присоединен слушатель. Этот элемент может быть div , ссылкой, перетаскиваемой областью — что угодно. Это позволит вам работать с элементом, не беспокоясь о странном поведении.
Поддержка сенсорного обнаружения
В настоящее время объект Touch доступен только в продуктах Apple (iPod, iPad, iPhone), но обнаружение смахивания и использование события ontouchstart доступны на ряде современных устройств, включая устройства Android. У меня не было возможности полностью протестировать новую Blackberry.
Если бы мне пришлось угадывать, я бы сказал, что объект Touch должен появиться на большинстве устройств в ближайшем будущем. Это просто имеет смысл, и это уже в WebKit Safari; это короткий путь, чтобы превратить его в Chrome, Android и WebOS.
Заглядывая вперед с дизайном интерфейса
В каждом дизайне или технике разработки будут прорезаны отверстия; Там нет идеальных решений там. Лучшие практики будут развиваться вместе с основными технологиями. Если мы сможем предпринять некоторые дополнительные шаги для создания наилучшего опыта для наших пользователей, мы сможем внедрить уровень взаимодействия, который кажется настолько естественным, что он практически невидим. В конечном счете, лучший пользовательский опыт — это тот, о котором мы никогда не слышали.