Помоги проекту - поделись книгой:
Мы сделали иконки на экране такими хорошенькими, что вам захочется их лизнуть.
Афоризмы – это интерфейсы, по которым передается оценка и понимание.
Непосредственная разработка мобильного приложения обычно начинается с создания интерфейса. Интерфейс пользователя (User Interface) – это все, что вы видите в своем приложении, все элементы управления приложением, а также все способы уведомления о происходящем в приложении. Некоторые могут называть интерфейс дизайном, но это неверно, так как дизайн слишком обширное понятие. А вот интерфейс – это как раз все то, что позволяет вам получать информацию из приложения и передавать ее в приложение. Сюда относятся все «кнопочки» на экране, клавиатура, голосовое управление, управление жестами, вывод информации на экран, вибрирование, звуки и голосовые уведомления.
Интерфейс – то, чем пользуется абсолютно каждый пользователь приложения. Помните, что приложение может иметь невероятный потенциал и огромные возможности, но если пользователь не разберется, как пользоваться интерфейсом, то он не будет к нему обращаться.
Многие заказчики, да и разработчики также, делают интерфейс понятным в первую очередь для самих себя. То есть оценка качества интерфейса строится исключительно на том, насколько он понятен для самого заказчика и разработчика, вообще не беря во внимание пользователей приложения. Многие считают, что, если это понятно им, значит, будет понятно кому угодно. Это совсем не так.
Нужно учитывать пользовательский опыт. Когда сотрудники компании Visualead создавали рисунки для сканирования в качестве кода, они поняли, что в обычной картинке пользователь не распознает код для сканирования, в результате чего родилась идея объединить картинку с QR-кодом. Так появился визуализированный QR-код. По-другому сделать было невозможно, ведь без QR-кода даже сам разработчик не догадается, какая картинка содержит код, а какая нет.
Прежде всего, еще на стадии проектирования, разработчики должны были понять две самые важные вещи:
1. Какую главную задачу необходимо решить с помощью приложения?
2. Для кого создается приложение?
В каждом приложении все вертится вокруг одной самой главной задачи – той, которую оно должно решать: и внешний вид, и режим управления; второстепенные задачи при этом отодвигаются на второй план. Только так можно сделать популярное приложение, выполняющее свои функции.
Часто приходится видеть разработчиков, не делающих акцент на чем-то одном, а просто сбрасывающих все возможности приложения в одну кучу. С таким подходом они не могут довести до ума ни одну функцию, постоянно доделывая все и сразу. Пользователь, запустивший такое приложение, тратит много времени и сил, чтобы понять, где находится основная функция, ради которой он его установил, что вызывает только разочарование.
Если с основной задачей обычно все понятно еще на стадии разработки технического задания, то целевую аудиторию многие понимают неправильно. В этом вопросе очень легко ошибиться, потому что понять людей сложнее всего. Вы должны быть уверены, что точно знаете, вашего идеального клиента – кто будет пользоваться мобильным приложением и в каких условиях.
Если потенциальные пользователи – это люди старшего возраста, им будет сложно делать точные движения. Обычно они плохо видят, следовательно, все должно быть несколько большего размера и учитывать ложные касания и жесты. Если пользователи молодые, значит, они отлично разбираются в мобайле и им можно немного усложнить интерфейс. Если приложением будут пользоваться в шумном месте, то звука слышно не будет. Если на улице – то все должно отлично выглядеть даже при ярком солнце.
Если не учесть такие детали, то целевая аудитория не сможет пользоваться приложением, поэтому в ИТ появилось понятие «юзабилити» – оценка удобства использования программы. Весь смысл приложения заключается в том, насколько оно удобнее, чем другой способ решения задачи. Например, если будет проще поручить дело помощнику, то вы не будете пользоваться приложением, а привлечете помощника.
Создание интерфейса начинается с разработки внешнего вида управления приложением (визуальный интерфейс), потому что большую часть времени пользователь использует именно его, и с ним всегда связаны наибольшие проблемы. Кроме того, визуальный интерфейс проще сделать в виде прототипа, чтобы протестировать и показать заказчику.
Вначале визуальный интерфейс создается в виде каркаса, без оформления (wireframes). Все, что должно быть в приложении, рисуется в виде прямоугольных областей и подписывается. Таким образом становится понятно, какие элементы и где лучше всего разместить. Это можно делать как в специальных веб-сервисах, специально для этого предназначенных, так и просто на бумаге. Существуют даже специальные трафареты для упрощения рисования элементов интерфейса. Можно использовать готовый макет смартфона и специальные листочки, на которых рисуется интерфейс, а затем вставляется в макет, чтобы лучше понять, как все будет выглядеть.
Создание визуального интерфейса начинают с первого экрана, то есть того, что увидит пользователь сразу после запуска мобильного приложения. Делайте его привлекательным и информативным. С первого взгляда он должен просто нравиться, со второго – быть понятным. В противном случае дальше первого экрана пользователь не пойдет, выйдет из приложения и удалит его. Оценка полезности приложений происходит очень быстро, иногда в течение считаных секунд.
На первом экране разместите все самое важное и полезное для пользователя. Если самое важное будет размещаться на других экранах, после нажатия нескольких кнопок, то количество пользователей, пытающихся найти то, что они ожидают получить от приложения, катастрофически уменьшится. Чем быстрее пользователь получит то, что хочет, тем большему количеству пользователей понравится ваше приложение.
Не стоит при первом запуске приложения предлагать пользователю зарегистрироваться или уходить прочь. Это очень плохая практика. Крупные и известные компании могут себе позволить так поступать, потому что, если пользователь скачивает их приложение, он точно начнет им пользоваться. Они напомнят ему об этом. Можете ли вы себе это позволить?
В Creators большинству заказчиков мы советовали сделать все возможное, чтобы пользователь мог работать с приложением без необходимости регистрироваться или хотя бы имел возможность опробовать его, а затем уже зарегистрироваться – это помогает удержать пользователей. Хотя процесс регистрации выглядит простым, на самом деле он требует от пользователя дополнительных действий. Пользователь как минимум должен заполнить два поля: имя пользователя и пароль. И тут начинаются проблемы, потому что пользователи вообще не хотят ничего делать. Они хотят получить все и сразу, ничего не заполняя, не нажимая, даже не скачивая. Также типичный пользователь очень не любит, когда от него чего-то требуют и указывают, что он должен делать и как. Он считает себя владельцем смартфона, не обязанным выполнять требования какого-то очередного приложения. При первом запуске на первом экране ваше приложение должно быть готово к использованию без необходимости дополнительных манипуляций со стороны пользователя.
Несмотря на то что важность удобства первого экрана сложно переоценить, не думайте, что только он может быть сделан на совесть, а все остальное – «как получится». Визуальный интерфейс должен быть единым для всех экранов приложения, то есть иметь одинаковое оформление и находиться в одинаковых местах экрана. Иначе при переходе на другой экран пользователю придется долго привыкать к новому размещению кнопок или внешнему виду визуального интерфейса, что мало кому понравится.
У многих заказчиков возникает желание просто натыкать больше кнопок на один экран, чтобы пользователь одновременно получил доступ ко всему и сразу. Однако это сделает приложение некрасивым и неприятным. Всегда должен быть баланс между количеством кнопок и эстетической составляющей дизайна. Также не стоит делать красивые приложения во вред удобству использования. Всегда ищите золотую середину, чтобы результат понравился пользователю во всех смыслах.
Большое количество функций всегда усложняет интерфейс приложения. Приходится либо отказываться от части функций, либо скрывать их. Минимализм и большое количество свободного пространства всегда позитивно воспринимаются пользователями в отличие от нагромождения элементов управления и перегруженности визуальной составляющей.
Лучше спрятать менее востребованные функции куда-нибудь подальше, чтобы, с одной стороны, они были, к ним можно было добраться и было понятно, где они расположены, с другой – чтобы они не мешали пользователю получить доступ к самым важным функциям приложения. С этой целью их чаще всего размещают на других экранах приложения или показывают только после определенных манипуляций. Многие даже добавляют отдельную настройку в приложение, которая включает расширенные функции приложения и делает его более сложным, а до этого показывает только необходимый минимум функций.
Прототип
Если картинка лучше тысячи слов, то прототип лучше десяти тысяч.
Определившись с размещением элементов в приложении, можно приступить к их «оживлению», сделав прототип мобильного приложения с минимумом функций и практически без оформления. На данном этапе нужно как можно быстрее сделать нечто, отдалено похожее на будущее приложение, чтобы проверить его в работе. Используются любые способы заставить работать прототип, даже в урон производительности, безопасности и правильности работы всех элементов. К примеру, проекты https://www.invisionapp.com/ и http://www.concept.ly
Прототип жизненно необходим при разработке любого приложения по нескольким причинам:
• позволяет оценить существующие идеи, а также найти новые;
• заказчик очень быстро может увидеть и опробовать свое приложение в работе;
• разработчик и заказчик лучше понимают, что необходимо сделать;
• в разы уменьшается количество доработок или переделок;
• позволяет точнее оценить количество времени на разработку приложения и стоимость работы.
Основная задача прототипа – показать, как будет выглядеть и работать приложение, чтобы можно было подробнее обсудить техническое задание и договор в целом, покритиковать первую задумку и улучшить ее. Иногда после создания первого прототипа и его обсуждения идея меняется настолько, что необходимо создавать второй прототип, чтобы обсудить все изменения. Хотя, конечно, чаще всего небольшие изменения вносятся в существующий прототип.
Вначале прототип видят только сами разработчики. Они все пробуют в работе и обсуждают. Далее показывают заказчику, и если он остается доволен результатом, то показывают целевой аудитории пользователей приложения. Важно организовать не просто просмотр прототипа, а тестирование. Продумайте этот процесс заранее, чтобы качественно проанализировать поведение пользователей, учесть все нюансы и сделать хорошее приложение.
Иногда прототип создается только в виде рабочего интерфейса, но без каких-либо функций. В других случаях добавляются самые важные функции. Все зависит от сложности задачи и договоренностей с заказчиком. Если задача сложная и незнакомая, то обычно необходимо реализовать важные функции, чтобы лучше понять, как дальше их воплотить в полноценном приложении.
Очень редко прототип создается с полностью готовым дизайном, а не в виде каркаса. Такой прототип очень удобен, потому что можно увидеть, как будет выглядеть и работать приложение. Мелкие детали дизайна обычно упускаются, также присутствуют небольшие ошибки в части оформления. Единственный недостаток такого прототипа – излишние затраты времени и денег на его изготовление, ведь после тестирования прототип будет уничтожен, так как создавался не для дальнейшего улучшения, а только чтобы опробовать приложение в работе.
Прототип запускается непосредственно на устройстве, чтобы можно было увидеть его в реальной работе.
Дизайн
Если ваша компания не заинтересована в дизайне, она бессмысленна. Все имеет форму. И если что-то имеет форму, значит, оно имеет смысл. Вы вынуждены создавать дизайн. Но дизайн – это не только форма. Дизайн – это также функциональность, себестоимость, стиль жизни и ее продолжительность.
Разобравшись со структурой интерфейса, можно приступать к разработке дизайна, то есть к внешнему оформлению мобильного приложения. Очень часто именно дизайн становится камнем преткновения между заказчиками и разработчиками. Оценить качество программного кода заказчик обычно не может, а специалистами в дизайне себя считают почти все люди. Каждый думает, что может точно оценить, чего стоит тот или иной внешний вид мобильного приложения.
В понимании заказчика, главная цель дизайна – нравиться ему. Это кажется естественным как для заказчика, так и для пользователя, и даже для разработчика. Но подход к реализации «сделайте мне красиво» у всех свой, ведь все по-разному понимают красоту. Пользователь приложения вообще не задумывается о том, насколько привлекательно выглядит приложение или какой у него должен быть дизайн. Оно ему или нравится, или нет. Разработчик одновременно оценивает красоту и удобство приложения с точки зрения пользователя, пытается не выйти за рамки требований заказчика, а также обдумывает, как можно реализовать задуманное с технической точки зрения, насколько это финансово выгодно и сколько займет времени. Другими словами, разработчик видит и тоннель, и свет в конце тоннеля, и поезд, мчащийся из него, но этого ни заказчик, ни пользователь не понимают. Каждому разработчику приходится довольно серьезно работать с заказчиком по вопросам его возражений и требований к внешнему оформлению приложения. Если у разработчика нет для этого подходящего человека, который сможет доступным и понятным языком объяснить заказчику, как лучше всего сделать дизайн приложения, то заказчик всегда будет чем-то недоволен.
Заказчику важно помнить, зачем он создает приложение и почему не делает этого сам. Ответ очевиден: приложение должно приносить прибыль и лучше, если его будут делать профессионалы с опытом работы. Помня об этом, умный заказчик не будет мешать разработчикам создавать приложение правильно, в том числе – правильно оформить его внешний вид.
Каждый дизайн должен создаваться под конкретную целевую аудиторию и конкретные задачи мобильного приложения. Нельзя делать весь дизайн или отдельные его элементы только с целью сделать его красивым. Дизайн приложения – это неотъемлемая составляющая всего приложения, и если вы сделаете что-то красиво, но в ущерб функциональной составляющей или удобству использования, это негативно отразится на приложении.
Оценивайте внешний вид приложения, учитывая его влияние на приложение в целом. Если, увеличивая эстетическую составляющую дизайна, вы тем самым уменьшаете удобство пользования приложением, то, с точки зрения пользователя, приложение будет более сложным. Сложное приложение отталкивает пользователей, несмотря на всю его красоту.
Понять, как должно выглядеть ваше приложение, вам поможет анализ приложений конкурентов. Изучите все, что сделали они, попытайтесь понять, чем они аргументировали свои решения, к примеру, что заставило их выбрать именно такой цвет, именно такие иконки, именно такое оформление кнопок. Поймите это, а потом сделайте свое приложение лучше.
Анализ приложений конкурентов покажет, что во многих из них оформление некоторых частей абсолютно однотипно. Дело не в том, что конкуренты копируют друг друга. Причина похожести элементов приложения заключается в том, что так делать лучше всего, и разработчики едины в своем мнении. Приложения так же похожи, как автомобили, имеющие четыре колеса, двери, руль – все потому, что это оптимальный вариант как с точки зрения создателя автомобиля, так и потребителя. Не нужно придумывать что-то, чтобы кардинально отличаться от остальных, потому что в таком случае потребитель вас не поймет и не станет пользоваться этими «инновациями».
Если мобильное приложение принадлежит вашей компании, его можно создать в ее фирменном стиле. Однако его придется адаптировать под требования мобильных приложений. Дело в том, что большинство компаний имеют фирменный стиль, созданный под веб-сайт и полиграфию. Используя его без изменений, на выходе вы получите уродливое или красивое, но неудобное приложение. Дизайн для каждой сферы деятельности отличается, потому что невозможно сделать оформление на маленьком экране точь-в-точь как на листе А4.
Если собственного фирменного стиля у вас еще нет, то рекомендую вначале сделать его, а затем уже приступать к дизайну приложения. Часто приходится видеть, что у компаний униформа одного цвета и стиля, сайт другого, приложение третьего и все эти цвета и оформление совершенно разные, по ним никак не догадаешься, что это одна и та же компания. А ведь клиенты, однажды получившие позитивный опыт сотрудничества с вашей компанией, зайдя в магазин приложений и увидев знакомый стиль, с большей охотой скачают ваше приложение, потому что уже сталкивались с вашей продукцией и остались довольны. Я уже не говорю об эстетической стороне вопроса: для нашего мозга удобнее и красивее то, что привычнее.
Дизайн лучше всего начинать с создания иконки. Она так же важна, как и название, потому что показывается в магазине приложений и на самом устройстве. Перед разработкой ознакомьтесь с материалами для дизайнеров с официального сайта Material Design[35] для Android и с Руководством по iOS Human Interface[36].
Иконка запуска приложения в магазине приложений должна отличаться от иконок приложений-конкурентов – это выделит ее на их фоне и увеличит количество загрузок. Она должна отличаться от стандартных приложений, установленных целевой аудиторией, чтобы привлекать больше внимание пользователя – так он будет чаще запускать приложение. Кроме этого, иконка должна быть создана в соответствии с требованиями разработчика и операционной системы, для которой она создается.
Делайте иконку максимально просто. Желательно, чтобы изображение объясняло главную функцию приложения (к примеру, телефонная трубка говорит о том, что перед нами мессенджер, а ноты – что перед нами плеер). Посмотрите, как сделали конкуренты, они ведь первым делом тоже попытаются использовать для иконки интуитивно понятное изображение, а повторяться нельзя.
Помните о размере: иконка очень маленькая, и в дизайне изначально должно это учитываться. Проблема с иконкой похожа на проблему с названием – нужен маленький размер. У иконки много схожего и с логотипом, но не стоит использовать логотип вашей компании, если она не такая же известная, как Apple. Ваш логотип в виде иконки скорее всего не только не сможет сказать ничего полезного о приложении, но и будет непривлекательно смотреться на экране смартфонов из-за их небольшого размера. Если уж вы решили во что бы то ни стало использовать существующий логотип, то переделайте его специально под мобильное устройство.
Разобравшись с иконкой можно приступить к выбору цветовой палитры приложения. Цветовая палитра – это набор цветов и их оттенков, которые гармонично сочетаются между собой. В интернете есть большое количество уже готовых цветовых палитр, подобранных другими людьми. Каждый цвет по-своему влияет на человека, и порой влияние сочетания цветов очень сложно предсказать.
Лучше делать приложение в цветах вашего фирменного стиля, уже знакомого потребителю. Есть и другой подход – выбор цветовой палитры на основе тех цветов, которые больше всего ассоциируется с вашим видом деятельности или полностью ему противоположны. К примеру, если ваша сфера деятельности – производство мебели, то вашей цветовой гаммой будет коричневый цвет и его оттенки, а полностью ему противоположный – синий цвет. Используйте только один подход к выбору цвета, то есть или только те цвета, которые ассоциируются с вашей деятельностью, или только те, которые противоположны вашей деятельности. Если смешать оба подхода, результат будет непредвиденным.
Ограничьте количество цветов. Все цвета радуги хороши только на небе, в приложении лучше использовать не более трех-четырех цветов. Если цветов будет много, это усложнит восприятие приложения, что негативно скажется на удобстве его использования.
После выбора цвета пора переходить к типографике, то есть выбору шрифтов для приложения и их оформлению. В первую очередь обратите внимание на размер текста: он должен быть комфортным для чтения даже на небольших экранах. Часто пытаются разместить как можно больше информации, ради чего уменьшают размер текста так, что даже человек с хорошим зрением ничего не видит. А теперь представьте, как читать тому, у кого есть проблемы со зрением, при плохом освещении, в транспорте и других не особо комфортных условиях. Мелкий шрифт не добавляет приложению пользователей.
Второй фактор, влияющий на читабельность, – контраст цвета текста и фона. Цвет текста должен сильно отличаться от фона текста. Если будете использовать похожие цвета, текст станет трудночитаемым. При выборе шрифта обращайте внимание на его вид на маленьких и больших экранах. Есть шрифты, отлично выглядящие на больших экранах и плохо – на маленьких.
Дизайн для каждой операционной системы должен быть уникальным и делаться специально под платформу. Это связано с разным подходом к оформлению на разных платформах и разными привычками пользователей. Можете не беспокоиться о том, что у кого-то будет два смартфона с разными платформами – это редкость, но если это случится, то пользователь, привыкший ими пользоваться, не будет испытывать от этого дискомфорт.
Когда разработчик покажет вам дизайн приложения, естественно, что вам нужно видеть его на самом устройстве. Никогда не соглашайтесь на просмотр дизайна в виде картинки – так вы не поймете, на что смотрите. Рекомендую смотреть дизайн на реальном смартфоне, с реальным контентом, чтобы все было предельно понятно. Только реальный контент, который будет использоваться в приложении, даст вам возможность увидеть, насколько хорош или плох дизайн вашего будущего приложения.
Программирование
Большинство хороших программистов делают свою работу не потому, что ожидают оплаты или признания, а потому, что получают удовольствие от программирования.
После создания дизайна у вас будет все необходимое для добавления функций в приложение. Все, что умеет делать приложение, реализуется с помощью программирования, то есть написания кода программы на одном из языков программирования.
При разработке мобильных приложений чаще всего используется только несколько языков программирования. Важно определиться, на каком языке лучше всего писать код, ведь от этого будет зависеть как производительность, так и возможность реализовать поставленные задачи. Если приложение создается на основе языков веб-программирования, то на выходе вы получите веб-приложение. Если будут использованы другие языки, то вы получите нативное приложение. Каждая операционная система имеет рекомендуемые языки для создания нативных приложений: для Андроид – это Java, а для iOS – ObjectiveC и Swift.
Многие разработчики советуют использовать веб-приложения. Они работают на принципах клиент-серверной архитектуры и запускаются через веб-браузер. На самом устройстве запускается небольшое приложение, которое отправляет всю информацию на сервер, а тот занимается обработкой информации. Единственный плюс таких приложений – простота и дешевизна создания каждой платформы. Одним из основных недостатков является невозможность использовать все возможности, предоставляемые операционной системой и аппаратной частью мобильного устройства. Еще один минус – для обмена информацией между клиентом и сервером необходим постоянный доступ или в локальную сеть, или в интернет. Еще один существенный недостаток – сложность реализации безопасного обмена информацией между клиентом и сервером (это требует реализации дополнительных инструментов, и не каждый разработчик это умеет делать).
Лучший выбор, по моему мнению, – создание нативного приложения, которое разрабатывается специально под конкретную операционную систему. У нативных приложений огромное количество преимуществ:
• Удобный процесс установки через магазин приложений.
• Быстрый запуск приложения и быстрая обработка информации.
• Меньшее потребление оперативной памяти устройства.
• Высокая энергоэффективность.
• Возможность полноценной работы без доступа к локальной сети и интернета.
• Использование всех возможностей операционной системы.
• Интеграция с другими нативными приложениями.
• Доступ ко всем возможностям аппаратной части устройства.
• Нативный и удобный интерфейс, интегрирующийся в операционную систему мобильного устройства.
Единственный недостаток нативных приложений – необходимость более высокой квалификации разработчика. Если разработчик начинает выдумывать недостатки нативных приложений, это означает только одно: он не способен их создавать.
Каждое приложение можно написать по-разному, используя для этого разные инструкции и получая при этом одинаковый результат. Опытные программисты пишут меньше кода и знают, что необходимо сделать, чтобы ускорить обработку инструкций. Неопытные пишут «лишь бы работало» и часто оставляют ошибки в коде. У опытных программистов легко читаемый код, что позволяет быстро понять его другому программисту, а также самому разработчику через несколько лет, а неопытные через некоторое время сами не могут разобрать, что написали.
Ошибки программиста именуют «багами». Каждая такая ошибка может привести к абсолютно непредсказуемым последствиям. К примеру, вместо того чтобы записать информацию, баг может привести к потере новой информации, а также удалению той информации, что сохранялась ранее. Самые худшие баги – это баги, связанные с безопасностью приложения, из-за которых его легко взломать, получив несанкционированный доступ к его содержимому и даже содержимому мобильного устройства. Баги не так просто найти, так как они проявляются только при сочетании определенных условий. Долгое время вы можете о них даже не подозревать.
Как говорит Джанел Гарвин, директор Evans Data: «
Единственное, что сразу может оценить любой заказчик, – оформление исходного кода приложения. Опытные программисты всегда сохраняют определенный стиль на протяжении всего кода. Например, отступы у них одинакового размера, а сам код выглядит аккуратно отформатированным. Также изредка у них встречаются комментарии к коду, написанные на русском или английском языках.
Первая версия приложения и его тестирование
Если тестирование (также известное как контроль качества) рассматривать как нечто, обеспечивающее поддержку программного проекта, оно должно служить цели получения прибыли.
После того как будет создан почти весь необходимый функционал, на свет появляется альфа-версия мобильного приложения (первая версия). Это работающее приложение, имеющее множество багов, а также недоделанные мелочи в дизайне и функционале. Заказчику лучше такое приложение не видеть, чтобы не разочароваться раньше времени.
Где-то на этом этапе разработчики добавляют эффекты, звуки, анимацию и локализацию. Немного остановлюсь на украшательствах. Каждый эффект, добавленный в приложение, делает его более ресурсоемким и может усложнить использование. Никогда не добавляйте что-то только ради красоты и чтобы «выглядело круто». Эффекты добавляются для решения конкретных задач пользователя, никак иначе. К примеру, эффекты анимации. Если добавляется анимация выдвижения, то она должна появляться и убираться в характерную для нее сторону: вправо, если хотим увидеть, что будет далее или влево, если хотим увидеть, что было ранее. Обратная анимация желательна в ту же сторону, откуда что-то появилось на экране.
Анимация необходима: только так пользователь может понять, что в приложении что-то произошло, например, после его действия. В противном случае будет непонятно, откуда взялось новое окошко. Когда оно появится без предупреждения, это будет как если в нашем физическом мире прямо перед вами из ниоткуда возникнет попугай. От такого можно и со стула грохнуться. А вот если вы увидите, как попугай залетел в окно, это не вызовет у вас неприятных эмоций из-за неожиданности его появления и отсутствия взаимосвязи между тем, что вы видели за секунду до его появления. Также попугай должен улететь с эффектом анимации, то есть постепенно удалиться от вас, а не просто исчезнуть. Анимация помогает пользователю понимать, что приложение работает, а не зависло или «заглючило». Кстати, анимировать можно что угодно, главное, чтобы анимация не просто «делала красиво», а добавляла смысл и помогала пользователю. По своей сути анимация имитирует материальный мир с последовательностью происходящего и законами физики.
Бета-версия выпускается вслед за альфа-версией и содержит небольшое количество ошибок. Все критические ошибки были исправлены в альфа-версии, и теперь приложение стабильно работает, но изредка «глючит». Такое приложение уже можно увидеть и опробовать в работе как заказчику, так и потребителям. С появлением бета-версии начинается активное тестирование приложения. Для этого есть специалисты – тестировщики, основная работа которых – выявление и документирование ошибок.
Такие сервисы, как AppsFlyer, App Annie, Tune, AppMetrika, дают возможность тестировать приложения без их загрузки в магазине приложений.
Довольно часто можно увидеть, как кто-то запускает в массы бета-версию приложения, чтобы ускорить выявление ошибок за счет пользователей. Иногда приложение делают доступным только для ограниченного числа знакомых, которым доверяют. Поступив так, вы можете быть уверены, что ваши пользователи не разочаруются в приложении со множеством мелких ошибок, так как основные ошибки исправятся до выхода программы на публику.
Если выпустите приложение с большим количеством ошибок или с несколькими, но критическими, вам гарантированы плохие отзывы о приложении и его проблемный запуск в массы. Многие пользователи настолько сильно разочаровываются, что навсегда перестают пользоваться не только приложением, но и услугами вашей компании. Ошибки есть почти в каждом приложении, даже в том, которое было тщательно протестировано, поэтому ваша задача состоит не в том, чтобы полностью их исключить, а в том, чтобы свести их к минимуму и сделать так, чтобы большинство пользователей на большинстве устройств не сталкивались с ними. Те несколько пользователей, у которых возникнут ошибки, не сделают погоды.
Проблема тестирования заключается в том, что разработчику необходимо опробовать приложение в самых разных условиях при выполнении приложением всех функций. Необходима команда опытных тестировщиков (один человек не справится) и много устройств от разных производителей, с разными экранами и разными версиями операционной системы. Обычным фрилансерам и командам, состоящим из нескольких человек, такое тестирование недоступно. Максимум, что вы можете от них ожидать, это установку приложения на несколько мобильных устройств и беглый осмотр их работы. Поэтому приложения, выпущенные ими, всегда содержат большое количество ошибок, проявляющихся в самых неожиданных ситуациях. Необходимость качественного тестирования – одна из причин, по которой я советую заказывать разработку мобильного приложения в компании, имеющей в штате тестировщиков.
Опробование приложения в работе – единственный способ, доступный заказчику для проверки качества созданного приложения. Хоть это и не полноценное тестирование, но поможет вам убедиться в качестве приложения. Итак, вот на что вы должны обратить внимание:
1. Скорость загрузки приложения: если после нажатия прошло несколько секунд, а результата нет, значит необходимо оптимизировать приложение.
2. После запуска внимательно осмотрите все, что увидите. Особенно изучите мелкие элементы интерфейса, края и углы. Все должно быть выровнено по одинаковым правилам. Например, если есть список похожих элементов, то они должны быть выровнены по одному и тому же краю и на одном и том же расстоянии. Текст должен быть достаточного размера, чтобы его можно было прочитать даже с расстояния и когда вы держите смартфон не прямо перед собой. Изучите правильность используемых названий в тексте и поищите «очепятки». Проверьте работу полей ввода: напечатайте в них неправильные надписи, чтобы посмотреть, как поведет себя приложение.
3. Опробуйте интерфейс в работе, нажимая на все подряд, а также используя несколько нажатий одновременно и много последовательных нажатий. Попробуйте нажимать на края элементов интерфейса: приложение должно распознавать, когда вы хотели нажать на клавишу, но промахнулись, и когда было ложное и случайное нажатие рядом. Опробуйте приложение в портретном режиме: несколько раз покрутите мобильное устройство в руках, чтобы посмотреть, нормально ли оно переключается в портретный режим и обратно.
4. Посмотрите на реакцию приложения при получении телефонного вызова, прихода СМС или другого уведомления. Проверьте, сохраняется ли введенная информация при звонке.
5. Если приложение использует сеть или интернет, проверьте, как оно работает при плохой связи и после обрыва связи.
6. Проверьте энергопотребление приложения. Используйте его как можно дольше, затем запустите приложение и выключите экран мобильного устройства, потом зайдите в настройки и проверьте: не слишком ли много энергии потребляет приложение.
Вынужден предупредить, что вы можете опробовать приложение в работе, но не можете проверить его на уязвимости, то есть безопасность. Что делать? Доверять обещаниям разработчика, что приложение не имеет ошибок, влияющих на безопасность, не стоит. У вас есть два варианта.
Первый вариант – вы нанимаете специальную компанию, и она проводит тестирование приложения и ищет ошибки в безопасности. Это довольно дорого, сложно найти ответственную компанию, а при частом обновлении приложения вам это придется делать регулярно.
Поделиться книгой: