Как получить хорошую верстку от верстальщика



    Вводная часть


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

    Прочитав обе статьи, вы сможете составить адекватное собственное мнение на заданную тему.

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

    Backend


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

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

    Работа до верстки


    Да, я знаю, что идеальный дизайнер разбирается во всех тонкостях верстки, что и как нужно делать в макете, чтобы верстальщик остался доволен. Но такие люди попадались мне очень редко. Здесь описывается работа с “обычным” дизайнером.

    Работа с макетом


    1. Стоит попросить дизайнера прочитать краткую инструкцию на сайте ilovepsd.ru. Особенно разделы касательно группировки слоев, нэйминга слоев, способа указания размеров и применения эффектов к объектам.
    2. Хорошо зарекомендовал себя прием, когда все размеры объектов ( без фанатизма) кратны двум.
    3. Стоит заранее определить размеры рабочей области сайта вместе с дизайнером и четко их обозначить. Иначе вы рассчитывали на одно, получили третье.
    4. Заранее предусмотрите в макете, какие элементы будут у вас на сайте, например, какие списки, таблицы или цитаты. Иначе после верстки вы будете просить верстальщика “Ну сделай таблицу посимпатичнее на свой вкус”.
    5. Для активных элементов в макете должно быть предусмотрено состояние активное и не активное.

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


    Работа со шрифтами


    1. Всегда забирайте шрифты вместе с макетом.
    2. Не каждый шрифт можно легко использовать в WEB. Никто лучше самого верстальщика вам в этом не поможет разобраться. Заранее уточните у него этот момент.

    Последнее время мы все чаще просим дизайнеров использовать бесплатные шрифты из набора Google Fonts.

    3. Если какой-то элемент на странице должен быть представлен, как текст, а не картинка, старайтесь избегать отображать этот текст сферически, волнами и так далее. Только в случае самой крайней необходимости.

    Консультация


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

    Работа во время верстки



    Версии браузеров


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


    Если вы без понятия для чего это нужно, то попросите поддерживать Chrome, Firefox, Opera, Explorer от 8 версии.


    Чем проверять верстку


    1. Лучшая проверка — это ваш браузеры. Открывайте макет во всех этих браузерах и смотрите.
    2. Стоит открыть макет на мониторах разного размера. Удобное приложение для Chrome если у вас нет 10 разных мониторов Resolution Test


    W3C Validator


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

    Валидатор здесь — http://validator.w3.org

    JavaScript


    Любое применение JavaScript должно быть обоснованно и там, где это использование можно заменить на HTML+CSS — стоит заменять. Особенно важно это для отображения контента. На данный, момент наши эксперименты показывают, что поисковики не всегда и не везде могут внятно и адекватно проиндексировать контент, генерируемый с помощью JavaScript. Каждое такое применение должно быть обоснованно и у него должна быть причина.

    Пиксель в пиксель


    Ошибаются все. Где-то может измениться отступ, где-то размер. Чтобы легко выявить не состыковки я использую приложение PerfectPixel. Оно позволяет поверх открытой страницы наложить изображение макета, отрегулировав прозрачность. Все неточности будут сразу видны.


    Мобильные платформы


    Верстка и сайты для мобильных — это тема отдельного материала, но все же, постарайтесь сделать так, чтобы на мобильных было удобно посмотреть хотя бы основную информацию о вас — контакты, телефон, время работы.
    • –10
    • 22.8k
    • 16
    Share post

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 16

      +1
      CSS-код в иллюстрации поста — это «как получить плохую вёрстку».
      nav li — путь к проблемному каскаду, а от каскада надо стараться уходить.
        0
        Это просто картинка. Если покажите скриншот с хорошей версткой, с удовольствием заменю.
          0
          delete
            0
            Ну тут можно еще придраться к порядку написания свойств ) Это же всего лишь картинка для привлечения внимания.
            +16
            Мда, начиная с «W3C Validator», каждый следующий совет всё хуже и хуже. Учтите, что эту статью скорее всего будут читать люди не разбирающиеся в вёрстке — вы ведь именно для них писали советы?

            W3C Validator
            Если вы не знаете, что это такое — не трогайте. Проверяйте вёрстку в браузерах. Всё выглядит хорошо — значит всё хорошо.

            Любой более-менее средний сайт содержит в стилях кучу префиксов + тянет за собой стили для сторонних компонентов. Как минимум, много предупреждений в валидаторе вам обеспечено. И зачем предъявлять это верстальщику?

            JavaScript
            В целом верно, но опять же смущает совет требовать обоснования применения JS. Если вы сами не способны понять обосновано или нет применение JS в конкретном случае, то какой смысл спрашивать об этом исполнителя? Разве что для самообразования :)

            Пиксель в пиксель
            Ошибаются все. И больше всего ошибаются те, кто считает, что вёрстка «пиксель в пиксель» возможна.

            С учётом того, что большинство макетов рисуются «обычными» дизайнерами, хорошая вёрстка — это не тогда когда результат выглядит «точно как в макете», а когда результат выглядит максимально хорошо:
            — вне зависимости от браузера
            — при разном количестве контента
              +1
              Согласен с вами полностью. В статье описаны скорее вредные советы, чем полезные.

              Вот в довесок мои советы:

              стоит познакомить дизайнера с понятием «сетка» (PDF на тему — www.subtraction.com/pics/0703/grids_are_good.pdf)
              стоит познакомить дизайнера с понятием «вертикальный ритм» (туториал на тему — webdesign.tutsplus.com/articles/improving-layout-with-vertical-rhythm--webdesign-14070)
              стоит рассказать дизайнеру какие элементы на странице трудно (невозможно) стилизовать (формы, скроллы, алерты)
              как показывает практика далеко не все дизайнеры знакомы с понятием «адаптивная верстка» и особенностями дизайна адаптивных макетов
                0
                Согласен, что советы неахти. А точнее некоторые из них даже вредны.

                W3C Validator
                Лично мое мнение и опыт показывают, что даже верстальщику среднего уровня по силам сделать верстку которая 100% валидна. И этого нужно добиваться. А вот когда верстку натянут на код — там уже могут появиться невалидные места и вот тут уже нужно начинать прикрывать глаза (например & в ссылках).

                «Обоснованный» JavaScript & Пиксель в пиксель
                Часто по своей работе вижу такие требования. И пишут их в основном после прочтения таких топиков.
                Но задайте себе вопрос: как вы сможете отличить обоснованный JS от необоснованного? Вы будете разговаривать с верстальщиком о вещах в которых он компетентен, а Вы — нет. Он вам докажет что угодно, даже не сомневайтесь.

                PixelPerfect — утопия. Можно убить половину времени проекта на это, но зачем? Вам шашечки или ехать? Прагматики выбирают Progressive Enhancement, а с идеалистами и фанатиками я никому не пожелаю работать.
                +15
                Эх, ну сколько можно говорить о валидаторе, только тратите время и заказчика и верстальщика.

                JavaScript, ну вот скажите, как заказчик отличит анимацию сделанную на js от анимации сделанной на css? Он даже не будет знать куда смотреть.

                Пиксель в пиксель, тоже требование сомнительное. Как показывает практика дизайнеры сами все время забывают свои же гайдлайны и у них в макетах скачут отступы, размеры шрифта и т.п. Хороший верстальщик подправит такие огрехи незаметно, но при проверке пиксель в пиксель на него еще и наедут! Или скажем сравнить макет сделанный под виндой с сайтом на маке? Там разная толщина шрифтов, пиксель в пиксель вообще невозможен.
                  +2
                  К сожалению, не моуг поставить плюс, но выразить свое согласие очень хочется. Pixel-perfect действительно невозможен из-за различных типов сглаживаний шрифтов, из-за того что дизайнер часто по своей же сетке направляющих не рисует пиксель-в-пиксель и т.п. Из-за советов «проверяйте через картинку с прозрачностью» и появляется всякое «подвиньте мне логотип на 1 пиксель влево, а менюшку на 2 пикселя вниз», будто это сильно что-то меняет. Я при верстке зачастую немного отхожу от макета именно по причине исправления неточностей за дизайнерами, пиксель перфект в таких ситуациях означает лажу.
                    0
                    JavaScript, ну вот скажите, как заказчик отличит анимацию сделанную на js от анимации сделанной на css? Он даже не будет знать куда смотреть.


                    Тут не согласен. У меня уже очень давно установлен NoScript и за много лет сформирован белый список сайтов. И так раздражает, когда даже в самые простые вещи, пытаются запихнуть JS.
                      0
                      Зачем вообще нужен NoScript (это плагин, я правильно понимаю?) если скрипт можно отключить в настройках браузера? Для чего вы отключаете JS?
                    +9
                    Клиент который хочет pixel perfect априори никогда не получит хорошую вёрстку.
                      0
                      главное без фанатизма, но сравнивать полезно. Пиксель ту пиксел — это перебор, тут без споров.
                        +1
                        Иногда можно, если дизайнер более-менее понимает верстку. Такие мамонты существуют.
                        +3
                        Если вы без понятия для чего это нужно, то попросите поддерживать Chrome, Firefox, Opera, Explorer от 8 версии.

                        Я бы отметил, что поддерживать необходимо современные версии браузеров, опираясь на данные вашей аналитики (GA и Я.Метрика в помощь). Так, например, на портале для геймеров поддержка IE8 будет не обоснована. А вот для корпоративных сайтов банковского сектора и вообще финансового сектора — здесь без IE8 и даже частичный поддержки IE7 не обойтись. Более того, нужно избегать флэша и очень аккуратно использовать JS. Это я вам говорю как человек, который работал в разных финансовых организациях. Сейчас я по своим проектам вижу долю IE8 в 50-55% и еще 1,5-2% IE7.
                          +1
                          Использовать наложение превью на макет для проверки пиксель в пиксель — это перебор, тут спору нет. Но делать это нужно в любом случае для проверки правильности расположения блоков, кнопок и прочих элементов. Текст может (и всегда будет) отличаться, а вот остальные элементы не должны. Исключение — если дизайнер сам их явно криво расположил (но за такие макеты вообще браться не рекомендую).

                          Only users with full accounts can post comments. Log in, please.