Дизайнеры и разработчики, работающие вместе

Question

Богатые презентационные возможности WPF и Silverlight, такие как я, будут работать в тесном сотрудничестве с графическими дизайнерами в наши дни, как это имеет место в моем следующем проекте.

Есть ли у кого-нибудь какие-либо советы и опыт (с обеих точек зрения), чтобы сделать это более плавным?

Например, когда я недавно упомянул об источнике управления дизайнеру, я быстро сказал, что вы не можете управлять графикой, изображениями и т. Д., Поэтому это пустая трата времени. Поэтому я ответил: хорошо, но как насчет файлов XAML в WPF/Silverlight?

Скотт Гензельм рассказал об этой теме в podcast, но он больше сосредоточился на инструментах, в то время как меня больше интересуют проблемы/аспекты коммуникации.

Answer 1

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

В моем случае я должен был действительно забить дом тем, что почти весь мой JavaScript зависел от разметки, и когда он изменил свой чистый CSS, основанный на DIV макет, на табличный, не сказав мне тогда все мой JS собирается сломаться.

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

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

Это все об общении и о компромиссе с обеих сторон.

Answer 2

Это может быть немного не по теме (я отвечаю конкретно на ваш вопрос об управлении исходным кодом и графикой), но вы можете поместить двоичные данные (изображения и т. Д.) В исходный контроль (и, на мой взгляд, в много случаев) - они просто занимают больше места на диске, и вы не можете использовать представление diff для анализа того, что изменилось каким-либо значимым образом, но то, что вы делаете, - это история фиксации сообщений, документирующих каждую ревизию, способность отката и возможность легко архивировать (с пометкой ревизии в терминах SVN) все файлы (будь то визуальные активы, документация, исходный код и т. д.), принадлежащие определенной версии/версии вместе. Кроме того, ваша система сборки также легко извлекает все необходимое для создания конкретной версии вашего программного обеспечения из исходного элемента управления.

Answer 3

Привлечение графического дизайнера на ранних этапах проектирования и архитектуры.

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

Answer 4

Совершенно откровенно вы должны сказать дизайнеру, что изображения могут, должны и «будут помещены в контролеры-источники»! :)

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

XAML может (и должен) быть помещен в исходное управление, а в качестве файла разметки он будет пользоваться всеми функциями.

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

Answer 5

Одна из вещей, которые я обнаружил, заключается в том, что как вы, разработчик, разрабатываете свой код, сильно влияет на то, что дизайнер может с этим сделать. Часто вы загружаете образец приложения Silverlight или WPF из Интернета и открываете его в Blend, просто для того, чтобы на вас напал Blend, потому что код не работает хорошо внутри дизайнера. Если он не падает, он редко выглядит чем-то вроде запущенного приложения.

Недавно я поговорил в Tech Ed Australia и Новой Зеландии о методах, которые вы можете применить к «дизайну для удобства». Включен короткий список:

1. Напишите код, который может использовать привязку данных. Модель-View-ViewModel или шаблон представления подходят для этого.

2. Поставка «времени разработки» для ваших сервисных зависимостей. Если класс, к которому вы привязаны, делает вызовы веб-сервисов, обязательно замените клиента веб-службы классом-заглушкой, который возвращает «фиктивные данные», которые дизайнер потребляет внутри смеси. Это можно легко сделать через IoC и Injection Dependency Injection, введя одну реализацию, если HtmlPage.IsEnabled == false.

3. Используя привязку данных, вы можете ограничить количество «именованных элементов», которые у вас есть в вашем файле XAML. Если вы напишете выделение кода позади, вы в конечном итоге соедините свой код C# с именованными элементами, такими как txtName или txtAddress, что упростит дизайнеру «ввернуть».

4. Используйте шаблон команды вместо кода за обработчиками событий кликов. Если вы свободно связываете invoker события с обработчиком, у вас может быть меньше именованных элементов, и вы даете дизайнеру свободу выбора между Button или Item Item, чтобы вызвать определенную команду.

5. Проверьте свой код в Blend! Даже если вы считаете себя чистым разработчиком, вы должны проверить, что ваш код потребляется инструментом, и стремиться получить наилучший опыт во время разработки. Некоторые утверждают, что инструмент не должен влиять на ваш дизайн программного обеспечения, так как некоторые жалуются на «дизайн для проверки» и принимают решения по разработке программного обеспечения только для того, чтобы сделать код более пригодным для тестирования. Я думаю, что это разумная вещь, и единственный способ, которым вы можете получить настоящий поток работы разработчика-разработчика.

Другие советы - начать с малого. Если ваш дизайнер новичок в XAML, WPF и Silverlight, начните с представления их команде проекта и попросите их сделать некоторые базовые проекты в инструментах, которые они знают. Позвольте им сделать несколько кнопок и иллюстраций в Adobe Illustrator и экспортировать их в XAML и показать им, как вы можете напрямую использовать свои проектные активы. Продолжайте вводить все больше и больше, и, надеюсь, они заинтересованы и хотят перейти на Blend.Это довольно кривая обучения, но она того стоит!

Удачи вам!

PS: Я написали все, что касается шаблонов и создания дизайнерского кода в моем блоге на http://jonas.follesoe.no. Вы также можете найти ссылки на видеозапись моего обсуждения в Tech Ed, а также множество ссылок для дальнейшего чтения по этой теме.

Answer 6

Первоначально предполагалось, что профессиональные дизайнеры будут работать в Expression Blend, а разработчики будут работать в Visual Studio, внося изменения в один общий набор исходных файлов. Хотя это, безусловно, возможно сделать это (пока вы будете осторожны, чтобы регулярно проверять, что вы не нарушили что-то, ожидаемое другим разработчиком или инструментом разработки), многие члены сообщества разработчиков, в том числе некоторые из Microsoft, обнаружили преимущества при сохранении активности проекта Blend и Visual Studio SEPARATE - вплоть до ручного вырезания и склеивания тщательно отредактированных версий сгенерированного Blend Xaml в «официальный» источник проекта VStudio, а не позволяя дизайнерам и разработчикам работать непосредственно на одном общая база кода. Команда пользователей Microsoft в Великобритании опубликовала видеоролик, описывающий проблемы, с которыми они столкнулись, чтобы попытаться согласовать усилия разработчиков и разработчиков в реальных проектах.

Real_World_WPF_DesignersAndDevelopersWorkingTogether

Одним из основных уроков, извлеченных в том, что вы не можете укомплектовать проект с дизайнерами и разработчиками, которые полностью невежественны доменами друг друга. Разработчики должны быть достаточно знакомы с Blend, что они могут предоставить дизайнерам полезные оболочки пользовательского интерфейса для дизайнера, чтобы украсить, и полезные «заглушки» данных, которые разработчик может проектировать в интерактивном режиме, а разработчику необходимо иметь достаточное понимание проблем разработки, которые они находят «Делайте такие вещи, как удаление элементов управления и замену их на пользовательские визуальные элементы, - не понимая, что они сломали все функциональные возможности, привязанные к исходному элементу управления.

Answer 7

Я очень верю в подход Integrator, который действительно является той ролью, которую я должен был выполнить, чтобы наши усилия WPF были успешными.

Laurent Bugnion имеет post, описывающий то, о чем я говорю. Robby Ingebretsen также является большим сторонником такого подхода.

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

Однако, независимо от того, в каком мире они происходят, им обычно приходится создавать навыки, которых у них никогда не было. В моем случае я разработчик, который любит слой пользовательского интерфейса, и поэтому я бы сказал, что я разработчик с дизайнерскими тенденциями. Чтобы покрыть этот пробел и иметь продуктивные беседы с нашим графическим дизайнером, мне пришлось подобрать целую кучу дизайнерских навыков: обучение использованию Expression Design, XAM 3D и т. Д.

Шеннон Браун недавно дал презентация на местной конференции разработчиков о взаимоотношениях разработчиков и дизайнеров и рабочие процессы, которые сообщество открывает для них. Я не присутствовал на конференции, но я думал, что его slides были большой дискуссией по этому вопросу.

Answer 8

Концепция Microsoft в отношении брака дизайнера/разработчика определенно, похоже, разрушается в реальной жизни.У меня есть опыт работы над довольно масштабным проектом WPF, в котором задействовано 2 выделенных ресурса дизайна около 4 месяцев. Вот некоторые факты, которые Microsoft, похоже, часто забывает.

• Дизайнеры часто предпочитают использовать Маки (дизайнеры в моей компании являются 100% Mac - 0% Windows)
• смесь не работает на Mac (насколько решения VM - дизайнеры, как правило, не нравится geeky решения, такие как запуск странных приложений в иностранной ОС).
• Дизайнеры используют свои инструменты для торговли - Photoshop и Illustrator. Период.
• Агрессивность сегодняшних расписаний обычно не дает достаточного времени для того, чтобы дизайнеры могли изучить совершенно новую среду приложения/дизайна (например, Blend).

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

Я оказался тем парнем (графически просвещенным программистом). Я потратил много времени на экспорт XAML из файлов Illustrator, при необходимости очищающий их вручную и делая эти активы легко используемыми отображаемыми объектами в Blend или VS. Были и времена, когда я использовал элемент дизайна и повторно рисовал его с помощью blend (обычно, когда исходный актив был основан на растровых изображениях, и было более целесообразно преобразовать его в вектор).

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

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

Answer 9

По моему опыту, интегратор или роль «devsigner» действительно должны участвовать в этом процессе, если каждый из (небольшой) команды не сможет выполнить эту роль. Это очень редкое обстоятельство. Обычно вы обнаружите, что разработчики очень хорошо развиваются, но не так хороши в дизайне/удобстве использования, и дизайнеры отлично справляются с эстетикой/удобством использования, но не хотят или недостаточно образованы для кодирования. Очень важно иметь кого-то, кто может пересекаться в обоих мирах и «говорить на языке».

Интегратор должен координировать элементы управления, которые разрабатываются с дизайнерскими активами, которые создаются дизайнерами. В нашем текущем проекте у нас есть 6 активных разработчиков и 2 дизайнера из внешнего магазина. Я являюсь интегратором для этого проекта, и большую часть своего времени я проводил в Expression Blend. Разработчики работают в основном в VS, создавая элементы управления, соответствующие нашей спецификации продукта, а дизайнерский магазин разрабатывает то, как будет выглядеть конечный продукт. Дизайнеры работают в Illustrator. Моя задача - взять файлы Illustrator и создать из них стили управления, а затем применить их к элементам управления, разработанным нашей командой разработчиков. Когда мы движемся к Blend 3 с собственной поддержкой PSD и AI-файлов, эта задача становится намного проще.

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

Answer 10

Я собираюсь предположить, что вы ссылаетесь на проекты RIA с момента упоминания SL.

Я работал над несколькими проектами RIA с Adobe, разрабатывая и разрабатывая приложения и службы.

Лучший совет, который я могу дать вам на основе моего 14-летнего опыта работы в качестве дизайнера UX и Visual, с некоторым опытом программирования, хотя и жалким по сравнению с вами, ребята.

Примите, что вы не понимаете друг друга.

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

Для разработчика кнопка в основном является общей, для дизайнера это не тот случай. Дизайнеры думают в композиции, думают разработчики в рамках.

Итак, научитесь понимать, что ваша ответственность различна.

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

Дизайнер должен подумать о приложении или услуге как-то уникальном. Это может означать, что кнопка не является кнопкой. Там могут быть разные размеры или цвета или другие неприятности.

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

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

Убедитесь, что вы четко понимаете, как дизайнер должен доставить вам, чтобы вы не тратили свое время или свое собственное время. Какой формат, активы? Именование?

Все, что связано с доставкой от одной парадигмы к другой.

И самое главное общаться и уважать то, что они не знают, как делать JavaScript или как понимать основные идеи CVS.

Большинство разработчиков вы не знаете, как кернировать, чтобы сохранить свою жизнь, что такое вдова, как наилучшим образом нанести слой FireWorks или создать фотореалистичную иконку, создать хороший слоган или сделать что-то понятное для среднего Джо в 4 слова. Вы не знаете, что такое сетка или выравнивание, и вы, как правило, делаете вещи зелеными и фиолетовыми на черном.

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

И самое главное. Не начинайте обсуждать Mac и PC :) Проекты были отменены из-за этого.

Answer 11

Я Феликс Корк, дизайнер из подкаста hanselman, который вы упомянули, так что вот пара моментов от настоящего креатива, а не разработчика.

Потребовалось много времени, чтобы привыкнуть к инструментам разработчика - я никогда не слышал о Visual Studio, C# или любом типе источника управления, когда я впервые начал работу с xaml несколько лет назад. Они были так же чужды мне, как, может быть, Illustrator или 3DsMax были бы для вас.

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

К счастью, я научился стать более ориентированным на дизайн интегратором, чем прямым творческим, и, возможно, это роль, которую вы должны включить в свой проект. Это иллюстрация, которую я сделал для нашей красоты и сеанса разработчика - разработчика/разработчика в Mix - если любой из вас находится слишком далеко в любом конце спектра, может быть трудно понять, как работает другой и какова должна быть их роль.

рад ответить на любые конкретные вопросы!

п.с. вы не хотите 100Mb + .psd файлы в системе управления версиями;)

Answer 12

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

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

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

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

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

Следовательно, разработчик, который не может проверить и тестер, который не может кодировать, является симптомом той же промышленной незрелости.

Вы не узнаете об этом из шаблона Scrum для TFS.Microsoft отстала от времени на пути к гибкому мышлению в игре даже в самых примитивных формах, и теперь, когда мы продвигаемся в Lean, Microsoft будет еще на три-пять лет от попыток включить Lean-мышление в свои производственные линии , Не ждите, пока Microsoft расскажет вам, как формировать команду и рабочий процесс. Теперь вы можете узнать у людей, что Microsoft в конечном итоге обратит внимание в течение нескольких лет.