Успешное проектирование приложения для iOS

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

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

Проектирование приложения: никогда не думайте, что кодить дизайн – это легко

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

Представьте, что вы хотите отобразить верхнюю часть таблицы Менделеева:

Периодическая таблица элементов

В веб-документе вы описываете содержимое. Вы указываете, что хотите таблицу 7×18 со сплошной черной рамкой. Затем вы помещаете букву «H» в первую ячейку и делаете ей зеленый фон.

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

1. Нарисуйте сплошной зеленый квадрат размером X, начиная с точек (Y, Z).
2. Нарисуйте букву «H» размера Q в точке W, которая должна лежать в центре квадрата.
3. Нарисуйте одну черную линию под квадратом, который является нижней границей первой ячейки.

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

Проблемы кастомного дизайна

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

Проектирование приложения для экранов разных размеров

На момент написания статьи последняя версия iOS 12 поддерживает телефоны с размерами экрана от iPhone SE (568x320 pts) до iPhone Xs Max (896x414 pts). Однако эксклюзивные приложения для iPhone также можно открывать на iPad в режиме совместимости с iPhone.

Приложение iPhone в режиме совместимости на iPad

В режиме совместимости приложение отображается с размером экрана iPhone 4 (480x320 pts). К сожалению, это не единичный случай, это более распространенное явление, чем вы думаете.

Большинство обзорщиков App Store намеренно используют iPad для обзора приложений iPhone. Если дизайн приложения не полностью функционален на таком крошечном экране, заявка на добавление приложения в магазин будет немедленно отклонена. Хорошим примером может служить кнопка регистрации, которая не отображается на маленьком экране, что не позволит пользователю завершить процесс регистрации.

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

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

Анимации

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

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

Это делает их дорогостоящими для реализации. Почему? Давайте найдем ответ, основываясь на одном из шотов Dribbble из раздела «Популярное».

Красиво анимированный переход между экранами

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

Чтобы понять проблему, давайте сделаем краткий обзор навигации по нативным приложениям iOS, как описано в Human Interface Guidelines от Apple:

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

И специально для иерархических данных:

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

Панель навигации – простая концепция, знакомая пользователям iOS

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

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

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

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

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

Лучшая анимация с Lottie

Гораздо лучший подход к нативной анимации – использовать Lottie. Lottie импортирует и воспроизводит анимации, экспортированные из After Effects, с помощью плагина Bodymovin. Он поставляется бесплатно для iOS, а также для Android и веб-интерфейса.

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

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

Учет данных

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

На шоте, представленном ниже, у нас есть популярные курсы упражнений с короткими названиями. Однако, если бы курс «After running tensile» был популярен, не было бы никакого способа вписать его название в плитку. Там нет места для дополнительной строки текста, и, если обрезать, «After runn…» будет иметь нулевой смысл для пользователя.

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

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

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

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

К сожалению, представленный пользовательский интерфейс меняет соотношение сторон фотографии в зависимости от высоты устройства. Фото, которое может отлично подходить для вашего iPhone SE, может быть неудачно обрезано на iPhone 8 Plus вашего друга.

«Бесконечные представления»

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

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

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

Повторное использование ячеек в iOS

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

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

Перетаскивание между двумя «бесконечными представлениями»

Проектирование приложения: дизайн, который вы можете воплотить в жизнь

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

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

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

Об авторе 

Jakub – iOS-архитектор в EL Passion. Вы можете связаться с ним на GitHub, Twitter или в его блоге.

Официальные страницы EL Passion в Facebook, Twitter и Instagram.

Спасибо Sona Kerim.