Для этого вы можете выполнить следующие шаги:
1. Убедитесь, что ваш контент доступен для всех, сделайте правильную семантическую разметку. Главное – отделить контент от представления.
2. Прогрессивно улучшайте контент, чтобы люди, которые просматривают его с экранов разных размеров, получили больше оптимизированного опыта (в настоящее время на этом сосредоточен отзывчивый/адаптивный дизайн).
3. Прогрессивно улучшайте контент, чтобы семейства устройств, основанные на поддерживаемых функциях и возможностях (например, тач), получили больше оптимизированного опыта. Проще говоря, сделайте сайт чувствительным в поведении, а не только в разметке. Здесь вы оптимизируете для особенностей, а не для специфических устройств (так сказать, для всех мобильных телефонов, которые поддерживают тач, а не только для одного iPhone).
4. Прогрессивно улучшайте контент для поддержки уникальной культуры и возможностей различных устройств, которые вы хотите поддерживать. Здесь оптимизация для специфических устройств вполне нормальна. Нет ничего плохого в том, что вы пытаетесь сделать опыт взаимодействия прекрасным, насколько это возможно, даже если он создается для специфических телефонов.
Конечно, каждый из этих шагов занимает и время, и много ресурсов. И в соответствии с этим, вам нужно планировать и составлять бюджет. А что если ваша задумка сделать действующий сайт адаптивным не удовлетворяет нужды пользователей в определенных случаях? Возможно, вам нужно предоставить больше оптимизированного и специального опыта, чем допускает прогрессивное улучшение, с учетом бюджета и сроков. Или может быть вам нужен такой уровень интеграции устройства, который просто не совместим с действующим браузером? В этом случае вам в голову могут прийти мысли о том, создавать ли приложение, и если да, то будет ли оно поддерживать множественные платформы, и какие технологии нужно будет использовать.
Кроссплатформенность или единственная платформа?
Как лучше удовлетворить потребности пользователя: запуская приложение на многих платформах или на единственной, по крайней мере сначала? Когда будете отвечать на этот вопрос, не забудьте, что создание одной платформы не означает, что вы позже не сможете создать отдельное приложение для другой платформы.
Это значит лишь то, что в начале работы над проектом в центре ваших дизайнерских изысканий будет единственная платформа (или даже единственное устройство).
Само по себе не имеет значения, будет ли работать ваше «родное» приложение или оно будет использовать «родные» компоненты устройства или устройств, на которых запускается. (Использование кроссплатформенных авторских технологий для создания приложения, которое вы оптимизировали для единственной платформы, легко осуществимо.)
Ответ на этот вопрос в любом случае определит, какую оптимизацию вы должны сделать на различных платформах. Если вы заботитесь об опыте взаимодействия, то должны оптимизировать ваше приложение на каждой платформе, которую поддерживаете. Ваше решение также повлияет на то, сколько тестирований вы должны сделать (потому что вам нужно будет тестировать каждую платформу, которую поддерживаете), на размер отдела техподдержки (потому что вам нужно будет разбираться с проблемами пользователей под каждую платформу) и на то, сколько времени и бюджета вам понадобится, чтобы все утрясти для этих различных функций.
Миф: Один раз написанный код работает везде
Типичная ошибка, которую допускают дизайнеры, – это предположение, что при использовании кроссплатформенных авторских технологий они могут написать код один раз, а работать он будет везде. Это миф. И он может привести к достаточно дорогим последствиям.
Ваше приложение должно запускаться на множестве платформ, но это в редких случаях означает, что оно будет хорошо запускаться на множестве платформ
Единственный способ заставить приложение хорошо работать на различных платформах – это оптимизировать его для каждой платформы и устройства. Как мы говорили раньше, каждая платформа имеет свою культуру, язык и нормы, которым, как ожидает пользователь, соответствуют приложения. И многих пользователей не интересует, на скольких устройствах работает ваше приложение. Их заботит только то, насколько хорошо ваше приложение будет работать на их устройстве.
Дизайнеры, которые не учитывают уникальную культуру, традиции, язык и нормы платформ, рискуют сделать свои приложения выглядящими неуместно. Приложение будет чужеродным, часто даже вызывающим, просто потому что оно не учитывает культуру платформы.
Так как мы не хотим, чтобы наши приложения демонстрировали такое отвратительное поведение, мы должны оптимизировать их под каждую платформу, которую поддерживаем. Наша цель – создать приложения, культурно восприимчивые к языку, нормам и традициям платформ, на которых они запускаются. Отступить от нее – значит, проявить неуважение к определенному сегменту пользователей.
Смерть от тысячи ранений
Худшее, что вы можете сделать, это, конечно, проявить неуважение к вашим пользователям, создав приложение с наименьшими сходными характеристиками, которое предоставляет им неоптимизированный опыт взаимодействия на каждой платформе. Здесь вы уязвимы больше всего. Даже если ваше кроссплатформенное приложение потенциально может иметь большое количество пользователей, потому что запускается на многих устройствах и платформах, на каждой из них оно будет неудобно в использовании. Проще говоря, кого волнует, на какой платформе работает приложение, если оно работает ужасно?
Еще важнее, что будет, когда на одной из этих платформ появится конкурент со своим великолепным, восхитительным, детально оптимизированным опытом взаимодействия и «вышибет» ваше приложение? А на другой платформе то же самое с вами сделает другой конкурент.
Это равносильно смерти от тысячи ранений. Поддержка множественных платформ не станет функционировать до тех пор, пока вы не сможете хорошо поддерживать все из них. У вас может быть преимущество первого игрока на рынке, но только до той поры, пока вас не превзойдет лучший конкурент.
Напиши один раз, оптимизируй везде
Что ж, написанное один раз работает везде – опасный миф. Кроссплатформенные приложения, которые удачно конкурируют, пишутся один раз, оптимизируются везде. Вы должны понимать, что это означает для вашего бюджета, сроков и плана оптимизации, тестирования и поддержки приложения на каждой платформе, которую вы выбрали.
Пожалуйста, не берите демонстрационные версии различных производителей, обещающие создание кроссплатформенного приложения за пять минут. Это все будет ерундой, пока вы не составите простейший план действий с приложением. Правильное тестирование технологии заключается не в том, чтобы легко создать пятиминутную демоверсию или быстро пройти 7 % пути к свой цели, а в том, насколько легко вам будет «удержать» последние 3 % вашей разработки, включая все важные оптимизации для опыта взаимодействия, что может забрать последний 1 %. На эти детали в разработке приложения у вас может уйти масса времени и усилий.
Рисунок 9.14. Бинарно-каркасная матрица
Сетевые и другие кроссплатформенные технологии
Вообще говоря, кроссплатформенные технологии можно разбить на две группы: те, которые создают «родной» бинарный файл и которые не делают этого. Мы можем дальше классифицировать их на те, которые используют «родные» фреймворки. Эта комбинация дает нам бинарно-каркасную матрицу, представленную ниже:
«Родной» бинарный файл – это пакет приложений, которые могут запускаться напрямую операционной системой данного устройства. Мы, как правило, говорим об этом, когда ссылаемся на «родное» приложение.
Однако гораздо важнее проверить, использует ли приложение «родные» фреймворки. Эти фреймворки воплощают в себе культуру, язык, жесты, символы и нормы платформы.
Чужие приложения в обертке от «родных» бинарных файлов, или Волки в овечьих шкурах
С помощью технологии типа Adobe PhoneGap вы можете (и вполне легко) создать для iPhone «родной» бинарный файл, не использующий «родные» компоненты в фреймворке Cocoa Touch для iOS. PhoneGap «оборачивает» существующее веб-приложение, и создает из него «родное» приложение операционной системы (в примере выше «родное» приложение системы iOS). Ваше приложение становится похожим на «родное» для iPhone и запускается как «родное» приложение, но пользовательский интерфейс приложения при этом воспроизводится с использованием веб-компонентов[115].
Ваше бинарное приложение это всего лишь оболочка, которая состоит из WebKit компонента. Этот WebKit-компонент визуализирует ваше веб-приложение с помощью веб-компонентов. Из-за того что веб-компоненты не могут соответствовать «родным» ожиданиям, я бы не советовал использовать PhoneGap при создании приложений для повышения продуктивности[116], таких как календарь, различные списки дел и т. п.