Контакты
Местоположение
Россия, Краснодарский край, Краснодар

Достижения

Все достижения (11)

Наибольший вклад в теги

Все теги (81)

Лучшие ответы пользователя

Все ответы (159)
  • Должен ли UX/UI дизайнер знать компоненты React/Vue?

    SeaInside
    @SeaInside
    10 лет пилю все эти штуки
    Смешались в кучу кони, люди...
    Давайте по порядку.

    Должен ли UX/UI дизайнер знать компоненты таких фреймворков как React и Vue

    Если команда разработчиков заранее знает, что будут использовать какой-нибудь набор готовых компонентов для работы (Vuetify, Material UI, etc), то дизайнер должен их знать и использовать как основу, дабы не плодить лишних сущностей, так как без боли эти компоненты можно разве что перекрашивать.

    подготавливать макет прямо на React, но без логики

    "Макет на React без логики" - это вёрстка.
    И боже упаси, чтобы это делал дизайнер - с этим и большинство фронтов так себе справляется (во многом потому, что через 3 месяца работы над пет-проектом говорят "я уже хорошо знаю HTML и CSS, пошёл учить Реакт и получать ЗП в 200+", ха-ха).

    не зная можно ли вообще реализовать такой календарь

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

    но наверное какие-то основы, работу с NPM, CSS/SASS препроцессоры он должен знать?

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

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

    Вообще такое ощущение, что все вокруг просто на самом деле ничего толково делать не умеют, но пытаются себе цену добавить мнимым знанием кучи всего. Сфокусируйтесь на одном чём-нибудь.
    Человеку, который делает гениальный дизайн, прощают всё - сложный характер, срывы сроков, никакую структуру файлов, Layer1-layer2 - и возвращаются к нему снова, потому что это профессионал в своём деле, и нет совершенно никакой нужды добавлять себе стоимость второстепенными навыками. Разве что самому интересно..
    Ответ написан
  • Сборка html из фрагментов?

    SeaInside
    @SeaInside
    10 лет пилю все эти штуки
    Компонентный подход - это всегда правильно.
    Сейчас в трендах работа с JS-компонентами, но практически тоже самое можно и на бэке делать, просто это менее удобно и готовых решений (и хороших практик) меньше.

    Вам нужен шаблонизатор. Если пишите на PHP - возьмите Blade, он простой как три копейки, есть в отрыве от Laravel, и хоть и несколько кастрирован в части работы с данными, но свои задачи как шаблонизатор выполняет более чем.
    Альтернативой может послужить Twig, но мне его синтаксис по сравнению с Blade нравится куда меньше, а регулярные задачи плюс-минус и там и там решаются.

    Чего-то готового найти довольно сложно, поэтому организовать воркфлоу, структуру придётся самостоятельно.
    Я, когда занимался, сделал себе вот так и использовать было не особо больно:
    5e89e66f399e0313757656.jpeg

    Те же компоненты, те же "пропсы" - это, пожалуй, в рамках шаблонизирования на PHP максимально приближенный вариант к модным фронтовым штукам.
    Из минусов по сравнению с ними - нет автокомплита и быстрой навигации по дочерним компонентам (всё приходится искать прям в файловой структуре, без Alt+LKM), нужно самостоятельно организовывать вопросы документирования компонентов.
    На скриншоте компонент входит в один экран и принимает три параметра, в таких случаях допустимо не документировать, но есть и другие, где параметров целая гора, там самостоятельно нужно думать о том, как организовать документацию, чтобы не запутаться.
    Для JS-фреймворков если классные инструменты для этого, Storybook мне например нравится очень.

    Если лень заморачиваться, всегда можно тем же пыхом сделать что-то в духе:
    function component($name, $params) {
      extract ($params);
      include 'path/to/components/' . $name;
    }
    
    component('component-name', [
      'param' => '123',
    ]);

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

    Ну а если вам и вашим клиентам стек не важен, не возникает проблем с SSR - то берите любой модный JS-фреймворк и пишите на нём, там всё до вас придумано и довольно удобно.
    Ответ написан
  • Какие модные фронтенд-фишки можете посоветовать?

    SeaInside
    @SeaInside
    10 лет пилю все эти штуки
    Лучшее, что вы можете сделать - не тащить на сайт кучу всякой херни, которая обычно много весит, ухудшает перфоманс, затрудняет восприятие контента и не нужна никому, кроме вас. Серьёзно.
    Любая анимация должна быть уместна, и если вам, глядя на дизайн, никаких конкретных идей в голову не приходит - то и не нужно. Нет способа удешевить сайт сильнее, чем добавить элементам разного толка выпрыгивания со всех сторон, глитч-эффекты и всё такое.
    Хочется динамики - найдите какое-нибудь не сильно быстрое видео и поставьте его как фон, или по запросу "canvas background animation" найдите ненапрягающую анимацию.

    P.S. Речь идёт не о сайтах, которые должны побеждать на Awwwards, а об обычных сайтах, которые делаются для людей, а не для конкурсов.
    P.P.S. Если всё-таки очень хочется, то нужно гуглить по запросам "hover effects" и "canvas animation", остальное без конкретной дизайнерской задумки вреда несёт куда больше, чем пользы.
    Юзабилити - это про то, чтобы "работает быстро и понятно (как у всех)".
    Ответ написан
  • Развитие во вебе?

    SeaInside
    @SeaInside
    10 лет пилю все эти штуки
    Фронтендер, не умеющий верстать - это оксюморон.

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

    Насколько вёрстка важна?
    Максимально, ибо работает ваша отрисовка 0.1с или 0.2с, используете ли вы fetch, или axios, или даже XMLHttpRequest - это пользователю неинтересно (в очередной раз напоминаю, что сайты и приложения мы делаем для пользователей), бизнесу обычно тоже не особо интересно, а вот если вёрстка расползается, что-то где-то едет, становится недоступным, или простая страница верстается 30 часов, а потом ещё 20 тестируется и правится, а в итоге всё равно какое-то говно - это уже замечают все причастные.

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

    HTML, CSS, JS - навыки, которые растут параллельно, если всё идёт правильно.
    Не в одинаковой пропорции, но одно без другого смысла не имеет.

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

Лучшие вопросы пользователя

Все вопросы (1)