Работа над крупным интернет-магазином

Хочу рассказать вам про работу и про проекты, но для этого нужно вернуться немного назад. Есть у вас машина времени?)

В июле мне написал один человек и предложил в работу проект. Я его выполнила в кратчайшие сроки (так как они горели) и за достаточно небольшой бюджет. Правок почти не было и, наверное, заказчика устроило качество выполненный работы, так как через пару дней он вернулся ко мне с ещё одним проектом. Как оказалось, это не совсем заказчик, а скорее посредник, но это не так важно, главное, что есть работа 😄 после второго проекта мне нужно было уехать на пару недель

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

Изначально нужно было исправииь три страницы: главная, каталог, страница товара и сдать их бекендерам (бек на Битриксе). Но исправить — это мягко сказано, мне пришлось полностью все переделывать (и не зря, как оказалось позже). Однако некоторые решения в коде были достаточно интересными и я переписала их на свой лад, ещё мне понравилась сборка — gulp + webpack, это подтолкнуло меня обновить свою текущую сборку

Макет не был полностью готов. Отсутствовали меню, выпадашки, модалки. Сам дизайн не подготовлен к вёрстке: дробные значения в размерах элементах и шрифтах, куча разных отступов и стилей. К дизайнеру накопился ряд вопросов, а он через пару дней просто перестал выходить на связь 🤦‍♀️

Когда главная страница была переделана, то мы стали показывать её заказчику. Тот сказал, что все слишком огромное и надо уменьшить раза в 2-3 все элементы. А я вот стесняюсь спросить, где же он был, когда принимал дизайн? Как он принял контенйер в 1700px и обычный шрифт в 24px?

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

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

#работа #верстка

Навигация

#инкубатор
#работа
#верстка
#дизайн
#теория
#книги

Темы:

#паттерны
#иммутабельность
#инструменты
#доступность
#цвет
#принципы
#архитектура
#fsd
#лексическоеОкружение
#замыкание
#this
#промисы
#оптимизация
#карты
#redux
#ts

Работа над крупным интернет-магазином продолжается

Через несколько дней к нам в команду добавили нового дизайнера, то есть дизайнершу. И она стала работать над остальными страницами, которых было ещё около 10-12

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

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

Теперь работа прилетала с их стороны. В основном требовалось внести изменения под битрикс. Где-то добавить новый скрипт, где-то обработать отправку формы и тому подобное

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

--------------

Теперь хочу рассказать о некоторых сложностях, с которыми столкнулась на этапе вёрстки

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

Сами линии делала через svg тег, но это было не совсем корректным решением. Так как для каждого плюсика пришлось рисовать отдельную линию, подгонять её пиксель в пиксель (не забываем, что я уменьшала контейнер на 400px и все элементы соответственно) и копировать её svg код, а затем добавлять тоже в html

Сейчас я бы старалась это реализовать через canvas в javascript, но тогда я ещё не прочитала об этом в книге Javascript для детей))

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

#работа #верстка

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

Через недельку - две завершилась работа над дизайном оставшихся страниц (напомню, их 10-15, вот те, что я вспомнила: история, о компании, контакты, сервис, доставка, сборка, установка). Теперь настала моя очередь

Я решила верстать их на своей новой сборке (пост про неё) С одной стороны, это хороший выбор, если бы я продолжила работать с таким объемом страниц на старой сборке от другого верстальщика, то я бы с ума сошла. Все же моя сборка лучше приспособлена для больших сайтов.

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

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

1️⃣ «Аналог плюсиков». Естественно, я делала с учетом на то, что заказчик сможет менять количество и расположение этих кнопок, почти тоже самое, что и с плюсами (читайте в этом посте).

Дизайнер почему-то нарисовала все кнопки слишком огромными и разного размера. А ещё не будем забывать, что в верстке контейнер на 300px меньше. То есть мне нужно было разместить все таким образом, чтобы оно не наезжало друг на друга, смотрелось не слишком огромным и был соблюден масштаб

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

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

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

4️⃣ Бегущая строка. Тоже много времени потратила на писки решения. Зато найденное решение добавила в шаблон в сборке и теперь на подключение уйдет минут 5)

#работа #верстка

Сегодня хочу рассказать об очень важной концепции в js

В javascript все виды данных делятся на две большие категории: примитивный тип данных и ссылочный

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

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

Давайте создадим две переменные, которым присвоим одинаковое значение примитивного типа данных

const example = 5
const example2 = 5

Как вы думаете, переменная example и example2 равны? Правильный ответ: да! Вы можете проверить это самостоятельно

А теперь давайте проведем подобный эксперимент с ссылочным типом данных

const example = {}
const example2 = {}

А сейчас равны ли эти переменные? Правильный ответ: нет. Почему? Потому что переменная example это ссылка на объект в памяти.. example2 это тоже ссылка на объект в памяти, но уже на другой объект

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

Предлагаю провести ещё один эксперимент. Создадим переменную simple и присвоим ей примитив (к примеру 5), создадим ещё одну переменную — simple2 и присвоим ей simple. Simple и simple2 равны между собой и в этих переменных хранится 5. Давайте изменим значение переменной simple2 (к примеру на 10)

let simple = 5
let simple2 = simple
simple2 = 10

Чему равна переменная simple сейчас? Правильный ответ: 5

А теперь сделаем тоже самое, но с ссылочным типом данных. Переменной obj присвоим пустой объект, а переменной obj2 присвоим obj

let obj = {}
let obj2 = obj

Теперь давайте объекту, на который ссылается obj2 добавим свойство

obj2.name = "Anna"

Как вы думаете, что сейчас находится в переменой obj? Правильный ответ: {name: "Anna"}

Почему так произошло? Потому что obj это ссылка, которая ссылается на объект в памяти (ключ для шкафчика). Переменой obj2 мы присваиваем эту же ссылку (точно такой же ключ). И получается, что через две эти переменные мы обращаемся к одному и тому же объекту (это одинаковые ключи от одного шкафчика)

#теория #иммутабельность

Четыре принципа веб-доступности (POUR)

В этом посте я рассказывала о том, что активно начала интересоваться темой доступности

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

Ладно, не будем о грустном. Давайте лучше расскажу об этих принципах

POUR — аббревиатура от четырёх принципов, на которые опирается веб-доступность. Они описывают, какими должны быть веб-интерфейсы, их отдельные элементы и контент

1️⃣ Воспринимаемость (perceivable) — интерфейс можно воспринимать разными органами чувств, например глазами и ушами. То есть если на сайте есть какой-то аудио файл, то было бы замечательно добавить к нему текстовое описание. Если у пользователя будет отит, то он сможет усвоить информацию через зрение, а не напрягать свое пострадавшее ухо

2️⃣ Управляемость (operable) — с интерфейсом можно взаимодействовать разными способами, например, с помощью мышки и клавиатуры. У пользователя может сломаться мышка, и у него должна быть возможность заказать новую мышку с помоom. клавиатуры (телефон он потерял). Поэтому прорабатывайте состояние фокуса для кликабельных элементов или хотя бы не отключайте outline 😠

3️⃣ Понятность (understandable) — интерфейс понятен для взаимодействия, пользователю должно быть интуитивно понятно, как совершить то или иное действие на сайте (как оставить заявку, как добавить товар в корзину и т.п). Тоже самое можно сказать и о контенте. Не надо писать слишком сложный и запутанный текст, использовать профессиональные термины. Пользователю должно быть все максимально понятно

4️⃣ Устойчивость (robust) — интерфейс соответствует техническим спецификациям и работает на разных устройствах, в разных браузерах и с разными вспомогательными технологиями

#теория #доступность

Пожалуй, это последний пост по теме верстки крупого интернет-магазина

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

Но проект мы ещё не сдали. Нам предстояла работа над меню и, наверное, это была одна из самых сложных частей при создание данного сайта. Изначально заказчик хотел три совершенно разных выпадающих меню: одно для каталога, а два других — подменю для пунктов основного меню (и это не обычная выпадашка, а полноценное меню на всю ширину сайта, внутри которого табы!). Повторюсь, он хотел, чтобы они были абсолютно разные! Кроме того, дизайнер сделала так, что на десктопе — одно выпадающее меню, а на планшете и смартфоне — другое! То есть адаптировать их никак нельзя, только верстать отдельное меню под мобильную версию. И получается, что всего должно быть 6 разных меню…

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

Дальше заказчик захотел немного переделать первый экран и добавить туда слайдер, а каждый слайд должен быть уникальным. Обычно слайды одинаковые по структуре, например, справа текст, а слева картинка. Меняется слайд — меняется текст и картинка, но структура остается. А тут нет, такая легкотня его не устраивала… Кроме того, клиент моментально принял дизайн, но раз пять приходилось переделывать верстку: менять размер всех элеметов и отступы между ними

Ещё добавляли несколько модальных окон и валидацию форм. Это не так сложно, но если бы заказчик об этом сказал заранее, а не в конце работы, то мне было бы проще

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

#работа #верстка

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

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

2️⃣ Рассказать заказчику, как правильно утверждать дизайн. Чтобы он смотрел на макет в 100% масштабе!!! Постараться донести ему, что вносить изменения в фигме проще и быстрее, чем в верстке. Если макет уже будет сверстан, а ему придется в голову шикарная идея — поменять дизайн, то это будут дополнительные работы, за которые придется дополнительно платить. Так как с дизайном работают на этапе дизайна, а не на этапе верстки

3️⃣ Мне, как верстальщику, нужно внимательнее смотреть макет, анализировать его. Заранее подмечать те блоки, которые переиспользуются и те блоки, что могут переиспольоваться. Уже на этом этапе продумывать, что и как лучше сделать

4️⃣ Не бояться задавать вопросы. Лучше обсудить все берегу, чем отправиться в плавание и понять, что ты плывешь куда-то не туда. Не бояться общаться с коллегами: верстальщиками, дизайнерами, бекенд разработчиками. Всегда думать о следующем этапе в создание сайта, подумать, как тебе лучше сделать этот блок, чтобы следующим ребятам было с ним работать, и опять же, не бояться обсуждать такие моменты с коллегами. Лучше задолбать их вопросами, чем задолбать их своим кривым кодом)

#работа

Вспомогательные технологии

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

Вспомогательные технологии (assistive technology) — это программы, которые упрощают взаимодействие пользователя с контентом. К примеру, выносные кнопки, трекболы, брайлевские дисплеи, экранные лупы и скринридеры

Скринридер (screen reader) — программа, которая превращает контент в речь. Они нужны людям с плохим зрением, а также пользователям с когнитивными особенностями, которым легче воспринимать информацию на слух

Ещё одна вспомогательная технология — экранная лупа (screen magnification). Частенько слабовидящие пользователи используют её вместе со скринридерами. Она увеличивает контент на экране и тоже его озвучивает, если это нужно

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

#доступность #теория

Как работают скринридеры

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

В этом посте хочу разобрать принцип работы этих программ

Скринридеры не берут контент из вкладки браузера. Существует Accessibility API — это посредник, который берет информацию из браузера и передает её скринридерам, не не просто передает, а делает это в виде дерева доступности

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

Пару слов о дереве доступности. Оно очень похоже на DOM, но состоит из доступных объектов и не включает в себя скрытые элементы (с display: none или visibility: hidden)

Доступной объект дерева доступности состоит из следующих свойств:

✅ role. Соответствует типу элемента, например, button или link

✅ name. Помогает лучше понять, что это за объект. Имя — это текст между открывающимся и закрывающимся html тегом, поэтому оно есть не всегда

✅ description. Дополнение к имени. Озвучивается, если выбрана такая настройка в скринридере.

Источник

#доступность #теория

Куки

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

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

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

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

#теория

Приветствую!

Давненько не было постов… Почему так и что будет дальше - расскажу как-нибудь потом. А сейчас хочу ответить на вопрос, который мне недавно задали в реальной жизни: “Как войти в айти?”

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

Как выбрать направление? Правильно, погуглить! А если серьёзно, то могу посоветовать к просмотру вот это видео - https://youtu.be/WMxztZHDq18?si=gXURGPKCPsv6o14i , ну и никто не мешает поискать ещё какие-то видео и статьи на эту тему

Окей, вот вы смотрите или читаете про какое-то направление в айти и думаете: “хм, а вот это мне было бы интересно”. Супер! Тогда находите интервью какого-то специалиста из этой сферы и смотрите его. Вам интересно о чем говорит человек, хотелось бы в этом разбираться? Если да, то начинаете искать материалы по этой теме, это могут быть мастер-классы, бесплатные курсы, уроки для начинающих и прочее

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

Если на каком-то этапе вы потеряли интерес, то вернитесь на первый этап и попробуйте другое направление

После того, как вы четко определились с направлением, попробовали самостоятельно бесплатное обучение, можно при желание и возможности задуматься и о платном. Выбор курса - дело серьезное. Образование - это бизнес, а заработать хотят все. Так что не стоит идти на первый попавшийся курс. Поспрашивайте мнения у людей в сообществе, почитайте отзывы, посмотрите на подачу преподавателей. Посмотрите на программу, стоимость, длительность и другие условия. И после сравнения и анализа можно принимать ответственное и осознанное решение. Главное, не бросать и двигаться вперед и тогда вы войдете в айти и не выйдите:))

🖐 Всем привет! Сегодня хочу порассуждать о различных библиотеках, которые упрощают верстку при создании приложений

Раньше я была категорически против них, топила только за чистую верстку. Мне казалось, что разные либы типо бутстрапа просто портят код и уважающий себя верстальщик должен писать все самостоятельно. Я не понимала frontend разработчиков, которые говорят, что не любят верстать. Как можно это не любить? Это же такой кайф, так интересно! — думала я 😀

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

Во-первых, на верстку уходило много времени (этому я не удивилась, потому что действительно, хорошая верстка не делается быстро) и она стала менять (как бы это ужасно не звучало для прежней меня) отвлекать… То есть ты пишешь логику, реализуешь какой-то flow, думаешь куда и зачем девать данные — тебя захватывает этот процесс, а потом смотришь — и вообще не вырисовывается никакая верстка

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

В-третьих, я понимаю, что бизнес платит деньги айтишникам за то, что они оптимизируют процессы и помогают предпринимателям зарабатывать больше. Какому-нибудь миллионеру плевать, сделана его платформа на SCSS или там используется Material UI. Если мы говорим про UI, то да, клиенту важно, чтобы это было удобно, красиво и не тормозило. Но как это сделано — пофиг! Бизнесу лучше, если ты потратишь час не на нативную верстку (если у него визуал не падает), а на решение более важных задач

Я сталкивалась с Material UI, Ant Design, и Radix UI. Вот последнее мне больше всего понравилось. Потому что в подобных рода библиотеках ты можешь очень многое редактировать и гибко настраивать. Ты имеешь полное право не для всего её использовать, ты можешь писать свои стили на свой вкус, там нет безумого количества лишних оберток и все хорошо с доступностью. Но ты экономишь время на том, что тебе не надо делать объемных и при этом шаблонных задач (типо модалок, радиокнопок, слайдеров и т.д.)

А Material и Ant сложнее настраивать под проект, некоторые стили не перезатираются и приходится писать вложенности, они создают много лишних оберток. И лично у меня создается ощущение, что раз уж ты используешь такую либу, то надо полностью создавай UI их средствами. А вот радикс — идеальный баланс между чистой версткой и готовыми решениями (на самостоятельное написание которых у тебя ушла бы куча времени)

А что вы думаете?