Який правильний спосіб роботи з графічним дизайнером? [зачинено]


41

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

Для здійснення цього виявилося неймовірно багато часу. Хоча в основному весь сайт був титульною, покажчиковою сторінкою та півдесятка сторінок з деталями, я витратив щонайменше 5 днів, просто впроваджуючи зміни CSS та HTML. Тож я вийду на кінцівку і назву це неправильним шляхом .

Мій основний підхід:

  1. Порівняйте статичне зображення та поточну візуалізацію та помітьте різницю.
  2. Здогадайтесь, які зміни будуть потрібні у CSS / HTML
  3. Внесіть ці зміни
  4. Перейдіть до першого кроку.

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

Який правильний шлях?


2
Мені здається, що тобі потрібен кращий дизайнер. Хтось, хто розуміє Інтернет.
boatcoder

Відповіді:


15

У моїй компанії є кілька людей, які спеціалізуються на цій роботі.

Вони дизайнери. І вони знають HTML. Вони можуть бути мостом між дизайнерами та інженерами; якими вони зазвичай є. Таким чином, нам просто потрібно інтегрувати їх HTML.

Це важка робота. Існує причина, що сайти типу "PSD в HTML за 24 години" працюють добре. Рішення в нашій компанії - мати людей, які спеціалізуються на цьому. Для нас робота з HTML - це вітер.

Срібної кулі немає.


Цікаво - mypsdtohtml.com . Поцікавтеся, що таке HTML - і чи можуть вони обробляти такі речі, як теги шаблонів Django.
Стів Беннетт

1
@SteveBennett у них портфоліо :) Чому ви хочете, щоб вони обробляли теги шаблону django? У них є PSD, вони дають вам HTML. Я не бачу, що б більше вони робили. Ви не очікуєте, що вони інтегрують ваш код, чи не так? ;)
Флоріан Маргаїн

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

1
@SteveBennett, я відчуваю, що розкласти повністю побудовані HTML-сторінки на динамічні шаблони і партії було б досить просто - це по суті простий рефактор коду. Для більшості конструкцій, я думаю, було б набагато простішою роботою з точки зору програміста, ніж створення html / css безпосередньо з psds.
Бен Лі

6

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

Гідним прикладом такого дизайну може бути jQueryUI ( http://jqueryui.com/ )


1
Так, одна помилка, яку ми допустили, - це побудувати непомітні шари шкур. 1 сирий завантажувальний інструмент, потім 2 незначні зміни, потім 3 досить грубі шкури для демонстрації, потім 4 професійні шкури - які виглядали абсолютно не так, як крок 3. Деякі з цих додаткових CSS дійсно почали заважати.
Стів Беннетт

помилки робляться, просто переконайтеся, що ви навчитеся на них, загалом, намагайтеся зробити речі максимально простими, залишаючись модульними :)
Єва

3

По-перше, я повинен визнати, що я ніколи до цього не працював з передніми перегородками.

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

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


+1 для "фокусування на компонентах, а не на цілих сторінках". Гарна ідея.
Стів Беннетт

0

Я розробляв HTML / CSS з кількома дизайнерами, і як уже було сказано, "срібної кулі" немає. Дизайнери, з якими я працював, не знали багато (нічого) про html / css. Деякі з них мали певний досвід веб-дизайну, і я мушу сказати, коли вони мають ці знання, це завжди закінчується легшим для розробки та «кращим веб-сайтом», особливо коли реагує UX на чутливість.

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

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

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

Це основний процес, який я намагаюся дотримуватися у більшості проектів:

  1. Дизайнер будує графічні стандарти, якщо вони не існують (я зазвичай тут не залучаюсь. Я просто намагаюся натякнути дизайнеру на шрифти, сумісні з веб-сайтами: шрифти Google)
  2. Макет зроблений дизайнером. Я залучаюсь сюди і працюю з дизайнером над створенням веб-схем (особливо для чуйних), перш ніж клієнт бачить це .
  3. Клієнт підтверджує змок
  4. Я кодую підрахунок

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

Це не врятує вас від щасливого дизайнера, який закликає вас у вечір п'ятниці з дуже гарною підказкою, яку бачив клієнт і тепер хоче з цим реченням: "Ей, спасибі, чи можете ви кодувати це для мене, термін - це вчора! " Тоді вся теорія розпадається, і якщо ти шукаєш роботу в цей момент, ти хороший для головної кінця протягом усього тижня.

Висновок:

Я не думаю, що це сильно відрізняється від будь-якого коду, пов’язаного з непроектним, найкращий спосіб роботи з іншими людьми - це спілкування з ними.


-1

Оскільки графічний дизайнер перетворився на веб-розробник повного стека, для мене це поки що була легкою частиною. Я вважаю, що багато разів виникає розрив у комунікації між командою дизайнерів UX та розробниками, які реалізують продукт. Звичайно, документи допомагають, але процес може почати відчувати себе набагато природніше, коли відбудуться розмови віч-на-віч про стратегію. Крім того, я знаю, що часу не вистачає для всіх, але спробуйте залучитись до етапу проектування та компонування. Це може допомогти надзвичайно, коли потрібна комунікація між дизайнером та розробником. Проект бере на себе більше об'єднаних зусиль команди і менше сценарію "Ну, я зробив свою частину, за стіною це йде". Я вважав, що дуже вигідно паралельно працювати над розробкою та розробкою, закликайте команду дизайнерів поставити вам каркасні рішення на початку процесу. Таким чином, ви можете зробити один стиль проходу, який стосується виключно компонування та позиціонування. Потім, як декани стають більш багатими та повноцінними. Візьміть інший пропуск CSS для зовнішнього вигляду та інших атрибутів стилю. Принаймні, це перешкоджає вам зосередитися на всьому.


1
цю публікацію досить важко читати (стіна тексту). Ви б не хотіли відредагувати його в кращій формі?
гнат

-2

Я зіткнувся з подібною проблемою. У мене є ідея, що для цього можна використовувати такі інструменти, як Greasemonkey або Tampermonkey. Лише минулого тижня я попросив коментарів щодо цієї ідеї: Як передавати інтерфейс динамічного веб-додатка в аутсорсинг? , але не отримав задовільних відповідей.

За допомогою цих інструментів ви можете вводити CSS, HTML та Javascript на сторінку. На мій погляд, ви даєте URL робочого сайту дизайнеру і очікуєте сценарії Greasemonkey. Теоретично ви повинні мати можливість швидко інтегрувати їх до існуючого сайту. Таким чином, завдання дизайнера буде писати HTML і CSS і змусити сайт фактично працювати. Це вимагає набагато більше навичок програмування з боку дизайнера.

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


3
Вибачте для узагальнення, але багато "графічних дизайнерів" не знають HTML та CSS, вони знають Photoshop, Corel / Illustrator, InDesign, Quark тощо. Це підкріплене ОП, говорячи про те, що дизайн був поставлений як серія " статичних зображень '. Якби вони знали HTML та CSS, вони були б "розробниками".
Дауст

У цьому випадку дизайнер стверджував, що знає трохи CSS та HTML, і таким чином висловлював частини дизайну (наприклад, кольори #abc), але недостатньо, щоб зробити велику різницю. І деякі терміни (наприклад, "padding") виявилися неоднозначними - не їх значення CSS.
Стів Беннетт
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.