ДЛЯ МОБИЛЬНЫХ РАЗРАБОТЧИКОВ

ДЛЯ МОБИЛЬНЫХ РАЗРАБОТЧИКОВ:
Flurry в ноябре прошлого года проанализировало аппы и вывела а-ля
матрицу BCG для мобильных приложений

http://blog.flurry.com/bid/95072/Black-Holes-and-Superstars-in-the-
App-Universe

За последнее время, по ощущениям, Apple несколько ужесточили
review процесс (ну или поменяли внутренние инструкции и чеклист),
поэтому делимся 3 топ проблемами за несколько последних ревью
App in the Air: Explore Airports, In Flow - Explore your happiness и
Airport Guru:

1) In-app purchase - несколько раз нас задвинули с необходимостью
регистрации (хотя бы iCloud) в приложении для "Subscriptions" типов
и restore функции для non-consumable инаппов
2) Неправильное использование лого Apple - не забывайте про
marketing & advertising guidelines for developers:
https://developer.apple.com/appstore/resources/marketing/index.html
3) Side библиотеки - будьте внимательны к библиотекам, которые
используют приватные API

Ну и остальное смотрим тут:
http://insights.empatika.com/blog/2013/02/21/for-mobile-developers-
how-to-succeed-review-of-your-app-by-appstore/

Многие спрашивали у нас наши презентации с курсов по Android
разработке - Ilya Zorin вот выложил. Enjoy! :)

http://www.slideshare.net/BayramAnnakov/android-hse-lecture1

Ситуация:
Мониторя DAU (daily active users), вы отмечаете заметное снижение
активности ваших пользователей. Исследуя ситуации и причины,
приходите к выводу, что в вашем приложении перестали приходить
пуши и поэтому юзеры реже стали открывать приложения. Для
отправки пушей вы пользуетесь сервисом Parse (http://parse.com/). Вы
ресерчите немного, вроде проблема не в Parse. Недавно в другом
приложении была аналогичная проблема и там дело было в
сертификатах. Да и на stackoverflow-подобных сервисах пишут об
этом. Вы издаете новый сертификат, выпускаете внутренний билд,
тестируете... а пуши все равно не приходят.

Отчаявшись вы не знаете, что делать и пишите в Parse. Выясняется, что
у них была ошибка, они ее исправили и теперь пуши приходят...
Приходят на новый сертификат, то есть на новый билд, который
доступен только вашим разработчикам.. А production пользователи
так и не получают пуши, и активность определенного сегмента
пользователей продолжает падать...

Вопрос: какие уроки вы бы вынесли для себя? И в чем положительный
аспект этой ситуации?

К слову диалог из фильма "После прочтения сжечь":
- Чему мы научились агент?
- Не знаю, но точно чему-то научились
- Научились, по крайней мере, больше этого не делать
- Ага, точно
- Еще бы знать, что мы сделали!

В последнее время очень много говорят про onboarding - процесс,
когда ваш пользователь впервые открывает приложения и проходит
первые экраны до тех пор, пока не совершит ключевое действие: для
In Flow - отметить свое настроение; для App in the Air - добавит
полет; для Foursquare - зачекиниться.

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

3 типичные проблемы в onboarding:
1) Cлишкоооом долгий - пользователю нужно преодолеть 100500
экранов пока он доберется до главного... Не все такие терпеливые.
Прикрепляю, к примеру, сравнительный анализ In Flow с Path,
Instagra, Foursquare и Day One, который открыл нам многое в нашем
продукте - респект за это Nikita Kosholkin :)
2) Cлишком вариативный - пользователю предлагается слишком
много вариаций куда пойти и что делать, никто "не проводит за
ручку". В эту тему презентация:
http://www.slideshare.net/BayramAnnakov/social-interfaces-2-
onboarding
3) Слишком "холодный" - чтобы прочувствовать ценность приложения,
пользователю нужны в нем друзья или контент. Без этого приложение
кажется мертвым. Именно поэтому в App in the Air мы
проанализировали отзывы, оставленные во всех аэропортах мира,
обработали их и добавили в раздел Tips.

Очень в эту тему рекомендую еще 2 спорные статьи:
1) If you see a UI walkthrough, they blew it -
http://blog.maxrudberg.com/post/38958984259/if-you-see-a-ui-
walkthrough-they-blew-it
2) Rethinking the Mobile App "Walkthrough" -
http://techcrunch.com/2012/12/28/rethinking-the-mobile-app-
walkthrough/

Я как-то уже share-ил наш чеклист для отправки билда в AppStore и
вот наткнулся на аналогичный для Google Play

Особенно мне понравились ;-)
1) Tell your friends and family to download, rate and review the app
2) Partner up with other app developers to cross promote apps
3) Reply to any negative feedback you’ve received on the Google Play
marketplace

и обилие ссылок под ряд пунктов: от stackoverflow до документации
Google!

https://s3.amazonaws.com/files.appannie.com/blog/pdf/Going_Live_on_
Google_Play_Checklist.pdf

В далеких 70х в Стэнфорде проводили эксперимент, в ходе которого
детям предлагалось не есть зефирку и тогда те получали 2.. Основная
засада была в том, что не есть нужно было тогда, когда
наблюдающего не было рядом... Мало кто выдерживал! Ну почему же
не слопать, если никто не видит?

Интересно, что с программистами так же (я сам был таким): если
никто не видит и не проверяет, то ты совершенно не паришься о
"чистоте" кода. Ты пишешь, чтобы работало, а не чтобы было
читабельно и так далее, и тому подобное! Проблема в том, что потом
этот код никто не может понять, решения не очень адекватные, я уже
не говорю о названиях переменных в коде, из-за которых Заказчик
может подать на тебя в суд (знающие - поймут ;-))

Поэтому мои 3 пункта:
1) Code inspection - только не классический и нудный, а интересный и
в форме challenge-а
2) Hackathon - умение делать простые и работающие, повторно
используемые решения
3) Release lessons learned - когда команды обмениваются опытом и
знаниями, полученными за релиз.

Удачи!

Редко при разработке приложений можно обойтись без
взаимодействия с 3-сторонними API: Foursquare, Facebook, FlightStats
и иже с ними.

Мы много повидали разных API и разных проблем и с Sergey Pronin
составили хит-парад основных ошибок:
1) Пока не попробуешь, не говори, что это работает - часто ты
находишь API и думаешь "опа, я теперь смогу брать расписание
полетов", а как только доходит дело до прототипа вдруг выясняется,
что взять-то ты можешь, да только по полетам с вылетом не ранее 3
дней.

2) Пока не попробуешь, не говори, что это НЕ работает - есть такая
штука в психологии "фундаментальная ошибка атрибуции": это когда
человек во всех бедах винит всех, кроме себя. Часто разработчики
винят во всем провайдеров API, но на деле выясняется, что ошибки
могут совершать и "боги"... ой, наши разработчики. Проблему
усугубляется слепой вере техлида в своих разработчиков и нежелание
поднять свою попу со стула и залезть в код и документацию, чтобы
разобраться в проблеме. У меня была история в жизни, когда я вот так
"промахнулся" перед Заказчиком, а Заказчик как раз полез в код... Я
чуть не сгорел со стыда и взял себе за правило перепроверять (и это
совершенно не относится к вопросу доверия, это скорее
профессионализм)

3) Если чего-то нет в документации, то это не значит что этого вовсе
нет (обратное тоже верно) - кто работал с Foursquare API знает, как
сложно порой взять аватарки - нужно догадаться или посмотреть на
stackoverflow, что между префиксом и суффиксом нужно вставить
слово "original" :)

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

5) Внимательно и почаще читай доку, чтобы понять все возможности -
часто техлид отдает это "на аутсорс", не вникая в документация и не
зная всех возможностей API. Еще важнее знать возможности продакт-
менеджеру, так как часто одна из возможностей может стать
конкурентным преимуществом продукта, а "мы.. а мы не знали" :). Еще
пример: возможность батчами отправлять пуш-сообщения через
Parse.com

6) Рассмотрите вынос взаимодействия с внешним API на сервер: не

надо переделывать клиент, единая точка входа, поддержка разных
платформ.

7) Оцените динамичность информации от провайдера, чтобы принять
правильное решение о кэшировании информации и т.п.

Удачи!

Посмотрел первый выпуск Facebook Developers Live с Doug Purdy,
Facebook Director of Platform Product

Ключевые пункты:
1) Build. Distribute. Promote - эту мантру Doug повторил несколько раз
за передачу.
Build при помощи SDK (Single Sing-On, Deep Linking);
Distribute при помощи Newsfeed и Timeline агрегаций;
Promoto при помощи mobile install ads и Facebook страничек

2) в качестве удачных примеров приложений: Foursquare, RunKeeper,
Nike+, BuzzFeed, Spotify, GoodReads

3) В 2012 ключевым событие стало осознание необходимости и
движение в сторону native разработчиков

4) Игры - 2.5 млрд выплат; 250 миллионов играющих в прошлом
месяце

5) Lifestyle - в прошлом году бум музыкальных приложений; в этом
году ожидают (и хотят) много приложение про книги, фильмы и
фитнесс

6) Facebook сам придерживает и рекомендует разработчикам: для iOS
& Android - нейтив приложения; для остальных - mobile web

7) 3 ключевых компонента Facebook платформы: newsfeed, timeline и
graph search

8) Совет стартапу: разрабатывайте с использованием Facebook SDK,
делайте так чтобы юзеры рассказывали истории при помощи вашего
аппа, а их друзья видели ваш апп и скачивали :))

Что вынес для себя?
Мантра очень напомнила такую же простую и понятную мысль,
которую Apple активно продвигала при выпуске iPhone: "An iPod. A
Phone. And an internet communicator". Задумался о таких же простых
слоганах для наших приложений. И надо повнимательнее посмотреть
на deep linking.

Ссылка: https://developers.facebooklive.com/videos/74/what-
developers-need-to-know-in-2013

Байрам Аннаков (Empatika): 5
индикаторов успеха мобильных
приложений
Процент пользователей, которые появляются благодаря
работе сарафанного радио. Ещё в 1969 году Фрэнк Басс
математически описал модель распространения нового продукта.
Пока продукт никто не знает, работает реклама, потом её
эффективность снижается, и число пользователей либо падает,
либо, если маркетинг и продукт хорошие, продолжает расти за счёт
эффекта сарафанного радио. Это как грипп: если пользователь
вашего продукта подсадит на него больше одного человека,
начнётся эпидемия. Как следить за распространением вируса?
Когда кто-то делится ссылкой на приложение в соцсетях, мы
можем потом увидеть, кто из его друзей перешёл на страничку
приложения и загрузил его, — есть специальные программы,
отслеживающие пути распространения ссылки. Число устных
рекомендаций можно оценить, например, отслеживая, сколько
друзей найдёт пользователь при регистрации. Если хотя бы одного,
значит, он, скорее всего, пришёл по устному совету.

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

Темпы недельного роста. Перед каждым проектом мы
ставим цель расти по количеству загрузок на 5% еженедельно — по
отношению к предыдущей неделе. Если эта цель не достигается, мы
думаем и предпринимаем что-нибудь. У каждого сотрудника-
сооснователя есть $50 в неделю, которые он может потратить на
любую идею, которая, как он думает, внесёт лепту в рост. Это
может быть конкурс детских рисунков или тупая реклама,
дискуссия на портале Quora с упоминанием нашего приложения
или дописывание статьи в «Википедии». Таким образом, каждый
сотрудник понимает, что рост — это и его цель тоже, а не какого-то
маркетолога или PR-агентства.

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

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

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

"Об отзывчивости и баскетбольных мячах"

Если вы занимались баскетболом или ваш "физрук" в прошлом был
тренером национальной сборной по этому виду спорта, то вы
непременно помните такой мяч. Мяч этот не простой: он в разы
тяжелее обычного и часто используется для тренировок - после
бросков со штрафной зоны таким мячом, вы обычным мячом легко
преодолеете половину поля (14 метров, как сейчас помню), а то и
больше.

Аналогично и с мобильными приложениями: если ваше приложение
быстро загружается на стареньком iPod (@Sergey Pronin привет ;-), то
оно точно будет летать на новеньких айфонах.

5 распространенных хаков, как повысить отзывчивость вашего
приложения:
1) Сносите в фоновый процесс инициализацию всего, что не видно
пользователю при старте приложения (маркетинговые и
аналитические фреймворки в первую очередь)
2) Apple рекомендует вместо логотипа на сплешскрине показывать
скриншот экрана приложения: это создает у пользователя ощущение,
что приложение загружается быстрее. Пруфлинк:
https://developer.apple.com/library/ios/#documentation/UserExperienc
e/Conceptual/MobileHIG/IconsImages/IconsImages.html
3) Если вы разрабатываете книгу, то подгружайте заранее следующую
и предыдущую страницу, чтобы быстрее было перелистывание (см.
Narr8)
4) Дайте возможность юзеру ввести комментарий без подгрузки всего
контента, не блокируйте ввод (см. Facebook app)
5) Подгружайте на сервак фотку, пока юзер пишет к ней комментарий
и решает, в какие соцсетки расшэрить (см. Instagram)

И, наконец, не стесняясь замеряйте responsiveness вашего
приложения, сравнивайте с конкурентами и лидерами отрасли. Ведь
лучше иметь представление что улучшать в своих продуктах, чем
довольствоваться статус-кво.

Приглашаю делиться своими "аппхаками" в комментариях - соберем
Best Practices? Думаю всем будет полезно.

1) Tech Lead должен обращать особое внимание на выбор
третьесторонних библиотек, не отдавая это на откуп программиста.
Особенно хорошо нужно разбираться в разного вида лицензионных
соглашений и условиях изменения кода/последующего
распространения. Статья в тему:
http://en.wikipedia.org/wiki/Software_license
2) Часто (я надеюсь, если вы начнете этим управлять ;-) у вас встанет
задача выбора библиотеки из нескольких альтернатив: помимо
вопросов цены и лицензии рекомендую обращать особенное
внимание активности этого проекта (к примеру, до сих пор ли они
юзают UDID в iOS и вовремя ли выпускают обновления - ситуация
может усугубиться отсутствием лицензии на изменения кода), обилия
форумов и вопросов/ответов, модификаций библиотеки.
3) Для коммерческих проектов или стартапов перед продажей
доли/оформлением прав встает вопрос наличия документированного
списка используемых библиотек, подтверждения возможности их
использования. Если сильно пренебречь пп.1 и 2, то эта задача
выльется в nightmare.

Немного "юридический" поcт, получился :)

На прошлой неделе мы встречались с инженерами Apple в Лондоне.
Встреча условно называлась "From Good to Great": спецы из Cupertino
и Apple Europe провели аудит нашего App in the Air - Fly smarter и
дали ряд рекомендаций по улучшению.

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

1) Responsiveness - Apple стремится время загрузки приложения
сократить до 1 сек. Не грузите в основном потоке больше, чем нужно
пользователю на первом экране. Остальное - в фоне.
2) Logging - не забывайте отключать логгинг в production версии - это
ускоряет работу приложения, а также позволяет не логировать
лишнего ;-)
3) Graphics - обратите внимание, как вы работаете с графикой,
слоями и прозрачностью. На скрине красным показаны проблемы с
прозрачкой, которые замедляют работу приложения. И статья в тему:
http://astralbodies.net/blog/2012/01/30/fixing-layer-transparency-
issues-in-xcode/
4) Memory - Не забывайте реагировать на memory warnings
(didReceiveMemoryWarnings)
5) Frameworks - Аккуратнее работайте с 3есторонним софтом
6) Bundle Contents - Просматривайте содержимое финальной сборки
приложения: там могут оказаться лишние ресурсы
7) И посмотрите хотя бы эти 3 видео с WWDC:
iOS App Performance: Graphics and Animations Essentials
iOS App Performance: Memory Essentials
iOS App Performance: Responsiveness

App in the Air: выдержка из чата :-)

Вовремя оказанный саппорт может "по-человечески" вырулить
недостатки продукта — с Никитой Кошолкиным.

1,5 месяца назад я впечатлился эссе Paul Graham-а про модель роста
стартапов. Впечатлился настолько, что решил внедрить у нас в App in
the Air и In Flow: перед каждым продуктом была сформулирована
цель: 5% недельный рост количества даунлоадов по сравнению с
предыдущей неделей. Если вы читали эссе, то знаете, что такой рост
позволяет за год вырасти в 13 раз.

Скажу сразу, цель мы достигли и даже перевыполнили, но я хочу
поделиться инсайтами:
1) Каждый участник команды стал задумываться о задаче роста, а не
делегировать это "какому-нибудь маректологу". Кто-то постил
провокационные вопросы на форумах по самоизмерению и просил
коллег отвечать на вопросы с упоминанием In Flow, кто-то пробовал
рекламу, а кто-то сгенерировал конкурс для детей.
2) Будущее стартапа очень неопределенное, поэтому нужна хоть
какая-то точка опоры, мини-цель, мини-шажок к большой цели.
Вырасти в 13 раз в год - звучит круто, но неопределенно и ты
ожидаешь какого-то чуда, и обычно в конце года :)) Синдром
студента в действии... А вот вырасти на 5 процентов в неделю звучит
более понятно и сфокусированно. Напомню еще раз 1й принцип
Джобса: Фокус. Это то, чего не хватало нам раньше и не хватает
многим стартапам, но это именно то, что теперь мы не упустим.
3) В команде появилась какая-то синхронность и нацеленность на
результат.

Спасибо, Коллеги, и спасибо - Paul Graham :)

ДЛЯ МОБИЛЬНЫХ РАЗРАБОТЧИКОВ: получили доступ к crashlytics beta,
очень легко ставится и хороший репортинг крашей! Рекомендую!

ДЛЯ МОБИЛЬНЫХ РАЗРАБОТЧИКОВ: рассказ основателя Instagram о
том, как они масштабировались и преодолевали проблемы с этим
связанные

"scaling = replacing allcomponents of a car while driving it at100mph"
http://ru.scribd.com/doc/89025069/Mike-Krieger-Instagram-at-the-Airbnb-tech-talk-on-Scaling-
Instagram

ДЛЯ МОБИЛЬНЫХ РАЗРАБОТЧИКОВ: размышления о кнопках
“Buttons are a hack. As in the real world, they’re often necessary,
but they work at a distance—secondary tools to work on primary
objects. A light switch here turns on a lightbulb there. These
indirect interactions must be learned; they’re not contextually
obvious. The revolution that touchscreen devices are working is
that they allow us, more and more, to use primary content as a
control, to create the illusion of direct interaction. I don’t mean to
suggest that we throw out all of our familiar buttons entirely.
Light switches shall remain necessary, after all, and so shall
buttons, espec...

ДЛЯ МОБИЛЬНЫХ РАЗРАБОТЧИКОВ: 10 типичных ошибок при дизайне
мобильного приложения
http://mashable.com/2012/04/11/mobile-app-design-tips/
Flurry недавно выкатили апдейт, в котором есть 2 суперполезных
фичи
1) Funnels - можно строить воронки пользователей, их поведения
внутри приложения и тп
2) Alerts - можно ставить алерты на ряд событий: например, если
повысился уровень ошибок или снизился уровень новых
пользователей и тд и тп

http://www.flurry.com/product/analytics/version3.2.html

ДЛЯ МОБИЛЬНЫХ РАЗРАБОТЧИКОВ: дарите своим юзерам физические
товары за ачивки в приложении

http://techcrunch.com/2012/03/22/kiip-goes-beyond-games-lets-
any-app-reward-you-with-real-life-prizes/

ДЛЯ МОБИЛЬНЫХ РАЗРАБОТЧИКОВ: Eugene Lensky натолкнул на очень
интересную презентацию про дизайн мобильных приложений, пара
принципов оттуда:
1) Никто не читает ваш текст
2) Считайте клики
3) Не копируйте web

Там же про тренды: 5кнопочное меню, смерть таббаров, скрытая
навигация и многое другое

http://www.slideshare.net/theevank/sensational-ios-app-design-first-
principles-and-new-trends-for-2012

ДЛЯ МОБИЛЬНЫХ РАЗРАБОТЧИКОВ: "На мобилках люди сканирует
страницу по картинкам и обычный паттерн слева-направо более не
срабатывает" - результаты eye-tracking-а на iPhone

http://searchengineland.com/study-reviews-and-images-drive-clicks-
in-mobile-109659

если вы интегрировались с facebook, то обратите внимание на
возможность тэгить друзей, локейшны и делать бОООльшие фотки,
проставив соответствующий флаг

http://developers.facebook.com/blog/post/2012/03/07/building-
better-stories-with-location-and-friends/

ДЛЯ МОБИЛЬНЫХ РАЗРАБОТЧИКОВ: простой и полезный сервис для
организации нагрузочного тестирования сервера

http://blitz.io/

ДЛЯ МОБИЛЬНЫХ РАЗРАБОТЧИКОВ: если пользуетесь TestFlight для
тестирования до выхода в AppStore, то очень рекомендую встроить их
SDK:
1) Позволяет отслеживать тестирование
2) Позволяет в режиме реального времени собирать информацию об
ошибках (логи, описание окружения тестера и тп)

https://testflightapp.com/

ДЛЯ МОБИЛЬНЫХ РАЗРАБОТЧИКОВ: часто бывает задача
протестировать экран приложения до кодирования и мы в Empatika
придумали небольшую процедуру: Design Hours

Вот она, собственно: каждый новый экран обсуждается согласно такой
структуре
1) Что это за экран? Зачем он нужен пользователю?
2) Какие действия возможны на экране?
3) Как эти действия можно инициировать?

Потом показываем скрин с результатом действия (если применимо)
4) То ли это что вы ожидали получить?
5) Опишите что вы видите?
6) И далее сам дизайнер отвечает на все вопросы...

Очень важно, чтобы "испытуемыми" были те, кто ранее не видел эти
экраны, а еще лучше - представителями ЦА. В том числе и
разработчикам приложения будет полезно заранее узнать :)

для мобильных разработчиков: из внутреннего обучения - вдруг
пригодится кому.
будут вопросы – welcome
http://www.slideshare.net/BayramAnnakov/flurry-analytics

ДЛЯ МОБИЛЬНЫХ РАЗРАБОТЧИКОВ

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (8)

En vedette

En vedette (11)

Similaire à ДЛЯ МОБИЛЬНЫХ РАЗРАБОТЧИКОВ

Similaire à ДЛЯ МОБИЛЬНЫХ РАЗРАБОТЧИКОВ (20)

Plus de Empatika

Plus de Empatika (20)

ДЛЯ МОБИЛЬНЫХ РАЗРАБОТЧИКОВ