Главная » Хабрахабр » Редизайн с большой буквы: изучаем перезапуск Smashing Magazine в 2017-м

Редизайн с большой буквы: изучаем перезапуск Smashing Magazine в 2017-м

Редизайн популярного сайта — всегда большая и сложная задача, где в миллионе вопросов всё может пойти не так. А когда речь о Smashing Magazine, всё становится ещё интереснее: какие решения приняли создатели сайта, который рассказывает миллионам читателей как раз о возможных веб-решениях?

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

А на случай, если вы предпочитаете смотреть англоязычный оригинал или если в нашем переводе какие-то места окажутся неясными, прикладываем и видеозапись: Получился подробнейший текст с 70 иллюстрациями (осторожно, трафик).

Я расскажу об изменениях, произошедших со Smashing Magazine за последние два с половиной года. Раньше я никогда не участвовал в проекте, который занял бы такое время, пусть и не фуллтаймовой работы. Стоило довольно больших усилий перейти от этого варианта:

К этому:

Если вам не нравится красный (хотя для России, наверное, такое нетипично), его можно отключить.

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

Дизайн

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

Проблема заключается в нехватке индивидуальности, но не нас самих, а в индивидуальности того, что мы совместно создаём. На мой взгляд, в случае с дизайном есть важная проблема в том, как мы понимаем креативность, рабочий процесс, взаимодействие друг с другом. Можете ли вы припомнить какой-либо сайт (кроме тех, которые вы сами разработали), который был бы настолько запоминающимся, что вы до сих пор о нём думаете?

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

Часто на творческий процесс смотрят так (не важно, о чём речь — дизайне, разработке, или ещё чем-то): вы начинаете в определенной точке, затем продолжаете, иногда достаточно запутанно, пока не дойдете до финишной прямой.

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

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

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

Кто из вас участвовал в спорах: давайте поменяем border-radius с 14 на 12 пикселей? Мы, в особенности дизайнеры, очень сильно повернуты на пикселях. Имеет ли это реальное значение? А через месяц решают, что все-таки лучше 13. Не теряем ли мы за этим перспективы?

Если мы посмотрим на эволюцию интерфейса, представленную на экране, то увидим, что за 30 чертовых лет практически ничего не поменялось, кроме border-radius и нескольких иконок тут и там.

Говорят о 67 оттенках синего у Google, как там тестируют разные цвета ссылок, чтобы понять какой отклик они вызывают у пользователей. Может, нам нужны более серьезные изменения? И у них есть традиция вводить новый тип чуть ли не каждый день и смотреть, какие результаты он дает. А у приложений Facebook вообще 228 вариаций значков.

Наверное, детали вроде порядка слов тоже надо тестировать, но при этом нельзя терять из виду перспективы. Мне очень не нравится A/B-тестирование, куда больше мне нравится тестирование A/Z, когда сравниваются принципиально разные вещи. Иногда это доходит до абсурда.

У кого из вас был следующий диалог с дизайнером: из-за iPhone Х нам крышка. Часто мы чрезмерно следуем моде. Но на самом деле эта проблема не имеет никакого значения, поскольку 98% людей на айфонах читают страницы в интернете вертикально, а не горизонтально. Эта штуковина наверху порушит нам все, она в корне поменяет то, как люди смотрят сайты.

Сколько приложений люди скачивают в месяц? Нам очень нравятся данные. Сколько приложений вы лично скачали в этом месяце и реально используете? Почти половина — ни одного. Тоже, наверное, не пять?

То же касается остальных кнопок для сайтов — «понравилось», «tweet», «LinkedIn» и так далее. Вот еще статистика: специализированной кнопкой «поделиться» пользуется 2 из 1000 пользователей мобильных телефонов. Поэтому как раз и нет, люди ими не пользуются. И при этом люди спрашивают: а почему у вас нет специальных кнопок для социальных сетей?

п.) пользователи отклоняют либо игнорируют, даже не читая. Или другая статистика, 90% запросов на предоставление разрешения (на пользование историей пользователя, положением и т. Действительно, кому хочется делиться своей личной информацией? Скорее всего, большинство из вас тоже так поступает.

Я спросил себя: а где здесь есть место индивидуальности? Итак, нам нравятся данные, нам нравятся вещи, уже достоверно работающие. Я не хотел, чтобы мы были нейтральными, хотел вызывать какую-то эмоцию — быть любимыми или ненавидимыми. Когда мы только начинали работать, мы поставили себе вопрос: не просто «что сделает нас отличными от других», а что может нам дать голос в сообществе?

Поскольку у нас всех достаточно высокий уровень, нам всем надо выделяться на общем уровне. Датский дизайнер Моуэнс Мюллер (Mogens Møller) сказал на одной из конференций несколько месяцев назад вещь, которую, в общем-то, говорят на всех конференциях. Нужна индивидуальность, дизайн должен быть запоминающимся, внимание к мелочам должно быть непревзойденным.

Сколько бы времени, ресурсов вам понадобилось на разработку этого сайта? Когда я это слышу, я думаю о сайтах вроде dada-data.net, посвященном дадаизму. Думаю, все согласятся, что у сайта есть индивидуальность, но лично мне он не по карману. Сколько итераций пришлось бы пройти, каким должен был бы быть бюджет? За выходные нечто подобное не собрать.

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

Я спросил себя: почему у меня нет совершенно никакой привязанности к Uber? На мой взгляд, есть принципиальное различие между приложениями типа Uber и типа MailChimp. Но чтобы я перестал пользоваться MailChimp, кому-то пришлось бы напрямую заплатить мне деньги. Если бы появился сервис на 10 центов дешевле, я моментально бы на него перешел. К MailChimp у меня привязанность значительно больше.

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

«Привет! В этой раскраске, на мой взгляд, прекрасное оформление и выбор слов. Быть мной весело! Меня зовут Фредди. «Я скучен, я самый ужасный человек в мире?» Там много ещё, и последний рисунок: «Мне нравится быть мной. А тобой?» Как можно на это ответить негативно? Тебе нравится быть тобой?» Я сам себя ненавижу, каждый день, с утра с момента как проснусь.

Вот пример их интерьера: Другая история, которую я хочу вам рассказать, касается Tijuana Flats, сети мексиканских ресторанов в США.

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

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

Они наняли дизайнеров и дали им полную свободу действий. На своем опыте этот урок очень хорошо усвоила компания Bloomberg. Когда последний раз вы пользовались тегом <marquee>? Получившийся продукт можно очень много ругать, тем не менее, он прекрасен, и выполняет свою работу: билеты стали продаваться значительно быстрее, чем в предыдущий год.


Советуем перейти по ссылке, скриншотом это не передать

Хорошо, мы работаем в JavaScript, нам этот тег не нужен. Нет ответа. И многими другими вещами, которыми, как считается, пользоваться «не стоит». Но в целом, почему бы не пользоваться разными безумными вещами, хотя бы просто чтобы попробовать?

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

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

Ему самое место в музее. А в этом проекте про Илона Маска ещё много всего, поисследуйте его самостоятельно.

Такой «сломанный» дизайн я создавать не хочу. И я задал себе вопрос: что это все означает для Smashing Magazine? Давайте возьмем что-то самое скучное или самое раздражающее всех. Но мне пришли в голову несколько вариантов. Кажется, одному человеку в зале, и, возможно, еще кому-то, кто не готов публично в этом признаваться. Скажем, кому нравятся всплывающие окна?

Да, это реклама, но оформить ее можно по-разному. Но если вдуматься, то что в них плохого? Представляю вам всплывающее окно с volkshotel.nl: самое раздражающее и самое прекрасное в мире всплывающее окно.

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

Возьмем нечто крайне скучное, например, окно выбора формы обращения «мистер/миссис/мисс». Другой пример. Давайте попробуем поменять это окно, например, вместо свободного выбора сделать закрытый, но очень длинный список. Мы все знаем, зачем оно нужно на самом деле — для целевой рассылки спама по полу. лейтенант». С вариантами вроде «ваше превосходительство» и «тов. Этого может быть достаточно, чтобы поменять всю индивидуальность вашего сайта.

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

Если я сейчас сделаю опрос, скорее всего окажется, что 80% пользуются ими, а 20% врут в опросах. Проблемой, с которой мы с самого начала столкнулись, были блокировщики рекламы. Я блокировщиком тоже пользуюсь, считаю их полезными, и вам советую, если вы его еще не установили.

Последние 5 лет каждый год они падали в 2 раза. Тем не менее, для нашей компании блокировщики стали проблемой, поскольку стали падать доходы от рекламы. У нас аудитория из людей вроде вас, конечно, вы используете блокировщики рекламы, вы же не дураки! Во время последней смены дизайна где-то у 12% наших пользователей были установлены блокировщики, а сейчас — у 66%.

То есть возникла проблема, требующая решения. Но это означает, что наша прибыль составляет 1/16 от того, что было пять лет назад. Нам нужно было найти другой подход, представить новый продукт, который должен стать центром всей нашей деятельности. Проблема в самой рекламе, она не работает и, в любом случае, я не верю в традиционную «медийную рекламу». И доступ должен происходить ко всему этому сразу. Не хочу говорить слишком подробно, но суть в том, что это подписка, дающая доступ к Smashing TV, вебинарам и тому подобным вещам.

Журнал уже работал к тому времени ни много ни мало 10 лет под старым добрым WordPress с большим количеством добавлений. На тот момент наша система состояла из следующих составляющих. Он неплохо работал, но его сложно было связать с журналом на WordPress, пока не появился плагин для Shopify. Помимо этого был онлайн-магазин, работавший поначалу на Magento и затем перешедший на Shopify. Все вместе связать было достаточно сложно. Кроме того, мы пользовались Kirby для создания статичных сайтов для Smashing.com и еще на Ruby-приложении был основан сайт с вакансиями. Например, вы осуществляете вход один раз и затем получаете скидку в системах на WordPress, Magento, Ruby и т. Чтобы создать проект, объединяющий все эти элементы, он с ними должен быть связан. Этот проект нам надо было написать с нуля. п., не создавая при этом отдельного аккаунта на каждой платформе.

Большая часть CSS была написана Сарой Суедан (Sara Soueidan), большая часть JavaScript — Ильей Пухальским. Мы собрали команду, и, несмотря на то, что презентую я этот проект в одиночку, работа перечисленных на экране людей была по-настоящему важна, заняла много времени и сил. И, кроме того, мы использовали Netlify в этом проекте. Тут работало много людей, включая «кошачьего иллюстратора» — скоро поймёте, что это значит. Я хочу рассказать вам о том, как мы действовали и почему. Проект оказался дорогим, и изначально мы хотели запустить всё к 10-летию с появления Smashing Magazine, затем к 11-летию, завершили только несколько недель тому назад.

Это было одной из главных вещей. Мы начали с текста, с названий компонентов. Мы начали с того, что посмотрели на интерфейс вот так:

Вы думаете о том, какие компоненты нужны странице или сайту, записываете их все. Это был мой первый набросок. У меня здесь есть прототипы микровзаимодействий: «Вы действительно хотите удалить этот файл?» Ещё не надо ничего воплощать, но надо продумать, что вам нужно, и дать этому названия. Он определяет то, как вы будете строить ваше взаимодействие с клиентами. И, в частности, я с самого начала думал над сообщениями об ошибках:

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

Тот вариант, который мы выбрали для заголовков — я его терпеть не могу. Затем мы перешли к выбору шрифта. А мне не хотелось, чтобы моим наследием остались кошки. Однако когда мы стали спрашивать у людей, с чем для них ассоциируется Smashing, то оказалось, что не с уважаемыми и профессиональными публикациями, а, например, с кошками. А собаки? Поднимите руки, кому из вас нравятся кошки? Обычно 40% собачников, 30% кошатников, а оставшимся наплевать на тех и других. Ух ты, наверное, это единственная страна, где кошек любят больше.

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

Сейчас у нас этих кошек 68 штук в разных местах в интерфейсе. Я решил, что тут важнее не мои предпочтения, а то, как нас воспринимают люди. Всех их вам не найти. Если вам удастся найти их все, я обещаю, что оплачу вам поездку в бизнес-классе на любую из наших конференций в любой точке мира, с учетом проживания, еды и чего бы вы ни захотели. Им можно только пожелать удачи, поскольку некоторые из картинок написаны в ASCII, а некоторые — в print.css. У меня есть знакомые, которые, когда я предложил им это пари, сказали «ты не знаешь, с кем связался», и написали алгоритм с машинным обучением, который пытался искать эти картинки.

Мы экспериментировали с вёрсткой, дошли до возможности поворота и посмотрели на свой логотип, который уже был под углом. Нам было важно взглянуть на вещи под правильным углом — причем в буквальном смысле слова. 6 градусов, а при редизайне стал 11 градусов. Раньше этот угол составлял 10. А это значит, что все остальное также должно быть под углом в 11 градусов, как видно в нашем стайлгайде; у нас все на основе компонентов. Большой шаг для нас!

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

Наверняка многие из вас видели созданную ими связку между Sketch и React. Затем они развили эту идею еще дальше, и назвали ее air/shots. По словам Бенджамина Уокинза, они решили, что если машинное обучение может отличить друг от друга сложные, написанные от руки изображения (вроде китайских иероглифов), то наверняка можно научить ее распознавать каждый из 150 компонентов нашей системы.

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

Перед вами пример нашего дизайна, как видите — все под наклоном. До этого мы, конечно не дошли, но в основе нашей работы тоже лежали отдельные компоненты.

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

Я человек ленивый, поэтому мне это казалось значительно проще, чем заниматься генерацией .pdf. Мы много внимания уделили вещам вроде Print Style Sheet. То же самое и со статьями. Вот пример чека, сделанного таким образом, и не нужны никакие расширения. Я решил, что надо один раз потратить достаточно времени на создание Print Style Sheet, который объединял бы несколько статей в один документ, и на выходе создавалась бы книга, прилично оформленная, со ссылками и прочим. Мы занимались созданием электронных книг, а в них часто есть статьи.

Фронтенд

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

С тех пор Firefox опустился до 7%, а Chrome только набрал популярности до 66% — то есть люди переходят с IE не на Edge или Firefox, а на Chrome. Большая часть из них хорошие, поскольку на сайт к нам приходят посетители вроде вас — вам ведь не придет в голову пользоваться IE 8, правильно? 2 до 0. Edge даже упал в популярности, с 1. Кто из вас пользуется Edge? 6%. 0%? 0. Данные немного сбивает тот факт, что раз в два года на сайт заходит пользователь с user-agent IE 666. Это немного грустно. Это, конечно, мило.

Знакомы ли вы с пирамидой потребностей Маслоу? Когда мы начали писать компоненты, мы следовали определенной пирамиде. Самый нижний уровень — это скорость, о ней нужно думать в первую очередь при написании любой страницы или компонента. Пэтти Толанд и FilamentGroup в Бостоне пришли идея применить принцип этой пирамиды к responsive design. п.). Затем идет доступность, масштабирование, и, наконец, стиль (логотипы, цвета, шрифты, анимации и т.

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

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

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

А потом ещё одну. Для борьбы с этим можно добавить точку прерывания (breakpoint). А в итоге получается страшная возня при переменах в структуре страницы. А потом ещё. Конечно, мы пользуемся вещами вроде Sass и Less, но всё равно приходится проходить по медиа-запросам и чинить их, а я не люблю заниматься починкой.

Как эффективно изменять размеры любого элемента UI (хоть слайдера, хоть календаря) с сохранением пропорций, но без обращений к их параметрам широты и высоты напрямую? Так мы пришли к мысли о необходимости гибких размеров (fluid sizing) для всех компонентов. С помощью небольшого трюка, о котором вы уже можете знать.

Есть размер шрифта body. Есть ваш компонент. 1 rem всегда равен размеру шрифта body. Есть единица rem, она завязана на корневой элемент (body или html). Вместо того, чтобы менять все в медиа-запросе, вам просто надо указать, что мы перейдём от размера шрифта 75% к 125%. Если размер шрифта у компонента выставить в единицах rem, а все остальное — в единицах em, то при увеличении окна всё вырастет. Все внутри элемента вырастет соответственно.

Нам не нужно, чтобы компонент рос таким образом: Но это — только первый шаг.

Рост должен быть контролируемым, он должен начинаться и прекращаться в определенных точках: Нам не подойдёт, если элемент будет размером в 1 пиксель на небольшом экране и 500 пикселей на крупном.

Тогда мы сможем выстроить точки прерывания в линию. Попробуем сделать график, на котором по вертикальной оси будут указаны размеры шрифтов, а по горизонтальной — ширина viewport. Она не будет прямой:

Поскольку нам всем нравится математика, эту зависимость можно описать уравнением y = mx3 + mx2 + mx + b.

Может быть, это возможно в JavaScript, но все равно это абсурд. В CSS такого, конечно же, никак не сделать. Вместо бесконечного написания точек прерывания можно один раз описать компонент, и он будет правильно отображаться на любых экранах, хоть на телевизионных. Но важна сама идея: представьте, что у каждого компонента была бы функция, определяющая его поведение. Можно разбить кривую на несколько прямых, каждая из которых будет определена как y = mx + b. Даже если это будет приближением, оно будет достаточно точным. В итоге приходишь к такому:

Ну, у меня оно возникло, но делать этого действительно не стоило. Но реализовывать такое в CSS или JavaScript у вас желания, скорее всего, не возникает, не правда ли? В CSS этот принцип можно реализовать при помощи формулы: В конечном итоге, нам нужно достаточно простое поведение: чтобы с определённой точки элемент начинал расти, а после определенной — переставал расти.

В начале формулы 16 пикселей — это минимальный размер шрифта. В CSS calc позволяет совершать базовые арифметические операции. Затем идет диапазон, в котором еще может продолжаться рост, и, наконец, разница между максимальным и минимальным размерами экрана. Затем ищется разница между максимальным и минимальным размерами. И получаете что-то вроде codepen.io/MadeByMike/pen/VvwqvW. Вот и все, что вам необходимо.

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

В последнем случае, опять-таки, речь идет не о неконтролируемом росте, а об изменении между 1. Мы подумали: почему бы не использовать этот метод вообще везде: с границами, отступом, шириной, вплоть до высоты строк. 5. 3 и 1. Принцип тут тот же, надо только пересчитать формулу.

Можно просто выставить динамический размер шрифта на элементе HTML в CSS. Есть два способа достичь этих результатов.

Если же вам нужен контейнер фиксированного размера, вы можете просто определить fixed-container с размером шрифта в пикселях и размером внутренних компонентов в em. И тогда, в зависимости от viewport, все внутренние элементы автоматически будут приведены к масштабу.

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

Если откроете Smashing Magazine и начнёте менять ширину окна, увидите, что все составляющие меняются: ширина, высота, межстрочный интервал, размер шрифта, SVG-логотип в углу и так далее. На этом варианте мы в итоге и остановились.

Но всё это делается через calc. Конечно, для этого нужно много «волшебных» чисел в CSS. Другим свойствам, возможно, несколько грустно от этого, но calc у нас — самое используемое.

Вот цитата из Гарри Робертса: «Я не знаю, какая у этого функция. Нам очень помогло организовать наше пространство имён. Я не знаю, можно ли это стереть, изменить, или использовать еще где-либо. Я не знаю, где это еще используется. В итоге мы стали использовать много приставок для различных компонентов, например, таких: Я вообще об этом ничего не знаю!» Каждый из нас сталкивался с такой ситуацией, когда вы, будучи дизайнером или разработчиком, обращаетесь к CSS и JavaScript и не понимаете, что к чему.

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

Я предполагаю, что в России о BEM слышали. Конечно, мы так же пользовались BEM, для определения связей. Мне, кстати, эта политика непонятна, поскольку, как мне кажется, в Европе и в США BEM достаточно хорошо известен, нет нужды так агрессивно его продвигать. Хоть, возможно, его и не уважают из-за настойчивости, с какой его рекламирует Яндекс.

Другая важная тема — это отзывчивые суффиксы, с которыми можно сделать что-то такое:

Если в классе написано «c-image-list@small-screen c-carousel@large-screen», то мне сразу становится ясно, что тут к чему. Цель такая: из кода должно быть ясно, что он делает, без необходимости заглядывать в CSS или JavaScript. Все, что остается сделать в CSS — это поставить символ “\” перед “@”.
Некоторая часть из этого кода написана другими людьми, некоторая часть — мной.

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

Кто из вас о ней слышал? Другая крайне полезная вещь — это модульная сетка в CSS, то есть Grid Layout. А кто пытался с ней поиграть? Оказывается, все. Давайте посмотрим, что при её помощи можно сделать.

Когда её пытаются рекламировать (непонятно, зачем, она и так прекрасна), зачастую показывают следующую картинку:

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

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

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

Например, при помощи ключевого слова repeat() можно создать несколько дорожек с одинаковыми параметрами. Сеть определяется через задание шаблонных столбцов grid-template-columns, и для этого можно использовать различные нотации.

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

У нас есть простой пример построения такого контейнера:

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

Есть значительно лучший способ. Пожалуйста, не поступайте так.

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

Если вдруг вы не знаете, это функция для определения возможностей в CSS. Первое, что мы добавляем — это supports. Загвоздка только в том, что у supports не всё хорошо с браузерным, так сказать, support. Ее можно использовать вместо Modernizr. Зато у любого браузера с суппортом supports будет и суппорт «display: grid».

Этих линий всегда будет на одну больше, чем столбцов. Далее, мы определяем столбцы сетки, и присваиваем имена линиям разделения: “full-start”, “main-start”, “main-end”, “full-end”. У каждой линии может быть несколько имён.

Затем, если надо вывести что-либо за пределы контейнера, указывается “grid-column: full”, и содержимое занимает все три столбца. Теперь осталось только указать: всё, что находится в контейнере, необходимо поместить в столбец main.

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

Я задался вопросом, как его можно реализовать. Дизайнерам почему-то очень нравится идея «вертикального ритма». На экране из двух примеров это выполнено правильно в том, который справа. Представим структуру страницы с заголовками, текстом, изображениями, в которой все элементы должны быть выровнены по правильным линиям.

Сделать это, на самом деле, достаточно просто.

Извините, что так много CSS, уж очень мне это дело нравится. Здесь есть тег figure, который выводится за рамки родительского контейнера (“breaks out”).

Для body можно выставить свойство calc, затем для root выставить свойство --gutter, которое определит зазор между строками.

И, наконец, осталось передать в grid-row-gap то значение, которое мы определили для gutter в root.

Достаточно часто у дизайнеров есть требование, согласно которому в каждой строке должно быть, например, 60 или 70 символов. Интересно, что я тут использую единицу измерения ch, «символьную», которой редко пользуются. И получается 12 дорожек по 4,85 символа.

Лия поправит меня, если я ошибаюсь. Единица ch (character unit) основана на ширине символа «0» в данном шрифте. (Голос Лии Веру из зала: «Правильно»).

Сравним два варианта:

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

CSS стал невероятно простым. Итак, структура страницы оказалась достаточно короткой. Кроме того, вам, конечно же, нужно будет использовать селектор “*”. Или сложным, зависит от того, как посмотреть.

Вот пример его использования: элементы, попадающие под правило “* + *”, получат свойство margin: 0, и содержимое будет ограничено центральным столбцом. Он замечателен. Никаких медиа-запросов не происходит. Все, больше ничего делать не надо. И с точки зрения гибкости и топографии, у нас все построено именно таким образом.

Выйдем на наш сайт, прокрутим страницу немного вниз… Небольшое отступление: вот мы видим кнопку, на которой написано, что она «ничего не делает».

Так вот, именно на эту кнопку чаще всего нажимают! Это тоже часть индивидуальности, которую мы пытаемся придать нашему сайту. Что не так с людьми?

У нас всё реализовано так, как я рассказал, и с этим подходом есть сложность. Вернёмся к теме. Например, в Edge 13 код, который я только что вам показывал, интерпретируется весьма оригинально: Существуют браузеры, которые поддерживают supports, но при этом достаточно плохо поддерживают модульную сетку.

Потребовалось много времени, чтобы выяснить, чем это обусловлено. Поэтому в коде надо заменить display: grid на grid-gap: 0, не спрашивайте почему. Сумасшествие.

Бэкенд

Под конец я хочу поговорить о бэкенде. Крайне важная тема, особенно, я думаю, для вас. Кто-то, возможно, слышал о JAM Stack. Один человек. Хм, я этого не ожидал. Ничего страшного.

В 2012 году я встретил Мэтта, впоследствии ставшего одним из основателей Netlify. Я рассказывал о том, как мы делали наш журнал на основе WordPress, все было на PHP (кроме частей на Ruby). Когда меня заинтересовало их творение, Мэтт продемонстрировал перенос наших ресурсов на CDN Netlify, благодаря чему производительность возрастала в три раза (при том, что мы уже на тот момент потратили много усилий для оптимизации нашего процесса на WordPress). Это платформа для автоматизации веб-проектов, использующая CDN вместо традиционных серверов, и в эту CDN они как следует вложились.

Хотя задействовано было много людей, большая часть — это наша с Ильей работа на CSS и JavaScript. Этот проект занял у нас целых два года из-за того, что у нас было много параллельной с ним активности. Это не совсем так. Иногда говорят, что мы ненавидим WordPress. Просто не особо люблю! Я его не ненавижу. Просто в определенный момент он перестал нам подходить. Ну, вообще он норм — инструмент, как любой другой. Как она устроена? Мы перешли к системе на основе генераторов статичных сайтов, которую также часто называют «JavaScript, API и разметка» или JAM Stack (разметка — markup).

Кроме того, конечно, растут Gulp, Grunt и подобные им инструменты. Мы все знаем, что интерес к FTP падает и он медленно умирает, а интерес к Git растет. Наконец, для них есть очень много различных API.

Изначально у нас были только взаимодействующие браузер и сервер. Вспомним историю. После этого сказали «и этого недостаточно», добавили базы данных на серверах, на PHP, MySQL и Apache. Затем кто-то сказал «нет, надо ещё программу для интерактивных вещей на cgi-bin и Perl». Когда это было реализовано, решили, что нам нужно что? Но и этого оказалось недостаточно, для увеличения производительности нам нужно кэширование. Всё это привело к колоссальному росту числа взаимодействующих сущностей в системе: Правильно, CDN.

Сделаем просто «браузер и CDN». И тогда-то возникла идея: возможно, нам следует вернуться к максимально простой схеме.

У нас есть система, которая скорее всего, присутствует также у всех вас, из Git, средств сборки и API. Работает это следующим образом. Каждая статья, каждый комментарий, каждый автор, каждая вакансия записываются как файл markdown. Код подаётся в средства сборки. Это затем отправляется на CDN, где к этому получает доступ пользователь. Далее из всего этого создается HTML, добавляются CSS и JavaScript. Интерактивные вещи вроде поиска и комментариев делаются при помощи JavaScript поверх всей этой системы.

Не возникает, поскольку это не одностраничное приложение, а набор одностраничных приложений. Мы пользовались Preact, что часто вызывало вопрос: не возникает ли проблем с временем загрузки? У нас нет ни единого блокирующего запроса, поскольку вы просто заходите на страницу и загружаете критический CSS наверху. Благодаря этому для того, чтобы начать отображать наши страницы или читать статьи, JavaScript не нужен вообще. И, конечно, наше приложение является PWA («прогрессивное веб-приложение»), хотя по большому счету других сегодня, скорее всего, уже и нет. Для разных страниц у нас пять или шесть блоков критических CSS.

У нас достаточно много микросервисов и API, но ничего особо сложного не происходит. Перед нами стек, в нем ничего сложного. Для оплаты используется Stripe. Конечно, есть проверка наличия подписки и подобные вещи. Для «бэк-офиса» в бэкенде используется система на Go.

Скорее всего, мы были одним из первых проектов такого масштаба, перешедших на JAM Stack. На меня большое впечатление произвела скорость этой системы. Если интересно, мы используем Hugo в качестве генератора статических сайтов, и мы используем Webpack. Я не ожидал, что у нас это получится, и был рад ошибиться. А также Gulp и Grunt, поскольку нам нужные разные плагины.

Netlify сделали для нас CMS, GoTell для комментариев, GoTrue для аутентификации, GoJoin для подписки на Stripe, GoCommerce взамен Shopify, и Gotiator, также для аутентификации. За два года было создано множество вещей. Это был большой путь для нас.

На самом деле, это не так. Многие думают, что из-за такого подхода у нас возникает множество зависимостей. Все доступно и без использования JavaScript.

Например, в поиске как запасной вариант мы просто используем Google, и затем на него накладывается JavaScript. Если по какой-то причине вы не можете или не хотите пользоваться JavaScript, для всех действий есть запасные механизмы (ну, комментарии пока недоступны, это нам еще предстоит исправить).

На одном этом нам удалось сэкономить 600 миллисекунд. С точки зрения производительности нам больше всего помогло наше решение с веб-шрифтами, о котором я говорил во вчерашнем докладе.

Кроме того, у нас работают Preload, Zopfli/Brotli и gzip. Для отзывчивых изображений мы в устаревших статьях используем элемент picture, но также у нас работает служба Cloudinary. В развёртывании у нас пока один бандл, мы планируем перейти к 8 или 10. Мы используем критические CSS, а не загрузку по инициативе сервера.

Перед вами — то, как выглядит CMS. Попробую продемонстрировать. Тем не менее, с нашими задачами справляется. Это похоже на WordPress, но, конечно, гораздо хуже. Д. Лучше всего то, что всё находится в одном и том же месте, и у нас тут кастомно сделанные авторы, вакансии, события, выступления и т.

Вот вы видите результаты полугодичной давности, до того, как мы занялись оптимизациями. Производительность была невероятной. Изначально отрисовка начиналась у нас на 700 миллисекундах, сейчас, при стабильном подключении — до 0. К примеру, мы еще ничего не сделали с веб-шрифтами. Попробуйте добиться такого с любой базой данных под WordPress. 5 секунды. Просто не получится.

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

Попробуем, например, заказать книгу на нашем сайте. В качестве заключения поделюсь с вами небольшим секретом, который позволит вам сэкономить. Если же такого кода нет, а скидку хочется, что мы делаем? Там есть окно для ввода кода купона, который даст скидку. Кто из вас так делает? Правильно, мы начинаем искать код в Google. Мы в России, конечно, мы так делаем. (Поднимаются руки).

Как улучшить конверсию? Я много работал в коммерции, занимался тестированием вещей, связанных с этими кодами. К чему я всё это рассказываю? Мы знаем по опыту, что при использовании кода «из Гугла» он будет работать в меньшинстве случаев, соответственно, будет много ошибочных вводов. А этот код уже даст нам скидку на 1%. Если мы попытаемся ввести случайный купонный код в нашем окне, оно сообщит нам, что код выглядит «fishy» («подозрительно»), и предложит вместо этого ввести «FISH».

Потому что неизвестно, что произойдёт дальше — на сайте ведь есть много ничего не значащих вещей, например, поле для галочки с подписью «мне просто нравится ставить галочки». И пользователь, увидев это, дальше купит книгу в любом случае, даже если ему придётся для этого одолжить кредитную карту у соседа. Мы теряем здесь 1% от цены, но это куда менее обычных кодов со скидками вроде $10.

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

Уже на этой неделе Виталий выступит на HolyJS 2018 Piter с двумя другими: «Dirty little tricks from the dark corners of eCommerce» и «New adventures in frontend, Season 2». Понравился доклад? А благодаря дискуссионным зонам его там можно будет как следует расспросить — по темам новых докладов и не только.


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

[Из песочницы] Синтез как один из методов улучшения производительности PostgreSQL

Философское вступление Как известно, существует всего два метода для решения задач: Метод анализа или метод дедукции, или от общего к частному. Метод синтеза или метод индукции, или от частного к общему. Для решения проблемы “улучшить производительность базы данных” это может ...

Искусство парсинга 2 или транслитерация собственной разметки

+БОНУС: как включать классы друг в друга в C++ Привет, Хабр! Эта статья — прямое продолжение статьи Искусство парсинга или DOM собственными руками, где мы разобрали HTML-документ и построили на его основе абстрактное синтаксическое дерево (AST) с доступом к любому ...