можно ли в мобильном приложении использовать негативные элементы
Безопасность данных в разработке мобильных приложений
При разработке мобильного приложения следует учитывать, что данные, которыми оперирует это приложение, могут представлять определенный интерес для третьих лиц. Степень ценности этих данных варьируется в широких пределах, тем не менее, даже наиболее простая приватная информация, например, пароль входа в приложение, требует проработки ее защиты. Особенно это важно в свете распространения мобильных приложений на все сферы электронных услуг, включая финансовые, банковские операции, хранение и передачу личных данных и так далее. Всем интересующимся — добро пожаловать под кат.
Все нижесказанное — исключительно мой опыт, безусловно, данные могут быть неточными, поэтому буду благодарен за любые поправки и дополнения к статье. Я не нашел исчерпывающих статей в сети на подобную тематику, которые бы собирали всю нужную (хотя бы базовую) информацию в одном месте, поэтому решил обобщить свой опыт в этой области на текущий момент времени.
Защита мобильного приложения
Основные виды атак на мобильное приложение:
Перечень основных уязвимостей приложений
Рассмотрим уязвимости общего характера, без привязки к конкретной платформе. Здесь и далее используется аббревиатура КВД — критически важные данные пользователей. К КВД относятся любые данные, которые не должны быть доступны третьей стороне, это касается как персональных данных пользователя (дата рождения, адрес проживания, личная переписка), так и его приватных данных (пароли, данные кредитных карт, номера банковских счетов, номера заказов и так далее).
Перечень основных уязвимостей следующий:
Использование незащищенных локальных хранилищ.
Хранение КВД в коде.
Применение алгоритмов с хранением приватного ключа.
Использование асимметричного алгоритма с приватным ключом, известным серверу.
Использование самописных алгоритмов шифрования и защиты.
Передача КВД во внешнюю среду в открытом виде.
Игнорирование факта наличия рутованных или зараженных устройств.
Хранение КВД в защищенных хранилищах, но в открытом виде.
Перевод части функционала во встроенные веб-движки.
Реверсивная инженерия алгоритмов, представляющих интеллектуальную ценность.
Специфика разработки мобильных приложений
Есть несколько общих для всех мобильных платформ моментов, которые следует соблюдать при разработке.
Защита пользовательским кодом
Функционирование клиент-серверного приложения
Работа с датами
Дополнительные рекомендации
Специфическая информация по платформе iOS
Рассмотрим доступные для разработчика хранилища данных при разработке под iOS:
Бинарные файлы (NSKeyedArchiver).
Связка ключей (Keychain).
Специфическая информация по платформе Android
Я слабо разбираюсь в платформе Android, поэтому нижеизложенный список — это краткое тезисное изложение базовых материалов, которые мне удалось найти по этой платформе:
Кроме того, нужно с осторожностью использовать доступные хранилища информации:
Базы данных (SQLite).
Заключение
Также стоит упомянуть, что количество применяемых уровней защиты зависит от конкретного приложения. К примеру, если приложение вообще не является клиент-серверным, не содержит никаких КВД, а также не оперирует ценными внутренними алгоритмами, то вообще нет смысла навешивать на него какую-либо защиту. Если же приложение ориентировано, например, на выполнение банковских операций, или хранение пользовательских паролей, то степень его безопасности должна быть наивысшей. Однако перечисленные ранее общие уязвимости мобильного сектора достаточно легко могут быть исключены из приложения, чаще всего это не вносит особых дополнительных затрат, если применение требуемого уровня защиты было начато на ранних этапах разработки приложения. А вот внедрение защиты пост-фактум в уже работающее приложение вполне может быть сопряжено со значительными затратами сил и времени разработчиков. Поэтому выбор и согласование уровня защищенности, а также перечня КВД в разрабатываемом приложении, должны выполняться на самых ранних этапах проектирования.
Чеклист по UX из 30 пунктов для мобильных приложений
Эта статья — напминалка о том, что нужно перепроверить в дизайне вашего приложения, прежде чем отсылать его на AppStore/GooglePlay. Список поделен на тематические блоки:
Статья переведена при поддержке компании EDISON Software, которая разрабатывает приложения и сайты, а также занимается пользовательскими интерфейсами.
1. Вход / Регистрация
Заставка показывается при запуске приложения. Это первое что видит пользователь, это создает первое впечатление о продукте, еще до начала работы.
Rider Launch Transition by Uber
Средний человек зарегистрирован в 90 онлайн-сервисах, которые требуют пароль. Поэтому часто пароли «забыватся». Согласно статистике 21% пользователей забываю пароль в течение 2 недель, а 25% забывают один пароль минимум раз в день. Если ваше приложение требует пароль, то позаботьтесь о форме восстановления пароля.
2. Первый опыт
3. Экран с приветствием/инструкция при первом запуске (Onboarding )
Onboarding — это термин UX-дизайна, означающий как понять пользователю что делать с вашим приложением, как в нем ориентироваться, куда нажимать. Хороший онбординг повышает вероятность того, что «вновь пришедшие» станут «постоянные».
Animated onboarding experience by Cuberto
4. Экран с оповещением об успешном подтверждение данных
Много мобильных приложений просят подтвердить почту/телефон. Оповещение об успешно выполненной операции подтверждения данных появляется после того, как пользователь выполнил все необходимое.
Для этого экрана жизненно важно обеспечить:
Контент — это то ради чего пользователи устанавливают большинство приложений. Важно продумать те места, куда пользователь умудрился заглянуть, где еще нет контента. Эти неизведанные места не должны быть пустыми.
Вместо того, чтоб оставлять пустоту, вставьте обучалку или инструкцию что делать дальше.
6. Дефолтная аватарка пользователя
95% по данным Jared M. Spool ) не меняют настройки по умолчанию. Это значит что у пользователей будет та аватарка, которую выбрали для них вы.
Cute default user avatar in Dropbox
3. Ежедневные взаимодействия
7. Экран запросов на разрешение
Когда пользователь открывает новое приложение, меньше всего они хотят увидеть множество всплывающих окон спрашивающих:
Notification Permission Dialog by Anton Tkachuk
8. Различные состояния для интерактивных элементов
Кнопки и прочие интерактивные элементы имеют несколько состояний. Очень важно продумать состояния «по умолчанию»/«нажата»/«не доступно» для каждого интерактивного элемента в вашем приложении.
Три состояния кнопки
Material design button by Vadim Gromov
Будет лучше, если ваши иконки будут единого стиля.
Tab bar icons in the Twitter app for iOS
10. Сообщения об ошибке
Лучшее сообщение об ошибке — это то которое не появляется вовсе. Лучше способ не допустить ошибку — это правильно проинструктировать пользователя заранее. Но если всё же ошибка возникла, то грамотное сообщение об ошибке не только учит пользователя как не допускать её в будущем, но и дает понять пользователю что о нем заботятся, а не игнорируют.
Error Interaction by Dwinawan
Вот несколько кейсов, для которых нужно продумать сообщения об ошибках:
11. Процесс загрузки
Хотя мгновенный ответ от приложения является лучшим, бывают случаи, когда вашему приложению придется «погрузиться». Плохое подключение к Интернету может вызвать медленный ответ, или сама операция может занять много времени. В таких случаях, чтобы минимизировать напряжение пользователя, вы должны заверить пользователей, что приложение работает по их запросу. Когда приложение не может уведомить пользователей о том, что для выполнения действия требуется время, пользователи часто думают, что приложение не получило запрос, и они пытаются снова. Из-за отсутствия обратной связи пользователь может усердно жать на все кнопки.
Анимированный индикатор «прогресса» является наиболее распространенной формой предоставления системного статуса пользователям, когда что-то происходит или загружается.
Smile loader for AI product design by Gleb Kuznetsov
12. Сообщение о том, что вы всё сделали правильно
Состояния успеха — это экраны, которые мы показываем пользователям, когда они выполняют задачи. Дизайнеры должны учитывать следующие типы состояний успеха:
Confirmation screen in Booking.com
Дизайнеры всегда должны стремиться минимизировать стоимость взаимодействия, удаляя ненужные действия. Автозаполнение упрощает ввод данных пользователем, уменьшая количество нажатий, которые пользователь должен выполнить, чтобы выполнить запрос.
14. Отменить операцию
Мы все совершаем ошибки, но когда дело касается взаимодействия с пользователем, крайне важно предоставить опцию, которая поможет пользователю восстановить важные данные.
Undo for Delete item. Image: Sashoto Seeam
Undo for sending email. Image: Tyler Beauchamp
Поскольку у многих групп разработчиков есть планы на глобальный охват, очень важно сделать локализацию/интернационализацию естественной частью процесса проектирования. Визуальные свойства элементов (например, размер) и UX-копии следует выбирать с учетом локализации/интернационализации.
Upvote button in different languages. Image: Chier Hu
Когда у пользователей возникает проблема, их первой естественной реакцией будет поиск решения в приложении. Поэтому хорошей идеей будет предоставить ссылку на раздел справки / часто задаваемых вопросов в приложении.
Help and Feedback by Alex Muench
Доступность позволяет людям со всеми способностями воспринимать, понимать и взаимодействовать с вашим продуктом. Вот отличная сводка от Lillian Xiao о том, что дизайнеры должны знать о доступности мобильных устройств.
4. Уведомления
18. Уведомления в приложении / Push-уведомления
Знаете ли вы, что паршивые уведомления являются основной причиной, по которой пользователи удаляют приложение?
Раздражающие уведомления — причина, по которой люди удаляют мобильные приложения (по мнению 71% респондентов).
Однако можно превратить этот UX-антипаттерн в нечто значимое и полезное как для бизнеса, так и для пользователя. Чтобы добиться хороших результатов с помощью уведомлений в приложении, дизайнерам нужна стратегия публикации, которая наилучшим образом подходит для мобильных устройств.
19. Настройки уведомлений
Всегда приятно предоставлять пользователям свободу выбора. В контексте мобильных уведомлений это означает предоставление возможности выбирать, какие уведомления они хотят получать.
Настройка параметров уведомлений в Slack
5. Параметры аккаунта
20. Инструмент для обрезки фото профиля
Позвольте пользователям не только загружать аватар, но и изменять его в соответствии с их потребностями прямо в вашем приложении.
Редактирование аватара от Scott Thomas
21. Экраны для просмотра/изменения личных данных
Разрешите пользователям редактировать свои личные данные прямо в мобильном приложении. Создавайте экраны для предварительного просмотра информации о доставке/выставлении счетов и внесения этой информации в редактируемый список.
Домашний адрес и адрес офиса доступны для редактирования. Выберите адрес доставки от Dhiraj S. Karki
Если ваше приложение требует логиниться, то и возможность разлогиниться тоже должна быть.
Logout in Facebook for iOS
23. Условия использования
Добавьте Условия использования в ваше приложение, чтобы избежать судебных исков.
24. Настройки конфиденциальности
Позвольте пользователям видеть, какие данные они отсылают вам и дайте им возможность выбирать.
Image: Vitaly Friedman
25. Отправить отзыв
Предоставляя быстрый способ обмена отзывами о вашем продукте, вы не только собираете ценные сведения о вашем продукте от реальных пользователей, но и заставляете их верить, что их отзывы ценны для вас.
Skype для iOS дает пользователям возможность «Оставить отзыв», «Сообщить о проблеме» или «Предложить функцию».
6. Лента
Мобильные дисплеи небольшие. Чтобы сэкономить место на экране, дизайнеры часто хотят оптимизировать отображаемую информацию и скрывать все, что не представляет ценности для пользователя. Вот почему многие экраны каналов имеют два состояния: состояние по умолчанию (экран, который видят пользователи при входе в канал) и состояние при прокрутке (когда пользователь проводит вверх, чтобы увидеть больше контента).
Обратите внимание, что область заголовка сворачивается при прокрутке. Craiglist Mobile animation by Aurélien Salomon
Поиск внутри приложения
27. Поведение «по умолчанию»
Ван необходимо решить, какой будет порядок результатов поиска «по умолчанию». Например, если вы разрабатываете страницу результатов поиска для приложения электронной коммерции, вам необходимо решить, следует ли сортировать выходные данные по наилучшему соответствию/цене/времени доставки.
28. Поделиться/Добавить в закладки
Позвольте пользователям делиться и добавлять в закладки то, что они нашли.
Like, Bookmark and Share options in the App AE by Martin Berbesson
29. Пустая формочка для «Нет результатов»
Что увидят пользователи, если они что-то искали, а результатов поиска нет? Экран «Нет результатов» не должен означать конец. Подскажите пользователю, какой нужно сделать следующий шаг.
Приложение Google Flights предлагает пользователям очистить все фильтры, чтобы найти рейс
8. AppStore/GooglePlay
30. Иконка для приложения
Вам нужно задизайнить запоминающуюся иконку для вашего приложения, что-то, что отражает суть вашего продукта и вызывает интерес у потенциальных пользователей.
iOS vs. Android: полное руководство по дизайну приложений
Если вы разрабатываете одновременно версии приложения для iOS и Android (Material Design), то это руководство станет вашим новым лучшим другом 😎.
Мы рассмотрим наиболее важные различия между iOS и Android для UX/UI-дизайнеров. Если вы уже создали приложение для одной платформы, здесь собрана большая часть того, что нужно знать, чтобы «перевести» его на другую платформу. Но! Это рекомендации, и практически всё, что я скажу, уже где-то опровергнуто, даже самими Apple/Google. Речь пойдет о «переводе» «iOS- мышления» на «Android-мышление» и наоборот.
Вот список тем, о которых мы поговорим. Пропустите его или дотошно изучите. Решение за вами.
UI-дизайн для iOS vs. Android: основные различия
Наиболее важные различия, которые UX/UI-дизайнеры должны учитывать при «переводе» приложения с iOS на Android или наоборот:
Прежде чем углубиться в эту тему, давайте ответим на один важный вопрос, это повлияет на всё, о чем пойдет речь далее…
Должен ли я делать приложения для iOS и Android разными?
Если кратко, то — нет.
Apple и Google — очень умные компании с бессчетным количеством пользователей. Они будут совершать UX-ошибки, как и все остальные компании. Но они не совершат вопиющих ошибок, определяя стандартный язык дизайна своих систем. Поэтому, хотя ниже я и представляю два способа реализации (способ iOS и способ Android), ни один из них не является неправильным. Если пользователи могут уверенно перемещаться по вашему приложению и работать с ним, никто не запрещает вам использовать вкладки в iOS или модальные окна в Android.
Эта статья написана в духе обучения «iOS-мышлению» или «Android-мышлению». И если ваша цель — создать такое приложение для обеих платформ, которое будет нативным для каждой из них, то это руководство вам очень поможет.
А теперь давайте углубимся в тему.
Сравнение навигации в iOS и Android
Навигация в верхней части экрана
Мы начнем в буквальном смысле с верхушки. У каждой платформы разные стандарты для того, что отображается в верхней части большинства экранов.
В iOS (опционально) действие вверху слева на странице почти всегда является действием «назад» — последовательно к предыдущему экрану (из «Шага 2» пользователь возвращается к «Шагу 1») или иерархически к родительскому экрану (из «Входящих» пользователь возвращается в «Почтовые ящики»). Кроме того, таким образом могут быть связаны не связанные изначально страницы. Заголовок страницы практически всегда присутствует, и он изначально большого размера, но уменьшается вместе с верхней панелью во время прокрутки (до прокрутки большой заголовок выравнивается по левому краю, во время прокрутки уменьшенный заголовок выравнивается по центру. — Прим. пер.). Единичное действие вверху справа на странице может отображаться как текстовая ссылка, а несколько действий — как несколько значков действия.
В Android заголовок страницы выравнивается по левому краю. Слева от заголовка страницы не должно быть ничего, но вы можете добавить кнопку «Назад» в двух случаях (во втором случае — при желании):
а) если страница является страницей верхнего уровня и в приложении есть кнопка-гамбургер (она появляется слева от заголовка);
б) если эта страница следует непосредственно за другой (не в иерархической последовательности).
Основные «пункты назначения»
Основные «пункты назначения» в приложении реализуются по-разному.
В приложениях для iOS они представлены в виде вкладок/табов в нижней части экрана:
Многие популярные сторонние приложения для iOS также соответствуют нескольким дополнительным правилам:
1. Любая вкладка, представляющая основное действие приложения (например, добавление новой фотографии в приложении для работы с фотографиями), располагается по центру.
2. Любая вкладка, относящаяся к профилю или настройкам, появляется последней.
3. Поиск находится на втором месте.
С другой стороны, в стандартных приложениях для iOS:
Самое большое отличие приложений для Android состоит в том, что одни и те же основные «пункты назначения» в большей степени распределены по всему интерфейсу — часто между: (a) кнопкой-гамбургером, (b) панелью поиска, (с) вкладками или (d) плавающей кнопкой действия. Мы рассмотрим все эти 4 случая в следующих разделах. Да, и обратите внимание: Android совсем недавно начал использовать навигацию снизу аналогично тому, как это реализовано в приложениях для iOS, — так что в этом у приложений для Android и iOS может не быть никаких существенных различий.
Источники: iOS панель вкладок, Material Design принципы навигации (здесь больше теории).
Вторичная навигация
В iOS навигация, которая не поместилась в меню в нижней части экрана, может размещаться на универсальной вкладке «Еще» (More) или же в верхнем левом или в верхнем правом углу экрана.
В Android вторичная навигация отображается в виде списка в боковом меню, доступном при нажатии на кнопку-гамбургер.
Примечание: хотя Apple не поощряет использование кнопки-гамбургера (или ее использование в приложениях для iOS по умолчанию), во многих сторонних приложениях для iOS она есть, и это просто ваш выбор — использовать ее или нет. Лучшей практикой считается не скрывать важное, потому что очевидное всегда побеждает.
Источник: Material Design Navigation drawer.
Возврат к предыдущему экрану
В iOS можно вернуться к предыдущему экрану четырьмя способами, в зависимости от контекста.
Что такое модальные и полноэкранные окна? Сейчас расскажу.
Модальное окно — это задача с одним экраном, которая появляется по свайпу вверх и располагается поверх предыдущего экрана, который лишь немного виден на заднем плане. Чтобы закрыть модальное окно, нужно свайпнуть вниз или нажать кнопку «Назад» наверху.
Полноэкранное окно — это медиафайл, например фотография или видео, занимающий весь экран. И в iOS, и в Android его можно закрыть свайпом вниз.
В Android возвратиться к предыдущему экрану намного проще: в версии 10 и более новых версиях достаточно просто свайпнуть от любой стороны экрана к его центру. В версии 9 используйте кнопку «Назад» в нижнем левом углу экрана.
iOS vs. Android: дизайн элементов управления
Главные кнопки призыва к действию
В iOS главная кнопка на экране обычно расположена в верхнем правом углу.
В Android главная кнопка на экране в большинстве случаев расположена в нижнем правом углу в виде FAB (англ. floating action button — плавающая кнопка действия. — Прим. пер.).
Стоит отметить, что для каждой платформы могут быть свои исключения. Давайте поговорим о них.
Иногда в iOS главные кнопки на экране могут располагаться на нижней панели инструментов. Apple утверждает, что она очень сильно отличается от панели вкладок. В Android можно встретить такие кнопки в верхней части экрана.
Поиск
И в iOS, и в Android поиск — это обычный, но очень гибкий инструмент. Иногда поиск используется как основная функция приложения, в других случаях поиск практически не используют, но чаще всего применяется компромиссный вариант. В каждой платформе поиск реализован достаточно гибко. Давайте рассмотрим общие парадигмы.
Одно из различий между реализацией поиска в iOS и поиском в Android:
Если поиск является важной функцией, то на обеих платформах панель поиска отображается сразу. При нажатии на нее обычно открывается отдельный экран.
Если поиск не является главной функцией и им нечасто пользуются, то получить доступ к нему можно другими способами.
В iOS поиск обычно отображается среди основных вкладок или как одно из действий в верхней навигационной панели.
В Android вы также можете увидеть поиск на верхней панели контекстных действий.
Источники: iOS search bars, Material Design search pattern.
Меню действий
В iOS меню действий можно вызвать нажатием на любую кнопку или попыткой выполнить любое действие. Меню появляются снизу вверх, на них легко нажимать пальцами.
В Android же нижнее меню действий появляется только после нажатия на пиктограмму «кебаб-меню» (три точки, которыми в Android обозначаются дополнительные параметры. — Прим. пер.) и обычно — только когда доступно много возможных действий.
У обеих платформ есть стандарты для всплывающих меню.
Если в iOS 13 вы нажимаете на элемент или удерживаете его, то в «контекстном меню» показываются подходящие действия. Когда отображается «контекстное меню», фон размывается.
В Android многие меню появляются прямо на элементе. В новых версиях Android меню закрывает пиктограмму «кебаб-меню».
Элементы управления выбором
На мобильном устройстве стоит отличать выбор из нескольких вариантов от выбора из большого количества вариантов.
В iOS для реализации выбора из нескольких вариантов используйте элемент управления picker («подборщик» — Прим. пер.). Его можно закрепить внизу на экране (как показано выше) или встроить в контент (см. «Выбор даты»).
Для выбора из нескольких вариантов в Android обычно используется раскрывающееся меню (появляется рядом с выбором) или модальное окно со списком вариантов (появляется в центре экрана, фон затемняется).
Для длинных списков вариантов или для случаев, когда возможен множественный выбор, и в iOS, и в Android можно использовать отдельный «экран выбора». Одна из самых больших ошибок начинающих дизайнеров — попытка уместить большой список вариантов с одиночным выбором в модальное окно, не выделяя для этого списка отдельный экран.
Выбор даты
В iOS выбор даты похож на любой другой элемент выбора (picker control), но с отдельными колонками для месяца, даты и (опционально) года.
В Android есть элемент выбора даты, который можно настроить в процессе разработки: включить/выключить выбор года или же позволить пользователю самому решить, хочет ли он включить выбор года.
Источники: iOS picker, Android date picker (обратите внимание на различия в спецификации Material Design).
Вкладки
В iOS отсутствуют вкладки в привычном понимании, но есть сегментированные кнопки, которые
позволяют реализовать функциональность вкладок.
На Android вкладки выполнены в привычном виде.
Источники: iOS segmented controls, Material Design tabs.
Отмена действия
В iOS уведомления появляются в центре экрана, но они также могут всплывать в нижней части экрана (на языке iOS это action panels). Деструктивные действия (например, удаление чего-либо) выделены красным цветом.
На Android некоторые уведомления появляются в центре экрана. Однако для уведомлений, которые не требуют действий от пользователя и исчезают через несколько секунд, можно использовать «снек-бары» (snackbars). «Снек-бары» позволяют сообщить пользователю, что его действие было успешным, а также на них можно предложить выполнить одно действие или выбрать одно из двух действий. Это делает их идеальным решением для функции «Отменить». Я бы предпочел давать пользователям возможность отменить ошибочное действие, чем спрашивать их дважды перед каждым важным действием.
Источник: iOS Undo, Material Design snackbars.
IOS vs. Android: типографика
Шрифт по умолчанию
Необязательно использовать в приложениях для iOS и Android системные шрифты по умолчанию, но полезно знать, что это такое, — например, на случай, если вы захотите сделать приложение в стиле нативного.
В iOS системный шрифт называется SF. Это компактный шрифт, позволяющий сделать текст удобным для чтения даже на небольших экранах. Вы можете скачать его здесь.
Системный шрифт Android называется Roboto. Он очень похож на SF, но есть пара отличий — буквы выше и расстояние между ними немного больше. Этот шрифт можно скачать здесь.
Также в Android часто используется шрифт Product Sans от Google, который недоступен для использования сторонними разработчиками.