Connect with us

Разработка

7 способов избежать создания плохого мобильного приложения

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

Джей лаб

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

/

     
     

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

1) В вашем приложении должен разобраться даже дурак

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

2) Не допускайте переизбытка рекламы

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

3) Помните о своей целевой аудитории – и делайте их счастливыми

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

4) Сделайте приложение недорогим или бесплатным

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

5) Учитесь у своей аудитории

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

6) Изучите своих конкурентов

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

7) Делайте что-то одно, но делайте это лучше, чем кто-либо другой

Некоторые заказчики хотят, чтобы их мобильное приложение было мобильной версией их сайта со всеми функциональными возможностями. Это, как правило, неправильный подход – ваше приложение не может быть всем для всех. Так, например, приложение Facebook периодически откручивает некоторые функции (например, Messenger) в отдельные приложения. Сделайте себе одолжение и осознайте это как можно раньше и сосредоточьтесь на том, чтобы стать экспертом в чем-то одном.

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

Комментарии
Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Advertisement
Click to comment

You must be logged in to post a comment Login

Leave a Reply

Дизайн и прототипирование

Hyperion

Hyperion – встраиваемый в iOS-приложения плагин, помогающий контролировать верстку.

Леонид Боголюбов

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

/

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

  

 

 

Комментарии
Продолжить чтение

Новости

Интересные материалы: 07.12

Лучшие материалы о разработке и маркетинге технологических продуктов.

Леонид Боголюбов

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

/

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

Комментарии
Продолжить чтение

Программирование

Правила, которые я выработал по результатам 1000 code review

Леонид Боголюбов

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

/

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

Вот мои 3 (+1 бонус) наиболее распространенных правки, которые я делал во время code review.

Правка 1: Генерирование исключения, когда что-то идет не так

Обычно я видел такое:

List<String> getSearchResults(...) {
  try {
    List<String> results = // make REST call to search service
    return results;
  } catch (RemoteInvocationException e) {
    return Collections.emptyList();
  }
}

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

Если бы вместо этого API выбросил исключение, то наша система мониторинга немедленно подобрала бы его, обработала и мы ошибку исправили.

Во многих случаях возникает соблазн просто вернуть пустой объект после того, как вы поймали исключение. Примерами пустых объектов в Java являются Optional.empty(), нулевой или пустой список. Хорошим примером того, где это все встречается постоянно, является парсинг URL. Вместо того, чтобы возвращать null, если URL-адрес не может быть получен из строки, спросите себя: «Почему URL-адрес неправильно сформирован? Является ли это проблемой данных, которую мы должны исправить где-то выше?».

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

Правка 2: Использование наиболее конкретного типа

Это предложение в основном противоречит строгому типизированному программированию.

Слишком часто я видел код, подобный этому примеру:

void doOperation(String opType, Data data); 
// where opType is "insert", "append", or "delete", this should have clearly been an enum

String fetchWebsite(String url);
// where url is "https://google.com", this should have been an URN

String parseId(Input input);
// the return type is String but ids are actually Longs like "6345789"

Использование наиболее конкретного типа позволяет избежать целого класса ошибок и, в основном, является основной причиной выбора строго типизированного языка, такого как Java.

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

  • параметры запроса и пути в URL-адресах
  • JSON
  • Базы данных, которые не поддерживают enum
  • Плохо написанные библиотеки

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

// Step 1: Take a query param representing a company name / member id pair and parse it
// example: context=Pair(linkedin,456)
Pair<String, Long> companyMember = parseQueryParam("context");
// this should throw an exception if malformed

// Step 2: Do all the stuff in your application
// MOST if not all of your code should live in this area

// Step 3: Convert the parameter back into a String at the very end if necessary
String redirectLink = serializeQueryParam("context");

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

Правка 3: Использование Optionals вместо null

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

Вопрос на миллион долларов: какое единственное исключение имеет собственную аббревиатуру? Ответ: NPE или Null Pointer Exception. Это, безусловно, самое распространенное исключение в  Java и, конечно, ошибка, которая стоит миллион долларов.

Optional позволяет вам полностью устранить NPE. Однако его следует использовать правильно. Вот некоторые советы по работе с Optional:

  • Не надо просто называть .get () в любое время, когда вам надо использовать Optional. Вместо этого внимательно подумайте о том случае, когда Optional не представлен, и придумайте разумное значение по умолчанию.
  • Если у вас еще нет разумного значения по умолчанию, тогда такие методы, как .map () и .flatMap (), позволяют отложить это решение.
  • Если внешняя библиотека возвращает значение NULL, чтобы указать на пустой случай, сразу же оберните значение с помощью параметра Optional.ofNullable (). Поверьте мне, вы поблагодарите себя позже. Нули имеют тенденцию «всплывать» внутри программ, поэтому лучше остановить их в первоисточнике.
  • Используйте Optional как возвращаемый тип в методах. Это здорово, потому что вам не нужно будет читать javadoc, чтобы выяснить, возможно ли, чтобы значение было пустым.

Бонус: Использование Unlift методов, когда это возможно

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

// AVOID:
CompletableFuture<T> method(CompletableFuture<S> param);
// PREFER: 
T method(S param);

// AVOID:
List<T> method(List<S> param);
// PREFER:
T method(S param);

// AVOID: 
T method(A param1, B param2, Optional<C> param3);
// PREFER:
T method(A param1, B param2, C param3);
T method(A param1, B param2);
// This method is clearly doing two things, it should be two methods
// The same is true for boolean parameters

Что общего у всех этих методов? Они используют контейнерные объекты, такие как Optional, List или Task как параметры методов. Еще хуже, когда  возвращаемый тип является тем же самым (т.е. метод принимает Optional и возвращает Optional).

Почему это плохо?

  1. Promise<A> method(Promise<B> param)
    менее гибко, чем просто
  2. A method(B param)

Если у вас есть Promise <B>, вы можете использовать 1, или вы можете использовать 2 путем «подъема» функции с помощью .map. (т.е. promise.map(method)).

Однако, если у вас есть только B, вы можете легко использовать 2, но вы не можете использовать 1, что делает 2 гораздо более гибким вариантом.

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

 

Комментарии
Продолжить чтение

Новости

Интересные материалы: 06.12

Лучшие материалы о разработке и маркетинге технологических продуктов.

Леонид Боголюбов

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

/

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

Комментарии
Продолжить чтение

Наша рассылка

Каждому подписавшемуся - "1 час на UI аудит": бесплатный ускоренный курс для разработчиков веб и мобильных приложений!

Нажимая на кнопку "Подписаться" вы даете согласие на обработку персональных данных.

Популярное

X

Спасибо!

Теперь редакторы в курсе.