6 самых распространенных ошибок при разработке мобильных приложений


Содержание

10 ошибок при выборе разработчика мобильных приложений

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

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

Ошибка 1. Не интересоваться историей компании

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

Решение

Изучите сайт компании. Задавайте вопросы. Сколько компания существует на рынке? Когда она начала заниматься мобильной разработкой? Сколько проектов реализовано за последний год?

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

Ошибка 2. Искать, где подешевле

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

Решение

Выбирайте по соотношению «цена-качество». Cost-effective solutions! Опытные разработчики будут стоить денег, но полученный результат поможет вам заработать больше.

Ошибка 3. Выбирать, кто быстрее

“Приложение нужно нам вчера” – так в большинстве случаев озвучивают сроки бизнесмены при заказе мобильной разработки. Не важно кто, не важно как – важно, что успеет. Неопытные подрядчики вполне могут пообещать вам сроки в 2 раза короче, чем знающие разработчики. Всё из-за неспособности провести адекватную оценку проекта. Меньшее из зол, если это приведёт к срыву сроков. Плохо, если в итоге вы получите совсем не то, что ожидали.

Решение

Отталкивайтесь от того, насколько ваше приложение актуально для рынка. Если вам важно опередить конкурентов, начните с MVP (от англ. minimum viable product — минимально жизнеспособный продукт), выполненного с опытной компанией. Если концепция приложения не нова, уделите время, чтобы отточить функционал. Помните, любой специалист – от разработчика до тестировщика – обладает определёнными возможностями. И каждая задача ограничена минимальными сроками по времени исполнения. Это значит, что заставить программиста написать 50 строк кода в секунду вместо 5 маловероятно.

Ошибка 4. Отдавать предпочтение «местным» компаниям

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

Решение

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

Ошибка 5. Игнорировать спецификацию требований

“От идеи приложения сразу к воплощению!” – распространённое заблуждение среди заказчиков мобильных приложений. Даже замечательная идея нуждается в прояснении деталей, уточнении того, как заказчик видит конечный продукт. Иначе вы рискуете получить мобильное приложение, далёкое от вашей исходной задумки.

Решение

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

Ошибка 6. Выбирать по числу созданных приложений

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

Решение

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

Ошибка 7. Выбирать только кросс-платформенных разработчиков

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

Решение

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

Ошибка 8. Не уделять внимание технологиям, с которыми работает компания

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

Решение

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

Ошибка 9. Не знакомиться с PM

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

Решение

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

Ошибка 10. Пренебрегать тестированием

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

Решение

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

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

6 наиболее частых проблем в тестировании мобильных приложений

Продолжаем рубрику полезных переводов от Noveo Test Engineer Анастасии!

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

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

Вот 6 наиболее частых проблем, с которыми сталкиваются тестировщики мобильных приложений:

1. Многочисленные девайсы.

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

2. Сети.

Этот фактор сильно затрагивает производительность приложений, что, в свою очередь, влияет на пользовательский опыт. Скорость Wi-Fi, сила сигнала сети могут оставить неприятное послевкусие у конечного пользователя. Так как все поставщики мобильной связи поддерживают разный объем передаваемых данных, важно тестировать скорость соединения. Тестировщик мобильного приложения должен учитывать все эти факторы и убедиться, что продукт хорошо работает в разных сетях. Тестирование в реальной сети — фундаментальный опыт для проверки существующих проблем. Некоторые системы, например, pCloudy, предлагают среду для тестирования, где пользователь может проверить работу приложения в условиях разных сетей на реальном девайсе в облаке.

3. Выбор инструментов.

Тестирование — необходимый аспект жизненного цикла мобильного приложения, и для этого существуют мириады доступных инструментов: Espresso, Appium, Selenium, OpKey, Calabash, Jenkins и не только. Выбрать правильный инструмент, соответствующий требованиям разработки, — важнейшее решение. Эффективность тестирования мобильного приложения будет полностью зависеть от возможностей приложения для автоматизации тестирования.

Что нужно учесть при выборе утилиты:

  • Тип приложения: может быть нативным, гибридным или веб. Сейчас в моду вошли гибридные приложения, но инструмент должен быть достаточно полон, чтобы поддерживать и другие типы приложений.
  • Облачное тестирование: создание облака для автоматизации тестирования позволяет командам проводить тестирование с использованием любого внешнего фреймворка для создания автотестов. Кроме того, результаты тестирования могут быть доступны из любой точки мира.
  • Поддержка ОС: большинство приложений разрабатываются для iOS и Android, но список может пополняться Windows, Firefox OS и т.д. в любой момент, когда база девайсов клиента увеличивается. Таким образом, лучше выбирать утилиту, поддерживающую большее количество потенциально используемых платформ.

4. Размеры экранов.

Сегодня существует множество девайсов под Android и iOS с разными размерами экранов. Довольно сложная проблема — протестировать приложение на каждом из них. Разработчики приложений под iOS, кто ориентировался в основном на pixel perfect дизайны, теперь вынуждены уделять больше времени адаптивности, не меняя необходимые элементы на экране. Таким образом, у поставщиков приложений нет выбора, кроме как менять дизайн, чтобы пользовательский опыт был высококлассным вне зависимости от девайса.

5. Типы мобильных приложений.

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

6. Автоматизация тестирования с участием искусственного интеллекта.

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

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

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Топ 10 ошибок в разработке приложений

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

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

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

Таким образом, наша первая рекомендация — провести исследование пользователей с вашей целевой аудиторией:

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

Несмотря на конкретные проблемные отрасли у большинства юзабилити приложений, здесь описаны 10 распространенных ошибок, которые мы часто встречаем в разных отраслях. Пять из этих вопросов (№ 1, 2, 3, 4 и 6) также были включены в первоначальную статью, что показывает, каковы принципы долговременного использования. Все 10 первоначальных руководств по-прежнему верны, но 5 ошибок (к счастью) уже менее распространены и их заменили на 5 более актуальных проблем (# 5, 7, 8, 9 и 10).

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

1. Плохая обратная связь

Одним из основных принципов повышения юзабилити приложения является предоставление четкой обратной связи:

  • Показывать пользователям текущее состояние системы
  • Расскажите пользователям, как были интерпретированы их команды и действия
  • Сообщайте пользователям, что происходит

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

Хорошая обратная связь говорит пользователям многое — к примеру, кнопка, которую они кликнули правильно интерпретируются системой как «клик» и реагирует ли система? Что сейчас выбрано или активно?

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

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

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

1.a. «Выход на обед» без индикатора прогресса

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

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

  • Если команда занимает от 2 до 10 секунд, покажите анимацию ожидания, в виде спинера. Индикатор прогресса этого типа говорит пользователям «придержать своих лошадей» и не нажимать на что-либо еще, пока не вернется обычный курсор.
  • Если команда занимает более 10 секунд, установите явный индикатор выполнения, предпочтительно в виде индикатора процента выполненных работ (если вы действительно не можете предсказать, сколько понадобится времени до завершения операции)
Цукерберг рекомендует:  Карьерный путь - Как вы заняли должность Product Manager

2. Несоответствие

Помните правило двойного D: различия сложны (differences are difficult). Когда у пользователей есть ожидания относительно того, как что-то будет работать или где они могут получить доступ, отклонения от этих ожиданий вызывают путаницу, разочарование и повышенную когнитивную нагрузку, когда люди пытаются решить проблему. Человеческий разум жаждет последовательности.

Существует несколько типов несоответствий, которые особенно распространены в сложных приложениях и приводят в замешательство даже опытных пользователей:

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

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

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

3. Некачественные сообщения об ошибках

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

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

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

Набор расплывчатых сообщений «Что-то пошло не так» от Quicken (вверху слева), Dropbox (вверху справа), IBM Verse (внизу): ни одно из них не описывает суть проблемы, подробности о том, как ее решить, и была ли работа пользователя потеряна в процессе.

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

4. Отсутствие значений по умолчанию

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

  • ускорить взаимодействие, освободив пользователей от необходимости указывать значение, если значение по умолчанию приемлемо
  • научить, предоставляя пример типа ответа, который подходит для вопроса
  • направить начинающих пользователей к безопасному или общему результату, позволив им принять значение по умолчанию, если они не знают, что еще делать

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

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

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

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

5. Значки без меток

Иконки редко не чем не подкреплены, но большинство пользователей сразу же могут их понять. Даже значки, которые могут показаться универсальными (например, меню гамбургеров), не настолько знакомы пользователям, как ожидало бы большинство практиков UX. Становится намного хуже, если в вашем приложении есть уникальные значки; вероятность того, что пользователи поймут, что означают эти уникальные значки, очень мала. Помните закон Якоба: «пользователи проводят большую часть своего времени на других веб-сайтах». Это означает, что большинство значков без текстовой метки, пользователи не смогут понять.

4 преимущества сопряжений значков с текстовой меткой:

  1. Увеличивает размер значка (что, согласно Закону Фиттса, сокращает время, необходимое пользователям для доступа к элементу управления).
  2. Это сокращает время распознавания команды: две метки (значок и текст) лучше, чем одна.
  3. Относительно предыдущего, это также может облегчить изучение интерфейса (путем создания нескольких ассоциаций с одной и той же командой).
  4. Это может помочь пользователям визуально различать несколько команд, расположенных рядом друг с другом.

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

6. Трудно достичь цели

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

6а. Слабые сигнификаторы

«Доступность» означает, что вы можете сделать с объектом. Например, флажок позволяет включать и выключать, а ползунок — перемещаться вверх или вниз. Сигнификаторы — это визуальные элементы, которые помогают вам понять преимущества, просто посмотрев на объект, прежде чем вы начнете его использовать (или почувствуете, если это физическое устройство, а не элемент пользовательского интерфейса на экране). Эти концепции обсуждаются в книге Дона Нормана «Дизайн повседневных вещей».

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

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

Распространенными признаками слабых сигнификаторов являются:

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

6b. Крошечный размер цели для нажатия

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

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


7. Злоупотребление модальных окон

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

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

8. Бессмысленная информация

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

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

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

9. Меню как мусорный бак

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

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

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

Salesforce: меню «Спам» с надписью «Подробнее»

10. Близкое расположение отменяющих и подтверждающих действий

Помещение таких действий, как «Сохранить», рядом с действиями, которые уничтожают работы, как «Отмена», является обычным дизайнерским решением, которое вызывает много горя у пользователей. Хотя с логической точки зрения такое размещение часто имеет смысл (например, «Сохранить» и «Удалить» связаны с тем, что они решают судьбу элемента), но оно также позволяет легко нажимать неправильную кнопку или значок — особенно когда пользователи спешат, выполняя повторяющиеся действия. Этот тип непреднамеренной замены одного действия другим называется ошибкой.

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

Microsoft Outlook размещает кнопку «Отметить для продолжения» рядом со значками «Архивировать» и «Удалить». Эти значки служат противоположным намерениям пользователя, тем не менее, они маленькие, размещены близко друг к другу и легко ошибиться пользователям спешке.

Выводы

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

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

Топ-5 ошибок, которых нужно избегать при разработке мобильных приложений

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

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

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

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

Мы рассмотрели пять самых распространенных ошибок, которых необходимо избегать при создании мобильного приложения.

1. Приложения не удовлетворяют потребности пользователей

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

Статистика свидетельствует, что 48% пользователей отказываются от приложения из-за его плохой разработки. Как правило, существуют определенные ожидания пользователей, но пытаться реализовать их все — тщетная попытка.

Компания, разрабатывающая Android-приложения, может удовлетворить основные требования, создавая программы, ориентированные на пользователей устройств на Android.

2. Отсутствие четкой навигации

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

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

3. Чрезмерная перегруженность приложения

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

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

4. Отсутствие визуальных подсказок

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

5. Отсутствие знакомой, интуитивно понятной и интерактивной графики

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

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

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

Цукерберг рекомендует:  Json - IOS developer вакансия

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

Юрий Прудиус – о том, что может угробить ваш апп ещё до старта

IT-инструменты, которые использует Юрий Прудиус

  • Slack
  • Trello
  • Facebook

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

Юрий Прудиус, директор по развитию компании WOXAPP , специализирующейся на разработке мобильных приложений. Образование: Национальный горный университет (Днепропетровск), специальность «системный анализ и управление». Компания WOXAPP работает на рынке мобильной разработки с 2011 года, у неё открыты офисы в Москве, Киеве и Днепропетровске.

Думаете, что мобильное приложение — это быстрый и дешёвый способ получить новый канал продаж? Вы разочаруетесь. Проследите, есть ли в цепочке поиска и принятия решения о покупке товара мобильное приложение? Будет ли покупатель искать информацию о вашем товаре в App Store или Google Play?

Среднестатистический пользователь активно использует 20 приложений в месяц. Если у вас небольшой магазин или товар с частотой покупки раз год, подумайте, найдётся ли место вашему приложению? Окупится ли его создание? Сколько надо получать заявок, продаж или посещений, чтобы разработка стала рентабельной?

С другой стороны, у нас есть кейс крупного интернет-магазина, в iOS-приложении которого каждый третий посетитель делает покупку (трафик приложения — 5–7 тысяч заходов в месяц). Но эти покупатели — постоянная клиентура, которой удобнее использовать приложение, нежели сайт.

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

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

Ошибки, которые часто допускают дизайнеры, проектируя мобильное приложение:

Не соблюдают принципы построения интерфейсов для Android и требования для iOS , закладывая неправильную структуру экранов. Это делает приложение непонятным для пользователя и увеличивает срок разработки.

Применяют ненативные элементы и неуместную анимацию, что также увеличивает срок и стоимость разработки.

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

Делают навигацию через «гамбургер-меню», что влечёт за собой проблемы. Например, для iOS нативно строить архитектуру через TabBarmenu. Про «гамбургер-меню» хорошо написано на Econsultancy и TechCrunch .

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

Заказываете приложение для Android, но хотите там видеть «фишки» из iOS? Или дизайнер с айфоном считает, что так будет лучше в Android? Это проблема.

Дизайн Android отличается от дизайна iOS. Использовать элементы одной операционной системы для другой — плохая идея. Во-первых, это сбивает с толку пользователей, во-вторых – сюрприз! — увеличивает сроки и стоимость разработки проекта.

Иногда клиент приносит вместо технического задания готовый дизайн 10-12 основных экранов, считая, что остальное «и так понятно». Увы, разработчики приложений – не телепаты, и без подробного технического задания не могут сделать хороший продукт.

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

Все сценарии и состояния должны быть чётко оговорены в ТЗ и детализированы в дизайне. Каждая упущенная деталь — сценарий или состояние элемента — увеличивает срок разработки проекта.

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

Сложность состоит в том, что:

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

Например, для получения данных об одном товаре надо сделать восемь (!) запросов. Отсюда последствия: медленное получение данных — клиенты ставят «колы»; превышение лимита на сервере или любая серьёзная нагрузка — сервер лежит.

Мобильное приложение — только небольшая часть системы:

Как всегда, всё упирается в человеческий фактор. Нередко отсутствует внятная коммуникация между разработчиком приложения и ответственным за базы данных IT-отделом со стороны клиента. Если отложить вопрос синхронизации «на потом» и не сделать грамотную «клиент-серверную» архитектуру, отладка приложения может занять длительный срок — от месяца до года.

Так что заложить взаимодействие «клиент-сервер» нужно со старта. Ещё до начала мобильной разработки подготовьте ТЗ для взаимодействия «клиент-сервер». Заложите на сервере правильную архитектуру. Уточните, в каких таблицах хранить данные, структуру запросов, какие данные используются чаще других. Назначьте ответственных за реализацию работ.

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

Не стоит гнаться за всеми платформами сразу.

Как говорят военные, любая тактика хороша до реального столкновения с противником.

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

Как избежать разработки ненужных функций:

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

Тестируйте приложение на реальных пользователях как можно раньше. Опросите пользователей на стадии дизайна. Опрос можно провести среди клиентов, сотрудников вашего офиса или знакомых. Используйте A/B-тестирование страниц приложений .

О методах и инструментах продвижения задумайтесь до запуска приложения. Необходимо понимать, как привлекать пользователей и сколько это будет стоить.

Используйте доступные каналы привлечения:

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

Привлекайте посетителей с помощью рекламы: контекста (Google AdWords, «Яндекс.Директ»), рекламы в магазинах приложений, баннерной рекламы или рекламы в социальных сетях.

Используйте ASO-оптимизацию — работу с описанием, ключевыми словами, названием и визуальным оформлением.

С помощью ASO всего за два месяца мы увеличили количество посетителей страницы приложения в маркете с 49 до 173 тысяч в месяц.

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

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

Помните также, что ваши затраты не ограничатся суммой на разработку. Заложите в бюджет:

  • развитие и поддержку продукта;
  • продвижение и рекламу;
  • стоимость аренды хостинга или сервера;
  • стоимость размещения в магазинах Google Play и App Store.

Системы аналитики встраивайте в приложение ещё на этапе разработки. Начните с бесплатных систем (Google Analytics или Firebase). Рекомендуем внедрить Google ecommerce для мобильных приложений интернет-магазинов. Так вы сможете следить за поведением пользователей и опираться на полученные показатели при выпуске новой версии.

Распространенные ошибки тестирования мобильных приложений

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

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

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

  1. Чрезмерное внимание к UI/UX

Очень часто разработчики сосредотачиваются на пользовательских интерфейсах и опыте взаимодействия, и забывают о функциональных особенностях приложения. Внешний облик и UX важны, но как насчет юзабилити? Зачем кому-то скачивать ваше приложение, если в нем не все функционирует должным образом? Важно не то, как выглядит приложение, а польза, которую оно приносит. Необходим сбалансированный подход применительно к UI/UX, а также к функционалу или юзабилити приложения.

  1. Тестирование приложения без необходимых знаний

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

  1. Тестирование приложения как веб-страницы

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

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

  1. Попытка тестировать абсолютно все

На практике не представляется возможным протестировать мобильное приложение на всех девайсах и операционных системах. Однако чтобы понять, каким образом пользователи будут обращаться с приложением, важно иметь ясное представление о том, что проверяется. Google Analytics позволяет сделать определенные выводы о поведении пользователей. Допустим, что необходимо протестировать 50 возможных кейсов на 10 разных устройствах в 5 разных сетевых средах. Чтобы справиться с этой задачей, потребуется проработать бесконечное число вариантов. А это невозможно.

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

  1. Разночтения в отчетах

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

Вывод

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

Как выбрать надежного разработчика мобильных приложений?

По данным аналитиков, в Google Play более 2,8 млн. приложений, а в App Store – более 2,2 млн. и более четверти из них использовались не более одного раза. Как же выбрать исполнителя, которому можно доверить разработку качественного мобильного приложения? Вот 7 практичных советов!

#1 – Оцените релевантный опыт подрядчика.

Ознакомьтесь с портфолио подрядчика и убедитесь в том, что у него есть опыт в создании приложений для мобильных платформ iOS и Andorid, аналогичных вашему. Наличие таких – надежный показатель того, что подрядчик лучше поймет особенности вашего проекта и реализует его.

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

#2 – Лично пообщайтесь с клиентами.

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

#3 – Лично пообщайтесь с командой проекта.

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

#4 — Не гонитесь за низкой ценой.

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

#5 – Не гонитесь за минимальными сроками.


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

#6 — Отдавайте предпочтение современным технологиям.

Опытные компании идут в ногу с новинками в сфере разработки мобильных приложений и следят за тем, чтобы их специалисты регулярно прокачивали своё мастерство. Например, современные приложения для Android пишутcя на Java и Kotlin, а для iOS – на Objective-C и Swift.

#7 – Принимайте оптимальное участие в проекте.

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

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

Оптимизации ошибок при разработке мобильных приложений следует избегать

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

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

Всегда начинайте рекламировать свое приложение после его запуска

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

Это не оптимизирует App Store

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

У вас нет эксклюзивной иконки

Чтобы создать другое место в толпе, вам нужен уникальный значок для вашего приложения. Чтобы узнать больше, вы должны прочитать рекомендации Apple App Store и Google Play Store для значков приложений.

Нет анализа результатов

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

Игнорирование внешнего трафика и рекламных акций

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

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

6 распространенных ошибок при разработке логотипов

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

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

Но даже тогда логотип должен передавать идею бренда доступно, без подсказок и моментально:

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

Разработка логотипа – это сложное дело, и даже крупнейшие организации могут его провалить. В 2010 году редизайн логотипа фирмы Gap был отменен в течение недели, а недавно ребрендингу Yahoo ! был также оказан холодный прием .

Это не точная наука, в этом вопросе нужен хороший уровень креативности.

Цукерберг рекомендует:  Применяем CSS в зависимости от ориентации экрана

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

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

Ошибка №1: использование растровой графики, зависящей от разрешения

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

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

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

Кроме того, редактировать векторную графику намного легче, и зачастую проще работать с первоначальными эскизами:

Растровая (основанная на пикселях) графика против векторной.

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

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

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

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

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

Ошибка №2: следование новинкам, трендам и увлечениям

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

И хотя есть несколько впечатляющих сайтов, использующих этот подход, вы должны спросить себя: « Как долго это будет в моде? »

Логотип Skype кричит «Привет» из 2006 года!

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

Skype разработал свой логотип в разгар моды на глянцевый пластик периода web 2.0 . Будьте уверенны, такой логотип был на пике популярности в 2006 году, но с тех пор устарел, как наполовину надкушенное яблоко. Этот логотип навсегда привязан к тому периоду истории.

Другой отличный пример того, как пользователи могут негативно воспринять новый логотип, относится к случаю с Калифорнийским университетом.

Его новый минималистичный логотип вызвал протест 50 000 недовольных студентов и сторонников. Онлайн петиция (сейчас она закрыта) пыталась заставить администрацию университета прекратить использование « монограммы », несмотря на то, что логотип получил: « …похвалу от группы опытных экспертов в области дизайна, не связанных с университетом ».

Новый логотип Калифорнийского университета.

Кажется, университет должен был больше заботиться о креативности в вопросе поиска финансирования, а не в разработке логотипов, говорится в письме, написанном Гавином Ньюсомом, заместителем губернатора, президенту университета:

Первоначальный логотип Калифорнийского университета.

Многие люди, связанные с университетом, считали, что новый логотип не говорит ничего о самом учреждении. Ньюсом отметил, что многие полагали, что этот логотип « …не чтит историю и престиж Калифорнийского университета ».

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

Ошибка №3: неразумное использование шрифтов

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

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

Набрасывая первоначальные идеи, тщательно подумайте о том, что должен выражать шрифт – не словами, а чувствами.

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

При выборе шрифта подумайте о:

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

Отличным примером последнего является знаменитый логотип FedEx , в надписи которого используется отрицательное пространство для создания фигуры в виде стрелки, подсказывающей скорость и направление:

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

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

Творение Джулиан Хэнсон – это своего рода карта того, как использовать шрифты; это интересно и полезно в качестве общего руководства.

Ошибка №4: подражание успешным брендам

Хм…что-то это мне напоминает…

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

Прежде всего, что это говорит о вас как о дизайнере?

Это говорит, что у вас недостаточно креативности, и предполагает наличие определенного количества лени.

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

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

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

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

Ошибка №5: излишние усложнения

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

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

Простота играет ключевую роль по нескольким причинам, в том числе:

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

Сравнение логотипов фестивалей вина и закусок: EPCOT против Newcastle.

Давайте взглянем на два сопоставимых логотипа фестивалей вина и закусок.

EPCOT передает свою идею с помощью:

  • 2-х очень разных шрифтов;
  • 10-ти цветов;
  • 1-го логотипа с макаронами и вилкой (тоже уродливыми);
  • 1-го логотипа в виде набора палочек и чашки (я так думаю);
  • 1-го логотипа с круассаном;
  • 1-го логотипа со сливой (наверное);
  • 1-го логотипа со штопором.

И я до сих пор считаю, что все это крайне трудно разобрать в виде букв.

Newcastle рассказывает свою историю с помощью 1-го шрифта, 2-х цветов и комбинирует два визуальных образа (вилку и бутылки) в одну простую форму.

Им не нужна была целая вилка – только существенные части, чтобы сделать ее « вилкоподобной ». И мы все сразу узнаем что это.

Я думаю, что отличные логотипы – это то, что остается после того, как вы удалили все неважные элементы.

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

Ошибка №6: слишком буквальное представление

Логотип LSO символизирует дирижера с палочкой.

Касательно последнего пункта, следует помнить, что логотипы это не схемы или обучающие рисунки.

Отличные логотипы обычно намекают на тему, но нет необходимости иллюстрировать ее в точности.

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

Также как и заголовок для журнала « Families » (« Семьи ») не нуждается в тщательной иллюстрации конкретных родителей и детей, или даже человеческих лиц и тел.

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

Заголовок «Families»

Попытайтесь попасть в сущность объекта или организации. Вы можете связать образ медведя только с лапой? Или даже всего с одним когтем?

Просто. Незабываемо. Креативно.

Это, конечно, лишь немногие из тех ошибок, которые могут возникнуть при разработке логотипов.

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

Шесть самых важных моментов, которые следует учитывать при разработке логотипа, по моему мнению, это:

  1. Узнать аудиторию;
  2. Познакомиться с имиджем бренда изнутри;
  3. Получить подтверждение первоначальных идей и не позволять клиенту диктовать слишком многое (помните, что дизайнер — вы);
  4. Придерживаться простоты;
  5. Обеспечить совместимость с разного рода носителями;
  6. Сделать логотип запоминающимся.

Дизайн, в определенной степени, субъективное дело. Но проведение собственного исследования и уверенное знание того, кого представляет ваш логотип, делает дизайн менее субъективным.

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

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

Данная публикация представляет собой перевод статьи « 6 Common Mistakes in Logo Design » , подготовленной дружной командой проекта Интернет-технологии.ру

Самые частые ошибки начинающих Andro >

Android воистину фантастическая платформа для разработчика. Судите сами: исходный код android открыт, все инструменты разработки бесплатны, вы можете использовать их на любой операционной системе, Android хорошо документирован, процесс распространения и продажи приложений очень прост и хорошо описан. С момента выхода на рынок в 2008 году Android проделал большой путь. Сегодня вы можете пользоваться различными IDE для написания своих программ, но с недавнего времени единственной поддерживаемой Google средой является Android Studio, которая в свою очередь базируется на IntelliJ IDE. Android Studio делает многое для упрощения жизни разработчика, однако даже очень продвинутая IDE не способна заменить программисту голову, и в нашем коде по прежнему встречаются баги. В этой статье будут указаны наиболее характерные ошибки Android разработчиков. Конечно, наиболее часто они встречаются в коде новичков, однако и опытные программисты иногда встречаются с этими граблями.

Использование интерфейсных решений, характерных для iOS

Android и iOS активно конкурируют на рынке мобильных операционных систем. Многие разработчики пришли в Android из мира Apple. Не удивительно, что оказавшись в новой среде они пытаются использовать свой предыдущий опыт. Android и iOS имеют много общего, однако некоторые интерфейсные решения для них сильно отличается. Поэтому прежде чем начать разрабатывать Android приложения было бы неплохо ознакомиться с «Android design guidelines». Это поможет Вам понять экосистему Android, и вы не напугаете своих пользователей «нелогичным» интерфейсом.

Неиспользование интентов

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

Неиспользование fragments

В стародавние времена, еще до Honeycomb, Android приложения строились только на базе активити и сервисов. Это доставляло массу неудобств при написании программ, которые должны были работать как при альбомной, так и при книжной ориентации устройства. Ночи, проведенные за отладкой и адаптацией макетов не редко заканчивались убитыми об стену устройствами, а ремонт планшетов и телефонов не самое дешевое дело. Внесение в API концепции фрагментов существенно улучшило ситуацию. Фрагмент — это мини активити, которая может быть встроена в обычную активити. Причем можно встроить в активити сразу несколько фрагментов. Это позволяет писать более элегантный код, отрабатывающий изменение ориентации устройства.

Разработка для текущей версии Android

Пожалуй самой обсуждаемой в среде программистов проблемой Android OS является ее фрагментация. На рынке одновременно присутствует большое количество устройств, работающих под различными версиями операционной системы. Каждая версия имеет собственный API. Начинающие разработчики очень часто ориентируются на последнюю версию операционной системы, отсекая тем самым огромный кусок рынка. Опытные программисты ориентируются на более старые версии и используют для обратной совместимости «Android Support Library». На самом деле, нет никакой реальной необходимости писать под очень старые устройства. Например, ориентация на Ice Cream Sandwich позволяет покрыть 95% находящихся на рынке устройств.

Разработка для одного или двух экранов

Фрагментация проявляется и в том, что при разработке приложений программист вынужден учитывать, что его приложение будет запускаться на устройствах с различным разрешением и размером экранов. Попыткой решения этой проблемы было привязывание всех размеров к dp и sp. Тем не менее, при написании Android приложения разработчик должен постоянно переключаться между различными типами экранов, чтобы удостовериться, что его программа нормально отображается. Новички обычно забывают про это и тестируют свой софт на одном-двух телефонах. Это неправильно.

Блокирование основного (UI) потока

При запуске любого приложения Android создает поток выполнения, называемый главным потоком или UI потоком. В этом потоке обрабатываются события щелчка по экрану, рисование и обновление экрана. По умолчанию весь код выполняется именно в этом потоке. Это может вызвать проблему — если у вас выполняется какая-нибудь долгая операция внутри UI потока, то приложение будет «подвисать». Особенно это актуально для приложений, взаимодействующих с сетью. В новых версиях Android работу с сетью запрещено осуществлять из основного потока, но остается целый ряд потенциально «тяжелых» задач, которые могут подвесить ваше приложение. Примером таких задач служат загрузка изображений, чтение/запись в файл или базу данных, сложные вычисления. Выходом может стать помещение этих задач в отдельные потоки. Приведенный ниже код иллюстрирует загрузку изображения и отображение ее в ImageView. Опытные разработчики никогда не позволяют своим приложениям подвисать. Если вам не знакома эта тема, рекомендую почитать об AsyncTask и использовании ProgressBar.

Пренебрежение документацией

Android Developer website — очень хороший ресурс, содержащий массу полезной информации для Android разработчиков. Документация, уроки, спецификации, обзор лучших решений — все это можно найти на Android Developer website. Если Вы всерьез собираетесь заняться программированием под Android — этот сайт должен быть у Вас в закладках. Начинающим разработчикам можно также рекомендовать StackOverflow — online сообщество, где можно задать вопрос и получить на него квалифицированный ответ. Начинающий программист с почти стопроцентной вероятностью найдет здесь ответ на мучающий его вопрос.

Глубокая иерархия в макетах экранов

При разработке макетов экранов своих программ (layouts) начинающие разработчики почему-то полагают, что использование базовых layout структур автоматически гарантирует создание эффективных и оптимизированных макетов. На самом деле, каждый виджет и layout, добавленный в приложение увеличивает время отрисовки экрана. В частности, использование параметра layout_weight — довольно дорогое в плане затрат времени удовольствие. Гораздо эффективнее использовать RelativeLayout и выстраивать виджеты по отношению друг к другу. С другой стороны, использование вложенных друг в друга layout-ов тоже очень накладно с точки зрения расхода времени.

Неправильное использование картинок

Графика является одним из самых больших кусков современных приложений. Прежде чем попасть на экран картинка должна быть загружена в память. Новички часто сталкиваются с OutOfMemoryError, когда пытаются загрузить коллекцию изображений. Например, загрузка картинки 2448×3264 ARGB_8888 потребует 4 * 2448 * 3264 байт памяти (около 30 Мб). Если вы потом собираетесь использовать эту картинку для отображения через ImageView размером 200×200, то на самом деле вам нужно всего 4*200*200 байт (около 160Кб). Довольно расточительно тратить 32Мб, когда действительно используется только 160Кб. При загрузке изображений опытные разработчики используют Bitmap.createScaledBitmap(). Кроме того, не стоит загружать картинки в основном потоке.

Мобильное приложение не маленький проект

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

Заключение

Разработка для Android очень увлекательное занятие (или тяжелая работа, кому как нравится). Рассмотренные ошибки это лишь небольшой список граблей, которые затаились в ожидании неопытного android разработчика. Наверняка вы тоже сталкивались с ошибками, не попавшими в этот список. Поделитесь опытом.

Понравилась статья? Поделиться с друзьями:
Все языки программирования для начинающих