Балансировка HTML/CSS между дизайнерами и инженерами

У меня есть вопрос о процессе разработки.

Справочная информация.. Я работаю на сайте скромного размера, где исторически дизайнеры создавали макеты/скриншоты того, что им хотелось, чтобы страницы и компоненты выглядели, а инженерная команда (включая меня) превратила их в html/css.

Это хорошо работает с точки зрения чистоты кода и значительно помогает при написании javascript. Однако он не помогает поддерживать согласованность от одной страницы/компонента к другой. На одной странице шрифт заголовка может быть 12px и еще один 11px, во многом потому, что его сложный сайт с большим количеством, чтобы отслеживать (и мы ездили на велосипеде через 4 дизайнера.) У нас есть только несколько действительно универсальных стилей, и они только использовать, когда инженеры распознают стиль, а не когда дизайнер говорит им.

Наш последний дизайнер - относительно способный кодер HTML/CSS. Мы думали, что у нас есть возможность создавать макеты в HTML/CSS и передавать нам код для быстрой интеграции. Наша надежда была в том, что дизайнеру было бы лучше быть последовательным в его стиле и что это может спасти нам некоторое время разработки впереди.

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

Вопрос: Как вы делаете руку от проектирования до разработки? Я знаю, что слышал о компаниях, которые позволили своей проектной команде делать все кодировки, но мне интересно, как это работает. Действительно ли команда дизайнеров включает членов инженерной команды в этих сценариях?

Поскольку мы структурированы прямо сейчас, нет никакого шанса в аду, мы бы позволили нашему дизайнеру писать окончательные шаблоны и проверять их на SVN, даже если он был опытным HTML-дизайном. Там слишком много в шаблонах, которые требуют знания нашей кодовой базы и потенциальных проблем с производительностью.

Как мы получим этот процесс? Это сон трубы?

Ответ 1

В частности - лично - поскольку я прихожу из web-dev, фона небольшого магазина, я делаю работу CSS и нарезаю PSD (обычно) самостоятельно. Но тогда мне нравится думать, что я хорошо закруглен:)

Как правило, лучший опыт, который у меня был в этом, - довольно большая компания с очень определенными группами разработчиков, включая команду разработчиков, которая создала команду gfx, команду разработчиков, которая сделала большую часть серверной архитектуры кодирования и приложений, и команда UE (пользовательский опыт), которая сшила их вместе, создавая разметку XSLT/JSP/HTML в целом и CSS и JS для клиентской стороны.

Был очень структурированный процесс:

userstory →
"wireframe" (документы) →
дизайн (PSD) →
"плоская" разметка (только DHTML) →
интегрированная разметка (с веб-приложением)

Где "каркас" будет близок к спецификации для UE, создаваемой с помощью UML или, возможно, visio. Я слышал термин, примененный к шагу 4, который, как мне кажется, подходит лучше, но это то, что он назывался там.

Несмотря на то, что это хорошо подходит для рассматриваемого вопроса, я обнаружил, что в него были встроены другие проблемы. Было очень сложно работать между командами, и из-за временных масштабов команда разработчиков редко включала UE в процесс принятия решений (что ставило UE в некоторые неудобные позиции), команда разработчиков и дизайн могут работать в перекрестных целях, и не было много возможностей для изучения в этих коробках в командах.

Мое подозрение (и, я думаю, идеальный сценарий) состоит в том, что разработчики проекта будут способны работать, например, с 80% задействованной технологии (будь то CSS, SQL и т.д.) для распространения контроля принятия решений и риск, но у каждого домена будет один (более?) "царь", который мог бы действовать как авторитет и надзор внутри домена. На самом деле производство этих проектов, на мой взгляд, странно и волшебное мастерство в нем, так что я не вижу реального совпадения с разработчиками, но я думаю, что пул художников и проектных команд перекрестных специалистов будет очень сильным.

Аполинги для долговечности. Я мог бы продолжить на этом немало, я много времени думал об этом.

Кстати, похоже, что вы можете сделать с некоторыми серьезными веб-разработчиками там (без обид). Имея проблемы для "поддержания согласованности с одной страницы/компонента на другую", кричит отказ от поиска CSS

Ответ 2

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

Часто одной модуляции недостаточно для желаемой интерактивности. Таким образом, некоторые блоки нуждаются в их взаимодействиях, которые также должны быть тщательно разработаны (например, анимация, компоновка жидкостей для размещения неопределенного контента, индивидуальное поведение с помощью дополнительного javascript, кэширование для устранения избыточных запросов и ускорения действий) или способность учитывать незначительные вариации презентации, что приносит нас в области программирования, где вы вычисляете размеры, включаете/выключаете детали, отслеживаете время, загружаете материал, недействительны предварительно загруженные материалы и т.д.

Введите HTML/CSS/JS. Они скорее являются продуктом эволюции, чем интеллектуальным дизайном. Вы не всегда можете заявить о своем намерении и сделать это. Вам нужны атрибуты, объявленные в html, глупых хаках в CSS в сочетании с дополнительной разметкой, смешными суммами js для сглаживания грубых краев, дублирования кода рендеринга на стороне сервера. Этот инструмент никогда не предназначался для создания приложений.

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

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

Ответ 3

Где я работаю, в основном то же самое. Дизайнеры создают макеты и спецификации дизайна пользовательского интерфейса, вплоть до пикселя, и разработчик создает из него код HTML/CSS/.

Причина, по которой я говорю код, заключается в том, что мы используем интерфейсы пользовательского интерфейса (а именно, GWT), и столько, сколько хотим, стили кода и CSS все еще очень связаны. Я не верю, что существует одна инфраструктура пользовательского интерфейса, в которой код может быть полностью отделен от дизайна пользовательского интерфейса.

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

Ответ 4

Проблема с передачами заключается в том, что идея и реализация одной группы не будут соответствовать возможностям и реализации следующей группы. Просто по своей сути передача обслуживания будет связана с проблемами. Итак, какова альтернатива вездесущему сценарию передачи обслуживания? Я думаю, что интеграция пользовательского интерфейса (UX) в гибкий и итеративный процесс разработки гарантирует, что действительно важно:

Затем проверяются требования клиентов.
Раннее и постоянное сотрудничество экспертов юзабилити, дизайнеров и программистов.

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

Джефф Паттон недавно сделал подкаст на Agile UX, который входит в некоторые концепции реализации и общие проблемы.

В Yahoo есть целая группа, посвященная гибкой юзабилити (которая в основном связана с дизайном интерфейса).

Для несоответствий CSS... Я просто предлагаю сделать руководство по стилю, а затем попытаться придерживаться его. Кто-то будет отвечать за "консистенцию дизайна" таким образом, что может отбросить любого, кто изобретает еще один способ отображения пользователя.

Ответ 5

В моей компании мой идеальный рабочий поток работает не очень часто, но иногда это происходит. Я знаю, когда это произойдет: инженеры пишут webapp и выводят семантический html с минимальным CSS. то у вас есть дизайнеры CSS.

Мне нравится, когда идет так, потому что:

Мне легко писать семантические HTML.
Я не очень хорошо подхожу с хорошим дизайном для моей семантической HTML.
Это вполне возможно сделать CSS, не задавая мне вопросов. Разметка просто говорит сама за себя.

Однако это редко срабатывает. Потому что:

CSS должен быть изменен всякий раз, когда изменяется HTML, а время дизайнера разрежено.
Кроме того, нашим дизайнерам не нравится стилизовать мою разметку, и бороться за свое время не нравится.
Наши дизайнеры часто хотят изменить разметку. В основном потому, что они считают, что некоторые макеты не могут быть выполнены без изменения разметки или потому, что они считают, что это единственный способ заставить IE подчиняться. Тем не менее, они технически не в состоянии изменить разметку.

У меня есть сомнения относительно многих из их дел. Много раз они заявляют о несовместимости IE, я сильно сомневаюсь, что они действительно хорошо знают IE. Есть аккуратные хаки CSS, чтобы заставить IE подчиняться, не прибегая к

<br clear="all">

Итак, к сожалению, обычно этот идеал немного для меня.

Ответ 6

Лучшим способом является отдельный рабочий процесс разработчика - разработчика. Проектирование веб-сайта и его кодирование - это совершенно разные задания. Существуют проблемы совместимости кросс-браузера, CSS, XHTML, помимо стандартов кодирования, с которыми приходится иметь дело.

Вы также можете выбрать аутсорсинг своего HTML для специализированного PSD to HTML conversion, такого как us (ButterflyHTML). В долгосрочной перспективе это может оказаться экономически эффективным.