Дизайн с Device API, учитывающий окружающую среду
Если вы когда-нибудь стояли на стуле и держали сотовый телефон на вытянутой руке, чтобы сигнал был получше или обновляли страницу, которая зависла на 30 секунд, то вы уже знаете, что в опыте взаимодействия пользователя с устройствами есть серьёзные проблемы. Мы разрабатываем интерфейсы и это выливается в бесконечные переговоры, пользовательское тестирование, и аналитику, в которой мы утопаем с головой, и все это только для того, что бы все пошло насмарку из-за скверного сигнала от вышки сотовой связи.
Может быть, ваш пользователь переключился с 3G на WiFi. Может быть, у него садится батарейка. Может быть, вокруг него просто темно. Что бы ни произошло, факторы реальной жизни легко могут нарушить любые ваши, даже самые благие намерения, и пользователи останутся разочароваными и разозлёнными.
Мысль, что в процессе планирования любой конструкции - надо принимать во внимание факторы реального мира, окружающего нас, не нова. Дизайн, учитывающий окружающий мир, появляется, как минимум, в 500 г. до н.э., когда древние греки начали строить дома, отапливаемые солнечной энергией, и этот дизайн покоится на двух “китах”: реальный мир существует, и вы не в силах его контролировать.
Конечно, вы не можете контролировать все факторы, когда пользователь работает с вашим дизайном, но вы определённо можете учитывать их, по крайней мере признав, что эти факторы имеют место. Я называю это - условиями дизайна. Некоторые условия дизайна, например, какое устройство использует пользователь — остаются одними и теми же на протяжении единичного посещения или взаимодействия с вашим продуктом. Однако, такие условия, как например, потребление энергии, освещение, мощность сигнала обладают возможностью (а иногда и тенденцией) меняться на протяжении одного посещения или даже при переходе от одной страницы к другой.
Всего лишь год назад, у меня не было бы определенного решения этих проблем в интерфейсах для пользователей, поскольку нужные для этого API, на уровне устройств, еще не были готовы для запуска. Но сейчас мы можем начать делать что-то, чтобы повысить уровень комфорта пользователей даже в этих меняющихся условиях, благодаря последним разработкам Device API.
Что такое Device API?
Device API начала разрабатываться в июле 2011 г., когда Mozilla и доктор Андреас Галь (Andreas Gal) создали Boot2Gecko, операционную систему, полностью построенную на веб-технологиях. Интересным в этой ОС было то, что Mozilla также разрабатывала JavaScript-API, которые позволяли браузеру получать доступ к функциям на уровне устройства.
Некоторые из этих API остались внутри операционной системы Boot2Gecko, но большая часть проделанной работы была передана в W3C для стандартизации. На этой работе мы и сфокусируемся сегодня: мы исследуем эти API и тот потенциал, который они несут в себе, чтобы улучшить поведение нашего продукта в реальном мире и в различных состояниях окружающей среды, важных для дизайна.
Состояние батареи и информация о сети
Отзывчивый дизайн сэкономил нам немало нервов. Но также, с принятием этой парадигмы, на первый план вышли новые занимательные задачи: например, управление ресурсами. Что мы будем делать с изображениями, чтобы они масштабировались правильно в любых условиях, даже на маленьких экранах или же в условиях медленного соединения?
Если бы проблема состояла только в том, что «на маленьких экранах надо выводить маленькие изображения», тогда вся проблема изображений в отзывчивом дизайне решалась бы элементом picture. Но предполагается также, что на маленький экран мы должны подать маленькое изображение, чтобы оно соответствовало его размеру и вероятному ограничению скорости соединения. Как ни крути, мы начинаем понимать, что размер экрана имеет минимальное отношение к скорости сети.
В идеале, все пользователи пользуются высокоскоростным соединением и, естественно, имеют в запасе полностью заряженнкю батарею. Но чем больше людей используют мобильные устройства, тем менее вероятным это становятся, и тем чаще эти условия будут влиять на впечатление пользователя от вашего продукта. Если пользователь кликает по страницам на быстром соединении, то изображения с маленьким разрешением он воспримет как плохой дизайн. С другой стороны, если у пользователя плохое соединение и разряженная батарея, то, пока он будет скачивать огромные изображения, телефон может и вовсе отключиться.
Именно в таких ситуациях Battery Status API и The Network Information API становятся особенно интересными.
Battery Status API рассказывает вам, сколько осталось заряда батареи в устройстве
(level), становится ли уровень заряда меньше (discharging) или больше (charging).
Эта информация приводится не только как переменные во время загрузки, но ещё и через
события, привязанные к статусу батареи. События, которые сейчас включены в спецификацию: onchargingchange, onchargingtimechange,
ondischargingtimechange и onlevelchange.
Всё это становится ещё интереснее, когда используется в паре с Network Information API,
которая позволяет вам получить данные о скорости соединения. В текущей версии спецификации
устройство возвращает два значения: скорость соединения в мегабайтах в секунду и булеву
переменную, с помощью которой вы можете узнать, ограничивается ли скорость соединения
каким-либо образом провайдером. Вот и вся информация, которая нужна вам для того, чтобы
фильтровать ресурсы и разбираться со скоростью соединения в браузере. Чтобы отслеживать,
когда пользователь теряет соединение, API возвращает в качестве значения скорости 0.
Хотя информация о сети и состояние батареи чудесно работают сами по себе, комбинация этих двух API даёт вам возможность не только управлять ресурсами во время загрузки страницы, но и изменять интерфейс по мере того, как изменяется скорость соединения или остаток заряда батареи. Вы можете даже проводить маленькие энергетические тесты, сколько времени батарея еще продержится при этих условиях (как «сколько километров вы проедете, пока не кончится бензин в машине»). У вас не получится выдать какую-то конкретную информацию («Facebook выедает вашу батарейку»), но, по крайней мере, вы будете знать достаточно ли заряда для того, чтобы закончить какую-нибудь задачу в вашем приложении.
Эти две API (а особенно их комбинация), скорее всего, должны стать нашей первой возможностью делать дизайны более приспособленными для “реальной жизни”. Они позволяют нам определять «бутылочные горлышки» производительности и создавать интерфейс, который обходит их (пример: наша задача с управлением изображениями). Но есть и несколько других API, которые выделяются среди остальных — это API датчика освещения и датчика приближения, которые выносят дизайн чуть дальше за пределы браузера.
Датчик освещения
Ambient Light Sensor API использует датчик освещения устройства, чтобы он рассказал
нам о текущих условиях освещения. Конечно, ограничение этого API состоит в том,
что у устройства должен быть датчик освещения — встроен он в камеру или в какой-либо
другой датчик. Неважно, где этот датчик находится, но он должен наличествовать. API
работает примерно так же, как API состояния батареи, то есть уровень света можно получить
во время первоначальной загрузки и с помощью события ondevicelight.
Это API может показаться немножко странным, так как в нем не используется привычная для
веб система единиц: px, % или em; API возвращает значения в люксах (lx).
Люкс - международная единица измерения мощности света. В целом, не совсем то, что мы
используем в вебе каждый день. Я, например, ни разу и не слышал о такой единице, пока не
стал заниматься этим API, но зато я чувствую себя Мега-Умником,
вставляя фразу о ней, то там то сям.
Поскольку это применяется только в самых современных устройствах, поддержка люксов несколько непредсказуема.
Ambient Light Sensor API наверняка улучшит опыт использования электронной книги, вроде Kindle, поскольку, та предоставляет доступ к информации об уровне освещенности в помещении. Обладая этой информацией, вы можете легко настроить значения цветов, типографику и другие элементы дизайна, чтобы обеспечить пользователям более удобные условия для чтения.
Датчик приближения
Proximity Sensor API, которая дает браузеру возможность коммуникации ближнего поля (NFC), скорее всего, на сегодняшний день наиболее далека от возможности её использования. И не из-за плохой спецификации, а потому что у большинства устройств ещё нет необходимых датчиков. Лишь в относительно малое число смартфонов прямо сейчас встроена NFC-технология, и понадобится наверняка еще несколько поколений устройств, пока мы не увидим её в чем-нибудь вроде iPhone.
Если устройство пользователя содержит датчик приближения, вы можете воспользоваться им, чтобы
обнаружить близлежащие предметы, которые предоставляют NFC-информацию (круто, не правда ли?).
В API включено событие ondeviceproximity,которое вызывается, когда предмет оказывается в
радиусе действия датчика.
W3C не рекомендует пытаться точно измерить расстояние до предмета из-за непостоянства текущих датчиков. Но вы, тем не менее, можете еще дальше расширить границы пользовательского интерфейса: всего несколькими строчками кода вы можете вырваться из узкого пространства браузера и вставить в интерфейс огромный настоящий мир интерактивных предметов, светочувствительности, информации о соединении и потреблении энергии.
Как развивать дизайн, учитывающий окружающую среду?
Дизайн, учитывающий окружающую среду — это просто концепт, в котором мы начинаем принимать во внимание внешние факторы. Появление Device API - это только первый шаг.
Каждый день появляются новые API, которые можно творчески использовать в своих приложениях , но не стоит ограничиваться ими. Мы уже знаем, что опыт использования приложения в разных браузерах может отличаться, но я бы сказал, что он может быть разным и в каждой комнате вашего дома. С изменением скорости соединения, заряда батареи и других условий может изменяться и поведение вашего приложения.
Разбираться с хаосом внутри браузеров, для большинства из нас, постоянная работа. Поэтому у нас есть тестирование и контроль качества. Ключ к развитию веб и созданию отличных интерфейсов — научиться “принимать” хаос, а не тратить время, борясь с ним. Оберните это безобразие и хаос в свою пользу и пополняйте свою коробочку инструментов проектировщика интерфейсов: если все мы будем делать так, мы поможем веб-технологиям двигаться в правильном направлении.
