TKS World: Финальный релиз! 🚀

Помните историю, как наш кейс по редизайну MINDVALLEY на Behance привёл нас к международному клиенту?

Мы прошли путь от первой тестовой страницы за $100 до глобального обновления всей экосистемы. И вот сегодня — финишная черта.

Сайт TKS World полностью в продакшене.

Что под капотом:
Обычно на канале мы показываем проекты собранные на Taptop, но под задачи TKS (масштабирование, западный рынок, специфика поддержки) WebFlow подошёл идеально.
⚡️ 20+ уникальных страниц
⚡️ Сложная CMS структура для программ и историй выпускников
⚡️ Анимации, интеграции и полная адаптивность

Это масштабная платформа для будущих инженеров и фаундеров, которые уже стажируются в SpaceX и Google. Дизайн, кстати, уже успел забрать «рыжую» и «золотую» на Dprofile, пока мы допиливали вёрстку.

Теперь всё это можно потыкать вживую.

👉 Смотреть результат: https://www.tks.world/

Принимайте работу. Это был долгий, сложный, но кайфовый марафон.

Всех обняли,
Ваш IZUM ❤️

😍 Когда дизайн это вызов, получается Боноферлат.

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

👉 Что делает этот проект особенным:

✨ «Живой» интерфейс: капсулы разлетаются, иконки перелетают между блоками
✨ Сложная логика на Taptop: 90% сделали нативно, GSAP подключили только для заголовков
✨ Скорость: собрали всё за 8 дней, хотя казалось, что нужно недели три

Кстати, проект уже успел собрать несколько наград в индустрии. Это тот случай, когда смелость дизайна и чистота кода дали отличный результат 🤘

Залетайте посмотреть, как всё это работает в связке.

👀 Кейс на Dprofile: https://dprofile.ru/case/168595/sait-dlia-bad-bonoferlat
👉 Сайт вживую: https://bonoferlat.ru

Рады работать с такой креативной командой.

Ваш IZUM ❤️

🖥 Почему для PC‑макета мы просим 1600?

Нас часто спрашивают дизайнеры: почему лучше рисовать десктоп именно на 1600, а не на 1440, 1366 или 1920?

Короткий ответ: для флюидной вёрстки это самая удобная точка отсчёта.

Мы собираем сайты во флюидной логике. Элементы не зафиксированы в пикселях, а пропорционально меняются вместе с шириной окна браузера. И от того, какое разрешение макета мы возьмём за основу, зависит, насколько сильно эти элементы будут масштабироваться у пользователя.

Обычно нам хватает трёх точек:
📌 1600 для PC
📌 768 для планшета
📌 390 для мобильной версии

Почему именно 1600?
Потому что это золотая середина, которая даёт адекватные пропорции при растягивании и сжатии экрана.

Смотрите, как это работает на практике:
• Если взять за базу 1280, то при просмотре на мониторе 1920 все элементы увеличатся в полтора раза — интерфейс станет гигантским. Придётся добавлять новые брейкпоинты, чтобы это успокоить.
• Если верстать от 1920, то на экранах компактных ноутбуков (1366px) всё сожмётся почти на треть и станет слишком мелким.

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

Конечно, дизайнеры часто отдают макеты в 1366 и 1920. С этим тоже можно работать: верстать от 1366 и корректировать отступы на 1920. Но если на 1920 реально меняется сетка и композиция — это уже отдельная полноценная вёрстка.

Для большинства лендингов 1600 закрывает десктоп без лишних костылей и новых состояний.

А в следующем посте мы отойдём от пикселей и разберём, почему такую вёрстку гораздо удобнее и быстрее собирать в rem. 🧮

Зачем мы верстаем в rem? 🧑‍💻

В Taptop можно работать с разными единицами измерения: px, vw, vh, em и rem. У каждой из них своя логика, но для флюида подходит не всё.

Пиксели понятные, но жёсткие. Если задать элементу 40px, он так и останется 40px, независимо от ширины экрана. А нам нужно, чтобы размеры интерфейса пропорционально менялись.

С vw элементы начинают зависеть от ширины окна. Но собирать весь проект только в vw — это боль. При переходе на каждый новый брейкпоинт (на планшет или мобилку) вам придётся заново пересчитывать в калькуляторе вообще все значения из макета.

em тоже может запутать. Эта единица привязана к размеру шрифта конкретного блока. Из-за этого отступ 3em у крупного заголовка и у мелкого абзаца даст на экране абсолютно разные расстояния.

А вот rem работает спокойнее. Он привязан к одному единственному корневому элементу (root), поэтому 3rem всегда дают предсказуемый размер для любых блоков.

Но просто переключиться на rem недостаточно. Традиционно за основу корня берут 16px. Под эту базу созданы десятки сервисов-конвертеров. Но пересчёт от 16 сложный: чтобы получить точные отступы из макета, нужно постоянно держать калькулятор открытым.

Мы делаем иначе: через embed с глобальными стилями прописываем скрипт и задаём корень так, чтобы на основном разрешении макета он был равен ровно 10px.

Например, если макет нарисован на 1600, значение в скрипте получается 0.625vw. Для макета на 1440 цифра будет другой, но суть остаётся.

Как только root настроен на 10px, мы полностью освобождаемся от калькуляторов. Начинается нормальная жизнь:
• в макете отступ 40px → просто пишем 4rem
• заголовок 56px → ставим 5.6rem
• элемент 120px → пишем 12rem

Берём значение из Figma, мысленно делим на 10 и переносим в Taptop. А когда доходим до адаптива, логика сохраняется. Вам не нужно пересчитывать значения элементов руками — вы просто добавляете в скрипт нужный брейкпоинт (планшет или мобилку) и его vw‑значение.

Ещё один нюанс. В скрипте можно оставить PC без ограничений — тогда интерфейс будет флюидно расти вместе с шириной монитора. А можно поставить потолок (например, на 1920): после этой точки элементы зафиксируются в абсолютных значениях. Это отлично выручает, когда на огромных экранах всё начинает казаться слишком гигантским. 🖥

🔎 Почему не стоит сразу прыгать в вёрстку?

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

Но перед стартом лучше внимательно изучить макет.

Не пробежать глазами за пару минут, а реально посмотреть структуру, разрешения, состояния и спорные места. Да, на это нужно потратить время. Но часто именно это время потом экономится в процессе вёрстки.

Важно заранее понять:

• какие есть разрешения
• сколько блоков в проекте
• есть ли UI-kit
• прописаны ли состояния: hover, active, disabled, error
• всё ли понятно по адаптивам
• всё ли дизайнер подготовил корректно
• какие вопросы лучше задать до старта

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

Типичный пример — текстовые стили.

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

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

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

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

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

В моменте кажется: «Разберусь по ходу».

Но часто это превращается в переделки.

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

Поэтому нормальный старт вёрстки начинается не с первого div’а.

Сначала смотрим макет.
Понимаем структуру.
Проверяем текстовые стили и состояния.
Собираем вопросы к дизайнеру.

И только потом идём верстать.

Так меньше сюрпризов, меньше переделок и меньше ситуаций из серии «а почему это всплыло только сейчас?» 😎

Салют, друзья! 🤘

Открываем четвёртый урок бесплатного курса по Taptop.

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

Внутри сначала разбираем важный момент с SEO: семантические теги для Header, Nav, Main, Section и заголовков.

Потом собираем саму обложку: секцию Cover, контейнер, cover-wrap, высоту на весь экран, внутренние отступы и границы.

Отдельно подробно разбираем Auto Layout: Grid: как он работает, как настраивать, как выставлять элементы и чем отличается от Flex.

Дальше добавляем внутренние элементы: буквы ГКВ через div-маски, центральный блок с заголовком, текстом и кнопкой, отдельный H1 для SEO, серый фон, линии и декоративные квадратики.

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

Новый урок уже доступен в боте: @Izum_Study_bot

Смотрите, пробуйте повторить за Андреем и пишите в закрытую группу, если что-то непонятно или хочется обсудить ❤️

Салют, друзья! 🤘

Открываем пятый урок бесплатного курса по Taptop.

На этот раз собираем блок «Красные флаги». Это не обычный слайдер с кнопками или свайпом, а блок, который работает по скроллу.

Урок разбили на 2 части.

Сначала собираем статику: структуру блока, линии, декоративные квадратики, контентную часть, карточки и визуалы.

Потом переходим к самому интересному: настраиваем и разбираем позиционирование sticky, отключаем pointer-events там, где это нужно, и собираем анимацию смены слайдов по скроллу.

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

Новый урок уже доступен в боте: @Izum_Study_bot

Смотрите, пробуйте повторить за Андреем и пишите в закрытую группу, если что-то непонятно или хочется обсудить ❤️

👀 Perfect pixel или флюид?

Perfect pixel звучит красиво. Взяли макет, перенесли всё пиксель в пиксель. Получили идеальное совпадение.

Но есть нюанс. Сайт живёт не в одном размере экрана. У пользователей мониторы на 1280, 1366, 1440, 1600, 1920. Плюс куча промежуточных вариантов, планшеты, мобилки, разные браузеры и высоты окон.

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

И чем жёстче подход, тем больше состояний придётся собирать.
Сначала делаем идеально на 1280.
Потом отдельно на 1366.
Потом на 1440, 1600 и 1920.
Плюс планшет и мобильные версии.

Так для одного лендинга набирается 10–12 состояний. И всё это только ради того, чтобы выглядело «как в макете».

Флюидная вёрстка решает задачу иначе.

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

Это не значит, что можно забыть про аккуратность. Наоборот. Флюид требует чёткого понимания: от какого разрешения строим базу, как всё масштабируется, где реально нужен breakpoint, а где он будет лишним.

Зато сайт ведёт себя спокойнее.
Он не скачет от одного жёсткого макета к другому.
Не требует ручных правок на каждом промежуточном размере.
И не превращает адаптив в бесконечный список исключений.

Perfect pixel отлично работает там, где размер всегда фиксированный. Но сайты почти никогда не живут в одном размере.

Поэтому для современных сайтов флюид удобнее. Это меньше ручной подгонки, минимум лишних breakpoint’ов и полный контроль над интерфейсом между экранами 😎