Интерфейс приложения: что это такое, основные принципы разработки интерфейса mobile app

что это такое, основные принципы разработки интерфейса mobile app

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

Содержание

Что такое интерфейс приложения?

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

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

Как спроектировать интерфейс мобильного приложения?

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

Понимание пользователей

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

Ориентация на поведенческие шаблоны, привычки и неписанные стандарты

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

Использование итеративного подхода

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

Принципы разработки интерфейса мобильного веб приложения

• Приложение должно быть уникальным и выделяться среди конкурентов;
• энергосбережение, легкость в управлении, сохранение действий – все это показывает заботу о пользователе;
• учет пользовательского опыта, расположение элементов на удобном уровне, к примеру, кнопки «удалить» и «редактировать» должны быть на таком расстоянии, чтобы не задеть случайно одну из них;
• проработка отклика, пользователь должен понимать, что его запрос выполняется, происходят какие-то действия;
• легкий ввод текста с учетом особенностей мобильной клавиатуры;
• заметная и привлекательная иконка;


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

Интерфейс мобильного приложения: основные требования

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

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

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

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

Создание концепции

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

Брейнсторминг и эскизы

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

Диаграмма переходов

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

Выбор стиля интерфейса

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

Проектирование интерфейсов: техническое задание

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

Прототипирование, дизайн и их демонстрация

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

Доработка выбранного концепта дизайна интерфейсов приложений

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

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

Интерфейс приложений: 3 критерия оценки

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

1. Оптимизация времени. Важно, сколько пользователь проводит времени, чтобы найти нужную информацию или функцию. Есть мнение, что он должен найти подходящую информацию в 3 клика. На самом деле, куда важнее оптимизировать интерфейс и сделать его понятным, навигация должна быть легкой и доступной.
2. Эмоциональная связь. Пользователь, проводя время в приложении, должен получать удовольствие от происходящего. Положительные цвета, доброжелательные формы, интерактивность и втягивание внимания пользователя помогут сделать интерфейс мобильного приложения дружественным и интересным.
3. Уровень интуитивности. Представьте, что вы впервые вошли в приложение. Насколько оно вам понятно? Можно ли разобраться в функционале, не открывая видео уроки на Ютубе?

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

5 правил для создания интерфейса приложений

1. Думать как пользователь

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

2. Ничего лишнего

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

3. Контекст использования важен!

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

4. Все взаимосвязанные элементы логически соединены

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

5. Иерархия по важности

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

Интерфейс приложений от компании Wezom

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

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

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

Вывод

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

MOBILE-Разработка

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

ЗАКАЗАТЬ MOBILE РАЗРАБОТКУ

Основные критерии интерфейса мобильного приложения

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

Итак. Главное правило, которое мы усвоили — не нужно взрывать мозг пользователя!
А теперь подробнее.
Мы расположили 5 правил по убыванию значимости, то есть работает всегда предыдущее правило, если следующее ему противоречит в конкретных проектах.

1. Думайте как пользователь

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

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

2. Ничего лишнего

По последним исследованиям человек может без стресса воспринимать только 3-5 объектов сразу. Видели светофор? Очень удобная штука, которая помогает нам безопасно передвигаться по городу. А теперь представьте, что в светофоре не 3 цвета, а десять, каждый из которых что-то означает. Или представьте, что вы ведете автомобиль, и перед вами вырастает десять дорожных знаков. Скорее всего, ваш мозг закипит. При создании интерфейса приложения это правило тоже действует, правда, с поправками. Нужно сокращать количество элементов до минимума пока это возможно, но не в ущерб задачам, которые решает пользователь.

3. Контекст использования тоже важен

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

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

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

4. Все взаимосвязанные элементы логически соединены

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

5. Иерархия по важности

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

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

Резюмируем:

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

этапы проектирования макетов с примерами

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

Содержание

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

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

О чем же следует помнить при разработке интерфейса мобильного приложения? 

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

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

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

4. 
   Ориентация страницы. Большую часть времени (около 94%) пользователь держит устройство вертикально. И тем не менее, важно продумать, как будет выглядеть интерфейс при повороте телефона в горизонтальную позицию — это не должно повлиять на удобство.

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

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

Этапы разработки mobile design

Существуют два основных этапа работы над дизайном:

1. 
   UX, или User experience — это разработка алгоритма, понимание того, как пользователь будет взаимодействовать с приложением. Иными словами, это некий каркас, архитектура ресурса.

2. 
   UI, или User Interface Design. UI дизайн определяет внешний вид, удобство и эстетику интерфейса. 

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

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

Создание концепции

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

• 
  качественные (интервью, фокус-группы, экспертное мнение) — отвечают на вопросы «как» и «почему»;

• 
  количественные (анкетирование, опрос, телефонное интервью) — отвечают на вопросы «сколько» и «как часто».

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

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

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

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

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

Мозговой штурм

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

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

Создание User Flow Diagram: пример блок-схемы

Разработка интерфейса мобильного приложения — это хорошо, но без представления, как им будут пользоваться, дальше продвинуться не получится. И тут на помощь приходит создание User Flow Diagram.

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

Согласование структуры интерфейса и переходов

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

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

Определение внешнего вида интерфейса и утверждение стиля

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

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

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

Демонстрация проекта: макеты, прототипирование и другие варианты

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

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

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

• 
  Кликабельный прототип. Это наиболее близкий к реальности прототип мобильного приложения. Здесь можно нажимать кнопки, переходить по ветке меню и делать почти все из того, что будет доступно реальному пользователю. Один из самых наглядных вариантов демонстрации разработки приложения, на создание которого уходит довольно много времени и ресурсов. Для работы часто используют InVision, нередко ее дополняет Craft. 

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

Утверждение дизайна приложения

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

IOS против Android — две глобальные операционные mobile системы

На сегодняшний день 98% рынка поделили между собой IOS от Apple и Android от Google, поэтому все популярные мобильные приложения разрабатываются под одну из этих операционных систем. Для того чтобы улучшить пользовательский опыт, каждый из гигантов IT-индустрии выпустил рекомендации по дизайну, разработке и проектированию приложений:

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

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

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

О том, как создавать приложения для разных операционных систем, мы писали в статьях «Дизайн приложений для IOS» и «Дизайн приложений для android».

Советы начинающему дизайнеру мобильных приложений

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

Работа с заказчиком

Хороший дизайнер всегда открыт к диалогу и слушает пожелания заказчика на всех этапах разработки. Даже если идея клиента кажется не самой удачной, стоит дослушать его до конца и предложить свои варианты с учетом запросов заказчика. Мнение и представление о mobile design у клиента и дизайнера могут отличаться, и очень важно донести свои предложения аргументировано, а также понять, что именно в итоге хочет получить клиент. Стоит брать во внимание, что на сам проект влияет сразу несколько факторов:

• 
  сроки выполнения заказа;

• 
  бюджет, который заказчик закладывает в проектирование;

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

• 
  технологии выполнения.. 

Взаимодействие с разработчиками

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

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

Процесс проектирования мобильного приложения

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

• 
  упрощает сам процесс создания интерфейса;

• 
  упрощает пользование приложением на всех уровнях, так как элементы, скорее всего, уже знакомы потребителю;

• 
  дизайн будет выглядеть более гармонично.

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

Использование UI Kit с самого начала работы над проектом

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

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

• 
  вносить необходимые изменения по мере работы легко;

• 
  дизайнеру в процессе работы все реже приходится отрисовывать что-то с нуля;

• 
  качественный UI Kit – находка для разработчиков: они пишут коды по тем же принципам, поэтому свободно смогут вносить изменения;

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

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

наши ошибки и 16 советов как их не повторить / Блог компании Topic / Хабр

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

Topic

и пощелкать его прямо при мне.

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

Изображение №1: поиск игр (Find a game в меню приложения)

Самое главное, для чего нужен Topic — это найти подходящую игру. При этом, основными критериями для игроков являются:

— Расположение площадки для игры

— Время игры (день недели и период времени)

— Уровень игры

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

Отсюда выводы:

1. Используйте привычные для пользователя элементы UI

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

2. Старайтесь снизить «шумность» интерфейса

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

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

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

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

4. Старайтесь выводить данные в формате, который проще для восприятия

Если цена ровная, без центов/копеек, то 00 центов выводить не надо. Если игра сегодня или завтра, то надо так и написать, не заставляя пользователя вспоминать какое сегодня число и день недели.

5. Не заводите пользователя в тупик нулевым результатом выдачи

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

Изображение №2: поиск игр, ничего не найдено (выставьте в настройках фильтрации приложения все диапазоны от 0 до 0)

6. Мягко подталкивайте пользователя к нужным вам действиям: If You Don’T Ask, You Don’T Get

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

Проблема, которую пока не удалось решить — список игр не дает наглядного представления о расположении игры на карте. Но карта не дает наглядного представления о других параметрах игр, например, дате и времени. Возможно, экраном по умолчанию должен быть не список игр с фотографиями (List), а карта с маркерами (Map). Буду рад услышать ваш совет.

Изображение №3: поиск игр (пролистать в самый конец ленту поиска игр)

7. Используйте вводные экраны: минимум текста, максимум наглядности

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

Изображение №4: вводные экраны при первом запуске приложения

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

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

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

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

9. Упрощайте ввод и выбор опций

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

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

Изображение №5: Выбор любимых видов спорта (четвертый вводный экран при первом старте приложения)

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

10. Запрашивайте права только перед тем, как они понадобятся

Изображение №6: Запрос прав на отправку push-уведомлений (после первой отправки сообщения кому-либо или после отправки запроса на участие в игре с необходимостью подтверждения записи организатором)

11. Прозрачно доносите, что пользователь получит, дав права

12. Показывайте диалоговое окно iOs только тогда, когда пользователь явно проявляет свое намерение дать права. Давайте пользователю выбор


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

Изображение №7: Пред-запрос прав на определение местоположения пользователя (третий вводный экран при первом запуске приложения)

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

Изображение №8: Если запрос прав на на отправку push-уведомлений уже был отклонен пользователем, но пользователь на экране изображения №6 нажал на «Notify me»

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

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

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

Изображение №9: Предложение найти зарегистрированных на Топике друзей (появляется на второй день использования приложения)

15. Делайте заметнее данные, которые влияют на совершение пользователем желательных действий

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

Изображение №10: Страница игры (Клик по любой игре в разделе Find a game)

Реквестирую совет хабравчан: возникла проблема, как дать пользователю возможность поменять список “My activities”, который он вводит при первом запуске приложения. Если он зарегистрированный, то все не так плохо, виды спорта редактируются в профайле. Хоть это и не такой уж очевидный путь, как хотелось бы.

Если незарегистрированный, то все еще сложнее. Возможно, стоит вывести в списке отдельный контрол для редактирования “My activities”. Если пользователь не зарегистрирован, то просить его зарегистрироваться для редактирования. Если зарегистрирован, то отправляем в редактирование профайла. Буду рад услышать ваш совет.

Изображение №11: Фильтр игр (Клик по соответствующей кнопке в разделе Find a game)

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

Для основной части пользователей создание игры и добавление площадки не так важно,

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

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

Изображение №12: Меню (клик по иконке в левом верхнем углу)

Ну и напоследок доработанная страница регистрации/авторизации:

Изображение №13: Страница авторизации (клик по ссылке «Sign in» в меню)

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

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

Советы по созданию интерфейсов мобильных приложений

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

1. Правила интерактивного дизайна применимы всегда

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

Некоторые эксперты выделяют 5 основных принципов интерактивного дизайна:

• Дизайн, ориентированный на потребителя. Дизайн разрабатывается для конкретных пользователей. Исследования целевой группы, опросы и интервью позволят нарисовать точный портрет потребителя, составить представление о тех, кто вероятнее всего будет пользоваться разработкой. Ориентируясь на эти данные, можно создать функционал приложения, исходя из интересов и потребностей конечного пользователя.
• Юзабилити. Это представляется самоочевидным, но не будет лишним напомнить, что приложение в первую очередь должно быть удобным. Если целевая аудитория не может без каких-либо сложностей пользоваться приложением, тогда люди попросту не будут его загружать из App Store.
• Подсказки. Пример: синий подчеркнутый текст является свидетельством того, что за кликом по нему последует перенаправление в другое место. Подсказки стоит применять корректным образом, чтобы пользователям не приходилось задумываться о том, зачем, собственно, нужен определенный элемент.
• Легкость освоения. Для того, чтобы интерфейс был интуитивно понятен, при разработке простых мобильных приложений лучше использовать привычные модели функционирования (об этом речь пойдет позже). Знакомые элементы позволяют быстрее освоить приложение.
• Фидбек и время реакции. Элемент обратной связи — это возможность узнать, была ли задача выполнена или нет. Им может быть простейший звуковой сигнал или же более сложная деталь, такая как диалоговое окно. Стоит перепроверить, что фидбек реализован должным образом, а время реакции не выходит за рамки, очерченные исследователями Nielsen Norman Group.

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

2. Сведения о пользователях

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

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

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

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

3. Контент и пользовательский маршрут как отправные точки UX-дизайна

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

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

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

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

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

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

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

Как описывается в бесплатной книге Mobile UI Design Patterns, существуют две категории моделей интерактивного дизайна, которые следует непременно применять.

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

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

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

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

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

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

5. Дизайн для толстых пальцев

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

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

• Люди держат свои телефоны и управляют ими по-разному. Некоторые аналитики выделяют три основных способа: в одной руке и одним пальцем, двумя руками и одним пальцем, двумя руками и двумя пальцами. Планшеты пользователи тоже держат по-разному.
• Согласно исследованию MIT Touch Lab, ширина среднестатистического указательного пальца составляет 1.6-2 см, или 45-57 пикселей, что больше тех данных, которые сообщаются в большинстве пособий. К примеру, Apple рекомендует придерживаться 44 пикселей, однако это не всегда уместно. Если кнопка слишком большая, пользователи могут и не понять, что это кнопка действия. Но, как бы то ни было, следует принимать в расчет размеры пальцев и способы взаимодействия с приложением.

6. Тренды веб-дизайна: градиенты и тени пока еще рано списывать со счетов          

Эти элементы возвращаются, достаточно взглянуть на экземпляры разработанного Google Material Design. Есть мнение, что тени помогают мозгу понять устройство интерфейса, и, видимо, по этой причине тени повсеместно присутствовали в эпоху повсеместного распространения скевоморфизма.

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

Благодаря теням и даже градиентам UI смотрится естественнее, эти детали можно использовать для создания 3D-кнопок и форм ввода.

7. Базовый принцип простого дизайна: устранить беспорядок

И хотя миф об эффективности правила трех кликов в веб-дизайне уже давно развенчан, это правило, тем не менее, может оказаться достаточно эффективным применительно к приложениям. В идеале пользователь должен выполнять задачи быстро и за ограниченное количество шагов. Гендиректор Yahoo Марисса Майер советует дизайнерам придерживаться правила «двух нажатий». По ее словам, «если в приложении недостаточно двух нажатий, чтобы сделать все необходимое, значит этому приложению необходим редизайн». «В Yahoo Flickr это присутствует повсеместно: открыв экран, вы можете выбирать изображения, просматривать альбомы, группы, устанавливать уведомления, выполнять другие действия — и все это с помощью только лишь двух кликов».

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

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

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

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

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

7 дней дизайн-перезагрузки

Мощнейние спикеры, самое дружелюбное дизайн-комьнити и желание делать клевый дизайн.
Скидка 10% по промокоду UXPUB

Присоединиться

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

Минимизируйте когнитивную нагрузку

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

Наведение порядка

Избавление от беспорядка – одна из главных рекомендаций статьи «10 Do’s and Don’ts of Mobile UX Design». Беспорядок – один из худших врагов хорошего дизайна. Загромождая интерфейс, вы перегружаете пользователей слишком большим объемом информации: каждая добавленная кнопка, изображение и иконка усложняют экран.

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

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

Чистая панель вкладок (справа) намного лучше, чем загроможденная (слева). (Изображение: Apple)

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

Интерфейс показывает больше возможностей после взаимодействия. (Изображение: Ramotion)

Упрощайте задачи

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

Разбивайте задачи на небольшие куски

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

Разбивка задачи делает форму менее загруженной, особенно когда вы запрашиваете у пользователя много информации. (Изображение: Murat Mutlu)

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

Поиск фильма и покупка билетов в кинотеатр. (Изображение: Anton Skvortsov)

Используйте знакомые экраны

Знакомые экраны – это экраны, которые пользователи видят во многих приложениях. Такие экраны, как «Начало работы», «Что нового» и «Результаты поиска», де-факто стали стандартами для мобильных приложений. Они не требуют дополнительных объяснений, потому что пользователи уже знакомы с ними. Это позволяет пользователям использовать предыдущий опыт взаимодействия с приложением без необходимости обучения.

Экран профиля пользователя в приложении Quora

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

Минимизируйте ввод информации пользователем

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

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

Основное правило в дизайне форм – чем короче, тем лучше. Объедините несколько полей в одно удобное для заполнения поле. (Изображение: Luke W.)

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

(Изображение: Josh Morony)

• Используйте такие интеллектуальные функции, как автозаполнение. Например, заполнение поля адреса часто является наиболее проблемной частью любой регистрационной формы. Использование таких инструментов, как Place Autocomplete Address Form(который использует как географическое местоположение, так и предварительное заполнение адреса для предоставления точных предложений, основанных на точном местоположении пользователя), позволяет пользователям вводить свой адрес с меньшим количеством нажатий клавиш, чем при обычном поле ввода.
• Динамическая проверка значения полей. Это печально, когда после отправки данных вам приходится возвращаться и исправлять ошибки. По возможности, проверяйте значения полей сразу после ввода данных, чтобы пользователи могли их мгновенно исправить.

Встроенная проверка (Изображение: Baymard)

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

Подберите клавиатуру для ввода требуемого текста. (Изображение: ThinkWithGoogle)

Предвосхищайте потребности пользователя

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

Не очевидно, где пользователь может найти штрих-код. Краткая справка рядом с полем ввода будет очень полезной. (Изображение: Hotjar)

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

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

Большие предметы привлекают внимание и кажутся более важными, чем мелкие. Кнопка «Request Lyft» привлечет внимание пользователя

Избегайте жаргона

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

Неизвестные термины или фразы увеличат когнитивную нагрузку на пользователя. (Изображение: ThinkWithGoogle)

Сделайте дизайн последовательным

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

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

Вот несколько практических рекомендаций по созданию последовательного дизайна:

• Соблюдайте стандарты платформы.
  Каждая мобильная ОС имеет стандартные рекомендации по дизайну интерфейса: Human Interface Guidelines от Apple и Material Design Guidelines от Google. При проектировании для нативных платформ соблюдайте дизайн-рекомендации ОС для обеспечения максимального качества. Причина, по которой важно следовать дизайн-рекомендациям, проста: пользователи знакомятся с паттернами взаимодействия каждой ОС, и все, что противоречит руководящим принципам, вызывает проблемы.
• Не имитируйте элементы интерфейса с других платформ.
  При создании приложения для Android или iOS не переносите элементы интерфейса с других платформ. Иконки, функциональные элементы (поля ввода, флажки, переключатели) и шрифты должны выглядеть естественно. Максимально используйте нативные компоненты, чтобы люди доверяли вашему приложению.
• Следите, чтобы мобильное приложение соответствовало веб-сайту.
  Это пример внешней согласованности. Если у вас есть веб-сервис и мобильное приложение, убедитесь, что оба они имеют сходные характеристики. Это позволит пользователям совершать беспроблемные переходы между мобильным приложением и мобильным сайтом. Несоответствие в дизайне (например, другая навигационная схема или другая цветовая схема) может привести к путанице.

Предоставьте пользователю контроль

Сделайте интерактивные элементы знакомыми и прогнозируемыми

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

Кнопка Назад» должна работать правильно

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

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

Информативные сообщения об ошибках

Человеку свойственно ошибаться. Ошибки возникают, когда люди взаимодействуют с приложениями. Иногда они случаются по вине пользователя. Иногда они случаются из-за сбоя приложения. Независимо от причины ошибки, способы ее обработки имеют огромное влияние на UX. Плохая обработка ошибок в сочетании с бесполезными сообщениями об ошибках может вызвать у пользователей разочарование и стать причиной, по которой пользователи покинут ваше приложение. Возьмем  в качестве примера экран состояния ошибки из Spotify. Он не помогает пользователям понять контекст или найти ответ на вопрос: «Что я могу с этим поделать?»

Экран ошибок Spotify просто говорит: «Произошла ошибка» и не дает каких-либо конструктивных советов о том, как решить проблему

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

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

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

Проектируйте доступный интерфейс

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

Учитывайте цветовую слепоту

4.5% населения мира страдают дальтонизмом (это 1 из 12 мужчин и 1 из 200 женщин), 4% страдают слабым зрением (1 из 30 человек) и 0,6% являются слепыми (1 из 188 человек). Легко забыть, что мы проектируем для этой группы пользователей, потому что большинство дизайнеров не сталкиваются с такими проблемами.

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

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

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

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

Сделайте анимации отключаемыми

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

Сделайте навигацию простой

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

Используйте стандартные компоненты навигации

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

Side drawer (Android). (Изображение: Material Design)
Панель вкладок (iOS). (Изображение: Ramotion)

Подробнее о паттернах навигации читайте в статье «Основные паттерны мобильной навигации: за и против».

Приоритизация навигационных опций

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

Не смешивайте навигационные паттерны

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

Сделайте навигацию заметной

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

Сообщайте текущее местоположение

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

Приложение «Здоровье» (от Apple) предоставляет информацию о текущем разделе (выделена опция навигации «Медданные») и подразделе (заголовок «Активность» отображается в верхней части макета)

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

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

Функциональная анимация может эффективно направлять внимание пользователя и облегчать понимание сложных переходов. (Изображение: Jae-seong, Jeong)

Будьте осторожны с использованием жестов в интерфейсе

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

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

Когда дело доходит до использования жестов в интерфейсе, следуйте нескольким простым правилам:

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

Для получения дополнительных сведений об использовании жестов в пользовательском интерфейсе прочтите статью «Жесты в приложениях и мобильный UX».

Сфокусируйтесь на первом опыте

Первый опыт может уничтожить мобильное приложение. У вас всего один шанс на создание первого впечатления. И если вы потерпите неудачу, есть большая вероятность, что пользователи больше не запустят ваше приложение. (Исследования Localytics показывают, что 24% пользователей никогда не возвращаются в приложение после первого использования).

Избегайте обязательного входа в учетную запись

Обязательная регистрация перед использованием приложения создает стену перед пользователем (sign-in wall). Это распространенная проблема для пользователей и одна из причин, по которой они отказываются использовать приложение. Количество пользователей, которые отказываются от процесса регистрации, особенно важно для приложений с низкой узнаваемостью бренда или тех, в которых ценностное предложение неясно.

Pinterest просит пользователей создать новую учетную запись или войти в имеющуюся при первой загрузке

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

Проектируйте хороший опыт обучения новых пользователей

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

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

У Duolingo есть пользовательский тур, который состоит из быстрого теста

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

Пустое состояние в Expensify успокаивает пользователей, сообщая им, с чего начать

Для получения дополнительной информации об обучении  новых пользователей рекомендуем к прочтению статью «Роль пустых состояний в обучении пользователя».

Не спрашивайте информацию о настройке заранее

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

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

Избегайте с самого начала просить разрешения

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

Паттерны запросов на разрешение, предложенные Google. (Изображение: Material Design)

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

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

Советы:

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

Сделайте ваше приложение быстрым и отзывчивым

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

Чем быстрее ваше приложение, тем лучше будет опыт. (Изображение: Google)

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

Сосредоточьтесь на загрузке контента в заметной области экрана

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

Сделайте понятным, когда закончится загрузка

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

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

Предлагайте визуальное отвлечение

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

Внимание к тонким движениям может приятно удивить пользователя. (Изображение: UI8)

Совет: помните о долголетии. Даже хорошая анимация может раздражать, когда она чрезмерно используется. Создавая анимацию спросите себя: «Будет ли анимация раздражать при сотом использовании или она универсальна и ненавязчива?»

Каркасные экраны (Skeleton Screens)

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

Каркасный экран показывает экран сразу. Плейсхолдеры заменяют любые элементы макета, содержимое которых еще не доступно. (Изображение: Slack)

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

Каркасный экран заполняет интерфейс по мере загрузки контента. (Изображение: Tandem Seven)

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

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

Сделайте текст читабельным и разборчивым

Когда мы думаем о контенте, в большинстве случаев мы имеем в виду типографику. Как говорит Оливер Райхенштейн в своем эссе «Веб-дизайн – это на 95% типографика»:

«Оптимизация типографики – это удобочитаемость, доступность, юзабилити (!), общий графический баланс».

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

Сначала несколько практических рекомендаций по читабельности:

• Размер шрифта
  Как правило, все, что меньше 16 пикселей (или 11 точек), сложно читать на любом экране.
• Семейство шрифтов
  Большинство пользователей предпочитают четкий, легкий для чтения шрифт. Проверенный вариант – использовать системный шрифт по умолчанию (Apple iOS использует шрифт San Francisco; Google Android использует Roboto).
• Контрастность
  Светлый текст (например, светло-серый) может выглядеть эстетически привлекательным, но пользователям будет трудно читать его, особенно на светлом фоне. Убедитесь, что между шрифтом и фоном большой контраст для удобства чтения. В руководстве по доступу к веб-контенту WC3  представлены рекомендации по соотношению контрастности для изображений и текста.

Даже высококонтрастный текст трудно читать при ярком свете, но низкоконтрастный текст почти невозможно прочитать

А теперь несколько рекомендаций по удобочитаемости:

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

• Ограничьте длину текстовых строк.
  Хорошее практическое правило – использовать для мобильных устройств от 30 до 40 символов в строке.

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

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

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

HD-качество изображений и правильное соотношение сторон

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

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

Последней проблемой, с которой сталкиваются многие мобильные дизайнеры, является оптимизация UX для iPhone X. Проектирование для iPhone X требует артборд другого размера, чем для любого другого iPhone (вам понадобятся изображения с разрешением 375 x 812 точек при коэффициенте увеличения 3x).

(Изображение: Apple)

Чтобы узнать больше о проектировании для iPhone X рекомендуем к прочтению статью «Проектирование приложений для iPhone X: Что каждый UX дизайнер должен знать о последнем устройстве Apple».

Видеоконтент, оптимизированный для портретной ориентации

Видео быстро становится стандартным методом потребления контента для многих пользователей. По данным YouTube, потребление видео с мобильных устройств растет на 100% каждый год. К 2020 году свыше 75% мирового трафика мобильных данных будет составлять видеоконтент. Это означает, что важно оптимизировать видеоконтент для портретного режима.

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

Facebook Live позволяет смотреть видео на временной шкале Facebook. (Изображение: Giphy)

Проектирование для сенсорных экранов

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

Проектируйте для пальцев, а не для курсора

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

Небольшая сенсорная цель увеличивает вероятность ложного выбора. (Изображение: Apple)

При разработке сенсорной цели вы можете положиться на исследование MIT Touch Lab (PDF), чтобы выбрать подходящий размер интерактивных элементов. Это исследование показало, что средний размер подушечек пальцев составляет от 10 до 14 мм, а кончиков пальцев – от 8 до 10 мм, что делает 10 на 10 мм хорошим минимальным размером цели касания.

10 на 10 мм – это хороший минимальный размер сенсорной цели. (Изображение: UXmag)

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

Пример пробела между кнопками. (Изображение: Material Design)

Учитывайте зону большого пальца

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

Зоны большого пальца, согласно исследованию Скотта Херфа. (Изображение: Smashing Magazine)

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

Зона большого пальца для правши, согласно исследованию Скотта Херфа

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

• Зеленая зона – лучшее место для параметров навигации или частых интерактивных действий (например, кнопок призыва к действию).
• Красная зона – лучшее место для потенциально опасных опций (например, «Удалить» или «Стереть»). Пользователи с меньшей вероятностью случайно активируют эту опцию.

Фидбек на взаимодействие

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

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

Делайте цифровой опыт человечным

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

Персонализированный опыт

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

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

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

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

Восхитительная анимация

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

Использование восхитительных деталей – это возможность создать эмоциональную связь с вашими пользователями. (Изображение: Serhii Hanushchak)

Оптимизируйте Push-уведомления

Раздражающие уведомления – причина номер 1, по которой люди удаляют мобильные приложения (по мнению 71% респондентов).

(Изображение: Appiterate Survey)

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

Ценные уведомления

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

Netflix делает большую работу по персонализации своих push-уведомлений, давая пользователям знать, когда их любимые шоу доступны

Не отправляйте много уведомлений за короткий период времени

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

Правильно подбирайте время для уведомлений

Важно не только то, что вы говорите, но и когда вы это говорите. Не отправляйте push-уведомления в странные часы (например, среди ночи). Лучшее время для push-уведомлений – часы пиковой нагрузки на мобильные устройства: с 18:00 до 22:00.

Рассмотрите другие каналы, доставки сообщений

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

Выберите правильный тип уведомления в зависимости от срочности и контента. (Изображение: Appboy)

Оптимизация для мобильных устройств

Проектируйте с учетом прерываний

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

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

Используйте преимущества возможностей устройства

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

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

(Изображение: Business Insider)

• Осведомленность о местоположении

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

Такие приложения, как Uber Eat, уже использует это свойство, чтобы уменьшить количество действий, требуемых от пользователя

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

Приложение Chase Mobile обеспечивает вход в систему одним касанием

Совет: Практические рекомендации по использованию Apple Face ID можно найти в нашей статье « Проектирование приложений для iPhone X: что нужно знать каждому UX-дизайнеру о новейшем устройстве Apple».

Используйте Face ID при входе в систему на iPhone X (в качестве замены пароля). (Изображение: Tesco)

Стремитесь создать многоканальный опыт

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

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

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

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

Если вы хотите стать глобальным, важно учитывать их опыт.

Плохое интернет соединение

В США и Европе пользователи привыкли к возможности повсеместного подключения к сети. Но так, безусловно, не во всем мире. Продукты на развивающихся рынках должны иметь возможность работать с медленным или прерывистым Интернет-соединением. В зависимости от местоположения человека, сеть может переключаться с Wi-Fi на 3G, на 2G или вообще пропасть, и ваш продукт должен это учитывать.

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

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

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

YouTube Go позволяет пользователям отправлять и получать видео, когда они вместе, используя peer-to-peer обмен в автономном режиме

Google News & Weather – еще один прекрасный пример приложения, учитывающего плохое Интернет-соединение. В приложении есть функция «Lite mode» для людей, подключенных к сети с низкой пропускной способностью. Когда этот режим активирован, он оставляет только основной контент, чтобы приложение загружалось быстрее. По данным Google, этот режим использует менее трети обычных данных, и он автоматически активируется, когда приложение обнаруживает медленную сеть.

Ограниченные данные

Приблизительно на 95% развивающихся рынков, люди почти полностью полагаются на дорогие мобильные данные с предоплатой. Люди покупают фиксированный объем данных, и многие могут позволить себе только около 250 МБ данных в месяц.

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

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

YouTube Go позволяет предварительно просматривать видео и выбирать размер файла, прежде чем сохранять его в автономном режиме, чтобы посмотреть позже

Ограниченные возможности устройства

Смартфоны в странах, ориентированных на мобильные устройства, значительно отличаются от популярных в США моделей Google Pixel и iPhone. Большинство устройств на развивающихся рынках стоят менее $100 и могут поставляться с ограниченными объемом памяти и возможностями обработки. Убедитесь, что проектируемый вами продукт работает со старыми недорогими устройствами и программным обеспечением.

Местная эстетика

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

Региональные особенности

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

Тестирование и фидбек

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

Фидбек

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

Дизайн – это бесконечный процесс

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

Полезные инструменты и ресурсы для дизайнеров

Color Contrast Checker

Удивительно, сколько мобильных приложений не проходят тест АА. Не будьте одним из них! Важно проверить доступность цветового контраста. Используйте Color Contrast Checker от WebAIM для проверки контраста цветовых комбинаций.

Color Contrast Checker от WebAIM

Наборы элементов интерфейса для Adobe XD

Хорошо спроектированный интерфейс сделает ваше приложение великолепным. Замечательно, когда вы можете создавать интерфейс не с нуля, а используя такой прочный фундамент, как набор элементов интерфейса (UI kit). У Adobe XD есть пять наборов элементов интерфейса, которые вы можете скачать абсолютно бесплатно. Эти наборы повысят вашу креативность и помогут создавать визуально интересные дизайны интерфейса.

Navigo Transportation UI Kit (Изображение: Adobe)

Вывод

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

Как адаптировать интерфейс приложения под разные платформы — Офтоп на vc.ru

В войне между iOS и Android нет победителя — это всем известно. Если продукт успешен на одной платформе, то он, без всякого сомнения, будет перенесен на другую. Иногда разработчики приложений даже не выдерживают паузы, и релизы происходят одновременно на обеих платформах. Для дизайнеров это значит только одно: им придется адаптировать UI и UX приложения для другой платформы, сохранив при этом целостность дизайна продукта.

Есть три способа мульти­платформенной адаптации пользовательского интерфейса:

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

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

Подход 1: Ориентация на целостность бренда

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

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

VSCO Cam

Первая версия приложения VSCO Cam от компании Visual Supply вышла для iOS в 2012 году. Год спустя ставший популярным фоторедактор перенесли на Android. Версия для Android повторяла интерфейс iOS-версии практически полностью. Но интересно тут вот что: ни одна из версий не соответствовала установленным для своей платформы стандартам визуального дизайна.

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

Instagram

Как и VSCO Cam, Instagram был выпущен в App Store намного раньше, чем появилась его версия для Android. Дизайн для iPhone строго соответствовал гайдлайнам платформы, а само приложение имело огромный успех. Типично «эппловский» дизайн стал одной из ключевых особенностей Instagram, и разработчики не стали его кардинально менять при переносе продукта на Android. Даже несмотря на то, что общая эстетика приложения отличалась от того, что привыкли видеть пользователи Android, загрузки Instagram в Google Play
превысили 1 миллион уже в день релиза.

Instagram для iOS (слева) и Android

Текущие версии Instagram для iOS и Android действительно выглядят как близнецы, хотя некоторые различия между ними все же есть. Например, search bar выглядят более стандартно для каждой из платформ. Интерфейс камеры в последней версии для Android также стал немного отличаться от iOS­-версии. Кроме того, в приложении для iOS логотип Instagram расположен в центре navigation bar, в то время как в Android-версии — слева от toolbar.

Реализация поиска в Instagram на iOS (слева) и Android

Хотя Instagram для Android не соответствует стандартам платформы, приложение все равно очень комфортно для пользователей.

Wire

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

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

Прииду Зилмер, ведущий дизайнер Wire

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

цветовая палитра, возможность выбирать фоновое изображение и цветовую схему — все это делает Wire уникальным решением на фоне Telegram, WhatsApp, Viber и других похожих друг на друга мессенджеров.

Мы вложили много сил в дизайн и не могли переделывать его для каждой

отдельной платформы (Android, iOS, компьютер, веб), особенно учитывая, что

нормы в дизайне постоянно меняются и за ними трудно угнаться: всегда есть риск, что приложение внезапно перестанет выглядеть актуальным, как это случилось со многими продуктами, когда вышли iOS 7 и Android L.

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

платформы, поэтому постоянно работаем над поиском правильного

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

уместно на всех платформах.

Прииду Зилмер, ведущий дизайнер Wire

Интерфейсы Wire на iOS и Android абсолютно идентичны, включая UX и иконки. Единственное, что есть в приложении от гайдлайнов, — это размер кликабельных элементов. Wire — еще один пример того, что дизайн интерфейса может быть более важен, чем соответствие требованиям платформы.

По словам Зилмера, команда Wire считает, что общение между людьми не должно быть ограничено какими­-либо рамками и условностями.

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

Когда следует ориентироваться на целостность бренда

1. Одни и те же пользователи используют разные каналы (компьютер, iPad, iPhone, Android) для доступа к вашим продуктам.

Довольно часто компании, которые используют несколько каналов взаимодействия с клиентами, ориентируются на целостность бренда. Однако в этом есть смысл лишь в том случае, если одни и те же пользователи имеют доступ к продукту на разных платформах и типах устройств (iPad, Android, веб). Например, пользователь iBroadcast одновременно имеет доступ к музыкальному сервису через iOS- и Android-устройства, а также через компьютер. Версии приложения для каждой платформы выглядят одинаково, потому что для iBroadcast важно обеспечить пользователю плавный незаметный переход с одной платформы на другую.

Пользователи нашего сервиса постоянно мигрируют между сайтом и

приложениями для iOS и Android, и мы стремимся сделать эти переходы как

можно более незаметными.

Род Коллен, со­основатель iBroadcast

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

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

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

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

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

продуктом.

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

Мне не нравилось, как в гайдлайнах предлагалось реализовать некоторые

функции, и я решил, что стоит придумать решение по­лучше.

По сути, я просто игнорировал гайдлайны в тех случаях, когда было четко

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

— лучший отклик на действия пользователя, избавление от ненужных

элементов и предотвращение помех в использовании приложения. Отказ от

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

важную роль.

Богдан Михайчик, основатель Receipt

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

Превосходный UI-­дизайн Citymapper также выделяет приложение на всех трех платформах, включая веб.

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

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

Я думаю, что важность уникальности языка дизайна очень часто

недооценивают… «Citymapper, говорите?» «Да, тот, зеленый». Это само по

себе дорогого стоит.

Иногда дизайнеры слишком пекутся о совершенстве пикселей и «правильности»

их дизайна. Жизнь хаотична, разработка продукта — тоже. Так зачем же

скрывать это? Мы все в одной лодке: те, кто создает проект, и те, кто его

использует.

Гилберт Уидэм, ведущий дизайнер Citymapper

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

Подход 2: Ориентация на платформу

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

В таком случае фокус смещается с целостности бренда на привычный UX, так как пользователи имеют свойство «привыкать» к платформе. В таком случае интуитивное восприятие приложения через знакомый дизайн может дать ряд преимуществ. Давайте посмотрим, как этим воспользовались Telegram и WhatsApp.

Telegram

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

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

Версии Telegram для iOS и Android различаются настолько, насколько могут различаться типичные приложения для этих платформ. Версия для iOS полностью следует гайдлайнам Apple и выглядит абсолютно как приложение, разработанное для iOS 7 или 8: справа от navigation bar — кнопка, отвечающая за написание нового сообщения, слева — кнопка для редактирования, внизу экрана — tap bar с разделами, а вверху можно найти название текущего раздела.

Android­-версия приложения следует гайдлайнам Google Material Design. Там есть гамбургер­-меню для навигации по разделам, простая кнопка поиска в верхнем правом углу, и, конечно, плавающая кнопка — сердце и душа Material Design.

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

Экран настроек Telegram для iOS (слева) и Android

WhatsApp

Пока не будем оставлять тему мессенджеров и устремим наши взоры на так называемого пророка приложений для обмена сообщениями — WhatsApp, который ныне принадлежит Facebook. Приложение для iOS вышло в 2009 году, вскоре после версий для BlackBerry и Symbian. WhatsApp для Android появился на рынке только в 2012 году и выглядел именно так, как должен был выглядеть, чтобы его приняли и полюбили пользователи этой системы.

Так как WhatsApp доступен на любой платформе, естественно, что его создатели при разработке дизайна приложения выбрали ориентацию на платформу. Версии для iOS и Android выглядят совершенно по-разному. Дизайнеры отлично провели мульти­платформенную адаптацию, поменяв все — от дизайна UX и вида сообщений до иконок и расположения элементов управления.

Текущая версия приложения для iOS соответствует стандартам iOS 9. Версия для Android оперативно получила обновление до соответствия стандартам Material Design и продолжает им следовать.

Komoot

Komoot — это приложение для путешественников и велосипедистов, которое принадлежит немецкому стартапу. Первая версия приложения вышла на iOS в 2010 году, а год спустя за ней последовала версия для Android. Старые версии Komoot не имеют ничего общего с нынешними продуктами стартапа.

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

Мы решили придерживаться правил, принятых для платформ, потому что

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

Кроме того, Apple и Google отдают предпочтение приложениям, которые

следуют их требованиям относительно дизайна UI, что действительно важно

для продвижения приложения в App Store и Google Play.

Дмитрий Прудников, UI- и UX­-дизайнер Komoot

Komoot неоднократно попадал в топ в App Store и был назван одним из лучших приложений на Google Play в 2014 году. Сейчас Komoot — топовое приложение на обеих платформах.

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

Когда следует ориентироваться на стандарты платформы

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

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

достаточно следовать гайдлайнам.

2. Тренды в дизайне, введенные Apple и Google, были очень хорошо восприняты пользователями.

Сверх­разумное брендинговое решение Google не оставляет нам иного выбора: если переносить приложение с iOS на Android, то переосмысление его под стандарты Material Design — уже необходимость.

Причем этот тренд привлек внимание владельцев iPhone, так что теперь некоторые iOS-приложения используют Material Design в своих интерфейсах. Мы упоминаем Material Design только для того, чтобы подчеркнуть: следовать общим тенденциям очень важно, даже если эти тенденции противоречат нормам отдельно взятой платформы. К слову, вот отличный
материал от InVision о том, как использовать Material Design и при этом не выглядеть, как Google.

3. У вашего приложения сложная функциональность и интерфейс.

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

Рассмотрим в качестве примера Accent Kit — приложение, которое мы разработали для ведущих британских тренеров по акцентам и диалекту для актеров. Accent Kit содержит множество функций (воспроизведение и запись аудио, просмотр текстов, изображений и так далее), которые призваны помочь актерам освоить акцент. Когда перед Yalantis была поставлена задача перенести приложение на Android, мы не рассматривали иных вариантов, кроме как следование стандартам платформы. В противном случае пользователи испытывали бы неудобства, пытаясь разобраться в функциональности приложения.

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

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

Подход 3: Смешанный

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

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

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

Давайте посмотрим, как с этим справились SoundCloud, Facebook, Airbnb и Viber.

SoundCloud

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

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

Сильвиан Гранде, вице­-президент SoundCloud по направлениям «продукт», «создатели» и «монетизация»

Среди характерных для платформы решений здесь — стандартный для iOS tap bar внизу экрана (с парой дизайнерских изменений) и search bar вверху. В Android-­версии — типичный tool bar вверху экрана, гамбургер­-меню слева и иконка поиска, раскрывающая search bar. Обе версии приложения используют стандартное для платформ управление.

Facebook

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

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

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

Версия для iOS использует стандартные для этой ОС navigation bar внизу экрана и search bar. В версии для Android переключение между разделами происходит с помощью tap bar, который, как в большинстве Android-приложений, расположен вверху экрана.

Airbnb

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

Дизайнеры Airbnb избрали смешанный подход при переносе сервиса на мобильные платформы. Бренд Airbnb уникален сам по себе и привлекает внимание людей по всему миру. Однако именно контент заставляет приложение работать. Поэтому создатели Airbnb сделали приложение удобным для пользователей обеих платформ.

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

поэтому мы должны были следовать нормам, к которым они привыкли. Но в то

же время мы хотели, чтобы это был именно Airbnb.

Связь между платформами (мобильные, веб, email, и так далее) ­очень важна для

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

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

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

Кэти Дилл, ведущий UX­-дизайнер Airbnb

На первый взгляд, главное различие между версиями Airbnb для iOS и Android — это расположение navigation bar: внизу на iOS и вверху на Android.

Если бы не эта маленькая, но очень важная особенность, мы бы отнесли Airbnb к приложениям, которые следуют подходу ориентации на целостность бренда. Но если присмотреться, то разница между версиями все­-таки есть.

Экран поиска Airbnb на iOS (слева) и Android

Учитывая простую функциональность Airbnb, более глубокое соответствие особенностям платформ усложнило бы приложение.

Навигация Airbnb на iOS (слева) и Android

Viber

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

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

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

Список контактов Viber на iOS (слева) и Android

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

Когда стоит следовать смешанному подходу

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

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

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

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

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

Какой подход побеждает

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

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

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

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

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

Единственное, что имеет значение, — это пользователи.

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

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

Что такое API? (Application Programming Interface)

API — это аббревиатура от Application Programming Interface, которая представляет собой программный посредник, позволяющий двум приложениям взаимодействовать друг с другом. Каждый раз, когда вы используете такое приложение, как Facebook, отправляете мгновенное сообщение или проверяете погоду на своем телефоне, вы используете API.

Что такое API? Наконец, узнайте сами, посмотрите это полезное видео от MuleSoft, экспертов по API.

Что такое пример API?

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

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

Представьте, что вы сидите за столиком в ресторане с выбором блюд из меню. Кухня — это часть «системы», которая подготовит ваш заказ.Чего не хватает, так это важного звена для передачи вашего заказа на кухню и доставки еды обратно к вашему столу. Вот тут-то и пригодится официант или API. Официант — это мессенджер (или API), который принимает ваш запрос или заказ и сообщает кухне — системе — что делать. Затем официант возвращает вам ответ; в данном случае это еда.

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

Однако что, если вы не используете веб-сайт авиакомпании — канал, который имеет прямой доступ к информации? Что делать, если вы используете онлайн-сервис для путешествий, такой как Kayak или Expedia, который собирает информацию из ряда баз данных авиакомпаний?

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

Что еще предоставляет API, так это уровень безопасности

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

API стали настолько ценными, что составляют значительную часть доходов многих предприятий. Крупные компании, такие как Google, eBay, Salesforce.com, Amazon и Expedia, — это лишь некоторые из компаний, которые зарабатывают деньги на своих API. Под «экономикой API» подразумевается рынок API-интерфейсов.

Современный API

На протяжении многих лет термин «API» часто описывал какой-либо общий интерфейс связи с приложением. Однако в последнее время современные API-интерфейсы приобрели некоторые характеристики, которые делают их чрезвычайно ценными и полезными:

• Современные API-интерфейсы соответствуют стандартам (обычно HTTP и REST), которые удобны для разработчиков, легко доступны и понятны в широком смысле
• Они рассматриваются больше как продукты, чем код. Они предназначены для потребления определенной аудиторией (например,g., мобильные разработчики), они документированы и имеют версии таким образом, чтобы пользователи могли иметь определенные ожидания в отношении его обслуживания и жизненного цикла.
• Поскольку они намного более стандартизированы, они имеют гораздо более строгую дисциплину в отношении безопасности и управления, а также контролируются и управляются для обеспечения производительности и масштабирования. SDLC) проектирования, тестирования, сборки, управления и управления версиями.Кроме того, современные API хорошо документированы для использования и управления версиями.

Чтобы узнать больше об API и о том, как разработать отличный API, загрузите электронную книгу Undisturbed REST: A Guide to Designing Perfect API.

Что такое интерфейс прикладного программирования (API)

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

Что такое интерфейс прикладного программирования (API)?

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

Как работает API

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

Вот как работает API:

1. Клиентское приложение инициирует вызов API для получения информации — также известный как запрос . Этот запрос обрабатывается от приложения к веб-серверу через унифицированный идентификатор ресурса (URI) API и включает команду запроса, заголовки, а иногда и тело запроса.
2. После получения действительного запроса API обращается к внешней программе или веб-серверу.
3. Сервер отправляет ответ API с запрошенной информацией.
4. API передает данные исходному запрашивающему приложению.

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

API

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

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

Зачем нужны API

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

• Улучшение совместной работы: Среднее предприятие использует почти 1200 облачных приложений (ссылка находится за пределами IBM), многие из которых отключены. API-интерфейсы обеспечивают интеграцию, чтобы эти платформы и приложения могли беспрепятственно взаимодействовать друг с другом.Благодаря этой интеграции компании могут автоматизировать рабочие процессы и улучшить совместную работу на рабочем месте. Без API-интерфейсов у многих предприятий не будет возможности подключения и они будут страдать от разрозненности информации, которая снижает производительность и производительность.
• Более простые инновации: API предлагают гибкость, позволяя компаниям устанавливать связи с новыми деловыми партнерами, предлагать новые услуги для их существующего рынка и, в конечном итоге, выходить на новые рынки, которые могут принести огромную прибыль и стимулировать цифровую трансформацию.Например, компания Stripe начиналась как API всего с семью строками кода. С тех пор компания установила партнерские отношения со многими крупнейшими предприятиями мира, диверсифицировала деятельность, предлагая ссуды и корпоративные карты, и недавно была оценена в 36 миллиардов долларов США (ссылка находится за пределами IBM).
• Монетизация данных: Многие компании предпочитают предлагать API бесплатно, по крайней мере на начальном этапе, чтобы они могли создать аудиторию разработчиков вокруг своего бренда и наладить отношения с потенциальными деловыми партнерами.Однако, если API предоставляет доступ к ценным цифровым активам, вы можете монетизировать его, продавая доступ (это называется экономикой API). Когда AccuWeather (ссылка находится за пределами IBM) запустила портал самообслуживания для разработчиков для продажи широкого спектра пакетов API, потребовалось всего 10 месяцев, чтобы привлечь 24 000 разработчиков, продать 11 000 ключей API и создать в процессе процветающее сообщество.
• Дополнительная безопасность: Как отмечалось выше, API-интерфейсы создают дополнительный уровень защиты между вашими данными и сервером.Разработчики могут дополнительно усилить безопасность API, используя токены, подписи и шифрование TLS; путем внедрения шлюзов API для управления и аутентификации трафика; и практикуя эффективное управление API.

Общие примеры API

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

• Универсальные учетные записи: Популярным примером API является функция, которая позволяет пользователям входить на веб-сайты, используя данные для входа в профили Facebook, Twitter или Google.Эта удобная функция позволяет любому веб-сайту использовать API одной из наиболее популярных служб для быстрой аутентификации пользователя, экономя время и хлопоты по настройке нового профиля для каждой службы веб-сайта или нового членства.
• Сторонняя обработка платежей: Например, теперь повсеместная функция «Оплата через PayPal», которую вы видите на веб-сайтах электронной торговли, работает через API. Это позволяет людям оплачивать продукты в Интернете, не раскрывая конфиденциальные данные и не предоставляя доступ неавторизованным лицам.
• Сравнение бронирования путешествий: Сайты бронирования путешествий объединяют тысячи рейсов, демонстрируя самые дешевые варианты для каждой даты и пункта назначения. Эта услуга стала возможной благодаря API-интерфейсам, которые предоставляют пользователям приложений доступ к последней информации о доступности отелей и авиакомпаний. Благодаря автономному обмену данными и запросами API-интерфейсы значительно сокращают время и усилия, необходимые для проверки доступных рейсов или жилья.
• Google Maps: Одним из наиболее распространенных примеров хорошего API является сервис Google Maps.В дополнение к основным API-интерфейсам, которые отображают статические или интерактивные карты, приложение использует другие API-интерфейсы и функции для предоставления пользователям маршрутов или достопримечательностей. С помощью геолокации и нескольких уровней данных вы можете взаимодействовать с API Карт при прокладке маршрутов или отслеживании перемещаемых предметов, например средств доставки.
• Twitter: Каждый твит содержит описательные основные атрибуты, включая автора, уникальный идентификатор, сообщение, отметку времени, когда он был опубликован, и метаданные геолокации.Twitter делает общедоступные твиты и ответы доступными для разработчиков и позволяет разработчикам публиковать твиты через API компании.

Типы API

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

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

Типы протоколов API

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

• SOAP (Простой протокол доступа к объектам) — это протокол API, построенный на основе XML, позволяющий пользователям отправлять и получать данные через SMTP и HTTP. С помощью API-интерфейсов SOAP проще обмениваться информацией между приложениями или программными компонентами, которые работают в разных средах или написаны на разных языках.
• XML-RPC — это протокол, который использует особый формат XML для передачи данных, тогда как SOAP использует собственный формат XML.XML-RPC старше, чем SOAP, но намного проще и относительно легковесен, поскольку использует минимальную полосу пропускания.
• JSON-RPC — это протокол, аналогичный XML-RPC, поскольку они оба являются удаленными вызовами процедур (RPC), но в этом протоколе для передачи данных используется JSON вместо формата XML. Оба протокола просты. Хотя вызовы могут содержать несколько параметров, они ожидают только одного результата.
• REST (передача репрезентативного состояния) — это набор принципов архитектуры веб-API, что означает отсутствие официальных стандартов (в отличие от стандартов с протоколом).Чтобы быть REST API (также известным как RESTful API), интерфейс должен соответствовать определенным архитектурным ограничениям. Можно создавать RESTful API с протоколами SOAP, но эти два стандарта обычно рассматриваются как конкурирующие спецификации.

API, веб-службы и микросервисы

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

Традиционно API относился к интерфейсу, связанному с приложением, которое могло быть создано с помощью любого из низкоуровневых языков программирования, например Javascript. Современный API придерживается принципов REST и формата JSON и обычно создается для HTTP, в результате чего удобные для разработчиков интерфейсы легко доступны и широко понятны приложениям, написанным на Java, Ruby, Python и многих других языках.

При использовании API существует два общих архитектурных подхода — сервис-ориентированная архитектура (SOA) и микросервисная архитектура.

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

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

Более подробные сведения о взаимосвязи этих архитектурных подходов см. В разделе «SOA и микросервисы: в чем разница?»

API и облачная архитектура

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

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

API и IBM Cloud®

API-интерфейсы

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

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

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

Сделайте следующий шаг:

• Изучите IBM API Connect®, интуитивно понятную и масштабируемую платформу разработки API для создания, безопасного предоставления, управления и монетизации API в системах облачных вычислений.
• Развивайте навыки, которые помогут вам создавать сообщества разработчиков для публикации и совместного использования API и взаимодействия с ними через портал самообслуживания в учебной программе Solution Developer: IBM API Connect.
• API Connect также может интегрироваться с другими возможностями автоматизации в IBM Cloud Pak® for Integration, гибридном решении для интеграции, которое обеспечивает автоматизированный и замкнутый жизненный цикл для различных стилей корпоративной интеграции.
• Примите нашу оценку зрелости интеграции, чтобы оценить уровень зрелости вашей интеграции по важнейшим параметрам и определить действия, которые вы можете предпринять, чтобы перейти на следующий уровень.
• Загрузите наше хрупкое руководство по интеграции, в котором исследуются достоинства контейнерного, децентрализованного, ориентированного на микросервисы подхода к интеграции решений.

Начните работу с учетной записью IBM Cloud уже сегодня.

Дизайн интерфейса приложений: Интернет и мобильные устройства

Что такое интерфейс приложения?

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

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

Что особенного в интерфейсе веб-приложения?

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

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

Чем это отличается от интерфейса мобильного приложения?

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

Краткое содержание урока

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

Application Interface — обзор

5.1 Динамический анализ

Традиционный статический анализ, основанный на анализе исходного кода и технологиях синтаксического анализа, имеет серьезные ограничения при анализе RIA, поскольку он недостаточно мощный, чтобы фиксировать динамическое поведение и изменения RIA. По этой причине динамический анализ был принят как Marchetto et al. [29] и Mesbah et al. [36] для поддержки анализа RIA, поскольку он может собирать информацию, полезную для понимания логики, лежащей в основе RIA. Выполнение динамического анализа целевого приложения включает запуск приложения в различных условиях и контекстах при сборе информации о компонентах приложения и отработанном поведении.Другими словами, отслеживание выполнения приложений и сбор информации в лог-файлах. Динамический анализ по определению является частичным, то есть, применяя динамический анализ, мы можем только рассуждать и понимать «часть» приложения, проявляемую наблюдаемым и отслеживаемым поведением. Поэтому часто может потребоваться ручная проверка или уточнение результатов, полученных с помощью динамического анализа, для повышения его эффективности. Два шага динамического анализа больше всего влияют на его эффективность.Чтобы применить динамический анализ, мы должны определить: (i) набор значимых сценариев выполнения, которые можно использовать для запуска приложения и выявления его соответствующего поведения; и (ii) входные значения, необходимые для реализации таких сценариев. Однако определение значимых выполнений и вводов, таким образом, сбор полезной информации о структуре и поведении приложения — сложная и трудная задача. Оба они нетривиальны и могут потребовать нетривиальных усилий, а также специальных знаний в области применения и предметной области.

Marchetto et al. [29] и Mesbah et al. [36] применяют два разных вида динамического анализа.

[Фактическое выполнение пользователем] Первый подход [29] собирает следы выполнения, наблюдая за фактическим взаимодействием пользователя с пользовательским интерфейсом RIA. Маркетто и др. [31] представили ReAjax, инструмент, который использует набор технологий (например, Javascript, Ajax, DOM, модель событий веб-браузера) для сбора информации времени выполнения об экземплярах RIA DOM (т.е. состояниях пользовательского интерфейса RIA) в виде а также обратные вызовы, активируемые событиями пользовательского интерфейса, которые, возможно, вызывают изменения DOM (т.е.е., переходы из одного экземпляра / состояния RIA в другое).

[Выполнение на основе обхода] Последний подход [35] вместо этого собирает следы выполнения, наблюдая за поведением поискового робота. Mesbah et al. представили Crawljax [35], поискового робота, который может выполнять код сценариев на стороне клиента с целью идентификации интерактивных элементов пользовательского интерфейса RIA, которые могут изменять состояния интерфейса RIA (т. е. экземпляр DOM). Crawljax использует пользовательский интерфейс RIA, моделируя входные события (например,g., щелчок мышью, ввод текста) и путем взятия входных данных из пользовательской базы данных. Более того, Crawljax проверяет обнаруженные экземпляры DOM, чтобы идентифицировать составляющие их элементы, на которые можно нажимать: все элементы, подверженные воздействию определенного типа события (например, щелчка мыши). Crawljax обнаруживает различия в посещенных экземплярах DOM, применяя строковые и древовидные алгоритмы сравнения.

ReAjax и Crawljax, следовательно, выполняют динамический анализ с целью сбора следов выполнения, содержащих информацию о: (i) содержимом и структуре экземпляров DOM приложения; и (ii) события и обратные вызовы, выполняемые в пользовательском интерфейсе приложения, которые оказали какое-либо влияние на DOM.Например, следующий фрагмент файла журнала показывает трассировку выполнения, собранную ReAjax для приложения Cart:

В таком журнале мы наблюдаем один сеанс выполнения, в котором пользователь добавил один товар в корзину, а затем удалил его. Подробно ReAjax отслеживает события, выполняемые в интерфейсе приложения (например, нажатие кнопок «AddToCart», «RemoveFromCart») и список разделенных запятыми строк XPath ⁵ , характеризующих элементы экземпляра Cart DOM (т. Е. Список имя «Контент» и поле «Итого»), а также значение их содержания.

ReAjax собирает эти следы выполнения, применяя полуавтоматический динамический анализ, в котором пользователя просят идентифицировать соответствующие сценарии выполнения, в то время как инструмент отслеживает информацию RIA прозрачно для пользователя. В случае, если у пользователя недостаточно знаний об анализируемом приложении, подходы, такие как представленные Elbaum et al. и Sampath et al. [20,42] могут быть полезны пользователю.

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

Интерфейс приложения — обзор

Неожиданные данные в запросах SQL

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

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

Итак, SQL подразумевает очень пугающую правду.Предполагается, что для работы вашего приложения оно должно иметь достаточный доступ к базе данных для выполнения своей функции. Следовательно, ваше приложение будет иметь надлежащие учетные данные, необходимые для доступа к серверу базы данных и связанным ресурсам. Теперь, если злоумышленник должен изменить команды, которые ваше приложение отправляет на ваш сервер базы данных, ваш злоумышленник использует заранее установленные учетные данные приложения; злоумышленнику не требуется дополнительная информация для аутентификации. Злоумышленнику даже не нужен прямой контакт с самим сервером базы данных.Между сервером базы данных и сервером приложений может быть столько брандмауэров, сколько вы можете себе позволить; Если приложение может использовать базу данных (что предполагается), у злоумышленника также есть прямой путь для ее использования.

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

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

SELECT * FROM table WHERE x = $ data

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

1; SELECT * FROM table WHERE y = 5

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

SELECT * FROM table WHERE x = 1; SELECT * FROM table WHERE y = 5

Обычно это приводит к тому, что база данных выполняет два отдельных запроса: предполагаемый запрос и еще один дополнительный запрос ( SELECT * FROM table WHERE y = 5 ).Я обычно говорю , потому что каждая платформа базы данных по-разному обрабатывает дополнительные команды; некоторые не позволяют использовать более одной команды одновременно, некоторые требуют наличия специальных символов для разделения отдельных запросов, а некоторые даже не требуют символов разделения. Например, следующий действительный запрос SQL (фактически это два отдельных запроса, отправленных одновременно) для баз данных Microsoft SQL Server и Sybase SQL Server:

SELECT * FROM table WHERE x = 1 SELECT * FROM table WHERE y = 5

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

Также важно понимать, что возвращаемый результат зависит от механизма базы данных. Некоторые возвращают два отдельных набора записей, как показано на рисунке 7.1, причем каждый набор содержит результаты отдельного SELECT . Другие могут комбинировать наборы, если оба запроса приводят к одним и тем же возвращаемым столбцам. С другой стороны, большинство приложений написано так, чтобы учесть только первый возвращенный набор записей; следовательно, вы не сможете визуально увидеть результаты второго запроса — однако это не означает, что выполнение второго запроса бесполезно.MySQL позволяет сохранять результаты в файл. В MS SQL Server есть хранимые процедуры для отправки результатов запроса по электронной почте. Злоумышленник может вставить результаты запроса в таблицу, из которой он может читать напрямую. И, конечно же, может не потребоваться просмотр запроса, например команды DROP .

Рисунок 7.1. Некоторые серверы баз данных, такие как Microsoft SQL Server, позволяют использовать несколько команд SQL в одном запросе

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

SELECT * FROM table WHERE x = $ data AND z = 4

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

… WHERE x = 1; SELECT * FROM table WHERE y = 5 AND z = 4

Это приводит к добавлению AND z = 4 ко второму запросу, что может быть нежелательно. Решение состоит в том, чтобы использовать индикатор комментариев, который отличается для каждой базы данных (в некоторых может и не быть). В MS SQL Server двойной дефис (––) указывает базе данных игнорировать все остальное, как показано на рисунке 7.2. В MySQL знак решетки (#) является символом комментария. Итак, для сервера MySQL злоумышленник представит

, рис. 7.2. Экранирование первого запроса путем отправки blah ‘select * from sales — , что использует индикатор комментария (––) в MS SQL Server

1; SELECT * FROM table WHERE y = 5 #

, что приводит к следующему окончательному запросу

… WHERE x = 1; SELECT * FROM table WHERE y = 5 # AND z = 4

, заставляя сервер игнорировать AND z = 4 .

В этих примерах вы знаете имя целевой таблицы, что не всегда так. Возможно, вам придется знать имена таблиц и столбцов, чтобы выполнять правильные запросы SQL; поскольку эта информация обычно не является общедоступной, она может оказаться проблемой. Однако еще не все потеряно. Различные базы данных имеют разные способы запроса системной информации для получения списков установленных таблиц. Например, запрос к таблице sysobjects (с запросом Select * from sysobjects ) в Microsoft SQL Server вернет все объекты, зарегистрированные для этой базы данных, включая хранимые процедуры и имена таблиц.

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

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

Что такое API? Объяснение интерфейсов прикладного программирования

API — это интерфейс прикладного программирования, концепция, которая применяется везде, от инструментов командной строки до корпоративного кода Java и веб-приложений Ruby on Rails. API — это способ программного взаимодействия с отдельным программным компонентом или ресурсом.

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

Что такое API?

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

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

Следует иметь в виду, что названия некоторых API-интерфейсов часто используются для обозначения как спецификации взаимодействий, так и фактического программного компонента, с которым вы взаимодействуете. Фраза «Twitter API», например, не только относится к набору правил для программного взаимодействия с Twitter, но, как правило, понимается как обозначение того, с чем вы взаимодействуете, например, «Мы проводим анализ твитов, которые мы получили от API Twitter ».

API как уровень абстракции

Когда дело доходит до программного обеспечения, API-интерфейсы присутствуют буквально повсюду.API идут рука об руку с одной из самых фундаментальных концепций информатики: абстракцией. Абстракция — это просто способ упорядочить сложность системы, чтобы сложные действия можно было легко обрабатывать. Подумайте об этой абстракции, как об этих кнопках Amazon Dash Buttons, кнопочных платах с батарейным питанием, которые вы можете использовать для заказа скобок на Amazon. Вот как они выглядят:

IDG

Несколько примеров кнопок Amazon Dash. Закажите еще моющее средство или бумажные полотенца одним нажатием кнопки.

Вы заказываете кнопку Dash на Amazon и используете приложение на своем смартфоне, чтобы связать ее с вашей сетью Wi-Fi, учетной записью Amazon и продуктом, например, бумажными полотенцами вашей любимой марки. Затем, когда вы захотите заказать больше бумажных полотенец, просто нажмите кнопку. Кнопка Dash подключается к Интернету и отправляет сообщение для размещения заказа в вашей учетной записи. Через несколько дней к вашему порогу прибудут бумажные полотенца.

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

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

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

Общедоступные API-интерфейсы и интеграция API-интерфейсов

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

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

«Открытый» или «открытый» не следует толковать как «бесплатный» в этом контексте.Чтобы это работало, вам все равно нужно быть клиентом Marketo и Salesforce. Но доступность этих API делает интеграцию намного более простым процессом, чем это было бы в противном случае. ( InfoWorld имеет отличный список общедоступных API, о которых вам следует знать.)

Веб-сервисы и API

Вы можете вспомнить термин w eb services из начала нулевых и подумать, что идея открытого API звучит очень похоже. Фактически, веб-сервис — это особый вид открытого API, который соответствует довольно жесткому набору спецификаций, включая то, что они должны быть указаны на языке описания веб-сервисов (WSDL), вариант XML.

Web-сервисы предназначались для использования как часть сервис-ориентированной архитектуры (SOA). Как объясняется в блоге Nordic APIs, это дало веб-сервисам плохую репутацию, поскольку SOA никогда полностью не раскрывали свой потенциал. Достижения в технологиях, используемых для связи между сервисами, особенно в более легком и гибком REST, также несколько отстали от веб-сервисов в мире общедоступных API.

API-интерфейсы REST

Веб-службы изначально были разработаны для связи с использованием SOAP (Simple Object Access Protocol), протокола обмена сообщениями, который отправляет XML-документы через HTTP.Однако сегодня большинство веб-интерфейсов API используют REST — передачу репрезентативного состояния — в качестве архитектурного стиля.

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

В REST API ресурс может быть чем угодно, но примеры включают пользователя, список твитов и текущие результаты поиска твитов. Каждый из этих ресурсов адресуется по идентификатору ресурса , который в случае веб-API REST обычно является URL-адресом, например https://api.twitter.com/1.1/users/show?screen_name=twitterdev. Когда приложение запрашивает ресурс с использованием идентификатора, API доставляет текущее представление этого ресурса в приложение в формате, который приложение может использовать, например, изображение JPEG, страница HTML или JSON.

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

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

Примеры API

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

• Google API , которые позволяют подключать ваш код ко всему спектру сервисов Google, от Карт до Переводчика.API настолько важны для Google, что они приобрели Apigee, ведущую платформу управления API.
• Facebook API , которые позволяют программным способом получить доступ к социальной диаграмме Facebook и маркетинговым инструментам. (Компания ограничила только то, к каким пользовательским данным вы можете получить доступ через эти API-интерфейсы из-за последствий Cambridge Analytica и других скандалов.)

Чтобы действительно понять, как работают API, давайте глубоко погрузимся в два: Java API, который Java-разработчики используют для взаимодействия с платформой Java, и Twitter API, общедоступный API, с которым вы могли бы взаимодействовать. социальная сеть.

Java API

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

IDG

Документация API OpenJDK для метода сортировки списка. Компаратор — это параметр, определяющий порядок сортировки списка.

Twitter API

Twitter API — это веб-интерфейс JSON API, который позволяет разработчикам программно взаимодействовать с данными Twitter.В отличие от Java API, который включен в Java Development Kit, Twitter API представляет собой веб-API. Доступ к нему должен осуществляться путем отправки запросов через Интернет к службам, размещенным в Twitter.

С помощью веб-API, такого как Twitter, ваше приложение отправляет HTTP-запрос, как это делает веб-браузер. Но вместо того, чтобы доставлять ответ в виде веб-страницы, для понимания человеком, он возвращается в формате, который приложения могут легко проанализировать. Для этой цели существуют различные форматы, и Twitter использует популярный и простой в использовании формат JSON.(Если вы не знакомы с JSON, вы можете потратить несколько минут на его чтение.)

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

IDG

Документация по Search API Twitter.Здесь вы найдете все подробности, необходимые для запроса вселенной твитов, от доступных операторов поиска до формата ответов.

Дизайн API

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

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

IDG

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

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

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

Что такое API (интерфейс прикладных программ)?

An a pplication p rogram i nterface ( API ) представляет собой набор процедур, протоколов и инструментов для создания программных приложений.По сути, API определяет, как должны взаимодействовать программные компоненты. Кроме того, API-интерфейсы используются при программировании компонентов графического пользовательского интерфейса (GUI). Хороший API упрощает разработку программы, предоставляя все строительные блоки. Затем программист собирает блоки вместе.

Различные типы API

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

Большинство операционных сред, таких как MS-Windows, предоставляют API-интерфейсы, позволяющие программистам писать приложения, совместимые с операционной средой. Сегодня API также указываются на веб-сайтах. Например, API Amazon или eBay позволяют разработчикам использовать существующую розничную инфраструктуру для создания специализированных интернет-магазинов. Сторонние разработчики программного обеспечения также используют веб-API для создания программных решений для конечных пользователей.

Популярные примеры API

ProgrammableWeb , сайт, который отслеживает более 15 500 API, перечисляет Google Maps, Twitter, YouTube, Flickr и Amazon Product Advertising как одни из самых популярных API.Следующий список содержит несколько примеров популярных API:

1. API Карт Google: API Карт Google позволяет разработчикам встраивать Карты Google на веб-страницы с помощью интерфейса JavaScript или Flash. Google Maps API разработан для работы на мобильных устройствах и настольных браузерах.
2. API YouTube: API YouTube позволяют разработчикам интегрировать видео и функции YouTube в веб-сайты или приложения. API YouTube включают в себя YouTube Analytics API, YouTube Data API, YouTube Live Streaming API, YouTube Player API и другие.
3. Flickr API: Flickr API используется разработчиками для доступа к данным сообщества Flick по обмену фотографиями. Flickr API состоит из набора вызываемых методов и некоторых конечных точек API.
4. Twitter API: Twitter предлагает два API. REST API позволяет разработчикам получать доступ к основным данным Twitter, а Search API предоставляет разработчикам методы взаимодействия с данными поиска и тенденций Twitter.
5. API рекламы продуктов Amazon: API рекламы продуктов Amazon предоставляет разработчикам доступ к функциям выбора и поиска продуктов Amazon.