Чи є перевага зробити макет повного зображення над дайвінгом прямо в написанні HTML / CSS?

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

Часто веб-дизайнер був "лише візуальним" і відповідав лише за створення дуже детального макету в програмі для редагування зображень, таких як Photoshop або Fireworks. Макет (и) відображатимуть усі можливі аспекти веб-сторінки, від кольорів та вибору типу, до фонів, піктограм, фотографій та інших зображень, які будуть використовуватися. Але "дизайнер" ніколи не переймався власне побудовою та реалізацією в реальному часі. Вони були зосереджені виключно на зовнішності.

Після затвердження дизайну (шляхом перегляду цих файлів зображень) було розпочато другий етап - перехід файлів зображень у реальні HTML / CSS.

• У середовищі з одним місцем або позаштатним веб-дизайнером, можливо , використовували фрагменти та експортували в HTML за допомогою деяких внутрішніх варіантів застосування. У рідкісних випадках дизайнер може створити основні кадри HTML / CSS сторінок.

• У деяких корпоративних середовищах ці макети залишатимуться у вигляді шару шару зображень (.psd, .png [для феєрверків]) для веб-дизайнера, і дизайнер ніколи не буде хвилюватися щодо впровадження будь-якої розмітки чи коду. "Дизайнеру" ніколи не доводилося потурбуватися про те, як побудувати HTML або CSS, щоб реалізувати створений ними макет зображень. Файли зображень передаються / передаються "розробнику", який відповідає за створення HTML / CSS, який відповідає файлу зображення.

Я думаю, деякі з них все ще дуже працюють. Однак, завдяки вдосконаленню мов розмітки, а саме CSS3 та покращенню підтримки браузера - у багатьох випадках час, ретельно витрачений на ретельне створення растрового подання повної веб-сторінки, у багатьох випадках може бути марним.

За допомогою поточної надбавки дуже просто реалізувати багато потреб у веб-дизайні безпосередньо за допомогою HTML / CSS, а використання графічного додатка обмежується генеруванням невеликих активів зображення чи фотографій, які можуть знадобитися. (Бібліотеки та / або шаблони, такі як Bootstrap, надалі посилили це поняття.)

У своєму робочому процесі я помітно відійшов від макетів повних сторінок, якщо вони спеціально не вимагаються. Я роблю це для того, щоб поліпшити швидкість дизайну та забезпечити, щоб те, що затверджено, було близьким до того, що буде остаточно відображено в браузерах. Насправді я не створював макет повної сторінки протягом кількох років. Але я знаю, що все ще існують робочі процеси за допомогою цього методу.

Чи є реальна користь для створення макетів повних сторінок у програмі для редагування зображень перед зануренням прямо в HTML / CSS для побудови дизайну?

Перевага побудови макетів на повних сторінках - це розподіл праці.

У великих компаніях, які мають як дизайнера, так і (переднього) розробника, завданням дизайнера є проектування, а завдання розробника - написання коду .

Наявність цього підрозділу дозволяє дизайнеру витрачати весь свій час на роботу над зовнішнім виглядом, відчуттям та інтерфейсом для веб-сайту, і не потрібно нічого знати про те, як він створений. Вони можуть створювати дизайн більш високої якості і продумувати рішення довше саме тому, що вони не працюють над тим, щоб код одночасно робити те, що вони хочуть.

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

Якщо дизайнером є також розробник, я думаю, що більшість людей в більшій чи меншій мірі починають супроводжувати вас тим, що вони створюють більш грубий продукт і швидко ітератують, щоб перевірити речі. Це дозволяє швидко протестувати ідеї на відміну від створення ідеального піксельного документа фотошопа.

Однак груба, ітеративна конструкція без коду - це також дійсний і неймовірно корисний підхід, особливо для макетів та робочого процесу. Мови розмітки та нові технології не придумали швидко працювати з грубими ідеями :)

З цією відповіддю я піду на Гуффу. Щоб було зрозуміло, я не намагаюся виокремити Гуффу, а навпаки, пункти, що знаходяться під кутом, є дуже поширеними. Я також хотів би запропонувати кілька зустрічних пунктів. Я не кажу, що Гуффа помиляється, і я правий. Я просто пропоную контрапункт.

1. Творча частина процесу дизайну страждає, якщо витрачається час на те, щоб з'ясувати, як робити різні речі в HTML та CSS.

Це справедливо, якщо не вважати код однаково творчим. Photoshop та HTML / CSS / JS - обидва середовища для роботи художника. Так само, як фарба настільки креативна, як і деревне вугілля, так і Photoshop може бути таким креативним засобом, як HTML / CSS / JS.

І великою перевагою роботи безпосередньо в HTML / CSS / JS є багатовимірність цього. Нарешті, Photoshop - це плоске полотно. HTML / CSS / JS - це динамічне полотно з плинністю, взаємодією, анімацією тощо.

Підсумок, я можу стверджувати, що в цьому випадку код є більш креативним середовищем.

2. Коли дизайнери та кодери - це різні люди, навіть якщо дизайнери досить добре вміють HTML та CSS, вони рідко справді добре кодують. Результатом було б (в різній мірі) неефективний код, який роздутий і важкий для обслуговування.

На жаль, протилежне до цього, на жаль, є те, що я стикаюся все часто: Більшість розробників, які працюють у виділених ролях, працюють у більшій організації (де виділені ролі більше є нормою) і через відсутність знань міждисципліни ( і часто повна відсутність коду шару презентації) роблять деякі з найбільш роздутих важкими для підтримки фронтального коду, який я коли-небудь бачив.

По суті, я не вважав би свої візуальні можливості дизайну будь-якими ознаками їх здатностей до кодування. Я б пішов на крок далі і стверджую, що талановитий загальний професіонал, який знає дизайн та кодування - навіть якщо вони не найкращий дизайнер чи найкращий кодер, часто може створити кращий загальний продукт, ніж сильно відокремлена команда просто завдяки тому факту що вони можуть бачити більшу картину під час створення. Значно менше втрачається при перекладі.

3. Якщо ви почнете писати код, перш ніж мати чітке уявлення про те, як повинен виглядати дизайн, ви робите неінформований вибір про те, як побудувати код. Ризик полягає в тому, що він погіршить код і обмежить можливості для дизайну.

Але розробка коду не означає, що це ваш виробничий код. Я працював над проектами, де більша частина створеного нами коду була виключно для повністю розробленого дизайну, а потім робила деякі прототипування. Після закінчення ми потім зробимо чисте перезапис. Це дало додаткову користь тому, що ми змогли знайти багато «ґетчей» у першому раунді кодування.

4. HTML та CSS-код можуть сильно змінитись із невеликими змінами в дизайні, що зробить процес проектування більш статичним. Ви ризикуєте обмежитися лише змінами, які легко внести в код.

Протилежним аргументом цього дизайнера є обмеження лише лише тих змін, які легко зробити в Photoshop. Це не дуже хороший аргумент.

Єдина причина, щоб не робити макет Photoshop спочатку, якщо дизайнер не розуміє обмежень коду. Ви ніколи не хочете дарувати клієнтові щось, чого він / він не може мати у фіналі.

Поки PSD являє собою те, що може бути досить тісно відтворено в CSS / HTML (з урахуванням обмежень для перехресного браузера та крос-медіа), я б це зробив у Photoshop (або InDesign - я знаю декількох дизайнерів, які це дотримуються). Ефективніше і набагато простіше маніпулювати зображеннями. Знову в CSS мені було б кодування до того, як я кодую, якщо це має сенс.

Існує кілька причин для того, щоб зберігати елемент дизайну окремо від елемента генерації коду, наприклад:

• Творча частина процесу дизайну страждає, якщо витрачається час на те, щоб з'ясувати, як робити різні речі в HTML та CSS.

• Коли дизайнери та кодери - це різні люди, навіть якщо дизайнери досить добре вміють HTML та CSS, вони рідко справді добре кодують. Результатом було б (в різній мірі) неефективний код, який роздутий і важкий для обслуговування.

• Якщо ви почнете писати код, перш ніж мати чітке уявлення про те, як повинен виглядати дизайн, ви робите неінформований вибір про те, як побудувати код. Ризик полягає в тому, що він погіршить код і обмежить можливості для дизайну.

• HTML та CSS-код можуть сильно змінитись із невеликими змінами в дизайні, що зробить процес проектування більш статичним. Ви ризикуєте обмежитися лише змінами, які легко внести в код.