Текст книги "Контентная стратегия для мобильных устройств"

Не так давно, путешествуя с тремя друзьями, я вылетала из аэропорта техасского города Остин. Поскольку мы прибыли немного раньше, чем объявили посадку, я решила передохнуть в United Club, подальше от толпы авиапассажиров. Было бы невежливо бросить друзей, поэтому мне понадобилось узнать, скольких гостей я могу привести с собой в клуб.

Введя простой поисковый запрос в Google, я быстро нашла многообещающую ссылку (рис. 1.8).

^{Рис. 1.8. В выдаче по поисковому запросу «Членство в United Club» видно, что нужные сведения есть на полной версии сайта. Но, поскольку мобильный сайт перенаправляет ссылку, пользователь попадает на главную страницу мобильного сайта}

Увы, перейдя по ссылке для членов United Club, я попала на главную страницу mobile.united.com. Когда сайт клуба идентифицирует устройство клиента, пришедшего с поисковой машины, как мобильное, он тут же автоматически перенаправляет пользователя на мобильную версию, не удосуживаясь проверить, есть ли там нужная информация. И если ее там не оказывается, пользователь просто попадает на главную страницу. Мобильный редирект, который прерывает поиск, – это что, удачное решение?

Да, там есть ссылка на полную версию сайта, но она тоже ведет на главную страницу.

Я могла бы попробовать встроенный поиск на сайте United Club, но это значило, что мне придется пролистывать, уменьшать и увеличивать десятки ссылок, отформатированных для «полноценного» сайта. Ну и, если честно: почему, собственно, я должна этим заниматься? Поиск нужной информации предполагал всего один переход с Google, и я вовсе не собиралась блуждать по дебрям мобильного и обычного сайтов клуба.

Я подошла к стойке и все выяснила у представителя клуба. (Правильный ответ: двух гостей.)

Я привела этот пример вовсе не для того, чтобы пристыдить United за то, что они перебрасывают пользователя на мобильный сайт, где нет нужного контента. (Безобразие, но, желая пристыдить United Airlines, я бы поставила его в конце длинного списка всех их недочетов.) Нет. Этот пример иллюстрирует совсем другое – распространенное заблуждение, что мобильным пользователям нужна только функциональность, а не информационное наполнение.

Люк Вроблевски в книге «Сначала мобильные!»[8]8
  Л. Вроблевски. «Сначала мобильные!» М.: Манн, Иванов и Фербер, 2012.


[Закрыть] говорит, что в iPhone-приложении авиакомпании Southwest Airlines сделан правильный акцент на задачах, важных для путешественника (рис. 1.9):

«Мобильный опыт… подобно лазерному лучу, фокусируется на том, что нужно потребителю и что делает Southwest: заказ билетов, регистрация, проверка статуса рейса, проверка расстояния, предупреждения. Больше ни для чего места не нашлось. Только это имеет значение».

^{Рис. 1.9. В приложении Southwest Airlines для iPhone нашлось место только для самых актуальных вопросов. Правда, в их число не входит поиск информации}

Определять, что «действительно важно», должны не эксперты по мобильным устройствам и создатели приложений. Важно то, что важно для пользователя.

86 % владельцев смартфонов в течение предыдущего месяца использовали свои телефоны для поиска информации – чтобы решить проблему, найти аргумент в споре, узнать, как обстоят дела с пробками, посмотреть текущие результаты спортивных соревнований или прикинуть, стоит ли идти в ресторан (http://bkaprt.com/csm/27). Не верите?

Загляните в историю поисковых запросов на своем смартфоне – вы и сами наверняка интересовались подобной информацией.

На обычном сайте Southwest Airlines можно найти сведения о процедуре обработки багажа. В том числе о действиях с проверенными сумками, о ручной клади, о домашних животных, о работе бюро находок и мерах в случае пропажи предметов, о задержках багажа и много другой нужной путешественнику информации (что делать в случае потери билета, как перебронировать рейс и как поступить, если мест нет).

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

В мобильном приложении ничего этого нет. Кто мы такие, чтобы утверждать, что все это не имеет значения?

Совсем не плохо, если мобильное приложение оптимизировано для решения самых распространенных задач. Но это не повод исключать иную важную информацию.

Вы когда-нибудь переходили по ссылкам из фейсбука или твиттера в вашем телефоне? А как насчет ссылок в полученных электронных письмах?

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

По данным на июнь 2012 года, почти 20 % пользователей фейсбука исключительно «мобильные» (http://bkaprt.com/csm/28).

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

Однако когда ваши читатели вместо интересного контента видят лишь сообщения об ошибках, ваши усилия потрачены впустую (рис. 1.10).

^{Рис. 1.10. «Мобильный контент не найден. Желаете посетить полную версию сайта?» – спрашивает The Guardian. Ответ сами угадаете?}

«Контекст» – это такое назойливое слово, которое сейчас повторяют все, когда говорят о мобильных. В 2011 году на конференции South by Southwest Interactive было представлено панельное исследование «Проектирование для контекста», по мнению журналистов сетевого издания. net.magazine, обязательное для ознакомления в первую очередь (http://bkaprt.com/csm/29).

Мечта – вплести контент в среду (контекст) пользователя, учитывать его местоположение, время дня, социальное окружение, персональные предпочтения. Исходя из того, что вы знаете о пользователе, вы динамически настраиваете контент, чтобы он отвечал потребностям человека.

Сегодня мы используем фразу «специально для мобильного контекста» как оправдание недостаточно изученной практики использования мобильных устройств. Все хотят инвестировать в мобильные услуги как можно меньше времени и усилий, пока не увидят, какова отдача. При этом каждый утверждает, что его разработка предназначена «для использования в мобильном варианте».

Суждение «дизайнерам лучше знать», когда речь идет о доставке персонализированного контента или функциональности, весьма рискованно. Нам плохо удается предугадывать пожелания пользователей. Даже располагая точными данными, мы некорректно подходим к выбору, какие вещи показать и какие скрыть.

В конце 1990‑х эту стратегию применили при разработке Microsoft Office. В Office 97 появилось много нововведений и усовершенствований, сделавших интерфейс очень сложным. Длинные меню и плотно скомпонованные панели инструментов создавали впечатление, что интерфейс «раздулся» (http://bkaprt.com/csm/30). Похоже на некоторые сайты, не правда ли?

Под влиянием этого в Microsoft разработали «сокращенные меню», где наиболее популярные пункты показывались первыми (рис. 1.11). И, хотя у Microsoft была хорошая база данных и мощный алгоритм для определения самых популярных пунктов, оказалось, что пользователям не нравится, когда думают за них. Выяснилось, что людей раздражает двухступенчатый процесс обращения к меню для поиска нужного пункта. Сокращенные меню нарушили один из главных принципов юзабилити: пользователь должен всем управлять сам.

^{Рис 1.11. В сокращенных меню Office 97 приоритет имели опции, наиболее, по мнению Microsoft, востребованные пользователями. Разработчики потерпели неудачу}

Теперь представьте, что вместо клика по значку «Еще…» для разворачивания меню пользователь вынужден следовать по ссылке, ведущей на «полный» сайт, и затем искать там нужный элемент навигации с помощью крошечного экрана. Если на вашем мобильном сайте представлен не весь контент, вы предлагаете пользователю такой же разочаровывающий опыт. Даже хуже.

За годы разработки множества версий своего офисного пакета Microsoft накопила тонны информации о пунктах меню, чаще других выбираемых пользователями. Программисты придумали комплексный алгоритм для «сокращенного» меню, основанный на анализе этих данных. И все закончилось неудачей.

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

Даже если у вас есть аналитическая информация, какого рода контент чаще всего ищут обладатели мобильных устройств, это вовсе не означает, что вам известна точная картина их предпочтений. Сегодняшний, достаточно убогий опыт применения мобильных устройств – плохая основа для оценки реальных потребностей будущих пользователей. По словам одного из основателей CloudFour.com и MobilePortland.com Джейсона Григсби, «мы не можем предсказать будущее поведение исходя из текущего никудышного опыта» (http://bkaprt.com/csm/31).

Мобильные сайты, спроектированные с учетом контекста пользователя, совершенно не обязательно «урезать». В будущем мы научимся по-разному расставлять приоритеты – ориентируясь на пожелания пользователя, на факты его окружения или в ответ на явный запрос.

Но пока до этого далеко. Еще предстоит накопить много данных об использовании мобильных устройств. Исследования контекста, изучение юзабилити, аналитика и привлечение пользователей к процессу – вот инструменты, необходимые для выработки подходов к контекстному проектированию.

Но эти исследования будут бессмысленны, если не основываться на полноте контента. Чтобы иметь объективные и точные данные о том, как люди взаимодействуют с мобильными устройствами, мы сначала должны обеспечить им доступ ко всему объему информации. Только тогда мы получим реальные факты и понимание: что нужно людям, когда это нужно, как это должно быть представлено в соответствии с их желаниями. До тех пор мы будем лишь строить догадки.

Это все? Правда?

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

• Пользователи постоянно меняют устройства, часто выходя в интернет с мобильного даже тогда, когда рядом есть настольный компьютер. Не надо отталкиваться от посылки, что посетитель обязательно заходит на ваш сайт «на бегу»: люди применяют мобильные устройства где угодно и когда угодно.

• «Только-мобильным» пользователям тоже нужен весь ваш контент! Не воспринимайте их как людей второго сорта лишь из-за того, что они редко садятся за настольный компьютер или вообще не имеют с ним дела. И даже если вы расцениваете их как «в-основном-мобильных», помните: не вам решать, с какого устройства заходить на ваш сайт. Решают они.

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

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

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

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

2. Сначала контент, потом платформа

Любые разговоры о мобильных сайтах и приложениях сводятся к четырем ключевым темам.

• Что лучше делать – мобильный сайт или мобильное приложение?

• Нужны ли отдельные приложения для iOS и Android? И как насчет других платформ, например Windows?

• Следует ли разрабатывать адаптивный дизайн для сайта, чтобы он сам подстраивался под клиентские устройства (настольный компьютер, планшет, телефоны)?

• Следует ли делать отдельный мобильный сайт с собственным набором специально разработанных шаблонов?

С точки зрения дизайна и программирования ответ на все перечисленные вопросы один: «Это зависит от…» Есть хорошие аргументы в пользу любого варианта. Скорость, использование жестов, безупречный вид, доступность, удобство поиска и распространения – все это нужно принимать во внимание. Найдется немало ученых мужей, готовых спорить с вами до поздней ночи о том, какой подход лучше.

Но нет смысла обсуждать достоинства контейнера, если вам нечего в него положить. Или если у вас нет воронки.

Настоящая проблема для большинства компаний не в том, какой формат выбрать для мобильного контента, а в том, чтобы обеспечить этот самый контент.

Ответ на эти вопросы один – по крайней мере относительно контента – да. Скорее всего, вам понадобится и мобильный сайт (с адаптивным дизайном или нет), и мобильные приложения для iPhone, iPad, телефонов и планшетов под управлением Android, Windows и BlackBerry.

Как раньше происходило с сайтами, наше внимание сосредоточено на вопросах дизайна и программирования, и лишь потом мы задумываемся о контенте.

Нас так захватил ажиотаж вокруг жестов и геолокации, HTML5 и адаптивного дизайна, что мы совершенно упустили из виду собственно главный вызов мобильной революции.

Это – контент-стратегия, подход к созданию, управлению и обновлению контента для всех платформ и устройств.

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

Отдельный мобильный сайт

Не так давно пионер юзабилити Якоб Нильсен[9]9
  Якоб Нильсен – основатель и руководитель компании Nielsen Norman Group, автор более трех десятков изобретений, в основном направленных на облегчение работы пользователей интернета. Перу Нильсена принадлежат девять книг по пользовательским интерфейсам, веб-дизайну, структуре сайтов и прочим аспектам юзабилити.


[Закрыть] высказал мнение, что следует «создавать отдельные оптимизированные для мобильных устройств сайты (мобильные сайты), если вы только можете себе это позволить». Эти сайты должны иметь урезанную функциональность, а также контент, из которого будет убрано все «не нужное для использования в мобильном варианте» (http://bkaprt.com/csm/32).

Дизайнеры и программисты, работающие в этой сфере, тут же стали активно возражать, доказывая, что создание отдельного мобильного сайта – плохая идея (http://bkaprt.com/csm/33). По словам Джоша Кларка, автора книги Tapworthy: Designing Great iPhone Apps, предполагая, что отдельный мобильный сайт – приемлемая стратегия, мы увековечиваем несколько упрямых мифов, ведущих к созданию «легких мобильных приложений, свысока относящихся к пользователям, подрывающих бизнес-цели и поглощающих творческие и технические ресурсы» (http:// bkaprt.com/csm/34).

Ноз Урбина, старший консультант и директор по развитию бизнеса компании Mekon, сказал мне, что идея разделения мобильного и «обычного» сайтов основывается на ложных ожиданиях по поводу того, как будет осуществляться управление контентом и сопровождение сайта.

Решение создавать отдельный мобильный сайт основывается на двух ошибочных предположениях: что для всех мобильных платформ достаточно одного сайта и что в принципе возможно поддерживать отдельные сайты для каждой платформы. Ваш контент – эволюционирующий организм, все элементы которого нуждаются в постоянном обновлении, и одни и те же пользователи будут получать к нему доступ с разных устройств. Сайты наподобие Facebook, eBay, Amazon, Evernote и мириады других заставили рынок ожидать, что, независимо от режима взаимодействия и способа доступа, контент всегда последователен, релевантен и актуален.

Создавая отдельный мобильный сайт, вы в перспективе можете отказаться от дублирования контента сразу в нескольких версиях сайта. И это будет катастрофой. Раздельные процессы. Несинхронизированные обновления. Растраченные усилия.

Отдельный мобильный сайт опасен еще и потому, что, как правило, вы стремитесь избежать создания множественных версий своего сайта. Это называется ветвлением, и с точки зрения обслуживания это настоящий кошмар. Если вы разделили ваш сайт на мобильную и обычную версии, то при каждом обновлении вам придется вносить изменения дважды. Обойти проблему, даже с помощью сложных систем управления контентом, очень сложно. Но, прежде чем говорить об этом, давайте разберем простой сценарий.

Вообразите, что у вас статичный сайт, который вы создали в конце 1990‑х. Никакой системы управления контентом – весь контент зашит прямо в HTML. (Если вы думаете, что не осталось уже организаций, живущих в эпохе «темных веков», предлагаю вспомнить, что 57 % сайтов американских федеральных агентств не имеют CMS:

http://bkaprt.com/csm/35; PDF.)

Вы решаете идти в ногу со временем и создать мобильную версию сайта. Отлично! За исключением той неприятности, что, по существу, это будет совсем новый сайт и вам придется обновлять обе версии каждый раз, когда вы захотите внести какие-то изменения. Вы должны создать два совершенно различных набора страниц: уникальные шаблоны как для мобильного варианта, так и для настольного. И даже в том случае, вернее, особенно в том случае, когда вы собираетесь опубликовать абсолютно одинаковый контент на обоих сайтах, вам придется разметить и загрузить его дважды. Вдвое больше работы, вдвое больше удовольствия?

Прекрасно! Возможно, вы думаете, что создание отличающегося контента даст вам преимущество. Отдельный мобильный сайт может справляться со своими задачами и если на нем будет представлен не весь контент «большого» сайта. Удалить часть возможностей, сократить контент, по-иному расставить приоритеты – и получится мобильный сайт, где представлена лишь та часть контента, которая нужна «мобильным» пользователям.

Оставим в стороне вопрос о том, насколько подобный подход корректен с точки зрения пользователя (ответ «нет»).

Речь о другом. Вы все равно не избежите ветвления! Хотите добавить новую страницу? Отредактировать, исправить опечатку? Все равно вам придется делать это дважды.

Смысл системы управления контентом в том, чтобы упростить процесс публикации. Верно? И вы, конечно, думаете, что ваша нынешняя CMS легко справится с публикацией контента в разных каналах и для разных платформ.

Такое же мнение высказал Якоб Нильсен, когда его спросили об опасности ветвления контента (http://bkaprt.com/csm/36):

«Полагаю, что большинство сайтов промышленного масштаба имеют в своей основе базу данных и систему управления контентом, которая обеспечивает различное представление информации в соответствии с шаблонами и наборами правил для каждой версии».

К несчастью, на сегодняшний день большинство CMS неспособны обеспечить многоканальные публикации без значительных инвестиций в дополнительное программирование. Запросите у своей CMS вывод похожего, но не одинакового контента в разных шаблонах в соответствии с бизнес-логикой – она задымится и сойдет с ума. Возможность многоканальных публикаций не предусмотрена не только в дешевых, но и в среднеценовых CMS. Лишь мощные промышленные системы управления контентом, способные обеспечить публикацию на бумаге и в сети, справятся с подобной задачей.

Многие CMS созданы для работы с одной, и только одной платформой: настольными компьютерами. В CMS функции создания и управления контентом «спарены» с функциями публикации и отображения. (Если у вас мощная промышленная CMS, то к вам, скорее всего, этот пункт не относится; там эти функции разведены.)

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

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