Релиз iOS 11 стал поводом для беспокойства — многие эксперты, разработчики и пользователи заметили, что качество программ в нем заметно снизилось. В новой версии появилось много багов, проблем с производительностью и визуальных глитчей. Вот пример такого глитча в сообщениях при нажатии на сообщение и тапе на кнопку “Назад”.
Так как приложения становятся сложнее, а ожидания пользователей растут, эти небольшие баги могут сильно влиять на конечный продукт.
Что такое джанк?
Джанк — это неожиданные и отвлекающие визуальные ошибки. Обычно они появляются из-за дополнительной анимации или недостатка анимации.
Понятие “джанк” может относиться и к неверному поведению приложения. Помимо глитчей, это относится и к неотвечающим кнопкам, ошибкам загрузки или странным жестам. В этой статье я буду говорить в основном о визуальных глитчах.
Мотивация
Это же проблема кода, верно? Как дизайн может помочь избежать джанка в приложении?
Дизайнеры играют важнейшую роль. Определенные элементы интерфейса особенно опасны в плане джанка. Если дизайнеры знают, какие элементы вызывают ошибки, они смогут создавать более качественный дизайн. Мы обсудим некоторые распространенные источники джанка в iOS-приложениях и исследуем способы предотвращения проблем.
Навигационные переходы
Давайте начнем с распространенного элемента интерфейса — панели навигации.
Вот нормальная панель навигации:
Вот панель навигации с ошибками:
В ней видна дополнительная анимация темной области справа и недостаток анимации при нажатии кнопки “Назад”.
В чем дело? В этом случае панель навигации экрана Home полупрозрачна, а панель экрана New Screen непрозрачна.
Панель навигации от Apple поддерживает только определенное поведение. Если разработчик хочет переделать панель по-своему, то она не всегда будет работать корректно.
Дизайн навигационных переходов
Многие распространенные решения не вполне поддерживаются Apple. Это скрытие подчеркивающей серой линии толщиной в 1px, скрытие текста кнопки “Назад”, вставка дополнительных элементов под панель навигации и поддержка жеста перехода назад из других мест экрана.
Если дизайнеры не знакомы с тонкостями UINavigationController API, как они смогут избегать проблем с интерфейсом? Главный совет — сохранять постоянство дизайна на всех экранах. Если на каждом экране свой стиль навигационной панели, у вас будут сложности.
Клавиатуры
Мой опыт показывает, что клавиатуры — это самый распространенный источник ошибок. Оба показанных выше примера связаны с клавиатурой.
Вот ещё один пример. Обратите внимание, как работает анимация круга при выборе изображения, но при использовании стандартной клавиатуры происходит ошибка.
Дизайн клавиатуры
При работе с клавиатурой вы должны сохранять дизайн как можно проще. Половина экрана при этом скрывается, поэтому не нужно заполнять оставшееся пространство кнопками.
Обращайте внимание на анимации, сопровождающие появление клавиатуры, и не думайте, что у вас будет полный контроль над клавиатурой. Скрыть клавиатуру без анимации возможно, но это может вызвать ошибки.
Также обратите внимание на сторонние и иностранные клавиатуры. Если ваш дизайн хорошо работает со стандартной англоязычной клавиатурой, это не означает, что он будет работать без ошибок для всех. Высота клавиатуры неизвестна и может меняться.
Анимация с несколькими состояниями
Такие анимации интересно создавать, но несколько состояний могут стать причиной возникновения ошибок.
Вот пример такого сбоя:
Кнопка в App Store с неправильной анимацией.
У этой кнопки есть несколько состояний: обычно она превращается в индикатор загрузки.
Даже “нормальное” поведение может быть джанком.
Здесь мы уже можем понять, откуда возник баг с крутящейся кнопкой. Обратите внимание, что перед появлением синей полосы прогресса на этом месте вращается серый круг. Из-за ошибки в коде кнопка Open сразу переходит во вращающееся состояние. Проблема здесь — в слишком большом количестве состояний.
Дизайн анимации с несколькими состояниями
Анимации с несколькими состояниями повышают сложность. Если вы создаете такой элемент, продумайте все переходы и крайние состояния. Простые на первый взгляд вещи могут оказаться сложнее, чем вы думали.
Избавление от ошибок
Теперь давайте используем знания об источниках ошибок, чтобы оценить дизайн.
Вот незаконченный дизайн, который я создал некоторое время назад. Я думал о создании простого приложения для презентаций. Пользователь вводил бы данные для каждого слайда, а приложение бы автоматически создавало тему и внешний вид презентации.
Главной целью является средний экран, где пользователь может добавлять новые элементы, вводить текст, менять местами слайды и смотреть готовые слайды. Выглядит неплохо, да? Нет. Этот дизайн похож на минное поле.
Рассмотрим потенциальные источники ошибок:
- Разные навигационные панели и переходы между ними.
- Превью слайда, которое всегда остается выше клавиатуры.
- Интерактивная анимация при развертывании слайда.
- Прокрутка и анимация клавиатуры при добавлении большого количества строк текста.
- Анимация на основе состояний для выбора типа текста.
При этом мы должны обратить внимание на побочные эффекты всех возможных комбинаций. Этот дизайн возможно реализовать, но разработчику придется провести определенное количество времени, исправляя глитчи и конфликты состояний. Это приложение потребует значительного внимания к деталям и исправлениям возможных ошибок.
Вот набросок нового дизайна:
Средний экран разделен на три: экран для организации слайдов, экран для организации элементов и экран для редактирования одного элемента. Вместо кастомной анимированной кнопки для выбора типа элемента, пользователь может выбирать при помощи дефолтного элемента. Клавиатура используется только на последнем экране и её не нужно скрывать, так как используется только одно поле.
Хотя второй дизайн не так оригинален, он будет правильно работать и покажется привычным пользователю.
О кастомных дизайнах
Я не против исследования границ возможного и создания необычных интерфейсов. Мне нравятся новые эксперименты, но слишком часто кастомные дизайны оказываются завершенными на 90%. По разным причинам оставшиеся 10% становятся причиной проблем. Если дизайнеры будут знать о распространенных подводных камнях, они помогут разработчикам их избежать, что приведет к лучшему опыту для всех.
Итоги
Дизайнеры могут предотвратить ошибки, если знают их источники и подстраивают свой дизайн. Вот несколько советов по предотвращению джанка:
- Как можно раньше советуйтесь с разработчиками. Они смогут оценить сложность реализации дизайна и скажут вам о потенциальных проблемах.
- Упрощайте дизайн. Если вы рассмотрите все возможные состояния и переходы, то естественным образом перейдете к более простым решениям.