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

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

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

Содержание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вывод

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

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

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

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

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

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

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

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

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, и наоборот. 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

наши ошибки и 16 советов как их не повторить / Хабр

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

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

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

Изображение №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: поиск игр (пролистать в самый конец ленту поиска игр)

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

Изображение №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-дизайн должен быть предельно функциональным и буквально работать со скоростью мысли. Идеальный вариант, когда интерфейс представляется достаточно простым для новых пользователей. В этой статье будут описаны проверенные способы работы с интерфейсами.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В этом материале — проверенные способы сделать удобный интерфейс… или найти готовый.

https://gbcdn.mrgcdn.ru/uploads/post/49/og_cover_image/a262ccafd177604f908186e9937e6993

Как вы приступаете к созданию интерфейса? Насколько сильно вы ориентируетесь на web-интерфейсы? Помните о 5 самых важных аспектах проектирования UI для мобильных приложений.

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

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

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

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

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

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

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

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

3. План потоков

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

Пример: банковское приложение. Сценарий: настройка пополнения депозитного счета.

Автоматическое пополнение депозита
[Установить]
Выберите частоту пополнения
[Раз в месяц] [Два раза в месяц] [Раз в несколько недель] [Каждую неделю]
Один раз в месяц
[Выберите дату]
Подтвердить
Введите сумму
[Введите сумму]
[Установить автоматическое пополнение счета]

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

Mockflow
iPhone Mockup
Mockup Builder
Fluid UI

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

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

По этой причине навигационные кнопки, как правило, находятся в нижней части экрана:

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

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

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

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

Именно так выглядят схемы наиболее удобных для человека жестов.

94% времени пользователи держат смартфон в вертикальном положении.

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

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

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

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

Бонус: web-помощники для проектировщика интерфейсов приложений

1. Как подобрать хорошо сочетающиеся цвета для мобильного приложения? Используйте эти сервисы:
getuicolors.com
www.coleure.com
bootflat.github.io/color-picker.html

2. Изучите готовые примеры отличных интерфейсов, чтобы лучше понять необходимый уровень:
www.mobile-patterns.com/

3. Используйте готовые мокапы:
www.premiumpixels.com/tag-index/
uispace.net/all-psd
dbfreebies.co/mobile

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

Как адаптировать интерфейс приложения под разные платформы — Офтоп на 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)

Интерфейсы прикладного программирования или 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 может ограничить доступ, чтобы минимизировать угрозы безопасности. Кроме того, во время обмена заголовки 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®

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

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

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

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

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

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

Что такое 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., мобильные разработчики), они документированы и имеют версии таким образом, чтобы пользователи могли иметь определенные ожидания в отношении его обслуживания и жизненного цикла.
• Поскольку они гораздо более стандартизированы, они имеют гораздо более строгую дисциплину в отношении безопасности и управления, а также контролируются и управляются для обеспечения производительности и масштабирования
• Как и любой другой компонент производимого программного обеспечения, современный API имеет свой собственный жизненный цикл разработки программного обеспечения ( SDLC) проектирования, тестирования, сборки, управления и управления версиями.Кроме того, современные API хорошо документированы для использования и управления версиями.

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

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

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

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

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

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

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

 

    

      

            

              …
            
          
        
      
 

  .dialog {
    позиция: абсолютная;
    осталось: 50%;
    маржа слева: -315 пикселей;
    ширина: 630 пикселей;
    z-индекс: 100001;

}
.dialog .body {
    фон: url (/img/dialog.png) 0 0; / * полупрозрачное изображение в формате .png * /
    отступ: 40px 13px 10px 40px;
}