Текст — это интерфейс, а хороший текст означает хороший дизайн.

Почитайте, с чего начинались графические интерфейсы, что влияет на читабельность текста, и как выбрать хороший шрифт для своего дизайна.

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

https://viljamis.com/2016/typography-for-user-interfaces/

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

Для всех, кто хочет развиваться в менеджменте продуктов запускается отдельный видеокурс. Также будет несколько полезных, с нашей точки зрения, лекций для дизайнеров и Android-разработчиков, которые дополнят программу «Мобилизации» 2016 года.

Подписывайтесь :)

— Менеджмент: https://www.youtube.com/playlist?list=PLEs8EuAPI73Bj78n7-BIW3s1we0r15yJl

— Дизайн: https://www.youtube.com/playlist?list=PLLkvpHo_HuBOiSFsDfT8I5aWJKkMzzrPD

— Мобильная разработка (три новых лекции в конце курса): https://www.youtube.com/playlist?list=PLQC2_0cDcSKBNCR8UWeElzCUuFkXASduz

Статья про относительно новый кроссплаторфменный SDK — Flutter. У него интересная система реактивных виджетов, быстрый hot reload и доступ к нативным фичам. Мне после прочтения статьи захотелось попробовать — выглядит многообещающе.
Осталось дождаться улучшения производительности. Демо-приложение выглядит красиво, но лагающие анимации сильно портят впечатление. Ну и поддержка Kotlin была бы очень кстати.

Чтобы добиться хорошего UX, нужно понимать, как работает память.

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

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

1. Не заставляйте пользователя запоминать много информации за один раз.
2. Не заставляйте выбирать из слишком большого количества вариантов.
3. Используйте узнаваемые паттерны.
4. Используйте элементы навигации, выполненные в одном стиле.
5. Не скрывайте ключевые элементы за "гамбургерами" и другими видами меню.
6. Используйте вместе иконки, текст и звук — это стимулирует различные виды памяти.
7. Помните о чувствах. Если пользователя бесит продукт, он плохо запомнит интерфейс и ему будет труднее работать.

https://uxplanet.org/how-human-memory-works-tips-for-ux-designers-12b14071bdf9

Invision показали Studio — инструмент для создания интерфейсов и прототипов. С его помощью можно создавать адаптивный дизайн, делать переходы между экранами и щедро поливать всё красивыми анимациями.
Выйдет в январе для macOS и Windows, но можно оставить заявку на early access.

invisionapp.com/studio

​​Подписчик @zkid18 прислал статью про дизайн приложений для iPhone X.
Автор рассказывает, что дизайнерам делать с выемкой и скругленными углами, и как с этими особенностями справляются дизайнеры Apple.

http://blog.maxrudberg.com/post/166045445103/ui-design-for-iphone-x-top-elements-and-the-notch

Хранить дату в SQL-базе, конвертируя Date в Long и обратно — плохая идея, если вам важны часовые пояса. Для этого лучше использовать отформатированную строку и SQL-функции для сортировки таких строк. Почитайте, как это можно сделать с помощью Room.

https://medium.com/@chrisbanes/room-time-2b4cf9672b98

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

Marcin Moskala пишет серию статей Kotlin programmer dictionary. В первой статье он объясняет различие между аргументами и параметрами. Во второй — между операторами (statement) и выражениями (expression).

Хорошие практики использования Dagger:
https://medium.com/square-corner-blog/keeping-the-daggers-sharp-%EF%B8%8F-230b3191c3f

Что такое корутины в Kotlin, как ими пользоваться, и чем они лучше обычных потоков:
kotlindevelopment.com/deep-dive-coroutines

Несколько примеров использования корутин:
https://proandroiddev.com/android-coroutine-recipes-33467a4302e9

Неочевидные грабли в Kotlin:
https://medium.freecodecamp.org/kotlin-pitfalls-and-how-to-avoid-them-7b0d3a2109ad

В прошлом году я искал способы прокачаться в дизайне и узнал про челлендж DailyUI. Каждый день тебе присылают задания — нарисовать экран управления умным домом, приложение для телевизора или логотип. Постишь результаты на Dribbble или в Twitter и получаешь фидбек от коммьюнити.

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

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

Я протянул 27 дней из 100. За это время у меня накопилась несколько макетов, которые было не стыдно куда-то выложить. Мой редизайн приложения Google Play Music даже занял первое место в ежедневном топе на uplabs.com.

За время участия в DailyUI я многое делал впервые — рисовал лендинг, приложения для часов, делал анимации в After Effects. Освоить что-то новое за один день иногда удавалось с трудом, но оно того стоило. Выполнение непривычных заданий хорошо помогает развитию дизайнера.

У DailyUI есть и плохие стороны. За один день вряд ли можно сделать хороший макет. Зачастую задания делались, как попало, и мне было откровенно стыдно за результат. Не было тестирования на реальных пользователях и фидбека. Лайки и ретвиты работ, возможно, и означали, что кому-то понравилась картинка, но критиковать было некому.

DailyUI хорошо подойдет новичкам, которые хотят научиться работать в Sketch/Figma/AI и собрать первые работы для портфолио, но лучше выполнить чьё-нибудь тестовое задание или поучаствовать в конкурсах, где нужна продуманность дизайна — например, в Russian Design Cup. А ещё лучше придумать и запустить свой продукт. В результате вы получите самое главное — отзывы людей о работе с вашим интерфейсом.

​​IBM выпустили семейство шрифтов Plex.
110 языков, 8 начертаний, с засечками и без.
IBM Plex стал частью дизайн-системы Carbon. Стильный-модный-молодёжный шрифт заменил Helvetica Neue. В компании использовали её с 1960-х и ежегодно платили за лицензию больше миллиона долларов.

🔨 Haiku

Помните Lottie — ту штуку, которая рендерит анимации из After Effects и при этом со стороны кода подключается не сложнее статической картинки? Так вот недавно появился Haiku. Он тоже работает с Lottie, но при этом заточен под анимацию интерфейсов. Возможностей пока не так много, как в AE, но разработчики собираются это исправить.
Одна из киллер-фич — Live Design. Если обновить деталь анимации в Sketch, она изменится в Haiku и во всех приложениях.

Бета-версия пока только для macOS, но планируются клиенты для Windows, Linux и веба.

Подробнее в блоге Haiku:
https://medium.com/haiku-blog/lottie-without-after-effects-9c5a8e74c239

#инструмент

Автор этой статьи сравнивает организацию Depedency Injection с помощью Dagger и нового фреймворка Koin.

Если коротко, то Koin круче, потому что:

- Подключается одной строчкой (вместо 7 у Dagger)
- Инициализируется тоже одной строчкой (вспомните свой класс Application)
- Не заставляет писать десятки аннотаций (потому что не использует кодогенерацию)
- Такой же быстрый, как Dagger

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

Разработчик из команды Runtastic пишет серию статей про устройство коллекций в Kotlin.
Первая статья про списки — сравниваем реализации, копаемся в байткоде и узнаём две вещи:

- Неизменяемые коллекции из Kotlin (List, EmptyList) могут быть неизменяемыми со стороны Java. Они выкидывают UnsupportedOperationException, если вызвать метод-мутатор из Java-кода. Это едиственный способ гарантировать immutability, если в проекте используются оба языка.
- Коллекции из Java (ArrayList) всегда изменяемы со стороны Kotlin.

https://www.runtastic.com/blog/en/tech/kotlin-collections-inside-part-1

Попросили рассказать о конференции:

9 декабря состоится пятый #ITsubbotnik в Санкт-Петербурге

В секции Mobile вас ждут 2 доклада:

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

Николай Ашанин расскажет о подходах к распознаванию лиц и о том, как их применить в мобильной разработке.

#ITsubbotnik - это бесплатная конференция для опытных разработчиков и инженеров.
Приходите!

Регистрация здесь: https://epa.ms/itsubbotnik-winter

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

reddit.com/r/Kotlin/comments/7hoytl/kotlin_team_ama_ask_us_anything

Realm добавили first-class поддержку Kotlin:

- Результаты запросов теперь могут быть только nullable
- Аннотацию @Required можно заменить nullable или non-null типом поля
- Некоторые статические функции заменили экстеншн-функциями (dog.addChangeListener() вместо RealmObject.addChangeListener(dog, changeListener))
- Ключевое слово anyOf пришло на замену слову in, которое надо было брать в апострофы.
- Вместо передачи класса в метод можно использовать генерики (delete<Dog>() вместо delete(Dog::class.java))

https://realm.io/blog/realm-4-3-0-released-w-first-class-support-for-kotlin/

​​Spritz — делаем анимированный онбординг

Библиотека Spritz помогает использовать Lottie-анимации в онбординге. Анимация экспортируется из Affter Effects и привязывается к Lottie и ViewPager. Одни фрагменты анимации проигрываются автоматически, а другие — вместе со свайпом.
Выглядит лучше, чем статичные картинки, а реализовать это со стороны кода совсем не сложно — меньше 20 строк кода для трёх экранов.

Spritz на GitHub:
https://github.com/novoda/spritz

Статья-туториал:
https://www.novoda.com/blog/onboard-your-users-with-lottie-of-spritz/

Демо-приложение:
https://play.google.com/store/apps/details?id=com.novoda.spritz.sample

#библиотека

​​Классный туториал по ValueAnimator, который поможет анимировать любую часть вашего кастомного View.

Анимация, как на гифке, пишется в 10 строчек:

 
PropertyValuesHolder propertyRadius = PropertyValuesHolder.ofInt(PROPERTY_RADIUS, 0, 150);
PropertyValuesHolder propertyRotate = PropertyValuesHolder.ofInt(PROPERTY_ROTATE, 0, 360);

animator = new ValueAnimator();
animator.setValues(propertyRadius, propertyRotate);
animator.setDuration(2000);
animator.addUpdateListener(animation -> {
    radius = (int) animation.getAnimatedValue(PROPERTY_RADIUS);
    rotate = (int) animation.getAnimatedValue(PROPERTY_ROTATE);
    invalidate();
});
animator.start();

А во второй половине рассказывается об анимированных графиках. Сделать их не так сложно, как кажется.

Для практики можно закодить какую-нибудь красивую анимацию с Dribbble:
раз — dribbble.com/shots/3533668-Loading-Analytics-Chart-018
два — dribbble.com/shots/2924172-Line-Chart
посложнее, с кривыми Безье — dribbble.com/shots/2475280-Line-chart-graph-animation

#туториал

С новым годом, ребят 🎉
Вы классные, желаю вам продуктивности и крутых проектов в новом году!

Привет 👋

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

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

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

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

Сейчас решил ввести такой режим.

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

2-3 часа занимаюсь стартапом. Беседую с пользователями, организую заметки, рефлексирую.

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

В 9 вечера прекращаю работать. Отдыхаю, смотрю доклады, читаю книги и общаюсь с близкими.

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

Выводы из этой истории такие:

1. Если вы начинаете фрилансить, ищите проекты с почасовой оплатой.
2. Ставьте жесткие дедлайны и соблюдайте их. Если не успеваете, обсуждайте с заказчиком, ищите выход вместе. Фриланс — это круто и удобно, но расслабиться и стать непродуктивным так же легко, как привыкнуть к переработкам и выгореть.
3. Если вы хотите делать свой стартап параллельно с работой, хорошенько подумайте. Скорее всего, придётся отказаться от развлечений и меньше заниматься любимыми хобби.