|
|
Люк Вроблевски
Сначала мобильные!
От партнера российского изданияЯ неизменно скептически отношусь к любым широковещательным заявлениям, особенно тем, что восхваляют какое-нибудь решение, объявляя его единственно верным. Поэтому, прочитав во введении к книге Люка Вроблевски «Сначала мобильные!» фразу «сайты и приложения должны проектироваться прежде всего с расчетом на мобильные устройства», усомнился в том, стоит ли мне читать ее целиком. Насторожило поспешное «прежде всего». Почему «прежде всего»? К каким сайтам и приложениям это относится, а к каким нет? На какую целевую аудиторию это рассчитано? Но все же фраза меня заинтриговала, и я продолжил читать, о чем нисколько не жалею. Огромное число приведенных в книге примеров убедительно свидетельствуют о наступлении новой эры — эры мобильных устройств. По крайней мере «там».
У нас же на рынке мобильных услуг дела обстоят пока не так блестяще — сказывается привычное отставание от Запада на два-три года. И все же динамика развития мобильного Интернета в России, изменение способов потребления информации, формирование новых привычек, связанных с использованием мобильных устройств, — все это красноречиво говорит о том, что «мобильная» эра не за горами и у нас. Число проектов растет день ото дня. «Российский рынок мобильных приложений в 2011 году вырос на 106 % и достиг объема в 355 миллионов долларов, — говорится в исследовании J’Son & Partners, предоставленном Digit.ru. — Наиболее популярны у пользователей игры и развлечения, на их долю приходится до 44 % закачек»[1].
В скором времени потребительские предпочтения изменятся, и готовиться к этому надо уже сегодня. Необходимо изучать, как целевая аудитория потребляет информацию и услуги через мобильные устройства, прогнозировать рост этого потребления и работать на опережение. Жизненно важно помнить: там, где сегодня нет выраженного спроса, завтра может возникнуть ажиотаж. И тогда, не сомневайтесь, придется тратить время и деньги на формирование в полном смысле слова своей, мобильной аудитории. Поэтому тем, кто отвечает за вопросы стратегического развития компаний, продуктов и услуг, советую дочитать эту книгу до конца. Она того стоит.
Приятного вам чтения.
С уважением,Евгений Храмов,директор по развитию,Корпорация РБС
ПредисловиеЛюк Вроблевски привык работать с данными. Так что начнем со статистики. Он написал 1372 статьи, сделал 190 презентаций и стал автором трех книг по вопросам юзабилити в мобильных приложениях и Сети, о взаимодействии с пользователями и о дизайне. Вы держите в руках его последнюю и, по моему мнению, самую важную книгу. А если приведенная статистика не произвела на вас впечатления, то примите к сведению, что Люк занимался всем этим в свободное от основной работы время, поскольку одновременно руководил дизайнерскими проектами некоторых известных интернет-компаний или вел собственные проекты.
Люк — опытный дизайнер, он прекрасно осведомлен обо всех новшествах в области мобильных приложений, к тому же умеет отлично излагать свои мысли. По части применения накопленных знаний ему повезло, ведь мобильные приложения — это направление, по которому движется и Сеть, и весь мир. Но еще больше повезло нам: ведь Люк не просто отлично разбирается в этих вопросах, он всегда ставит во главу угла интересы пользователя. А еще он отличный источник научной информации: за шестнадцать лет управления проектами он прочел тысячи технических документов, отчетов, статей, книг и других материалов. Весь его опыт отражен в этой книге.
Читать ее легко и приятно, хотя Люк рассказывает о крайне важных вещах. То, о чем он рассуждает, изменило принятый в моей компании подход к дизайну сайтов; то же наверняка произойдет и с вами. Книга «Сначала мобильные!» убедительна, потому что приведенные в ней данные и факты говорят сами за себя. Здесь вы также найдете множество практических советов: Люк очень внимателен к деталям, но при этом уважает и ваш интеллект, и ваш опыт.
Я полюбил эту книгу. Я счастлив, что именно нам повезло ее издать. Я надеюсь, что она займет достойное место на книжной полке каждого дизайнера и разработчика пользовательских интерфейсов. Мне очень хочется, чтобы в нашем деле нашло применение лучшее из опыта мобильных приложений: это поможет не только пользователям, но и нам самим. И чем больше моих коллег последует рекомендациям Люка, тем спокойнее я буду относительно будущего Сети.
Джеффри Зельдман,редактор сайта A List Apart, основатель компании Happy Cog
ВведениеИдея, рассматриваемая в этой книге, достаточно проста. Однако, как у многих других простых идей, у нее могут быть сложные и далеко идущие последствия. Эта идея способна изменить наше представление о персональном компьютере и о том, как мы используем Сеть. И при этом ее можно выразить в двух словах. С них и начнем.
Сначала мобильные!
На протяжении многих лет веб-разработчики создавали продукты и контент для стационарных компьютеров и ноутбуков. Если они и думали о мобильных устройствах, то уж точно не в первую очередь. Как ни обидно, но такой подход преобладал практически повсеместно. Странствия по Сети с помощью мобильных телефонов требовали значительных усилий: доступ в Интернет предопределили особенности самих устройств, а скорость была такой, что использование мобильного Интернета зачастую превращалось в бесконечное ожидание. За исключением жителей Японии, мало кто выходил в Сеть через мобильные телефоны; те же, кто на это решался, сталкивались с немалыми трудностями.
Однако за последние несколько лет произошли коренные изменения, и теперь невозможно даже представить, чтобы при создании веб-продукта разработчики ориентировались прежде всего на стационарные ПК. Создание приложений по принципу «сначала мобильные!» не только открывает новые перспективы для самих разработчиков, но и значительно помогает пользователям в работе с сайтом или приложением.
В этом и заключается суть нашей идеи. Сайты и приложения должны проектироваться прежде всего с расчетом на мобильные устройства. Это позволит:
• подготовиться к появлению новых возможностей мобильной связи, поскольку эта область стремительно развивается;
• сосредоточиться на правильных приоритетах для своих продуктов, учитывая ограничения, присущие дизайну для мобильных устройств;
• обрести инновационный опыт и новые навыки, связанные с мобильными устройствами и методами их использования.
Подход «сначала мобильные!» несет в себе ряд преимуществ даже в том случае, если использование мобильных платформ не входит в ваши ближайшие планы. Всего каких-нибудь полдня на «мозговой штурм» такого подхода — и, уверяю, вам откроются совершенно новые горизонты.
И это не просто слова. Некоторые из крупнейших компаний уже взяли на вооружение философию «сначала мобильные!». Председатель правления Google Эрик Шмидт советует: «Все очень просто — что бы вы ни делали, применяйте принцип „сначала мобильные!“» (http://bkaprt. com/mf/1).
Директор по дизайну Facebook Кейт Ароновитц говорит: «Мы начали использовать подход, при котором вначале думаем о мобильном вебе и только потом об обычном. Мы обнаружили, что дизайнеры мобильных приложений научились справляться с огромным количеством ограничений, и это учит нас по-новому относиться к приложениям для стационарных компьютеров» (http://bkaprt.com/mf/2).
Кевин Линч, главный технический директор Adobe, заявляет: «Нам необходимо переключиться на мышление в стиле „сначала мобильные!“… Это куда более значительная смена парадигмы, чем та, что потребовалась при появлении персональных компьютеров» (http://bkaprt.com/mf/3).
Эти и многие другие компании видят в принципе «сначала мобильные!» большое будущее. Но почему же мобильные приложения так важны, и если все так, с чего начинать их проектирование? Ответить на эти вопросы и призвана книга, которую вы держите в руках.
Несколько слов о книге
Я ценю ваше время, поэтому книга короткая и воды в ней нет. В первой части поясняется, почему подход «сначала мобильные!» стал в последнее время таким актуальным. Вторая часть рассказывает об отличиях мобильного веб-дизайна от обычного — ознакомившись с ней, вы сможете сегодня же приступить к созданию мобильных сайтов.
В книге нет программного кода. В мире существует немало программистов, способных куда лучше меня рассказать о практических вопросах мобильной веб-разработки. Здесь вы найдете нечто иное — рассказ о применении принципа «сначала мобильные!» в бизнесе, а также ряд идей и практических примеров, которые вы сможете использовать в процессе разработки веб-приложений для мобильных устройств.
Сразу оговорюсь, что иногда я буду использовать термин «мобильные веб-приложения» вместо более привычных определений, таких как «мобильный веб» или «мобильный сайт».
В сущности, речь всегда идет об одной и той же Всемирной паутине, различия же состоят в опыте работы с нею, основанном на особенностях устройств. Об опыте мы будем говорить много.
Что ж, я обещал, что повествование будет лаконичным, так давайте покончим со вступительной частью и перейдем к разговору о том, как небольшая идея позволяет достичь поистине грандиозных результатов.
Часть 1
Почему так важен принцип «сначала мобильные!»Все просто: проектирование для мобильных устройств не только готовит веб-дизайнеров к лавинообразному росту мобильного Интернета и связанных с ним новых возможностей, но и вынуждает сконцентрироваться на инновациях. Разумеется, подобное заявление нуждается в конкретизации. Об этом и пойдет речь в этой части книги.
РостПОЕЗДИВ В МЕТРО, побродив по торговому центру, понаблюдав за старшеклассниками, вы наверняка заметите новую эволюционную тенденцию в облике и поведении человеческой расы. Практически повсюду встречаются люди с маленькими светящимися экранами, буквально приросшими к ладоням! Слава богу, это не какая-то генетическая мутация — просто все они держат в руках мобильные устройства.
Если вам не известны последние статистические данные, кратко введу вас в курс дела: рынок мобильных устройств растет сумасшедшими темпами. (Да, я знаю, что это не научный термин.) Аналитики давно предсказывали, что мобильные устройства станут «новой великой идеей», и эти прогнозы начинают сбываться. Чтобы понять всю масштабность изменений, давайте все-таки обратимся к статистике.
• Предполагалось, что по объемам рынка смартфоны превзойдут ноутбуки и стационарные ПК в 2012 году.
На самом деле это случилось уже в последнем квартале 2010 года (рис. 1.1) — на два года раньше!
• Это означает, что все больше людей будут выходить в Сеть с мобильных устройств, а не со стационарных ПК и ноутбуков. Признаки таких изменений уже заметны.
В 2010 году в США количество домашних пользователей персональных компьютеров снизилось на 20 % по сравнению с 2008 годом. Почему? Мы проводим все больше времени в Сети, применяя для этого смартфоны и планшеты (http://bkaprt.com/mf/5).
• Вот еще одно доказательство: в ноябре 2010 года общее число посетителей, проверяющих свою почту на почтовых серверах, сократилось на 6 %, при этом тех, кто получал доступ к электронной почте через мобильные устройства, стало на 36 % больше (http://bkaprt.com/mf/6).
• Трафик на мобильных сайтах в 2010 году вырос на 600 % по сравнению с уровнем предыдущего года (http://bkaprt. com/mf/7).
• И все это лишь начало. Если в 2009 году доступом к мобильному Интернету пользовались полмиллиарда человек, то к 2013 году эта цифра вырастет до миллиарда (http://bkaprt.com/mf/8; http://bkaprt.com/mf/9, PDF).
Дело не только в том, что с каждым днем через мобильные сети прокачиваются все большие объемы информации. Использование мобильных технологий для электронной торговли, поиска информации, общения через социальные сети и многих других целей ведет к развитию связанного с ними бизнеса.
На мобильных технологиях уже можно зарабатывать деньги!
• Через систему PayPal ежедневно проходят мобильные платежи на сумму до 10 миллионов долларов (http:// bkaprt.com/mf/11).
• Общемировой объем продаж eBay через мобильные устройства составил в 2010 году около 2 миллиардов долларов (http://bkaprt.com/mf/12).
• В третьем квартале 2010 года мобильный поисковый трафик Google вырос на 130 % (http://bkaprt.com/mf/13).
• Не менее 50 % общего числа пользователей Pandora подписываются на услуги через мобильные устройства (http://bkaprt.com/mf/12).
И если вам кажется, что к вашему сайту или приложению это не имеет никакого отношения, то знайте: обычный владелец смартфона ежедневно посещает до 24 веб-ресурсов, а 40 % всех визитов на половину наиболее посещаемых мировых сайтов осуществляется с мобильных устройств (http://bkaprt.com/ mf/14). Это означает, что в ближайшее время кто-то попытается при помощи мобильного устройства зайти и на ваш сайт.
Но, честно говоря, и без статистики понятно, что использование мобильных услуг растет потрясающе высокими темпами. Достаточно просто оглядеться по сторонам: видите, сколько людей уставились в эти небольшие экраны? Мобильная связь уже повсюду.
Так что же изменилось?
Чтобы происходящее стало понятнее, расскажу вам историю, которая началась в 2006 году. Если вы уже забыли, какой была жизнь в те далекие дни, позвольте заново представить вам Motorola Z3 — модель телефона, заменившую чрезвычайно успешный Motorola RAZR (рис. 1.2).
В 2006 году модель Z3 считалась в США самой продвинутой. Этот телефон давал возможность отправлять SMS и сообщения электронной почты. Он имел двухмегапиксельную камеру, музыкальный плеер, цветной экран, а также веб-браузер с поддержкой WAP 2.0/XHTML. Телефон работал с высокоскоростным протоколом EDGE. Увы, ощущения от использования веба на Z3 были, мягко говоря, отвратительными.
Насколько плохо обстояли дела? С момента открытия окна браузера до загрузки веб-страницы, состоявшей всего из пары ссылок, проходило почти две минуты (http://bkaprt.com/mf/15). В мире, где время отклика большинства сайтов измерялось долями секунды, такое ожидание было невообразимо мучительным. Но проблема заключалась не только в этом. Писать текст, перебирая символы на цифровой клавиатуре, было жутко неудобно, и тут не помогала даже функция автозавершения текста T9 (http://bkaprt.com/mf/16).
Всего лишь год спустя произошло событие, полностью изменившее мир. 29 июня 2007 года Стив Джобс поднялся на сцену и представил аудитории первый iPhone. Даже не самые большие поклонники Apple признают, что это устройство имело невероятное влияние на развитие мобильного Интернета. iPhone оказался первым мобильным телефоном, на котором просмотр веб-страниц был не мучением, а, напротив, приятным занятием. Анализ данных мобильного трафика через каналы AT&T с 2006 по 2009 год (то есть за период, когда компания была эксклюзивным оператором iPhone в США) позволяет четко увидеть картину происходившего (рис. 1.3).
За это время мобильный трафик AT&T вырос на 4932 % (http://bkaprt.com/mf/9; PDF) — неудивительно, что у ее клиентов постоянно возникали проблемы с доступом! Различие между устройством, не предназначенным для быстрого передвижения по Сети, и устройством, отлично выполняющим эту функцию, играет очень важную роль. В сущности, в 2009 году каждый iPhone создавал столько же мобильного трафика, сколько 30 обычных телефонов (http://bkaprt.com/mf/17). Разумеется, немалое значение имело и то, что плата за пользование услугами iPhone не зависела от объема трафика.
Однако мобильный трафик растет не только потому, что появляются все более совершенные устройства — они становятся еще и дешевле. Люди, которые раньше не могли позволить себе обычный компьютер, теперь получили возможность выходить в Интернет благодаря недорогому мобильному устройству и доступному тарифному плану.
Плюс к этому расширяются зоны покрытия, и неуклонно увеличивается скорость работы мобильных сетей. Только за 2010 год скорость передачи данных возросла в два раза. В результате вдвое увеличился и объем проходящей через смартфоны информации.
В ближайшее время эта тенденция вряд ли изменится: по прогнозам, глобальный объем мобильных данных за период с 2010 по 2015 год вырастет еще в 26 раз (http://bkaprt.com/mf/17)!
Новые возможности открываются все быстрее.
Не все устройства созданы равными
Однако прежде чем погрузиться в сладостные грезы о новых перспективах и возможностях, давайте еще раз окинем взором действительность. Во-первых, показатели мобильного трафика включают не только данные, поступающие из Сети. Во-вторых, до сих пор основная масса мобильных устройств — это обычные телефоны с фиксированным набором функций, или фичафоны[2], которые, естественно, ограничивают и объемы работы в Сети.
О каких именно различиях между устройствами идет речь?
• Если говорить о владельцах смартфонов, то 35 % из них ежедневно пользуются мобильным Интернетом. Среди пользователей фичафонов этот показатель составляет всего 4 %.
• Не менее 31 % владельцев смартфонов заходят в социальные сети через браузер мобильного устройства. Для владельцев фичафонов этот показатель составляет всего 7 %.
• Не менее 70 % владельцев смартфонов проверяют электронную почту на своих мобильных устройствах. Для владельцев фичафонов этот показатель составляет всего 12 %.
Так обстояли дела в 2009 году. Кроме того, эти данные включают в себя «псевдосмартфоны» с неудобными веб-браузерами (http://bkaprt.com/mf/18). Так что есть все основания полагать, что на данный момент разрыв стал еще заметнее.
Если вы заинтересованы в том, чтобы доступ к вашему контенту мог иметь любой пользователь мобильной сети, вам необходимо найти решение, учитывающее особенности устройств и интересы владельцев как фичафонов, так и смартфонов и разного рода промежуточных вариантов. И все же в этой книге я буду в основном говорить о дизайне для смартфонов. И вовсе не потому, что Google платит мне процент с каждого проданного телефона с Android, а вот почему:
• Смартфоны отвечают за непропорционально высокий объем трафика как при работе в Сети, так и при передаче данных. По данным компании Cisco, смартфоны составляют лишь 13 % используемых в мире мобильных устройств, однако на их долю приходится 78 % общего трафика (http://bkaprt.com/mf/19; PDF).
• Число владельцев смартфонов увеличивается все более быстрыми темпами. В третьем квартале 2010 года их продажи выросли на 96 % по сравнению с аналогичным показателем предыдущего года. Доля владельцев смартфонов в общем числе пользователей день ото дня увеличивается (http://bkaprt.com/20).
• Смартфоны становятся все более доступными. Устройство, прежде стоившее несколько сотен долларов, сегодня можно купить менее чем за сотню. Рынок подобных устройств поистине огромен.
• Так что есть все основания полагать, что современные смартфоны завтра будут восприниматься как вполне заурядные мобильные телефоны — других просто не останется.
И по этим, и по ряду других причин смартфоны представляют для многих компаний великолепную возможность вовлечь клиентов в близкие и длительные отношения. Разумеется, это не повод забывать и о множестве возможностей, предоставляемых обычными мобильными телефонами. Например, об SMS-услугах или специальных мобильных браузерах типа Opera Mini (которые значительно упрощают работу в Сети для устаревших моделей телефонов).
Однако перспективы мобильной отрасли все-таки связаны со смартфонами, поэтому мы будем говорить в основном о них.
Стоит отметить, что не все устройства, именующиеся «смартфонами», предоставляют равные возможности и одинаково удобны в использовании. В начале 2010 года трафик данных через iPhone более чем в четыре раза превышал объем трафика с телефонов на других платформах. Однако ближе к концу года для iPhone этот показатель был всего в 1,75 раза больше, чем для устройств на базе Google Android (http:// bkaprt.com/mf/17).
Показатели использования сетевых ресурсов могут значительно меняться даже в рамках одной платформы. После того как компания Research in Motion (RIM) представила более удобный веб-браузер, интегрированный в смартфон Storm, мобильный трафик RIM в сети Verizon увеличился на 16 % (http://bkaprt.com/mf/21). У смартфонов Blackberry, выпускаемых RIM сегодня, браузер еще лучше, поэтому можно ждать дальнейшего роста этих показателей.
Подобные примеры указывают не только на связь между удобством мобильного устройства и интенсивностью его использования, но и на исключительно высокий темп инноваций в этой сфере. В результате перед нами открываются невиданные перспективы.
Вместе с новыми возможностями появляются и новые способы взаимодействия с Сетью и людьми, использования информации и получения цифровых услуг. Мы еще будем говорить об этом, но пока я хочу подчеркнуть, что наличие хороших устройств и высокой скорости передачи данных могут привести не только к росту трафика — они открывают для веб-дизайнеров новое окно возможностей.
Достаточно посмотреть на сайт для поиска услуг на местном рынке Yelp. Мобильными версиями этого сервиса пользуются лишь 7 % общей аудитории, но это 35 % всех поисковых запросов. Каждые две секунды обладатели мобильных устройств запрашивают через Yelp информацию, касающуюся деятельности местных компаний, или узнают, как проехать к нужной цели (http://bkaprt.com/mf/22). Пока клиенты не начали использовать мобильные устройства, сервис Yelp вообще не предоставлял информацию такого рода.
Другой пример — онлайн-каталог недвижимости Zillow.
Его клиенты обращаются к базе сервиса с мобильных устройств на 45 % чаще, чем с обычных компьютеров. (http://bkaprt.com/ mf/23). Большинство из них — активные покупатели, которые изучают предложения, существующие в непосредственной близости от их текущего местоположения; это совершенно новая аудитория, с которой компания смогла взаимодействовать только с появлением мобильного Интернета.
А как насчет нативных приложений?
Разумеется, мы не можем в разговоре о росте мобильного Интернета оставить без внимания бесконечные дискуссии о том, что лучше: программы, специально создаваемые для того или иного мобильного устройства (так называемые нативные приложения), или мобильные веб-решения.
Споры идут яростные, однако истина в том, что оба этих направления имеют право на жизнь.
Нативные приложения разрабатываются под конкретную платформу и поэтому имеют такой уровень доступа к системным ресурсам устройства, каким веб-приложения похвастаться не могут. Это означает, что при взаимодействии с пользователем интерфейс нативных приложений работает, как правило, более быстро и гладко. Попытки воспроизвести такой интерфейс в браузере часто приводят к сбоям и задержкам в работе.
Нативные мобильные приложения позволяют использовать оборудование мобильных устройств так, как не может сделать ни один из мобильных браузеров. В частности, речь идет о доступе к адресной книге, работе с SMS, встроенными сенсорами, камерой и записи аудио. Веб-приложения нельзя запускать в фоновом режиме, а их создатели не могут зарабатывать на продаже своих разработок через апп-сторы[3] или реализуя товары и услуги через сами приложения. Ненативные приложения не могут попасть в апп-сторы, поэтому им гораздо сложнее оказаться на домашнем экране устройства, их становится труднее найти и использовать.
Поэтому если вашему мобильному продукту или бизнесу необходим доступ к «железу» устройства или работа в фоновом режиме, если вы хотите распространять свое приложение через апп-сторы или продавать с его помощью товары и услуги, без нативного формата вам, скорее всего, не обойтись.
Однако это вовсе не означает, что придется отказаться от решений, связанных с мобильным Интернетом.
Как отмечает эксперт по мобильному бизнесу Джейсон Григсби, «веб-ссылки не открывают приложения, они направляют вас на веб-страницы» (http://bkaprt.com/mf/24). Если у вас есть контент в Сети, то пользователи найдут его и расскажут о нем другим — через системы поиска, по электронной почте, через социальные сети или на своих веб-страницах. Отсутствие мобильного вебрешения означает, что пользователь, который пойдет по ссылкам на ваш ресурс с мобильного устройства, не увидит ничего хорошего (а то и вообще не сможет получить доступ к контенту). И наличие нативного приложения ситуации не изменит (рис. 1.4).
Для пользователя главное преимущество мобильных устройств — их доступность. Даже если вы решили создать нативное приложение для одной или нескольких платформ, велика вероятность, что все существующие платформы вам охватить не удастся. Для Apple iOS требуется Objective C, а для Google Android — Java; программы для Microsoft Windows Phone 7 пишутся на Silverlight, для Samsung Bada — на C + +, а для Blackberry от RIM — на базе Java, WebWorks и Adobe Air. Мало кто способен одновременно вести разработку с использованием всех перечисленных технологий. И даже если у вас получится создать нативные приложения для каждой платформы, расходы на их поддержку могут оказаться непомерными.
Кроме того, не исключено, что именно Сеть обеспечит вам максимум посетителей. Например, 14 % пользователей Twitter заходят в сеть через браузер, 8 % — при помощи нативного приложения для iPhone, и 7 % — нативного приложения для Blackberry. На долю остальных платформ приходится менее 4 % (http://bkaprt.com/mf/25).
То же самое можно сказать и о Facebook. Около 19 % постов в Facebook отправляются с мобильного сайта, в то время как с использованием нативных приложений для iPhone, Android и Blackberry публикуются лишь по 4 % сообщений (http:// bkaprt.com/mf/26). Причина все та же — доступность мобильного сайта на любых платформах.
Скажу больше: наличие нативного приложения зачастую стимулирует пользователей применять мобильный веб. Каждый раз, когда вы делитесь ссылкой или нажимаете на нее в нативном приложении, она открывается в окне браузера. Таким образом, увеличение числа нативных приложений приводит к росту мобильного трафика.
Веб-приложения не требуют от пользователя загрузки обновлений (сайт обновляется непосредственно на сервере, на котором располагается). С их помощью можно постоянно исследовать предпочтения пользователей, сравнивая, как они реагируют на различные варианты интерфейса (A/B-тестирование). Если какие-то из перечисленных факторов для вас важны, имеет смысл отдать предпочтение мобильному вебу.
И наверное, лучше всего начинать с мобильного решения хотя бы потому, что у вас уже имеются навыки в области вебдизайна и развития проектов. Стартовать можно в любой момент. В сущности, я думаю, стартовать следует прямо сейчас.
Время пришло
Мобильный Интернет развивается бешеными темпами, чему способствует модернизация устройств и увеличение скорости передачи данных. Применение подхода «сначала мобильные!» позволяет воспользоваться преимуществами этого роста и открывает новые перспективы для привлечения клиентов.
Теперь вы сможете не только создавать мобильные версии веб-продуктов. У вас появляется возможность более полно соответствовать потребностям аудитории.
Давайте посмотрим на социальную сеть Facebook. Более 250 миллионов ее пользователей (http://bkaprt.com/mf/27) получают доступ при помощи мобильных устройств.
Они в два раза активнее тех, кто заходит на сайт со стационарного компьютера или ноутбука.
Комбинация решений для мобильных устройств и компьютеров повышает вовлеченность пользователей обоих типов. Это происходит потому, что Facebook не расценивает свой мобильный сайт как дополнение к основному, а использует его, чтобы сделать ресурс более удобным для всех посетителей.
Джо Хьюитт, в прошлом ведущий разработчик приложения Facebook для iPhone, говорит:
Изначально мы рассматривали мобильное веб-приложение только в качестве вспомогательного сервиса, но я быстро понял, что могу создать версию, которая будет гораздо лучше, чем основной сайт.
В сущности, в его словах заключена основная идея стратегии развития мобильных приложений.
А теперь зададимся следующим вопросом: каким образом ограничения и возможности мобильных устройств помогут нам достичь заветной цели?
2
ОграниченияНЕСОМНЕННО, НЕВЕРОЯТНЫЙ РОСТ использования Интернета через мобильные устройства связан с улучшением их характеристик, однако сами эти устройства имеют и серьезные ограничения. У них маленькие экраны, телефонные сети зачастую ненадежны, да и доставать телефон иногда бывает просто неудобно. Но на самом деле все эти ограничения полезны, и не только для бизнеса, но и для самого дизайна.
Со мной согласятся все те, кто считает, что для достижения совершенства необходимо отсекать все лишнее и необязательное. Другими словами, ограничения надо приветствовать, а не бороться с ними — это позволит нам сделать дизайн лучше.
Размер экрана
На протяжении многих лет в дизайнерском сообществе горячо обсуждалась тема пространства на экране стационарных компьютеров. В итоге мы сошлись на том, что будем считать стандартом размер 1024 x 768 пикселей. Однако мобильные устройства сжимают наш огромный песчаный пляж до размеров песочницы.
Первое поколение смартфонов на платформах iOS, Android и WebOS имели экраны разрешением 320 x 480 пикселей, что составляет примерно 20 % экрана обычного компьютера. Таким образом, 80 % всех ссылок, рекламных объявлений, текстов, картинок и прочих элементов прежнего дизайна должны были либо найти себе новое место, либо исчезнуть. На экране мобильного телефона им просто не хватало пространства.
И это… прекрасно!
Как только вы поймете, каким количеством бессмысленных навигационных элементов, пустого контента и неэффективных рекламных баннеров завален типичный сайт, вам станет очевидно, почему мобильная «диета» может оказаться полезной как для самих владельцев сайта, так и для их клиентов. Как только потребитель начинает использовать мобильную версию, он хочет, чтобы и версия для обычного компьютера стала «поскромнее».
Давайте посмотрим на сайт авиакомпании Southwest Airlines (рис. 2.1), отвечающий, как кажется, на все возникающие у клиентов вопросы — даже те, которые они никогда не зададут. Добавлять новые элементы на сайт довольно легко, поэтому на веб-страницах размещаются горы контента — особенно при наличии множества заинтересованных сторон.
Требования к сайтам весьма разнообразны: владельцы хотят одного, пользователям нужно другое. Поэтому при разработке дизайна страницы часто приходится искать баланс между различными рекламными предложениями, контентными модулями, вариантами навигации… На экране 1024 x 768 так много свободных пикселей!
Мобильное решение (в данном случае нативное приложение Southwest для iPhone) позволяет максимально сконцентрироваться на том, что нужно клиенту: бронировании путешествий, регистрации на рейс, проверке расписания, расчете призовых миль и получении уведомлений (рис. 2.2). Ничего лишнего — лишь то, что может понадобиться в первую очередь.
Ограниченное пространство дисциплинирует разработчиков. На небольшом экране им необходимо представить набор свойств, наиболее важных для бизнеса и клиентов. Для сложных интерфейсов или контента сомнительной ценности просто нет места. Приходится оставлять самое важное.
А для этого нужно хорошо знать и своих клиентов, и суть бизнеса. Нравится вам это или нет.
Чтобы еще раз проиллюстрировать эту мысль, предлагаю взглянуть на сайт популярного фотохостинга Flickr. Многие из вас наверняка с ним знакомы. В течение многих лет сайт активно развивался, в результате в одном только верхнем навигационном меню появилось около 60 пунктов (рис. 2.3).
Когда же пришло время для создания мобильного приложения, команда Flickr смогла выбрать из 60 опций шесть наиболее важных. Каким образом они это сделали? Просто Flickr знали, чего ждут их клиенты. Большинство пользователей этого сервиса заходят на сайт, чтобы проверить свои фотоальбомы, просмотреть новые фотографии друзей или взглянуть на самые популярные изображения. Мобильная версия сайта ставит во главу угла именно эти функции (рис. 2.4).
Начиная разработку мобильного веб-приложения, необходимо прежде всего определить, что считать самым важным. Впоследствии тот же подход вы можете применить при проектировании версий для стационарных компьютеров или других устройств. Если вы уже определились с тем, какие свойства будут основными для ваших клиентов и вашего бизнеса, то почему эти приоритеты должны меняться, как только в вашем распоряжении окажется больше экранного пространства?
Конечно, поведение посетителей обычного сайта и его мобильной версии будет в чем-то различаться. Однако главная ценность любого веб-сервиса остается неизменной и не зависит от форматов и устройств. В сущности, клиенты ожидают от мобильной версии практически того же, что и от версии для большого экрана. Особенно это справедливо для тех, кто выходит в Интернет преимущественно с мобильных устройств. Поэтому не зацикливайтесь на простоте мобильных приложений, лучше подумайте о том, что действительно важно для ваших пользователей.
Подход «сначала мобильные!» предполагает, что конечный результат будет обеспечивать решение наиболее важных для пользователей задач, поэтому при проектировании сайтов разработчикам необходимо безжалостно избавляться от избыточного интерфейса, пустого контента и всего того мусора, которым сегодня заполнены многие интернет-ресурсы. На экране размером 320 X 480 пикселей для всего этого просто нет места.
Эффективность
Мобильными устройствами мы готовы пользоваться всегда и везде, но мобильные сети зачастую не дают нам этого делать. Даже при наличии сети путешествие по Интернету может оказаться достаточно дорогостоящим удовольствием (это зависит от тарифа), соединение — не всегда стабильным, скорость соединения — невысокой, а значит, придется нервничать в ожидании загрузки очередной страницы.
Такова реальность, и, проектируя дизайн для мобильных устройств, необходимо ее учитывать. Все, что можно сделать для того, чтобы повысить эффективность работы вашего мобильного сайта, должно быть сделано. На практике это означает снижение интенсивности обмена данными и использование всех доступных методов для ускорения загрузки и сокращения трафика между сервером и мобильным устройством.
Если вы будете управлять размерами и количеством отправляемых на устройства файлов (то есть HTTP-запросами), ваши пользователи смогут загружать меньшие объемы данных, а значит, не только быстрее получать всю необходимую информацию, но и существенно экономить на оплате счетов. Ни для кого не секрет, что из-за задержек с передачей сигнала каждый HTTP-запрос, сделанный с мобильных устройств, способен изрядно ударять по карману. Поэтому убедитесь, что вы:
• Использовали «спрайты[4]» для группировки нескольких изображений в единый закодированный файл. (Главное, чтобы при раскодировании он не оказался слишком большим!)
• Объединили и максимально уменьшили размер файлов CSS и JavaScript.
• Ограничили использование и вообще постарались избегать зависимости от тяжелых библиотек JavaScript, особенно если они применяются всего для одной-двух функций.
• Ограничили использование CSS-сеток.
• Применили соответствующие HTTP-заголовки, для того чтобы нужные файлы правильно сохранялись в кэше браузера.
• По возможности использовали такие HTML5-функ: ции современных браузеров, как Canvas (http://bkaprt.com/ mf/29) и AppCache (http://bkaprt.com/mf/30).
И моя любимая рекомендация: используйте CSS3 для скругленных углов, градиентов, теней текста и HTML-объектов.
Это позволит вам избавиться от необходимости публиковать картинки по всему сайту — в современных мобильных браузерах сайт будет выглядеть прекрасно; кроме того, он будет смотреться вполне достойно даже в браузерах, не обеспечивающих полную поддержку CSS3.
Однако не стоит перегружать сайт тяжелыми CSS3-эффектами, так как это может снизить результативность работы браузера.
Скорость важна не только для мобильных сайтов. Как показывают результаты тестов, проведенных Amazon, Yahoo! Microsoft и многими другими компаниями, даже небольшая задержка (100 миллисекунд) при работе в Сети может заставить пользователя покинуть сайт. Многолетние исследования компании Google показали, что низкая эффективность имеет отсроченный эффект: даже после того, как проблема задержки была решена, посетители в течение пяти недель менее активно заходили на такие сайты (http://bkaprt.com/mf/31). Так что эффективность имеет значение и для стационарных компьютеров.
Если вы следуете принципу «сначала мобильные!» и разрабатываете веб-приложения с учетом нестабильности мобильных сетей, то на обычных компьютерах они будут загружаться с поразительной скоростью. Это наверняка понравится вашим клиентам — вот вам и дополнительные преимущества такого подхода.
Время и место
Сейчас речь пойдет о контексте — об условиях, в которых мы находимся. К примеру, стационарные компьютеры чаще всего используются в офисе или дома; они имеют постоянное подключение к Сети и источнику питания; работают на них обычно в одиночестве, как правило, сидя — ну и далее в том же духе. Конечно, кто-то может постоянно пользоваться мобильным устройством и за рабочим столом, однако они потому и называются мобильными, что их обладатели не привязаны к месту.
Поскольку владельцы мобильных устройств практически всегда носят их с собой, придется учитывать такие факторы, как место и время. Очевидно, что в данном случае контекст будет влиять на дизайн. Если вы занимаетесь дизайном для мобильных устройств, то, по сути, создаете дизайн, пригодный всегда и везде.
Место.
Разработчики мобильных приложений зачастую представляют пользователя как спешащего куда-то по оживленной улице бизнесмена. Конечно, бывает и так, но на самом деле список мест, где люди постоянно прибегают к помощи мобильных устройств, гораздо более разнообразен. Вот результаты опроса (http://bkaprt.com/mf/32), целью которого было выяснить, где люди обычно используют смартфоны. Оказалось, что они делают это:
• дома (84 % опрошенных);
• в различных ситуациях в течение дня (80 %);
• ожидая кого-либо или стоя в очередях (74 %);
• в магазинах (69 %);
• на работе (64 %);
• во время просмотра телепередач (62 %; другое исследование называет цифру 84 %);
• во время поездок на общественном транспорте (47 %).
Тот факт, что 84 % опрошенных пользуются мобильными устройствами дома, говорит о многом. Оказывается, типичный пользователь мобильного приложения — это не спешащий бизнесмен, а человек, который находится у себя дома.
Короче говоря, как бы мы ни старались, нам вряд ли удастся удовлетворить требования всех типов пользователей.
Размышляя о тех, кто обращается к мобильным приложениям, я представил себе человека, который использует один глаз и один палец. «Один палец» — потому что именно так мы обычно управляем мобильным устройством, а «один глаз» — поскольку в большинстве случаев нас непременно что-то отвлекает.
Кто-то, стоя в очереди, решил узнать счет футбольного матча; кто-то держит в одной руке мобильное устройство, а в другой — руку ребенка; кто-то едет в переполненном вагоне метро на работу, а кто-то удобно устроился на диване перед телевизором. Ясно представив себе этот образ — «один глаз и один палец», вы поймете, почему дизайн для мобильных устройств должен быть максимально простым. Только тогда потребители смогут эффективно использовать их в самых разных ситуациях.
Но даже в среде, свободной от отвлекающих факторов, пользователи чувствуют себя гораздо более комфортно, если мобильное приложение оказывается достаточно простым.
Время.
Несмотря на то что компьютеры доступны нам в любое время суток, все же в течение дня одни устройства мы используем чаще, чем другие. Рис. 2.5 показывает, сколько статей прочитывают каждый час пользователи сервиса Read It Later со стационарных ПК и ноутбуков. Число материалов стабильно растет до полудня, а затем падает и остается низким вплоть до окончания рабочего дня (до 6–9 часов вечера).
Второй график (рис. 2.6) отображает количество статьей, ежечасно прочитываемых пользователями iPhone. Здесь можно выделить четыре основных пика: 6 часов утра (завтрак); 9 часов утра (дорога на работу и начало рабочего дня); 5–6 часов вечера (окончание рабочего дня и дорога домой); 8-10 часов вечера (отдых, свободное время, чтение в постели).
На графиках хорошо видно, что периоды использования компьютеров и мобильных устройств не совпадают. С планшетами ситуация еще интереснее. Чтобы наглядно продемонстрировать, как различные устройства влияют на сайты или приложения, приведу график, отображающий динамику прочтения статей пользователями Read It Later, заходящими на сайт со своих iPad (рис. 2.7). Несмотря на небольшой всплеск активности утром и постоянное обращение к услугам сервиса в течение дня, основной объем трафика приходится на вечер, когда люди ложатся в кровать. Я и сам читаю в постели — но, клянусь, только статьи по веб-дизайну.
Иногда такая периодичность обусловлена физической доступностью устройства: до какого из них мне проще дотянуться прямо сейчас? Во многих других случаях обращаются именно к тем устройствам, которые лучше подходят для решения конкретных задач. Это становится особенно очевидно, если совместить данные об использовании компьютеров и мобильных устройств на одном графике (рис. 2.8).
График наглядно иллюстрирует одну характерную особенность: владельцы мобильных устройств задействуют их в течение коротких промежутков времени (именно поэтому пики оказываются столь резкими). Рэйчел Хинман из Nokia, описывая различия в поведении пользователей при работе со стационарными компьютерами и мобильными устройствами, провела замечательную аналогию: она назвала первых «аквалангистами», а вторых — «ныряльщиками» (http://bkaprt. com/mf/34).
С каждым днем появляется все больше веб-приложений для мобильных устройств, позволяющих выполнять короткие, импульсивные действия и способных на протяжении всего дня быстро обеспечить потребителей необходимой им актуальной информацией. Доступ к Facebook через мобильные браузеры всего за один год вырос на 112 %, а к Twitter — на 347 % (http://bkaprt.com/mf/18)! Оба сервиса идеально подходят для кратких погружений в океан последних новостей вашей френд-ленты.
Но обратите внимание: и тех, кто погружается с аквалангом, и тех, кто ныряет, имея из снаряжения лишь маску и дыхательную трубку, интересует одно — подводный мир. Время и место взаимодействия пользователя с вашим мобильным сайтом могут быть различными, но основные ценности остаются неизменными. Вот почему я еще раз хочу подчеркнуть: не стоит лишать посетителей контента и ограничивать доступные им функции только потому, что они зашли на мобильную версию сайта.
Чем хороши ограничения
Мобильные устройства имеют несколько естественных ограничений, которые, на первый взгляд, могут сужать ваши возможности при проектировании мобильных приложений. Речь идет о небольшом размере экрана, о низкой скорости, о том, что пользователи обращаются к вашему приложению на короткое время или уделяют ему мало внимания. Разрабатывая дизайн по принципу «сначала мобильные!», вы будете вынуждены учитывать все эти ограничения. Но именно они заставляют нас находить элегантные решения. И преимущества такого подхода не ограничиваются мобильными устройствами.
Небольшой размер экрана заставляет определить, какой контент действительно важен для клиентов и компании.
Для всего остального просто нет места. Медленная связь и ограничения трафика вынуждают вас предельно упрощать и облегчать сайты, чтобы ускорить их загрузку.
Место и время также накладывают свои ограничения, заставляя вас задумываться о том, как потребитель будет использовать ваши продукты в течение дня. Но все эти ограничения создают и новые возможности для привлечения потенциальных клиентов, что, в свою очередь, позволяет внедрять инновации. Давайте теперь поговорим о новых возможностях, которые обещает нам применение мобильного подхода.
3
Потенциальные возможностиЕСТЕСТВЕННЫЕ ОГРАНИЧЕНИЯ мобильных устройств, сетей, а также особенности их использования заставляют при разработке мобильных приложений сосредоточиться на самом важном. Однако, проектируя дизайн для мобильных приложений, следует не просто придерживаться заданных рамок, но и подумать, как эти рамки можно раздвинуть.
Владельцы мобильных устройств могут использовать (и используют) их в любое время и в любом месте, что позволяет нам лучше узнать о потребностях наших клиентов, а значит, быстрее достичь намеченных бизнес-целей. Когда наши возможности объединяются с техническими возможностями современных мобильных устройств, открывается множество перспектив для инноваций. Мои слова похожи на корпоративную презентацию? Проиллюстрирую все вышесказанное примером из жизни.
Как я искал метро
Во время очередной поездки в Лондон я решил наконец посетить некоторые достопримечательности. Я уже бывал в Лондоне и знал, что метро (его еще называют Tube) — это лучший способ передвижения. Оставалось выяснить, какая станция находится ближе всего. Включив ноутбук, я зашел на сайт лондонской транспортной системы (рис. 3.1).
Я быстро нашел ссылку на карту метро и перешел на нужную страницу.
Теперь позвольте мне на минуту прерваться, чтобы продемонстрировать несколько примеров чрезвычайно разумного подхода к юзабилити и информационной архитектуре, характерных для сайта лондонской транспортной системы (рис. 3.2). Яркие ссылки, крупные изображения, поясняющие содержание каждого раздела; кроме того, каждую ссылку сопровождает соответствующая иконка PDF с указанием размера файла, так что вы сразу понимаете, что находится за каждой из них.
Я уверен, что разработчики потратили немало времени, продумывая структуру каждой страницы и определяя принципы навигации по сайту. В результате я легко нашел нужную информацию и загрузил карту метро в формате PDF (рис. 3.3).
А теперь давайте попробуем решить ту же задачу посредством нативного мобильного приложения Nearest Tube. Это приложение использует целый ряд возможностей мобильных устройств, формируя принципиально иной опыт взаимодействия. В основе программы лежит функция определения текущего местонахождения пользователя при помощи систем навигации, цифрового компаса (или магнитометра), видеокамеры и акселерометра.
Система навигации позволяет установить ваше местоположение на карте, цифровой компас определяет, к какой из сторон света вы стоите лицом, а видеокамера позволяет воспроизвести изображение той части города, которая в настоящий момент попадает в поле вашего зрения. Таким образом, чтобы найти ближайшую станцию метро, достаточно просто открыть приложение и посмотреть на экран (рис. 3.4).
На экране вы увидите маркеры, указывающие на ближайшие станции метро, линии, к которым те относятся, и расстояние, на котором вы от них находитесь. Приложение также использует акселерометр (сенсор, измеряющий параметры движения устройства); благодаря ему изображение на экране меняется в зависимости от того, куда направлена камера. Поместите устройство прямо перед собой, и вы увидите детальную информацию о близлежащих станциях; поднимите его чуть выше, и появится информация о более отдаленных станциях (рис. 3.5).
Я не хочу сказать, что приложение для мобильного телефона значительно лучше, чем сайт. Проблемы с юзабилити есть у обоих решений. Но насколько сильно эти проблемы отличаются друг от друга! И сайт, и мобильное приложение решают одну и ту же задачу, но совершенно разными способами.
Nearest Tube использует функции мобильного устройства (камеру, систему навигации, компас и акселерометр), предлагая целый ряд инноваций для решения достаточно простой задачи. Именно это чаще всего и позволяют делать мобильные устройства: изобретать способы удовлетворения потребностей пользователей, предоставляя им великолепные новые инструменты.
А что же происходит с браузером?
Не все из того, что предлагает приложение Nearest Tube, в настоящее время работает в мобильных веб-браузерах. Половина функций уже реализовано (например, определение местонахождения и ориентация устройства), однако на момент написания этой книги вторая половина (видеокамера и компас) пока была недоступна. Так что, как я говорил выше, для разработки нативных приложений имеются веские причины. Если вы все же склонны считать, что стакан наполовину полон, то современные веб-браузеры мобильных устройств предлагают вам множество интересных возможностей, и чуть ли не ежедневно к ним добавляются новые.
Важно отметить, что первоочередность тех или иных функций определяется потребностями пользователей, а не техническими преимуществами того или иного устройства. Технические возможности позволяют предлагать оригинальные способы решения задач, однако клиентам вряд ли понравится тот факт, что новые функции появились исключительно потому, что мы могли их предложить.
Определение местоположения.
Когда посетитель заходит на наш сайт со стационарного компьютера, в 99 случаях из 100 мы знаем, в какой стране он находится. Для кого-то эта информация наверняка будет полезной, для нас же она особой ценности не представляет.
Но и в большинстве смартфонов функция определения местоположения доступна через веб-браузер. В табл. 3.1 (созданной Рахулом Наиром) приведен краткий обзор технологий, имеющихся в нашем распоряжении.
И хотя местоположение современного мобильного телефона может быть определено по сотовым вышкам, устройства, подобные iPhone, способны делать это при помощи Wi-Fi-маяков.
Wi-Fi-маяки (привязаны к точкам доступа Wi-Fi):
а) работают внутри помещения;
б) не потребляют энергии батарей;
в) способны определить местоположение практически мгновенно.
GPS-устройства имеют проблемы по всем трем фронтам, однако их показания гораздо более точные. Поэтому, если вам нужно как можно более верно определить, где вы находитесь, следует делать ставку на GPS и сотовые вышки.
В любом случае по этому поводу сильно беспокоиться не стоит. Веб-браузеры с поддержкой локационных API получают от устройств максимально точную информацию о вашем текущем местоположении.
Определение местоположения — важная вещь, так как она позволяет мобильным приложениям предоставлять пользователю полезные сведения о близлежащих кинотеатрах или ресторанах, информацию о погоде и пробках, цифровой контент (фотографии и комментарии к ним), оставленные другими пользователями, и многое другое. Текущее местоположение может использоваться для уточнения поисковых запросов или адаптации действий и возможностей под конкретного потребителя (рис. 3.6–3.7).
Итак, возможность точно определить местоположение позволяет создавать новые услуги. Каждые две секунды пользователи мобильных устройств обращаются к сервису Yelp, чтобы связаться с компаниями, предоставляющими необходимые услуги. С помощью мобильного приложения Zillow можно за час просмотреть изображения 20 тысяч домов. Перспективы для подобных сервисов поистине безграничны.
Ориентация устройства / акселерометр.
Вряд ли у кого-то возникает желание повсюду таскать с собой свой компьютер, пусть даже это ноутбук. С мобильными устройствами дело обстоит совершенно иначе. Они помещаются на ладони, их легко перемещать, вращать или направлять в разные стороны. Акселерометры отслеживают все, что происходит с аппаратом, и дают возможность сайтам и приложениям реагировать на это соответствующим образом.
Наиболее простое использование акселерометра — определение того, как мы держим устройство: горизонтально или вертикально (http://bkaprt.com/mf/36). Эта мелочь может существенно повлиять на поведение приложения.
В нативном почтовом приложении Google для Android смена ориентации устройства применяется для увеличения окна ввода текста при создании электронного сообщения. Если устройство перевести в горизонтальное положение, текстовое поле расширяется, занимая всю свободную площадь экрана над клавиатурой, а в правом углу появляется кнопка «Отправить» (рис. 3.8).
Не будь этого небольшого изменения в дизайне, приведение мобильного устройства в горизонтальное положение значительно осложнило бы процесс создания сообщения. Текстовое поле стало бы меньше, а поля — шире. Однако Google нашел решение, при котором поле не уменьшается, а увеличивается — иными словами, он превратил потенциальное ограничение в преимущество.
Акселерометры могут также определять, с какой скоростью перемещается устройство в руке пользователя. Это простое свойство можно использовать в Сети и сделать массу процессов более простыми и приятными. Представьте себе, как выглядит чтение статьи в онлайне: каждый день миллионы людей читают первый абзац текста, а затем двигаются вниз, крутя колесо мыши или пользуясь линейкой прокрутки браузера. Не слишком много вариантов для инноваций, не так ли?
Аналогичные возможности мобильных устройств богаче, чем возможности стационарных компьютеров. Например, сервис Instapaper позволяет пользователю сохранять вебстраницы и просматривать их в любое время при помощи мобильного устройства (или обычного компьютера). Приложение Instapaper для iPhone использует данные акселерометра, чтобы пролистывать текст, когда вы наклоняете телефон вперед или назад, избавляя вас от необходимости делать это самостоятельно (рис. 3.9). Изменяя угол наклона, можно регулировать скорость пролистывания, что позволяет читать в удобном для вас темпе. Это пример того, как правильный подход к использованию функций мобильного устройства помогает проще решать даже самые привычные задачи.
Внимательные читатели наверняка заметили, что последние два случая касались нативных, а не веб-приложений. Давайте уравняем позиции и рассмотрим два примера того, как ориентация устройства применяется в веб-браузере.
В первом примере воссоздана привычная с детства игрушка — стеклянный шар со снегом внутри. Потрясешь телефон, и в окне браузера начинает идти снег (рис. 3.10).
Второй пример немного сложнее — здесь используется гироскоп iPhone 4, способный реагировать на движения с радиусом в 360 градусов. Можно делать панорамные кадры, просто поворачивая телефон в руке (рис. 3.11).
Прикосновение.
Дизайнеры интерфейсов всегда были сторонниками предельной простоты в обращении с устройствами. Зачем нужны мышь и клавиатура, если к объекту можно прикоснуться пальцем? Мобильные устройства с сенсорным экраном позволяют работать в Интернете с помощью прикосновений — это открывает совершенно новые горизонты использования «естественных» для человека способов взаимодействия.
О веб-навигации для мобильных устройств с сенсорным экраном я расскажу во второй части книги. Сейчас хочу лишь заметить, что сенсорный интерфейс открывает широкое поле для инноваций. Мы только начинаем понимать, как можно использовать прикосновения, чтобы управлять устройствами, создавать и получать доступ к информации в Сети. Привыкнув к таким простым действиям, как «потянуть экран вниз, чтобы обновить его», или «перелистнуть экран для перехода к дополнительным опциям», пользователи ждут и от мобильного интерфейса простых, «натуральных» способов взаимодействия.
Иногда сенсорный экран становится главным фактором, определяющим принципы работы всего приложения в целом. Достаточно посмотреть на нативное приложение Sketch a Search от Yahoo! чтобы найти ближайший к вам ресторан или кафе, достаточно нарисовать пальцем круг или линию на карте (рис. 3.12). Результаты поиска появляются внутри нарисованной фигуры или около нее.
Если сравнить это со стандартным (для обычных компьютеров) подходом, при котором вы вводите адрес и поисковый запрос с клавиатуры, новый метод поиска — всего лишь с помощью пальца! — кажется не только простым, но и довольно забавным.
Расширение возможностей
Начав применять принцип «сначала мобильные!», вы сможете сразу оценить широкие перспективы такого подхода и использовать его, чтобы лучше удовлетворять потребности своих клиентов. Такие технические новшества, как определение местонахождения, ориентация устройства в пространстве и сенсорный экран, уже реализованы во многих мобильных браузерах. Вскоре появятся и новые функции, например:
• определение направления с помощью цифрового компаса;
• гироскоп: поворот устройства на 360 градусов;
• аудио: прием входящего сигнала с микрофона и вывод на динамик;
• видео и изображения: захват и ввод с камеры;
• двойные камеры на передней и задней панелях устройства;
• связь между устройствами при помощи Bluetooth;
• определение расстояния от устройства до различных объектов;
• контроль освещенности: автоматическое определение интенсивности внешнего освещения;
• NFC: «коммуникация ближнего поля» с помощью устройств считывания RFID-меток.
Приоритет, отдаваемый разработкам для мобильных устройств, позволяет не только воспользоваться всеми этими возможностями, но и дает шанс переосмыслить взаимоотношения пользователей как с вашим сайтом, так и с окружающим миром. Потенциал мобильных веб-браузеров будет возрастать по мере того, как они получат доступ к возможностям, которые сегодня предоставляют нативные приложения.
Как начать использовать принцип «сначала мобильные!»
Подведем итог и перечислим причины, почему при создании веб-приложений стоит использовать принцип «сначала мобильные!».
Такой подход:
• готовит вас к новым возможностям, возникающим по мере развития мобильного рынка;
• помогает определиться с приоритетами в разработке продуктов — этому способствуют ограничения, накладываемые мобильным дизайном;
• позволяет находить инновационные решения, опираясь на свойства, органически присущие мобильным устройствам.
Надеюсь, я смог убедить вас в том, что мобильный Интернет не только предоставляет широкие возможности для роста, но и предлагает новые варианты удовлетворения потребностей клиентов. И теперь вы наверняка спросите меня: «Отлично, но с чего начать?» Что ж, спасибо за вопрос.
Часть 2
Как стать мобильнымИтак, мы установили, что мобильные технологии открывают множество новых перспектив. Но если ваш прежний опыт связан с дизайном обычных сайтов, то как перейти к проектированию мобильных веб-приложений? Конечно, вам пригодится уже наработанный инструментарий, знания и навыки, однако могу предположить, что вам все-таки придется пересмотреть свои взгляды на организацию процесса разработки, способы взаимодействия с пользователями и дизайн приложений.
Мы не будем подробно говорить о веб-дизайне — коснемся лишь тех областей, в которых мобильный веб максимально отличается от обычного. Прежде чем отправиться в путь, давайте разберемся, что из имеющегося багажа может понадобиться нам в дороге.
4
ОрганизацияГОВОРИМ МЫ О МОБИЛЬНОМ ВЕБЕ или об обычном, базовые принципы информационной архитектуры — правильная разметка кода, баланс ширины и глубины, основы поведения пользователя — остаются неизменными. Но для правильной организации взаимодействия с мобильным вебом также необходимо:
• хорошо понимать, как и почему люди используют мобильные устройства;
• отдавать приоритет контенту перед навигацией;
• предоставлять пользователям возможность взаимодействовать с составными элементами сайта;
• обеспечивать ясность и лаконичность контента.
Поведение пользователей
Я уже говорил об ограничениях и особенностях поведения пользователей, определяющих уникальность дизайна для мобильных устройств. Сайты для обычных компьютеров имеют свои ограничения и особенности, и автоматически переносить то, что вы делали раньше, на мобильные устройства бессмысленно. Поэтому сначала необходимо осознать преимущества мобильного Интернета, а затем — понять, как объединить собственные возможности и потребности клиентов.
Пристальный взгляд на эту область может пролить свет на то, как люди обычно используют мобильные устройства.
В книге Tapworthy («Куда следует нажимать») Джош Кларк уделил особое внимание трем основным поведенческим моделям владельцев мобильных устройств: «Микрозадачи», «Ориентирование на местности» и «Мне скучно». Эти модели практически совпадают с поведенческой классификацией, принятой в компании Google: «Мне это нужно срочно», «Я повторяю то, что часто делаю» и «Я делаю это, потому что мне больше нечем заняться». Как эти типы поведения ни назови, использование мобильных устройств обычно предполагает один из следующих видов взаимодействия:
• поиск (срочная информация, местный масштаб): мне нужен ответ прямо сейчас (часто связанный с моим местоположением);
• изучение/развлечение (скука, местный масштаб): у меня есть немного свободного времени, я хочу отвлечься;
• проверка/статус (повторяющееся занятие / микрозадачи): то, что для меня важно, постоянно изменяется или обновляется, и я хочу быть в курсе;
• редактирование/создание (срочные изменения / микрозадачи): мне необходимо безотлагательно что-то сделать.
Поскольку люди чаще всего задействуют мобильные устройства именно в подобных целях, знание специфики их поведения в той или иной ситуации поможет вам определить, как проектировать мобильные приложения, чтобы их структура и организация соответствовали потребностям пользователей. К примеру, на мобильном сайте Flickr обычно выполняются четыре основные операции. «Последние действия» и «Новые фото ваших контактов» позволяют пользователю понять, что происходит с фотографиями на его странице и на страницах друзей, а «Интересные снимки» и «Фотографии, сделанные рядом с вами» дают возможность заполнить свободное время (рис. 4.1).
Еще один пример — мобильное приложение для управления проектами Basecamp: здесь основное внимание уделяется возможности легко зарегистрироваться или войти в аккаунт, редактировать и создавать новые сообщения и т. п. И хотя люди заходят на Flickr и Basecamp с совершенно разными целями, разработчики хорошо продумали, как пользователи будут взаимодействовать с их сайтами, и правильно их организовали.
Учитывая особенности поведения владельцев мобильных устройств, вы, естественно, будете адаптировать сайт под их потребности и действия в реальных ситуациях. Поскольку доступ к мобильному веб-ресурсу возможен в любое время и в любом месте, вы должны сделать так, чтобы ваш сайт был полезен пользователям, где бы они ни находились. Иными словами, вам придется изучить человеческое поведение.
Недавно я познакомился с отличным примером подобного подхода. Один из авторов блога Mobile in Higher Ed (http:// bkaprt.com/mf/39) Дейв Олсен дал следующий комментарий к картинке с сайта xkcd.com, приведенной на рис. 4.2:
…разглядывая правую часть диаграммы Венна, я вдруг подумал: «А ведь это очень похоже на нынешний и будущий контент нашего мобильного сайта». […] Отказ от всего лишнего, максимальный учет размера экрана устройства и сетевых ограничений делает сайт гораздо более полезным.
Точнее и не скажешь.
Контент важнее навигации
Общее правило при разработке мобильных приложений гласит: контент всегда должен иметь приоритет над навигацией.
За какой бы информацией люди ни приходили на ваш сайт — будь то новости, часто обновляющиеся данные о котировках ценных бумаг и результатах спортивных матчей, сведения местного характера или другие виды контента, — им нужен немедленный ответ: на то, чтобы изучать карту вашего сайта, у них просто нет времени.
Слишком многие мобильные сайты (даже рассмотренные выше Flickr и Basecamp) начинают диалог с пользователями не с контента, а с элементов навигации. Время в мобильном Интернете зачастую очень ценно, а обмен данными стоит денег, поэтому сделайте все для того, чтобы пользователи получали необходимую им информацию как можно быстрее.
Именно так работают мобильные версии сайтов YouTube и ESPN: на экране появляется простой заголовок, сообщающий, на чей сайт вы зашли, а вся навигация сведена к одному действию. Остальную часть страницы занимает либо актуальный контент (ESPN), либо список популярных видеороликов (YouTube) (рис. 4.3).
Использование и взаимодействие
Минуточку! Если контент всегда важнее навигации, то как найти на мобильном сайте необходимую информацию? Разве без навигации это возможно? Разумеется, она необходима, но для того, чтобы использовать сайт и взаимодействовать с ним, вовсе не требуется создавать громоздкую систему навигации, способную похоронить под собой сам контент.
Например, мне нравится, что на мобильном сайте Facebook актуальный контент занимает основную часть страницы.
Но при этом в верхней ее части разработчики разместили сразу три навигационные панели, из-за чего на экране умещается всего одна новость. Мобильный сайт Google Finance содержит актуальные данные, но этот контент спрятан под пятью навигационными панелями. Иными словами, драгоценное экранное пространство заполнено навигационными опциями, которые могут и не потребоваться пользователям, в то время как на их месте могла бы находиться полезная информация (рис. 4.4).
Недавно Facebook изменил дизайн мобильного сайта, уменьшив число элементов навигации (рис. 4.5). Если не считать фильтров «Главные истории» и «Последние» в ленте новостей, их стало вдвое меньше (пять вместо десяти). Так держать!
Примеры сайтов YouTube и ESPN (рис. 4.3) показывают, что контент важнее навигации, однако они по-разному решают задачи доступа к основному содержанию и навигации. Чтобы перемещаться по сайту YouTube, необходимо использовать иконку, открывающую отдельную страницу с элементами меню (рис. 4.6). То есть для того, чтобы перейти к навигации, пользователю необходимо совершить действие, которое выводит его из общего контекста сайта (на отдельную страницу).
Кроме того, он должен заранее знать, что иконка с решеткой в шапке сайта — это вход в навигационное меню.
В шапке мобильного сайта ESPN есть хорошо заметная кнопка «Меню», при нажатии на которую открывается обширный (и многоуровневый) перечень пунктов навигации (рис. 4.7). Это позволяет посетителю выбирать направление движения по сайту, не покидая текущей страницы. Кроме того, навигационное меню дублируется в подвале большей части разделов веб-ресурса, что соответствует логике их просмотра: дойдя до конца страницы, пользователь решает, что делать дальше — и облегчает взаимодействие с сайтом при управлении одной рукой. Дизайнеры мобильного сайта YouTube не предусмотрели такой возможности, поэтому их пользователи просто доходят до конца страницы, так как дальше им двигаться некуда (рис. 4.8).
Меню в подвале страницы удобно для дальнейшего перемещения по сайту, но все же оно не должно дублировать все элементы навигации. Лучше, если кнопка меню в верхней части экрана будет просто направлять пользователя к списку навигационных пунктов, расположенному в нижней части страницы (после контента). Мы, например, применили этот прием при разработке мобильного сайта Bagcheck (рис. 4.9). Помимо этого в меню в нижней части каждой страницы мы добавили ссылку на верхнюю часть страницы. Это дает пользователям возможность вернуться в начало раздела, если потребуется еще раз просмотреть его содержимое.
Такой дизайн предполагает минимум навигационных элементов (в сущности, единственную ссылку в начале страницы). Он позволяет пользователям продолжить взаимодействие с сайтом после того, как они достигли конца страницы. Содержание меню не дублируется, а главное, для его работы требуется всего лишь ссылка-якорь, отсылающая посетителя в нижнюю часть страницы. Никаких скриптов JavaScript, оверлеев, отдельных навигационных страниц… Это своего рода HTML0 (который, как я слышал, поддерживается большинством браузеров, за исключением Internet Explorer).
Каждая страница Bagcheck имеет уникальное навигационное меню, позволяющее более детально изучать контент сайта (рис. 4.10). Перейти в другие разделы посетители могут, также воспользовавшись и главным меню.
Возможности контекстной навигации крайне полезны.
На мобильном сайте Gmail (рис. 4.11) контекстное меню расположено в верхней части экрана. Поскольку навигация по сайту напрямую связана с отображаемым в окне сообщением электронной почты, размещение элементов навигации в подвале страницы было бы не очень эффективным. А в этом случае все необходимые функции остаются наверху и всегда доступны.
Возвращаясь назад
Всегда интересно наблюдать за тем, как мигрируют решения в области дизайна. Например, в шапке многих нативных приложений для iPhone есть кнопка возврата к предыдущей странице (рис. 4.12). У мобильных устройств компании Apple нет физической кнопки для возврата к предыдущему окну, iOS также не предлагает пользователю каких-либо системных инструментов для этой операции.
C iPhone кнопка «Назад» перекочевала в шапку многих сайтов, хотя зачастую она совершенно не нужна. Многие устройства (Android, Blackberry, Windows Phone 7 и т. д.) имеют физические кнопки «Назад» (рис. 4.13). Такая кнопка есть даже на панели управления мобильного браузера Apple (рис. 4.14). И появление еще одной в шапке мобильного сайта способно лишь запутать пользователя. У него может возникнуть вполне обоснованный вопрос: «А она предназначена выполнять то же действие?»
При разработке дизайна мобильного сайта пусть кнопка «Назад» останется уделом нативных приложений. Если вы хотите помочь пользователю вернуться на предыдущий уровень, дайте этому навигационному элементу другое название.
Привязка к низу страницы
У многих нативных приложений для iPhone навигационные панели зафиксированы в нижней части экрана, что позволяет управлять приложением при помощи большого пальца. И в отличие от мобильного браузера в нативных приложениях отсутствует нижняя панель инструментов, пожирающая драгоценное экранное место. На примере сайта Yahoo! Mail можно увидеть, как инструменты управления браузером влияют на отображение мобильной веб-страницы. Две панели браузера и два фиксированных меню сайта Yahoo! Mail оставляют крайне мало места для просмотра содержимого почтового ящика (рис. 4.15).
Мобильным сайтам приходится учитывать особенности не одного, а множества браузеров для различных операционных систем. А на устройствах с физическими кнопками определенные проблемы может создавать программное меню, расположенное в нижней части окна (рис. 4.16). Подобное соседство неминуемо приведет к тому, что пользователи будут промахиваться и, выбирая необходимый пункт меню, нажимать на физические кнопки устройства.
Разрабатывая нативные мобильные приложения, вы можете учесть наличие кнопок, расположенных под экраном устройства. Однако мобильные сайты должны работать на любых устройствах, независимо от того, есть у тех такие кнопки или нет.
Таким образом, если для нативных приложений навигационное меню в нижней части экрана может стать неплохим решением, то в случае мобильных сайтов эта идея, скорее всего, окажется не столь удачной с точки зрения юзабилити. Если вам нужно фиксированное меню, пусть лучше оно будет располагаться сверху. Именно так поступил Twitter, разрабатывая новый дизайн своего мобильного сайта (рис. 4.17).
Ясность и отсутствие лишних деталей
Как я уже говорил в первой части книги, владельцам мобильных устройств порой достаточно «одного глаза и одного пальца». Ждать, что они сядут за стол и начнут сосредоточенно изучать ваш сайт, не стоит. Более вероятно, что в этот момент их будет отвлекать множество факторов. Мы вряд ли можем рассчитывать на безраздельное внимание пользователей, поэтому мобильный дизайн должен быть ясным, не содержать лишних деталей и давать пользователям возможность быстро достигать нужных целей — желательно, обходясь минимумом навигационных опций.
Окно создания письма программы Yahoo! Mail — отличный пример того, как, отказавшись от всего лишнего, разработчики дали пользователям возможность сосредоточиться на основной задаче (в данном случае — на написании сообщения).
На экране присутствует всего одна навигационная кнопка — «Отменить» (рис. 4.18). Остальной интерфейс нацелен на выполнение текущей задачи.
Другой пример: сайт спортивного канала ESPN, отображающий в реальном времени ход матчей Национальной баскетбольной ассоциации, содержит такое количество навигационных кнопок, что схема самой площадки фактически смещена за пределы экрана. А ведь посетители заходят на эту страницу для того, чтобы наблюдать за ходом игры, а не перепрыгивать от одного пункта меню к другому.
Уменьшив число навигационных опций на экранах мобильных устройств и тем самым снизив вероятность, что пользователь, спеша выполнить задачу, нажмет не на ту кнопку, вы сможете предотвратить множество ошибок.
Структура мобильного сайта
Проектируя мобильный сайт, продумайте, как совместить в дизайне особенности поведения владельцев мобильных устройств и их потребительские нужды.
• Анализ основных способов взаимодействия (поиск, изучение/развлечение, проверка/статус и редактирование/создание) позволит понять, как владельцы мобильных устройств будут использовать ваш сайт, а значит, разработать структуру, соответствующую их потребностям.
• Уделив внимание в первую очередь контенту и лишь потом навигации, вы предоставите посетителям возможность максимально быстро получить доступ к нужной информации или произвести необходимые действия.
• Продуманное и правильно расположенное навигационное меню помогает пользователям более детально изучить содержание страницы и облегчает переход к другим разделам сайта.
• Уменьшение числа навигационных опций и акцент на выполнение основных задач позволяют пользователям быстрее достигать поставленных целей. Это особенно важно, когда у них мало времени или они находятся не в самых удобных условиях.
• Но даже если владелец мобильного устройства заходит на ваш сайт в свободное время, находясь у себя дома и удобно расположившись в кресле, будьте уверены: он по достоинству оценит простоту и функциональность вашего дизайна!
Продуманная структура мобильного сайта позволяет пользователям быстро находить необходимую информацию. Отыскав ее, они начинают действовать. Давайте посмотрим, что и как они делают.
5
ДействияДЛЯ УСТРОЙСТВ С МАЛЕНЬКИМ ДИСПЛЕЕМ, помещающихся на ладони, сенсорный экран — это естественный выбор. В сущности, благодаря ему мобильное устройство (а не только клавиатура или трекбол) превращается в интерактивную поверхность. Именно поэтому телефонов, экран которых реагирует на прикосновение, производят все больше. К примеру, доля смартфонов с тач-скрином в общем объеме продукции компании Nokia постоянно растет (рис 5.1).
И хотя некоторые из этих устройств имеют также и аппаратные средства ввода информации — трекпады, колесики прокрутки и клавиатуру, при взаимодействии с Интернетом их владельцы все чаще используют именно сенсорный, или, точнее, тач-интерфейс, в основе которого лежит управление устройством при помощи пальцев. Но как обеспечить всем посетителям возможность взаимодействовать с сайтом посредством прикосновений? Для этого, прежде чем приступать к проектированию тач-интерфейса, необходимо:
• определить размер и расположение зон тактильного касания (тач-зон);
• изучить наиболее распространенные тач-жесты и понять, с какой целью они используются;
• продумать, чем заменить операции, которые раньше выполнялись наведением курсора;
• не забыть о средствах «непрямой манипуляции[5]».
К малому через большое
При разработке мобильных веб-приложений дизайнеры зачастую идут по пути простого уменьшения всех элементов обычного сайта. Места на экране немного, а значит, чем меньше, тем лучше, не так ли? В этом подходе есть логика, но все же в процессе проектирования следует придерживаться противоположного направления и увеличивать элементы — иногда даже до размеров, превышающих привычные (рис. 5.2).
Человеческие пальцы — не самый точный инструмент.
Им не хватает аккуратности компьютерной мыши. Они разных размеров. Кроме того, они то и дело соскальзывают, не попадая в нужный участок экрана. Поэтому чем важнее выполняемая задача, тем крупнее должна быть зона касания — только тогда людям с «одним глазом и одним пальцем» будет удобно взаимодействовать с вашим сайтом.
Действительно ли это так важно? Результаты исследований показывают, что почти в половине случаев нажатие на рекламные баннеры в мобильном браузере происходит случайно (http://bkaprt.com/mf/41). Продуманные размеры и правильное расположение зон касания позволяют пользователям уверенно и точно нажимать на экран. Но до каких пределов следует увеличивать размеры тач-зоны?
В руководстве iOS Human Interface Guidelines (http://bkaprt.com/ mf/42) Apple рекомендует, чтобы размер зоны для нажатия составлял 44 x 44 пункта. В качестве единицы измерения Apple использует пункты, а не пикселы, поскольку экраны разных устройств имеют разное разрешение (об этом поговорим ниже). А чтобы правильно учитывать различия в экранном разрешении (или ppi), лучше задавать размеры тач-зон в физических единицах.
Microsoft также применяет этот подход в руководстве для Windows Phone 7. В нем указано, что оптимальный размер тач-зоны составляет 9 мм, минимальный — 7 мм, а минимальное расстояние между различными зонами — 2 мм. Другие руководства для разработчиков (например, от Nokia и даже Ubuntu) рекомендуют примерно такие же размеры, как и у Microsoft; за основу принят средний размер человеческого пальца. Лаборатория Touch Lab Массачусетского технологического института (MIT) определила, что средний размер зоны для касания подушечкой пальца составляет 10–14 мм, кончиком — 8-10 мм (http://bkaprt.com/mf/43).
К подобным рекомендациям следует прислушаться, однако это вовсе не означает, что размеры любой иконки или кнопки на вашей мобильной странице обязаны составлять ровно 9 x 9 мм. Указанным параметрам должна соответствовать активная тач-зона, в то время как ее визуальное отображение может быть вдвое меньше. Иллюстрация из «Руководства Microsoft» (рис. 5.3) показывает, какие значения атрибутов margin или padding следует задавать, чтобы тач-зоны имели правильный размер, а элементы визуального интерфейса при этом не выглядели бы одинаково.
Помимо этого в «Руководстве Microsoft» подробно описаны случаи, когда размер тач-зоны должен превышать 9 мм: «Если пользователям приходится часто нажимать на элемент интерфейса; если результат ошибочного нажатия необратим или имеет неприятные последствия; если элемент интерфейса расположен слишком близко к краю экрана; если на него трудно нажимать или он является составной частью в цепочке последовательных действий — как в случае набора телефонного номера» (http://bkaprt.com/mf/44).
Другими словами, когда речь идет о прикосновениях к экрану мобильного устройства, следует всегда придерживаться принципа «чем больше, тем лучше». Правильное расположение и надлежащий размер тач-зоны позволяют избежать куда более серьезных проблем, чем простое соскальзывание пальца.
Посмотрите внимательно на стартовую страницу мобильного сайта Quora (рис. 5.4). Заметили, где могут возникнуть проблемы?
Действительно, кнопки Cancel и Login расположены слишком близко друг к другу. Здесь неправильные размеры и расположение тач-зон (помните о правиле двух миллиметров?) могут привести к тому, что пользователь, вместо того чтобы войти в свой аккаунт, покинет сайт.
Еще один пример: окно расширенного поиска на мобильном сайте Flickr, где элементы интерфейса также расположены слишком близко друг к другу (рис. 5.5). В данном случае «больше» однозначно было бы лучше, чем «меньше».
Куда мы нажимаем?
Ранее я уже упоминал, что размещение активных элементов интерфейса в нижней части экрана наиболее соответствует положению мобильного устройства в руке пользователя. Однако все не так просто. Расположение основных тач-зон зачастую зависит от того, каким пальцем (большим или указательным) владелец мобильного устройства нажимает на экран, а также от того, левша он или правша.
Большинство людей в мире — правши (от 70 до 90 %) и взаимодействуют с мобильным устройством посредством большого пальца. Соответственно, чаще всего приложения оптимизируются именно под управление большим пальцем правой руки. Это означает, что элементы интерфейса, соответствующие основным действиям, будут находиться в средней или нижней части экрана и располагаться слева направо (рис. 5.6).
Деструктивные функции, такие как отмена или удаление, выносятся за пределы зоны комфорта пользователя. Если вы держите мобильное устройство в правой руке и управляете им при помощи большого пальца, вам придется приложить некоторое усилие, чтобы дотянуться до левого верхнего угла экрана. Это не очень легко и не слишком удобно. Следовательно, вы лишний раз задумаетесь, действительно ли вам необходимо удалить результаты проделанной работы.
Изучите язык жестов
Тач-зоны позволяют управлять мобильным сайтом, но само взаимодействие происходит при помощи жестов. И хотя в технической документации для различных платформ жесты обозначаются и описываются по-разному, на сегодняшний день существует стандартный набор жестов, применяемый пользователями при работе с мобильными приложениями.
Для того чтобы лучше разобраться в этом вопросе, я вместе с Дэном Уиллисом и Крейгом Вилламором изучил техническую документацию для следующих платформ:
• iOS и OS X компании Apple;
• Android компании Google;
• Windows Phone 7, Windows 7 и Surface компании Microsoft;
• Web OS компании Palm;
• библиотеку поддержки жестов GestureWorks в среде программирования Flash компании Adobe;
• и даже для графического планшета Bamboo компании Wacom, поддерживающего тач-интерфейс.
К счастью, проведенный анализ показал, что у этих систем больше общего, чем различий. Фактически основной набор жестов одинаков для всех платформ: они соответствуют основным действиям, которые выполняют пользователи при работе с сенсорными экранами: нажатие (tap); двойное нажатие (double tap); перемещение (drag); пролистывание (swipe); уменьшение масштаба (pinch); увеличение масштаба (spread); продолжительное нажатие (press and tap); продолжительное нажатие с перемещением (press and drag); а также несколько разновидностей поворотов. Поскольку некоторые мобильные веб-браузеры не поддерживают определенные жесты или резервируют их для системных операций, этот список может быть сокращен всего до трех операций — нажатие, перетаскивание и пролистывание (рис. 5.7).
Несомненно, разработчикам важно знать, какие жесты возможны в принципе, но еще более важно понимать, как пользователи при помощи жестов взаимодействуют с интерфейсом мобильных устройств. Если человек собирается произвести какое-то действие или перейти к другому объекту или странице, какие из этих жестов он выполнит? Созданное по итогам нашего аудита «Справочное руководство по жестам для тач-интерфейсов» отвечает на эти и некоторые другие вопросы (http://bkaprt.com/mf/45) (рис. 5.8).
Руководство начинается с описания основных задач, которые обычно решают пользователи — например, изменить параметры, удалить объект или пролистать список. Рядом с каждым из потенциальных действий приведены применяемые на большинстве платформ (и чаще всего выполняемые пользователями) жесты.
Руководство находится в открытом доступе и содержит файлы шаблонов для каждого жеста в форматах PDF, EPS, OmniGraffle и Visio, которые можно свободно использовать при создании макетов и прототипов.
Устройства с тач-интерфейсом стремительно завоевывают популярность, а значит, будут появляться все новые дизайнерские решения. Например, такое действие, как «потянуть вниз для обновления», которое раньше было доступно лишь для отдельных приложений, сегодня получает широкое распространение, так что нетрудно предположить, что в ближайшее время пользователи попробуют применить их и на вашем сайте. Поэтому смело экспериментируйте с жестами! (рис. 5.9–5.10).
Не стоит бояться NUI[6]
Я всячески приветствую распространение естественного пользовательского интерфейса (NUI). Я верю, что потенциал этого подхода позволит нам войти в новую эру программирования. Такие его принципы, как превращение контента в интерфейс, прямое взаимодействие пользователя с контентом, а также отказ от визуальных элементов, не относящихся к контенту, открывают перед нами новые пути использования цифровой информации и медиа.
Уходят в прошлое те времена, когда для того, чтобы увеличить изображение, приходилось использовать окна, иконки, меню и указатели (WIMP[7]). Теперь для этого достаточно коснуться фотографии и развести пальцы в стороны. Такому «прямому» взаимодействию не только легче научиться (спросите об этом детей и пожилых людей, активно использующих iPad) — оно лучше отражает наше представление о реальном мире.
Сегодня мы находимся на стадии перехода от графического к естественному пользовательскому интерфейсу. Далеко не все пользователи смогут быстро освоить управление жестами, и, судя по всему, выполнять основные операции на мобильных сайтах нам по-прежнему придется при помощи кнопок. Однако это не должно становиться препятствием для экспериментов с жестами в тех случаях, когда это оправданно, например для дополнительных настроек или «горячих» команд.
Старайтесь сделать так, чтобы предусмотренные в интерфейсе жесты были как можно более естественными: пользователям будет легче к ним привыкнуть. Недавнее исследование, проведенное среди пользователей девяти стран, показало, что люди разных культур для выполнения одинаковых действий применяют одни и те же жесты (http://bkaprt.com/mf/46). Так что если говорить об использовании тач-интерфейсов, у всех нас есть много общего.
И наконец, проблемы переходного периода можно частично решить, добавив на страницы вашего сайта подсказки, анимацию и заметные графические элементы. Сначала их нужно размещать более активно, показывая посетителям, где и как они могут использовать жесты, но с течением времени следует постепенно сокращать их количество. И помните о том, что, если подсказок становится слишком много, использование жестов уже не будет таким естественным, как вы того хотели бы.
При работе с тач-интерфейсом ожидания пользователей и замысел разработчиков не всегда совпадают. Например, несмотря на то, что на мобильном сайте ESPN данные о набранных командами очках представлены так, будто их можно просматривать, пролистывая страницы, — чтобы перейти от одного блока к другому, приходится использовать стрелки (рис. 5.11).
Выбор наведением
Раз уж мы заговорили о подсказках, следует отметить, что привычные подсказки, возникающие при наведении курсора (состояние on hover, когда указатель мыши находится над определенным участком страницы), не подходят для приложений с активным экраном. Это и понятно: курсора, который можно было бы наводить, здесь просто нет. И хотя пальцы тоже отбрасывают тень, я не знаю ни одного мобильного устройства, которое воспринимало бы это в качестве функции наведения.
Следовательно, необходимо пересмотреть все действия, которые прежде выполнялись при помощи указателя мыши.
И это прекрасно! На самом деле на обычных сайтах значение наведения часто бывает переоценено. Когда пользователь подводит курсор мыши к объекту, это еще не означает, что он хочет, чтобы на экране появилась подсказка или меню (рис. 5.12). В отличие от нажатия наведение курсора не всегда предполагает действие.
Меню, появляющееся при наведении мыши, обычно представляет собой список дополнительных действий, не настолько важных, чтобы отображать их на экране постоянно. Оно часто содержит опции, которым не хватило места в основном экранном меню. Однако при переходе на мобильные версии сайтов об этих опциях не следует забывать.
При создании мобильных сайтов у вас есть следующие варианты размещения опций выпадающего меню:
• меню располагается непосредственно на экране;
• меню появляется при нажатии на экран, а выбор необходимых функций производится пролистыванием;
• меню выносится на отдельную страницу;
• и мой любимый: вообще отказаться от выпадающего меню.
На экране.
В тех случаях, когда содержание выпадающего меню имеет принципиальное значение, наиболее правильно размещать его непосредственно на экране. Именно такое решение использовал Twitter в первоначальном варианте своего мобильного сайта.
На обычном сайте Twitter при наведении курсора на сообщение появлялось меню со следующими опциями: «В избранное», «Ретвитнуть» и «Ответить» (рис. 5.13). По мнению разработчиков, эти действия достаточно важны, поэтому в мобильной версии сайта они расположили их непосредственно на экране (рис. 5.14).
При нажатии и пролистывании.
При открытии обычных сайтов в некоторых мобильных браузерах стандартное выпадающее меню отображается при нажатии на экран. Это оправдано в тех случаях, когда опции такого меню логически связаны со следующим действием пользователя. Однако если его содержание добавляет к процессу лишние шаги, это может мешать перемещению посетителей по сайту, а значит, вызывать у них раздражение.
Пролистывание — жест куда менее очевидный и понятный пользователю, чем нажатие. И чаще всего при проектировании мобильного интерфейса он требует дополнительных усилий со стороны разработчиков. С другой стороны, этот жест редко бывает случайным, а значит, производимое им действие не будет мешать посетителям в процессе их естественных перемещений по сайту. Если вы намерены использовать пролистывание на своем сайте, то имеет смысл добавить подсказку или небольшую анимацию, объясняющую, как оно работает (рис. 5.15).
Следует также иметь в виду, что для действий, выполняемых при помощи неочевидных жестов (например пролистывание), нужно предусмотреть альтернативы.
Так, на мобильном сайте Yahoo! Mail функции меню, открывающиеся при пролистывании, дублируются также в отдельном окне (рис. 5.16).
На отдельной странице.
Если выпадающее меню включает большой объем информации, то на мобильном сайте имеет смысл размещать его на отдельной странице. Такой подход использовал Barnes & Noble (рис. 5.17). То, что на обычном сайте было большим (и навязчивым) выпадающим меню, в его мобильной версии теперь занимает отдельную страницу.
Полный отказ.
Если изначально в выпадающем меню не было особой необходимости, то в мобильной версии сайта лучше и вовсе от него избавиться. Отказ от лишних действий или информации, не представляющей ценности для пользователя, не только сделает интерфейс проще, но и облегчит разработку и поддержку сайта. Так что смело избавляйтесь от всего лишнего!
Вы можете выбрать любой из описанных выше подходов — главное, убедитесь, что при переходе от обычной версии сайта к мобильной вы не забыли ни об одной из функций выпадающего меню.
Не трогать!
Вы надеялись, что мы уже покончили со всеми проблемами?
А как насчет сайтов для устройств с бесконтактным или гибридным интерфейсом? Мобильные устройства с механизмами непрямого воздействия — такими как трекпады, трекболы, колесики прокрутки или физическая клавиатура (цифровая или QWERTY) — позволяют при взаимодействии с Интернетом не водить пальцами по экрану.
Когда пользователи перемещаются по веб-страницам при помощи описанных выше средств промежуточного контроля, CSS-состояние: hover часто применяется для того, чтобы выделить выбранный элемент интерфейса, не прибегая к Java Script. И хотя правильнее в таких случаях было бы задействовать состояние: focus, таблицы стилей многих сайтов не содержат его явного описания. Поэтому такие мобильные браузеры, как OperaMini, используют: hover, чтобы выделить активный элемент интерфейса, выбранный пользователем в данный момент.
Добавив в таблицу стилей описание состояний: hover и: focus для всех ссылок, кнопок и меню вашего мобильного сайта, вы облегчите его использование на устройствах, оборудованных средствами непрямой манипуляции.
Когда речь идет об устройствах, не имеющих тач-интерфейса, можно вообще не беспокоиться о состоянии: focus. И хотя в настоящее время подавляющее большинство производителей смартфонов отдают предпочтение сенсорным экранам, не все устройства, выпущенные ими ранее (да и те, что продолжают выпускать), имеют тач-интерфейс. Экраны старых моделей обычно меньше, поэтому тач-зоны заняли бы слишком много места и использовать жесты было бы невозможно. А значит, возникает необходимость в некоторой адаптации.
Ниже я еще расскажу о методике прогрессивного улучшения, позволяющей уменьшать размер интерактивных зон так, чтобы это не создавало неудобств для пользователей.
Но поскольку я обещал, что не стану слишком углубляться в технические аспекты и постараюсь сделать эту книгу как можно более краткой, то предоставлю право подробно рассказать о прогрессивном улучшении тем, кто разбирается в этом вопросе лучше меня (http://bkaprt.com/mf/47).
Камера, мотор, начали!
Мобильных устройств с сенсорным экраном и тач-интерфейсом становится все больше, поэтому необходимо постоянно работать над тем, чтобы у пользователей не возникало проблем при взаимодействии с нашими сайтами.
Поэтому:
• при определении размера и расположения тач-зон применяйте принцип «чем больше, тем лучше»;
• постарайтесь как можно лучше изучить «язык жестов», использующихся при работе с активным экраном, и то, как пользователи применяют их для навигации и управления сайтом;
• смело используйте принципы естественного пользовательского интерфейса (NUI), благодаря которым внимание посетителей сайта сосредоточивается на контенте, а не на оболочке;
• выберите наиболее подходящий для мобильного сайта способ внедрения функций, реализованных на обычном сайте в виде выпадающего меню;
• при проектировании мобильного сайта не забывайте об устройствах без сенсорного экрана и с гибридным интерфейсом.
Теперь, после того как мы разобрались с основами, давайте обратим наше внимание на самое важное из действий — ввод.
6
О вводеОДНО ИЗ ГЛАВНЫХ ПРЕИМУЩЕСТВ Интернета заключается в том, что он позволяет человеку не только изучать и использовать контент, но и участвовать в его создании. В мобильных технологиях правильная организация ввода данных — вопрос не менее важный, чем их отображение. Однако организация этого процесса также имеет свои особенности. Поэтому:
• думайте о мобильных приложениях как о предоставленной пользователю возможности создавать что-то новое, причем там и тогда, где и когда его посетит вдохновение или придет интересная мысль;
• используйте оптимизированные для мобильных устройств теги label[8] — это поможет предельно ясно формулировать вопросы;
• чтобы упростить ввод данных, применяйте различные типы ввода, атрибуты и маски;
• выбирайте правильный дизайн для последовательных, нелинейных и контекстных форм;
• используйте любые возможности для того, чтобы минимизировать количество полей для ввода данных.
Упрощение ввода
Дизайнеры обычно не склонны соглашаться друг с другом. Именно поэтому кажется удивительным, что в появившихся за последние годы руководствах по дизайну мобильных приложений можно найти множество примеров единого мнения по вопросу ввода данных. Первоначально почти все разработчики были согласны с тем, что мобильные устройства — не самый удобный инструмент для ввода данных. В книге Mobile Web Design and Development («Дизайн и разработка мобильных сайтов») Брайан Флинг писал:
Неписаный закон веб-дизайна: в мобильном контексте использование форм должно быть ограничено.
У нас есть множество веских причин, чтобы освободить пользователя, оперирующего «одним глазом и одним пальцем», от необходимости вводить информацию, но найдется и немало поводов, чтобы позволить им более активно взаимодействовать с мобильными устройствами. В конце концов, в 2010 году только в США в день отправлялось свыше четырех миллиардов текстовых сообщений, причем большинство из них создавалось при помощи не самой удобной цифровой клавиатуры обычных телефонов. Очевидно, что потребители хотят переписываться через мобильные устройства и ради этого готовы даже терпеть некоторые неудобства.
Но некоторых трудностей вполне можно избежать. Современные мобильные устройства упрощают ввод информации — этой цели служат увеличенные сенсорные экраны, микрофоны, видеокамеры и многое другое. Дизайнерам мобильных сайтов пора перестать бояться ввода данных и начать воспринимать мобильные устройства как наиболее удобное средство для получения разнообразного контента от всех категорий пользователей.
Мобильные устройства всегда при нас. Поэтому всякий раз, когда нас посещает вдохновение, мы можем поделиться своими мыслями с друзьями или принять участие в создании онлайн-контента. Возможность определить местоположение пользователя и ориентация устройства, запись аудио, видеокамера и многое другое предоставляют нам массу новых возможностей для ввода информации, при этом нет необходимости прибегать к помощи такого неточного инструмента, как палец.
Самое важное — перестать бояться того, что пользователи не станут выполнять то или иное действие лишь потому, что в данный момент они вышли в Сеть с мобильного устройства. Ведь приобрел же какой-то человек самолет стоимостью 265 тысяч долларов через приложение eBay для iPhone (http://bkaprt.com/mf/48, http://bkaprt.com/mf/49). Осознав, что ввод данных следует поощрять и всячески ему содействовать, можно перейти к дизайну.
Мобильные вопросы
То, каким образом мы просим пользователей вводить данные, во многом предопределяет их ответы. В Интернете большинство вопросов задаются через формы, а для того, чтобы правильно сформулировать вопрос, формы содержат подсказки — теги label. В мобильных интерфейсах эти теги имеют ряд ограничений и предоставляют определенные возможности, что и определяет то, как они должны быть спроектированы.
Экран мобильного устройства невелик — следовательно, необходимо адаптировать веб-формы под его размер. В большинстве случаев разместить элементы label справа или слева от поля ввода не удается — просто нет места для двух колонок. Поэтому их лучше всего выравнивать по верхнему краю: это позволяет не только оптимизировать пространство экрана (даже когда они достаточно длинные), но и сохранить их видимыми при открытии виртуальной клавиатуры, занимающей половину имеющегося пространства.
В регистрационной форме мобильного сайта Twitter (рис. 6.1) элементы label находятся над полями ввода, а под ними располагается пояснительный текст. Эти элементы остаются видимыми даже при открытии виртуальной клавиатуры. И раз уж мы заговорили о Twitter, известно ли вам, что за первые пять месяцев 2010 года 16 % его новых пользователей зарегистрировались при помощи мобильных приложений (http://bkaprt.com/mf/25)?
А что 40 % всех твитов поступают именно с мобильных устройств (http://bkaprt.com/mf/50)? Или даже эти цифры не смогут убедить вас в том, что проблема ввода данных через мобильный интерфейс имеет первостепенное значение?
Элементы label, располагающиеся над полем ввода, — хорошее решение. Но если они находятся внутри поля формы — еще лучше. И вот доказательство: практически все мобильные платформы в своих приложениях поддерживают элементы label, находящиеся внутри полей ввода. Однако в мобильном веб-дизайне внедрение такого решения может потребовать от разработчика дополнительных усилий.
На первый взгляд элемент label внутри поля ввода кажется отличным решением, однако для его реализации придется преодолеть ряд препятствий.
Итак, элемент label внутри поля ввода формы:
• Никогда не должен становиться частью ответа. Это правило выглядит простым, но на практике подобное происходит достаточно часто (например, при ошибке в коде или неполной загрузке страницы). Вы никогда не обнаруживали, что слово «найти» неожиданно становилось частью вашего поискового запроса?
• Не должен быть похожим на текст, который вводится в поле. В противном случае пользователь (и вполне обоснованно) может предположить, что программа уже ввела ответ за него. При тестировании веб-интерфейсов я сталкиваюсь с такими ситуациями постоянно.
• Как только пользователь начинает вводить текст в поле, label обычно исчезает и больше не появляется. Таким образом, заполнив форму, он не может проверить, на какой именно вопрос отвечал.
Две последние проблемы наглядно иллюстрирует форма регистрации на мобильном сайте сервиса почтовых рассылок MailChimp (рис. 6.2). С началом ввода имени находящийся внутри поля элемент label исчезает. (Хочу отметить: с точки зрения спецификации HTML5 это вполне нормально, поскольку в данном случае применяется атрибут placeholder, представляющий собой подсказку, а не название поля.) Цвет текста в заполненном поле (lukew) почти неотличим от названия следующего поля (password). Рассматриваемая форма очень проста, и описанную проблему вряд ли можно считать значительной. Однако чем более сложной будет становиться форма, тем большим может быть и масштаб проблемы.
И все же решение вышеописанной проблемы существует. Рассмотрим в качестве примера регистрационную форму мобильного приложения для управления проектами Basecamp, где название поля остается видимым вплоть до того момента, как вы начинаете вводить в него текст. (Эта опция не входит в штатный функционал веб-браузеров, и поэтому в данном случае разработчикам пришлось немного потрудиться.) Разница между текстом ответа и названием поля очевидна, поэтому пользователь вряд ли их перепутает (рис. 6.3).
Мобильные ответы
Спроектировать хорошую веб-форму для мобильного сайта совсем не сложно — достаточно просто задавать правильные вопросы при помощи элементов label. А вот сделать так, чтобы пользователям было легко давать правильные ответы, — задача куда более серьезная. К счастью, проектирование мобильных приложений не только накладывает ограничения, но и предоставляет целый ряд возможностей, позволяющих найти выход из этой ситуации.
Стандарты…
Если вы уже проектировали сайты, то наверняка знакомы с различными типами полей веб-форм. Наиболее часто используются следующие типы полей: чекбокс (checkbox), поле ввода пароля (password), радиокнопка (radio), выпадающий список (select), поле выбора имени файла (file pick), кнопка отправки (submit) и обычное текстовое поле (plain text). Придерживаясь этого стандарта, вы значительно облегчите пользователям взаимодействие с вашим мобильным сайтом (табл. 6.1).
Например, когда вы применяете стандартный выпадающий список, браузер устройства с активным экраном может представить его в виде большого количества элементов довольно крупного размера, а не как стандартное выпадающее меню, которое можно увидеть на стационарных компьютерах (рис. 6.4–6.5). Различные мобильные платформы будут по-разному отображать эти списки, однако в любом случае выбрать подходящий вариант с их помощью будет значительно проще. То же справедливо и в отношении кнопок отправки, радиокнопок, сообщений об ошибках и многого другого.
Есть, однако, и исключения. Несмотря на то что реализованный на мобильных платформах функционал меню обычно облегчает выбор из списка, иногда мобильные ограничения дают о себе знать. Например, если меню оказывается слишком длинным, то при масштабировании страницы оно часто выходит за пределы экрана, что осложняет выбор необходимых опций (рис. 6.6).
Иногда длинный список не разворачивается на весь экран, а прокручивается в небольшом окне, что также крайне неудобно. На таких устройствах, как iPhone, одновременно можно видеть не больше четырех-пяти пунктов меню. Поэтому если размер меню выходит за вертикальные или горизонтальные ограничения стандартного выпадающего списка, лучше выделить для него отдельную страницу.
В некоторых случаях лучше вообще отказаться от выпадающего меню — без него сделать выбор зачастую и проще, и быстрее. Как показывает практика, в случае тач-интерфейса выпадающее меню предполагает выполнение минимум четырех действий: сначала требуется нажатие, чтобы открыть меню, потом пролистывание — чтобы его просмотреть, затем снова нажатие — чтобы выбрать нужный вариант ответа, и еще одно нажатие — чтобы закрыть список и вернуться назад к форме. Если же форма содержит несколько выпадающих меню (рис. 6.7), то нажимать на экран приходится очень интенсивно.
К счастью, эту задачу можно решить при помощи пользовательских элементов управления, специально разработанных для устройств с тач-интерфейсом. Например, в мобильной версии туристического сайта Kayak (рис. 6.8) для ввода количества бронируемых номеров и числа проживающих вместо выпадающих меню применяется элемент управления «спиннер». Чтобы ввести новое значение, достаточно один раз нажать на кнопку «+» или «—». Это отличное решение для полей с ограниченным диапазоном выбора, таких как на сайте Kayak, где вы можете заказать не более двух гостиничных номеров.
На сайте Kayak необходимые поля проще заполнять еще и потому, что в них предустановлены значения, которые выбирает большинство посетителей (http://bkaprt.com/mf/51). Чаще всего клиентам требуется один номер, и, сделав «1» значением по умолчанию, разработчики сэкономили пользователям время и силы — ведь теперь тем не нужно вводить число вручную или выбирать его из списка.
Исследование, в ходе которого проводилось сравнение эффективности взаимодействия с пустыми формами и формами, содержащими значения по умолчанию, показало, что владельцы мобильных устройств заполняют формы второго типа в четыре раза быстрее, чем формы первого (http:// bkaprt.com/mf/52; PDF). Согласитесь, такая экономия времени дорогого стоит.
Выбирать даты путешествия на сайте Kayak также невероятно просто. В отличие от сайта American Airlines, где этой цели служат аж три выпадающих меню (рис. 6.7), клиентам Kayak достаточно отметить соответствующие даты в большом, занимающем почти весь экран календаре (рис. 6.9). И снова разработчики избавили пользователей от необходимости производить массу ненужных манипуляций.
Проектируя мобильную версию сайта, которая предполагает нестандартные способы ввода данных, не забывайте об устройствах без тач-интерфейса или с гибридным интерфейсом. Убедитесь, что посетители смогут взаимодействовать с вашим сайтом при помощи средств непрямой манипуляции (трекболов, трекпадов и т. д.), — укажите порядок элементов выпадающего меню, а также установите значения состояний: focus и: hover.
Новые стандарты.
Чтобы задать нестандартные поля для мобильного сайта, необходимо написать специальный код. Однако мобильные веббраузеры стремительно развиваются, и те элементы, которые сейчас требуют специальных действий, в недалеком будущем могут стать частью стандартной разметки (http://bkaprt.com/ mf/53). Более того, уже сегодня существует ряд решений, позволяющих значительно упростить ввод данных.
Начну с того, что в рамках стандарта HTML5 новые типы полей облегчают ввод данных определенного формата. В мобильном Safari и аналогичных ему браузерах при заполнении поля url (веб-адрес) открывается виртуальная буквенно-цифровая клавиатура с кнопками «.», «/» и «.com». При указании типа поля e-mail возникает виртуальная клавиатура с символами «.» и «@». А при указании типа поля number появляется цифровая клавиатура (рис. 6.10).
Спецификацию HTML5 можно использовать без опасений — браузеры, не поддерживающие новые типы полей, обнаружив неизвестный им тип поля, интерпретируют его как стандартный текст. (Изучить типы полей, поддерживаемых популярными мобильными веб-браузерами, можно в сравнительной таблице, составленной Питером-Полом Кохом (http://bkaprt.com/mf/55)).
Применение специальных типов полей форм дает положительные результаты даже на тех устройствах, браузеры которых не имеют виртуальной клавиатуры (поддерживающие HTML5 или менее распространенные спецификации, такие как CSS-MP или Wireless CSS), поскольку пользователям для ввода числовых данных не требуется переключаться в соответствующий режим. Кстати о числах: телефоны изначально создавались, чтобы набирать на них цифры, и большинство из них имеют виртуальную или физическую цифровую клавиатуру. Поэтому для ввода числовых последовательностей, таких как номер телефона или цена, задайте единое поле и предоставьте пользователям возможность набрать правильное значение на клавиатуре.
Несмотря на появление новых типов полей, основная часть данных по-прежнему вводится в формате обычного текста.
К счастью, и в этой сфере дополнительные атрибуты полей позволяют сделать жизнь мобильных пользователей проще.
Среди них:
• автоматическое добавление прописных букв (autocapitalize) — отключайте этот атрибут при вводе адресов электронной почты, паролей, веб-адресов и других данных, где имеет значение регистр; включайте при вводе имен собственных, таких как географические названия или имя/фамилия;
• автоматическое исправление (autocorrect): отключайте этот атрибут при вводе адресов электронной почты, паролей, веб-адресов и других нетекстовых данных; включайте при вводе текста и данных в свободной форме; не забывайте удалять лишние пробелы в конце слов, возникающие в режиме автоисправления текста.
Повторю еще раз: браузеры, не поддерживающие эти атрибуты, просто проигнорируют их, поэтому вы можете смело использовать их в своих формах. В современных браузерах ваши формы покажут все, на что они способны, и потребители будут вам благодарны — особенно после того, как увидят, что введенная ими информация не была уничтожена излишне активными штатными средствами автокоррекции, встроенными в операционную систему устройства.
Маски для особых случаев
Новые типы полей и дополнительные атрибуты позволяют владельцам мобильных устройств вводить данные быстро и точно. Но вы можете сделать их жизнь еще проще, добавив к полям соответствующие маски, задающие параметры ввода и ограничивающие объем вводимых данных.
Маски ввода поддерживают большинство мобильных операционных систем, поэтому неудивительно, что они есть во многих нативных приложениях. В случае мобильных браузеров основная задача по интеграции масок ввода в веб-формы ложится на плечи разработчиков и JavaScript. Так что полезно знать, что заставляет маску корректно работать.
В простейшем виде маска определяет верный формат вводимой информации. Например, вам необходимо получить адрес электронной почты пользователя на домене me.com — маска ввода позволит отсечь любую информацию, не соответствующую заданному формату. В данном случае поле адреса электронной почты будет содержать на конце «@me.com». Таким образом, вы сможете ограничить ввод символов после знака «@», гарантировав, что написанный электронный адрес будет содержать доменное имя me.com (рис. 6.11).
Как это работает? Пользователь вводит адрес электронной почты, при этом часть текста внутри поля, а именно «@me.com», остается видимой на экране. Система проигнорирует любые символы, набранные после знака «@». Это позволяет не только снизить вероятность ошибки, но и уменьшает число символов, вводимых владельцем мобильного устройства. И то и другое создает существенное преимущество.
Если вы хотите быть уверены, что ваша маска помогает пользователям вводить информацию, а не создает им дополнительные трудности, при добавлении масок к полям ввода следует учитывать несколько моментов. Прежде всего нужно точно указывать, какой формат данных предполагает то или иное поле. В описанном выше примере информация о домене была доступна пользователям сразу и оставалась видимой все время, пока они вводили адрес электронной почты.
Аналогичный пример — маска, используемая для ввода идентификационного номера налогоплательщика (рис. 6.12). В этом случае она будет не только игнорировать ввод дефисов (поскольку они уже включены в формат), но и любых нецифровых символов. ИНН должен содержать только цифры и два дефиса, и применение подобной маски к полю ввода не позволяет ошибиться и написать вместо цифры букву.
Однако не всегда маски позволяют получить ожидаемые результаты: некоторые из них могут настолько непредсказуемо меняться, что способны сбить вас с толку. Пример одной из таких масок показан на рис. 6.13: увидев маску ввода номера телефона, пользователь предполагает, что номер будет иметь следующий формат: «XXX–XX–XXXX» (лично я в таком случае предложил бы маску «_-_»). Но стоит ввести в поле первую цифру, как формат номера исчезает, а вокруг набранных символов появляются скобки — весьма неожиданно, не так ли? Процесс автоматического форматирования данных будет продолжаться до тех пор, пока пользователь не введет последнюю цифру.
В итоге телефонный номер будет состоять из цифр, скобок, пробела и дефиса — то есть выглядеть совсем не так, как предполагала его первоначальная маска. Для общепринятых данных, таких как номер телефона, возможно, это и не столь важно. Но общее правило работы с масками ввода гласит: изначально видимые маски ввода проще и удобнее, чем скрытые или появляющиеся постепенно.
Огласите весь список, пожалуйста!
Элементы label и поля ввода — это кирпичики, из которых строится форма. И эти кирпичики необходимо складывать так, чтобы они стимулировали взаимодействие компаний и их клиентов. Другими словами, важно, чтобы поля ввода были правильно организованы. По большому счету существуют три сценария ввода информации, которые мы должны принимать во внимание: последовательность взаимосвязанных вопросов, нелинейное обновление и контекстный ввод с целью немедленного реагирования.
Последовательный набор полей — это группа вопросов, которые необходимо задать, чтобы завершить определенные действия. Самый простой пример такого сценария — формы регистрации и оформления заказа. К этой группе относятся любые вопросы, на которые пользователь должен последовательно ответить, чтобы достичь конкретной цели (покупки, подписки на услуги и т. д.).
Несомненно, когда дело касается мобильного Интернета, правильная организация элементов label и полей ввода играет немаловажную роль, но все же одним из наиболее важных факторов является объем информации, запрашиваемой у пользователя. Чем меньше вопросов вы будете задавать, тем лучше.
Сравните первоначальный вид формы Get Online на мобильном сайте Boingo (рис. 6.14) и ее вид после проведенного мной редизайна (рис. 6.15): этот пример позволяет понять, от скольких элементов можно смело отказаться, чтобы сделать ваш сайт более лаконичным. Когда речь заходит о мобильных формах, следует действовать радикально — сокращать, сокращать и еще раз сокращать.
Однако сразу задавать пользователю все имеющиеся вопросы необходимо далеко не всегда, ведь зачастую тому требуется лишь изменить (или обновить) некоторые поля формы.
А если для редактирования открыты все имеющиеся поля, ему непросто найти среди них те, в которые он планировал внести изменения, — и особенно трудно это сделать на маленьком экране мобильного устройства.
В этом случае более чем оправданным будет применение нелинейного подхода к проектированию формы. В качестве примера давайте рассмотрим профиль пользователя на мобильном сайте Bagcheck. Как правило, мы достаточно редко редактируем свои данные; и еще реже изменяем их полностью. Поэтому на сайте Bagcheck процесс редактирования профиля организован следующим образом: в соответствующих полях формы отображены все пользовательские данные, и, чтобы изменить те или иные из них, необходимо просто нажать на соответствующую строчку, вызвав диалоговое окно (с клавиатурой и курсором в поле) или отдельную страницу для редактирования.
При проектировании форм необходимо принимать в расчет высоту виртуальной клавиатуры (обычно она занимает примерно половину экрана). Оптимально, если клавиатура не будет закрывать поле ввода и кнопки формы.
И последний (но от этого не менее важный) сценарий, позволяющий легко и быстро создавать и редактировать контент, — это контекстный ввод. В этом случае в тексте обозначается область, которую пользователь может редактировать. Форма контекстного ввода обычно состоит из одного поля. Взгляните на мобильный сайт Quora, где можно комментировать ответ, не покидая текущей страницы (рис. 6.17). Такая схема позволяет оперативно реагировать на сообщения других пользователей и вполне соответствует привычным способам взаимодействия с мобильными устройствами.
Формы и поля ввода… а что еще?
Сегодня возможности мобильных устройств позволяют выйти далеко за рамки ограничений обычных форм ввода. Геолокация, ориентация устройства, ввод аудио и видео, технология коммуникации ближнего поля (NFC) и многое другое позволяет пользователям создавать и редактировать контент, не заполняя форму.
В качестве иллюстрации давайте подробно рассмотрим функцию определения местоположения пользователя. Резервируя гостиничный номер на мобильном сайте Kayak, вы можете ввести данные о том, где находитесь, с клавиатуры или выбрать текущее местоположение, просто нажав на иконку справа от поля ввода. Мобильный сайт Twitter позволяет добавлять к вашему сообщению информацию о текущем местоположении посредством единственного нажатия (рис. 6.18).
В обоих случаях пользователи избавлены от необходимости вводить текст.
Есть и другие интересные примеры. Задействуя видеокамеру мобильного устройства, приложение Google Goggles способно идентифицировать книги, вина, картины и ориентиры на местности. С его помощью можно сканировать визитные карточки или переводить иностранные тексты (рис. 6.19). Только представьте, какой объем текста понадобилось бы ввести, чтобы добиться аналогичного результата.
Технология коммуникации ближнего поля (NFC) предоставляет нам дополнительные возможности. Мобильные устройства считывают передающиеся на радиочастотах метки (RFID). Для того чтобы ваше устройство начало взаимодействовать с объектом, транслирующим в эфир свою метку («цифровой штрихкод»), достаточно просто оказаться с ним рядом. Хотите больше узнать о продукте? Достаточно подойти к нему на расстояние, позволяющее уловить сигнал, и вся необходимая информация появится на экране вашего мобильного устройства. О каких полях и формах тут может идти речь?
И все же давайте вернемся к сегодняшним реалиям мобильного веба. Имея доступ к API мобильного устройства, нативные приложения могут управлять вводом аудио и видео, NFC-взаимодействием (там, где оно доступно) и другими функциями. И хотя в настоящее время широко обсуждается возможность доступа к камере и NFC-приемнику через браузер, законченных решений в этой области пока нет. Но динамика развития мобильных технологий такова, что новые подходы и идеи появляются чуть ли не каждый день. Не волнуйтесь, в скором времени при разработке веб-приложений вы сможете использовать функции API в полной мере.
Ввод до упаду
Мобильные устройства существуют уже немало лет, но до недавнего времени возможности ввода контента с их помощью оставались рудиментарными. Сегодняшнее сочетание технических характеристик устройств, скоростного доступа в Интернет и растущего желания пользователей поделиться информацией «здесь и сейчас» открывает перспективы, которыми не стоит пренебрегать.
• Активно поощряйте пользователей создавать и редактировать информацию при помощи мобильных устройств.
• Убедитесь, что элементы label оптимизированы под мобильные устройства и предельно четко формулируют заданный вами вопрос.
• Везде, где возможно, применяйте форматирование ввода, атрибуты и маски, чтобы избежать проблем, связанных с ошибками, возникающими при вводе данных.
• Рассмотрите возможность использования кастомизированных элементов, если они действительно помогут пользователям вводить информацию легко и точно.
• Правильно применяйте сценарии последовательного, нелинейного и контекстного ввода информации.
• Используйте все имеющиеся возможности для расширения способов ввода информации через мобильное устройство.
Мы изучили ввод данных, средства взаимодействия и общую организацию информации на мобильных устройствах. Теперь давайте поговорим о великом множестве устройств, для которых предназначаются все эти элементы. Итак, переходим к следующей главе: верстка.
7
ВерсткаПРИНЦИПЫ ОРГАНИЗАЦИИ КОНТЕНТА и элементов интерфейса, применяемые при разработке дизайна обычных сайтов, несомненно, могут быть полезны и при проектировании мобильных веб-приложений. Но как быть уверенными в том, что эти принципы будут актуальны для любых мобильных устройств — как существующих сегодня, так и тех, что появятся в ближайшее время?
Для этого необходимо:
• принять тот факт, что в обозримом будущем мобильная индустрия будет развиваться столь же стремительными темпами;
• «сообщать» мобильным браузерам, что созданный вами сайт оптимизирован для просмотра;
• создавать «гибкие» (flexible), «резиновые» (fluid) и «отзывчивые» (responsive) макеты веб-страниц;
• хорошо представлять, в чем состоят технические различия между устройствами;
• проектируя мобильные сайты, избавляться от всего лишнего и ненужного.
Лишь изменения постоянны
Пока я обдумывал и писал эту книгу, мобильная отрасль несколько раз претерпела кардинальные изменения. Прежние лидеры рынка мобильных платформ утратили свои позиции. Появились устройства с новыми возможностями, а значит, и новыми ограничениями. Производители устройств, разработчики мобильных платформ и операторы сотовой связи объявили о партнерстве.
Добро пожаловать в мобильный мир, где постоянны лишь изменения! Этот мир продолжает стремительно меняться, поэтому я сосредоточусь на тех тенденциях, которые в последнее время незыблемо задавали параметры разработки дизайна для мобильных устройств. Речь идет о появлении более мощных процессоров, увеличении скорости передачи данных, росте популярности тач-интерфейса и совершенствовании веб-браузеров.
Так что же делать веб-дизайнеру, оказавшемуся в этом море постоянной нестабильности? Плыть по воле волн? Ни в коем случае. Вы все еще на Диком Западе, а значит, придется стать ковбоями. Рискуйте, экспериментируйте, творите и примите как данность, что в настоящий момент далеко не все границы между устройствами, браузерами и веб-стандартами нанесены на карту.
Итак, седлайте скакунов — и в путь! Вооружившись принципами и методами мобильной верстки, попробуем укротить непокорные мобильные устройства. (Обещаю, ковбойских метафор больше не будет.)
Вы здесь ради них
Главное в мобильном веб-дизайне — «сообщить» мобильным браузерам, что вы потратили время и силы, чтобы адаптировать ваш сайт для каждого из них. Я помню об обещании не углубляться в программные коды, но все же здесь необходимо привести синтаксис тега viewport[9] как важнейшей части любого мобильного сайта.
<meta name=«viewport» content=«width=device-width»>
Процитирую Питера-Пола Коха, много писавшего о применении этого атрибута (http://bkaprt.com/mf/56):
По умолчанию атрибутивное значение viewport устанавливается равным ширине, которую разработчик считает оптимальной для просмотра сайтов на обычных компьютерах. Задав для тега viewport значение device-width[10], вы можете быть уверены, что ширина страниц вашего сайта будет соответствовать ширине экрана того устройства, на котором ее будут просматривать.
Тег viewport позволяет также преодолеть различия в разрешающей способности дисплеев мобильных устройств. Разрешающая способность, измеряемая в пикселях на дюйм (ppi), показывает число пикселей, из которых состоит горизонтальная или вертикальная линия длиной в 1 дюйм, отображенная на экране конкретного устройства. iPhone первого поколения имел экран с диагональю 3,5 дюйма и разрешением 320 X 480 px; таким образом, разрешающая способность этого экрана составляла 164 ppi. У смартфона Google Nexus One был 3,7-дюймовый экран с разрешением 480 X 800 px, а следовательно, его разрешающая способность равнялась 252 ppi. Почему это так важно?
Разрешающая способность определяет физические размеры элементов, отображающихся на экране. Чем выше ppi, тем меньше физические размеры каждого пикселя. Посмотрите, как графический объект — в данном случае набор кнопок — выглядит на мониторе Apple Cinema Display, ppi которого составляет примерно 94 единицы, как и у большинства мониторов настольных компьютеров. А теперь взгляните, как те же кнопки отображаются на экране смартфона Nokia N900 с разрешающей способностью 266 ppi. Разница заметна невооруженным глазом. То, что в первом случае было крупным и читаемым, во втором стало крошечным и практически нечитаемым (рис. 7.1).
Если вы создаете приложение с расчетом на то, что его будут просматривать на устройствах, имеющих разную разрешающую способность экрана, то подобный нюанс может стать проблемой. Однако решить ее довольно легко — для этого достаточно при разработке дизайна вашего сайта включить в него тег viewport, который распознают все мобильные браузеры. Как заметил Питер-Пол Кох (http://bkaprt.com/mf/56), браузеры для iPhone первого поколения (разрешающая способность экрана 164 ppi), Google Nexus One (252 ppi) и iPhone 4 (329 ppi) используют значение параметра device-width, равное 320 px, что позволяет обеспечить столь необходимое постоянство отображения веб-страниц.
Следующий вопрос: просмотр изображений высокого разрешения. В отличие от интерпретируемых браузером объектов (формы, кнопки, текст, линии и другие визуальные элементы) растровые изображения автоматически не адаптируются к разрешающей способности того или иного экрана. На дисплеях с высокой разрешающей способностью они будут иметь правильные физические размеры, но при этом отображаться недостаточно четко и резко (рис. 7.2).
Чтобы решить эту проблему, вам потребуется сделать два комплекта изображений: с высоким (удвоенным) и стандартным разрешением. Затем, используя медиазапросы CSS3 (media queries), JavaScript или серверный сценарий, необходимо дать браузеру команду загружать на устройства с высокой разрешающей способностью изображения из первого набора (http://bkaprt.com/mf/57).
Если идея с двумя комплектами изображений вас не привлекает (да и кому она может понравиться?), максимально задействуйте возможности визуального оформления, заложенные в CSS. Градиентные заливки и скругленные углы в дизайне мобильного сайта Yahoo! (рис. 7.2) создаются средствами CSS3 и поэтому отлично выглядят на экранах как с высоким, так и с низким разрешением. Благодаря их использованию разработчикам не пришлось тратить время на создание нескольких версий каждого изображения, а посетители были избавлены от необходимости их загружать.
Мобильные браузеры, не поддерживающие визуальные эффекты CSS3, вместо градиентных заливок и скругленных углов будут отображать однотонный фон и прямые углы. Ничего страшного.
Однако следует иметь в виду, что чрезмерное увлечение CSS3-эффектами может существенно влиять на производительность, поскольку на некоторых устройствах многочисленные тени и градиентные фоны замедляют загрузку страницы. К счастью, движки мобильных браузеров постоянно совершенствуются, так что в ближайшее время и эта проблема будет решена.
Гибкость и отзывчивость
Несмотря на то что некоторые мобильные устройства, имея разную разрешающую способность экрана, используют одну величину атрибута viewport, только значения ширины страницы нашего сайта будет явно недостаточно. Взять хотя бы тот факт, что, даже если бы все устройства имели device-width, равный 320 пикселям, нам все равно пришлось бы предусмотреть разную ширину страницы для экрана в вертикальном и горизонтальном положениях.
Чтобы справиться с этой, а заодно и с любыми другими проблемами, связанными с шириной страницы, мы должны сделать верстку максимально адаптируемой к устройствам отображения. И как бы мы ни называли такой макет — гибким (flexible) или резиновым (fluid), — дизайн, при котором страница сужается и расширяется в зависимости от размера экрана, является обязательным атрибутом мобильного вебдизайна. При таком подходе элементы интерфейса (например, поля поиска и элементы меню на мобильном сайте Google Places, рис. 7.3) меняются в зависимости от доступного им пространства.
Гибкий макет — вещь важная, но это только начало.
Отзывчивый веб-дизайн
С увеличением диапазона размеров экранов мобильных устройств для корректного отображения веб-страниц гибкого макета оказывается недостаточно. Только представьте, сколько существует возможных вариантов размещения элементов вашего сайта на устройствах с шириной экрана 768 px и 320 px. Экран с горизонтальным разрешением 768 px предлагает в два с половиной раза больше свободного пространства! Очевидно, мы можем сделать что-то гораздо более интересное, чем просто растянуть страницу до границ окна! И здесь нам на помощь приходит технология отзывчивого веб-дизайна.
Этот подход включает гибкий макет на основе сетки, гибкие изображения, медиазапросы CSS3 и (иногда) немного JavaScript — все вместе эти элементы позволяют создавать дизайн, который будет адаптироваться к изменениям разрешения экрана и размеров области просмотра. Технология отзывчивого веб-дизайна предполагает, что вы начинаете разработку вашего сайта с создания его мобильной версии, а затем постепенно совершенствуете его или приводите в соответствие с требованиями для вновь появляющихся устройств.
На практике это означает выбор определенных значений ширины экрана, которые станут «контрольными точками», задающими новые параметры отображения страницы и ее графических элементов (изображений, видео). Другими словами, «контрольная точка» — это условный оператор, определяющий, соответствует ли устройство определенному критерию (например, ширина окна браузера менее 600 px). Если условие выполняется, браузер использует новый набор параметров отображения страницы (как правило, новую таблицу стилей CSS, а иногда и новый код JavaScript), а сайт видоизменяется, масштабируясь под доступное пространство. О деталях этого процесса можно узнать, прочитав отличную книгу Итана Маркотта «Отзывчивый веб-дизайн»[11].
Таблицы стилей CSS определяют наличие и расположение элементов на странице, а также размер изображений. Однако изменения не должны быть ни кардинальными, ни еле заметными (рис. 7.4).
Итак, применяя принципы отзывчивого веб-дизайна, мы можем масштабировать нашу веб-страницу под размеры экрана устройства, на котором ее будут просматривать. Но устройства отличаются не только размерами экранов.
Взаимодействие с устройствами
Современные устройства предполагают не только многообразие характеристик и ограничений, но также и различные способы взаимодействия. Сравните телевизоры со встроенным доступом в Интернет, настольные компьютеры, ноутбуки, планшеты, смартфоны и обычные телефоны — каждое из этих устройств уникально по нескольким параметрам:
• Поза, которую принимает их владелец: сидит в кресле на расстоянии нескольких метров от экрана, в течение нескольких часов непрерывно находится за рабочим столом, сидит на диване, или лежит в кровати с устройством в руках, или использует его несколько раз в течение дня там, где это удобно.
• Основной метод ввода данных: жесты/дистанционное управление, мышь/клавиатура, нажатие/сенсорный ввод, цифровая клавиатура.
• Размер экрана: настенный, настольный, переносной, наладонный или еще меньше.
Комбинация этих параметров зачастую определяет способ взаимодействия пользователя с устройством. Каждый из этих способов требует определенного подхода к дизайну пользовательского интерфейса, поскольку то, какие именно задачи решает владелец при помощи своего устройства, во многом зависит от условий, в которых он находится в данный момент, так же как, например, проектирование сайта и элементов управления зависят от методов ввода данных и размеров экрана.
В результате разработчикам веб-приложений во многих случаях приходится создавать уникальное решение для каждого интерфейса. Например, сервис потокового видео Netflix спроектировал отдельные сайты для телевизоров со встроенным доступом в Интернет, планшетов, настольных компьютеров и смартфонов (рис. 7.5). Конечно, создание такого числа вариантов занимает немало времени, зато каждый из разработанных интерфейсов максимально учитывает особенности взаимодействия пользователей с конкретным устройством.
Разумеется, вы можете спроектировать единый пользовательский интерфейс, но результатом такого «универсального» решения, скорее всего, станет необходимость идти на компромиссы и соглашаться с наличием множества ненужных элементов. К тому же единый дизайн не способен в полной мере учесть ограничения и возможности использования тех или иных устройств.
Например, телевизор со встроенным доступом в Интернет позволяет просматривать текстовые списки, оптимизированные под обычный мобильный телефон, но вряд ли кто-то захочет это делать. И напротив, веб-приложение, оптимизированное под планшетные компьютеры, вполне подойдет и для стационарных ПК, поскольку у первых экран меньше, средства взаимодействия с пользователем проще, а кнопки и ссылки крупнее. И хотя при разработке этого интерфейса не учитывались ни поза, которую принимает владелец устройства, ни методы ввода данных, ни размеры экрана обычного компьютера, он все равно будет функциональным.
Понимание особенностей взаимодействия пользователей с различными устройствами помогает задать критерии, определяющие новые параметры отображения веб-страницы и ее графических элементов — ведь сайт должен не только хорошо выглядеть, но и хорошо работать. Расположение и масштаб элементов должны соответствовать доступному пространству и учитывать имеющиеся средства ввода данных (например, тач-зоны не могут быть меньше определенного размера).
В сочетании с принципами отзывчивого дизайна такой подход обеспечит эффективную работу вашего сайта на любых мобильных устройствах — как существующих сегодня, так и будущих.
Чем проще, тем лучше!
На всякий случай, если до сих пор эта мысль не прозвучала достаточно убедительно, повторю: основное правило разработки мобильных интерфейсов — чем проще, тем лучше. Тач-зоны должны быть достаточно крупными, чтобы мы могли управлять ими при помощи своих не всегда точных пальцев. Отзывчивый дизайн должен помогать сайтам адаптироваться к изменениям разрешения экрана и размеров области просмотра. По мере увеличения объемов контента и появления устройств с новыми характеристиками мобильные приложения должны оставаться простыми и удобными в использовании.
Все это подталкивает нас к тому, чтобы на экранах мобильных устройств располагалось как можно меньше элементов — это позволит пользователям легко управлять нашими сайтами, быстро достигать поставленных целей и допускать меньше ошибок. Поэтому, проектируя мобильный сайт, оставляйте лишь то, что действительно необходимо вашим пользователям, независимо от того, какие задачи они будут решать — искать или изучать информацию, проверять обновления или создавать и редактировать контент.
Избавляясь от всего лишнего, вы не только облегчаете процесс создания мобильного сайта, но и помогаете пользователям сосредоточиться на выполнении основных задач. И если они вдруг начнут просить, чтобы и обычные сайты стали такими же, как мобильные версии, знайте: вы на правильном пути.
Проектирование пространства
Мобильный ландшафт продолжает видоизменяться, поэтому дизайн наших сайтов должен быть готов к тому, чтобы полностью отвечать потребностям пользователей независимо от времени и места их взаимодействия с веб-приложением, технических характеристик мобильных устройств или размеров их экранов.
• Примите тот факт, что в обозримом будущем мобильная индустрия продолжит развиваться столь же стремительными темпами.
• Используйте тег viewport, чтобы «сообщать» мобильным браузерам, что в процессе разработки сайта вы о них не забыли.
• Не забывайте о разрешающей способности экранов и старайтесь показывать изображения высокого разрешения на устройствах, позволяющих это делать.
• Применяйте принципы отзывчивого веб-дизайна, чтобы адаптировать свои сайты к различным устройствам отображения.
• Создавая отзывчивый веб-дизайн или используя серверные процедуры, учитывайте особенности взаимодействия пользователей с различными устройствами.
• Сводите число элементов сайта к минимуму, позволяющему сохранять функциональность.
Перечень рассмотренных в этой книге принципов и методов разработки мобильных веб-приложений, каким бы широким он ни был, нельзя считать исчерпывающим. Новые решения появляются практически каждый день. Мобильная вселенная постоянно расширяется, и даже само понятие мобильного устройства начинает размываться. Принципы мобильного веб-дизайна еще только формируются, и основные изменения ждут нас впереди. Держите руку на пульсе!
ЗаключениеНадеюсь, что мой простой призыв «сначала мобильные!» станет катализатором новых идей и решений. Сегодня мобильные устройства заменили нам персональный компьютер: они всегда при нас, они подключены к Интернету, они позволяют решать массу различных задач, общаться друг с другом или просто хорошо проводить время. Поэтому если при разработке сайтов мы прежде всего будем думать об этих персональных портативных устройствах, мы сможем:
• воспользовавшись растущей популярностью мобильного Интернета, предложить потребителям новые способы взаимодействия с нашими сайтами и приложениями;
• приняв ограничения, присущие мобильным устройствам, сконцентрироваться на наиболее приоритетных задачах и функциях;
• используя возможности мобильного интерфейса, найти инновационные решения для удовлетворения потребностей наших клиентов;
• переосмыслив накопленный нами опыт в области традиционного веб-дизайна, по-новому взглянуть на свойственные мобильным устройствам особенности организации контента, взаимодействия с пользователями, ввода информации и визуальных решений.
И в завершение — несколько практических советов.
• Если есть возможность, тестируйте верстку и код на реальных мобильных устройствах. Программы-эмуляторы и браузеры стационарных компьютеров не способны в полной мере их заменить.
• Если в вашем распоряжении нет нужного устройства, отправляйтесь в ближайший магазин и протестируйте результаты вашей работы на выставочных образцах.
• Прототипы, прототипы, прототипы! Чем раньше вы сможете опробовать то или иное мобильное решение, тем быстрее поймете, работает ли оно в реальном мире.
И последнее по счету, но не по значению. Не бойтесь начинать с малого. Некоторые из самых крупных и успешных проектов, реализованных в мобильном бизнесе, начинались с небольших экспериментов, проводившихся командами страстно увлеченных веб-дизайнеров и разработчиков. Вам не нужно знать о мобильных технологиях все — возьмите с собой то, что уже знаете, и отправляйтесь в путь.
БлагодарностиНаписание книги, пусть и такой небольшой, как эта, — огромное дело. К счастью, у меня было множество помощников. Джеффри Зельдман, Эрик Майер и вся команда An Event Apart дали мне прекрасную возможность обсудить тему книги на замечательной веб-конференции. Всюду, где мне доводилось представить аудитории свою концепцию, я слышал множество ценных советов и важных вопросов. Именно они помогли мне преобразовать разрозненные мысли и идеи в книгу, которую вы только что прочитали.
Неоценимую помощь в работе мне оказали и советы моих рецензентов: Брайана и Стефани Ригер, Джейсона Григсби, Крейга Вилламора, Питера-Пола Коха, Джоша Кларка. Несколько небольших, но очень важных рекомендаций мне дал Итан Маркотт. Для автора способность слушать не менее важна, чем умение писать, и я благодарен всем этим людям за то, что они предоставили мне возможность слушать их в течение последних лет.
Оформить мысли в слова мне помогла команда A Book Apart. Я получил истинное наслаждение, работая с редактором Мэнди Браун, литературным редактором Кристой Стивенс, потрясающим веб-дизайнером Джейсоном Санта-Марией и, конечно же, с властелином дизайна Джеффри Зельдманом.
Эта книга не появилась бы на свет, если бы меня не поддерживала моя жена Аманда. Несмотря на заботы о новорожденной дочке и нашем двухлетнем сыне, на занятие моим стартапом и мои постоянные разъезды, она непостижимым образом смогла убедить себя в том, что моя идея написать книгу не совсем безумна. Возможно, она была единственным человеком, кто так считал. Я со всей любовью посвящаю эту книгу ей.
Приложение
Полные веб-адреса упомянутых в книге источниковВведение
1. http://www.lukew.com/ff/entry.asp71270
2. http://www.lukew.com/ff/entry.asp71226
3. http://www.lukew.com/ff/entry.asp71225
Глава 1
4. http://www.smartonline.com/smarton-products/smarton-mobile/smartphones-pass-pc-sales-for-the-first-time-in-history/
5. http://articles.businessinsider.com/2011 -02-15/ tech/29983706_1_tabletmarket-pcs-smartphones
6. http://www.comscore.com/Press_Events/Press_ Releases/2011/1/Webbased_Email_Shows_Signs_of_Decline. in_the_U.S._While_Mobile_Email_Usage_on_the_Rise
7. http://news.bango.com/2010/02/16/600-percent-growth-in-mobile-webusage/
8. http://mobithinking.com/mobile-marketing-tools/latest-mobile-stats
9. http://www.morganstanley.com/institutional/techresearch/ pdfs/MS_Economy_Internet_Trends_102009_FINAL.pdf
10. http://www.mediapost.com/publications/?fa=Articles. showArticle&art_aid=120590
11. http://www.lukew.com/ff/entry.asp71361
12. http://www.lukew.com/ff/entry.asp71269
13. http://techcrunch.com/2010/12/13/google-mobile-searches-grew-130-percent-in-q3/
14. http://www.mobiadnews.com/7p=5133
15. http://www.youtube.com/watch7v=8aa0tVJQcg0
16. http://en.wikipedia.org/wiki/T9_Cpredictive_text)
17. http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ ns537/ns705/ns827/white_paper_c11-520862.html
18. http://www.comscore.com/Press_Events/Press_ Releases/2010/3/Facebook_and_Twitter_Access_via_Mobile_ Browser_Grows_by_Triple-Digits
19. http://newsroom.cisco.com/dlls/ekits/Cisco_VNI_Global_ Mobile_Data_Traffic_Forecast_2010_2015.pdf
20. http://www.gartner.com/it/page.jsp7idH466313
21. http://blog.admob.com/2008/12/18/impact-of-new-rim-handsets-stormrising/
22. http://officialblog.yelp.com/2011/02/via-yelp-mobile-yelpers-call-a-localbusiness-every-other-second.html
23. http://www.lukew.com/ff/entry.asp71131
24. http://www.cloudfour.com/links-do-not-open-apps
25. http://blog.twitter.com/2010/09/evolving-ecosystem.html
26. http://danzarrella.com/new-data-on-mobile-facebook-posting.html
27. http://www.facebook.com/press/info.php7statistics
28. http://joehewitt.com/post/ipad/
Глава 2
29. https://developer.mozilla.org/en/canvas_tutorial
30. http://www.html5rocks.com/en/tutorials/appcache/beginner/
31. http://googleresearch.blogspot.com/2009/06/speed-matters.html
32. http://blog.compete.com/2010/03/12/smartphone-owners-a-ready-andwilling-audience/
33. http://readitlaterlist.com/blog/2011/01/is-mobile-affecting-when-we-read/
34. http://www.lukew.com/ff/entry.asp71259
Глава 3
35. http://itunes.apple.com/us/app/nearest-tube/ id3224366837mt=8
36. http://stackoverflow.com/questions/1649086/detect-rotation-of-androidphone-in-the-browser-with-javascript
37. http://mail.glustech.com/SnowGlobe/
38. http://thenextweb.com/apps/2010/12/21 /hidden-safari-mobile-featurereveals-augmented-reality-capability/
Глава 4
39. http://www.dmolsen.com/mobile-in-highered/2011/02/07/ the-universityhome-page-mobile-first/
Глава 5
41. http://paidcontent.org/article/419-pontiflex-about-half-of-mobile-appclicks-are-accidental/
42. http://developer.apple.com/library/ios/#documentation/ UserExperience/Conceptual/MobileHIG/Introduction/ Introduction.html
43. http://www.lukew.com/ff/entry.asp71085
44. http://go.microsoft.com/7linkid=9713252
45. http://www.lukew.com/touch
46. http://www.lukew.com/ff/entry.asp71197
47. http://en.wikipedia.org/wiki/Progressive_enhancement
Глава 6
48. http://www.lukew.com/ff/entry.asp71198
49. http://mashable.com/2010/08/07/ebay-facts/
50. http://mashable.com/2011/01/07/40-of-all-tweets-come-from-mobile/
51. http://www.lukew.com/ff/entry.asp7691
52. http://www.medien.ifi.lmu.de/pubdb/publications/pub/ deluca2007pmc/deluca2007pmc.pdf
53. http://www.lukew.com/ff/entry.asp71235
55. http://www.quirksmode.org/html5/inputs_mobile.html
Глава 7
56. http://www.quirksmode.org/blog/archives/2010/09/ combining_meta.html
57. http://www.lukew.com/ff/entry.asp71142
58. http://www.morganstanley.com/institutional/techresearch/ mobile_internet_report122009.html
59. http://www.slideshare.net/kleinerperkins/kpcb-top-10-mobile-trendsfeb-2011
62. http://yiibu.com/about/site/index.html
63. http://www.cloudfour.com/category/mobile-web-and-services/
64. http://www.lukew.com/ff/entry.asp71337
65. http://www.lukew.com/ff/entry.asp71193
66. http://www.cloudfour.com/on-mobile-context/
67. http://globalmoxie.com/blog/mobile-web-responsive-design. shtml
Помощь онлайнНужно больше данных?
Отличным источником фактов и интересной информации для меня служит Mobile Internet Report — исследование инвестиционного банка Morgan Stanley. Оно содержит сотни файлов с данными обо всех основных тенденциях в мобильном мире (http://bkaprt.com/mf/58).
Основным автором этого отчета на протяжении нескольких лет была Мэри Микер, после перехода в компанию Kleiner Perkins она продолжает публиковать свои выводы (http:// bkaprt.com/mf/59).
Если вам интересны данные о развитии мобильного рынка, обратите внимание на статьи и заметки Хораса Дедью на сайте Asymco (http://bkaprt.com/mf/60).
Кроме того, и я каждый понедельник размещаю в своем блоге статьи, посвященные дизайну и программированию для мобильных устройств, а также другим вопросам (http://bkaprt.com/mf/61).
Концепция «сначала мобильные!»
Я рассказываю лишь об основах концепции «сначала мобильные!». Более детальное описание этого принципа можно найти в других источниках.
• Брайан и Стефани Ригер рассказали о процессе создания сайта под названием Yiibu, о своем подходе к верстке, стилям и контенту (http://bkaprt.com/mf/62).
• Блог Cloud Four содержит огромное количество отличных статей, посвященных теме пересечения принципов мобильного и обычного веб-дизайна (http://bkaprt.com/mf/63).
Бесконечные споры
Практически любой вопрос в области технологий и веб-дизайна вызывает бурные обсуждения, и вопросы проектирования для мобильных устройств — не исключение. Вот лишь несколько ссылок на самые злободневные дискуссии.
• Мобильные приложения против мобильных веб-решений: когда и почему лучше выбирать тот или иной вариант (http://bkaprt.com/mf/64, http://bkaprt.com/mf/65)?
• Понимаем ли мы суть мобильного контекста и умеем ли программировать под него? Джейсон Григсби суммирует основные вопросы и приводит на своем сайте ссылки на ряд интересных статей (http://bkaprt.com/mf/66).
• И наконец, следует создавать отдельные версии (мобильную и стационарную) одного и того же сайта или применять отзывчивый веб-дизайн? Все зависит от ситуации, утверждает Джон Кларк в завершающем разделе своей статьи (http://bkaprt.com/mf/67).
Об авторе
Люк Вроблевски — сооснователь и руководитель социальной сети Bagcheck (http://bagcheck.com), которая была приобретена компанией Twitter Inc. всего через девять месяцев после создания. До этого он занимал пост директора по дизайну в компании Yahoo! занимаясь вопросами совершенствования продуктов и пользовательских интерфейсов. Кроме того, Люк успел поработать старшим дизайнером пользовательских интерфейсов в eBay Inc., где руководил разработкой дизайна потребительских продуктов (таких как eBay Express и Kijiji), а также основать компанию LukeW Ideation & Design (http://www.lukew.com), предоставляющую консультации в области продуктовых стратегий и дизайна, и выступить сооснователем Ассоциации интерактивного дизайна (IxDA).
В разные годы он преподавал основы дизайна пользовательских интерфейсов в Университете штата Иллинойс и работал старшим дизайнером в Национальном центре суперкомпьютеров (NCSA), где был создан первый популярный графический веб-браузер NCSA Mosaic.
Люк — автор популярной книги по веб-дизайну Web Form Design («Дизайн веб-форм»), а также множества статей о дизайне и стратегии в области цифровых продуктов. Он желанный гость на отраслевых мероприятиях и участник многих конференций по всему миру.
© 2012 Luke Wroblewski. All rights reserved
© Перевод на русский язык, издание на русском языке, оформление. ООО «Манн, Иванов и Фербер», 2012
Примечания
1http://digit.ru/telecom/20111128/386853468.html
(обратно)
2Термином «фичафон» (feature phones) обычно обозначают устройства низшего в сравнении со смартфонами ценового диапазона и с меньшим набором функций. Первоначально фичафонами называли телефоны, которые имели больший набор функций, нежели традиционные мобильные телефоны. Современные модели могут иметь тачскрин, использоваться для GPS-навигации, подключения к Wi-Fi и мобильному Интернету. Здесь и далее прим. ред.
(обратно)
3Апп-сторы — онлайн-магазины, торгующие приложениями для мобильных устройств.
(обратно)
4Спрайт — технология группировки изображений для сокращения времени загрузки сайта.
(обратно)
5Существуют два метода взаимодействия пользователя с мобильным устройством: прямая и непрямая манипуляция. Прямая манипуляция предполагает нажатие или физическое перемещение элементов интерфейса. Непрямая манипуляция характерна для устройств без тач-интерфейса, управление которыми осуществляется при помощи таких средств как трекпады, трекболы, колесики прокрутки или физическая клавиатура.
(обратно)
6Natural User Interface (англ.) — естественный пользовательский интерфейс. Термин и подход, который он обозначает, был предложен профессором Торонтского университета Томасом Мэнном в 1980-е годы.
(обратно)
7WIMP (Windows, Icons, Menus, Pointers) — стиль взаимодействия, при котором для управления положением курсора применяется физическое устройство, а информация предоставляется пользователю в виде окон и иконок. При этом все доступные команды собраны в меню и управляются курсором мыши. Был придуман Мерзугой Уильбертсом в 1980 году. Сегодня это слово нередко выступает в качестве синонима «графического интерфейса пользователя».
(обратно)
8Label — тег, функция которого заключается в отображении названия того или иного элемента ввода данных в форме. Используется как атрибут либо как контейнер, внутрь которого помещается соответствующий элемент формы.
(обратно)
9Тег viewport позволяет задавать точные размеры области просмотра браузера.
(обратно)
10Параметр device-width делает ширину окна просмотра браузера равной ширине экрана устройства.
(обратно)
11Маркотт И. Отзывчивый веб-дизайн. М.: Манн, Иванов и Фербер, 2012.
(обратно)Оглавление
От партнера российского издания Предисловие Введение Часть 1 Почему так важен принцип «сначала мобильные!» Рост 2 Ограничения 3 Потенциальные возможности Часть 2 Как стать мобильным 4 Организация 5 Действия 6 О вводе 7 Верстка Заключение Благодарности Приложение Полные веб-адреса упомянутых в книге источников Помощь онлайн Об авторе
