Руководства по разработке AR Google'а хороши, а вот Apple не дотягивают

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

Впервые любой, кто знаком с разработкой мобильных приложений, может создать захватывающий 3D-опыт с потенциальным охватом в полмиллиарда пользователей Android и iOS (вместо небольшого количества владельцев VR-гарнитур). Эти платформы - ARCore от Google и ARKit от Apple - демократизировали 3D-дизайн для масс.

Но энтузиазм быстро уступил место более практическим проблемам:

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

Чтобы ответить на первое беспокойство дизайнеров, Apple и Google быстро выпустили руководства по разработке дополненной реальности. Руководящие принципы Apple являются более скромными с точки зрения содержания и амбиций. Они выпустили их в разделе «Введение в дополненную реальность» в своих руководящих принципах пользовательского интерфейса. Руководство по разработке дополненной реальности Google (GARDG) привлекло наше внимание благодаря широкому кругу тем, которые, кажется, черпают вдохновение из реального опыта Google по разработке и созданию приложений, таких как AR Stickers и Just a Line.

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

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

Выбор объекта
Обусловленное поведение
Разветвляющиеся потоки сцен или раскадровки, основанные на поведении пользователя
Перемещение между сценами с помощью телепортации
Порталы
Физические жесты

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

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

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

Тем не менее, когда дело доходит до размещения объектов (самое основное взаимодействие в AR), в Руководствах Google делаются предположения об оптимальном диапазоне размещения объектов - в пределах досягаемости пользователя. Это то, для чего мы не видим причин для кодификации в настоящее время. А как насчет того, чтобы бросать объекты как метод размещения, указывать на них, захватывать и взаимодействовать с ними на расстоянии?

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

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

С их продолжающейся эволюцией, разумно ожидать, что руководящие принципы будут расти, чтобы отразить многие из областей интересов, о которых мы слышали. Тем временем дизайнеры могут заполнить пробелы, оставленные Google и Apple. У нас есть возможность самим создавать лучшие практики для 3D UX, и некоторые лидеры отрасли уже начали это делать. Например, Бушра Махмуд, дизайнер, в настоящее время работающий в Unity, выступила с инициативой разработать свои собственные обширные Рекомендации по разработке (на которые стоит обратить внимание), в то время как команды, подобные одной из Marino Software, загружают совершенно новые процессы путаницей из уже существующих инструментов.

Такая инициатива снизу имеет решающее значение, поскольку Рекомендации Apple и Google просто не успевают за миллионами творческих людей, которые экспериментируют и интегрируют новшества. К тому времени, когда гарнитуры станут широко доступными, различие между дизайном 2D и 3D UX будет окончательно стерто.

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

Руководства по разработке AR Google'а хороши, а вот Apple не дотягивают

Report Page