Возможно, вы знаете, что дизайн опыта взаимодействия – это дисциплина, включающая все аспекты разработки интерактивных продуктов. Хотя она объединяет важные элементы графического и видеодизайна, в основном касается интерактивного дизайна. В сфере дизайна ближайшим родственником ему является промышленный дизайн, т. е. дизайн предметов и продуктов.
Как дизайнеры опыта взаимодействия, мы создаем виртуальные продукты. Более того, так как дизайн оборудования и дизайн программного обеспечения по существу связаны и нераздельны, грань, которая разграничивает дизайн продукта и интерактивный дизайн (если она вообще существует), – расплывчатая.
Веб-разработчик – это разработчик опыта пользовательского взаимодействия
По существу, веб-разработчик – это разработчик, создающий опыт взаимодействия, владеющий специальными знаниями о средствах Интернета. В качестве материалов веб-разработчик использует основные (HTML, CSS, JavaScript) и вспомогательные (LESS, Stylus и т. п.; HAML, Jade и т. п.; jQuery, MooTools и т. п.) фреймворки Сети и их компоненты. Эти фреймворки и компоненты внутри них созданы из кода. Того самого, который определяет границы дизайна и поведение этих материалов.
Так же как конструктор автомобилей глубоко разбирается в различных материалах, из которых делают машину, веб-разработчик должен понимать суть материалов, которыми он создает сайт.
Мы интерактивные разработчики и нас интересует не просто эстетика интерактивного объекта, но и его поведение.
Особенно это важно, когда вы разрабатываете приложения (которые являются объектами, на основе поведения) в противовес разработке документов (которые являются объектами, на основе содержания).
Дизайн документов против дизайна приложений
Разработка интерактивного документа для Сети – особенно адаптивным способом, – требует специальных знаний. Как минимум нужно понимать принципы адаптивного дизайна и прогрессивного улучшения. Рисование милых картинок – это искусство, а не разработка.
Интерактивные продукты или приложения – совершенно другое дело. Разработка для интерактивной среды требует знаний графического и динамического дизайна, и, что самое главное, интерактивного дизайна. Важнейшим аспектом интерактивного продукта являются его взаимодействия. Они заложены в код.
Процесс дизайна приложения не ограничивается лишь рисованием красивой картинки, как проектирование автомобиля не ограничивается рисунком машины
К сожалению, из-за увеличения числа различных специализаций в команде, роли веб-дизайнера и веб-разработчика искусственно разделились. Хотя такое разделение может быть необходимым при работе в команде, тем не менее названия специализаций определяют скорее текущие задачи для членов команды, но не копилку их знаний. Вы можете сосредоточиться на определенных областях больше, особенно в специфичных проектах. Но вы должны понимать, что первоначальная причина, по которой мы создаем продукт – удовлетворить потребности пользователей, и каждый в команде разработчиков играет важную роль и влияет на опыт пользователя. Вот почему обязательно нужно работать в маленьких междисциплинарных группах, где каждый член думает в первую очередь о пользователе.
Разработка в первую очередь для пользователей
При создании продукта дизайн руководит разработкой, а разработка одушевляет дизайн. Это цикличный, повторяющийся процесс, цель которого постоянное улучшение продукта для лучшего удовлетворения нужд пользователя.
В основе каждого решения, которое вы принимаете по своему продукту, должны быть потребности пользователи. В первую очередь вы должны думать об этом, и только потом о себе. Другими словами, практикуйте то, что мы называем «outside-in design» («дизайн “снаружи внутрь”»). Думайте о нуждах пользователя и их контексте, создавайте то, что он увидит и с чем соприкоснется, а уж потом переходите к решению проблем, которые предстанут перед вами.
Цель главы
Два основных решения, над которыми вы должны «поломать» голову во время процесса разработки, – делать ли продукт кроссплатфор-менным или «родным».
Cнаружи – это хорошо. Изнутри – это плохо
Ваш первый вопрос в новом проекте: «Какую использовать серверную технологию, или как должна выглядеть схема базы данных?» Стоп! Неверный подход! Вы пытаетесь решить не проблемы пользователя, а свои собственные. Получается дизайн «изнутри наружу». А это – Очень Плохая Штука!™
Цель этого раздела помочь вам как разработчику пользовательского опыта понять вашу среду так, чтобы вы были подкованы, отвечая на эти вопросы. Начнем с того, что посмотрим, что же именно представляет собой «родное» приложение.
Что значит «родной»?
Вы замечали, как люди волей-неволей бросаются термином «родной», не до конца понимая, что это на самом деле значит? Давайте исправим ситуацию. Начнем с того, что выясним, чем «родной» не является.
Все дело в нулях и единицах
Если уж быть педантичными, то «родной» – насколько это касается цифровых устройств – относится к наличию или отсутствию электрического тока в транзисторах наших компьютеров. Мы, как правило, визуализируем это как базовое клише цифрового вычисления: бинарный код, серия «бегущих нулей и единиц». Мы называем эти бинарные инструкции машинным языком.
Рисунок 9.1. Да, существует большое количество устройств. Но! Наше приложение не должно поддерживать их всех. Сосредоточение на пользователе означает определение вашей целевой аудитории и оптимизацию ваших приложений под платформы и устройства, которыми они пользуются. Поддержка огромного количества платформ через прогрессивное улучшение проще, если вы первоначально создаете сайты с учетом содержания в противовес приложениям с учетом поведения.
Фото: Дэвид Джонс /
Когда-то компьютеры запрограммировали бинарно с использованием переключателей, но мы больше не пишем программы на таком низком аппаратном уровне. Однако каждый второй компьютерный язык программирования, который мы создавали, – язык ассемблера, Си, Питон, JavaScript и т. д. – в конечном итоге переводится на язык «бегущих нулей и единиц». А они уже обеспечивают наличие или отсутствие электрического тока в транзисторах.
Каждая из этих технологий основана на абстракциях. Например, Питон написан на Си. Цель каждого абстрактного слоя – каждого более высокого слоя в слоеном торте технологий, которые составляют современную компьютерную экосистему – упростить разработчикам создание приложений. Так что употребление термина «родной» в смысле бинарного программирования сегодня поблекло.
Итак, теперь, когда мы знаем, что такое «неродной», давайте выясним обратное.
Рисунок 9.2. Веб-технологии могут быть «родными» для определенных операционных систем. Здесь вы видите лэптоп Samsung с системой Chrome OS, чьи первостатейные граждане – HTML, CSS и JavaScript и веб-приложения. Фото: промо-изображение Google
Родной как культура
Термин «родной» относится к технологиям, т. е. языкам и объектным структурам – всему тому, что формирует культуру, язык, условные обозначения и нормы платформы. Это базовый уровень абстракции. Он включает в себя базовые символы, жесты и взаимосвязи, применяемые пользователем для взаимодействия с приложениями на установленной платформе. Эти элементы крайне важны, потому что они составляют культуру и нормы платформы. Это языки, как визуальные, так и поведенческие, которые пользователь изучает для взаимодействия при пользовании платформой. И наоборот, это также слова, фразы и концепты, которые приложения на установленной платформе применяют для взаимодействия с пользователями. Чем больше они используются и постоянны на установленной платформе, тем больше плюсов для создания приложений для нее.
Рисунок 9.3. «Руководство по интерфейсу» от Apple дает ясные инструкции, как должно выглядеть и вести себя приложение на платформе iOS. Это поможет определить культуру платформы
В конце спектра мы имеем платформу iOS от Apple с ее подробным «Руководством по интерфейсу» и элегантным и единообразным фреймворком Cocoa Touch. «Родное» приложение от производителя, которое соответствует руководству, унаследует много от практичности базовых фреймворков и сразу же покажется знакомым пользователю, уже знающему другие приложения этой платформы.
На другой чаше весов мы имеем такие платформы, как Android. Они основательно переработаны производителями устройств, сотовыми операторами и пользователям из-за того, что существует маленькая совместимость (если она вообще есть) между различными телефонами Android и приложениями. Разработчикам «родных» приложений для таких платформ придется затратить больше усилий, чтобы обеспечить постоянный пользовательский опыт взаимодействия.
Рисунок 9.4. Swype-клавиатура на самом деле восхитительна. Просто скользите пальцем от буквы к букве, а она автоматически будет угадывать слово, которое вам нужно. К сожалению, такая система есть не во всех устройствах Android, а лишь в некоторых. У других клавиатура похожа на клавиатуру iPhone, и пользователи могут купить и использовать кучу других сторонних клавиатур. Огромный выбор поначалу может показаться плюсом, однако это значит, что нет единого пользовательского опыта системой Android. Фактически есть столько опыта пользования платформами Android, сколько существует различных версий Android, которые адаптируются производителями, сотовыми операторами и самими пользователями. Поэтому так трудно использовать общий язык дизайна, когда создаете приложения
Например, мое iPhone-приложение Feathers имеет собственную клавиатуру, которую я сделал, чтобы вводить расширенные уникод символы. На iPhone она работает в точности, как встроенная программная клавиатураiPhone. Чтобы добиться этого, пришлось попотеть, но невозможное возможно. Если бы я переносил приложение на Android, мне пришлось бы вычислять, какую именно из кучи программных платформ установил пользователь, а потом адаптировать ее поведение для совместимости. Не факт, что это было бы вообще реально сделать, не говоря уже о том, что точно потребовалось бы больше усилий. Клавиатура Swype на телефонах Android, например, патентована. Поэтому на устройстве Android со Swype-клавиатурой я не смогу заставить свою вести себя точь-в-точь как системная.
Рисунок 9.5. Портирование Feathers на Android потребует создания различных версий пользовательской раскладки клавиатуры под различные типы клавиатур
Компромиссное решение – создать единую пользовательскую клавиатуру и использовать ее независимо от системной клавиатуры пользователя. Конечно, она не будет ни смотреться, ни ощущаться как основная клавиатура и поэтому не будет обеспечивать такое же удобство работы, как и в Feathers на iOS. Вместо этого пользователям приложения придется учиться управлять двумя разными видами клавиатур в приложении и напрягаться при переключении с одной на другую.
Рисунок 9.6. Веб-приложение Gmail обеспечивает постоянный опыт взаимодействия на всех платформах. Пользователям не нужно ничего устанавливать или беспокоиться о синхронизации своей почты на разных устройствах
Аналогично на платформах, в которых нет сильного и постоянного визуального языка и культуры, «неродные» приложения будут иметь меньше недостатков и даже смогут, как это ни парадоксально, обеспечивать больше удобства при использовании в некоторых ситуациях.
Великолепный пример «неродного» приложения, которое обеспечивает лучший опыт взаимодействия на определенных «родных» платформах, – это Gmail. Использование почтового клиента компьютера в операционной системе, такой как Windows, может потребовать от вас установки самого приложения, его обновления, хранения вашей почты, синхронизации в различных устройствах. Нужно будет проверять, нет ли в сообщениях вирусов и другого вредоносного ПО. Оцените простоту Gmail, когда вводите URL-адрес в браузер любого устройства – раз! – вот и ваша почта. Все! Все отлично!
Gmail также прекрасный пример того, как создание хорошего кросс-платформенного опыта взаимодействия может требовать много оптимизаций, характерных для разных платформ. Хотя приложение Gmail работает на настольных и мобильных платформах, фактически у него есть несколько высоко оптимизированных версий.
Рисунок 9.7. Браузер – «родное» приложение операционной системы (ОС), работающий в ее контексте. Веб-приложение работает в контексте браузера. Веб-приложение так или иначе не является «родным» приложением ОС. Между ним и операционной системой одна степень разделения (браузер). Аналогично Flash-приложение работает в виртуальной машине, «сидит» поверх браузера и не является «родным» по отношению к нему.
Изображение: Розмари Воегтли /
Однако Интернет как платформа имеет мало фиксированных пользовательских опытов. Хотя веб-приложения пользуются общими свойствами, «Руководства по интерфейсу» для Сети нет (но наверно, должно бы быть). Вместо этого, мы концентрируем свое внимание на документировании и продвижении хорошего кода и дизайн-практик, таких как прогрессивное улучшение. Различные браузеры по-разному реализуют управление основными элементами форм. Вот почему поведение веб-приложения отличается в различных браузерах, даже если у него такие же компоненты, разметка и код.
Гибридные приложения
Итак, у нас есть «родные» приложения, которые относятся к культуре платформы, на которой они работают. И у нас есть веб-приложения, которые работают в браузере. Но мы забыли о третьей категории, под которую подпадают многие современные приложения: гибридные приложения.
Рисунок 9.8. Гибридное приложение Facebook на iPhone
Мы должны понимать всю силу различных технологий и использовать их где возможно. Официально провозглашенные авторские технологии (главным образом HTML и CSS) прекрасно подходят для создания сложных документов, и придают им бесподобный стиль. Таким образом, многие дизайнеры «родных» приложений используют язык HTML и библиотеки CSS, когда им нужно отобразить разнообразный контент. Эти виды приложений носят название «гибридные приложения», потому что они являются смесью «родных» и сетевых технологий.
Приложение Facebook на iPhone является одним из примеров гибридного приложения, в котором определенные разделы (такие как новостные ленты) воспроизводятся с помощью веб-технологий.
Аналогично тому, что мы видели раньше, веб-приложения тоже могут быть гибридными. Сайт, написанный на HTML, CSS и JavaScript и использующий Flash для отображения богатого интерактивного контента, – пример гибридного приложения.
Многие приложения сегодня – гибриды. И если вы ас в HTML, CSS и JavaScript, могу сказать, вы не останетесь голодным независимо от того, какая платформа или платформы в конечном итоге станут популярными через годы.
Преодоление идеологических предрассудков
Гораздо чаще технологические и дизайнерские решения основываются не на желании выбрать лучшие средства и материал для работы, а на идеологии. К сожалению, почти повсеместно веб-стандарты поддерживают те, кто слепо предлагает платформы и «родные» авторские технологии для любого проекта, не учитывая нужды пользователей. Веб-специалисты – практики, которые без оглядки советуют Flash и «родные» iPhone– или iPad-приложения для любого проекта, тоже явление распространенное. На ум приходит старая поговорка «Против лома нет приема». Поэтому важно увидеть такие предрассудки и строить свои решения на нуждах ваших пользователей, а не на идеологии. Еще важно уметь распознавать идеологические взгляды так, чтобы направить дискуссию в область разработки.
Иные сторонники веб-стандартов убеждены, что платформа и авторские технологии по своей природе являются некой силой добра. Никто не спорит, что Интернет и Сеть как основы оказали на мир такое же (если не большее) демократическое воздействие, как печатный станок Гутенберга. Однако веб-платформа и авторские технологии по сути своей ни плохие и ни хорошие, и они могут легко использоваться в обоих случаях.
В случае веб-платформы принято считать, что она хорошая по своей природе, потому что к любому документу или приложению, расположенному на ней, повсюду есть доступ. Хотя это может быть верно для открытых коллекций документов (это было нормой для контента на заре веба), но не подходить для того, что мы сегодня называем современными приложениями. Возьмем, к примеру, Facebook. Facebook – это сетевое приложение. Оно – закрытое. Оно бесплатное. Но это значит, что вы, пользователь, не клиент Facebook. Вы – его продукт. Ваши личные данные и поведенческие характеристики – это то, что Facebook продает своим реальным клиентам, рекламодателям. Так может это лучше и более открыто, чем покупать коммерческое приложение в магазине приложений от Apple? На самом деле нет.
По сути, вы легко можете привести аргументы, что купить лицензию на коммерческое приложение iPhone более честная и открытая сделка. Вы платите за нее и таким образом владеете лицензией, чтобы пользоваться. Вы становитесь клиентом компании или личности, которая сделала приложение. Это прозрачность, с которой компания делает деньги. Во многих отношениях это больше традиционные коммерческие отношения.
Естественно, даже коммерческие приложения могут окольными путями использовать ваши данные, поэтому сегодня важно быть начеку. Но суть в том, что просто веб-приложение не сделать силой добра каким-то магическим образом.
«Родные» приложения и платформы – исчезающие виды?
Как отлично подметил Джереми Кейс на конференции по модернизации, «писать „родное“ приложение все равно что писать код под лазерный диск». Смысл здесь в том, что Сеть все время развивается, и «родные» платформы, как и компакт-диски (CD-ROM) и лазерные диски (LaserDisc) скоро устареют.
Я сильно надеюсь, что это не так, потому что Сеть сама по себе «родная» платформа и все больше становится таковой (в общепринятом смысле) с ростом операционных систем, таких как WebOS и Chromium, которые созданы на основе «родных» веб-технологий. Мы должны понимать, что Интернет развивается – это движущаяся цель. Новые свойства, расширение опыта взаимодействия и т. д. постоянно добавляется к «родным» платформам. Это не похоже на решение Apple с 1 сентября 2012 года прекратить создание новых операционных систем и моделей iPhone и iPad, потому что создана система iOS и может понадобиться несколько лет, чтобы Сеть догнала ее.
Мы знаем, что термин «родной» относится к базовой культуре и языку платформы, поэтому утверждать, что «родные» приложения исчезнут, значит, признавать, что различные устройства не будут иметь особую культуру в будущем.
Исходя из этого, можно предположить, что в будущем разовьется монокультура, где каждое приложение на каждом устройстве будет «говорить» через элементы системы и авторизовываться с использованием «родных» сетевых авторских технологий. Более того, эти приложения будут обслуживаться с помощью веб-платформы. Вообще, это ужасное и безрадостное видение будущего. Такого, где люди все меньше смогут управлять своими данными, а их устройства попросту превратятся в «немые» терминалы, подвешенные к огромным облачным хранилищам, подконтрольным большим корпорациям.
Например, вместо того чтобы владеть лицензией на приложение по обработке текста, вы могли бы написать все в Google Docs. Google, со своей стороны, анализировал бы каждое слово и предложение и старался понять больше о том, кто вы и что вам интересно, и использовал эту информацию для манипуляции вашим поведением в коммерческих целях.
Не сказать, что веб-приложения – это неизбежное зло, но по своей природе они точно нехорошие.
Размывание границ
Пока разработчики свято верят в то, что будущее Сети – исключительно в разнообразных авторских веб-технологиях, таких как HTML, CSS и JavaScript, которые обеспечат лучший доступ к таким свойствам устройств, как тач, GPS, поддержка акселерометра и камеры, я буду спорить. Очень редко говорят о том, как «родные» приложения догоняют веб-приложения.
В некоторых отношениях «родные» приложения делают серьезные успехи и уже почти не уступают в преимуществах, которыми долгое время могли похвастаться лишь веб-приложения.
Вот три основные области, в которых они догоняют веб-приложения, – это легкость в использовании и доступе, автоматическое обновление и прямой доступ к данным.
Рисунок 9.9. Граница между потоком использования «родных» веб-приложений или «родных» OS-приложений размытая. Фактически в операционных системах, основанных на веб-технологиях, «родные» веб-приложения – это «родные» OS-приложения
Легкость в использовании и легкий доступ
Одно из основных преимуществ опыта взаимодействия, которое Сеть имеет от «родных» приложений, это – легкость, с которой они могут использоваться и быть доступными. Нажмите клавишу Upload (Загрузить) в вашем FTP-клиенте по выбору, и разработанное приложение станет доступным каждому, у кого есть ссылка на него, в любом уголке мира. Все просто.
Не нужно скачивать Zip-файл, потом искать приложение, чтобы разархивировать его, потом искать, куда оно скачалось, потом распаковывать архив, устанавливать, запускать. И все это только для того, чтобы узнать, что оно не поддерживается вашей видеокартой. Ик! Вас не удивляет, что такие веб-приложения, как Gmail и Google Docs обрели феноменальный успех, особенно на «родных» платформах с низким уровнем удобства в работе?
Так или иначе «родные» приложения стремятся к легкости размещения и доступа, которые предлагают веб-приложения благодаря разработке хранилища приложений. С хранилищем приложений типа Apple процесс поиска так же прост, как клик по ссылке в браузере. По сути, вы можете кликнуть по URL, чтобы найти приложение в хранилище, там просто нажать клавишу, чтобы загрузить и установить его.
Автоматические обновления
По своей природе веб-приложения всегда находятся в обновленном состоянии. На самом деле мы совсем не думаем о «версии» веб-приложения, потому что Сеть, по сути, независима от версий.
Вы всегда пользуетесь последней версией Gmail, и вам все равно, что это за версия.
Это не Gmail версии 7; это просто Gmail.
Для сравнения, «родные» приложения имеют громоздкий механизм обновления, который прерывает процесс использования.
Это тоже меняется. Все больше и больше «родных» приложений выполняют непрерывное обновление. К примеру, когда вы в последний раз видели, как Google Chrome обновлялся? Да никогда. Он делает это тихо.
Непрерывный доступ к данным
Другое огромное преимущество, которым пользователи веб-приложений обычно наслаждаются, это непрерывный доступ к своим данным с любого устройства. Вам никогда не нужно волноваться о синхронизации e-mail с вашего компьютера на мобильный телефон, когда вы пользуетесь сервисом Gmail. Это всегда в нем. Сравните это с ночным кошмаром, который обычно «обрушивается» на синхронизацию на «родных» платформах.
Однако, как ни крути, «родные» приложения снова наверстывают упущенное. Например, с сервисом iCloud от Apple, синхронизация вручную становится вчерашним днем. Ваши данные легко и просто доступны автоматически на ваших устройствах Apple и постоянно находятся в процессе синхронизации, и у вас не должна болеть об этом голова. Хотя сервис iCloud по большому счету клиентское решение Apple, кроссплатформенные технологии типа Dropbox дают похожие преимущества другим платформам.
Просто еще один клиент
Вы внимательно прочли предыдущий раздел? Отлично. Тогда вы могли заметить как красной нитью во всех трех областях проходит то, что «родные» приложения должны «наверстывать» веб-приложения. Это все области, где плюсы опыта взаимодействия – это заслуга Интернета, а не Сети. Сеть – это просто стек технологий, а именно HTTP и адресов URL на вершине Интернет-стека. Поэтому «родные» приложения «наверстывают» Сеть с помощью тех же характеристик Интернета, что и она сама.
Кроме того, мы наблюдаем рост новых моделей опыта взаимодействия, которые называются непрерывный клиент. Непрерывный клиентский опыт, изначально предлагаемый Джошуа Топольски, позволяет пользователю непрерывное взаимодействие с устройствами и контекстами. Например, когда вы читаете Twitter на своем компьютере, а затем хватаете свой телефон, вам нужно, чтобы вы могли продолжить чтение ленты с того места, на котором остановились. А когда вы приходите домой, вам надо продолжить с того же места на телевизоре.
Рисунок 9.10. Келли Соммерс представляет хороший пример приложения, которое демонстрирует опыт непрерывного использования: . Пользователи могут начать просмотр видео на своих Windows Phone 7, продолжить в веб-клиенте, а затем перейти на свои iPhone
Рисунок 9.11. Приложение по передаче непрерывных сообщений сервисаTrillian – хороший пример непрерывного клиента.
Фото: Trillian Blog,
Хорошим примером непрерывного клиента служит приложение мгновенного обмена сообщений программы-мессенджера Trillian. Оно может сохранять сообщения в облаке, распределять разговоры между всеми вашими устройствами в реальном времени, отслеживать и синхронизировать ваши прочитанные и непрочитанные сообщения и даже воспользоваться «присутствующей технологией», чтобы узнать, на каком устройстве вы в данный момент активированы. И это для того, чтобы посылать текущие сообщения только туда.
Как вы понимаете, в эпоху использования приложений типа «непрерывный клиент» Сеть и сама становится просто еще одним клиентом. В определенных контекстах он может быть лучшим для использования, но у пользователей все-таки есть выбор – переключиться на «родных» клиентов, не беспокоясь о синхронизации данных. Скоро пользователи в основном будут ожидать приложений типа «непрерывный клиент», а не инноваций, тем более что технологии высокого уровня, например iCloud, упрощают задачу разработчиков при их внедрении.
Будущее за родным
Сегодня Сеть – это просто еще одна «родная» платформа, которая набирает обороты и должна конкурировать по своим уникальным достоинствам, а не по тем, которым ее одаривает Интернет, ведь другие платформы тоже реализуют такие же возможности. Вопрос на засыпку! Что вы запланируете при выборе веб-платформы для вашего следующего приложения как его достоинство: интерфейс пользователя «родного» приложения или показ через URL и обслуживание его через HTTP?
Веб-приложения «догоняют» «родные» платформы по таким свойствам, как локальное хранилище и способность работать, когда устройство не в Сети, граница между веб и «родными» приложениями стирается все больше. Она достигает своего логического предела в операционных системах типа WebOS от Palm и Google Chrome, где «родные» технологии – это веб-технологии.
Нам надо понимать, что веб-приложения, работающие на таких ОС, являются «родными» приложениями. Поэтому мы выбираем между структурами различных ОС и «родными». Этот выбор определяет то, какая «родная» ОС предложит лучший опыт взаимодействия. Потом наш выбор будет проходить между различными «родными» авторскими технологиями – HTML, CSS и JavaScript для «родных» веб-приложений, Objective-C и Cocoa Touch для iOS приложений, Java и Android SDK для Android приложений, C# и. NET для Windows Phone-приложений, и т. д., и т. п.
Неважно, какие платформы или технологии в конце концов победят. Будущее явно за «родным», а веб – это просто еще один клиент. Сейчас вопрос на миллиард долларов звучит не как «Выберем мы сетевое или «родное»?» – а, скорее, так: «Какая платформа или платформы, какая клиентская технология или технологии должны поддерживать наш продукт?»
Чтобы ответить на него, нам нужно понимать сущность нашего продукта и особенно то, к чему он по сути ближе – к сайту или приложению.
Документ или приложение
В Сети один из способов классификации продуктов – это определить их ядро: содержание или поведение. Мы называем совокупность документов с концентрацией на содержании сайтом. Продукт, сконцентрированный на поведении, называется приложение. Вместо того чтобы полностью вставать на сторону одного или другого лагеря, ваш продукт, возможно, расположился где-то между двумя этими полюсами.
Рисунок 9.12. Континуум документ-приложение
Рисунок 9.13. Принцип универсальности, выдвинутый создателем Всемирной паутины, Тимом Бернерсом Ли, был написан в пору, когда Сеть представляла собой в основном совокупность связанных документов. Не обязательно применять его полностью к приложениям, которые по своему дизайну имеют различные ограничения и требования. См. комментарии Ли Веру на возражения Джона Олсопа по поводу моего манифеста одной версии в. Net magazine:
Когда продукт «приближается» к документальной стороне, можно постепенно улучшать свойства ядра, основанного на содержании, сохраняя при этом доступ большого количества людей к ядру. Вносимые изменения обычно либо расслаивают продвинутое форматирование, либо размещаются на этих документах, либо добавляют невообразимые взаимодействия для навигации в них или между ними. Мы можем адаптировать контент под различные размеры экрана и адаптировать ограниченные взаимодействия, которые используются для навигации контента под различные механизмы ввода. Это непростая, но все же выполнимая задача.
Когда продукт перемещается от документа к приложениям, введение прогрессивного улучшения, так или иначе, усложняется. Фактически это может стать полностью бессмысленным и невозможным.
Это напоминает скорее изящную деградацию онлайн-функционала редактора изображений? Как бы редактор изображений работал на телефонах без полноцветного дисплея?
Ни одна команда разработчиков продукта на земле не имеет ресурсов для создания приложений, которые предоставят наилучшие возможности опыта взаимодействиф для каждого пользователя
Какой контент вы бы отображали на таких устройствах?
Приложения не основаны на контенте. Они основаны на поведении. Изящная деградация к упрощенному представлению любого контента приложения не всегда имеет смысл. Приложения часто полностью составлены на основе поведения, которое позволяет пользователю создавать контент. Вернемся к редактору приложений: в нем нет никакого контента, но он позволяет пользователю создать его.
Чтобы создать образцовый опыт взаимодействия, нам нужно поддерживать фокус. Это фокус должен устанавливаться с учетом потребностей пользователей самым наилучшим способом, какой только возможен.
Предоставляя неограниченное время и ресурсы, мы могли бы оптимизировать опыт использования наших приложений на любом устройстве и платформе, известных человечеству.
Однако, используя ограниченное время и бюджет, с которыми нам приходится работать в реальном времени, мы обязательно должны быть разборчивы в выборе нашей аудитории, платформ и устройств. Мы делаем это не для того, чтобы исключить ненужных людей, а потому что мы понимаем, что включать всех и предоставлять всем огромный опыт взаимодействия – непрактично.
Соображения по мобильному дизайну для сконцентрированных на документах продуктах – сайтах
Документальную сторону непрерывной среды – континуума – представляют сайты. Сайт содержит контент, а также представление этого контента. Контент может представлять собой текст, изображения, аудио, видео и т. д., размеченные с помощью языка HTML, для того, чтобы добавить семантику и структуру. Презентация включает в себя как визуальную разметку, так и интерактивные элементы (такие как навигация между страницами и положениями), и обычно осуществляется с использованием комбинаций CSS и JavaScript.
Протестируйте свои дизайнерские разработки на действующих устройствах
Симулятор или эмулятор прекрасно подходят для проверки эффективности изменений кода в ходе разработки, но они не смогут восстановить уникальную эргономику самого устройства. Контекст также является ключевым фактором, который влияет на удобство мобильного использования. А, например, дизайн, который прекрасно действует в офисе при отличных условиях освещения, может не работать при солнечном свете.
Помните еще одно! Когда вы проводите тестирование с симулятором, он потребляет мощность «железа» вашего компьютера, чтобы запустить приложение. Вы можете наблюдать низкую производительность и даже слегка разное поведение, когда работаете с реальными устройствами.
Если у вас есть сайт, первое, что вы должны сделать, протестировать его в мобильной среде и посмотреть, как он отображается и действует. Я сталкивался со слишком многими компаниями, которые не считали важным делать свой сайт удобным для мобильного использования и сразу же «прыгали» в создание «родного» приложения. Будьте осторожны! Не повторяйте таких ошибок, особенно если ваш сайт является важным генератором прибыли. В сайтах, основанных на документах, используйте по возможности прогрессивное улучшение, для того чтобы обеспечить контент и основные взаимодействия при навигации, и чтобы убедиться, что контент остается доступным самой широкой публике.
Для этого вы можете выполнить следующие шаги:
1. Убедитесь, что ваш контент доступен для всех, сделайте правильную семантическую разметку. Главное – отделить контент от представления.
2. Прогрессивно улучшайте контент, чтобы люди, которые просматривают его с экранов разных размеров, получили больше оптимизированного опыта (в настоящее время на этом сосредоточен отзывчивый/адаптивный дизайн).
3. Прогрессивно улучшайте контент, чтобы семейства устройств, основанные на поддерживаемых функциях и возможностях (например, тач), получили больше оптимизированного опыта. Проще говоря, сделайте сайт чувствительным в поведении, а не только в разметке. Здесь вы оптимизируете для особенностей, а не для специфических устройств (так сказать, для всех мобильных телефонов, которые поддерживают тач, а не только для одного iPhone).
4. Прогрессивно улучшайте контент для поддержки уникальной культуры и возможностей различных устройств, которые вы хотите поддерживать. Здесь оптимизация для специфических устройств вполне нормальна. Нет ничего плохого в том, что вы пытаетесь сделать опыт взаимодействия прекрасным, насколько это возможно, даже если он создается для специфических телефонов.
Конечно, каждый из этих шагов занимает и время, и много ресурсов. И в соответствии с этим, вам нужно планировать и составлять бюджет. А что если ваша задумка сделать действующий сайт адаптивным не удовлетворяет нужды пользователей в определенных случаях? Возможно, вам нужно предоставить больше оптимизированного и специального опыта, чем допускает прогрессивное улучшение, с учетом бюджета и сроков. Или может быть вам нужен такой уровень интеграции устройства, который просто не совместим с действующим браузером? В этом случае вам в голову могут прийти мысли о том, создавать ли приложение, и если да, то будет ли оно поддерживать множественные платформы, и какие технологии нужно будет использовать.
Кроссплатформенность или единственная платформа?
Как лучше удовлетворить потребности пользователя: запуская приложение на многих платформах или на единственной, по крайней мере сначала? Когда будете отвечать на этот вопрос, не забудьте, что создание одной платформы не означает, что вы позже не сможете создать отдельное приложение для другой платформы.
Это значит лишь то, что в начале работы над проектом в центре ваших дизайнерских изысканий будет единственная платформа (или даже единственное устройство).
Само по себе не имеет значения, будет ли работать ваше «родное» приложение или оно будет использовать «родные» компоненты устройства или устройств, на которых запускается. (Использование кроссплатформенных авторских технологий для создания приложения, которое вы оптимизировали для единственной платформы, легко осуществимо.)
Ответ на этот вопрос в любом случае определит, какую оптимизацию вы должны сделать на различных платформах. Если вы заботитесь об опыте взаимодействия, то должны оптимизировать ваше приложение на каждой платформе, которую поддерживаете. Ваше решение также повлияет на то, сколько тестирований вы должны сделать (потому что вам нужно будет тестировать каждую платформу, которую поддерживаете), на размер отдела техподдержки (потому что вам нужно будет разбираться с проблемами пользователей под каждую платформу) и на то, сколько времени и бюджета вам понадобится, чтобы все утрясти для этих различных функций.
Миф: Один раз написанный код работает везде
Типичная ошибка, которую допускают дизайнеры, – это предположение, что при использовании кроссплатформенных авторских технологий они могут написать код один раз, а работать он будет везде. Это миф. И он может привести к достаточно дорогим последствиям.
Ваше приложение должно запускаться на множестве платформ, но это в редких случаях означает, что оно будет хорошо запускаться на множестве платформ
Единственный способ заставить приложение хорошо работать на различных платформах – это оптимизировать его для каждой платформы и устройства. Как мы говорили раньше, каждая платформа имеет свою культуру, язык и нормы, которым, как ожидает пользователь, соответствуют приложения. И многих пользователей не интересует, на скольких устройствах работает ваше приложение. Их заботит только то, насколько хорошо ваше приложение будет работать на их устройстве.
Дизайнеры, которые не учитывают уникальную культуру, традиции, язык и нормы платформ, рискуют сделать свои приложения выглядящими неуместно. Приложение будет чужеродным, часто даже вызывающим, просто потому что оно не учитывает культуру платформы.
Так как мы не хотим, чтобы наши приложения демонстрировали такое отвратительное поведение, мы должны оптимизировать их под каждую платформу, которую поддерживаем. Наша цель – создать приложения, культурно восприимчивые к языку, нормам и традициям платформ, на которых они запускаются. Отступить от нее – значит, проявить неуважение к определенному сегменту пользователей.
Смерть от тысячи ранений
Худшее, что вы можете сделать, это, конечно, проявить неуважение к вашим пользователям, создав приложение с наименьшими сходными характеристиками, которое предоставляет им неоптимизированный опыт взаимодействия на каждой платформе. Здесь вы уязвимы больше всего. Даже если ваше кроссплатформенное приложение потенциально может иметь большое количество пользователей, потому что запускается на многих устройствах и платформах, на каждой из них оно будет неудобно в использовании. Проще говоря, кого волнует, на какой платформе работает приложение, если оно работает ужасно?
Еще важнее, что будет, когда на одной из этих платформ появится конкурент со своим великолепным, восхитительным, детально оптимизированным опытом взаимодействия и «вышибет» ваше приложение? А на другой платформе то же самое с вами сделает другой конкурент.
Это равносильно смерти от тысячи ранений. Поддержка множественных платформ не станет функционировать до тех пор, пока вы не сможете хорошо поддерживать все из них. У вас может быть преимущество первого игрока на рынке, но только до той поры, пока вас не превзойдет лучший конкурент.
Напиши один раз, оптимизируй везде
Что ж, написанное один раз работает везде – опасный миф. Кроссплатформенные приложения, которые удачно конкурируют, пишутся один раз, оптимизируются везде. Вы должны понимать, что это означает для вашего бюджета, сроков и плана оптимизации, тестирования и поддержки приложения на каждой платформе, которую вы выбрали.
Пожалуйста, не берите демонстрационные версии различных производителей, обещающие создание кроссплатформенного приложения за пять минут. Это все будет ерундой, пока вы не составите простейший план действий с приложением. Правильное тестирование технологии заключается не в том, чтобы легко создать пятиминутную демоверсию или быстро пройти 7 % пути к свой цели, а в том, насколько легко вам будет «удержать» последние 3 % вашей разработки, включая все важные оптимизации для опыта взаимодействия, что может забрать последний 1 %. На эти детали в разработке приложения у вас может уйти масса времени и усилий.
Рисунок 9.14. Бинарно-каркасная матрица
Сетевые и другие кроссплатформенные технологии
Вообще говоря, кроссплатформенные технологии можно разбить на две группы: те, которые создают «родной» бинарный файл и которые не делают этого. Мы можем дальше классифицировать их на те, которые используют «родные» фреймворки. Эта комбинация дает нам бинарно-каркасную матрицу, представленную ниже:
«Родной» бинарный файл – это пакет приложений, которые могут запускаться напрямую операционной системой данного устройства. Мы, как правило, говорим об этом, когда ссылаемся на «родное» приложение.
Однако гораздо важнее проверить, использует ли приложение «родные» фреймворки. Эти фреймворки воплощают в себе культуру, язык, жесты, символы и нормы платформы.
Чужие приложения в обертке от «родных» бинарных файлов, или Волки в овечьих шкурах
С помощью технологии типа Adobe PhoneGap вы можете (и вполне легко) создать для iPhone «родной» бинарный файл, не использующий «родные» компоненты в фреймворке Cocoa Touch для iOS. PhoneGap «оборачивает» существующее веб-приложение, и создает из него «родное» приложение операционной системы (в примере выше «родное» приложение системы iOS). Ваше приложение становится похожим на «родное» для iPhone и запускается как «родное» приложение, но пользовательский интерфейс приложения при этом воспроизводится с использованием веб-компонентов.
Ваше бинарное приложение это всего лишь оболочка, которая состоит из WebKit компонента. Этот WebKit-компонент визуализирует ваше веб-приложение с помощью веб-компонентов. Из-за того что веб-компоненты не могут соответствовать «родным» ожиданиям, я бы не советовал использовать PhoneGap при создании приложений для повышения продуктивности, таких как календарь, различные списки дел и т. п.
Однако при разработке таких приложений, как электронные книги и игры, т. е. приложений с эффектом присутствия, недостаточная поддержка «родной» структуры в похожих технологиях не является большой проблемой. В среде создателей игр и электронных книг Adobe Flash и ActionScript, Unity и Ansca’s Corona считаются фаворитами, даже если они не используют «родные» структурные элементы и компоненты. Это из-за того, что подобные приложения редко используют «родные» компоненты. Вместо этого дизайнеры стремятся создать полностью иную среду, возможно, скевоморфную, которая выглядит и ведет себя, как настоящая книга, – со своими правилами, взаимодействиями и культурой.
Я бы не советовал использовать Adobe Flex (или приложения, которые пользуются компонентами Flash) по той же причине, что и не советовал использовать PhoneGap для создания «родных» приложений без эффекта погружения. Они не соответствуют культуре «родной» платформы и будут вести себя иначе, чем «родные» компоненты системы.
В общем, будьте осторожны, когда создаете «родные» бинарные файлы, которые легко «обволакивают» «неродные» приложения. Выглядят они как «родные», но ведут себя иначе, потому что не используют собственные компоненты в «родных» фреймворках. PhoneGap приложения, которые используют структуру jQTouch, могут отображать нечто, похожее на таблицу интерфейса iOS при запуске на iPhone. Но это всего лишь HTML, продукт умного использования таблицы CSS и языка JavaScript. Он выдает себя за таблицу вида iOS, но не может соответствовать поведенческим характеристикам настоящего компонента представления таблицы из каркаса Cocoa Touch и поэтому перестает соответствовать ожиданиям.
Неудовлетворенные ожидания – это главный враг для удобства взаимодействия. Бегите от этого, как от чумы.
Приложения с эффектом присутствия против приложений без эффекта присутствия
Важно понимать разницу между приложениями, создающими эффект присутствия и не создающими. Значительно меньше проблем вы получите для приложений с таким эффектом, сделав их «неродными».
Эти приложения обычно занимают все устройство и по определению создают собственную культуру и язык. Игры – хороший тому пример. Игра может иметь собственную систему управления бегом, прыжками и стрельбой. В отрыве от культуры платформы, хорошая игра переносит пользователя в созданный свой собственный мир. Таким образом, в рамках платформы такие приложения используют очень немногие. По сути, это первые кандидаты на использование «неродных» технологий.
Вот почему технология Flash, не являясь «родной» для веба, так популярна при создании игр в Сети. Или почему Unity, не пользуясь «родными» компонентами в Cocoa Touch, применяется для создания многих основных игр на iOS и других платформах.
Приложения без эффекта присутствия, например повышающие продуктивность, как правило, усложняют использование стандартных элементов интерфейса пользователя, таких как кнопки и таблицы. Они используют определенные платформенные взаимодействия, например переход в полноэкранный режим в iOS либо древовидное управление в приложениях Windows или OS X. Таким образом, очень важно, чтобы приложения без эффекта присутствия говорили на «родном» языке и соответствовали «родной» культуре и нормам той платформы, на которой они запускаются.
Суммируя вышесказанное, даже для приложений с эффектом присутствия, главным критерием для выбора «родной» или «неродной» технологии все ещеможет быть производительность.
У некоторых игр, таких как стрелялки от первого лица, нужно выжимать каждый бит для эффективной работы в системе. В подобных случаях некоторые «неродные» технологии могут не совсем подходить для ваших нужд. Например, ранние версии приложений на основе Adobe AIR Flash для iPhone были печально известны как медленные. Впрочем, в последних версиях Adobe AIR на iOS Adobe улучшил эффективность работы.
«Родные» приложения, переведенные с «неродных» языков
Если вы стремитесь оптимизировать опыт взаимодействия, лучшим кроссплатформенным методом при создании «родных» приложений без эффекта присутствия будет использование собственных объектных структур и компонентов. Это не значит, что вы обязательно должны применять «родной» язык программирования данной платформы, чтобы авторизовать ваше приложение.
Рисунок 9.15. Сравнительная таблица некоторых общеизвестных кроссплатформенных технологий
Например, используя Titanium Mobile SDK от Appcelerator, вы можете написать на JavaScript, чтобы создать «родные» компоненты. Таким образом, на iOS, когда вы создаете представление в виде таблицы в Titanium Mobile, «родной» компонент представления таблицы Cocoa Touch создается в вашем интерфейсе пользователя. Оно не просто выглядит как «родное» представление таблицы (как могло быть в случае приложения на PhoneGap, которое имитирует «родные» компоненты), но и фактически является «родным» представлением таблицы. И, что самое важное, оно ведет себя так, как и должно это делать представление таблицы.
«Родное» не обязательно лучше, но все же это «родное»
Единственный способ создания приложений, которые соответствуют нормам, т. е. культуре и языку данной платформы, – это использовать «родные» технологии. Например, пока возможно создание Flash-приложений, которые используются на веб-платформе, они не будут выглядеть или восприниматься как «родные» веб-приложения, которые используют «родные» авторские веб-технологии, такие как HTML, CSS и JavaScript. Также, пока возможно использование этих технологий для создания приложений на таких платформах, как iPhone, они не будут выглядеть или восприниматься как «родные» iPhone-приложения, которые создаются при помощи компонентов структуры Cocoa Touch. Не сказать, что Flash-приложения не могут быть представлены лучше, чем HTML приложения. В определенных случаях использования, особенно в играх, Flash-приложения могут обеспечить лучший опыт взаимодействия. Например, Machinarium, прекрасная игра, созданная с помощью Flash, прекрасно работает на iPad. Опять же для таких приложений, как игры и электронные книги, кроссплатформенное применение технологий типа Unity или Corona поможет сократить время на разработку и облегчить внедрение свойств, что было бы сложнее сделать с родными технологиями (такими как 3D-среда или физический движок).
Рисунок 9.16. Machinarium на iPad, интерактивное «родное» приложение, созданное на технологии Flash
Использование скриптового языка типа JavaScript может облегчить написание приложений и в очередной раз применить навыки по веб-разработке, которыми владеет ваша команда. При этом вы получите все преимущества использования «родных» компонентов в ваших «родных» приложениях.
Кроме того, поскольку Titanium Mobile является кроссплатформенной технологией, она обрабатывает «родные» iOS-компоненты для вашего «родного» iOS-приложения и использует «родные» Android-компоненты, когда компилирует «родное» приложение под Android. Преимущества налицо: вы используете простой скриптовый язык (JavaScript), и вам нужно всего лишь поддерживать один базовый код, вместо того, чтобы изучать и применять Objective-C в iOS и Java в Android, и поддерживать два отдельных языка.
Минус в том, что у вас есть еще один слой абстракции для работы. В конце концов, качество ваших приложений зависит от качества кода, который напишет Appcelerator в своих абстрактных фреймворках. А вы будете зависеть от того, как быстро Appcelerator поддержит новые свойства, которые выпускаются для «родных» фреймворков и SDK. Хотя Appcelerator пытается сделать разницу между платформами прозрачной, насколько это возможно в Titanium, есть различия, не в последнюю очередь культурные, к которым вам еще нужно будет обращаться и оптимизировать (помните наше кредо: напиши один раз, оптимизируй везде).
Это не к тому, что вы должны бояться кроссплатформенных технологий, а, скорее, к тому, что вам нужно проводить исследования, взвешивать все за и против и принимать обоснованное решение по поводу того, добавлять ли еще один слой абстракции в ваш процесс разработки. Каждая кроссплатформенная технология имеет свои плюсы и минусы, а также ситуации, при которых она лучше приспособлена для определенных видов приложений. В то время как Corona – это прекрасный выбор для 2D-игр, Titanium Mobile может быть лучше для построения кроссплатформенного рабочего приложения.
Конечно, Titanium не единственная кроссплатформенная технология, которая может создавать «родные» бинарные файлы и использовать фреймворки. Если у ваших разработчиков есть навыки в разработке C# и. NET, вы также могли бы рассмотреть технологию Mono (а особенно MonoTouch для iOS и Mono для Android). Mono работает по такому же принципу, как и Titanium, но вместо использования JavaScript, вы берете язык программирования C# (…и с осторожностью другие языки программирования. NET),NET паттерны и инструменты для создания «родных» приложений.
Веб-приложения
Если вы читаете эту книгу, скорее всего, вы либо веб-дизайнер, либо веб-разработчик (либо и то и другое), либо вы только учитесь. Ваша роль как веб-дизайнера заключается в разработке набора документов (в этом случае вы могли бы здорово положиться на ваши навыки в графическом дизайне) для приложений с разнообразным поведением (здесь вы бы поупражнялись в применении ваших интерактивных дизайнерских способностей).
У вас также есть богатый выбор материала для разработки вашего продукта. Исходя из нужд вашей аудитории, вы можете выбрать использование «родных» авторских веб-технологий, таких как HTML, CSS и JavaScript, для создания «родных» веб-приложений. В качестве альтернативы вы можете использовать «неродные» кроссплатформенные авторские технологии, такие как Adobe Flash или Unity, для создания «неродных» веб-приложений. И как третий вариант, вы можете использовать комбинацию обеих авторских технологий: «родной» и «неродной» для создания гибридных веб-приложений. Например, сайт, изначально построенный на HTML, CSS и JavaScript, но дополненный технологией Flash, чтобы обеспечить богатый игровой опыт.
Независимо от того, что вы выберете– «родные» или «неродные» веб-технологии, обратите внимание на то, как ваше приложение запускается, откуда (как) оно доступно и есть ли доступ к нему из Сети. Проще говоря, это означает, что у вашего сайта или приложения должен быть URL-адрес и оно должно обслуживаться через протокол HTTP. Это то, что делает веб-приложение веб-приложением.
«Родные» приложения одиночной платформы
В процессе работы, описанном выше, вы, возможно, придете к выводу, что лучше удовлетворите нужды пользователя, если оборудуете одиночную платформу или устройство под ваше приложение. А свое ограниченное время и бюджет вы вложите в оптимизацию опыта взаимодействия именно на ней.
Если все же вы решаете поддерживать одиночную платформу, вам все равно нужно выбрать технологию. Если вы делаете игровое или другое интерактивное приложение, то можете взять кроссплатформенную технологию, такую как Corona от Ansca, Unity или Adobe Flash, которые существенно облегчают разработку подобных приложений.
Если вы создаете не интерактивное приложение, у вас есть выбор между такими кроссплатформенными наборами средств, как Titanium Mobile или Mono. Недостаток здесь в том, что процесс разработки потребует еще одного дополнительного преобразования, и вы мало сможете контролировать оптимизацию вашего приложения, потому что в какой-то степени будете полагаться на «родной» код, написанный специалистами Titanium. Даже если вы погружаетесь в Titanium (или похожий фреймворк типа Mono), помните, что вам все равно нужно изучить «родные» фреймворки (или API) платформы, на которой вы собираетесь работать. Изучать новые фреймворки гораздо сложнее, чем новые языки программирования.
Хотя опытный программист может освоить такой язык программирования, как Objective-C, в считанные дни, у разработчиков уйдут недели (а то и месяцы, даже года) на то, чтобы полностью вникнуть и приноровиться к паттернам, культуре и тонкостям такого фреймворка, как Cocoa Touch.
В конце концов, вы можете использовать «родной» набор средств платформы, которую выберете. Например, вы можете использовать XСode с Objective-C и Cocoa Touch для разработки «родного» iOS-приложения, или Eclipse с Android SDK для создания «родного» Android-приложения, или Visual Studio с C# и фреймворком. NET для разработки Windows Phone-приложения.
Это может включать в себя изучение нового языка программирования (Objective-C для iOS, Java для Android и C# для Windows Phone) или привлечение группы специалистов, которые знают эти языки и имеют опыт работы с «родными» фреймворками. Как мы уже говорили, выбрать новый язык легко, гораздо сложнее изучить новый фреймворк. Не забывайте об этом, когда будете решать, идти ли вам таким путем, если ни вы, ни ваши специалисты не обладают необходимыми навыками.
Плюсов в создании родного приложения с использованием «родных» технологий множество. Во-первых, вы имеете полную гибкость в оптимизации приложения и опыта взаимодействия. Когда вы используете «родные» компоненты и придерживаетесь руководства по интерфейсу для выбранной платформы, ваше приложение будет соответствовать культуре, языку и нормам данной платформы. Пользователям будет легче его изучить и использовать. Также, если вы полагаетесь на чужой абстрактный или преобразующий слой, вы будете постоянно работать с последними версиями кода и фреймворками от производителя, которые дают вам дополнительную гибкость для подгонки новых свойств и обновлений, когда они выпускаются для платформы.
Самое важное то, что если вы направите свои усилия на одну конкретную платформу, время, которое вы потратили бы на оптимизацию, тестирование и поддержку другой платформы, можно сначала уделить оптимизации опыта взаимодействия вашего приложения, а потом, если нужно, добавить поддержку для других платформ.
Дизайн для людей
Платформы и технологии, которые вы выбираете для создания вашего нового продукта, существенно повлияют на то, какой к нему будет доступ, как он будет выглядеть и восприниматься, будет ли он соответствовать, и, будем надеяться, превышать запросы ваших пользователей. Такое решение нельзя принимать на скорую руку.
Если выбор платформы и технологии основан просто на ваших сиюминутных деловых нуждах или на имеющейся у ваших специалистов компетенции, то в этом случае вы принимаете решение в своих интересах, но никак не в интересах пользователя. Это может сработать на какой-то короткий промежуток времени, но вы не сможете долго тягаться с теми, кто изначально решал проблемы пользователей. Выбор платформ и технологий должен базироваться на том, как лучше удовлетворить нужды пользователей, а не на идеологических пристрастиях или стремлении к краткосрочным целям в ущерб долгосрочным.
Помните, что и так существует слишком много нестандартных вещей. Нам не надо больше. Нам нужны вещи, которые будут хорошо работать. Создавайте то, что информирует, оказывает поддержку, развлекает и вызывает восторг. И при этом используйте в работе правильный инструментарий и технологии.
Об авторе
* * *
Арэл Балкан – дизайнер, разработчик, автор, учитель, предприниматель. Страстный поклонник ренессанса, помешан на разработке опыта использования и желании сделать мир лучше с помощью технологии и ораторского искусства. В настоящее время является организатором Конференции по модернизации как части Фестиваля цифровой техники в Брайтоне, а также создает iPhone-приложения, например тепло принятый критиками Feather.
О рецензентах
* * *
Джош Кларк окончил Гарвардский колледж (Кембридж, штат Массачусетс, США). Джош постоянно выступает на интернациональных технологических конференциях, делясь своим видением мобильной стратегии и дизайна для телефонов, планшетов и других перспективных устройствах. Его девиз одинаков как для фитнеса, так и для опыта использования программ: «Без труда не вытащишь рыбку из пруда». Джош является основателем агентства Global Moxie.
*****
* * *
Андерс М. Андерсен имеет степень магистра компьютерной науки, университет La Trobe University, Мельбурн. Его кредо – следующие строки Дугласа Адамса: «Я люблю дедлайны. Мне нравится свист, с которым они пролетают». Благодаря своей работе он делает информацию доступной людям. Самый большой урок, который он извлек из своей карьеры: если хочешь, чтобы что-то было сделано, сделай это сам. Его личное пожелание вам: «Старайтесь узнавать что-то новое каждый день».