В прошлом у многих компаний и веб-дизайнеров рабочий процесс состоял как минимум из двух-трех частей: дизайн, разметка, серверная часть. Это обобщает, и линии могут немного размыться... но я уверен, что вы поняли мою суть.
Часто веб-дизайнер был «только визуальным» и отвечал только за создание очень подробного макета в программном обеспечении для редактирования изображений, таком как Photoshop или Fireworks. Макет(ы) будет отображать все возможные аспекты веб-страницы, от выбора цвета и шрифта до фона, значков, фотографий и других изображений, которые будут использоваться. Но «дизайнер» никогда не занимался реальной живой конструкцией и реализацией. Они были сосредоточены исключительно на внешнем виде.
После того, как дизайн был одобрен (путем просмотра этих файлов изображений), был предпринят второй этап - перевод файла(ов) изображения на живой HTML/CSS.
В одноместной или внештатной среде веб-дизайнер мог использовать фрагменты и экспортировать в HTML с помощью некоторых внутренних параметров приложения. В редких случаях дизайнер может создавать базовые фреймы страницы HTML/CSS.
В некоторых корпоративных средах эти макеты оставались в виде файла многослойного изображения (.psd, .png [для Fireworks]) для веб-дизайнера, и дизайнер никогда не беспокоился о внедрении какой -либо разметки или кода. «Дизайнеру» никогда не приходилось думать о том, как построить HTML или CSS, чтобы реализовать этот макет изображения, который они создали. Файлы изображений были переданы «разработчику», который затем отвечает за создание HTML/CSS, соответствующего файлу изображения.
Я предполагаю, что некоторые до сих пор очень много работают таким образом. Однако с развитием языков разметки, а именно CSS3, и улучшенной поддержкой браузеров время, потраченное на тщательное построение растрового представления полной веб-страницы, во многих случаях может быть в значительной степени бесполезным.
С текущей разметкой очень легко реализовать многие потребности веб-дизайна непосредственно через HTML/CSS, а использование графического приложения ограничено созданием небольших изображений или фотографий, которые могут понадобиться. (Библиотеки и/или шаблоны, такие как Bootstrap, еще больше продвинули это понятие.)
В моем собственном рабочем процессе я заметно отошел от полностраничных макетов, если они специально не запрошены. Я делаю это для того, чтобы повысить скорость проектирования и гарантировать, что то, что одобрено, близко к тому, что будет окончательно отображено в браузерах. На самом деле, я не создавал полностраничный макет уже несколько лет. Но я знаю, что все еще есть рабочие процессы, использующие этот метод.
Есть ли какая -то реальная польза от создания полностраничных макетов в приложении для редактирования изображений, прежде чем погрузиться прямо в HTML/CSS для построения дизайна?
Преимущество создания полностраничных макетов заключается в разделении труда.
В крупных компаниях, в которых есть и дизайнер, и разработчик (front end), работа дизайнера заключается в проектировании, а работа разработчика — в написании кода .
Наличие этого разделения позволяет дизайнеру тратить все свое время на работу над внешним видом, поведением и интерфейсом веб-сайта, и ему не нужно ничего знать о том, как он создается. Они могут создавать более качественный дизайн и дольше обдумывать решения именно потому, что они не работают над тем, чтобы код делал то, что они хотят, в то же время.
Это также позволяет разработчику писать больше кода, не задумываясь о том, как он будет выглядеть, включая мелкие детали и различные состояния. Они реализуют дизайн как можно лучше в отведенное время и могут перейти к другому проекту.
Если дизайнер является также и разработчиком, я думаю, что большинство людей более или менее начинают на вашей стороне в том, что они создают более грубый продукт и быстро итерируют, чтобы проверить вещи. Это позволяет быстро тестировать идеи, а не создавать документ в фотошопе с точностью до пикселя.
Тем не менее, грубый итеративный дизайн без кода также является допустимым и невероятно полезным подходом, особенно для макетов и рабочего процесса. Языки разметки и новые технологии не изобрели быструю работу с грубыми идеями :)
Я собираюсь придраться к Гуффе с этим ответом. Чтобы было ясно, я не пытаюсь выделить Guffa, скорее, маркированные пункты очень распространены, которые я слышу. Я также хотел бы предложить некоторые контраргументы. Я не говорю, что Гуффа не прав, а я прав. Я просто предлагаю контрапункт.
- Творческая часть процесса проектирования страдает, если время тратится на то, чтобы понять, как делать разные вещи в HTML и CSS.
Это верно, если кто-то не считает код в равной степени творческим. Photoshop и HTML/CSS/JS — это среды для работы художника. Так же, как краска столь же креативна, как и уголь, Photoshop может быть столь же креативной средой, как HTML/CSS/JS.
И большим преимуществом работы непосредственно в HTML/CSS/JS является его многомерность. Photoshop, в конце концов, представляет собой плоский холст. HTML/CSS/JS — это динамический холст с плавностью, взаимодействием, анимацией и т. д.
В итоге я бы сказал, что код в этом случае является более творческим средством.
- Когда дизайнеры и программисты — разные люди, даже если дизайнеры неплохо разбираются в HTML и CSS, они редко действительно хороши в программировании. Результатом будет (в разной степени) неэффективный код, раздутый и сложный в обслуживании.
К сожалению, контраргументом этому я часто сталкиваюсь: большинство разработчиков, работающих в выделенных ролях, работают в более крупной организации (где выделенные роли являются более нормой) и из-за отсутствия междисциплинарных знаний ( и часто полное отсутствие кода уровня представления) делают один из самых раздутых и сложных в обслуживании интерфейсных кодов, которые я когда-либо видел.
Суть в том, что я бы не стал рассматривать чьи-либо способности к визуальному дизайну как показатель их способностей к кодированию. Я бы пошел еще дальше и утверждал, что талантливый специалист широкого профиля, который разбирается в дизайне и кодировании, даже если он не лучший дизайнер или лучший кодер, часто может создать в целом продукт лучше, чем сильно обособленная команда, просто благодаря тому факту, что что они могут видеть более широкую картину, когда они создают. При переводе теряется гораздо меньше.
- Если вы начнете писать код до того, как у вас будет четкое представление о том, как должен выглядеть дизайн, вы сделаете неосведомленный выбор в отношении того, как построить код. Риск в том, что это ухудшит код и ограничит возможности дизайна.
Но проектирование в коде не означает, что это ваш производственный код. Я работал над проектами, где большая часть кода, который мы создавали, предназначалась исключительно для дизайна, а затем для прототипирования. После того, как мы закончим, мы сделаем чистую перезапись. Дополнительным преимуществом этого было то, что мы смогли найти много «подводных камней» в первом цикле кодирования.
- Код HTML и CSS может сильно измениться за счет небольших изменений в дизайне, что сделает процесс проектирования более статичным. Вы рискуете ограничиться только теми изменениями, которые легко внести в код.
Контраргументом этому является то, что дизайнер ограничивает себя только теми изменениями, которые легко сделать в Photoshop. В любом случае это не очень хороший аргумент.
Единственная причина не делать сначала макет в Photoshop, если дизайнер не понимает ограничений кода. Вы никогда не хотите давать клиенту что-то, чего он/она не может получить в финале.
Пока PSD представляет собой что-то, что можно довольно точно воспроизвести в CSS/HTML (учитывая кросс-браузерные и кросс-медийные ограничения), я бы сделал это в Photoshop (или InDesign — я знаю нескольких дизайнеров, которые компилируют это). Это быстрее и намного проще манипулировать изображениями. Моделирование в CSS для меня было бы кодированием до того, как я начал кодировать, если это имеет смысл.
Существует несколько причин для отделения элемента дизайна от элемента генерации кода, например:
Творческая часть процесса проектирования страдает, если время тратится на то, чтобы понять, как делать разные вещи в HTML и CSS.
Когда дизайнеры и программисты — разные люди, даже если дизайнеры неплохо разбираются в HTML и CSS, они редко действительно хороши в программировании. Результатом будет (в разной степени) неэффективный код, раздутый и сложный в обслуживании.
Если вы начнете писать код до того, как у вас будет четкое представление о том, как должен выглядеть дизайн, вы сделаете неосведомленный выбор в отношении того, как построить код. Риск в том, что это ухудшит код и ограничит возможности дизайна.
Код HTML и CSS может сильно измениться за счет небольших изменений в дизайне, что сделает процесс проектирования более статичным. Вы рискуете ограничиться только теми изменениями, которые легко внести в код.
Скотт
Энди Холмс