Дизайн
Женя Иванов
3606

Как дизайнеру оседлать четыре строчки кода и больше никогда не загружать картинки для интерфейса: гайд по Framer X

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

В закладки

Как обычно это происходит?

Вот сделал ты главную онлайн-кинотеатра. Чтобы наполнить его контентом, тебе придётся сходить на «Кинопоиск» и отобрать фильмы, которые будут «достойны» красоваться в твоём приложении. Потратил время, всё красиво, но через пару дней ты решишь чуть-чуть изменить компонент и у тебя случайно послетали все картинки. Ладно один экран, не так обидно, но если их сотни?

Рубрика «Э-э-эксперименты»

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

А что, так можно было?

Вообще да, но есть маленькое но... Figma сегодня мы открывать не будем. Прошу любить и жаловать, Framer X – наш сегодняшний конь, которого мы и будем седлать. Если ты ещё не в курсе, это такой инструмент для дизайнеров, в котором ещё можно немного поковырять код. В умелых руках это нереальная вещь, поэтому я пытаюсь её изучать :D

​Вот такого монстра мы сегодня напишем

Страшно, дизайнер? Не переживай, тут всё не так жёстко, как ты думаешь (даже если ты никогда не тыкался в коде). Вот всё что нам нужно:

Те самые четыре строчки​

Да, именно из-за этих строчек весь сыр-бор. Это описанный запрос к базе данных с фильмами, именно оттуда мы и будем получать картинки, тексты и другие штуки, чтобы наш дизайн сразу был законченным. Больше никаких заглушек!

Ну что, погнали дизай...кхм...кодить

Надеюсь, ты уже скачал Framer. Вот ещё мой файлик с проектом, можешь параллельно сверяться с ним.

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

Для удобочитаемости компонент сразу с контентом, но у тебя может быть обычный заглушенный серый квадрат :)

Самоё лёгкое позади. Теперь нужно взять откуда-то данные для карточек фильмов. Тут нужно познакомиться с API. Эта штука позволяет «стучаться» к базе данных и просить у неё всякое разное.

Обращение к базе: «Заткнись и дай мне постеры для фильмов​»

Я нашёл сайт с каталогом API на любой вкус и цвет, подойдёт для любого приложения. Для нас тут есть огромная база с фильмами от IMDb.

Тут всё сложновато, на первый взгляд, поэтому к этому сайту вернёмся в конце статьи, когда разберёмся с основами. А пока будем тренироваться на сайте от самого Framer. Тут можно один раз вручную создать JSON-файлик с данными, чтобы потом его переиспользовать. Я заранее создал набор фильмов для этой статейки, поэтому тебе заморачиваться не придётся.

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

​Как выглядит JSON-файл

Теория позади, открывай редактор кода, дизайнер

Переходи на четвёртую вкладку на панели слева и создавай новый сode component. У тебя откроется пустой проект, и первое, что нужно сделать, сказать Framer, что мы будем использовать в коде:

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

Запрос​

Ну что, вот и твоя первая осознанная строчка кода. Fetch — это метод запроса, с помощью него мы и будем получать данные по ссылке внутри скобок. Потом сможем сюда вставлять ссылки на любые API, а пока тренируемся на этой. Допустим, данные ты получил, что теперь с ними делать? Надо бы их обработать, коронавирус же...нет... и без него надо было бы:

Я сейчас не расскажу про асинхронность всего этого дела и другие мелочи запросов к API, давай мы договоримся, что тут мы преобразуем запрос в нужный нам формат. Как я говорил ранее, мы будем использовать JSON. Да-да, мы преобразуем JSON в JSON, Framer-то не знает, что мы ему уже скармливаем нужный формат, поэтому говорим ему, чтоб тот сделал свою работу :)

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

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

Ну как бы всё

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

Шучу, осталось ещё много чего непонятного. Сейчас расскажу, для чего нужен остальной код и как в итоге засунуть данные внутрь дизайн-компонента.

Эта штука для экспорта компонента FilmList из кода, чтобы можно было использовать { всё, что внутри скобок } в дизайне, а там и запрос к API и другие интересные штуки.

А вот и вторая импортнутая штука из начала проекта. useEffect сделает ваш запрос к API стабильным, потому что отрисует данные один раз и больше трогать их не будет. Если интересно, попробуй сделать запрос без useEffect и посмотри, что будет (спойлер: забавные глюки).

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

Тут мы говорим переменной data, в которой у нас лежат данные о фильмах, чтобы она распределилась по компоненту FilmComponent, который мы рисовали в дизайне. Отдельно выделяем это дело в переменную (const List), чуть позже нам это пригодится.

По сути, всё, компонент должен получать данные через API, а ты радоваться проделанной работе, но ничего подобного :)

Ты ещё не вывел свой код компонент FlimList на дизайн область. Чтобы это сделать, заверстаем Stack из всех фильмов, что мы получили через API. Stack — это функция Framer, которая работает как Auto Layout, растягивается до размера контента внутри.

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

Теперь обернём стак в Scroll, чтобы можно было проскроллить карточки фильмов до конца.

Вот теперь точно всё

Должно получится такое превью, которое можно открыть на телефоне. Оно кстати, делает запросы к API отдельно от ПК. А ещё Framer может собрать демку в веб-превью, очередная крутотень!

Ну что, теперь ты готов к взрослым API

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

Но крутые API требуют крутого подхода, один из таких — API-ключ. Он позволяет базе данных понимать, кто конкретно запрашивает данные, это сделано для безопасности и для всяких бизнес-штук. Чтобы использовать API-ключ, нужно дополнить наш fetch запрос к API таким образом.

​Делаем запрос через апи IMDb из начала статьи

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

​Ключ покажется только у зарегистрированных пользователей

Готово, ковбой, Framer X осёдлан

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

@evgn_design – мой канал в телеграм для тех, кому мало хардкора. Там всякая подобная писанина про компоненты, дизайн-системы и процессы. Залетай!

{ "author_name": "Женя Иванов", "author_type": "self", "tags": [], "comments": 47, "likes": 41, "favorites": 229, "is_advertisement": false, "subsite_label": "design", "id": 115953, "is_wide": false, "is_ugc": true, "date": "Mon, 30 Mar 2020 14:01:11 +0300", "is_special": false }
SEO
Контент — король: как мы с помощью SEO привели 400 тысяч англоязычных геймеров в блог, играя в PUBG
Подготовили кейс по работе с изначально незнакомой нам нишей, да еще и на англоязычную аудиторию. Вот некоторые…
Объявление на vc.ru
0
47 комментариев
Популярные
По порядку
Написать комментарий...
4

Слишком длинная инструкция как оседлать 4 строчки кода )

Ответить
11

Всего 4 строчки, но как брыкаются)
Я пытался сократить, но это оказалось импосибл. Всё хотел затронуть, чтобы максимум вопросов отсечь)

Ответить
3

Вещь интересная, но зачем дизайн-макетам (которые созданы для того что-бы показать структуру компонентов) подтягивать какие-то данные с каких-то АПИ? Бесполезная игрушка получается, а так потыкаться можно да 👍

Ответить
3

Согласен, у меня это пока эксперименты, но вообще у этого большой потенциал в двух моментах:
1) Исследования пользователей, там контентом обязательно нужно заполнить все макеты
2) Проверка дизайн макетов (частенько реальные фото и текста выглядят в сервисе не так читаемо, как в макетах из-за нерандомной выборки дизайнером)

Ответить
1

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

Ответить
3

А у меня у одного возникает вопрос что нужно сделать с компонентом в фигме что бы полетели все картинки? Первый раз такое слышу

Ответить
0

Защита от дураков никогда не помешает :D
На практике, в больших китах часто что-то происходит, особенно, когда инструменты (фигма, скетч и другие) добавляют какие-то новые штуки, которые хочется добавить в кит, например авто лэйауты для множества компонентов.

Ответить
1

Ну у меня бывает подлагивает фигма что все блоки съезжают или исчезают куда-то, но это пока не кликнешь по нему и это то это все если 100500 уровней автолейаутов в 5 слоев компонентов завернуть. А вот чтоб фотки пропадали

Ответить
0

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

p.s. Перестал замечать «прыгающие» компоненты, может уже починили?

Ответить
1

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

Ответить
3

Я не кодер, а продуктовый дизайнер. Мне тоже было сложно, поверь :D

Ответить
1

Нехороший ты человек автор, я вот сознательно не лезу в код, чтобы не лишать разработчиков заработка; твои методы оббезработят половину айтишников, стыд!

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

Ответить
0

Привет, Pixel, знакомые лица :)
Не думаю, что подобные инструменты заменят разрабов или дизайнеров. Как по мне эта штука наоборот приучает всех общаться на одном языке, и это круто!

Не совсем понял про код для разработчиков?)) А для кого он ещё?)

Ответить
0

Напомни откуда знакомы?

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

Думаю за инструментами типа фреймера будущее, но таки надеюсь что верх возьмёт фигма и ее тотальная автоматизация) Типа задизайнил приложеньку, указал что и как себя ведёт, кликнул кнопарь "опубликовать в стор" и плотоядно потираешь ручки :)

Ответить
1

Мне кажется, в сторону твоих мечт будет идти как раз фреймер. Фигма ближайшие 5-10 лет будет разрабатываться для больших компаний, чтобы заработать денег, а там нужна командная работа и вот это вот всё)

Мы с тобой не знакомы, но я помню тебя по комментам под другой моей статьёй «ячейки на auto layout в фигме», ты там тоже жаловался на разработчиков :D

Ответить
0

Лол, да, похоже на меня! Как только разработчики станут грамотнее я прям статью запилю о том, как я стал счастлив)))

Ответить
0

Разработчики грамотны (в том что касается дизайна) ровно настолько,  насколько хорошо с ними налажены отношения. Так то большинство актуальных новшеств в инструментах дизайна пришли как раз из области разработки (reusable components и overrides,  распределенный контроль версий,  тот же auto layout). Часто между дизайнерами и разработчиками пропасть — первые не имеют представления как устроена система для которой они проектируют интерфейсы, ограничения, возможности, best practices. 

Ответить
0

Разработчики грамотны настолько, насколько им позволяет им ЧСВ. Часто оно ограничивает: "я технарь, я самый умный, это точно нельзя сделать". Я: "вот готовый код, не пизди, а делай!"

Ответить
0

Если не секрет, где ты работаешь?)

Ответить
0

Компанию не раскрою, а индустрия - интернет вещей: клиентская часть и админки операторов. 
+ шабашки, куда без них.
А ты?)

Ответить
0

Я поработал в маленькой региональной студии, потом в небольшом стартапе и сейчас, в крупной компании, нигде не было такого, чтобы прям хейтили друг друга в команде

Ответить
0

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

Ответить
0

скорее из за консервативности и возможно лени

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

Ответить
0

А ты со своей стороны как с ними общаешься? Выполняешь ли «дизайнерский долг»?

Ответить
0

Согласен, видел только такую форму дисконекта с разработчиками, но чтобы они смотрели на дизайнеров, как на говно? Ну такое :)

Ответить
0

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

Ответить
0

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

Ответить
1

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

Ответить
0

Не думаю, что он бесполезный.  Скорее кажется избыточным — фрэймворк для фрэймворка 

Ответить
0

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

Ответить
0

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

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

Ответить
0

А когда ты дизайнишь макеты в фигме, реальными данными их не заполняешь? Только вайрфреймы делаешь? В фигме вроде как достаточно инструментов прототипирования, чтобы что-то потестить. Не совсем понимаю просто, чем прототипы во фреймере лучше чем в фигме. Двойная работа получается. Ну, шрифты не искажаются так сильно может быть.

Ответить
0

Вот я и говорю, что заполнять дизайн в фигме оооочень долго. Мы недавно коллеге помогали заполнять один раздел всей дизайн командой, потому что там было около 400-500 изображений, она бы просто там утонула в фотостоках)) Да, сейчас появляются плагины, тот же ансплэш, но мне было интересно попробовать сделать что-то самому «на плагины надейся, а сам не плошай»

Ответить
0

Как сказал один дизайнер: Framer - это инструмент о котором все говорят, но толком никто не знает что с ним делать.

Ответить
0

Парни ищут себя просто)) А мы смотрим со стороны за этой движухой

Ответить
0

Кто знает — тот пользуется и особо не афиширует. Зачем у себя же хлеб отбирать.

Ответить
0

Блин, придётся поиграться. Люблю, когда можно сделать что-то новенькое и весь процесс уже разжеван — остаётся проглотить

Ответить
0

Закидывай потом ссылку на проект, посмотрим, что получилось :D

Ответить
0

А зачем две строки импорта из реакта?

Ответить
0

Ой, честно, в эту тему не сильно погружался, но как я понял: * as React from "react" – это полноценный модуль, а { some thing } from "react" – разворачивание его отдельных частей. А отдельные части модуля и модуль импортируются по разному, от того и запись в две строки.

Ответить
0

Сам Реакт нужен чтобы работал JSX (реакто-специфичная смесь JS и HTML) , ну а отдельные функции используются в коде.

Это записывается в одну строку: import React, { useState } from 'react';

Ответить
0

Во, спасибо за разъяснение, в следующий раз так и буду писать)

Ответить
0

Все-таки кодеры народ усидчивый и терпеливый жесть, я даже до конца не осилил дочитать, дочитать, а Вы тут такое расписали..

Ответить
0

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

Ответить
0

В анимации я супер абстрактно показал код, просто для динамичной обложки) А так там распределение и рейтинга и имени есть тоже шагом ранее, присмотрись))

Ты уже готовишься к судному дню, когда без кода ты никто?))

Ответить
0

Круто, что дизайнеры осваивают код и пишут такие туториалы. Сам таким занимался (спойлер: стал разработчиком).

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

Читатель повторить туториал сможет, а сделать что-то свое (например, обновлять данные каждые 5 секунд) — уже нет.

Это не упрек автору, скорее пространное ворчание по поводу количества слоев абстракции и адской кривой обучения.

Ответить
0

Дааа, многие вещи пришлось сильно так подсократить по многим причинам. На то подобные статьи и обзорные, чтобы лишь зацепить дизайнеров идеей {ideaName}, чтобы они потом шли дальше разбирались и ковырялись в исходниках. По сути так со мной и было: увидел официальный короткий туториал, из которого нифига не понятно, пошёл сам додумывать и пробовать. Надеюсь, мне удасться зацепить кого-то так же, как меня когда-то)

Ответить

Прямой эфир