Всю неделю шли анонсы складных смартфонов: Samsung и Huawei уже жаждут лишить нас крупной суммы, у Oppo и Xiaomi пока что прототипы.

Их бурно обсуждали, но в основном речь шла о железе и о ценах. А для любого нового форм-фактора важна и софтовая поддержка: можно вспомнить, как при появлении iPad сначала приходилось пользоваться «айфонными» приложениями, ужасно выглядевшими на 10-дюймовом экране, а позже постепенно появлялись адаптированные.

Возникнут ли сложности у существующих Android-приложений на «раскладушках»? К чему готовиться тем пользователям, которые решатся купить дорогущее устройство? А что нужно сделать разработчику, чтобы эти пользователи остались довольными? Как протестировать своё приложение, если под рукой нет устройства за $2000?

Под катом мы описали это и с «пользовательской» стороны, и с «разработческой». Могли что-то упустить — так что, если Android-разработчики в комментариях дополнят, будем рады.

Нет ничего проще, чем добавить иконку в проект: нужно всего лишь написать дизайнеру, он экспортирует её из Sketch и пришлет вам нужный вариант, а вы используете ее у себя в коде. Если же у вас с десяток проектов, несколько платформ и множество А/Б-тестов на дизайн, то достаточно делать всё то же самое, только в 40 раз чаще и нигде не ошибаться… либо постараться автоматизировать процесс. Под катом — первая часть перевода статьи моего коллеги Cristiano Rastelli про один из примеров такой автоматизации.

Проблема, которую мы решали

Мы в Badoo разрабатываем приложение для знакомств. Вообще-то это несколько приложений, каждое из которых функционирует на нескольких платформах (iOS, Android, Mobile Web, Desktop Web), и работу над ними ведут несколько команд.

При разработке мы используем сотни различных иконок. Некоторые одинаковы в каждом приложении, другие — соответствуют тому или иному бренду. Иногда дизайн меняется, а вместе с ним меняются и иконки: появляются новые, какие-то обновляются, какие-то — удаляются (но часто остаются при этом в кодовой базе).

Привет, Хабр!

Меня зовут Евгений, я Full Stack JS разработчик, текущий стек Node.js + React + React Native. В разработке я более 10 лет. В мобильной разработке пробовал разные инструменты от Cordova до React Native. Получив опыт работы с Cardova, я понял, что мне хотелось бы создавать нативные интерфейсы, на мой взгляд WebView не должно быть всем приложением. Но это не значит, что его не надо использовать вовсе.

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


Источник: srishta.com

Также немного расскажу о том, как вы можете использовать WebView и как его могут использовать против вас злоумышленники. Примеры в статье будут показаны с использованием фреймворка React Native, но те же идеи можно реализовать и без него.

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

Примечание: это далеко не единственный способ выбора хороших цветов, скорее, набор эвристик, которые я освоил самостоятельно. Надеюсь, что это поможет вам подбирать правильные цвета для вашего веб-сайта/приложения/игры.

Первое, что хочется сказать — это было сложно. Гораздо сложнее, чем я думал. Я имел до этого весьма жесткий опыт выведения продуктов в релиз на работе, однако никогда не дотаскивал до продакшена персональные проекты. Они у меня все заканчивались на прототипах разной степени отвратительности, но этот вроде бы выжил. В данный момент он запущен для 80+ стран (вся Европа, Азия и Северная Америка), на обеих мобильных платформах, и в конце статьи будут ссылки на скачивание — поэтому всех заинтересовавшихся приглашаю попробовать, поломать и поругать.

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

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

Привет! Меня зовут Азат Зулькарняев, я занимаюсь разработкой iOS-приложений в компании Badoo. При создании мобильных приложений большая часть времени уходит на разработку UI, и оптимизация этого процесса всегда является актуальной темой в среде разработчиков. Мой коллега Алексис Сантос написал статью о том, с какими проблемами мы столкнулись и как двигались в сторону их разрешения при работе над этой задачей. Я решил поделиться с вами переводом. Также рекомендую посмотреть запись недавнего доклада Игоря Савельева на Mobius 2018.

Несколько месяцев назад я наткнулся на очень интересный документальный сериал от Netflix — «Абстракция: Искусство дизайна». В нём подробно рассматривается работа дизайнеров из разных сфер: архитектура, графический дизайн, мода и т. д. Нетрудно заметить определённое сходство их работы с деятельностью iOS-разработчиков, занимающихся реализацией пользовательских интерфейсов. В частности, ведя работу над крупным проектом, дизайнеры стараются разбить её на множество мелких задач по принципу «разделяй и властвуй» и получают возможность собрать все элементы воедино на более позднем этапе.

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

• определить задачу клиента;
• сформировать свои гипотезы;
• продумать метрики;
• определить контекст использования, CJM, прочее;
• продумать решение и его валидацию.

Для людей, привычных к дизайну продуктов, которыми пользуются миллионы пользователей по всему миру, этот фреймворк знаком (в том или ином виде).

Когда продакты думают, что точно знают, чего хочет пользователь

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

Меня зовут Лев, я ведущий дизайнер функции «Цифровые технологии» в СИБУРе, и я расскажу вам о том, как работается дизайнерам приложений и интерфейсов в условиях, когда часть твоих пользователей — это коллектив обходчиков на производственной площадке в Тобольске, которые используют твое приложение немного не в тех условиях, в которых ты это приложение сделал.

Каждый пятый житель США владеет умной колонкой, а это 47 000 000 человек. Помощник может создать напоминание, список дел, будильник, таймер, прочитать новости, включить музыку, подкаст, заказать доставку, купить билеты в кино и вызвать такси. Все это «навыки» или «skills» помощников. Еще их называют голосовыми приложениями. Для Alexa и Google Assistant таких приложений на 2018 год разработано 70 000.

В 2017 году Starbucks запустил функцию по заказу кофе домой для Amazon Alexa. Кроме того, что выросли заказы на доставку, об этом написали все возможные СМИ, создав классный PR. Примеру Starbucks последовали Uber, Domino’s, MacDonald’s, и даже у стирального порошка Tide появился свой skill для Alexa.

Как у Starbucks, голосовое приложение выполняет одну-две функции: заказывает кофе, ставит будильник или вызывает курьера. Чтобы спроектировать нечто подобное, не обязательно быть межконтинентальной корпорацией. Идея, проектирование, тестирование, разработка и релиз похожи на аналогичные этапы в мире мобильной разработки, но с особенностями для голоса. Подробно о процессе рассказал Павел Гвай: от идеи до публикации, с примерами реальной игры, с историческими вставками и разбором мира голосовой разработки.

Полгода назад мы представили одну из самых впечатляющих функций Badoo — прямые трансляции. Среди прочего она позволяет пользователям выразить благодарность любимым стримерам в виде подарков. Мы хотели сделать эти подарки максимально яркими и привлекательными, поэтому решили их оживить — другими словами, анимировать. А чтобы было ещё интереснее, мы планировали обновлять подарки и анимации каждые несколько недель.

iOS-инженеры наверняка догадались, о каких объёмах работы идёт речь: чтобы удалять старые и добавлять новые анимации, необходимо совершить множество действий с клиентской стороны. Для этого в каждом релизе должны быть задействованы Android- и iOS-команды, а вкупе со временем, необходимым на одобрение обновления в App Store, это означает, что запуск каждого релиза с обновлёнными анимациями может занять несколько дней. Однако нам удалось решить эту проблему, и сейчас я расскажу как.

Архитектура решения

К тому времени мы уже умели экспортировать анимации Adobe After Effects (далее — AAE) в понятный нашему iOS-приложению формат при помощи библиотеки Lottie. В этот раз мы пошли чуть дальше: решили хранить все актуальные анимации на сервере и скачивать их по мере необходимости.

Дайджест собирает свежие статьи по дизайну интерфейсов, а также инструменты, паттерны, кейсы, тренды и исторические рассказы с 2009 года. Я тщательно фильтрую большой поток подписок, чтобы вы могли прокачать свои профессиональные навыки и лучше решить рабочие задачи. Предыдущие выпуски: апрель 2010-декабрь 2018.

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

При создании набора компонентных iOS-шаблонов для Figma я решил поэкспериментировать с компонентом Tab Bar. Напомню, что в гайдлайнах iOS это нижняя навигация. Мне хотелось, чтобы его содержимое имело логичное и оптимальное поведение при ресайзе. Хотелось сделать его максимально адаптивным для всех iOS-устройств, насколько это позволяет сделать Figma и направляющие (constraints).

Возможность использовать translucent в андроид появилась ещё в KITKAT. И выглядит в правильном дизайне это довольно эффектно. А с появлением моды на девайсы с "Чёлками", кажется, просто необходимой вещью в любом тёплом ламповом стартапчике.

Давайте представим ситуацию: вы запилили офигительно красивый, скроллящийся под StatusBar и NavigationBar дизайн. И вот вы добавляете поле ввода и понимаете, что adjustResize у вас не работает.

Вы можете:

1. Забить, – пользователь сам закроет клавиатуру, чтобы посмотреть что под ней.
2. Отказаться от translucent, стиль – это не ваше, всё будет олдово, надёжно, как у всех.
3. Как только пользователь начинает скроллить, скрывать клавиатуру. Вы молодец! Всё правильно сделали, skype даже под ios так делает! А там и прозрачности-то нет.
4. Вынести все поля ввода на отдельные экраны. Как бонус — каждый лишний переход на экран, минус удобство и конверсия.
5. Запилить свой adjustResize.

Иллюстрация от J.HUA

Год назад мы составили прогноз трендов в дизайне мобильных UI. В этом году мы решили выйти за рамки мобильных интерфейсов, потому что тренд №1 в современном дизайне — это контекст. Больше никаких обобщений — теперь всё завязано на контексте.

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

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

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

Дайджест собирает свежие статьи по дизайну интерфейсов, а также инструменты, паттерны, кейсы и исторические рассказы с 2009 года. Я тщательно фильтрую большой поток подписок, чтобы вы могли прокачать свои профессиональные навыки и лучше решить рабочие задачи. Предыдущие выпуски: апрель 2010-ноябрь 2018.

Чтобы стать UX-экспертами дизайнерам нужно усердно работать каждый день. Постоянное самосовершенствование и любовь к тому, что создаёшь, — два ключевых фактора, помогающие стать мастером своего дела. Конечно, у каждого UX-эксперта есть собственные секреты успеха, но всё же есть что-то общее между ними. Есть несколько характеристик, отличающих любителей от настоящих профессионалов. Эта статья описывает, какими привычками обладают специалисты UX дизайна.

Мне нравится Dribbble. Там есть много крутых и вдохновляющих дизайн-проектов. Но если вы разработчик, то часто чувство прекрасного быстро сменяется на отчаяние, когда вы начинаете думать о том, как реализовать этот крутой дизайн.

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

Онбординг

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

Чаще всего онбординг осуществляется тремя способами:

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

Давным-давно, когда я занималась веб-разработкой больше, чем текстами, раз в полгода обязательно смотрела вакансии: кого ищут и что хотят. Даже если совсем не собиралась менять работу — просто чтобы быть в курсе требований и технологий. А иногда даже делала тестовые — чтобы проверить, что могу, что не могу, а что стоит подтянуть. И однажды почти случайно наткнулась на чудесное тестовое задание: «Представьте, что Яндекс.Деньги стали принимать оплату носками. Напишите текст для баннера на главную и письмо для партнёров».

Первая реакция: «Ха-ха, кто же придумывает такие тестовые, а главное — кто их делает». Через три часа я перечитала все рассылки, баннеры и статьи Яндекс.Денег, которые нашла в открытом доступе, и знала всё про носки: из чего их делают, сколько человек на Земле носит, чем отличаются мужские от женских. А главное, передо мной лежало готовое тестовое — пришлось отправлять. Так началось моё путешествие во вселенную интерфейсных текстов. А заодно — работа в Яндекс.Деньгах.

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

— I’m too young to die.

SceneKit — высокоуровневый фреймворк трехмерной графики в iOS, который помогает создавать анимированные сцены и эффекты. Он включает в себя физический движок, генератор частиц и набор простых действий для 3D-объектов, которые позволяют описать сцену в терминах контента — геометрии, материалов, освещения, камер — и анимировать её через описание изменений для этих объектов.

Сегодня мы внимательным, немного суровым взглядом посмотрим на SceneKit, но, для начала обратимся к основам и посмотрим, что представляет из себя 3D-сцена и что нужно сделать, чтобы её создать.