Мобильные приложения ИД Коммерсантъ

За несколько лет совместной работы с Издательским домом «Коммерсанъ» мы спроектировали и разработали мобильные приложения для всех популярных мобильных платформ: iOS, Android и Windows Phone.

Компания Google опубликовала список 75 лучших приложений 2014 года для операционной системы Android. В список включено приложение издательского дома «Коммерсантъ» — единственное, представляющее российские СМИ. В числе других новостных приложений, вошедших в топ-75 Google Play, — New York Times, CNN Breaking US and World News, BuzzFeed, а также агрегаторы Yahoo News Digest и Anews.

Ниже представлен рассказ о создании планшетной версии приложения для iPad.

Предстартовые условия

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

Чего желает заказчик?

Приложение для iPad, в которое войдут все материалы издательского дома «Коммерсантъ».

Тут стоит упомянуть, что в состав ИД «Коммерсантъ» входит более десятка различных газет и журналов, несметное количество приложений, радиостанция и даже собственное новостное агентство.

Поскольку делать по одному приложению для каждого участника ИД долго и дорого в поддержке, было принято решение показать весь этот разнородный контент в одном приложении. Кроме того, единое приложение сможет собрать гораздо более широкую рекламную аудиторию, стоимость контакта будет значительно ниже, а привлекательность для рекламодателей — выше.

В общем, в данном случае идея делать одно приложение для всех участников ИД, хоть и не бесспорна, но, определенно, наиболее практична.

Как подступиться?

Решено было зайти одновременно с двух фронтов

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

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

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

km-ipad-2

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

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

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

km-ipad-3

Техническое задание

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

«Отчего бы не начать с этого сразу?» — спросит внимательный читатель. Безусловно можно, но, как показывает практика, героический блиц-криг очень часто приводит к непредвиденным затратам и обоюдному разочарованию, а это, согласитесь, рано или поздно надоедает.

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

Оценка стоимости проекта

Оставалось лишь согласовать план разработки и стоимость работ с потенциальными исполнителями. Но не тут-то было.

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

Переоценка стоимости - кто виноват и что делать?

На этапе проектирования следовало уделить внимание не только технической, но и бизнес-стороне вопроса, но мы, следуя традиции, этот аспект целиком оставили на усмотрение заказчика. Как оказалось — напрасно.

Способов сократить бюджет в такой ситуации обычно немного: либо сделать скидку, уменьшив почасовую ставку разработчиков, либо ограничить функциональность приложения, пожертвовав тем, что называется User Experience.

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

Кросс-платформенная архитектура

Реализовывать UI на HTML очень не хотелось. Большое время отклика и ограниченные возможности анимации элементов не предоставляют возможности собрать интерфейс, в полной мере отвечающий ожиданиям современных пользователей.

Приводить интерфейс к минимальному набору элементов не имело смысла, поскольку приложение «Коммерсанта» не является для пользователя чем-то жизненно необходимым, а количество контактов с аудиторией — основа бизнеса, а значит, интерфейс в данном случае последнее (после контента), чем можно жертвовать, и придется реализовывать UI нативными средствами.

Для распятия на кросс-платформенном кресте остался единственный кандидат: бизнес-логика. Следовательно, нужно было найти архитектурное решение, которое позволит объединить кросс-платформенную бизнес-логику и «родной» UI в рамках одного приложения.

km-ipad-4

MONO

В результате проведенного исследования оказалось, что единственной кросс-платформенной технологией, на которой можно реализовывать функциональные компоненты без потери производительности, является MONO. Лучшую адаптацию этой технологии для мобильных платформ разработала компания Xamarin: http://xamarin.com/.

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

Для взаимодействия с UI был разработан набор модулей, поддерживающих перевод данных из формата MONO в форматы нативных интерфейсов. В данном случае — между C# (MONO), и Java / Objective C (UI для Android и iOs соответственно).

km-ipad-5

В итоге — сплошные плюсы: проще (быстрее и дешевле) разрабатывать и поддерживать бизнес-логику кросс-платформенного приложения, при этом не пришлось жертвовать удобством пользователей.

Обновили техническое задание в соответствии с архитектурой, план разработки и смету и приступили к делу.

Разработка

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

Вначале была мысль поступить вот так:

km-ipad-6

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

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

Как при таком раскладе сохранить контроль над ситуацией и быть уверенными, что все будет готово в срок?

Поскольку на традиционно длинную стабилизацию в конце проекта времени у нас уже не оставалось, нужно было быть уверенными в статусе проекта на всем протяжении разработки. Один из способов этого добиться — вести разработку не крупными блоками (сервер, бизнес-логика, UI), а по функциональным разделам — издания, новости, реклама, покупки, поиск и т. д.

Оптимальный процесс разработки

km-ipad-7

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

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

Итог

Разработка, не считая двухмесячного этапа проектирования и обсуждения, заняла четыре месяца, из которых месяц ушел на согласование системы подписок на издания для публикации в AppStore.

Чтобы не скучать в ожидании ответа из Apple, мы встроили в приложение систему сбора статистики (в качестве бонуса). Клиент остался доволен, и вслед за приложением для iPad заказал приложения для iPhone и Android.