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

Достижения

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

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

Все теги (69)

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

Все ответы (216)
  • Надо ли все детали дизайна сайта заключать в автолэйауты?

    SeaInside
    @SeaInside
    15 лет пилю все эти штуки
    В идеале - да, по факту - оно того чаще всего не стоит, ниже объясню почему.
    * Вообще, если у вас такой вопрос возникает, то вам оно, скорее всего, не нужно.

    Основных целей две:
    1. Автоматическое перестраивание макета в случае использования компонентов
      Вот есть у вас традиционная, любимая дизайнерская сущность "карточка".
      Она вынесена в компонент и используется на N страницах примерно N * 50 раз.
      Приходит клиент и говорит: хочу в карточку добавить внизу большую красную кнопку.
      Вы добавляете кнопку в компонент.
      Если и сам компонент, и все родители, где он используется, сделаны с помощью автолейаутов - на этом ваша работа заканчивается, все страницы выглядят как надо.

      Если автолейаутов нет, добро пожаловать либо в "руками передвинуть все экземпляры на всех страницах" (что нудно, скучно, а если клиент завтра передумает, то вообще лол), либо в "ну я вот тут на странице "Карточка v2" показал, как должно быть", что спустя какое-то время ведёт к бардаку на проекте, в котором невозможно найти концов.
    2. Больше уверенности в том, что всё стоит ровненько
      Что выливается в то, что верстальщику над макетом работать приятнее - он видит автолейаут и он сразу уверен, что отступ между всеми элементами одинаковый.
      Скорее всего, получится сделать `pixel-perfect`, если заказчику это будет важно. А без автолейаутов у вас может быть ситуация, когда между одинаковыми элементами разный отступ.
      * Необязательно будет - можно быть внимательным, но дополнительная уверенность - это хорошо для всех. Технология страхует от ошибок.

    Теперь о том, почему не стоит.
    • Для того, чтобы автолейауты помогали процессу, а не мешали - у вас ещё до начала работы должно быть полное представление о том, что вы хотите в итоге получить.
      Если вы находитесь в процессе творческого поиска - рисуйте как рисуется. Как только кажется, что всё выглядит хорошо - подумайте над лейаутами.
    • Когда нужно задизайнить сложный, составной компонент с разными вариантами - его реально нужно проектировать, по субъективным ощущениям это гораздо ближе к вёрстке, чем к дизайну - а это вообще другая профессия, и думать там надо по-другому.
      У меня, когда доводится рисовать, компоненты структурно получаются практически такие же, как они и на вёрстке потом будут - и это замечательно в долгосрочной перспективе - бардака меньше.
      Но я - в первую очередь технический специалист, а дизайнер не думает (и не должен думать) как верстальщик, и сделает немного не то и немного не так. Со стороны будет выглядеть чаще всего как "создал себе проблем на ровном месте".
      Кроме того, у этого есть минусы: компонент становится сложнее (порой - прям ощутимо), чем если просто внутри фрейма мышкой расставлять элементы. Это влияет на то, насколько легко другому человеку разобраться, что происходит и внести свои изменения.
    • В фигме нет (пока нет) абсолютного позиционирования. Пока в ходу хак с фреймом ширины/высоты 0/0 - но это именно что хак, это увеличивает сложность и разработки, и поддержки. Сложные компоненты без этого не заворачиваются в автолейауты никак.
    • Не очень опытных дизайнеров автолейауты серьёзно ограничивают в творчестве - дизайн получается... Ну, квадратный, что ли.
    • Не все вещи возможно реализовать на автолейаутах


    Во всём нужна мера. Должно быть удобно, быстро, надёжно и понятно команде.
    А где эта мера - ну каждый ведь для себя решит, верно? :)
    Ответ написан
    3 комментария
  • Должен ли UX/UI дизайнер знать компоненты React/Vue?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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