Shark Develop - компания по разработке мобильных приложений для iOS и Android
Envelope Whatsapp

Рубрика: Разработчикам

Опубликовано

Кто такой дата-инженер, чем он занимается и что должен знать?

| Разработчикам | Кто такой дата-инженер, чем он занимается и что должен знать? 2

Причём здесь дата и почему ею должен заниматься целый инженер?

Учёный может открыть новую звезду, но не сможет её создать.
Ему придётся просить инженера сделать это.
Гордон Линдсей Глегг

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

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

Накопленная информация сама по себе ничего не даёт: для получения выгоды её нужно обработать. Тут в дело вступает дата-инженер.

Чем дата-инженер отличается от аналитика?

| Разработчикам | Кто такой дата-инженер, чем он занимается и что должен знать? 3

Дата-инженер (от англ. data engineer), как можно понять по названию профессии, напрямую занимается доставкой, хранением и обработкой информации. Он выстраивает рабочие процессы, конвейеры обработки данных и ETL-процессы (обработка/преобразование информации).

Термин дата-сайентист (от англ. data scientist) у всех на слуху и обозначает коллегу дата-инженера. С учётом современных трендов на объединение или работу в команде, штатные единицы сайентиста (ученого, аналитика) и инженера представлены либо в одном лице, либо эти специалисты тесно сотрудничают друг с другом.

Итак, инженер выстраивает все каналы связи – от процесса сбора информации до её преобразования в нужный формат. Как в каком-нибудь промышленном симуляторе Factorio или Satisfactory: он находит источник данных, выстраивает конвейер для их передачи, а также создаёт инфраструктуру для обрабоки и преобразования информации.

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

Что нужно знать дата-инженеру?

Так как наша задача – собрать данные, сохранить их, преобразовать и отдать дальше, то основными языками для инженера являются Python и SQL. С учётом популярности облачных технологий – ещё и Java (вкупе с её универсальностью). Нужно также разбираться в облачных платформах.

Для первичной обработки информации и организации её хранения инженеру понадобятся знания бекенда и в области разработки ПО. В качестве основного и самого популярного хранилища выступают СУБД (SQL и noSQL), поэтому в начале пути можно сфокусироваться на них.

| Разработчикам | Кто такой дата-инженер, чем он занимается и что должен знать? 4

Базовые требования

Дата-инженер работает с данными, а значит ему нужно знать о данных всё:

  • Алгоритмы и структуры данных. Здесь важна не теоретическая подготовка с вызубренными определениями, а понимание всех рабочих процессов.
  • SQL – язык структурированных запросов. Почти каждая реляционная СУБД поддерживает этот язык организации запросов для получения или обработки данных.
  • Python, Java/Scala. Python считается одним из лучших языков для работы с данными (и, определенно, самым популярным), а Java/Scala следует знать, поскольку на них написаны почти все инструменты для работы с информацией.
  • Инструменты для работы с большими данными (Hadoop, Spark, Kafka).
  • Облачные платформы (MS Azure или Amazon Web Services).
  • Распределённые системы. Большие объёмы данных предполагают, что работать с ними придётся в кластерах. Новичкам стоит прочесть книгу Эндрю Таненбаума “Распределённые системы”. Для начала она может показаться сложной, но потом это пройдет.
  • Конвейеры данных. Выстраивание путей сбора, обработки и хранения информации занимают большую часть рабочего времени дата-инженера.

Заключение

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

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

Источник: proglib.io

Опубликовано

Apple уточняет правила публикации в App Store

| Разработчикам | Apple уточняет правила публикации в App Store 6

7 июня 2021 года Apple опубликовала новую версию App Store Review Guidelines — документа, который диктует правила, которым должны следовать приложения, чтобы быть опубликованными в App Store.

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

Одно из ключевых обновлений на этом фронте связано с изменением Кодекса поведения разработчиков Apple (разделы 5.6 и 5.6.1–5.6.4 гайдлайна).

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

Apple разъяснила формулировку мошенничества в App Store (5.6.3), чтобы более конкретно указать на любые типы манипуляций с чартами, поиском и отзывами в App Store. Положат ли конец новые правила фальшивым отзывам и покупным установкам пока остается большим вопросам.

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

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

Правила о мошенничестве — это лишь небольшая часть множества изменений, внесенных в гайдлайны App Store. Есть и несколько других, которые также стоит выделить:

  • Apple разъяснила правила, касающиеся hookup-приложений для свиданий и уточнила, что в них запрещена проституция и порнография.
  • Приложения с пользовательским контентом должны следовать правилам и должны иметь блокировку сообщений о нежелательном содержимом и надежную модерацию.
  • Apple поясняет, что разработчики могут общаться по электронной почте с кем угодно, но заявляет, что они не могут направлять клиентов, привлеченных через App Store, на покупки вне App Store.
  • Компания прекратила принимать игры с алкогольными напитками.
  • Приложения, предлагающие создание учетной записи, также должны предлагать удаление учетной записи.

Источник: apptractor.ru

Опубликовано

Разница между User Stories, Use Cases и Scenarios

| Разработчикам | Разница между User Stories, Use Cases и Scenarios 8

Прежде, чем отвечать, нужно сделать паузу и признать, что в сегодняшней терминологии есть некоторая путаница — под Сториз, Сценариями или Юзкейсами могут понимать разные инструменты.

Авторы культовой Designing Interactive Systems — People, Activities, Contexts, Technologies выделяют 4 вида сценариев в зависимости от этапа проекта и целей их создания: пользовательские истории (сториз), концептуальные сценарии, конкретные сценарии и варианты использования (юзкейсы).

Важно заметить, что есть еще Эджайловские Юзер сториз товарища Паттона, что описываются по шаблону As a <>, I want <> so that <> и находятся где-то между Concrete Scenario и Use case.

| Разработчикам | Разница между User Stories, Use Cases и Scenarios 9

Зависимость содержания деталей

Сториз, они про потребность пользователя. Raw user needs.

Юзкейсы же про поведение, которое вы встроите в продукт, чтобы удовлетворить эти потребности. What the software needs to do.

Сториз пишутся человеческим языком = легко читаются и бизнесом и разработчиками. Express understanding of User needs.

Написание Юзкейсов это designing a functional solution.

Разберемся на примерах

User story

Стартуем с самого масштабного уровня, уделяем внимание контексту и всем поведенческим особенностям. Рассказ ведется не от лица абстрактного пользователя, и даже не от лица персонажа, а от лица реального человека (либо от лица того, кто ведет наблюдение/проводит интервью).

Выиграли билеты на концерт Radiohead в Риме, сборы проходили в последний момент, нанервничались и чуть не поругались 🙂 Решили, лететь налегке.

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

Вообщем встряли в пробку и, спустя некоторое время, загорелась лампочка низкого уровня топлива. Пришлось спешно искать заправки поблизости. Как назло, нашу машину можно заправлять только 98-ым бензином, что только добавило накала страстей.

По итогу, нам повезло — заправку нашли, в аэропорт успели, но пришлось сильно поволноваться. Благо Том Йорк сгладил впечатления о поездке, да и Рим крут.

Conceptual scenario

Снижаем планку контекста и движемся к конкретике за счет абстрагирования. Conceptual scenario важны для генерации идей и поиска ответа на вопрос «Как улучшить существующий опыт?».

Алан Купер рекомендует представить, что интерфейс волшебный и в нем можно реализовать всё, что угодно, чтобы выйти за рамки привычного.

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

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

Concrete scenario

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

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

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

Во время движения соединение с интернетом может прерываться.

Agile User story

Примерно на этом уровне находятся и Эджайловские Юзер стори.

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

Use case

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

Из всех видов сценариев Юзкейс — наиболее технический и напоминающий алгоритм, а не историю.

Я, как пользователь-водитель (с включенной лампочкой низкого уровня топлива) смогу:

  • посмотреть все ближайшие заправки на карте
  • посмотреть все ближайшие заправки списком
  • выбрать заправки нужного бренда
  • посмотреть на выбранной заправке наличие нужного топлива
  • — построить до выбранной заправки маршрут

У Юзкейсов есть свой стандартизированный шаблон:

| Разработчикам | Разница между User Stories, Use Cases и Scenarios 10

Потом собираете вместе ваши Сценарии, Сториз и Юзкейсы в один документ, рисуете Флоу и получаете полное описание каждого взаимодействия между пользователем и продуктом, которое вы планируете создать.

Когда и что использовать?

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

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

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

Источник: designpub.ru 

Опубликовано

Как и зачем писать Use Cases

| Разработчикам | Как и зачем писать Use Cases 12

Создание эффективных Use Cases (далее используется термины «варианты использования», «сценарии», «юзкейсы») — must have навык любого аналитика. Ведь в некоторых случаях без описанных сценариев не обойтись намного сложнее, чем с ними.

Следующие заметки будут полезны начинающим бизнес аналитикам, системным аналитикам, а также студентам.

Что такое Use Case

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

Use Case описывает сценарий взаимодействия участников (как правило — пользователя и системы). Участников может быть 2 и больше. Пользователем может выступать как человек, так и другая система.

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

В жизни встречаются такие названия: варианты использования, юзкейс, сценарий, прецедент, сценарий использования.

Текст vs диаграмма/схема

Какое описание лучше: текстовое или диаграмма? Выбор за вами и вашей командой. В первые годы работы я использовал диаграммы либо диаграммы + текстовое описание к ним. Сейчас я предпочитаю текстовое описание сценариев, и объясню почему:

  • Такой формат более понятен заказчикам (а они тоже предпочитают читать и согласовывать варианты использования).
  • Текст проще и быстрее отредактировать, чем диаграммы и текст.

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

Кому и в каких случаях нужны сценарии

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

А также другим участникам процесса.

В каких случаях они нужны:

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

Как их описывать

Давайте рассмотрим пару примеров, они говорят сами за себя.

Пример 1. Разблокировать учетную запись пользователя (простой короткий пример, без альтернативного потока событий):

| Разработчикам | Как и зачем писать Use Cases 13

Пример 2. Авторизация пользователя:

| Разработчикам | Как и зачем писать Use Cases 14

| Разработчикам | Как и зачем писать Use Cases 15

Важные моменты

  • Очевидно, что если Пример 1 можно было безболезненно описать простым текстом, то Пример 2 намного лучше воспринимается в виде сценария. Но если у вас вся функциональность описана в виде юзкейсов, то лучше описывать юзкейсами даже очень простые сценарии, из пары шагов. Пусть ваша спецификация будет в едином стиле.
  • Используйте минимальное количество слов и пунктов, необходимых для однозначного понимания сценария. Если юзкейс получается слишком длинный, возможно, лучше будет разбить его на несколько. С очень длинными сценариями, с большим количеством расширений, работать крайне неудобно.
  • Если в двух и более сценариях повторяется одинаковый набор шагов, есть смысл вынести эти шаги в отдельный сценарий, и ссылаться на них. Документ будет легче. А если что-то в этих шагах поменяется, то достаточно будет изменить в одном месте.
  • Список сообщений, которые система выдает пользователю, стандартные тексты электронных писем и т.п. удобно расположить в едином месте в документе, и ссылаться на нужный пункт из разных юзкейсов, т.к. сообщения в сценариях часто дублируются.
  • Перечитайте документ со сценариями, перед тем, как отдавать его разработчикам или заказчикам. Лучше даже несколько раз. Всегда находятся моменты, которые можно описать лаконичнее, или выявляются какие-то несоответствия. Или случайные «копипасты». Уважайте время и головы других людей.
  • Кстати, про «копипасты». Незаполненную табличку для описания юзкейса есть смысл «копипастить».
  • Как видно из примеров выше, расширение к шагу номер 1 указывается в разделе «Расширение» как 1а, 1б, и т.д. Расширение *а — это общее расширение к сценарию, не к конкретному.

Правильных и полезных вам сценариев! Спасибо за внимание.

При написании статьи я использовал материалы из книги Алистера Коберна «Современные методы описания функциональных требований к системам».

Источник: dou.ua

Опубликовано

Все инженеры умеют программировать, но не все программисты могут быть инженерами: в чем отличие?

| Разработчикам | Все инженеры умеют программировать, но не все программисты могут быть инженерами: в чем отличие? 17

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

Многим людям не нравится термин “инженер по разработке программного обеспечения” из-за относительного сравнения с инженерным делом. Но эта статья посвящена не термину. Если вам не нравится название, вы можете заменить его на “автор ПО”, “мастер ПО” или даже “художник по ПО”.

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

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

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

Хотите еще больше аналогий? Конечно:

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

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

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

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

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

Склонность к поиску решений

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

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

Перед созданием программы инженер задает вопросы:

  • Какие проблемы я пытаюсь решить?
  • Можно ли сделать для их решения что-то, кроме написания кода?
  • Что я могу сделать, чтобы эти проблемы было проще решить при помощи кода?

Качество кода

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

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

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

Другой важный аспект отличных программ — это ясность кода, а не количество тестов или число в отчете по тестовому покрытию. Этот код может прочитать кто-то ещё? Смогу ли я понять этот код через несколько недель?

В программировании существует только две по-настоящему сложных вещи: инвалидация кэша и наименование вещей, — Фил Карлтон

Удобство чтения кода важнее, чем вы думаете. К сожалению, для ясности кода нет хороших метрик. Знание хороших методов может помочь, но часто этого недостаточно. Хорошие инженеры просто учатся этому с опытом. Здесь подходит метафора с писательством: знание большого количества слов не поможет вам писать понятные тексты.

У меня не было времени на короткое письмо, поэтому я написал длинное, — Марк Твен

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

Среда и тестирование

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

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

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

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

Стоимость и эффективность

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

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

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

Удобство использования

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

Вот несколько примеров:

  • При создании форм для ввода данных хорошая программа будет игнорировать прописные или строчные буквы, которые используются для ввода email-адреса. Она также уберет ненужные пробелы. Не нужно мучать пользователя из-за включенного Caps Lock, адрес почты уникален. Если программа принимает новые адреса, она должна сообщать пользователю о проблемах с вводом, например, об отсутствии знака @ или опечатке в gmail.ocm.
  • При перенаправлении пользователя хорошая программа запомнит первоначальное местоположение и перенаправит пользователя туда после завершения задачи. Хорошая программа также запомнит уже введенные данные и взаимодействия, которые нужны будут в следующих шагах. Например, вы ищете авиабилеты на Expedia в качестве гостя. Затем вы решили создать аккаунт. Вся ваша история поиска будет сохранена в новый аккаунт, и вы сможете получить к ней доступ с разных устройств.
  • Хорошая программа создается с учетом пользовательских сценариев. Поставьте себя на место пользователя. Однажды я забронировал билет United и забыл ввести свой номер постоянного пассажира. После получения подтверждения я отправился на сайт United, чтобы добавить номер, и эта задача заняла у меня десять минут. К этой функции не было очевидных путей, поэтому мне пришлось проверить все ссылки, которые могли бы вести к ней. Я уже был на странице с этой функцией, но я не увидел её в первый раз, потому что она была спрятана в большой форме. Мне пришлось найти информацию о пассажире, пролистать около 20 строк в этой форме, ввести номер пассажира и номер телефона, чтобы отправить эту форму. Это пример программы, которая создавалась без учета точки зрения пользователя.

Читабельность и безопасность

Это наиболее важные моменты, которые отличают профессионалов от любителей. Они знают, что ответственны за создание надежных и безопасных решений.

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

Пользователи будут вводить неверные данные в программу. Некоторые будут делать это специально, чтобы взломать её. Ответственного за недавний скандал с Equifax обвинили в том, что этот человек не сделал свою работу, то есть не создал устойчивую к зловредным входным данным программу.

Безопасность касается не только зловредных данных, но и обычных. Если пользователь забывает пароль, то сколько раз он или она сможет его ввести? Заблокируете ли вы после этого аккаунт? Что если кто-то этого и добивается? Позволите ли вы вводить пароль через незащищенное соединение? Что если попытка логина состоялась из необычного места? Что если логин кажется сгенерированным автоматически?

Что вы сделаете, чтобы защитить пользователей от межсайтового скриптинга и подделки запросов, атаки посредника и простого социального фишинга? Есть ли у вас стратегия на случай DDoS-атаки? Эти вопросы — это только несколько из проблем, к которым вы должны готовиться.

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

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

Инструменты

Несомненно, нам нужны хорошие инструменты. Они многое меняют и часто недооцениваются. Представьте, если бы нам все ещё нужны были FTP для файлов! Представьте проблемы с производительностью и устранением багов без Chrome DevTools! Представьте, как неэффективно бы было писать на JavaScript без ESLint и Prettier!

Выбор языка имеет значение. Типобезопасность имеет значение. Лучшее, что случилось с JavaScript — это TypeScript и Flow. Статический анализ кода важнее, чем вы думаете. Если вы этого не делаете, то ставите себя под удар неизвестных будущих проблем. Не программируйте без системы статической проверки типов. Если в вашем языке этого нет, поменяйте язык или используйте компилятор. Сегодняшние компиляторы могут работать, просто читая комментарии в коде, и это будущее проверки типов для языков, которые не поддерживают её.

Эволюция разработки

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

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

Источник: apptractor.ru

Опубликовано

9 трендов, которые изменят digital-маркетинг в 2019 году

| Разработчикам | 9 трендов, которые изменят digital-маркетинг в 2019 году 19

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

Дополненную реальность станут использовать намного шире

Совсем недавно AR в digital-маркетинге использовалась только среди бьюти-брендов. L’Oreal, Punky Colour и Madison Reed давно сделали AR-приложения для виртуального макияжа. Однако по оценкам Harvard Business Review, мировые инвестиции в развитие сферы к 2020 году превысят $60 млрд.

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

Coca-Cola недавно проспонсировала разработку брендированного приложения для AR-трансляций с автогонок NASCAR. Виртуальный «портал» на экране смартфона выполнен в виде гигантской банки колы. Так бренд газировки планирует повысить лояльность среди любителей автогонок, а NASCAR надеется «достучаться» до миллениалов.

| Разработчикам | 9 трендов, которые изменят digital-маркетинг в 2019 году 20

SEO-инструменты начнут подстраиваться под голосовой поиск

Голосовой поиск быстро набирает популярность. Среди драйверов роста — распространение голосовых ассистентов в мобильных, бурная динамика продаж «умных колонок», появление бытовой техники с голосовым управлением вроде холодильников Samsung Family Hub.

| Разработчикам | 9 трендов, которые изменят digital-маркетинг в 2019 году 21

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

Интеграция с голосовыми сервисами

По прогнозам агентства NPD Group, к концу 2019-го продажи «умных колонок» вырастут на 50%, а объем рынка достигнет $2,7 млрд. Маркетинговые инструменты будут интегрироваться с голосовыми сервисами: появится много приложений для голосового шопинга, заказа еды и получения новостей.

H&M Home уже запустил приложение, работающее в связке с Google Ассистентом. Оно дает советы по оформлению комнат в разных стилях и помогает подобрать подходящие товары в каталоге компании. В приложении пиццерии Domino’s голосовой ассистент Google запоминает последний выбор пользователя и может сам его повторить — это позволяет ускорить заказ. Тем временем, знаменитый фэшн-ритейлер Asos и розничная сеть Argos запустили онлайн-сервисы для резервирования товаров с помощью «умной» колонки Google Home или голосового ассистента на смартфоне.

| Разработчикам | 9 трендов, которые изменят digital-маркетинг в 2019 году 22

Прорыв чатботов

Ботов всё чаще используют во всех видах взаимодействия между брендами и потенциальными клиентами. По прогнозам компании Gartner, к 2020-му 85% таких взаимодействий будет происходить без человеческого участия.

Пока развитие тренда тормозится из-за консервативности пользователей: согласно опросам компании Statista, лишь 34% респондентов готовы предпочесть чатботы традиционным каналам коммуникации с онлайн-ритейлерами. Но их мнение может измениться с появлением нового поколения AI-чатботов. Они будут запрашивать информацию о пользователе, понимать разговорную речь и вести полноценный диалог, который будет сложно отличить от общения с обычным собеседником.

Среди них — чатбот Clare.AI, использующий обработку естественного языка и способный работать финансовым онлайн-консультантом. Также есть не менее общительный Morph.AI, который автоматизирует клиентскую поддержку. В ближайшие год-два такие чатботы полностью поменяют привычные представления о том, как происходит общение между бизнесом и клиентами.

«Микромоменты» будут вычисляться точнее

Уже сейчас в среднем пользователь проводит со своим мобильным устройством 177 минут в день и обращается к нему около 150 раз. Такие обращения в итоге могут привести его к онлайн-покупке — это и есть «микромоменты», когда пользователю нужно что-то узнать, сделать, купить или куда-то пойти. Скоро они обретут особую значимость благодаря доступности новых технологий обработки данных.

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

Пример — гостиничная сеть Red Roof Inn. Не так давно компания использовала информацию о задержках авиарейсов, чтобы запустить таргетированную мобильную рекламу для авиапассажиров. Если вблизи аэропорта оказывался отель Red Roof Inn, пассажиры получали лаконичное рекламное сообщение: «Застряли в аэропорту? Приезжайте к нам». Удачное использование микромомента увеличило объем заказов на 60%.

Успех вдохновил Red Roof Inn на запуск новой таргетированной рекламы — в этот раз нацеленной на водителей. Чтобы точно отслеживать микромоменты, в ней используется сложный алгоритм, основанный на обработке информации о дорожном движении в реальном времени. С момента запуска эта реклама обеспечила компании 225-процентный прирост в бронированиях.

Видео станет важнейшим из искусств

В 2019 году пользователи впервые проведут онлайн больше времени, чем перед экранами телевизоров. Значительную часть времени они потратят на просмотр онлайн-видео. К концу 2018-го средняя длительность просмотра в мире впервые превысила час, а к 2020-му достигнет 84 минут.

И если рынок телерекламы начнет стагнировать, то суммарный мировый бюджет на производство онлайн-видеорекламы будет ежегодно расти на 17%. Бурный рост ждет индустрию и в прямых онлайн-трансляциях. По данным Yahoo, они обгоняют все другие направления онлайн-видео с точки зрения ежегодного прироста.

Разнообразие форматов (репортажи, видеоблоги, интервью, дискуссии) позволяет легко приспособить такой контент практически под любую аудиторию. Отсутствие обработки и монтажа сокращает дистанцию между брендом и пользователями, а главное — соответствует запросу на достоверность и аутентичность.

Живые трансляции, согласно статистике Facebook, смотрят трое дольше обычных видео, присылая больший поток комментариев. Это создает все условия для развития трансляций в digital-маркетинге.

Мультиканальность вырастет в омниканальность

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

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

| Разработчикам | 9 трендов, которые изменят digital-маркетинг в 2019 году 23

Мобильные сайты будут загружаться быстрее

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

Для решения этой проблемы у Google есть набор эффективных инструментов во главе с Accelerated Mobile Pages (AMP) — проекта с открытым исходным кодом для создания ускоренных мобильных веб-страниц. Среднее время загрузки AMP-страницы из поиска Google сокращается до 0,5 секунды, трафик сайта при этом увеличивается в среднем на 10%, а конверсия в интернет-магазинах вырастает на 20%. Проверить, насколько хорошо работает ваша мобильная версия, можно с помощью сервиса Test my Site. Он сравнит работоспособность сайта с другими игроками отрасли и расскажет, что можно улучшить.

Ценность пользовательского контента возрастет

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

| Разработчикам | 9 трендов, которые изменят digital-маркетинг в 2019 году 24

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

Один из недавних примеров UGC-кампании с небольшим бюджетом и высокой отдачей — 10-дневный фоточеллендж #Etihad1Million, устроенный авиаперевозчиком Etihad Airways и приуроченный к миллионному фолловеру бренда в Instagram. Участникам предлагалось делиться своими трэвел-фотографиями с хэштегом конкурса, а для мотивации использовались небольшие ежедневные призы за лучший кадр.

Футбольное медиа Copa90 подошло к организации своей UGC-кампании с куда большим размахом. В преддверии Чемпионата мира по футболу в России оно договорилось о партнерстве со Snapchat. Результатом стали ежедневные выпуски с UGC-контентом, призванные обеспечить эффект присутствия на чемпионате для тех, кто не смог приехать в Россию. По итогам этой кампании Copa90 удалось привлечь 31 миллион уникальных пользователей.

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

Источник: thinkwithgoogle.com

Опубликовано

Тренды в языках программирования 2019

| Разработчикам | Тренды в языках программирования 2019 26

2018 запомнится нам открытиями в сфере искусственного интеллекта и машинного обучения, скачками биткоина и развитием блокчейна. Что нас ждет в новом году?

Автоматизация поглощает отрасли целиком. Появляется всё больше новых технологий, но нельзя забывать об языках программирования и алгоритмах, которые являются базой.

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

3 языка программирования, обязательных к изучению

1. Python

Python — не новый язык. Он был создан Guido van Rossum и впервые выпущен в 1991 году. В настоящее время с развитием искусственного интеллекта, машинного обучения, аналитикой данных, разработкой на основе алгоритмов, внезапно захватывающей мировое внимание, он стал любимцем для большинства программистов.

Владельцы бизнеса, которые хотят масштабироваться и расти, всё больше внимания уделяют автоматизации, в связи с этим растет спрос на IT-услуги.

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

Применение Python:

Аналитика данных

Когда речь заходит о науке о данных, статистике, аналитике, ML, Python — один из самых подходящих языков. Да, он конкурирует с R. R — это статистический язык программирования. Если вам это интересно, изучайте R.

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

Веб-разработка

Python хорошо подходит для разработки веб-приложений без особых сложностей. Он поставляется с богатым набором библиотек и интернет-протоколов, таких как:

  • Requests — клиентская HTTP библиотека.
  • BeautifulSoup — HTML парсер.
  • Feedparser — парсинг RSS/Atom лент.
  • Paramiko — для реализации протокола SSH2.
  • Twisted Python — событийно-ориентированный фреймворк (для асинхронного сетевого программирования).

Есть еще такие сильные фреймворки, как Django, Pyramid и микрофреймворки flask и bottle, позволяющие программировать быстрее.

Вы можете писать CGI скрипты, еще у вас есть возможность управлять контентом с помощью таких систем, как Plone и Django CMS в Python.

Разработка на Python — отличный вариант для новичков и для тех, кто хочет сменить язык программирования.

Science и Numeric применение

Python — любимец многих экспертов по аналитическим данным из-за коллекции библиотек, предназначенных для статистического и численного анализа:

  • SciPy — коллекция пакетов для математики, науки и инженерии.
  • Pandas — библиотека для обработки и анализа данных.
  • IPython — интерактивная оболочка, которая предоставляет расширенную интроспекцию, дополнительный командный синтаксис, подсветку кода и автоматическое дополнение.
  • NumPy —предоставляет общие математические и числовые операции в виде пре-скомпилированных, быстрых функций.

Образовательный сектор

Python преподается в большинстве колледжей и университетов, потому что прост для понимания.

Разработка ERP

Python подходит для разработки программного обеспечения для решения бизнес-задач корпоративного уровня. Уже существует много популярных ERP, таких как Odoo & Tryton, с помощью которых можно эффективно управлять ресурсами предприятия.

Разработка игр

Да, на python можно разрабатывать игры, хотя наиболее предпочтительно использовать Unity, у Python есть PyGame, фреймворк PyKyra. Вы также получаете множество 3D-рендеринговых библиотек для разработки 3D-игр.

Базы данных, создание сетей, программирование, робототехника, web scrapping, AI, ML — вот что делает Python таким популярным для изучения в 2019 году.

2. Javascript

Это сильный соперник для Python, и главная причина этого — его легкость и способность поддерживать full stack и мобильную разработку.

Все благодаря популярности стека технологий NodeJs & MEAN. Крупные технологические компании разрабатывают свой продукт с помощью javascript и активно используют этот стек.

С помощью JavaScript вы можете создавать веб-приложения, серверные приложения, desktop и мобильные приложения.

Разработка серверной части

NodeJS — подарок для многих разработчиков. Это сильная основа для всех JS программистов. NodeJS помогает создавать как desktop, так и серверные приложения на JavaScript, без необходимости использования браузера.

Мобильная разработка

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

React Native стал очень популярным среди разработчиков мобильных приложений, которые хотят внедрить кросс-платформенную мобильную разработку, не изучая Native Development с помощью Android и iOS.

Blazing Fast JavaScript engines

Все популярные разработчики браузеров: Mozilla, Google и Apple конкурируют за создание самых быстрых интерпретаторов JavaScript внутри браузеров, чтобы браузер мог имитировать среду, похожую на собственные приложения. Они конкурируют, чтобы предоставить веб-приложениям дополнительные функции, высокую скорость и большую производительность, которые поставляются с родными мобильными приложениями.

Javascript расширяет возможности создания собственного приложения в браузере и облегчает жизнь веб-разработчикам.

JS фреймворки, которые нужно обязательно знать

Рассмотрим некоторые из популярных JS-фреймворков:

AngularJS

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

Это дает совершенно новую жизнь HTML-коду, когда атрибуты HTML смешиваются с Angular директивами. Кроме того, он понятен и прост в развертывании.

ReactJS

React.js — библиотека от Facebook и Instagram, позволяет разрабатывать масштабируемые приложения, которые соответствуют всем современным требования, которые так быстро меняются.

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

Vue.js

Один из самых простых фреймворков, который должен знать даже новичок в области программирования. Он создан на основе ReactJS, AngularJS и Knockout.js, чтобы создать экосистему, которая продуктивна во всех отношениях.

Meteor.js

Meteor.js — JavaScript фреймворк с открытым исходным кодом. Это всеобъемлющий фреймворк, чрезвычайно стабильный и использует чистый JavaScript для создания масштабируемого веб-сайта, а также мобильных приложений. Он предоставляет множество ресурсов, учебных пособий и пакетов, которые упрощают процесс разработки веб-сайта или мобильного приложения.

Backbone.js

Был выпущен Джереми Ашкенасом в 2010 году по лицензии MIT. Он придает структуру веб-приложениям с помощью моделей с биндингами по ключу и пользовательскими событиями, коллекций с богатым набором методов с перечислимыми сущностями, представлений с декларативной обработкой событий; и соединяет это все с вашим существующим REST-овым JSON API. Pinterest, Delicious, Disqus, Walmart и Foursquare активно им пользуются.

Polymer.js

Google выпустил этот JS-фреймворк в 2013 году с целью расширения возможностей HTML через веб-компоненты. Это дает разработчикам возможность структурировать пользовательские элементы HTML на основе технологий браузера. Причина роста его популярности — способность внедрять современный и инновационный подход к разработке веб-технологий.

3. Язык программирования Go

Go — это язык программирования с открытым исходным кодом, который упрощает создание простого, надежного и эффективного программного обеспечения.

Go был задуман в 2007 году и официально выпущен в 2012 году и был принят в Google для повышения производительности программирования в эпоху многоядерных процессоров, компьютерных сетей и больших баз кода.

Преимущества Go:

  • Статическая типизация и эффективность (как в C ++ или Java).
  • Производительность и простота использования (как в Python или JavaScript).
  • Высокопроизводительная сеть и многопроцессорность.

Таким образом, он включает всю легкость Python и эффективность C ++ и Java, чтобы помочь создавать масштабируемые приложения.

Go постепенно становится одним из самых перспективных языков, которые нужно изучать и применять в будущем.

Почему Go?

Популярность использования Go объясняется тем, что это легкий язык с открытым исходным кодом, подходящий для современных архитектур. Docker и пакет от Google Kubernetes построены с использованием Go. Go также набирает силу в науке о данных.

Данные на 2018 год:

| Разработчикам | Тренды в языках программирования 2019 27

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

Мы видим большое будущее для Javascript и Go. Если вам нужно проникнуть в интеллектуальный анализ данных, то изучайте Python. Если вы планируете заниматься мобильной разработкой, изучайте Javascript.

Развивайтесь в одном направлении и становитесь лучшим в своем деле.

Источник: vc.ru

Опубликовано

Монетизация приложения: 6 прибыльных бизнес-моделей, которые работают

| Разработчикам | Монетизация приложения: 6 прибыльных бизнес-моделей, которые работают 29

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

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

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

Как выбрать правильную бизнес-модель для своего приложения?

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

  1. Какую проблему и каким образом решает ваше приложение?
  2. Чем ваше приложение уникально, почему люди будут за это платить?
  3. Как вы думаете, какие еще положительные стороны есть у вашей программы?
  4. Насколько хорошо может работать уже выбранный вами способ монетизации для этого приложения?

Также важно определить баланс между вашим желанием привлечь больше пользователей с желанием получить деньги. Некоторые способы монетизации позволяют начать зарабатывать сразу же после релиза приложения, в то время как другие модели обеспечивают постепенный набор пользовательской аудитории с монетизацией через определенный период. Сколько у вас времени? Можете ли вы какое-то время воздерживаться от монетизации приложения, чтобы набрать базу пользователей

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

Бесплатное приложение с рекламой

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

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

| Разработчикам | Монетизация приложения: 6 прибыльных бизнес-моделей, которые работают 30

Итог:

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

Плюсы:

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

Минусы: 

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

Freemium

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

Отличным примером сейчас является игра Angry Birds. Компания Rovio предоставляет приложение бесплатно, но некоторые функции скрыты до момента оплаты, включая дополнительные уровни, расширение возможностей птиц и прочие. Игра очень увлекательна, поэтому пользователи играют в нее месяцами и некоторые покупают дополнительные возможности уже за деньги.

| Разработчикам | Монетизация приложения: 6 прибыльных бизнес-моделей, которые работают 31

| Разработчикам | Монетизация приложения: 6 прибыльных бизнес-моделей, которые работают 32

Итог:

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

Плюсы: 

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

Минусы:

  • Если вы предложите слишком мало базовых функций, пользователи будут уходить.
  • Если будет слишком много базовых функций, пользователи не станут покупать дополнительные.

Платные приложения

Еще одна очень распространенная бизнес-модель, которая предполагает оплату для получения доступа к приложению. Стоимость может быть очень разной – от $0,99 до $999.99, а разработчик получает деньги с каждого нового пользователя. Ключом к успеху является способность разработчика представить возможности приложения в выгодном свете, так, чтобы заинтересовать покупателя в самом начале. В каталоге, как правило, указываются «киллер-фичи» программы, это в буквальном смысле слова предложение, от которого невозможно (в идеале) отказаться.

Примером удачного приложения, где используется именно эта бизнес-модель, является Calendar 5, оцененное разработчиком в $4,99. Программа позиционируется как умный календарь для корпоративных задач и важных событий. Авторам приложения в большей степени удается убедить пользователей, что Calendar 5 лучше, чем календарь, поставляющийся с ОС по умолчанию.

| Разработчикам | Монетизация приложения: 6 прибыльных бизнес-моделей, которые работают 33

Итог:

Эта бизнес-модель исповедует принцип «плати, затем бери», использовать ее стоит тем командам, которые уверены, что смогут убедить пользователей платить за программу.

Плюсы:

  • Средства зачисляются на счет пользователя с каждой новой загрузкой программы.
  • Люди, которые оплатили приложение, скорее всего, станут часто им пользоваться – ведь деньги уже потрачены.
  • В платном приложении обычно нет никакой рекламы, которая может раздражать пользователей.
  • Эта модель мотивирует разработчиков уделять максимум внимания продвижению и упрощает подсчет ROI.

Минусы:

  • Продавать программы довольно тяжело, поскольку конкуренция в каталогах приложений очень высока.
  • 90% платных программ скачиваются меньше, чем 500 раз в день.

Внутриигровые покупки

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

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

| Разработчикам | Монетизация приложения: 6 прибыльных бизнес-моделей, которые работают 34

Итог:

Такого рода бизнес-модель позволяет открыть еще один канал продаж своих товаров или услуг. Кроме того, это может быть и способ зарабатывать деньги в игровом приложении – продавать внутриигровую валюту и разного рода бонусы.

Плюсы:

  • Довольно гибкая бизнес-модель, которая с успехом может использоваться компаниями, работающими в eCommerce-/mCommerce-сфере.
  • Внутриигровые покупки – отличный способ продажи товаров или услуг с минимальным риском.
  • Возможность приобретения виртуальных товаров может увеличить степень лояльности пользователя.
  • Маржа обычно достаточно высокая, поскольку продавцы не несут побочных затрат вроде аренды помещений для реальных магазинов.

Минусы:

  • Обычно каталоги приложений забирают себе часть дохода от продажи виртуальных (но не реальных) товаров, приобретенных внутри программы.
  • Не так давно власти США и Евросоюза обязали Google и Apple указывать больше подробностей о товаре в приложениях из каталога для лучшей защиты пользователей.

Подписка

Еще одна привычная бизнес-модель, которая имеет много общего с Freemium. Но здесь речь, как правило, идет о получении пользователем доступа к контенту, а не к возможностям программы. Обычно подписка (paywall в некоторых случаях) предполагает получение некоторого объема контента бесплатно. Если пользователь желает получить больше, нужно платить – обычно предусматривается оплата полного доступа на определенное время.

Umano – неплохой пример использования именно такой бизнес-модели. Программа предоставляет пользователям доступ к новостным подкастам с их ограниченным количеством на бесплатной основе. При желании получить неограниченный доступ к материалам сервиса пользователь может оплатить подписку.

| Разработчикам | Монетизация приложения: 6 прибыльных бизнес-моделей, которые работают 35

Итог:

Эта модель позволяет пользователю опробовать программу перед оплатой.

Плюсы:

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

Минусы:

  • Эта бизнес-модель может использоваться в ограниченном количестве приложений.
  • Определить, когда и где разместить paywall, может быть довольно сложной задачей для разработчика.

Спонсорство

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

RunKeeper – отличный пример такой бизнес-модели. Здесь пользователя поощряют выполнять определенные действия (пройти сколько-то шагов или проехать определенное количество кругов не велосипеде). Рекламодатели платят пользователю, а плюс для разработчика заключается в том, что в программе нет рекламы, раздражающей пользователей.

| Разработчикам | Монетизация приложения: 6 прибыльных бизнес-моделей, которые работают 36

Итог:

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

Плюсы:

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

Минусы:

  • В силу новизны эта бизнес-модель еще не слишком тщательно проверялась разработчиками и маркетологами.
  • Требует наличия сильного специалиста по продажам в составе команды и ручного убеждения спонсоров.

Источник: habr.com

Опубликовано

Пользователи и пользовательницы: гендерный вопрос в интерфейсе

| Разработчикам | Пользователи и пользовательницы: гендерный вопрос в интерфейсе 38

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

Где проявляется пол

  • текст,
  • иконки и изображения,
  • цвета и оформление.

| Разработчикам | Пользователи и пользовательницы: гендерный вопрос в интерфейсе 39

Как делать не надо

Иконки и изображения

Любая иконка — это мем: люди понимают её смысл, потому что встречали что-то подобное в прошлом. И чем чаще мы сталкиваемся с одним и тем же символом, тем устойчивее становится ассоциация — так постепенно мемы становятся нормой.

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

Цвета и оформление

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

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

Пол по-русски

В каких случаях проявляется пол:

  • глагол в прошедшем времени единственного числа («Ты добавила это объявление в избранное»);
  • прилагательное в том числе краткое («Я согласна с условиями пользовательского соглашением»);
  • местоимение («Сегодня у Жени день рождения, отправьте ему сообщение»);
  • существительное («Ваша подруга получит 500 бонусов»);
  • косвенно («Подарите своему мужу бритву»).

Ещё один повод обращаться к пользователю на вы — не нужно спрашивать его пол или пытаться его угадать.

Что можно сделать

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

Совсем не

  • Ничего не делать: выбрать один пол и считать всех пользователей мальчиками или девочками. Иногда это может быть вполне оправданно: редакции женских журналов и создатели женских же календарей по умолчанию уверены, что их аудитория — девочки.
  • Писать варианты через дробь или в скобках: «Я ознакомлен(а) с политикой конфиденциальности».

Немного

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

Достаточно

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

Кстати, часто мужской пол пишется перед женским. Можно обращать на это внимание и писать сначала про девочек, а можно сделать ещё круче и выводить перечень в случайном порядке.

Больше двух

Строго говоря, если ваш сервис не имеет дело с паспортными или медицинскими данными пользователей, вас интересует не пол пользователя, а то, кем он себя ощущает — его гендер. И если вы думаете, что мальчиками и девочками гендерное разнообразие исчерпывается, идите на Facebook — заботливые разработчики предлагают пользователям больше 50 вариантов гендера, а заодно спрашивают о том, какое обращение они предпочитают.

Правда работает это только в английской версии — у русскоязычных пользователей варианта по-прежнему два.

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

Как правильно

  1. Помните, что женщины существуют.
  2. Не спрашивайте пол без необходимости и если спрашиваете, объясняйте, зачем вам нужно его знать.
  3. Если это не противоречит системе (например, при покупке билетов на самолёт), дайте возможность выбрать небинарный пол («другой», «небинарный»)
  4. При выборе пола выводите мужской, женский и небинарный в случайном порядке.
  5. Проверяйте формулировки: постарайтесь избегать указания на пол, спросите о нем, если это важно, или выясните из имеющихся данных.
  6. Посмотрите на изображения — не нужно обозначать мальчиков и девочек логичными, как вам кажется, цветами и усложнять иконки стереотипными деталями.

Источник: apptractor.ru

Опубликовано

Progressive Web Apps — это просто

| Разработчикам | Progressive Web Apps - это просто 41

Интерес к разработке приложений для мобильных операционных систем стабильно растёт, количество инструментов и подходов, позволяющих создавать приложения, становится всё больше. Сегодня мы расскажем вам об одном из новых подходов, а именно о Progressive Web Apps. Когда изменения происходят постепенно, шаг за шагом, порой бывает трудно заметить насколько они драматичны и всеобъемлющи. Казалось бы всего несколько лет назад web платформа проигрывала нативным приложением практически по всем фронтам, и пропасть между тем, что можно было сделать в браузере, и тем, что было доступно приложениям, загружаемым из магазинов, таких как Apple App Store или Google Play Store, была ужасающе огромной. Многое изменилось с тех пор, и web технологии на месте не стояли. Они шли по пути снятия ограничений, и то, что раньше было принципиально невозможно — работа оффлайн, фоновая синхронизация данных, push-нотификации, поддержка входа в один клик и оплата с помощью кредитных карт, Apple Pay, Google Pay и других методов, встроенная в браузер — теперь реальность. Эти функции органично дополняют основную часть платформы — HTML/CSS и JavaScript, которая в последние годы развивалась более чем активными темпами. Понятие Progressive Web Applications (далее PWA) на слуху давно. С весны 2018 года приложения этого класса поддерживаются всеми основными браузерами, однако распространенность технологий PWA, несмотря на очевидные их «плюсы», пока очень низка. Специалисты Google очень информативно и компетентно пишут о PWA, но их рекомендации полезны больше тем, кто уже знаком с предметом. Данная статья призвана показать, что Progressive Web Apps — это не сложно, и использовать эти технологии можно и нужно уже сейчас разработчикам любых сайтов.

Философия PWA

Для начала стоит заметить, что нет точного определения PWA приложения. Нельзя четко сказать, вот этот сайт PWA или нет. Это протяженная шкала, на которой могут располагаться как «хоумпейдж» второкурсника Пети, который добавил web app манифест, создающий иконку сайта на домашнем экране мобильника, так и внешне ничем не отличимый от обычного новостной сайт, только пользователи которого могут сказать, что он удивительно быстрый и удобный, а всё потому, что где-то внутри него бьется горячее сердце работника сферы услуг (service worker’a). Относительность PWA заложена в самом названии — «прогрессивное». Прогрессивный сравнительно с чем и в какой мере? Но эта относительность, на самом деле, очень хороша, потому что изучать технологии PWA и применять их в своих текущих проектах можно постепенно, без глобального ремоделинга и рефакторинга. С другой стороны, идея у PWA есть, и идея достаточно четкая и мощная. И то, как неспешно она разворачивается, вполне может свидетельствовать о масштабности последствий.

Архитектура PWA

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

| Разработчикам | Progressive Web Apps - это просто 42

Целевые показатели расшифровываются следующим образом:

  • Надежность (Reliable) — приложение загружается и показывается сразу же, вне зависимости от статуса и качества сетевого соединения.
  • Быстрота (Fast) — взаимообмен данными по сети происходит быстро, UI плавный и отзывчивый.
  • Привлекательность (Engaging) — делает для пользователя опыт работы с приложением комфортным и приятным, побуждая его захотеть пережить его снова, и снова, и снова…

С точки зрения Google, именно это отделяет сейчас по внешнему виду и ощущениями (look and feel) веб-сайты от нативных приложений. Другими словами, разработчику предлагаются инструменты (Service Worker, Push Notifications и др.) и указываются цели (сайт/приложение должен быть быстрым в загрузке, работать на слабом коннекте, не «лагать», при необходимости работать оффлайн). Насколько далеко продвинется по этому пути разработчик зависит только от него.

PWA и нативные приложения

То, что PWA внешне похожи на нативные приложения, является, скорей, косметическим решением (хотя и важным для пользователя с психологической точки зрения). А вот то, что они похожи внутренне (все основные ресурсы приложения можно хранить на клиенте, по сети будет передаваться только меняющийся контент) — это огромное достижение. Можно даже назвать это скрытой революцией. По сути, браузер используется как некая виртуальная машина, хранящая и запускающая в себе PWA приложение. Как Андроид является виртуальной машиной для андроид-приложений, так и браузер становится виртуальной машиной для PWA. Как нативное приложение обращается через файловую систему к своим ресурсам, так же и PWA обращается к своим ресурсам — пусть по HTTP, но хранящимся локально. И в кои-то веки всё это одинаково работает на всех основных браузерах и на всех основных платформах. [learn_more caption=»Google атакует iOS»] Есть мобильные приложения, которым нужно быть нативными (необходима производительность, доступ к системным ресурсам и др.), однако есть приложения, которые в своем функционале вполне реализуемы как PWA. Для них теперь:

  • Не нужно писать различные версии для Android и iOS (и Windows).
  • Не нужно регистрировать в Google Play и App Store и платить за это.
  • Открыт прямой выход на десктоп.

До нынешнего времени рынок мобильных приложений был закрыт для энтузиастов, которые могут написать полезную программу, но не могут/не хотят платить за ее размещение. И не хотят связываться с бюрократией Google и Apple по проверке приложения, после которой монопольные времена Microsoft вспоминаешь с тоской. Сейчас эти барьеры сломлены. И сломала их Google. Учитывая то, что именно она является флагманом интернет-технологий, подобный заход на территорию iOS, скорей всего, вполне продуман и просчитан. Остается ждать бума PWA. Различия PWA с нативными приложениями конечно же есть — в основном, в правах доступа к ресурсам системы, но работа в этом направлении идет даже в поле чистого HTML5, а для PWA дополнительные привилегии проблемой не будут. 

Технологии

Service Worker

Кратко рассмотрим основные движители PWA. Сердце PWA — Service Worker. Это проксирующий слой между фронтэндом и бэкэндом, находящийся в браузере. Все запросы браузера идут через него. Данное разделение на два независимых слоя позволило сделать переход обычного веб сайта в PWA максимально простым. Из хранилищ у Service Worker’a есть доступ к Cache Storage для web ресурсов, и IndexDB для данных. Но, самое главное, полная свобода для реализации бизнес логики. Можно, например, принять запрос от браузера, проверить состояние сети, взять данные из хранилища, произвести с ними операции и вернуть некий результат обратно в браузер, который будет думать, что ответ ему пришел от сервера. Или не будет — как разработчик захочет, так и сделает. Два браузерных слоя (клиентский фронтэнд и Service Worker) позволяют писать полноценные приложения. В то же время, для большинства сайтов будет достаточно кэширующей функциональности Service Worker’a, чтобы превратиться в PWA. PWA не зависит от каких-нибудь фреймворков, это чистый javascript, хотя даже специалисты зачем-то советуют использовать библиотечные генераторы кода. Service Worker прекрасно пишется руками и это нужно, чтобы хорошо понимать и контролировать логику работы твоего приложения. С программистской точки зрения Service Worker представляет собой javascript файл, подключаемый в html коде страницы. В нем разработчик определяет логику работы с приходящими из фронтэнда запросами и другую функциональность.

HTTPS

PWA требует, чтобы все ресурсы сайта передавались по HTTPS протоколу. SSL сертификат можно получить бесплатно, некоторые хостеры это делают за вас. Но критично, чтобы на сайте не было ссылок на незащищенные ресурсы — некоторые браузеры просто не будут отображать сайт в этом случае. Основная встречаемая в таких случаях проблема — картинки. Часто редакторы или комментаторы ставят в материал ссылки на картинки из интернета, иногда они автоматически туда (в материал) попадают. Необходимо картинки пересохранять или к себе, или на сервис с доступом по HTTPS.

Application Shell

App shell — это просто скелет графического интерфейса, шаблон. Для примера, возьмем средний сайт c хидером, двумя колонками и прочим. Грубо говоря, вырежем из него контент текущей страницы и всю динамическую информацию, оставшаяся статика — app shell. Суть в том, что app shell хранится на клиенте и загружается при запуске приложения, а затем уже в него грузится из сети динамическая информация. И пока она грузится, app shell должен выглядеть красиво («лоадеры» на местах и т.п.) Данную архитектуру сайта — загрузку контента и иной динамичной информации через ajax вызовы — можно продумать и реализовать на сайте заранее, тогда переход в PWA будет совсем несложным. App shell — это как оболочка нативной программы. Смотрите на свое PWA как на нативную программу и многое станет проще.

Web App manifest

JSON файл, декларативно определяющий для браузера название приложения, иконку, как будет выглядеть PWA (fullscreen, standalone и др.) и некоторые другие параметры. Позволяет «установить» PWA как отдельное приложение на домашний экран смартфона.

Push Notifications

Если посерфить интернет с Chrome DevTools, открытым на вкладке Application, то можно увидеть, как мало сайтов используют PWA технологии. А 90% тех, что используют, делают это только ради Push Notifications. Пока что это самая популярная и самая злоупотребляемая технология PWA — за последние несколько месяцев число сайтов, заходя на которые первым делом ищешь мышкой кнопку «Блокировать» на предложение получать самые свежие новости, выросло, такое ощущение, многократно. А само желание навязать свой Push становится похоже на Spam. А ведь можно же предлагать подписку на второй или третий заход пользователя на сайт, когда уже понятно, что он тут не случайно. [learn_more caption=»Рекомендации Google»] Push-уведомления должны быть:

  • Своевременными. Своевременное уведомление — это уведомление, которое появляется тогда, когда пользователи этого хотят, и когда оно им важно.
  • Точными. Точное уведомление — это уведомление, содержащее конкретную информацию, к которой можно незамедлительно обратиться.
  • Релевантными. Релевантное сообщение — это сообщение о людях или предметах, которые интересуют конкретного пользователя.[/learn_more]

Заключение

За последнее десятилетие web технологии прошли путь от стадии надежд и ожидания всеобщего доминирования Web 2.0 и HTML5, до стадии разочарования 2010-2013 годов. Но самая темная ночь бывает перед рассветом, и для web технологий в деле конкуренции с нативными приложениями таким рассветом стало движение, связанное с Progressive Web Apps. Сейчас, в 2018 году, уже все браузеры поддерживают основные PWA возможности — работу оффлайн и установку на стартовый экран на мобильных устройствах. PWA работают везде, не зависят от магазинов приложений и обеспечивают близкий к нативному user experience. По некоторым прогнозам PWA заменят 50% пользовательских приложений общего назначения. Но не надо завышенных ожиданий, можно сказать почти наверняка, что сто процентов рынка PWA не займут. Сейчас наличие PWA является конкурентным преимуществом. Например PWA Twitter’а на 65% увеличило количество просматриваемых за сессию страниц. Lancome благодаря PWA на 17% увеличили конверсию. OLX показали еще более впечатляющие результаты, и увеличили повторные визиты на 250%. И таких примеров множество. Скоро наличие PWA будет просто необходимо для любого серьезного бизнеса и его отсутствие будет восприниматься как существенный недостаток. 

Shark Develop - компания по разработке мобильных приложений для iOS и Android

О нас

Shark Develop — ваш надежный партнер в разработке мобильных приложений для iOS и Android. Мы создаем качественные приложения, которые помогут вашему бизнесу расти и привлекать новых клиентов.
Доверьтесь нам, чтобы превратить ваши идеи в реальность!

Контакты

Email: [email protected]
Тел.: +995 568 875 449

Envelope Whatsapp
Политика конфиденциальности

Shark Develop © 2013-2023