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

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

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

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

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

Ответ 1

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

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

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

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

Все дело в общении и немного компромисса с обеих сторон.

Ответ 2

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

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

Введите код, который может использовать привязку данных. Модель-View-ViewModel или шаблон представления подходят для этого.
Поставляйте "время разработки" для ваших зависимостей в сервисах. Если класс, к которому вы привязаны, делает вызовы веб-сервисов, обязательно замените клиента веб-службы классом-заглушкой, который возвращает "фиктивные данные", которые дизайнер потребляет внутри смеси. Это можно легко сделать с помощью IoC и Injection Dependency Injection, введя одну реализацию, если HtmlPage.IsEnabled == false.
Используя привязку данных, вы можете ограничить количество "именованных элементов", которые у вас есть в вашем файле XAML. Если вы напишете выделение кода позади, вы в конечном итоге соедините свой код С# с именованными элементами, такими как txtName или txtAddress, что упростит дизайнеру "прикрутить".
Используйте шаблон команды вместо кода за обработчиками событий кликов. Если вы свободно связываете invoker события с обработчиком, вы можете иметь менее именованные элементы, и вы даете дизайнеру свободу выбора между кнопкой или пунктом меню, чтобы вызвать определенную команду.
Проверьте свой код в Blend! Даже если вы считаете себя чистым разработчиком, вы должны проверить, что ваш код потребляется инструментом, и стремиться получить наилучший опыт во время разработки. Некоторые утверждают, что инструмент не должен влиять на ваш дизайн программного обеспечения, так как некоторые жалуются на "дизайн для проверки" и принимают решения по разработке программного обеспечения только для того, чтобы сделать код более пригодным для тестирования. Я считаю, что это разумная вещь, и единственный способ, которым вы можете получить настоящий поток работы разработчика-разработчика.

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

Удачи!

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

Ответ 3

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

Ответ 4

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

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

Ответ 5

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

Real_World_WPF_DesignersAndDevelopersWorkingTogether

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

Ответ 6

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

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

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

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

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

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

Ответ 7

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

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

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

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

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

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

Ответ 8

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

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

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

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

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

Ответ 9

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

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

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

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

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

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

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

Ответ 10

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

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

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

Ответ 11

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

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

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

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

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

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

Итак, научитесь понимать, что ваша ответственность другая.

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

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

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

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

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

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

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

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

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

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

Ответ 12

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

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

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

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