Выходные с Adobe XD: Всё, что вам нужно про проектирование мобильного приложения
Выходные — идеальное время, чтобы попробовать новые инструменты и креативные приёмы; Отсутствие давления со стороны боссов или клиентов, и (надеюсь) без переадресации на электронную почту или телефон. В эти выходные, между делом, попробуйте создать мобильное приложение в Adobe XD, со своими друзьями или семьёй. XD — универсальный инструмент от Adobe для UX/UI дизайна, прототипирования и обмена опытом своего веб-сайта или мобильного приложения.
Чтобы вы могли работать на много быстрее, мы отобрали для вас некоторые из лучших наборов пользовательских интерфейсов, учебные руководства и ресурсы, чтобы научить вас, как делать дизайн мобильного приложения в XD.
Четыре шага для разработки мобильного приложения
Шаг 1: Скачать Adobe XD и Wires
Поместите свои лучшие идеи в превосходный пользовательский опыт, загрузив последнюю версию Adobe XD и бесплатный комплект вайрфреймов. Комплект Wires включает в себя полный набор готовых к использованию компонентов, шаблонов и многое другое.
Шаг 2: Дизайн
Следуйте этому учебному руководству, чтобы узнать, как создать мобильное приложение в XD. Вы узнаете основы XD, в том числе создание артбордов, разработка иконок и заставок, импорт изображений и работа с повтором сетки (Repeat Grid).
Шаг 3: Прототип
Следуйте этому учебному руководству, чтобы превратить свой дизайн в интерактивный прототип. Свяжите артбоды друг с другом, переключитесь от дизайна к прототипу и просмотрите свой результат.
Шаг 4: Совместное использование
В этом уроке вы узнаете, как поделиться своим прототипом, чтобы получить обратную связь, предварительно просмотреть на мобильном устройстве и поделиться спецификациями дизайна с разработчиками.
Шаг 5: Добавить финальные штрихи
Загрузите эти бесплатные ресурсы UI, которые помогут вам усовершенствовать опыт любого, проектируемого вами, мобильного приложения.
Жаждете большего?
Поиграйтесь с этими комплектами пользовательского интерфейса
Посмотрите на Adobe XD в действии с проектом AdobeLive Behance
Behance может стать отличным ресурсом, чтобы посмотреть, что возможно с Adobe XD. Ознакомьтесь с этим красивым примером действенного UX дизайна, созданного Bahdis Mousavi и Rolf Jensen в Adobe XD.
Mousavi и Jensen использовали Adobe XD, чтобы создать мобильное приложение для салона красоты, которое позволяет пользователю отслеживать определенного стилиста, парикмахера или визажиста, и просматривать график их работы и портфолио. Также приложение пользователям позволяет пользователям оставлять отзывы определённым мастерам, о предоставленных услугах клиентам, тем самым решая две ключевые проблемы в индустрии услуг красоты: Пользователи могут оценивать конкретного мастера, а не заведение, плюс пользователь всегда может отслеживать предпочтительных для себя профессионалов, даже если они меняют салоны.
Этот проект Behance включает исходный файл XD, поэтому вы можете скачать и воспроизвести его, чтобы просмотреть все элементы, которые вошли в интерактивный прототип Mousavi и Jensen.
Следите за процессом UX дизайна в трансляции Трэвиса Нильсона
Когда вы только готовитесь увидеть, насколько мощный Adobe XD, в процессе UX дизайна, трансляции AdobeLive от Трэвиса Нильсона, переполнены отличными идеями и советами. Трэвис Нильсон — дизайнер взаимодействия с продуктом в Google, писатель, подкастер и ютубер, увлечённый UX дизайном. В следующих трёх видео, Трэвис покажет, как задействовать весь процесс проектирования UX, от планирования до рисования эскизов и, окончательного проектирования, прототипирования и построения готового продукта.
Видео 1: Макет приложения «Instagram для подкастов»
В первом видео Трэвис использует Adobe XD для создания макета приложения «Instagram для подкастов».
Разработка мобильных приложений на Adobe Flash + AIR: обзор возможностей
Недавно замечательная flash-игра Machinarium заняла 1 место в рейтинге платных игр для iPad. Тем не менее много талантливых разработчиков flash-игр с опаской смотрят в сторону мобильных платформ. На русском языке информации по теме крайне мало. Надеюсь эта статья немного улучшит положение вещей. Желаю приятного прочтения.
Изначально Adobe AIR задумывалась как платформа для настольных приложений. Однако сейчас она поддерживает разработку stand-alone приложений для мобильных устройств, настольных компьютеров, домашних цифровых устройств. Такой широкий охват делает ее привлекательной платформой для разработки. В то же время каждая среда имеет свою уникальную специфику, которую надо учитывать.
Например мобильные приложения чаще всего запускаются на небольшие промежутки времени. Пользовательский интерфейс таких приложений должен быть удобен для использования на маленьких экранах, масштабироваться для корректного отображения на планшетах и поддерживать различную ориентацию устройств. Он должен работать на тачскринах и использовать программные и аппаратные возможности, уникальные для конкретного класса устройств. Кроме того надо учитывать требования к памяти и графике.
Эта статья описывает возможности, предоставляемые AIR разработчикам приложений для смартфонов и планшетов под управлением iOS, Android и Blackbery Tablet OS.
Экраны
Пожалуй первым и наиболее очевидным предметом рассмотрения является экран мобильного устройства. Он относительно небольшой как в плане физических размеров, так и в плане количества отображаемых пикселей и характеризуется большой плотностью (в пикселях на дюйм). Различные устройства имеют различные комбинации плотности пикселей и физических размеров. Кроме того само устройство можно удерживать как в портретной так и в пейзажной ориентации.
Мобильные приложения не обязаны поддерживать вращение экрана, но вы должны помнить, что не у всех мобильных устройств портретная ориентация (высота больше ширины) используется по-умолчанию. Приложения, которые не заинтересованы в возможности автоматического вращения экрана, могут отказаться от нее установив в значение flase в дескрипторе приложения. И напротив, вы можете установить в true и слушать события StageOrientationEvents у Stage.
Сенсорный ввод
С момента, когда приложение отрисовалось на экране, оно как правило уже готово принимать пользовательский ввод. Для мобильного приложения это означает ввод посредством тачскрина.
AIR автоматически сопоставляет событиям мышки простые однопальцевые жесты, такие как нажатие одним пальцем на кнопку (tap). Это позволяет писать код, который без дополнительных изменений работает одинаково как на мобильных устройствах, так и на настольных компьютерах.
Ввод текста
Мобильные устройства с программной клавиатурой (т.е. отображаемой на экране, без физических клавиш) требуют особого внимания. Хотя такая клавиатура присутствует не везде, но использующие ее устройства начинают преобладать, и вы должны убедиться, что все работает хорошо. 
При отображении, программная клавиатура закрывает собой часть экрана. Чтобы учесть это, AIR сдвигает Stage таким образом, чтобы оставались одновременно видны и поле ввода и клавиатура, скрывая верхнюю часть приложения за пределами экрана. Такое поведение можно отключить и реализовать свое собственное. Для этого нужно установить параметр softKeyboardBehavior в дескрипторе приложения в значение none (значение по-умолчанию — pan).
Поле Stage.softKeyboardRect хранит размеры области, занимаемой программной клавиатурой. Слушайте событие SoftKeyboardEvent, чтобы знать, когда это значение изменяется.
Приложению, как правило, не надо заботится об открытии программной клавиатуры, это происходит само по себе, когда текстовое поле получает фокус. Однако, можно запросить автоматическое открытие клавиатуры для любого InteractiveObject, когда тот получает фокус (свойство InteractiveObject.needsSoftKeyboard) или открыть ее самостоятельно, вызвав InteractiveObject.requestSoftKeyboard(). Данные API не окажут никакого эффекта на устройствах, не поддерживающих программную клавиатуру.
Датчики
Как отмечалось ранее, акселерометр может быть полезен, когда вы хотите узнать фактическое положение устройства в пространстве, а не просто логическую ориентацию. Акселерометр позволяет превратить ваше устройство само по себе в средство ввода наподобие джойстика. Многие приложения используют эту возможность.
Оба описанных API дают возможность задать интервал опроса датчиков, т.е. частоту, с которой соответствующим слушателям будет отправляться актуальная информация. Стоит уточнить, однако, что выставленная частота не гарантируется, и может зависеть от различных факторов, таких как, например, аппаратные характеристики устройства.
Отображение web-контента
Современная среда выполнения должна содержать средства поддержки HTML-контента. В AIR для этого присутствует StageWebView API. StageWebView предоставляет AIR-приложениям доступ ко встроенным возможностям устройства по отображению HTML. Стоит отметить, что так как StageWebView использует HTML-движок самой платформы, то одинаковое отображение на разных платформах не может быть гарантировано.
Еще одним следствием использования нативных средств является то, что содержимое StageWebView не интегрировано со списком отображения приложения. Однако это содержимое может быть сохранено как растровое изображение методом drawViewPortToBitmapData(), а затем помещено в список отображения. Это можно использовать, например, для создания скриншота страницы или создания эффектов плавного перехода.
Для тех, кто знаком с HTMLLoader API в AIR, стоит отметить, что StageWebView не является его заменой. HTMLLoader содержит встроенную поддержку HTML и допускает размещение HTML и JavaScript, выполняемых вне песочницы браузера. StageWebView работает с HTML и JavaSctipt контентом в рамках традиционной песочницы браузера.
Если вы захотите отправить пользователя из своего приложения в браузер или приложения вроде YouTube или Google Maps, используйте navigateToURL().
Изображения
Когда разговор заходит о получении фотоснимков, не стоит вопрос “умеет ли устройство фотографировать”, а стоит другой: “сколько камер в этом устройстве?”. AIR для мобильных устройств включает API позволяющие работать как непосредственно с камерой, так и с уже полученными фотографиями.
Классы CameraUI и CameraRoll
Функционал встроенной камеры доступен через класс CameraUI. Как можно догадаться из названия, класс отличается от похожего класса Camera тем, что работает с пользовательским интерфейсом камеры а не непосредственно с ней. В зависимости от устройства это может выражаться в возможности пользователя выбирать между фото- и видеосъемкой, указывать разрешение снимков, включать/выключать вспышку, переключаться между фронтальной и тыльной камерами и т.п.
Однако мобильные устройства не только делают снимки, но и хранят их. Библиотека сделанных пользователем фотографий доступна через класс CameraRoll. Метод browseForImage() может быть использован для открытия стандартного диалога выбора изображения из библиотеки. Кроме того в эту область можно писать свои данные при помощи метода addBitmapData().
Класс MediaPromise
CameraUI и CameraRoll возвращают медиаконтент с помощью события MediaEvent. В нем нет ничего необычного, за исключением поля data, которое имеет тип MediaPromise, через которое доступна соответствующая информация.
Как следует из названия, MediaPromise обещает предоставить содержимое, однако совсем не обязательно хранит его в себе. Это важный нюанс, поэтому стоит уделить несколько минут на его понимание.
Помещать ли медиафайл в память или работать с ним прямо с запоминающего устройства зависит от нескольких факторов. Например видеоролик обычно имеет большой размер и помещать его целиком в память нецелесообразно, т.к. ее как обычно не очень много. С другой стороны, только что сделанное фото и так уже находится в памяти, оно не так велико как видео и с ним можно работать непосредственно из памяти.
Класс MediaPromise является оберткой, призванной упростить работу с этой неопределенностью, предоставляя доступ к медиаобъекту посредством единого интерфейса. Если приложение хочет работать с объектом прямо с запоминающего устройства, проверить его наличие там можно через MediaPromise.file (должно быть не null).
Если приложение пожелает обрабатывать медиаобъект в памяти, он всегда может быть прочитан через поток, доступный с помощью MediaPromise.open(). MediaPromise автоматически вернет содержимое медиаобъекта, независимо от того, где он находится — в памяти или на запоминающем устройстве. При использовании open() не забудьте проверить MediaPromise.isAsync, чтобы определить вид потока.
Наконец, если понадобится напрямую поместить медиафайл в список отображения, избегая лишнего копирования в коде, в классе Loader есть метод Loader.loadFilePromise(). Как видно из названия он работает с любыми FilePromise (MediaPromise реализует интерфейс IFilePromise).
Жизненный цикл приложения
На мобильных устройствах у приложений мало возможностей для управления своим жизненным циклом. Они не могут запускаться сами, а лишь при непосредственном участии пользователя (например с домашнего экрана или через URL, привязанный к приложению). В любой момент приложение может быть отправлено в фоновый режим, а затем и вовсе остановлено (обычно это происходит, когда текущему активному приложению не хватает ресурсов).
На некоторых мобильных платформах NativeApplication.exit() неприменима (inoperable, “no-op”). Вместо того, чтобы сохранять свое состояние при выходе, приложениям следует делать это при переходе в фоновый режим и/или через определенные промежутки времени.
Приложение получает события DEACTIVATE и ACTIVATE соответственно при переходе в ждущий режим и возвращении из него. AIR помимо этого дополнительно предпринимает некоторые специфические действия, детали зависят от платформы. 
Фоновое поведение в Android
На андройде приложения стремятся выпонять как можно меньше работы в фоне, однако жестких ограничений нет. Когда AIR-приложение переходит в фоновый режим, частота кадров снижается до 4 fps, и, хотя обработка событий продолжается, фаза рендеринга в цикле обработки событий опускается.
Таким образом, AIR-приложение на Android может в фоне выполнять такие задачи как скачивание/загрузка файлов, синхронизация информации. Тем не менее, приложение при переходе в фоновый режим должно самостоятельно предпринимать дополнительные шаги для уменьшения частоты кадров, отключать ненужные таймеры и.т.п.
Фоновое поведение в iOS
В iOS у приложений нет реальной многозадачности. Приложения должны указывать, что они намереваются проявлять определенную активность в фоне (например удерживать voip-звонок или докачивать файл)
AIR не поддерживает такую модель работы, поэтому когда приложение переходит в фоновый режим, оно просто ставится на паузу. Это значит, что частота кадров выставляется в 0 fps, события не обрабатываются, рендеринг не происходит. Состояние приложения тем не менее хранится в памяти и восстанавливается при выходе из фонового режима.
Производительность
Чтобы достичь хорошей производительности вашего приложения, необходимо внимательно подходить ко всем его аспектам.
Время запуска
Уменьшение времени запуска — непростая задача, т.к. запуск как правило затрагивает множество сторон приложения. Прежде всего направьте усилия на уменьшение количества выполняемого кода, нежели на его ускорение.
Например, вы пишете игру и хотите отобразить на первом экране таблицу очков, хранящуюся локально. Выполнение этого кода может оказаться на удивление затратным. Поскольку код будет выполняться впервые, возникнут издержки, связанные с его интерпретаций/компиляцией, и выполнение пройдет чуть медленнее, чем обычно работает ActionScript-код в steady-state. Во-вторых, затраты на чтение информации из файловой системы. И наконец, затраты на позиционирование и отображение информации на экране.
Вместо этого, рассмотрите возможность выполнить всю эту работу уже после того, как первый экран отобразился. А затем, пока пользователь занят разглядыванием всех достоинств вашего арта, вы можете подготовить таблицу очков и отобразить ее при помощи анимации.
В целом подход к оптимизации такой: прежде всего тщательно обдумайте какой код и когда должен выполняться, вместо того, чтобы биться над скоростной оптимизацией. Важна субъективная производительность, ощущаемая пользователем: пользователи замечают задержки, когда их насильно заставляют ожидать завершения какого-либо процесса.
Рендеринг
Применение графических процессоров (GPU) изменило подход к оптимизации рендеринга. При рендеринге с использованием CPU работать с большими объемами пикселей — расточительно, целесообразнее использовать математическое описание форм объектов и их преобразование, и лишь после этого отрисовывать. Это традиционный подход, который используется в AIR для работы с векторным содержимым.
GPU, напротив, используя конвеерную обработку, может черезвычайно быстро оперировать большими массивами пикселей, а вот с векторными изображениями дела обстят значительно хуже.
AIR позволяет взять лучшее из обоих подходов. Вы можете использовать все возможности flash по работе с векторными изображениями, а затем, закешировав результат как набор растровых изображений, эффективно отрисовать его на экране. Используйте BitmapData.draw() для этих целей.
Отметим также, что остается возможность использовать заранее подготовленные растровые изображения, вместо того, чтобы получать их из векторной формы на лету. Однако, это не так эффективно, в силу многообразия размеров и плотностей экранов мобильных устройств.
Память
Хотя современные мобильные устройства и обладают приличным количеством оперативной памяти, важно помнить что они используют несколько другую модель управления памятью нежели традиционные настольные операционные системы. На десктопах, если память заканчивается, часть данных может быть временно выгружена на диск, а затем возвращена обратно в память. Это позволяет операционной системе держать запущенными почти неограниченное количество программ одновременно.
На мобильных устройствах такой подход, как правило, неприменим. Если запрошенный размер памяти превышает доступный на данный момент, фоновые приложения вынуждено завершаются, высвобождая таким образом память. Если запрос на выделение памяти все еще не может быть удовлетворен, тогда запрашивающее приложение вынуждено прекратить свою работу.
Это влечет следующие следствия. Во-первых, необходимо иметь четкое представление о занимаемой вашим приложением памяти. Во-вторых, чтобы повысить шансы остаться запущенным, приложение должно постараться занимать как можно меньше памяти, находясь в фоновом режиме.
Обе эти задачи могут быть достигнуты за счет явного управления памятью из приложения. Сначала это может показаться странным, ведь для этих целей существует сборщик мусора. Однако лучше думать о нем, как о механизме, который только очищает мусорную корзину, однако мусор в эту корзину вы должны отправлять сами.
Первый шаг на пути к явному управлению памятью — убедиться, что вы очищаете все ссылки на объект, если он больше не нужен. Вот пример: предположим, что у нас есть приложение, читающее при запуске XML-файл с настройками. После того, как настройки прочитаны и применены, в памяти хранится ссылка на корень дерева и соответственно связаное с ней дерево XML, которое нам уже не нужно. В таком случае нужно явно присвоить значение null ссылке на корень дерева, позволяя таким образом сборщику мусора освободить память.
Явное управление памятью также важно в случае работы с множеством однотипных объектов. Например приложение, подгружающее набор изображений, если оно написано неграмотно, и если этот набор достаточно большой, обязательно столкнется с нехваткой памяти. И наоборот, если программно ограничить максимальное количество изображений, пребывающих в памяти одновременно, проблем с памятью можно избежать. В нашем примере можно удалять старое изображение перед подгрузкой нового или циклически перезаписывать фиксированное количество изображений, находящихся в памяти.
Хранилище
Мобильные устройства предоставляют доступ к локальной файловой системе, где приложение может хранить свои настройки, документы и т.п. Как правило, приложение должно рассчитывать на то, что данные доступны только ему, и нет возможности делиться этими данными с другими приложениями. На всех устройствах хранилище доступно через свойство File.applicationStorageDirectory.
Addroid, помимо того, предоставляет дополнительную возможность использовать файловую систему на SD-карте, доступную по пути “/sdcard”. В отличие от основного хранилища, она доступна для чтения и записи всем приложениям на устройстве. Следует однако помнить, что SD-карта может быть извлечена из устройства или быть вставлена, но не смонтирована.
Учитывая распространенность камер на мобильных устройствах, не стоит забывать, что есть еще специальное общее хранилище для фотографий. Доступ к нему можно получить через CameraRoll API, упомянутое ранее в разделе “Изображения”. И хотя на некоторых платформах доступ к фотографиям можно получить непосредственно через файловую систему, это плохо сказывается на портируемости приложения и является плохой практикой.
Развертывание
В мире мобильных устройств распространение приложений происходит в основном через специальные магазины (app marketplaces). Эти магазины включают в себя специальный функционал на устройствах, для поиска, установки и обновления приложений.
Все магазины мобильных приложений требуют, чтобы приложение было подписано. Для iOS сертификаты выдает Apple. Для Android-устройств разработчики сами создают сертификаты, действительные как минимум 25 лет, и которыми они должны подписывать каждое свое приложение и обновления к нему. Таким образом, если вы публикуете свое приложение на разных площадках, вам нужно оперировать несколькими сертификатами.
Что дальше?
Разработка с использованием Adobe AIR дает возможность создать единое мобильное приложение, которое может быть развернуто на множестве мобильных устройств, включая смартфоны и планшеты под управлением Android, iOS или BlackBerry Tablet OS.
Это достигается путем использования кроссплатформенных абстракций (например при доступе к фотографиям), предоставления информации о динамических свойств устройств (например размер экрана). В то же время AIR не мешает, когда помощь не требуется (например при использовании API файловой системы).
Разработка кроссплатформенных мобильных приложений требует от программиста знаний об эфективном использовании памяти и о жизненном цикле приложения. Объеденив эти познания со средой выполнения AIR, можно быстро создавать кросплатформенные приложения.
Прототип мобильного приложения в Adobe XD за два часа
Игорь Музыкин, менеджер проектов студии мобильных технологий Anvics, написал специально для Нетологии статью о том, как создать прототип мобильного приложения за два часа и не упасть лицом в грязь. Статья для конкурса блога.
Первые варфреймы, схемы переходов, для мобильного приложения из 64 экранов заняли 16 часов моей жизни, 6 подходов по 2–3 часа. Раза три хотелось бросить уже это всё. Проработка интерфейса — занятие сколь интересное, столь и утомительное.
.png "adobe разработка мобильных приложений")
Конечно, было бы здорово, чтобы это занимало раза в три времени меньше. Мы в Anvics также исходим из того, что нам нужно показать визуализацию, максимально приближенную к финальной, но не в ущерб тому, что важные функции продукта будут забыты и не отражены.
Попробую дать читателям такую возможность. Напишу, какие сделал выводы из того, как сам готовился к проектированию и использовал Adobe XD: какие функции программы чаще других пускались в ход и что не стоит делать для первой проработки. Советы ниже в первую очередь даются в помощь руководителям проектов, диджитал-продюсерам, проектировщикам мобильных приложений из мира заказной разработки, когда нужно показать клиенту ваше видение проекта и согласовать набор хотелок.
.png "adobe разработка мобильных приложений")
Стадия 0. Черновик
Предположу, что к созданию прототипа вы пришли с определенными вводными: о функциях приложения и пониманием его главной пользы, а также того, что нужно пользователям. Например, после первичного брифования клиента. Возможно, даже появился бэклог. Нужны ещё две части формулы:
Когда определитесь, iOs или Android (выбор не всегда очевидный), не поленитесь узнать стандарты реализации функциональности выбранной платформы. Как хорошо, что разработчики ОС собрали эту информацию за нас. Ссылки на стайлгайды Apple и Google. В примере этой статьи был выбран Android-интерфейс.
Настало время мозгового штурма для расстановки разделов. Не вымещайте идеи сразу в XD — это ошибка. Лучшее начало — набросать экраны ручкой на бумаге. Это помогает быстро составить список функций и сориентироваться какие в проекте есть вложенности экранов. Отличное упражнение — в буквальном смысле расставляет по местам 90 процентов проекта.
.png "adobe разработка мобильных приложений")
Черновик. Боковое меню заменила нижняя навигация.
Стадия 1. Начинаем рисовать
К этой фазе мы подходим с общим знанием о вложенности функций и примерным представлением о переходах между экранами. Можно собирать прототип.
Далее опишу скорее не строгую последовательность действий, а дам список советов, к которым пришел пока работал над проектами.
От lo-fi к hi-fi. Речь о степени детализации и стилизации экранов прототипа. В самом начале проработки, как бы вам ни хотелось, постарайтесь не застревать на одном экране, доводя его до «идеала».
Я застревал, поэтому делал прототип столько, сколько получилось. А клиент, на согласованиях уровня идей (прототип именно их и отражает), не вдается в детали, ему важно увидеть что вы уловили смысл (проверено на нескольких заказчиках).
В режиме низкой детализации проще сосредоточиться на структуре приложения и том, как пользователи должны взаимодействовать с ним. Это важный шаг разработки, который заставляет тебя как проектировщика работать с определенным набором проблем, прежде чем вникать в вопросы цвета, стиля, вместо того, чтобы решать, была ли кнопка на правильном расстоянии от текста над ней (это ведь очень важно! Некрасиво же будет).
Метод прогрессивного джипега Артемия Лебедева говорит об этом же. Идет на пользу в условии ограниченного времени, в котором менеджер находится почти всегда. Скорее просто всегда. До демонстрации два дня и за предыдущие два вы сделали по ощущениям четверть? Найдите, где можно снизить уровень шлифовки. Например, не искать идеально подходящую по смыслу и теме иконку функции, а использовать один стандартный набор.
Наборы пользовательских интерфейсов. Чтобы клиент узнал в прототипе знакомые детали, берем на вооружение наборы элементов, с любовью сделанные несколькими дизайн-командами. Внутри Adobe XD есть ссылки на стандартные наборы, но им не хватает примеров использования элементов по стайлгайдам. Поэтому познакомлю с другими ресурсами, на которых остановился сам после отсмотра десятка пакетов:
Несколько стандартных фреймворков. Под фреймворками мы понимаем типовые экраны вашего будущего приложения, например, лицевые экраны разделов и экраны первой вложенности. Так мы выдерживаем последовательность в виде единых подходов и одинаковых решений для схожих задач. У таких экранов повторяются местонахождения иконок, текстов, схожи интерфейсные решения.
На практике, после проработки 8-9 экранов эти фреймворки дадут о себе знать, потребуют повторного использования. Придерживайте эти болванки рядом с основной рабочей областью и вставляйте как каркас очередного экрана.
.png "adobe разработка мобильных приложений")
Не бойтесь использовать скриншоты. По тем же соображениям, что клиент не вдается детали. Отсмотр похожих приложений дает необходимое вдохновение для собственных идей. И если планируется лента новостей, а нравится реализация в приложении Meduza и вы поузнавали у разработчиков насколько сложно будет сделать также. Советую вставлять скриншоты, а клиенту устно объяснить замысел.
Тексты Lorem ipsum не создают проблем, хоть и кажутся дурацкими, в условиях ограниченного времени подходят для наших задач. Конечно, «боевые» тексты проекта лучше, но оставьте их на этап тюнинга. Чтобы рыба текста была интереснее, идите к Джулсу из Криминального чтива.
Включаем Prototype. Одноименный режим Adobe XD. В нем мы присваиваем элементам экраны действия, которые мы от них хотим получить. Стрелка «назад» возвращает на предыдущий экран, кнопка «сохранить» сворачивает клавиатуру и отправляет данные на сервер. Взаимодействия в XD тестируются окном предварительного просмотра (Cmd-Enter), которое дает достаточную обратную связь, чтобы убедиться, что приложение работает так, как мы того хотим.
Стадия 2. Спускаемся в детали
Как показала практика, результаты первой стадии достаточно фапабельны, чтобы презентовать и успешно утверждать с клиентом (или внутри команды) принципиальные структурные и визуальные решения. Если остается время, прототип можно дотюнить, базовую структуру легко превратить в дизайн большей точности.
На этом этапе можно сделать:
Следуя этим стадиям, вы не потратите слишком много времени на создание значков разных цветов и форм в соответствии с вашими понятиями эстетики, но составите архитектуру приложения и сфокусируетесь на функциональности.
Получится примерно так, как в этом прототипе приложения теннисной лиги Amatour. В нем есть туториал, шторка с пуш-уведомлениями, ленты турниров и новостей, авторизация, регистрация, профиль, статистика, список игроков, рейтинг и центр оповещений.
.png "adobe разработка мобильных приложений")
6 главных фишек Xd
Микродействия, открытию которых в процессе работы я был особенно рад.
Закрывающие фигуры. Обозначены пиктограммой квадрата в левом боковом меню. Использовал для случаев, когда в другом приложении понравился фон, и поверх него хотелось поставить свой текст.
Применение цвета. На языке фотошопа — пипетка. Появляется в правом боковом меню после выбора элемента. Нужно в основном для сливания выбранного элемента с фоном экрана.
Присвоение элементу слоя. В ситуации, когда сначала напечатали текст, потом решили подложить под него фоновый блок, блок будет ложиться сверху текста. В диалоговом меню, оно вызывается правой кнопкой мыши, есть два пункта: — Send to Back и Bring to Front.
Блокировка слоя. Когда нужно было выделить, например, нижнее навигационное меню, и немного опустить его вниз, а вместе с ним неизбежно выделяется и фон. Решение — нажать на фон, выбрав его, и Cmd-L. Будет теперь стоять на месте. Блокировать можно несколько элементов одновременно.
Кнопки центрирования. Ставят элемент ровно посередине ширины или высоты одним нажатием на иконку. Находятся в правом верхнем углу.
Ввод координат. Под кнопками центрирования, есть цифровые значения X и Y. Изменяя их, выбранный элемент сдвинется в другую точку артборда. Иногда это работает быстрее чем перемещением курсором. И похоже на телепортацию машин в Убере, когда пропадал сигнал.
Мнение автора и редакции может не совпадать. Хотите написать колонку для «Нетологии»? Читайте наши условия публикации.