Привет, средний - рад быть здесь. Я много лет использовал эту платформу и впервые решил написать собственный пост.
Я хотел бы немного рассказать о дизайн-мышлении и методах разработки, которые мы использовали для нового веб-сайта Keen. По пути мы узнали множество вещей, и я надеюсь, что некоторые из них могут быть полезны другим.
Еще в октябре 2017 года мы начали возиться с идеей перестроить веб-сайт нашей студии с целью отличить себя от конкурентов, более точно продемонстрировать набор наших навыков и попытаться установить более честную связь с тем, кто мы есть как личности и как личность. коллектив. На протяжении многих лет мы черпали вдохновение из множества веб-сайтов студий / агентств, но у большинства из них был такой святой способ, которым они сообщают, кто они и чем занимаются. Все они пытаются посоревноваться, кто лучше остальных говорит на маркетинговом жаргоне.
Наш процесс брендинга лучше, чем ваш. Сосредоточенность, соразмерность, вдохновение, исполнение и т. Д. Бла-бла-бла.
Сотни разных магазинов с сотнями разных творческих процессов, делающих одно и то же. Мы не хотим участвовать в этих крысиных бегах.
Мы хотим быть теми, кто мы есть, и хотим, чтобы наш веб-сайт служил окном именно в это. Не поймите меня неправильно, вам нужен хотя бы некоторый уровень этого маркетингового жаргона, хотя бы для чего-то другого, кроме SEO, и многие люди определенно читают и ценят этот тип контента, но мы этого не сделали. не хочу, чтобы это было краеугольным камнем нашего сайта.
У нас всегда были проблемы с тем, как веб-сайты обычно представляют собой набор страниц. Сейчас 2018 год! Интернет способен на гораздо большее. Просить сервер отправлять вам совершенно другую «страницу» каждый раз, когда вы щелкаете по ссылке, кажется примитивным. И почему посетитель нашего сайта должен так отличаться от посетителя самой студии? Оба случая дают нам возможность установить контакт с другим человеком, но первый часто используется недостаточно.
Студия направила некоторые творческие соки на поиск способа максимально честного общения с нашей аудиторией и как-то попытаться сократить разрыв в существующих различиях между посетителем, приходящим на наш веб-сайт и в нашу студию. Мы решили представить комбинацию нескольких разных идей - веб-камеру нашей студии в реальном времени и интерактивный чат, размещенный прямо поверх потока веб-камеры.
Конечно, мы были не первыми, кто придумал эти идеи, но в этом и не было необходимости. Эта комбинация может позволить получить множество интересных способов связи с нашими посетителями - и это то, что нам было нужно. Посетитель мог поздороваться, и мы могли помахать в камеру. Может быть, однажды мы все придем на работу в масках лошади. Кто знает.
Но мы надеемся, что люди покинут наш сайт с ощущением, будто они имеют представление о нас, а не о том, что они были просто маркетинговой тарабарщиной с ложечки.
Время сиять
Теперь, когда у нас появился маленький росток идеи, нам нужно было выяснить, как ее реализовать.
Мы начали придумывать идеи и перебрасывать разные подходы между дизайнерами. Мы довольно быстро остановились на эстетике и UX. Все опиралось на нашу первоначальную идею, и я лично считаю, что дизайн приносит наибольшее удовлетворение, когда он так распадается.
Сторона клиента
Разработка началась с подготовки клиентской части проекта. Мы довольно часто использовали React и Redux в Keen и решили полностью построить наш интерфейс с помощью приложения Create React, которое я очень рекомендую. Его просто использовать безболезненно, и мы не сталкиваемся с какими-либо проблемами из-за его чрезмерной самоуверенности. Мы даже не осознаем это, когда начинаем писать код. И я должен сказать - я чувствую, что React снова делает написание кода увлекательным.
Компоненты и 2018
Когда вы начинаете думать о пользовательском интерфейсе с точки зрения компонентов, это похоже на то, как бейсбольная бита, сделанная из логики, ударит вас в купол. Разделение кода на части делает функциональность более многократно используемой и расширяемой. Это похоже на то, как будто каждый компонент - это небольшой сгусток радости, который вы можете просто перетащить куда угодно, и он будет отрисовываться и работать безупречно. Вебу предстоит пройти долгий путь, прежде чем он станет нативным, но мы очень рады видеть прогресс с Shadow DOM и идеями, вытекающими из него. Будущее выглядит светлым, но тоже далеким. Да ладно, цифровые вундеркинды, докажите, что я ошибаюсь.
Пример, который, как мы обнаружили, является свидетельством того, почему компоненты так полезны для сегодняшней веб-экосистемы, можно найти в нашем проекте Подписки для SaaS.
В процессе создания собственного сайта мы спроектировали, разработали и запустили быстрый микросайт для одного из наших любимых клиентов из Германии. Сайт использует WP Rest API для контента в сочетании с клиентским приложением React, и это был очень полезный проект для разработки и создания.
В итоге мы написали несколько анимированных графических модулей из компонентов React для микросайта, остались очень довольны их результатом и захотели включить их в наш новый сайт в качестве портфельного проекта.
По сути, это было так же просто, как скопировать и вставить папку в другой проект, и бум - вся логика, стили и разметка были встроены в совершенно другой сайт, выглядели и работали отлично. Конечно, нам пришлось добавить несколько шрифтов и немного поддержки CSS, но это был глоток свежего воздуха. Это хорошая штука.
Состояние CSS
Поскольку мы были проектом для себя, мы смогли исследовать новые технологии и новые методы без риска привнести что-то слишком новое в производственную среду. Вначале мы немного поэкспериментировали с тем, как мы будем проектировать CSS.
Мы уже некоторое время оцениваем CSS-in-JS, и нам очень нравится его предпосылка, и мы видим преимущества определения стилей непосредственно для компонентов, но, к сожалению, он имеет недостатки и недостатки, которые не позволяют нам полагаться на него. для всего, что близко к всеобщему принятию. Встроенные стили медленнее обрабатывают браузер, а псевдоэлементы, наведение курсора и другие аспекты CSS на данный момент труднее реализовать. Кроме того, в глубине души это всегда было своего рода простым решением гораздо более серьезной проблемы веб-разработки, и я не люблю полагаться на такие временные решения.
Я в основном не согласен с документацией Create React App и позицией по использованию Sass в React. Да, компонентная природа библиотеки означает, что должно быть меньше совместного использования кода, что устраняет большую часть причин, по которым Sass используется в первую очередь, но мы по-прежнему довольно часто используем функции Sass, вложение и переменные. Кроме того, что бы произошло, если бы нам понадобилось предоставить CMS с предварительно стилизованными HTML-компонентами, которые можно было бы использовать в полях WYSIWYG? Подумайте о том, чтобы дать администратору возможность вставить <button class=”btn”> в поле WYSIWYG в конце абзаца. Это должно быть откуда-то стилизовано, и это не компонент React. И любые стили, составляющие эту кнопку, следует повторно использовать во всех других фактических компонентах React Button, присутствующих в базе кода.
По этим причинам мы решили написать наш CSS, по-прежнему в значительной степени полагаясь на Sass, и ограничили каждый компонент его собственным партиалом, который максимально изолирован от окружающих их компонентов, как и говорит React. Но почти все наши компоненты при необходимости импортируют небольшое подмножество партиалов Sass (миксины, вары, базовые показатели, структура и т. Д.), Которые для нас одинаковы от проекта к проекту. У нас это работает, но оставляет желать лучшего. Я планирую написать об этом пост в будущем.
Сервер
Для большинства веб-проектов Keen мы создаем локально, используем свежую каплю из DigitalOcean и настраиваем ее для производства на основе технического стека проекта.
Мы часто используем Let’s Encrypt для SSL и сделали это для нашего собственного сайта. Nginx будет действовать как обратный прокси для нашего приложения Node. Пока что все довольно просто.
CMS
Я мог бы говорить о состоянии CMS в Интернете в течение трех лет. Я жажду полностью JS-стека, и если бы мы собирались использовать PHP / MySQL CMS, мы могли бы также использовать WP Rest API в паре с Advanced Custom Fields и держать его отделенным от клиента (что, честно говоря, довольно круто) . Я не вижу особых причин, чтобы экспериментировать с другими вариантами PHP. Различные способы сделать одно и то же. Но у нас были большие планы на наш сервер Node - он должен был передавать поток веб-камеры пользователям, а также обеспечивать интерфейс чата в реальном времени. Последнее, что мы хотели сделать, это смешать стек LAMP с узлами и веб-сокетами.
Чтобы реализовать наши мечты о полностью JS-стеке, мы в конечном итоге реализовали KeystoneJS и использовали его веб-сервер Express для обслуживания как пользовательского интерфейса администратора Keystone, так и статических файлов из приложения Create React и нескольких конкретных маршрутов, которые мы добавили поверх Keystone.
Однако, когда дело дошло до управления контентом, Keystone на самом деле сильно ограничила нас на практике. Например, каждый из представленных на сайте проектов имеет уникальный макет и, следовательно, уникальную модель контента. Keystone полностью основан на списках, которые, насколько я понимаю, ограничены определенной моделью контента для каждого списка. Однако каждый из наших проектов должен был быть построен с использованием компонентов React - и нам никогда не нравилась и не оправдывалась идея просто вставить большой пакет HTML в WYSIWYG, а затем проанализировать его в HTML.
Это означает, что Keystone бесполезен для нас в большинстве случаев, почему мы использовали его для обработки нашего контента. В итоге мы статически сохранили наши проекты, членов команды и страницы сервисов в виде объектов в массивах JS, каждый со своими собственными свойствами и компонентами React, импортированными в CRA и связанными. Худой и скупой. Мы разработчики. При этом мы планируем использовать Keystone для будущих потребностей в управлении контентом сайта Keen, где его основанная на списках природа могла бы быть более уместна (подумайте о сообщениях в блогах, будущих студийных досках настроения и т. Д.).
ОБНОВЛЕНИЕ CMS (27 августа 2021 г.):
С тех пор, как я написал этот пост, я покинул Keen, чтобы основать новое цифровое агентство под названием TRBL, и там моя команда и я создали Payload CMS как прямое решение того, что мы всегда хотели. Мы запустили его в январе 2021 года и получили безумно положительный прием, и его сообщество бурно. Это сверхмощная автономная система управления контентом на Node / TypeScript, созданная специально для разработчиков React.
Проверьте это!
Настройка веб-камеры
Первой реальной проблемой сайта была попытка выяснить, как транслировать прямую видеотрансляцию из нашего офиса посетителям на нашем сайте. Существует множество готовых решений, которые могут предоставить прямой поток с веб-камеры в приложение или в Интернет, но мы хотели получить немного больше контроля над происходящим, чем то, что можно было бы предоставить с помощью готового решения.
После некоторого исследования мы нашли два очень полезных пакета программного обеспечения, которые можно было бы использовать для создания веб-камеры.
Но сначала, что касается аппаратного обеспечения, мы взяли Raspberry Pi и дешевую веб-камеру за 40 долларов от Amazon для захвата и потоковой передачи потока. Отсюда мы выбрали ffmpeg , инструмент командной строки, который помогает преобразовать и потоковое мультимедиа, чтобы отправить поток с веб-камеры USB на HTTP-сервер, который мы будем запускать где-нибудь в дикой природе.
ffmpeg действительно круто. Одна команда направляет поток веб-камеры из нашего офиса в любое место, где мы захотим.
ffmpeg -re -f video4linux2 -video_size 640x480 -i /dev/video0 -f mpegts -codec:v mpeg1video -s 640x480 -b:vb 2000k -vf hue=s=0 http://recipient-url-goes-here.com
Здесь мы установили ffmpeg для использования физической камеры, подключенной через USB на /dev/video0, с разрешением 640x480 и битрейтом 2000k, для потоковой передачи по URL-адресу, настроенному для приема и распространения. Мы также использовали несколько удобных встроенных фильтров для преобразования потока в оттенки серого.
Мы написали быстрый сценарий оболочки для Pi, который автоматически запускал указанную выше команду при перезагрузке и сохранял ее работоспособность в случае сбоя.
URL-адрес, настроенный для получения потока, представляет собой сценарий узла, работающий в нашей капле DigitalOcean, в основном основанный на этом очень полезном репозитории. На самом деле это довольно просто. Сервер Anhttp принимает входящий поток, а затем распределяет его среди всех подключенных клиентов через websocket. Дроплет, запускающий скрипт, может отвечать за увеличение пропускной способности, поэтому мы следим за этим и масштабируем его по мере необходимости - но мы на данный момент не получайте большого количества трафика, поэтому битрейт 2000k на одного клиента должен быть вполне выполнимым на данный момент.
Клиентское приложение React использует пакет с именем JSMpeg для подключения к потоку mpeg-1, его декодирования и отображения, который также можно найти в приведенном выше репо. Но на самом деле мы выбрали расширение JSMpeg под названием jsmpeg-player, потому что оно предоставляет еще несколько опций, а также обратные вызовы событий.
Чувак, Javascript - это здорово. Так много невероятно трудных задач, которые так изящно выполняются для нас другими тайными супергениями, бесплатно.
Чат
Мы использовали Socket.IO для самого компонента чата. Существует около 100 000 руководств по созданию интерфейсов чата с SocketIO, поэтому я не буду вдаваться в подробности, но работать с ним в React и Redux и приспосабливать его было довольно забавно. так легко с Node на бэкэнде.
Если заинтересованный администратор присутствует и вошел на сайт, чат автоматически становится общедоступным, но в остальном он остается отключенным. Администратору предоставляется список всех сетевых сокетов, каждый со своей собственной цепочкой беседы, и уведомления отправляются как администратору, так и пользователю, когда одна из сторон отправляет сообщение. Пользователи видят только их собственные разговоры с увлеченными администраторами, а сообщения вообще не сохраняются в памяти. Система полностью глубока на уровне поверхности. Отключитесь, потеряйте свою историю. Чат создан не для работы - он создан для игры.
Остальная часть сайта
Разработка длилась около 4 месяцев, работала между клиентскими проектами и в нерабочее время. За это время несколько наших зависимостей выпустили критические изменения, в первую очередь 15_, на которые мы в значительной степени полагались для наших рандомизированных переходов между представлениями. Меня не перестает удивлять, как быстро все меняется в Интернете.
То, как мы представляем нашу работу на сайте, претерпело несколько радикальных изменений из-за ограничений рендеринга CSS и старого оборудования, и мы фактически отказались от нашего первоначального подхода всего за несколько недель до запуска. По состоянию на начало 2018 года поддерживать выше (или приближаться к) 60 FPS во всех CSS-анимациях на всех устройствах (включая старые телефоны), действительно, является сложной задачей .. Есть так много ошибок в том, как CSS по-прежнему обрабатывает интенсивный рендеринг и Я думаю, что вебу предстоит пройти долгий путь с точки зрения производительности при работе с анимацией и переходами.
Тем не менее, мы очень рады услышать, что все думают о новом сайте, и рады прочитать какую-то ерунду, которая неизбежно будет отправлена в чате. Давай.
Спасибо за прочтение. Сообщите нам на сайте, если хотите.
